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

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

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

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

Что такое TTM

TTM (time to market) – период с момента возникновения идеи до выпуска продукта на реальных пользователей. Чем ниже ТТМ, тем раньше компания начинает зарабатывать. Либо мы сразу убьем нежизнеспособную идею и переключимся на следующую, либо выкатим хорошее решение на рынок и начнем зарабатывать с него деньги.

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

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

New opportunities discovery

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

Product Discovery

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

Product Delivery

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

Scaling & Product Operations

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

Проблемы при запуске продуктов

С какими проблемами мы столкнулись в Авито:

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

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

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

Этап «New opportunities discovery»

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

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

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

Чек-лист на этап подготовки идеи: 

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

Этап «Product Discovery»

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

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

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

Чек-лист продакта на этапе Product Discovery:

  • Сформировать дискавери-команду и провести установочную встречу.
  • Подготовить роадмэп.
  • Совместно с РММ сформировать USP продукта
  • Согласовать продуктовое решение с юристами, финансами, отделом информационной безопасности.
  • Обсудить продуктовое решение с продажами (если затрагивает сегмент профессиональных продавцов) и поддержкой, получить от них бюджет на хэдкаунт при необходимости.
  • Уточнить потенциал продукта, сформировать traction-модель и согласовать ее с аналитиками, финансами, ответственными категорийными менеджерами и продажами (если продукт не про деньги, только с аналитиками).
  • Получить от РММ GTM-план для запуска MLP (minimum lovable product).

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

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

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

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

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

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

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

Этап «Product Delivery»

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

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

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

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

Чек-лист для продакта: 

  • Подготовить MLP.
  • Совместно с РММ привлечь первых пользователей.
  • Проанализировать метрики после запуска MLP.
  • Собрать обратную связь от поддержки и менеджеров по продажам.
  • Составить план доработок и презентовать его проектной команде.
  • Совместно с РММ и другими участниками проектной команды составить GTM-план для масштабирования (привлечение и обучение пользователей, увеличение хэдкаунта при необходимости) и презентовать его стейкхолдерам, юристам.
  • Подготовить процесс сбора обратной связи после масштабирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

Митинги

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

Этап «Scaling & Product Operations»

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

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

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

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

источник

Related Posts
AllEscortAllEscort