Как генерировать сильные продуктовые гипотезы
Это вторая статья из цикла материалов про базу по работе с гипотезами, который я готовила для внутреннего обучения команды продактов OTUS. В первой статье говорили про важность продуктового мышления. Здесь разберемся, что такое хорошая продуктовая гипотеза и как генерировать сильные гипотезы для роста вашего продукта на основе данных, а не субъективных ощущений.
Что такое хорошая продуктовая гипотеза и чем она отличается от идеи?
Идея – это догадка, часто основанная на чьем-то конкретном мнении. Пример: «Давайте добавим в приложение темную тему».
Почему? Потому что это модно, или нравится нам, или есть у конкурентов? Не очень похоже на достаточный аргумент, особенно с точки зрения бизнеса, когда цена каждого изменения в продукте может быть довольно (или слишком) высока.
Хорошая продуктовая гипотеза превращает абстрактную идею в проверяемое обоснованное предположение. Это не чья-то субъективная фантазия, наитие или галлюцинация. Она отвечает на вопрос «Почему мы вообще это задумали?» и «Как мы поймем, что это действительно работает?».
Ключевой элемент сильной гипотезы — ее обоснованность. Прежде чем строить предположение о будущем, мы должны проанализировать прошлое и настоящее. Хорошая гипотеза рождается из попытки понять и объяснить существующие явления или тенденции в продукте. Она опирается на данные статистики, результаты опросов, исследований и экспериментов.
Почему это так важно?
- Смещает фокус с мнений на данные. Обсуждение начинается не с «мне кажется», а с «вот что мы видим в данных».
- Повышает качество гипотез. Команда не будет тратить время на проверку догадок, у которых нет фундамента.
- Создает ясность для команды. Все понимают не только что делать, но и почему мы это делаем, какую конкретную проблему решаем.
Есть разные подходы к формулированию продуктовых гипотез. Разберем здесь такую формулу:
«Основываясь на [Факт/Наблюдение F], мы считаем, что если [сделать А] для [группы пользователей B], то это приведет к [ценному результату C]. Мы будем правы, если увидим изменение [метрики D] на [значение E].»
Она может показаться излишне сложной или громоздкой, но эта формула дисциплинирует мышление, заставляет заранее продумать критерии успеха и отлично подходит для оттачивания навыка формулирования гипотез. Разберем формулу на практике:
Факт/Наблюдение F (триггер или обоснование)
Это основание для вашей гипотезы. Конкретный факт, данные или качественное наблюдение, которое объясняет, с чего вы вообще это взяли. Примеры:
- «Основываясь на анализе heat map, который показывает, что 60% пользователей не прокручивают главный экран до ключевого CTA-элемента...»
- «Основываясь на пяти интервью с ушедшими пользователями, где они жаловались на сложность первоначальной настройки профиля...»
- «Основываясь на данных из отдела поддержки, где 30% обращений связаны с непониманием статуса заказа...»
Сделать A (действие)
Конкретное и реализуемое изменение в продукте, которое должно решить проблему, выявленную в пункте F. Пример:
«...мы считаем, что если вынести ключевой CTA-элемент в sticky-бар в верхней части экрана...»
Для группы пользователей B (Аудитория)
Сегмент, на котором проявляется проблема или возможность. Пример:
«...для пользователей мобильного приложения с экраном меньше 6 дюймов...»
Приведет к ценному результату C (outcome)
Предполагаемое улучшение, которое мы ожидаем. Пример:
«...то это увеличит видимость целевого действия и повысит общую конверсию...»
Мы будем правы, если увидим изменение метрики D (метрика)
То, как мы измерим результат. Через что мы поймем, что были правы в своем предположении. Пример:
«...Мы будем правы, если кликабельность этого CTA-элемента...»
На значение E (критерий успеха)
Количественный порог.
«...увеличится на 20% в течение двух недель после релиза.»
Полная обоснованная гипотеза по такой формуле в итоге будет выглядеть так:
«Основываясь на анализе heat map, который показывает, что 60% пользователей не прокручивают главный экран до ключевого CTA-элемента, мы считаем, что если вынести ключевой CTA-элемент в sticky-бар в верхней части экрана для пользователей мобильного приложения с экраном меньше 6 дюймов, то это увеличит видимость целевого действия и повысит общую конверсию. Мы будем правы, если кликабельность этого CTA-элемента увеличится на 20% в течение двух недель после релиза.»
Формулирование гипотезы таким образом пригодится в дальнейшем для подготовки дизайна эксперимента и оценки его результатов.
Гипотеза — это не стартовая точка, а середина исследовательского цикла. Сначала мы собираем данные (F), затем формируем и проверяем гипотезу (A-E).
В следующем блоке мы как раз подробно разберем, где и как собирать эти самые «Факты F» – качественные и количественные данные, которые станут топливом для ваших гипотез.
Как генерить гипотезы?
Сильная гипотеза всегда начинается с «Факта F» — наблюдаемого явления. Эти явления можно разделить на две логические группы: эмпирические данные (качественные и количественные) и стратегический контекст (внешние требования и возможности). Начнем с самого объективного источника.
Группа 1: Эмпирические данные – результаты прямых наблюдений за пользователями
Это «золотой стандарт» обоснования продуктовых идей. Вы не предполагаете, вы видите и слышите проблему или возможность своими глазами. Здесь мы тоже можем разделить данные на 2 подгруппы:
1. Качественные данные. Услышать «почему» за сухими цифрами
Это данные, которые объясняют мотивы, боли и контекст пользователей. Они отвечают на вопрос «Почему?».
- Общение с пользователями/клиентами: глубинные интервью, коридорные тесты, фокус-группы.
Как искать гипотезы: Слушайте не только что говорят, но и что они не договаривают. Ищите противоречия между словами и действиями. Задавайте уточняющие вопросы, которые позволят избавиться социально-желаемых ответов.
Пример «Факта F»: «На основе 5 интервью мы выяснили, что пользователи не используют функцию «Избранное», потому что не понимают, в какой момент им будет предложено вернуться к этим товарам.» → Гипотеза: «Основываясь на этом, мы считаем, что если добавить триггерное сообщение «Смотрите, товары из вашего избранного сейчас со скидкой» при запуске акции, то это повысит осведомленность о ценности функции и увеличит конверсию в покупку из «Избранного». - Фидбек из поддержки/отзыв. Готовый источник самых острых проблем. Но нужно помнить, что люди чаще всего оставляют негативные отзывы/фидбек, то есть картина может быть искажена в минус и реальный масштаб проблемы может не быть таким большим, как кажется при первом приближении. Оставайтесь критичными и не забывайте валидировать полученный фидбек.
Как искать гипотезы: Агрегируйте и категоризируйте запросы. Какие темы всплывают чаще всего? Где пользователи путаются?
Пример «Факта F»: «Анализ обращений в поддержку показал, что 40% запросов касаются сброса пароля.» → Гипотеза: «Основываясь на этом, мы считаем, что если упростить процесс восстановления пароля, добавив ссылку в SMS, то это снизит нагрузку на поддержку и уменьшит время на восстановление доступа.» - Записи сессий (Session Recording) и карты кликов/просмотров (Heatmaps). Позволяют увидеть продукт глазами пользователя.
Как искать гипотезы: Смотрите, где пользователи залипают, где бесконечно скролят, куда кликают без результата («слепые клики»).
Пример «Факта F»: «Карты кликов показывают, что 60% пользователей кликают на неинтерактивный элемент, ожидая, что он ведет на страницу доставки.» → Гипотеза: «Основываясь на этом, мы считаем, что если сделать этот элемент интерактивной ссылкой, то это уменьшит путаницу и повысит удовлетворенность.»
2. Количественные данные. Увидеть масштаб и тренды
Это данные о том, что происходит в продукте, в виде чисел и метрик. Они отвечают на вопрос «Что?» и «Насколько масштабно?».
- Системы аналитики (Amplitude, Mixpanel, GA). Позволяют найти закономерности в поведении пользователей и показывает поведенческие паттерны в масштабе.
Как искать гипотезы: Ищите узкие места в воронках (где самые большие потери?), анализируйте пути пользователей, сегментируйте аудиторию.
Пример «Факта F»: «Воронка аналитики выявила, что 80% пользователей отваливаются на шаге добавления платежных данных.» → Гипотеза: «Основываясь на этом, мы считаем, что если добавить возможность оплаты через Apple Pay/Google Pay для пользователей iOS/Android, то это снизит трение и увеличит финальную конверсию на 15%.» - Результаты A/B тестов. Каждый завершенный эксперимент — источник новых вопросов и гипотез.
Как искать гипотезы: Почему вариант Б выиграл? Почему проиграл? Какие побочные метрики изменились? Ответы на эти вопросы рождают новые, более глубокие гипотезы.
Пример «Факта F»: «Прошлый A/B тест показал, что красная кнопка конверсии лучше зеленой, но также увеличил показатель отказов.» → Гипотеза: «Основываясь на этом, мы считаем, что красный цвет создает визуальную перегрузку, и если мы смягчим цветовую схему вокруг кнопки, то сохраним высокую конверсию, но снизим показатель отказов.»
Группа 2: Стратегический и операционный контекст – те тенденции, идеи, инсайт, которые требуют дополнительной валидации и исследования
Источники из этой группы служат “вдохновением” и опорой для продакта. Они должны подталкивать вас копнуть глубже в данные, исследовать и проверять.
1. Бизнес-контекст – стратегия компании, OKR, запросы от sales или маркетинга
Как ни крути, но конечная задача любого продукта – достичь бизнес-целей. Гипотезы должны двигать бизнес, а не просто добавлять функциональность.
Как искать гипотезы: Превращайте стратегические цели в исследовательские вопросы. «Один из наших OKR на квартал — увеличить долю повторных покупок до 40%.» → Темы для мозгового штурма и исследований: «А как сейчас происходят повторные покупки?», «Почему пользователи совершают повторные покупки?», «Какие пользователи совершают повторные покупки?» и т
2. Внешний контекст – технологии, тренды, конкурентный анализ
Появление новой технологии (например, AI), успешные фичи у конкурентов, рыночные тренды – все это может служить дополнительным источником идей и гипотез.
Как искать гипотезы: Что делают конкуренты? Что у них хорошо работает (судя по отзывам)? Какие потребности пользователей они упускают? Все возникающие гипотезы нужно валидировать через призму нашей ЦА, наших пользователей. Важно не просто копировать и внедрять все новое и интересное, а понять, может ли это принести ценность именно в наш продукт.
3. Личные идеи и инсайты. Как их валидировать
Это самая «сырая» форма гипотезы. Чтобы она стала обоснованной, нужно превратить ее в «Факт F». Спросите себя: «Какое наблюдение или данные привели меня к этой идее?». Если ответа нет — это догадка. Ищите ей подтверждение в качественных или количественных данных, прежде чем продвигать.
Далее мы разберем фреймворки, которые помогут структурировать этот поток идей и докопаться до сути.
Фреймворки и полезные фишки для генерации и структурирования гипотез
Фреймворки не генерируют гипотезы за вас, но создают структуру, которая систематизирует поиск идей и помогает докопаться до коренных причин, превращая сырые данные и стратегические цели в проверяемые предположения.
Opportunity Solution Tree (OST)
OST или карта пути от бизнес-целей продукта к решению – это метод, популяризированный Терезой Торрес.
Как это работает (4 уровня):
- Вершина дерева – продуктовая цель (Outcome). Чего мы хотим достичь? (Например, «Увеличить 30-дневный retention на 10%»). Эта цель часто берется из OKR.
- Возможности (Opportunities): Какие потребности, боли или желания пользователей, если мы их удовлетворим, помогут нам достичь цели? Это не фичи, а проблемы, которые мы выявили из данных. Пример из интервью (Факт F): «Пользователи говорят: "Я забываю, зачем приходил в это приложение"». Возможность: «Пользователям нужен способ быстро вспомнить последние действия и неотложные задачи».
- Решения (Solutions): Как мы можем реализовать эти возможности? На этом уровне проводится мозговой штурм всех возможных решений — от самых простых до сложных. Решения для возможности выше: «История последних действий», «Закрепленные заметки на главном экране», «Умные напоминания».
- Проверка гипотезы (Assumption Test или Experiment): Каждое решение мы формулируем как проверяемую гипотезу по знакомой нам формуле, чтобы выбрать самое перспективное для эксперимента.
Почему это круто? OST не позволяет сразу прыгать к решениям. Он заставляет сначала глубоко понять проблемное пространство и только потом искать ответы, обеспечивая обоснованность наших будущих гипотез.
Jobs To Be Done (JTBD)
JTBD — это философия, которая предлагает смотреть на продукт не как на набор фич, а как на «наемного работника», которого пользователь «нанимает», чтобы выполнить определенную «работу».
«Работа» (Job) — это фундаментальная задача, которую пользователь пытается решить в своей жизни. Например, «когда я прихожу домой уставшим с работы, я хочу быстро приготовить вкусный и полезный ужин».
Как это помогает находить гипотезы? Вы перестаете думать «какую фичу добавить?» и начинаете спрашивать: «Какую "работу" наш продукт не позволяет сделать хорошо?» и «Как мы можем помочь пользователю лучше и быстрее выполнить свою "работу"?». Разберем на примере:
- Факт F (из качественных интервью): Пользователи говорят: «Я пользуюсь вашим кулинарным приложением, но все равно трачу много времени на поиск рецепта».
- Анализ через JTBD: «Работа» пользователя — не «найти рецепт», а «быстро принять решение о том, что готовить, исходя из имеющихся продуктов».
- Обоснованная гипотеза: Основываясь на понимании этой «работы», мы считаем, что если добавить функцию «умный поиск по ингредиентам в холодильнике» для пользователей, которые заходят в приложение после 18:00, то это уменьшит время на принятие решения и повысит частоту использования приложения по вечерам.
Бэклог гипотез
Это живой, постоянно обновляемый артефакт продуктовой команды, который служит единым источником истины о том, что мы планируем проверить дальше. Создайте свою удобную систему для хранения и обработки идей, в которой вы сможете валидировать идеи, превращать их в гипотезы, приоритизировать, хранить информацию о статусе и результатах экспериментов.
Полезные фишки для бэклога гипотез:
- Не пытайтесь заносить туда сразу готовую гипотезу – добавляйте любые идеи, но следите за статусом и регулярно проводите ревью.
- Храните источник идеи и автора, чтобы всегда можно было уточнить детали
- Определитесь сразу, на какую метрику потенциально будет влиять ваша гипотеза. Идеи, не влияющие на метрики продукта, вам не нужны.
- Можно добавить связку с OKR или бизнес-целями. Это помогает держать фокус.
В следующей статье рассмотрим, как выбрать гипотезы, которые стоит брать в работу:
Это третья статья из цикла материалов про базу по работе с гипотезами, который я готовила для внутреннего обучения команды продактов OTUS. Ранее я писала про продуктовое мышление и генерацию сильных продуктовых гипотез. Здесь разберемся, как расставить приоритеты, используя популярные фреймворки для оценки и приоритизации гипотез в продуктовом бэкл…
Дальше разберем подробнее процессы проверки гипотез через HADI-циклы:
Это финальная статья из цикла материалов про базу по работе с гипотезами, который я готовила для внутреннего обучения команды продактов OTUS. Ранее я писала про продуктовое мышление, генерацию сильных продуктовых гипотез и популярные фреймворки для оценки и приоритизации гипотез . Здесь разберемся, как это все работает вместе в итеративном цикле ра…
Буду рада вопросам, комментариям и конструктивной критике!
Про автора:
Я Даша, product manager в онлайн-школе дизайна Contented с неплохим таким бэкграундом в web dev, маркетинге, FinTech и EdTech проектах. Обожаю тему growth hacking'а, CRO и оптимизации UX/CX.