Продуктовый процесс в «Везёт»: как всё устроено
Недавно директор по продукту «Везёт» Анатолий Кульбацкий рассказал о том, какие вопросы он задаёт на собеседовании продакт-менеджеру. Команда собрана, поэтому настало время рассказать, как мы работаем. Меня зовут Александр Токмаков, и в этой статье я подробно опишу, как устроен продуктовый процесс в нашей компании с позиции продакт-менеджера.
Основная цель — создать такой контролируемый, масштабируемый и при этом измеримый процесс, в результате которого есть большая вероятность достигнуть роста показателей продукта, которые в свою очередь будут вести к росту показателей бизнеса.
А так как нашим приложением пользуются тысячи пользователей, которые делают несколько миллионов поездок в месяц, то любое, даже маленькое, изменение их опыта может принести немаленькие последствия для показателей бизнеса. Мы хотим, чтобы эти показатели менялись только в лучшую сторону.
Про структуру и цели
В нашей компании пять продакт-менеджеров: каждый отвечает за своё направление и имеет свою команду. Я работаю с командой пользовательского приложения, наш продукт — это приложение «Везёт».
Команда, которой я управляю:
- Два продуктовых дизайнера.
- Один продуктовый аналитик.
- Три бэкенд-инженера.
- Три iOS-инженера.
- Три Android-инженера.
- Три QA-инженера.
- Scrum master — один на несколько команд.
Наша основная задача — это улучшать опыт пользователя с помощью продукта: до, после и во время поездки.
В этой статье будет много ссылок, поэтому не лишним будет показать основные сервисы, которые мы используем работе:
- Google Docs.
- Jira.
- Confluence.
- Firebase.
- Fabric (сейчас переехал в Firebase).
- Amplitude.
- Miro.
- Figma.
- Telegram.
- Mattermost.
- Braze.
- SurveyMonkey.
- TestRail.
Весь наш продуктовый процесс состоит из четырех основных блоков:
- Поиск проблем/идей/гипотез (Discovery).
- Проектирование решений (Define).
- Разработка решения (Develop).
- Запуск решения (Delivery).
За основу был взят фреймворк Double Diamond или 4D от British Design Council.
Discovery
Этот блок — основная часть работы продакт-менеджера, поэтому уделим ей наибольшее внимание. Условно можно разделить его на две части:
1. Поиск проблем пользователей. Идеи и гипотезы для улучшения продукта
На этом этапе можно применять разные методики по агрегации идей для улучшения продукта, ниже я опишу те, которые мы используем на постоянной основе.
Внешние и внутренние исследования. Продакт-менеджер анализирует информацию из следующих открытых источников:
- Открытые или внутренние исследования, которые проводит отдел маркетинга.
- Анализ отрасли, вот, к примеру, исследование рынка грузовых перевозок.
- Документы из других отраслей, например, обзор трендов из банковской и fintech-индустрии.
Мозговой штурм. Организуется внутри продуктовой команды. В состав группы входят дизайнеры, аналитики и менеджеры из других команд. Это классический мозговой штурм со всеми его атрибутами, где мы обязательно выбираем модератора, чтобы эффективно использовать время и фиксировать идеи на большой доске с помощью стикеров, которые в конечном итоге переносим в Miro.
Конкурентный анализ. Полноценно пользуемся сервисами конкурентов и проходим полный путь заказа такси в различных ситуациях: в зависимости от времени суток, дня недели или локации. В прошлом году мы провели несколько смен по 10 часов в качестве водителей в разных такси-сервисах. Это был уникальный опыт, который позволил почувствовать все «боли» пользователей и водителей на себе, а также глубже погрузиться в контекст бизнеса такси.
В результате продакт получает таблицу с описанием функциональности конкурентов. Шаблон такой таблички можно посмотреть вот здесь.
CustDev. Состоит из четырёх этапов:
Скрипт. Вопросы для интервью строятся от обратного, исходя из наших гипотез и идей.
Если хотим проверить гипотезу добавления информации, например, пробки в приложении, то в скрипте задаем открытый вопрос: «Какую информацию вам важно получить для принятия решения использовать тот или иной вид транспорта?» Важно собрать контекстную и эмоциональную информацию об опыте пользователя, идеально, если получиться отранжировать ее, например, по 10-балльной шкале.
Важно не спрашивать о будущем, говорить о прошлом и настоящем опыте. Идеально, когда пользователь что-то делает с приложением в моменте и говорит о своих мыслях, чувствах и ощущениях.
Пример вопросов для интервью от наших коллег из JTBD.academy можно посмотреть тут.
Респонденты. Для нас работают несколько подходов. «Везет» — это массовый продукт, и аудитория у него очень широкая. Для определения первичных потребностей и проблем иногда достаточно написать пост в социальных сетях и телеграм-каналах, чтобы таким образом собрать десяток респондентов с релевантным опытом.
Для получения регионального опыта необходимо договариваться с пользователями из других городов.
В нашем случае нам сильно помогает маркетинговый отдел, т.к. в каждом городе есть свой офис. Чаще всего это проходит так: я звоню пользователям и представляюсь специалистом по работе с клиентами, договариваюсь на продолжительный разговор лично, по скайп или телефону. Обычно это подразумевает вознаграждение, в нашем случае это кофе + десерт, обед в кафе или промокод, но в других компаниях есть примеры денежных вознаграждений, одежды или другого мерча.
Интервью. В среднем интервью занимает от 20 минут до 1 часа. Здесь важно сонастроиться и установить эмпатическую связь с респондентом, не перебивать, но контролировать ход встречи.
Состав участников может варьироваться от одного менеджера до нескольких человек. Наиболее эффективный и комфортный вариант для респондента это встреча втроем: менеджер, собеседник и участник команды.
От команды может быть дизайнер, аналитик или инженер, лучше предупредить его о порядке проведения и показать скрипт заранее.
Заметки лучше делать сразу на встрече, так сохранится больше деталей и нюансов. Аудио формат записей у меня не прижился, т.к. расшифровывать беседу оказалось очень затратно по времени.
Интерпретация. Расшифровка может занимать еще больше времени, чем само интервью, поэтому ранжирование инсайтов и ответов очень помогает в приоритезации гипотез. Пример документа из интервью.
P.S. Если вы не уверены, что способны проводить глубинные интервью, то лучше наймите профессионального исследователя/социолога или улучшите свои скиллы с помощью курсов по проведению интервью, один из них я проходил в прошлом году. На курсе разбирается очень много нюансов и ошибок, например, отличие проблем пользователя от его потребностей.
Опросы. Работают в связке с CustDev и являются количественным инструментом для подтверждения/опровержения инсайтов и сигналов из интервью. Нашим приложением ежедневно пользуется более 100 тысяч пользователей, поэтому за несколько дней можно собрать несколько тысяч ответов, распределение которых также является подтверждением или опровержением гипотез. Для запуска опроса мы используем два инструмента:
Аналитика. Продуктовый аналитик и менеджер анализирует все данные из системы, у нас это Amplitude. Мы сегментируем аудитории, считаем конверсии и ретеншн в зависимости от событий и путей пользователя. Еженедельно мы обсуждаем аномалии в данных и пытаемся либо валидировать текущие гипотезы, либо формулировать новые. При этом мы осознанно инвестируем в поддержку текущих и добавление новых событий в приложения.
Стейкхолдеры. Продакт-менеджер регулярно общается с другими отделами бизнеса. Для нас основные: маркетинг, бизнес девелопмент, саппорт, операционный отдел и офисы городов. Любой сотрудник в компании может предложить и написать инициативу на почту или в мессенджер, который указан в релиз ноуте.
2. Верификация, приоритизация и оформление идей в проекты
На этом этапе гипотезы и идеи в таблице, которую мы собрали выше, приоритезируем между собой. Для этого мы оцениваем их в RICE. Подробнее о фреймворке можно почитать вот здесь.
Reach и Impact мы определяем по ретроспективным данным или по условной шкале (от 1 до 10), если создаем что-то абсолютно новое в приложении.
Effort считаем в спринтах и оцениваем вместе с инженерами, этот процесс оценки напоминает Planning poker.
Верификация идей происходит в параметре Confidence, где мы его определяем по шкале доверия от Intercom + добавляем несколько своих параметров, которые связаны с нашей текущей индустрией, стратегией, бизнес-моделью и спецификой бизнеса.
В итоге получаем таблицу (пример), где сортируем гипотезы по главному коэффициенту и начинаем сфокусировано работать с 3-5 гипотезами.
Создаем под каждый проект отдельный эпик в продуктовом бэклоге в Jira. Расписываем Product Vision Scope, а затем решаем в каком виде будем все это делать: MVP или Версия 1.0, Версия 2.0 и так далее.
После этого вносим проект в открытый бэклог, по сути, это таблица Ганта для бизнеса и стейкхолдеров. Теперь у нас есть полностью описанный проект для команды и бизнеса, со всеми метриками и бизнес ожиданиями.
Define
На этапе проектирования менеджер описывает User Story или JTBD Story того, какие действия/результаты ожидаются от пользователя, системы и других ролей в данном проекте.
Дизайн-команда готовит дизайн-макеты, прототипы, CJM и транзишны состояний. Проводят UX-тесты и коридорные исследования, чтобы провалидировать те или иные решения. Иногда это также является источником для новых продуктовых гипотез и идей, которые снова попадают на этап discovery.
Аналитик готовит описания событий и пользовательских данных, которые мы хотим залогировать, а также показатели для проведения А/B теста или когортного анализа.
В конце мы собираем всю информацию в эпик в Jira для этапа Delivery и презентуем проект всей команде, обсуждаем возможные риски и маневры.
После этого мы разбиваем проект на части и передаем всю информацию скрам-мастеру и инженерам.
Все, дальше начинается процесс Delivery, где продакт менеджер участвует как куратор и источник информации о целях, логике и приоритетах проекта.
Develop
Мы работаем по Scrum, который дает нам возможность фокусироваться и создавать каждые 2-4 недели версию приложения с новой функциональностью.
Процесс состоит из следующих этапов:
- Грумминг.
- Планирование.
- Разработка.
- Ревью.
- Тестирование функциональности, визуальных элементов и аналитических событий.
- Тестирование Release Candidate.
- Создание финальных сборок версий приложений (разработчики собирают конечные версии приложения; менеджер загружает их на бета-тестирование в AppStore и Google Play; финально тестируем версии вместе с командой и стейкхолдерами).
Delivery
Состоит из трёх этапов:
Выкладка происходит после успешного бета-тестирования. Пишем текст «Что нового» в AppStore и GooglePlay, если необходимо, добавляем новые скрины и выкладываем версию уже для пользователей.
Отправляем релиз ноут всем стейкхолдерам и заинтересованным лицам в компании.
И финально контролируем динамику раскатки (adoption), кол-во критичных багов в Crashlytics и воронки в Amplitude, на случай просадок между версиями.
А/B тест или когортный анализ.
Рандомизированную выборку для теста мы формируем с помощью сервисов Remote Config и A/B Testing в Firebase и создаем дашборды экспериментов в Amplitude. Ждем, когда наберется достаточное количество данных для эксперимента. Помним про «проблему подглядывания».Итоги. Подводим итоги на основе результатов эксперимента. Обязательно доносим итоги до всей команды, обычно это происходит на ретроспективе или грумминге.
Аналитик отсылает письмо всем заинтересованным.
После этого продакт-менеджер может принять три управленческих решения:
- Функциональность улучшает метрики → оставляем функциональность и раскатываем на 100%.
- Функциональность ухудшает метрики → убираем функциональность.
- Функциональность не ухудшает метрики → либо проводим новый эксперимент с другим решением, либо убираем функциональность.
Вот так, вкратце, выглядит продуктовый процесс в нашей компании, нам понадобилось около четырёх месяцев для выстраивания его в команде.
Я работаю в продуктовой разработке уже 6 лет и считаю, что сейчас мы приблизились к практически идеальному процессу для B2C продукта, и вот почему:
- Системность. Каждый этап как маленькая «коробочка», которая имеет понятную информацию на входе, описание действий внутри нее и четкий результат, который ожидается на выходе. Будь то таблица, макет, дашборд, тикет, сборка с новой функциональностью или тест-кейс. Всегда известно, кто лидирует этап, в каком он статусе сейчас и когда будет закончен. Это критически важно для нас, т.к. мы распределенная команда и работаем из офисов в Москве, Краснодаре и Уфе.
- Мотивация. Прозрачный процесс, где каждый участник, будь то дизайнер, аналитик или инженер, понимает цели, планы и ожидания от его деятельности, а также их влияние на бизнес-результаты. Все это формирует внутреннюю мотивацию, которая так важна для высокоинтеллектуальных профессий.
- Результаты. За 2019 год по этому процессу прошло более 50 инициатив. Большинство из них так и осталось на этапах в Discovery. Но 19 продуктовых проектов прошли весь путь, а 12 из них показали улучшение показателей нашего продукта. А это значит, что мы добились своей цели.
Надеюсь, что эта статья была для вас полезной, буду рад услышать ваши комментарии.
Stay tuned!
Всё, что написано в этой статье не сравнится с тем как "классно" работает сервис. авто можно ждать неизвестно сколько. с оплатой картой как всегда проблемы. ну это по крайней мере в Воронеже последние пару лет. Пользуюсь везёт очень редко, но каждый раз остается негатив, особенно это касается то кривой, то отсутствующей онлайн-оплатой. про то, что у нас в везёт катаются сплошные вёдра вместо автомобилей, даже говорить не хочется. вы бы там чтоль контроль какой-нибудь ввели за состоянием авто, которых к сервису подрубаете.
Евгений, добрый день! Написал вам в личку
Комментарий недоступен
Специалист достаточно грамотно описывает свою работу. Он не несет ответсвенности за решения владельцев и прочих вышестоящих товарищей за общее состояние сервиса на земле.
Автор несет ответственность за приложение и Кирилл об этом тоже написал: "старое приложение с доисторическим дизайном.".
PS не пользовался "везёт". В статье описываются эффективно выстроенные процессы. Захотелось установить и посмотреть на приложение. Статья - завуалированная реклама? :)
Автор написал о приоритизации доработок, которым он только следует, собрав фидбэк. Возможно, то что кажется Кириллу доисторическим никого не трогает.
Возможно. Кстати в статье очень много рассказано про процесс и очень мало про результат.
"Результаты. За 2019 год по этому процессу прошло более 50 инициатив. Большинство из них так и осталось на этапах в Discovery. Но 19 продуктовых проектов прошли весь путь, а 12 из них показали улучшение показателей нашего продукта. А это значит, что мы добились своей цели." - это совсем не означает, что цели добился сам бизнес. Интересно было бы посмотреть, что за показатели, итоговые p/l и пр.
Кирилл, мы точно говорим об одном и том же приложении?
Года два-три назад ехали загород в отель, заказал заранее минивенВ статье речь идет о приложении «Везёт», которое было создано в 2018 году.
Сожалею, про ваш опыт.
Про проблемы мы, конечно, знаем и работаем над их решением, но целью статьи было рассказать о процессах, которые есть сейчас.
По поводу водителя написал вам в личку.
Привет, Кирилл, меня зовут Эльвира. Расскажите подробнее о вашей поездке нам на [email protected]. С какого номера телефона вы заказывали автомобиль, почему ждали в течение часа, а не попробовали заказть другой минивен? Так же напишите, пожалуйста, в каком городе произошла эта история, обращались ли вы в нашу службу качества по поводу этой поездки? Очень ждем от вас письмо, чтобы все проверить.
Комментарий недоступен
Хорошая статься, отдельное спасибо за ссылки!
В моей локации 4мл населения, сервис такси появился 3 месяца назад. Хочу составить ему конкуренцию со своим самопалом. Приветствую продакта энтузиаста.
Неужели нет ни одного продакта, который хочет оценить мою локацию и самопал ?
Продакты энтузиасты могут свои проекты пилить, зачем им ваш самопал? И оставили бы хоть ссылку, что ли.
Зачем птицы сбиваются в стаи ? Что бы долететь до цели.
Ссылки пока сырые, поясню кому интересен сам кэйс 4мл без внятных конкурентов в Африке.
Это все, конечно, классно , но:
1) Не увидел вообще ни слова про метрики. Дашборды и стикеры это классно, но что отслеживаете и максимизируете?
2) JTBD и CJM работают хорошо на основе определения нужного JTBD и субсегментов в них же (соцдем, средняя длина поездки, откуда едет и так далее по списку). Опросы полезны при нерепрезантативном наборе транзакций (алгоритмы не поняли ху ис ху), а дальше уже чисто математическая задачка и весь креативный дух вместе со смузи летит как фанера над Москвой, хе-хе.
3) Скорее совет-рекомендация. Добавьте кнопку обратной связи если такой нет и дайте возможность записывать голосом. Алгоритмами выделить текст, семантический анализ и засунуть это все добро в QFD. И сразу полезные гипотезы появяться :)
P.S. Возможно, вы просто не все рассказали в материале, поэтому вопросы и возникли. :) P.P.S. Сервисом не пользовался - в моем бульбостане вас пока (вроде) нету.
Мiкiта,
1. Статья была про процесс. Метрики всегда конверсия и ретеншн пользователей новой функциональности к пользователям без этой функциональности на периоде: для нас это 1й, 2й, 3й, 7й, 14й, 30й день.
2. Уходим в частности и автоматизацию. В статье задача была показать каркас. Опросы мы не используем как репрезентативный инструмент, для нас это больше индикатор и проверка частотности проблем и гипотез.
3. Спасибо за фидбек, возьмем на заметку ;)
Cпасибо за полновесный ответ :)
Хорошая статья, полезные ссылки 👍. По составу команды вопрос: руководителя проектов и продуктового маркетолога нет?
Проектный офис на все команды - следующий этап эволюции, был запланирован, но пока отложили. Маркетолог есть в команде маркетинга, привлекается на этапах запусков.
Иметь в продуктовой команде на текущих задачах и процессе нецелесообразно, т.к. загрузка будет неполная.
Все что здесь написано это бредовая ерунда, которая не имеет ничего общего с реальной жизнью! Написано о какой-то там философии, ценностях, улучшениях для d2c, b2b. Ахахаха!!! Почитайте реальные отзывы на сервисах по скачиванию приложений от этого такси, как для клиента, так и для водителя - и услышите правду.
Заказы висят по пол часа, в иной раз водителям приходится после взятия заказа сразу звонить клиенту и спрашивать не уехал ли он на другом такси. Если клиент грубит, создает аварийную ситуацию своим поведение, периодически делает отбои, не платит и т.д. - к нему не будут применены никакие санкции, у этого такси - клиент всегда святой. Отношение к водителям как к г@вну по многим факторам, в офисах общаться не умеют, звонишь как-будто на зону... У водителей отняли заработки с такими нищенскими тарифами, со своей чудо маркетинговой политикой по демпингу цен.
Спасибо, что поделился.
В нашем продукте процесс выглядит очень похожим, только ещё имеется описание, как мы работаем, если появляется какой-нибудь «черный лебедь», например, болезнь COVID-19, в связи с которой врубили карантин, и рынку в короткий срок понадобились фичи, которых у нас в продукте не было. Стандартный процесс здесь не спасает, т.к. следует действовать очень быстро.
Вопросы:
1. Как вы оптимизируете time-to-market?
2. Катите ли вы что-нибудь вне релизного процесса? В статье, к сожалению, про это ни слова.
3. Есть ли у вас «протокол быстрого реагирования»? Процесс, по которому фича выкатывается в максимально короткие сроки в обход стандартного.
1. Уточни, плиз. Не совсем понял time-to-market в каком этапе? Потому что метрика взята из девелоп.
2. Есть система приоритетов. Хотфиксы случаются, но не часто (1 раз в полгода). Обычно это или критичная баги или внештатные обновления инфраструктуры (сертификаты, ключи и т.д.). Задача оформляется собирается полный скоп информации и делается релевантным инженером. Тестирование либо быстрая регрессия(очень редко), либо smoke тест и раскатка в прод. Если все ок, то включаем форс апдейт, на тех у кого данная версия.
3. Внутри спринта катим что-то очень редко. Потому что косты на переключения, подготовку помноженную на сырое описание и информационный вакуум будут стоить в итоге дороже, чем докатить нормальный спринт и взять фичу в следующий.
Отличная статья, видно хорошо проработанный продуктовый процесс. Письмо аналитика про A/B тест сделано круто, хоть это и шаблон и наверное глаз замыливается со временем читать его каждый раз детально. Мне интересно, как аналитик выбирает контрольную группу? Распределение новых и старых, как он определяет для теста? Количество людей в контрольной группе как он считает? Ведь нужно знать ожидаемую конверсию. У вас системного все сделано на всех этапах, а тут не очевидно. Вдруг, будет чему в этом смысле поучиться.
Спасибо за оценку.
По вопросу. Выборка. Если А/Б то берем только новых
- Распределение делегируем Firebase (там есть данный раздел). 50/50 обычно, если делаем А/А/Б, то по 33%
- Размер определяем на основании прогноза по приросту метрики. Обычно угадываем. Если все идет криво и нужно больше, то можем "пересобрать" эксперимент в Амплитуде. Обычно это влияет только на сроки сбора данных. Но благо у нас больше 1 млн МАУ и сотни тыс новых ежемесячно, поэтому проблемы подождать пару дней нет
Интересная статья. Вопрос к автору 1. Когда появится продукт? 2. Насколько актуально создание продукта, если, по данным из открытых источников, Яндекс.Такси приобретёт активы Везёт?
Александр,
1. Не понял Вашего вопроса. Везет запущен в 2018 году и работает. Если есть комментарии по работе приложения, то с удовольствием отвечу.
2. Сделка с Яндекс Такси пока только анонсирована. Наша продуктовая команда работает в штатном режиме.
Поясню. 1. Пользуюсь «красным» ( Новым? ) приложением Везет и «желтым» (старым?) приложением Рутакси. Вижу отличия в дизайне и второстепенных фичах, но какого- то принципиального технологического прорыва ( прогресса) , существенной разницы не наблюдаю. Поэтому и спросил - где продукт? Раз появилась такая амбициозная жизнеутверждающая статья. 2. У Яндекс.Такси хорошая продуктовая команда и хорошее приложение. А зачем в случае слияния два клиентских приложения единовременно?
Комментарий удален модератором
Комментарий удален модератором
Это все про UI/UX - самый простой, самый малозначимый и самый последний этап в продуктовой разработке. Не тем CPO в Везёт занимается. Что умеет, то и делает, он же маркетолог.