Продуктовые гипотезы: как перестать проверять уже принятое решение
Разбираемся, как не принять готовую фичу за гипотезу и что спросить, пока все не побежали её разрабатывать.
— Женёк, чего-то в кнопку не тыкают в самом начале нашего сценария. Мы тут подумали, и у нас есть гипотеза: нам нужен новый онбординг, ребята порисовали!
Медленно достают макеты нового онбординга.
Но нет, это уже не гипотеза. Это вполне конкретное решение, которое вы, скорее всего, начнёте делать и уже не откатите, потому что потратили 1000 часов. А цели так и не достигнете.
То же самое происходит, когда мы слышим: «нужно добавить ИИ», «пользователи хотят дашборд» или «если мы переставим вот эту вот кнопку, то конверсия вырастет».
Иногда за этим действительно стоит настоящее наблюдение, а иногда — просьба клиента, который так чувствует, конкретный вкус конкретного руководителя или даже идея, в которую команда уже влюбилась.
А дальше мы идём в исследование, которое должно доказать, что фича нужна пользователям, прототип должен всем точно понравиться, а A/B-тест — обязательно дать рост. Ну а если не дал, то виноват ретроградный Меркурий.
Но гипотеза нужна не для доказательства уже выбранной фичи, а для того, чтобы ответить себе на три вопроса:
- Чего мы пока не знаем?
- Как это проверить?
- Что изменится после ответа?
Если ответ ничего не меняет, то и проверять особо нечего.
Дальше на одном примере соберём карточку из четырёх вопросов. Доставать её стоит, когда решение уже появилось, но команда ещё не побежала его рисовать, доказывать и разрабатывать.
В нашем вымышленном сервисе для совместной работы новые пользователи открывают первый проект, но не создают первую задачу. Почему они останавливаются — никто не знает.
Отделяем факт от фантазии
В продуктовой гипотезе обычно смешаны четыре разные вещи:
| Слой | Что это | Пример |
|---|---|---|
| наблюдение | то, что команда действительно зафиксировала | новые пользователи открывают проект, но не создают первую задачу |
| предположение о причине | наше объяснение происходящего | люди не понимают, с какого действия начать и зачем |
| решение | то, что мы хотим изменить | раньше показать следующее действие и его результат |
| продуктовая гипотеза | ставка на то, что изменение даст наблюдаемый результат по предполагаемой причине | если следующий шаг станет заметнее и понятнее, больше новых пользователей создадут первую задачу |
Из всей таблицы мы точно знаем только первое: люди открыли проект и не создали задачу. Почему так произошло, что с этим делать и изменит ли решение поведение — пока наши версии. Поэтому про онбординг думать рановато.
Если после такого разбора осталась только конкретная фича, то это норм: мы перестали себе врать. Оставляем её решением и сначала разбираемся, что вообще происходит с пользователями.
Если наблюдение есть, не назначаем первое правдоподобное объяснение единственно верным. Выписываем ещё несколько причин, которые могут объяснить то же самое.
Для нашего примера список может быть таким:
- пользователь не понимает, с какого действия начать;
- ждёт, пока придут приглашённые коллеги;
- открыл продукт без намерения начать работу;
- выполняет нужное действие вне продукта;
- столкнулся с техническим ограничением.
Для каждой причины спрашиваем: что мы увидим, если она верна, и чем это будет отличаться от остальных объяснений?
Например, версия «не понимает первый шаг» предполагает, что человек спотыкается в самом сценарии. Версия «ждёт коллег» — что сценарий ему понятен, но начинать одному нет смысла.
Если разобрать с человеком недавний случай, версии будут выглядеть по-разному: один человек не сможет объяснить, что делать дальше, а другой назовёт действие, но скажет, что сознательно его отложил.
Обе версии объясняют одну и ту же цифру в аналитике, но ведут к разным решениям. Если люди понимают действие и просто ждут коллег, работа над онбордингом теряет смысл. Такой ответ сразу изменит план.
Остальные версии сравниваем так же и выбираем вопрос, ответ на который быстрее всего может изменить план. Он и станет главной неизвестностью для следующего шага.
Фиксируем неизвестность
Главную неизвестность выбрали, но теперь её нужно связать с наблюдением и решением команды — иначе через день всё это точно превратится в фичу.
Для этого используем простую рабочую карточку. Первым шагом запишем всего четыре поля:
Наблюдаем:
что зафиксировано, где, у кого и когда — без объяснения причины.
Решение, которое предстоит принять:
Главная неизвестность:
Какой ответ изменит план:Для нашего примера карточка выглядит так:
Наблюдаем:
по продуктовой аналитике за выбранный период новые пользователи
открывают проект, но не создают первую задачу.
Решение, которое предстоит принять:
нужно ли менять сценарий создания первой задачи.
Главная неизвестность:
не создают ли люди первую задачу потому, что не понимают,
с чего начать.
Какой ответ изменит план:
если люди понимают, с чего начать, не делаем онбординг
и ищем другую причину.Этих четырёх полей уже хватает, чтобы понять, чего команда не знает и может ли ответ поменять решение.
Если после этого нужно собрать гипотезу в одну фразу для обсуждения или бэклога, вот две шпаргалки:
Если нужно записать возможную причину:
мы предполагаем, что [кто] не делает [действие],
потому что [возможная причина].
Если нужно записать ставку на решение:
если мы [что изменим] для [кого и в каком контексте],
то [наблюдаемый результат] изменится [в какую сторону],
потому что [предполагаемый механизм].Не придумывайте, что метрика обязательно вырастет на 10% за пару недель. Сначала назовите направление изменения и объясните, почему вы его ожидаете. Число, срок и порог добавите позже, если проверка вообще их требует и у команды есть данные, на которые можно опереться.
Если любой результат всё равно ведёт к разработке онбординга, то это значит, что решение уже принято. И это не плохо. Плохо — делать вид, что команда всё ещё что-то проверяет.
Расширяем карточку
Когда выбрали конкретную проверку, не заводите новую карточку. Допишите под четырьмя полями:
Предполагаем:
какую причину или связь сейчас проверяем.
Проверяем так:
каким способом получим ответ.
Сигнал:
какой сигнал, поведение или метрика помогут
ответить на главную неизвестность.
Правило решения:
что команда сделает, если сигнал появится
или не появится.
Допустимый вывод:
какой вывод действительно поддерживает эта проверка.
Фиксируем после проверки
Что увидели:
какие сигналы появились, какие объяснения они поддерживают
и какие всё ещё возможны.
Какое решение приняли:
на какой шаг результата хватает и что пока заключить нельзя.Допустим, на тесте люди не замечают основное действие и застревают — вот сигнал. Мы заранее договорились: если так происходит, прототип не отдаём в разработку. Это уже правило решения. А вывод скромнее: текущий сценарий пока непонятен. Больше эта проверка ничего не доказывает.
После проверки запишите две вещи: что увидели и какое решение приняли. Иногда данных недостаточно или они противоречат друг другу. Тогда результат звучит так: «Мы пока не знаем». Это будет лучше, чем объявить гипотезу подтверждённой только потому, что команда потратила время на её проверку.
Если команда уже работает по HADI, Test Card или другому шаблону проверки, новый процесс не нужен.
Но мутный вопрос ни один фреймворк не починит.
Одна карточка — разные вопросы
Допустим, после первой проверки версия про непонятный первый шаг устояла. Теперь другой вопрос: понятно ли людям предложенное решение? А после запуска — изменило ли оно их поведение?
Не пытайтесь ответить на всё сразу одной проверкой. Сохраните результат, возьмите тот же шаблон и заполните его для следующего вопроса:
| Поле | Почему это происходит | Понятно ли решение | Изменилось ли поведение |
|---|---|---|---|
| какое решение принимаем | стоит ли устранять этот барьер | готов ли сценарий к разработке | стоит ли раскатывать изменение |
| чего не знаем | что мешает создать первую задачу | могут ли люди пройти новый сценарий | изменило ли решение поведение |
Порядок здесь не священный. Иногда технический риск нужно снять раньше, чем разбираться с поведением. Смотрите, какое решение команда принимает сейчас и чего ей для этого не хватает.
Выбираем метод по вопросу
...а не по настроению.
Не нужно выяснять, что взрослее и лучше: интервью, юзабилити-проверка или A/B-тест. У них просто разные задачи.
| Что хотим узнать | Чем проверить | Что узнаем | Чего не узнаем |
|---|---|---|---|
| что происходит в продукте | продуктовая аналитика, системные события и логи ошибок | где люди останавливаются, какие действия и ошибки видит система | почему это происходит |
| о каких проблемах люди говорят | обращения в поддержку, обратная связь | на что люди жалуются, какими словами и в каких ситуациях | что они делали на самом деле и насколько часто возникает проблема |
| почему люди так действуют | наблюдение, интервью о недавнем случае | контекст, возможные причины и обходные пути | насколько распространена каждая причина и поможет ли фича |
| понятен ли сценарий | юзабилити-проверка | где люди спотыкаются, выполняя реалистичную задачу | будут ли они пользоваться решением после запуска |
| можем ли мы это сделать | короткий технический прототип | можно ли технически реализовать критическую часть решения | нужно ли это людям |
| как решение работает в реальном продукте | пилот, ограниченный запуск | как им пользуются, какие всплывают зависимости и крайние случаи | вызвало ли именно решение наблюдаемый эффект, если сравнения не было |
| изменило ли решение поведение | A/B-тест или другой эксперимент с контрольной группой | можно ли связать изменение поведения с решением при корректном дизайне эксперимента | повторится ли результат на другой аудитории и в другом контексте |
В Авито хотели сравнить, как люди выполняют целевые действия в разных вариантах карточки объявления. Обычная юзабилити-проверка не дала бы сравнить варианты в цифрах, а для A/B их пришлось бы сначала разработать. Поэтому команда выбрала айтрекинг. Он помог сравнить макеты до разработки, но не показал, как поведёт себя вся аудитория после запуска.
Бывает и наоборот: знакомое название метода создаёт ложную уверенность. Ozon Tech разбирал, как можно испортить даже A/B: не продумать эксперимент заранее, ошибиться в расчёте метрики, остановить тест слишком рано или начать искать эффект сразу во множестве показателей.
Гипотеза нужна не всегда
Очевидный баг, требование закона или безопасности и обязательная техническая миграция могут быть просто задачами. И это норм.
Гипотеза может появиться внутри — например, когда нужно решить, что и как переносить для пользователя, — но проверять сам факт обязательной работы незачем. Договоритесь, каким должен быть результат, и проверьте его после запуска.
Карточка всего лишь ориентир
Карточка не подскажет, кого позвать на интервью, какую метрику выбрать и насколько можно доверять выводам.
Проверяете причину или понятность сценария — позовите исследователя, пока вопрос ещё можно поменять. Хотите измерить эффект — подключите аналитика до запуска. После сбора данных чинить кривую проверку поздно.
Насколько тщательно проверять гипотезу, зависит от цены ошибки:
- сколько времени и денег команда потеряет;
- можно ли быстро и безопасно откатить изменение;
- скольких людей затронет неудачное решение и чем оно им навредит.
Небольшую правку текста иногда дешевле выпустить на часть аудитории и посмотреть на результат. Решение на месяцы разработки, которое затрагивает деньги или права доступа, требует оснований посильнее.
В общем, не делайте рокет-сайенс для каждой кнопки, но и банковскую транзакцию не проверяйте на пяти коллегах в коридоре офиса.
А можно другую задачу?
Можно.
В B2B-сервисе пользователи открывают еженедельный отчёт, но редко нажимают встроенную кнопку «Поделиться», чтобы отправить отчёт коллеге или начальству. Команда решила, что людям сложно собрать короткую выжимку для коллег, и предлагает добавить ИИ-саммари.
Мы ещё не знаем причину, но ИИ уже почти запихнули ногой в продукт.
Пока не решаем, будет ли это ИИ. Просто заполняем четыре поля:
Наблюдаем:
в выбранном сегменте пользователи открывают еженедельные отчёты,
но редко нажимают кнопку «Поделиться».
Отправляют ли они отчёты другим способом, аналитика не показывает.
Решение, которое предстоит принять:
нужно ли менять сценарий, чтобы людям было проще
делиться выводами с командой.
Главная неизвестность:
почему люди не используют кнопку «Поделиться»
и как они передают выводы из отчёта сейчас.
Какой ответ изменит план:
если потребности делиться нет или мешают права доступа
и конфиденциальность, не делаем ИИ-саммари.
Если люди вручную выписывают из отчёта основные цифры и выводы,
а потом отправляют их коллегам, проверяем,
поможет ли им короткое саммари.Можно поговорить с людьми, которые недавно открывали отчёт, и разобрать последний реальный случай: кому они хотели передать выводы, как это сделали и что им помешало. Но спрашивать «нужно ли вам ИИ-саммари» бессмысленно — мы снова получим мнение о готовом решении вместо рассказа о поведении.
Даже если проблема действительно в саммари, ИИ всё ещё не обязателен. Сначала соберите короткую выжимку вручную или покажите простой прототип и посмотрите, помогает ли она вообще.
Теперь вернитесь к своей гипотезе и заполните четыре поля. Нечего записать в наблюдение — сначала разберитесь, что вообще происходит. Любой ответ ведёт к одной и той же фиче — значит, вы уже всё решили. Не надо называть это гипотезой.
