Общая логика

Логически наша работа была поделена на два крупных блока:

1. Проектирование и создание внутренней инфраструктуры для обеспечения бизнес-процессов. 
2. Продуктовая аналитика, создание и маркетинг сервисов для клиентов. 

Внутренняя инфраструктура крупноблочно выглядит следующим образом:

Сервисы для клиентов:

Внутренняя инфраструктура

Диспетчерское ПО

Проектирование

Диспетчерское ПО в нашем случае – это ядро системы, обеспечивающей выполнение и мониторинг всех основных бизнес-процессов компании:

• Диспетчеризация заказов
  Прием, обработка, геокодирование, распределение, управление, учет, биллинг.
• Работа с клиентами
  Управление контрагентами, документооборот и ключевые CRM-процессы.
• Работа с автопарком
  Управление водителями и транспортными средствами, планирование загрузки внутренних мощностей, управление загрузкой привлекаемых автопарков.
• Администрирование системы
  Блок отчетности, управления правами, доступами и настройкой процессов.

Проектирование на данном этапе состоит из следующих шагов:

1. Сбор и формирование бизнес-требований.
   На данном этапе проводится ряд интервью с заказчиком для выявления целей программного продукта для бизнеса, целей данного проекта по его созданию, требования бизнеса с точки зрения процессов, а также формулирование измеримых показателей, по которым мы будем впоследствии оценивать эффективность созданного продукта. На выходе получаем артефакт, обязательный к прочтению всеми участниками проекта, где понятным языком изложены осмысленные требования.
2. Опрос конечных пользователей.
   В нашем случае конечные пользователи уже работали с программными продуктами, некогда внедренными в компании. Мы наблюдали за их работой и провели опрос по части удобства, эффективности, скорости и пожеланий к изменению их инструментов работы. По результатам сформировали карту автоматизируемых бизнес-процессов.
3. Разработка требований к дизайну процессов и интерфейсов. 
   На данном этапе мы сопоставили карты процессов с требованиями бизнеса с одной стороны и пожеланиями конечных пользователей к инструментарию с другой и сформировали требования для следующего этапа работ.

Остановимся на последнем пункте.
В разработке мы придерживаемся методологии Agile, но со своими нюансами. Мы убеждены, что каждая средне-крупная задача в разработке продукта должна иметь аргументацию и измеримый эффект для бизнес-показателей.

Поэтому перед началом следующего этапа мы составляем вот такой бэклог для разработки продукта:
 

Смотреть подробнее/ скачать по ссылке.

Приоритизация задач начинается с роадмэпа. Совместно с клиентом мы формируем верхнеуровневый план продукта, в котором обозначаем стратегические планы по запуску некоторых программных частей системы.

Следующий шаг – разработка бэклога задач.

1) Формируем список задач:

• В первую очередь приоритизируем задачи исходя из роадмэпа продукта и стратегических целей.
• С командой разработки определяем скоуп, в который пойдут наиболее приоритетные задачи.
• Описываем задачу в формате пользовательских историй, чтобы задать им ясный приоритет исходя из экономики решения.

2) Задаем показатели продаж:

На данном этапе всего два условных показателя – количество входящих заявок и стоимость одной входящей заявки.
Эти показатели можно проверить тестовой рекламной кампанией, или взять из исторических данных (если такие есть).

3) Создаем мультипликатор влияния на выручку:

Чтобы приоритизировать задачи с привязкой к экономике и понимать, в какой связке между программными продуктами и/или бизнес-процессами необходимы улучшения – мы формируем воронку исполнения входящего заказа. 

В нашем случае это 4 шага:

• прием заявки – учитываем омниканальность: сайт, email, телефон, приложение;
• создание заказа – это первый шаг воронки, где мы теряем в конверсии. Обращение может быть обработано не должным образом. Или клиент может позвонить за справочной информацией и не получить ответа на интересующий вопрос;
• исполнение заказа – заказ может быть отменен по разным причинам. Не устроило время подачи, стоимость или из-за нехватки автомобилей;
• оплата заказа – если не сработает приложение для водителей или пользователей, сумма будет рассчитана неверно или не рассчитана вообще. Или клиент может не оплатить заказ в принципе (сбежать в конце концов) и т.д.

Далее, чтобы рассчитать экономическую целесообразность и приоритетность задач, мы формируем финансовые показатели:

