Продуктовые фичи могут казаться нужными, метрики отличными, но в итоге — оставаться нерабочими. Из-за чего так происходит и почему это нормально, как не отклоняться от курса, проверяя гипотезу или внедряя новое изменение, рассказывает команда OneTwoTrip.
Мария Семикатова, Growth Product Owner в OneTwoTrip, поделилась со студентами программы «Продакт-менеджер» реальным кейсом из работы и рассказала, что делать, если фича оказалась нежизнеспособной. Даже если вы генерируете большое количество гипотез, всегда нужно помнить, для чего вы все это делаете. North Star Metric работает как «продуктовый метроном», который позволяет не отклоняться от курса. Ориентироваться стоит на такой вопрос: «На что мы влияем, проверяя гипотезу или внедряя новое изменение?»
Моя ключевая метрика как продакт-менеджера конкретного этапа воронки — это установки мобильного приложения. И что бы я ни делала, какой бы ни придумывала «продукт внутри продукта» или новую механику, я всегда задаю себе вопрос:
«А какая у меня конечная цель?»
И если ответ «Получаю установки мобильного приложения», то стоит это обсудить, исследовать и понять, насколько это ценно для пользователя и бизнеса.
Если начинаются сомнения или переплетение метрик, то процесс так или иначе остановится на чем-то, и не факт, что это будет моя метрика. Поэтому North Star Metric — это опора для продакта. Расскажу на примере реального кейса OneTwoTrip, как выстраивать гипотезы и рассчитывать потенциал фичи, следуя за метрикой Полярной звезды.
Кейс: совместный доступ к избранным отелям
Сейчас в нашем сервисе у пользователей есть возможность добавлять отели в «Избранное», чтобы в дальнейшем забронировать лучший вариант из понравившихся. Но если пользователь планирует путешествие с друзьями или близкими, то для совместного выбора ему придется поделиться каждым отелем отдельно в стороннем мессенджере.
Вводные о продукте
North Star Metric
Установки мобильного приложения, полученные через механику совместного доступа к избранным отелям.
Текущий продукт
Пользователь может добавить любой отель в «Избранное», создав подборку лучших для себя вариантов в конкретном городе.
Что знаем про отели
Представим, что мы пришли к аналитикам, чтобы собрать ретроспективные данные об отелях. Выяснилось, что около 40% бронирований отелей за 2023–2024 годы приходится на двух и более человек, при этом суммарно за эти два года 242 тысячи уникальных пользователей добавили отели в «Избранное».
Гипотеза
Если люди смогут делиться доступом к избранным отелям со своими попутчиками, то это привлечет в сервис новых пользователей и даст рост установок мобильного приложения.
Расчет потенциала
Прежде чем активно готовить фичу к разработке, нужно понять, какие результаты мы можем получить от ее реализации. Важно, чтобы вложенные ресурсы были оправданны с точки зрения бизнес-результата.
При расчете потенциала можно, например, опираться на результаты схожих механик, если такие уже есть в продукте.
В нашем случае в продукте есть совместный доступ к заказу. Логика совместного доступа к избранным отелям его полностью повторяет, поэтому можно взять результаты имеющейся фичи для расчета потенциала новой функции. Более того, совместный доступ к заказу есть в продукте «Отелей», что еще больше подходит для расчета.
Итак, мы знаем, что каждый пятый из всех, с кем делились заказом, присоединяется к нему и приносит нам установки. Эти метрики оправдывают потенциальные вложения в разработку. Такое мы в работу, конечно же, берем!
Мы прошли все этапы, обсудили с аналитиками и дизайнерами, отрисовали несколько итераций и…просчитались!
Где мы просчитались?
Ожидания и реальность не совпали, потому что изначально для анализа использовались смешанные данные.
Для расчета потенциала мы взяли общее количество уникальных пользователей, которые взаимодействовали с «Избранным» за два года, а все остальные показатели были годовые. При расчете это дало нам бóльший потенциал. Правильнее было бы взять данные только за 2024 год и опираться на них.
Так мы сами себя загнали в иллюзию, что придуманная нами реализация фичи оправдана с точки зрения результата.
Ключевые тезисы при анализе фичи перед запуском
Осознанная аналитика
Не пытаемся притянуть за уши цифры, которые есть. Они могут быть совершенно не применимы к текущему набору функций даже в одном и том же продукте. Классно, если бизнес готов инвестировать и может себе позволить много раз ошибаться, но логичнее вкладывать ресурсы в более жизнеспособные вещи.
A/B-тесты
Не всегда A/B-тест предполагает разработку. Можно просто добавить имитацию фичи и посмотреть на спрос — это точнее, чем выдумывать потенциал.
Мелкие итерации
Новый продукт должен доказать свою жизнеспособность перед полноценным запуском. Это должно быть быстро, дешево, базово — и с понятным результатом.
Иметь план Б
Цифры могут быть плохие по разным причинам. Например, вы просто не попали в нужный сегмент, и это нормально. Тогда необходимо понимать, как трансформировать гипотезу. Также любую гипотезу или фичу всегда нужно проектировать на шаг вперед через позицию «А если стрельнет, что дальше?» И это должно быть что-то понятное и простое, но улучшающее пользовательский опыт.
Три ключевых совета по разработке фичи
Малыми шагами к успеху
Большая ценность в гипотезах и коротких итерационных изменениях в продукте. Лучше медленно, но постоянно, чем быстро, но один раз.
Пишите!
Ведите всю документацию: от идеи до полного описания требований, включая метрики. Освободите свою память от мелких деталей и помогите команде быстро погрузиться.
Big Data — Big Love
Цифры — это круто, они наш большой помощник в принятии решений, но не забываем о человеческой составляющей, трендах и динамике изменений.
