Продуктовый процесс в «Везёт»: как всё устроено

Недавно директор по продукту «Везёт» Анатолий Кульбацкий рассказал о том, какие вопросы он задаёт на собеседовании продакт-менеджеру. Команда собрана, поэтому настало время рассказать, как мы работаем. Меня зовут Александр Токмаков, и в этой статье я подробно опишу, как устроен продуктовый процесс в нашей компании с позиции продакт-менеджера.

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

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

В нашей компании пять продакт-менеджеров: каждый отвечает за своё направление и имеет свою команду. Я работаю с командой пользовательского приложения, наш продукт — это приложение «Везёт».

Команда, которой я управляю:

• Два продуктовых дизайнера.
• Один продуктовый аналитик.
  
• Три бэкенд-инженера.
  
• Три iOS-инженера.
  
• Три Android-инженера.
  
• Три QA-инженера.
  
• Scrum master — один на несколько команд.
  

Наша основная задача — это улучшать опыт пользователя с помощью продукта: до, после и во время поездки.

В этой статье будет много ссылок, поэтому не лишним будет показать основные сервисы, которые мы используем работе:

1. Google Docs.
2. Jira.
   
3. Confluence.
   
4. Firebase.
   
5. Fabric (сейчас переехал в Firebase).
   
6. Amplitude.
   
7. Miro.
   
8. Figma.
   
9. Telegram.
   
10. Mattermost.
    
11. Braze.
    
12. SurveyMonkey.
    
13. TestRail.

Весь наш продуктовый процесс состоит из четырех основных блоков:

1. Поиск проблем/идей/гипотез (Discovery).
2. Проектирование решений (Define).
   
3. Разработка решения (Develop).
   
4. Запуск решения (Delivery).

За основу был взят фреймворк Double Diamond или 4D от British Design Council.

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

1. Поиск проблем пользователей. Идеи и гипотезы для улучшения продукта

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

Внешние и внутренние исследования. Продакт-менеджер анализирует информацию из следующих открытых источников:

• Открытые или внутренние исследования, которые проводит отдел маркетинга.
• Анализ отрасли, вот, к примеру, исследование рынка грузовых перевозок.
• Документы из других отраслей, например, обзор трендов из банковской и fintech-индустрии.
  

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

Конкурентный анализ. Полноценно пользуемся сервисами конкурентов и проходим полный путь заказа такси в различных ситуациях: в зависимости от времени суток, дня недели или локации. В прошлом году мы провели несколько смен по 10 часов в качестве водителей в разных такси-сервисах. Это был уникальный опыт, который позволил почувствовать все «боли» пользователей и водителей на себе, а также глубже погрузиться в контекст бизнеса такси.

В результате продакт получает таблицу с описанием функциональности конкурентов. Шаблон такой таблички можно посмотреть вот здесь.

CustDev. Состоит из четырёх этапов:

1. Скрипт. Вопросы для интервью строятся от обратного, исходя из наших гипотез и идей.

   Если хотим проверить гипотезу добавления информации, например, пробки в приложении, то в скрипте задаем открытый вопрос: «Какую информацию вам важно получить для принятия решения использовать тот или иной вид транспорта?» Важно собрать контекстную и эмоциональную информацию об опыте пользователя, идеально, если получиться отранжировать ее, например, по 10-балльной шкале.

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

   Пример вопросов для интервью от наших коллег из JTBD.academy можно посмотреть тут.

2. Респонденты. Для нас работают несколько подходов. «Везет» — это массовый продукт, и аудитория у него очень широкая. Для определения первичных потребностей и проблем иногда достаточно написать пост в социальных сетях и телеграм-каналах, чтобы таким образом собрать десяток респондентов с релевантным опытом.

   Для получения регионального опыта необходимо договариваться с пользователями из других городов.

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

3. Интервью. В среднем интервью занимает от 20 минут до 1 часа. Здесь важно сонастроиться и установить эмпатическую связь с респондентом, не перебивать, но контролировать ход встречи.

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

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

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

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

   P.S. Если вы не уверены, что способны проводить глубинные интервью, то лучше наймите профессионального исследователя/социолога или улучшите свои скиллы с помощью курсов по проведению интервью, один из них я проходил в прошлом году. На курсе разбирается очень много нюансов и ошибок, например, отличие проблем пользователя от его потребностей.
   

Опросы. Работают в связке с CustDev и являются количественным инструментом для подтверждения/опровержения инсайтов и сигналов из интервью. Нашим приложением ежедневно пользуется более 100 тысяч пользователей, поэтому за несколько дней можно собрать несколько тысяч ответов, распределение которых также является подтверждением или опровержением гипотез. Для запуска опроса мы используем два инструмента:

1. Пуши/иннапы через Braze, если нужна тонкая настройка по параметрам пользователя, например, опросить только пользователей, у которых больше шести совершенных поездок за последний месяц.
2. Внутренняя кнопка, которая переводит на SurveyMonkey, откуда мы после опроса получаем отчет (цифры вымышленные).

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

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