• средний чек заявки;
• повторные покупки;
• выручка – перемножаем показатели, отнимая стоимость обслуживания входящих заказов.

Последний шаг – формулирование задач и расстановка плановых изменений показателей значений:

• формулируя задачу, мы меняем тот или иной плановый показатель экономики или воронки и получаем расчет изменения выручки;
• добавляем здесь плановое значение себестоимости выполнения задачи;
• и получаем срок окупаемости, заранее вводя в формулу условие убыточности задачи.

Теперь мы должны сфлормулировать минимальный необходимый функционал для минимального прохождения каждого шага воронки и приоритизировать их по срокам окупаемости.

Ниже мы покажем, как данный инструмент применяется в ходе работ над развитием и поддержкой продукта, когда есть реальные исторические данные для принятия решений.

Дизайн

Обычно требования к дизайну интерфейсов у бизнес-приложений сводятся к формулировке – лишь бы работало. И делаются, как принято говорить, “разработчиками для разработчиков”.

В общем случае, в этом есть и экономия средств на разработку клиентской части, есть технические ограничения (не секрет, что большинство бизнес-приложений как были созданы на технологиях 2000-х, так там и остались – слишком долгим и дорогим кажется пересоздание).

Вот как выглядят интерфейсы большинства систем:

У крупных игроков ситуация такая же. Вот, к примеру, чем приходится пользоваться диспетчерам Яндекс.такси:

Мы же решили взять на вооружение другой подход – создание продукта, который быстро интегрируется в бизнес-процессы (а значит будет интуитивно понятным для конечных пользователей) и кроме обеспечения отчетов для управляющих органов, будет действительно полезным инструментом для конечных исполнителей, ускоряющим их работу и следовательно, эффективность.

Из требований к дизайну на входе мы получили:

1) Обучение оператора — не более 2-х недель
Система узкоспециализированная, перед ее использованием оператора необходимо обучить. В сроки предполагаемого обучения более чем уложились. В финальной версии время обучения и отработки навыков составляет не более 2-х дней.

2) Формирование заказа — не более 1 минуты
Действия оператора должны быть организованы максимально эффективно на всех этапах с момента звонка клиента до назначения борта. Мы исключили ошибки ввода, долгие переключения между полями, добавили возможность быстро проверить заказ.

3) Полноэкранный режим и мониторы от 21’
Операторы клиента работают на больших мониторах. Это упростило задачу по организации рабочего пространства. Полноэкранный режим позволил использовать края и углы экрана как области с самым маленьким временем реакции согласно закону Фиттса.

Концепция Изучили первую версию функциональных требований нового продукта — приступаем к проектированию структуры и дизайн-концепции. На этом этапе тестируем разные идеи компоновки интерфейса, не углубляясь в детали.

Разделение по ролям
В системе много ролей — диспетчеры, сотрудники отдела контроля качества, начальники смен. Функционал распределили удобно для всех, чтобы зоны ответственности не пересекались.

Всплывающие панели
Каждая панель несет свою функцию. Будь то просмотр карточки водителя или заведение нового заказа. В каждый момент оператор видит только одну карточку и выполняет одну задачу, что снижает его нагрузку.

Карта
Карта работает синхронно с карточками и меняет свое состояние в зависимости от них. Некоторые ситуации можно понять только с помощью карты. Например, определить какой маршрут у заказа или какая сейчас загруженность таксопарка в центре города. Поэтому мы отдали под нее 70% экрана.

Сразу после закрытия этого этапа — детальное прототипирование. Месяц работы с функциональными требованиями и согласованиями, и мы получаем детальный интерактивный прототип. 

Горячие клавиши При работе с системой можно использовать только клавиатуру. Это сделано с целью сократить время на переключение между устройствами ввода. Если бы оператору приходилось каждый раз брать в руку мышь, чтобы закрыть/открыть окно или поменять фокус в поле, время работы увеличилось бы не менее чем в 2 раза. Мы сделали использование мыши необязательным, оператор пользуется ей только для обучения.

Все основные операции можно делать с помощью горячих клавиш. Их полный список доступен при двухсекундном зажатии клавиши Ctrl. К тому же, когда оператор видит это окно, первая клавиша у него уже зажата, осталось подсмотреть вторую.

Задержка создана, чтобы не отвлекать этим экраном при простом переключении языков или копировании текста.

