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

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

Есть 7 видов гипотез: привлечения, активации, удержания, виральности, монетизации, ценности и управленческие.

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

Представим, что у вас есть продукт, приложение службы доставки. И вы решили, что нужно добавить туда функцию разделения счета. Чтобы большая компания могла прямо в приложении разделить счет и понять, кто сколько должен. Но вот вопрос, как вы поймете, что эта функция людям нужна? Что именно она даст рост вашему продукту? Как вы это измерите?

Или у вас есть мобильная игра Match 3 (собери в ряд). И вы решили, чтобы продвигаться дальше, нужно срочно запилить еще 30 новых уровней. Но как понять, что это действительно поможет? И пользователям понравится эта идея?

Продуктовая гипотеза помогает найти тот самый баланс между необходимыми действиями и реальным выхлопом. То есть вы не просто говорите: давайте запилим 30 новых уровней или добавим новую функцию. А весь этот процесс тщательно структурируете.

• Формат обсуждения гипотез облегчает взаимодействие внутри продуктовых команд.
• Позволяет донести идею и смысл до стейкхолдеров.
• Гипотезы упорядочивают процесс развития и разработки продукта.

Получается есть определенные ожидания от продукта и в связи с этим определенный набор действий, которые вы можете предпринять. К примеру, минимально жизнеспособный продукт (MVP) — это тоже одна большая продуктовая гипотеза, которую проверяет команда стартапа.

Есть 7 видов гипотез. Они помогут понять в каком направлении вам думать, чтобы создать свою.

• Гипотезы привлечения. Они тестируют каналы привлечения пользователей в продукт. Если поменяем что–то в канале, можем получить такой–то результат. Например такая гипотеза: если добавим в объявление цену, то конверсия в покупку вырастет на 7%. Или если изменим заголовок в письме рассылки, то увеличим открываемость писем на 50%.
• Гипотезы активации. Тестируют самый первый успешный пользовательский опыт. Гипотеза: допустим, я верю, что если внедрить персонализацию в онбординг, то приложение станет более полезным и понятным. Чтобы проверить гипотезу, сделаем одним из этапов онбординга опрос пользователя. Так он заполняет свой профиль, как в соцсети, и тем самым настраивает приложение под себя. Измерять результаты будем на органической аудитории. Метрика — увеличение количества сессий на пользователя на 15%.
• Гипотезы удержания. Тестируем создание привычки пользоваться нашим продуктом. Гипотеза: если добавить простой и быстрый доступ к историям поиска, то доля аудитории, которая будет использовать историю поиска при возвращении в продукт, увеличится на 7%.
• Гипотезы виральности или привлечение новых пользователей через существующих. Три старых пользователя приводят 10 новых, и так далее по нарастающей.
• Гипотезы монетизации. Про то, как переводить активных пользователей в платящих.
• Гипотезы ценности. Про востребованность главной ценности вашего продукта пользователями.
• Гипотезы управленческие. Связаны с изменениями в команде, использованием новых продуктов для повышения какой–либо метрики. Разберемся на примере. Гипотеза: если нанять в команду продукта второго контент–менеджера, то количество подписчиков в приложении вырастет на 1000 человек за 3 месяца. Или если мы начнем использовать эту платформу для управления проектами, то... и строим гипотезу.

Итак, чтобы быстрее расти, IT–компаниям нужно тестировать гипотезы. С чего начать?

• Для начала определимся, что хотим изменить в продукте. Добавить новые функции или уровни в игре, изменить цветовую гамму или какую–то кнопку убрать/добавить.
• Какая продуктовая метрика должна измениться, когда мы это сделаем. Это может быть конверсия, retention, LTV, MAU, DAU и так далее.
• На ком мы будем измерять этот эффект? Все люди ведут себя по–разному. Соответственно и их реакция на новшества в продукте может быть разной. Поэтому мы обозначаем, на ком проверяем гипотезу: на органическом трафике или неорганическом, на каких странах, на каких когортах людей.
• На сколько изменится нужная метрика. На 5%, 10% или 100%?
• За какой период мы получим необходимый результат. Тут все четко: за две недели или за три? За месяц или за год? Важно установить границы проверки продуктовой гипотезы, не делать их расплывчатыми по времени.

Когда мы ответим на все эти вопросы, то поймем, а надо ли тестировать гипотезу. Например, вы решите, что то самое изменение в продукте повысит конверсию на 10% через два года. Тогда стейкхолдеры, вероятно, спросят: «А, собственно стоит ли эта продуктовая гипотеза того, чтобы ждать целых два года?».

Сроки, которые вы закладываете на проверку продуктовой гипотезы, напрямую зависят от трафика. Допустим, вы можете привлечь в продукт 1 миллион человек из нужной вам аудитории за сутки. Тогда и сроки проверки нет смысла растягивать, вам вполне хватит этого дня.

