Сокращение ТТМ запуска продуктов в компании: кейс Авито

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

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

В этой статье я, Аня Подображных, ведущий менеджер продукта в Авито и автор тг-канала «Будни продакта», расскажу о том, как в Авито работают над сокращением ТТМ.  

Из чего складывается ТТМ запуска продукта

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

New opportunities discovery

• Поиск и обоснование ценности.
• Исследования рынка, формулирование ценности.
• Обратная связь от отдела продаж, поддержки.
• Консультации юристов, финансов.

Product Discovery

• Поиск и обоснование ценности и реализуемости продуктового решения.
• Обратная связь от отдела продаж, поддержки.
• Расчет бюджета под хэдкаунт.
• Консультации юристов, финансов.
• Формирование USP продукта (Unique Selling Proposition – уникальное торговое предложение).
• Планирование go to market (GTM) и расчет бюджета на запуск.

Product Delivery

• Разработка продукта и проверка его solution fit.
• Подготовка онбординга клиентов, обучение продаж и поддержки (+ найм, если необходимо).
• Привлечение первых пользователей и подготовка GTM.
• Сбор обратной связи от продаж, поддержки.

Scaling & Product Operations

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

Как мы в Авито эти проблемы решаем

• Определили зоны ответственности и согласовали со всеми функциями (продажи, поддержка, маркетинг), кто за какой блок отвечает в процессе запуска продуктов. Для вертикальных и горизонтальных команд выделили ответственных в функциях, так что каждый продакт знает, к кому обратиться. 
• Обозначили важные майлстоуны в процессе GTM.
• Прописали чек-листы для каждой функции.

Этап «New opportunities discovery»

На этом этапе продакт плотно работает с РММ (product marketing manager – продакт-маркетолог), который является его входным лицом в маркетинг. Первая задача продакта на этом этапе – провести исследование рынка (понять, как аналогичные проблемы решаются на рынке, собрать обратную связь о продуктах конкурентов). РММ рассказывает о существующих маркетинговых исследованиях потребностей пользователей, подключается к формулированию ценности, проверяет, как новый продукт впишется или изменит существующий CJM (customer journey map), прикидывает потенциальную стоимость привлечения пользователей.  

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

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

Этап «Product Discovery»

После защиты идеи продукта в компании продакт проводит установочную встречу с дискавери-командой, которая будет заниматься этим продуктом. В дискавери-команду, как правило, входит РММ, аналитик, исследователь, дизайнер, представитель разработки (тимлид). После установочной встречи формируется роадмэп на этап Product Discovery. 

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

РММ отвечает за формирование USP продукта, планирование GTM и расчет бюджета на запуск. 

На этом этапе есть и другие проблемы в дискавери-команде, которые замедляют ТТМ. Разберем несколько наиболее весомых на примере Авито.

Проблемы в дискавери-команде

Повторные проведения исследований

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

Узкое горлышко в одной из функций

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

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

Этап «Product Delivery»

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

Дальше основная задача продакта – разработка самого продукта и проверка его solution fit (подтверждение результатов этапа продакт-дискавери и проверка соответствия решения потребностям пользователей). 

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

Далее совместно с РММ и другими участниками проектной команды он формирует GTM-план для масштабирования: обучение пользователей, увеличение хэдкаунта при необходимости, формирование процесса сбора обратной связи от пользователей, согласование юридических вопросов, которые не стали делать на этапе MVP. 

На этом этапе сильно замедлять ТТМ могут проблемы в процессе разработки. Разберем несколько весомых. 

Проблемы процесса разработки

Непонятные задачи

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

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

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

Нет системы оценки

Система оценки важна: она позволяет более точно планировать проект и принимать решение о нужности функции в MLP в зависимости от стоимости ее разработки. Да и в целом она вносит больше определенности в разработку продукта.  

Но не у всех команд есть система оценки. Проблема может быть вызвана двумя факторами: 

1. Системы оценки никогда не было. В этом случае заводить ее сложно и больно: команда не понимает, как оценивать задачу. Мы в команде используем сторипоинты и придерживаемся правила, что задача должна «стоить» одинаково вне зависимости от того, кто именно ее делает. Задача как гиря – одному человеку будет легко ее поднять, другому сложно, но вес самой гири не меняется от того, кто именно ее поднимает. Разные люди могут брать разное количество сторипоинтов в спринт, чтобы не подгонять оценку под себя, а наоборот – считать, сколько гирь ты сможешь поднять за спринт. 

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

Очень много встреч

Работа становится неэффективной, если календарь полностью забивается встречами. Я не буду писать о важности или НЕважности какой-то конкретной из них, но поделюсь несколькими советами, которые помогают моей команде сделать встречи более эффективными.

• Очевидно, но об этом забывают: ставьте по возможности встречи рядышком. Если поставить 4 встречи с перерывами в полчаса-час, день будет «дырявым»: во время встречи не поработаешь, в коротких перерывах сфокусироваться на какой-то задаче тоже сложно. 
• Еще более очевидно, но не менее распространенно: если можно обойтись без встречи, обойдитесь без встречи. Часто встречи ставят из-за того, что лень приложить усилие и описать проблему текстом. Но прочтение продуманного текста и ответ на него часто занимают гораздо меньше времени в сумме у всех участников, чем попытка синхронизироваться во время встречи. 
• Оптимизируйте участников встречи: если есть люди, без которых можно обойтись – обойдитесь без них и напишите фоллоу-ап. 
• Ставьте конкретную цель встречи и готовьтесь к ней. Если заранее прочитать и сделать все, что можно сделать самостоятельно, то на встрече останется только обсудить непонятные моменты – на это, как правило, уходит меньше времени. 

Читайте также

Как сделать дейлики эффективными: интервью с Настей Ткаченко из Craftum

Как продуктологу мотивировать разработчика: интервью с Антоном Ширшаковым из Райффайзен Банка

Этап «Scaling & Product Operations»

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

Результаты и проблемы, с которыми мы столкнулись в Авито при заведении процесса 

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

Единственный честный способ оценки ТТМ – замерить время перехода с одного этапа на другой. Мы видим сокращение времени product discovery и product delivery в 2 раза. При этом последний этап масштабирования по времени не изменился.