Цветовое кодирование У каждого раздела свой цвет. Не читая заголовки, оператор может понять, в каком разделе он сейчас. Даже с помощью периферического зрения. Копируются не только разделы, но и элементы внутри них. Например, у кнопки создания нового заказа цвет такой же как у формы заполнения нового заказа. Эффективность этого приема напрямую связана с опытностью пользователя. Новичок будет читать заголовки и смотреть на графику, а опытный поймет состояние, даже не переводя взгляд.

Защита от ошибок Важно понимать, что на той стороне сидят люди и никто не застрахован от ошибок. В случае с такси, это грозит, например, появлением недовольного клиента, мерзнущего на улице, потому что его машина уехала на другой адрес.

Чтобы сократить количество ошибок, связанных с человеческим фактором, мы применили 2 стратегии:

Двойное подтверждение.
Например, оператор не может просто так случайно закрыть заказ на этапе заполнения. Для этого необходимо еще раз подтвердить действие.

Неслучайные комбинации.
Например, чтобы отправить заказ на обработку водителям, оператор нажимает комбинацию клавиш Ctrl+Enter. Случайно нажать их практически невозможно.

Резюме Задачу уложиться по времени оформления заказа в 1 минуту выполнили. В общем случае заказ оформляется в несколько раз быстрее.

P.S.: Разработчикам программных продуктов, которые сдают в аренду ПО диспетчеризации в этом секторе, мы рекомендуем обратить внимание на грамотный интерфейс своего продукта. Впрочем, это справедливо и для логистических отделов внутри компаний-ритейлеров.

Очевидные плюсы:

• Быстрота внедрения – это дешевле. 
• Быстрота выполнения операций – удобнее для персонала, увеличивает скорость выполнения операций, а следовательно, эффективность работы. 
• Конкурентное преимущество – пока не все озаботились этим вопросом, интерфейс системы может быть одним из ключевых факторов принятия решений о покупке, если вы делаете продукт на продажу.

Кажущиеся минусы:

• Высокая стоимость разработки и содержания новых технологий – устаревшая реальность. Современные фронтенд-фреймворки позволяют быстро и качественно создавать и, самое главное, масштабировать и менять интерфейсы.

Разработка и интеграция

Здесь речь пойдет не о практиках управления проектами, о которых уже написано много полезной литературы. Мы расскажем о практиках, которые помогают нам эффективно управлять разработкой продуктов подобного масштаба.

Риски разработки Первое, с чего необходимо начать внутреннюю организацию или работу с подрядчиками по разработке – это нивелирование рисков.

Риск №1 – заменяемость команды.
Первый и ключевой риск при разработке программного продукта, от которого зависят ваши бизнес-процессы – это заменяемость подрядчика или специалистов на проекте.

Это достижимо, при изначальной разработке и дальнейшей поддержке технических требований.

Требования не должны быть 300-х страничным, нечитабельным документом. Во-первых, избыточные требования все равно на доли процентов не будут актуальными к завершению проекта, во-вторых, их поддержка дорого стоит.

При наличии актуальных требований вы увеличиваете скорость вхождения нового подрядчика или специалиста в проект.

Риск №2 – качество.
Вопрос качества разработки спорный. Мы, например, применяем следующие критерии оценки до запуска проекта в коммерческую эксплуатацию:

1. Скорость сборки и интеграции. 
2. Доступность.

Для увеличения скорости сборки и интеграции продукта необходимы автоматические тесты. Они проверяют ключевые связки в продукте в момент добавления нового функционала. Это требует времени и стоит денег. Но на крупном проекте такие тесты необходимы, чтобы разработчики не сидели днями в поисках всплывшей проблемы. Или ошибки не обнаруживались позже, в процессе коммерческой эксплуатации (особенно, если внутри системы производятся взаиморасчеты).

Доступность системы необходимо определить на уровне бизнеса. В зависимости от нагрузок и других факторов, система должна иметь % допустимой доступности вне зависимости от происходящего. Есть специальные тесты, которые позволяют проверить доступность системы при определенных нагрузках и нестандартных случаях поведения. На основании необходимой доступности формируются требования к ИТ-инфраструктуре программного продукта.

KPI разработки Когда продукт уже работает и запущен в коммерческую эксплуатацию, мы можем использовать измеримые показатели эффективности его работы.

