Подход к запуску продукта на основе данных

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

Имеют ли данные значение?

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

  • Как увеличить доход в рамках приемлемого бюджета (финансовые ограничения) и уровня обслуживания (ограничения по качеству)?
  • Как расставить приоритеты между тем, над чем работает моя команда разработчиков, чтобы добиться успеха в #1 (ограничения по времени)?

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

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

Как ориентироваться на данные во время запуска?

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

Процесс отслеживания и мониторинга данных можно разделить на несколько этапов:

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

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

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

Определение контрольных показателей или целей запуска, которые можно отследить по фактическим данным. Например, для запуска продукта, ориентированного на электронную коммерцию, целью может быть привлечение X-количества платных пользователей в течение четырех недель после запуска с менее чем Y% возвратов/отказов.

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

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

“Опережающие метрики” - это метрики, которые можно отслеживать без каких-либо задержек. Например, отслеживание того, где пользователи отсеиваются или покидают сайт в потоке регистрации, является опережающим показателем, и по нему можно немедленно предпринять меры.

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

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

Остерегайтесь метрик тщеславия!

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

Пример 1

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

Пример 2

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

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

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

Как держать руку на пульсе после запуска?

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

Подход к запуску продукта на основе данных

Еще несколько рекомендаций

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

Заключение

При прочих равных условиях data-driven подход может определить успех при запуске продукта. Он помогает команде разработчиков принимать разумные решения и фокусироваться на актуальных проблемах. Он помогает держать всех участников в курсе событий и поддерживать их боевой дух.

22
Начать дискуссию