Как правильно организовать работу с гипотезами

Сегодня речь пойдет о том, как правильно организовать работу с инсайтами и гипотезами при развитии продукта с точки зрения аналитика.

Обычно от команды продуктовой аналитики бизнес ожидает следующее:

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

А как на самом деле?

Чаще всего в командах продуктовой аналитики в той или иной степени присутствуют следующие проблемы (за исключением крупных компаний с развитой аналитической культурой, таких как Яндекс, Ozon, Avito):

Не систематизирован процесс поиска инсайтов, выдвижения гипотез для улучшения продукта, а работа группы данных в основном состоит из решения потока срочных задач с редкими A/B-тестами;
Гипотезы «прилетают» случайным образом и без какой-либо приоритизации, а часть идей теряется;
Есть проблемы с проведением A/B-тестирования, как на техническом уровне, так и на уровне методологии;
Члены продуктовой команды не координируют свои действия для достижения ключевых целей;
Нет фиксации результатов и наработанной базы знаний, новые члены команды могут тестировать по кругу одни и те же вещи.

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

Бэклог гипотез

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

Бэклог гипотез — это список идей по улучшению продукта для будущих A/B-тестов или исследований, отсортированный по приоритету и полезности.

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

Поэтому, я предлагаю использовать kanban доску в Jira или любой аналог. Этот инструмент прост, понятен и чаще всего уже есть в вашей компании. То есть не нужно будет тратить драгоценное время на поиск, покупку и интеграцию — создание новой доски займет всего 5 минут.

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

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

Цель

Теперь давайте подумаем о том, зачем мы это делаем. Создание бэклога преследует несколько целей:

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

Какие бывают гипотезы?

Гипотеза проблемы

Предположение о любых проблемах в продукте, которое должно быть подтверждено данными.

Пример:

Пользователям продукта не нравится ярко-красный цвет кнопки «Купить» и из-за этого они меньше на нее нажимают.

Гипотеза решения

Предположение о том, что мы можем изменить в продукте и как это изменение повлияет на метрики.

Пример:

Давайте покрасим кнопку в более приятный глазу цвет, что поспособствует увеличению количества кликов на нее.

Для аналитика

В зависимости от стадии разработки продукта у вас может быть много гипотез. Чтобы трансформировать идею в потенциальное решение, вы должны следовать схеме:

Собрать и проанализировать информацию о пользователях из следующих возможных источников:
- интервью с продактами и пользователями;
- наблюдение за воронкой;
- проверка обратной связи и отзывов о продукте;
- анализ деятельности конкурентов.
Выявить болевые точки пользователей и затем спросить себя: «Что мы можем изменить в продукте, чтобы получить улучшение метрики N?»;
Подробно описать гипотезу решения и подумать, возможна ли в принципе разработка такого изменения;
Поместить свою гипотезу на доску в Jira для оценки потенциального эффекта от внедрения;
В зависимости от результатов валидации совместно с командой создать план следующего шага:
- если гипотеза решения получит положительные результаты валидации, продумайте способ проверки: A/B-тест или ресерч;
- если результаты отрицательные — просто перенесите ее в архив, но не удаляйте.

Бизнес-процесс

А теперь самое интересное о том, как устроен бизнес-процесс менеджмента гипотез.

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

Однако дальнейшее управление бэклогом лучше доверить аналитику или продакту.

Жизненный цикл гипотезы

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

Кликни, чтобы увеличить

А теперь давайте подробно пройдемся по каждому из статусов.

Problem List

Список проблем — это страницы в Confluence или Notion, которые агрегируют информацию о проблемах из разных источников:

отзывы партнеров или пользователей;
количественные или качественные исследования;
экспертное мнение или идея любого сотрудника.

Важно сгруппировать проблемы по похожим кластерам и пронумеровать.

Список гипотез проблем — Пример списка гипотез проблем

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

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

Backlog

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

Prioritization

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

Одним из самых простых и классических вариантов является скоринг гипотез на основе Value & Effort. Однако, вы можете использовать более сложные модели, например ICE или RICE для расчета скорингового балла для каждой гипотезы.

На данном этапе осуществляется проверка гипотез, которая состоит из двух этапов:

Проверка аналитиком: расчет потенциального влияния на ключевую метрику (Value) .
Проверка владельцем продукта: расчет ресурсов, необходимых для реализации фичи (Effort).

Что такое Value & Effort

«Value & Effort» — это метод приоритизации, который позволяет оценить ценность задачи и уровень усилий, необходимых для ее выполнения. Этот подход обеспечивает системность при принятии решений.

Основные принципы:

Ценность (Value) — это оценка потенциального позитивного влияния от выполненной задачи. Например, вы можете отдать бОльший приоритет задаче, которая увеличивает доход продукта или улучшает пользовательский опыт.
Усилия (Effort) — это оценка количества времени, ресурсов и энергии, необходимых для выполнения задачи.

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

Важно помнить, что при такой приоритизации существует риск отодвинуть долгосрочные проекты, которые хоть и обладают высокой ценностью, но требуют очень больших усилий. Учитывайте это при планировании работ и подумайте об альтернативах, позволяющих сократить усилия (например, Fake door тест, вместо реального A/B).

Что отличает «Value & Effort» от других методик приоритизации? Большинство методов сконцентрированы либо на количественной, либо на качественной оценке, в то время как «Value & Effort» сочетает в себе оба подхода. Таким образом, вы учитываете как стратегическую ценность, так и реальные ресурсы. В итоге, вы можете принимать обоснованные решения.

Ready

В этот статус переносятся гипотезы, которые прошли проверку и не были отброшены, получили оценку Value & Effort и готовы перейти к следующему этапу.

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

Также нужно описать то, по каким критериям будет оцениваться успешность или неуспешность эксперимента.

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

Например, если ваша метрика увеличение конверсии на 2%, в результатах эксперимента вы должны увидеть это увеличение и оно должно быть статистически значимо.

Research

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

A/B-теста;
Fake door теста;
Process Mining;
UX исследования или другого подходящего метода.

Review

На этом этапе проводится анализ результатов и подводятся итоги эксперимента. После этого принимается решение об успешности проверяемой гипотезы и выпуске фичи в продукт на основе критериев определенных на этапе подготовки (Ready).

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

Done

Это окончательный статус, который имеет три возможных итога:

Есть эффект — эксперимент показал эффект, рассчитывается фактическое влияние на ключевую метрику;
Нет эффекта — эксперимент не показал эффекта;
Гипотеза отвергнута — гипотеза была отклонена (на любом этапе), причины могут быть разные, например, на реализацию такой идеи нужен огромный бюджет, сравнимый с бюджетом какой-нибудь маленькой страны.

Итог

Описанный бизнес-процесс не истина в последней инстанции и в вашем случае он может быть совершенно другой.

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

Об авторе
Свежие записи

Роман Романчук

Эксперт по маркетинговой и продуктовой аналитике, ex-директор по аналитике Сравни.

What are You Looking for?

Как правильно организовать работу с гипотезами?