Мы применяем следующие:

1. Скорость загрузки страниц – важно для понимания быстродействия системы.
2. Процент доступности в коммерческой эксплуатации – следим за downtime в течение периода и фиксируем время восстановления.
3. Процентное соотношение функциональных изменений и ошибок, на которое тратится время команды разработки – если у нас в течение нескольких месяцев работы много ошибок, значит тестов недостаточно и продукт плохо спроектирован. Если много функциональных изменений, значит мы либо быстро растем и все хорошо (если это добавление какой-то логики), либо мы слишком часто меняем требования – нужно остановиться и продумать наперед требования к продукту.

KPI продукта Мы осознанно вынесли в отдельный пункт KPI продукта, от KPI разработки.

Дело в том, что команда разработки занята решением двух задач:

1. Технических.
2. Бизнес-задач.

KPI и риски технических задач перечислены выше.

У бизнес-задач критерии оценки другие. Здесь важно понимать, какой профит приносят те или иные функциональные изменения и улучшения, приоритизировать эти задачи по критериям достижения бизнес-результатов и отдавать на техническую проработку и реализацию.

Для оценки KPI продукта мы используем две ключевые метрики:

1. Процент задач выполненных командой разработки в периоде, приносящих изменение в KPI бизнеса.
2. Абсолютные значения изменений KPI бизнеса по результатам выполнения задач командой разработки в периоде.

В данном случае мы используем тот же бэклог, что и на этапе проектирования. Но теперь у нас есть реальные данные, которые со временем позволяют точнее прогнозировать изменение KPI.

Смотреть подробнее/ скачать по ссылке.

Приложение для водителей

Мобильное приложение для водителей – это ключевой источник получения информации и работы с конечными исполнителями заказов.

Важные моменты в проектировании приложения для водителей:

1. Логика работы приложения должны быть “железобетонной”, т.е. все тексты, кнопки и прочее должны быть однозначно понятны.
2. Необходимо учитывать, что пользователь приложения в основном находится за рулем – т.е. учитывать размещение планшета на лобовом стекле или приборной панели, количество необходимого внимания для реакции на приложение во время движения и пр.
3. Обязательно необходима справка-инструкция для обучения водителей, как перед запуском приложения, так и постоянный доступ при использовании.
4. Участки дорог без связи с интернетом – например, если расчет стоимости поездки будет происходить в месте без интернета, приложение должно уметь хранить и частично обрабатывать данные на клиенте, с последующей передачей зашифрованных (иначе легко будет взломать) данных на сервер, для финального расчета.

Как показала наша практика, сервисы пассажирских перевозок Яндекс.Такси, Uber и Gett сформировали и внедрили в массы кейс использования мобильных приложений водителями – это увеличивает скорость внедрения таких решений для автоматизации в том числе внутренних бизнес-процессов. Самое время задуматься о создании таких решений.

Система внешних личных кабинетов

Кабинет создан для владельцев и менеджеров партнерских автопарков.

Основной функционал кабинетов:

1. Карточка контрагента с данными.
2. Создание профилей водителей и транспортных средств со связками в борта.
3. Планирование загрузки и расписание работы своего автопарка.
4. Взаиморасчеты и финансовая отчетность, которая позволяет партнеру эффективно управлять автопарком (видеть, кто из водителей приносит больше денег, кто отказывается от поездок и т.д.).

В данном случае, мы практически “копируем” функционал блока управления транспортом из диспетчерского ПО и передаем его с “урезанными” правами партнеру.

Преимущества наличия такого кабинета для партнера:

1. Вы предоставляете партнеру не просто доступ к вашей системе, но инструмент управления своим автопарком, оценки эффективности работы водителей и прозрачность взаиморасчетов.
2. У вас всегда актуальные данные доступности и статуса партнерского автопарка и конкретного водителя на заказе, а значит скорость выполнения операций снова увеличивается.

Сервисы для клиентов

Личные кабинеты

В нашем случае речь идет о корпоративных клиентах и агентах (посредниках). На самом деле, это важный момент, очень частая ситуация, когда на стороне компании, оказывающей услуги клиентам, нет real time данных о происходящем в логистическом операторе.

Это усложняет жизнь всей цепочке: конечным клиентам – время уточнения статуса заказа, ритейлерам – время для выяснения актуального статуса и дальнейшая работа с возражениями клиента, оператору – время на выяснение ситуации у водителя и т.д.