2. Верификация, приоритизация и оформление идей в проекты

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

Reach и Impact мы определяем по ретроспективным данным или по условной шкале (от 1 до 10), если создаем что-то абсолютно новое в приложении.

Effort считаем в спринтах и оцениваем вместе с инженерами, этот процесс оценки напоминает Planning poker.

Верификация идей происходит в параметре Confidence, где мы его определяем по шкале доверия от Intercom + добавляем несколько своих параметров, которые связаны с нашей текущей индустрией, стратегией, бизнес-моделью и спецификой бизнеса.

В итоге получаем таблицу (пример), где сортируем гипотезы по главному коэффициенту и начинаем сфокусировано работать с 3-5 гипотезами.

Создаем под каждый проект отдельный эпик в продуктовом бэклоге в Jira. Расписываем Product Vision Scope, а затем решаем в каком виде будем все это делать: MVP или Версия 1.0, Версия 2.0 и так далее.

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

На этапе проектирования менеджер описывает User Story или JTBD Story того, какие действия/результаты ожидаются от пользователя, системы и других ролей в данном проекте.

Дизайн-команда готовит дизайн-макеты, прототипы, CJM и транзишны состояний. Проводят UX-тесты и коридорные исследования, чтобы провалидировать те или иные решения. Иногда это также является источником для новых продуктовых гипотез и идей, которые снова попадают на этап discovery.

Аналитик готовит описания событий и пользовательских данных, которые мы хотим залогировать, а также показатели для проведения А/B теста или когортного анализа.

В конце мы собираем всю информацию в эпик в Jira для этапа Delivery и презентуем проект всей команде, обсуждаем возможные риски и маневры.

После этого мы разбиваем проект на части и передаем всю информацию скрам-мастеру и инженерам.

Все, дальше начинается процесс Delivery, где продакт менеджер участвует как куратор и источник информации о целях, логике и приоритетах проекта.

Мы работаем по Scrum, который дает нам возможность фокусироваться и создавать каждые 2-4 недели версию приложения с новой функциональностью.

Процесс состоит из следующих этапов:

1. Грумминг.
   
2. Планирование.
   
3. Разработка.
   
4. Ревью.
   
5. Тестирование функциональности, визуальных элементов и аналитических событий.
   
6. Тестирование Release Candidate.
   
7. Создание финальных сборок версий приложений (разработчики собирают конечные версии приложения; менеджер загружает их на бета-тестирование в AppStore и Google Play; финально тестируем версии вместе с командой и стейкхолдерами).

Состоит из трёх этапов:

1. Выкладка происходит после успешного бета-тестирования. Пишем текст «Что нового» в AppStore и GooglePlay, если необходимо, добавляем новые скрины и выкладываем версию уже для пользователей.

   Отправляем релиз ноут всем стейкхолдерам и заинтересованным лицам в компании.

   И финально контролируем динамику раскатки (adoption), кол-во критичных багов в Crashlytics и воронки в Amplitude, на случай просадок между версиями.

2. А/B тест или когортный анализ.

   Рандомизированную выборку для теста мы формируем с помощью сервисов Remote Config и A/B Testing в Firebase и создаем дашборды экспериментов в Amplitude. Ждем, когда наберется достаточное количество данных для эксперимента. Помним про «проблему подглядывания».
   

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

   Аналитик отсылает письмо всем заинтересованным.

После этого продакт-менеджер может принять три управленческих решения:

1. Функциональность улучшает метрики → оставляем функциональность и раскатываем на 100%.
2. Функциональность ухудшает метрики → убираем функциональность.
   
3. Функциональность не ухудшает метрики → либо проводим новый эксперимент с другим решением, либо убираем функциональность.
   

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

Я работаю в продуктовой разработке уже 6 лет и считаю, что сейчас мы приблизились к практически идеальному процессу для B2C продукта, и вот почему:

1. Системность. Каждый этап как маленькая «коробочка», которая имеет понятную информацию на входе, описание действий внутри нее и четкий результат, который ожидается на выходе. Будь то таблица, макет, дашборд, тикет, сборка с новой функциональностью или тест-кейс. Всегда известно, кто лидирует этап, в каком он статусе сейчас и когда будет закончен. Это критически важно для нас, т.к. мы распределенная команда и работаем из офисов в Москве, Краснодаре и Уфе.
2. Мотивация. Прозрачный процесс, где каждый участник, будь то дизайнер, аналитик или инженер, понимает цели, планы и ожидания от его деятельности, а также их влияние на бизнес-результаты. Все это формирует внутреннюю мотивацию, которая так важна для высокоинтеллектуальных профессий.
   
3. Результаты. За 2019 год по этому процессу прошло более 50 инициатив. Большинство из них так и осталось на этапах в Discovery. Но 19 продуктовых проектов прошли весь путь, а 12 из них показали улучшение показателей нашего продукта. А это значит, что мы добились своей цели.
   

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

Stay tuned!