В ином случае нужно рассчитывать, за какой срок к вам в продукт придет необходимая выборка пользователей.

Оптимальный срок для тестирования продуктовой гипотезы — 1-2 недели. В командах могут за месяц протестировать десятки разных гипотез. Лучше взять много гипотез, которые можно проверить за короткое время, чем одну–две, на которые уйдут месяцы или даже годы. Чем быстрее вы найдете правильные гипотезы и начнете с ними работать, тем быстрее вырастите. А чем круче ваша продуктовая команда,тем больше гипотез она сможет протестировать.

Давайте потренируемся создавать продуктовые гипотезы на реальных примерах с помощью нашей схемы.

Новый экран

Первая продуктовая гипотеза — создаем новый экран покупки в приложении. Это должно увеличить конверсию в покупку. Проверяем эффект на пользователях из США, которые пришли к нам в продукт из FB. Конверсия в покупку для них должна увеличиться на 12% в течение двух недель.

Новая функция в приложении

Следующая гипотеза — запуск новой функции в приложении. Она должен увеличить метрику 7 day retention на 11%. Напомним, что метрика ретеншн седьмого дня — это доля пользователей, которые открыли приложение через неделю, после первого своего визита. Они уже разобрались что тут к чему и активно пользуются. Считаем метрику по формуле: 7 day retention = X7 / Z. X7 — число пользователей, которые зашли в приложение на седьмой день, Z — общее число людей, которые установили продукт.

Проверяем метрику на органических пользователях из России в течение одного месяца.

Как видите, условия продуктовой гипотезы изменились, но структура осталась прежней.

Новая цветовая схема в приложении

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

Вы спросите, как же можно измерить количество пользователей, которые воспринимают приложение как приложение для женщин? Мы ведь не можем вытащить это из какой–то системы аналитики. И тут мы подходим к важному разделу: инструментам для проверки продуктовых гипотез. Они и помогут нам ответить на этот вопрос про метрику.

• A/B тестирование (сплит–тест). Когда старый, неизмененный вариант продукта, показывают 50% аудитории. А второй вариант, с изменениями, показывают другим 50% аудитории. Затем с помощью статистики оценивают, какой вариант зашел лучше или же между ними не было заметной разницы. На основе этого делают выводы.
• Количественный опрос пользователей. Их создание и проведение облегчают специальные сервисы. Например, Survey Monkey (на бесплатном тарифе можно создавать анкеты до 10 вопросов. Статистику ответов можно тут же просматривать в реальном времени, что особенно удобно на совещании. Ссылку на анкету можно разместить на сайте или в соцсетях). Такие сервисы позволяют выбрать нужную аудиторию и задавать ей вопросы. Этот вариант как раз и подойдет для проверки нашей продуктовой гипотезы по смене цветовой схемы в приложении. Опрос покажет, стали ли пользователи воспринимать приложение как приложение для женщин.
• Качественное исследование или customer development. Это прямой разговор с потребителями или с определенной группой потенциальных потребителей продукта. Специалист (обычно это product owner команды) в ходе этих разговоров должен узнать, что волнует их, какое у них восприятие. И с помощью этого проверять продуктовые гипотезы. Особенно этот способ хорош до того момента, как начали делать минимально жизнеспособный продукт. То есть это инструмент для того периода, когда продукта еще нет и вы пытаетесь понять, делать его или нет. Например, вы создаете продукт для молодых девушек, но в команде разработки нет ни одной девушки. Тогда нужно идти к этой аудитории и спрашивать ее.

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

Правильно формулировать продуктовые гипотезы помогает концепция SMART. Каждая буква имеет свое значение.

S — specific. То есть гипотеза должны быть конкретной и точной. Нельзя отнести к гипотезе смену позиционирования или редизайн всего приложения.

M — measurable. Вы должны суметь измерить результат продуктовой гипотезы. Иначе как вы поймете, в правильном идете направлении или ваша гипотеза оказалась ложной? Хорошую продуктовую гипотезу всегда можно измерить, это факт.

A — attainable. Ваша гипотеза должна быть достижима.

R — relevant. Продуктовая гипотеза должна быть вам реально полезна. Например, решили вы проверить новую функцию на пользователях из Индии. Вот только они совсем не приносят вам денег, никто из них ничего у вас не покупал и не покупает. Тогда зачем тратить на это время?

T — time bound. Это про реальную оценку сроков на проверку гипотезы. Подробнее об этом мы рассказывали выше.

Вы проверили продуктовую гипотезу по схеме, и она оказалась правдивой. Тогда на ее основе вы вносите изменения в продукт. Или если это был A/B тест, то распространяете продукт с изменениями уже не на 50, а на все 100% аудитории.

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