Что необходимо учитывать при создании подобных личных кабинетов: Роли в системе.
В нашем случае мы имеем:
Конечного клиента – пассажира.
Заказчика услуги – офис-менеджера или помощника конечного клиента.
Спонсора оказания услуги – финансового менеджера.
Агента – гостиницу или ресторан, который заказывает автомобиль у нас, но не является конечным клиентом. Потребности каждой роли.
Они разные. Конечному клиенту нужно знать только актуальный статус своего заказа. Заказчик услуги может заказывать и мониторить одновременно несколько заказов, для него важно создать заказ на доставку и ждать решения от системы.
Для финансового менеджера же важны прозрачные финансовые выкладки по периодам, для осуществления взаиморасчетов с компанией перевозчиком. Исходя из потребности, у нас выявляются общие с диспетчерским ПО функциональные требования:

1. Диспетчеризация – с серьезным ограничением функционала, но той же логикой: создания, отслеживания и учета заказа.
2. Администрирование – назначение ролей в системе, финансовые и другие выкладки с привязкой к карточке контрагента.

Спроектированный интуитивно-понятно и прилично интерфейс диспетчерского ПО, таким образом, позволил нам “вырезать” из личные кабинеты, перераспределив права и спрятав некоторые возможности, в зависимости от роли в системе.

Приложение для пользователей

В нашем случае приложение для пользователей – не просто мобильный доступ к услугам компании для корпоративных клиентов (в этом случае, это удобно конечным пассажирам).

По сути приложение для пользователей – это вывод нового для b2c рынка продукта в сегменте пассажирских перевозок, в нашем случае, премиум-класса.

И потому, этот вопрос требует отдельной проработки, начиная с бизнес-модели. С точки зрения логистики грузоперевозок – этот пункт, скорее всего, актуален для компаний сдающих свое ПО в аренду, практики продуктовой разработки здесь будут максимально полезны и применимы.

Продуктовая аналитика User App

1) Бизнес-модель (Canvas)

Начинаем мы с построения бизнес-модели на основании гипотез. На данном этапе записываем то, что понятно в данный момент времени.
Мы составляем свой вариант Business Model Canvas:

Смотреть подробнее/скачать по ссылке.

Формулируем наших потребителей и несколько их ключевых проблем (3-4 максимум), формулируем решения, которые отвечают на эту проблему, УТП и преимущества, каналы распространения и прикидываем структуру расходов и доходов.

В нашем случае мы не смогли сформулировать УТП на данном этапе. Продукты без УТП бывают, конечно, но это более рискованно, предполагает больший бюджет для маркетинга и не всегда отвечает амбициям инвесторов и основателей. Чтобы сформулировать УТП, мы приступили к следующему шагу.

2) Изучение рынка

a) Сначала нужно изучить сегменты рынка в принципе
В случае с агрегатором такси премиум-класса, у нас выделились следующие сегменты:

Компании, с собственным автопарком, оказывающие услуги перевозки, которые вообще не продвигаются в интернете.

Пример:

Такси-Бизнес

Компании, имеющие и свой автопарк и привлекающие партнерские автопарки, которые присутствуют в интернете.

Пример:

КОМАНДИР

Агрегаторы. Яндекс, Gett, Uber, Wheely и пр.

Пример:

Яндекс.Такси

У каждого сегмента своя направленность на сегмент аудитории. Первые работают с семьями и постоянными клиентами давно и скорее являются аутсорсинговой компанией личных водителей. Во втором сегменте те, кто находится в стадии перехода от первого типа компаний к третьему. В третьем сегодняшние лидеры рынка премиум-перевозок Москвы и ЦАО. Этот шаг дал нам примерную картину конъюнктуры рынка вообще.

b) Отличия

Чтобы сформулировать наши преимущества, необходимо было проанализировать текущую ситуацию. Мы сопоставляли конкурентов по следующим признакам:

• Тип автопарка: свой/ партнерский 
• Виды автомобилей: эконом, бизнес, VIP, V-class 
• Целевой сегмент клиентов: физлица, юрлица 
• Каналы получения заказов: телефон, сайт, приложение 
• Способы оплаты: наличные, карта, приложение (с привязкой к карте), безналичный расчет

По результатам анализа сопоставили, какие для наших типов целевой аудитории требуются решения, выявили возможные точки роста и дополнили гипотезы решения проблем и каналов доставки продукта до аудитории.

3) Customer Development

Напридумывали, теперь нужно все проверить.

Составляем опросник и идем к реальным людям – представителям аудитории:

• Действительно ли есть проблемы, которые мы сформулировали? 
• Как сейчас решают проблемы (если никак, то может и не столь нужно решение?)? 
• Как выбирали решение (к каким конкурентам пошли, почему выбрали именно их, что понравилось, что нет)? 
• И вообще как можно подробнее о том, почему человек решил обратиться за решением проблемы, как к этому пришел, что подтолкнуло, какие есть скрытые потребности и т.д.

По результатам такого опроса, как правило, половина гипотез отбрасывается, часть добавляется в бизнес-модель, часть записывается и сохраняется для проверки в будущем.

Очень хорошо и подробно когда-то Дмитрий Алексеев, наш партнер из компании Digital change, написал на хабре саммари книги Running Lean, а еще конечно рекомендуем почитать Стива Бланка.

4) Экономика

Теперь от гипотез к цифрам.

Сначала считаем доходы.
У нас есть услуги перевозки, мы придумали некоторые фичи (NDA), которые позволяют увеличивать LTV и средний чек, записали все виды оказываемых услуг с ориентировочной стоимостью.
Прикинули LTV на уровне: 1-2 раза (0101) может попробовать каждый. За этим показателем нужно будет пристально следить в действии – спрогнозировать до появления продукта сложно.
Учли Churn Rate – отвалы людей, которые попробовали, но на следующий расчетный период отказались от нашего продукта в пользу конкурентов или по другим причинам.

Маркетинг.
Рассчитали примерную стоимость привлечения клиента на сайт/ в AppStore. Рассчитали конверсию. Снизили её с учетом дополнительных отвалов после установки приложения.

Получилось примерно следующее:

Экономику считаем в двух сценариях:

• Умеренно пессимистичный – который на самом деле с высокой вероятностью всегда возможен и мы должны быть к нему готовы.
• Умеренно реалистичный – который нам хотелось бы видеть.

Отдали клиенту на разработку финансовой модели, расчет расходов с роадмэпом развития продукта и т.д.

5) Развитие продукта

Помните вопрос про гипотезы роста? На этапе Customer Development мы выявили весьма интересные, которые позволяют бизнесу диверсифицироваться и увеличить выручку в 5 раз в течение 1-2 лет. По этим гипотезам также прикинули экономику и скорректировали роадмэп продукта с учетом такой диверсификации после набора пользовательской базы.

Интернет-ресурсы компании

Веб-сайт компании, в нашем случае, должен был выполнять следующие функции:

1. Представительские – для корпоративных клиентов, для которых порой важно подтвердить дееспособность подрядчика таким образом.
2. Маркетинговые:
   Для привлечения b2c клиентов – отдельная посадочная страница с продуктом – мобильным приложением;
   Для привлечения b2b клиентов – отдельная страница с рассказом о преимуществах для корпоративных клиентов и демонстрацией личных кабинетов;
   Для привлечения партнерских автопарков.

Причем страница для привлечения b2c клиентов, с демонстрацией мобильного приложения, в обязательном порядке должна быть оптимизирована под просмотр со смартфонов.

Резюме

О проектировании и дизайне внутренних программных продуктов:

1. Используйте жесткую приоритизацию задач в разработке и отслеживайте конечный профит каждой. Так вы будете максимально эффективно распределять задачи. 
2. Интуитивно-понятный интерфейс важен и для продуктов внутреннего использования – это возможности гибкости, масштабирования и скорости внедрения на предприятиях.

О разработке программных продуктов:
Требуйте заранее разработку и поддержку документации продукта и пояснение об используемых тестах.
Применяйте KPI для оценки качества разработки.
Разделяйте оценку эффективности работы технической команды и принятия решений о приоритетах и конечной эффективности выполняемых задач.

О продуктовой аналитике сервисов для клиентов:
Думайте и помните о конечном клиенте – именно для него все делается и он обеспечивает всю цепочку вашей работы.
При выводе на рынок технологического продукта – готовьтесь к переосмыслению и изменению всех ваших внутренних бизнес-процессов, начиная с общей бизнес-модели.

Продуктовых побед вам.
И удачи.