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

Автор: Роман Романчук

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

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

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

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

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

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

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

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

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

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

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

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

Пример оформления Jira доски
Пример оформления Jira доски

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

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

Цель

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

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

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

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

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

Пример:

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

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

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

Пример:

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

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

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

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

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

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

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

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

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

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

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

Problem List

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

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

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

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

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

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

Backlog

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

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

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

Почему мы должны ее рассматривать?

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

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

Результаты быстрой проверки для следующих показателей:

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

По результатам быстрой проверки на данных мы увидели что:

  • доля пользователей с такой кнопкой составляет 40%, так как такая кнопка отображается только у пользователей desktop-версии сайта;
  • все регионы;
  • desktop-версия сайта;
  • доля выручки составляет всего 15%, так как наши мобильные пользователи покупают активнее.
Гипотеза решения

Опишите что бы вы хотели изменить или протестировать:

  • гипотеза о решении какой-то проблемы в продукте;
  • предложение о том, что мы могли бы изменить в продукте и как это изменение повлияет на ключевые показатели продукта.
 Гипотеза решения

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

Также это повысит нашу выручку и долю платящих пользователей в desktop-версии сайта.
Метрики

Какие показатели продукта вас интересуют?

Как по вашему мнению изменятся метрики после внедрения фичи?

 Метрики

  • Коэффициент конверсии из просмотра карточки товара в клик (СR), как основная метрика;
  • Выручка (Revenue);
  • Доля платящих пользователей (Share of paying users).
Метод оценки гипотез

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

  • A/B test;
  • Fake Door test;
  • UX research;
  • Process Mining research.
 Метод оценки гипотез

Проверить гипотезу хотелось бы через A/B test.
Автор

Человек, придумавший идею

 Автор

Иван Иванов

Prioritization

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

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

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

  1. Проверка аналитиком: расчет потенциального влияния на ключевую метрику (Value) .
  2. Проверка владельцем продукта: расчет ресурсов, необходимых для реализации фичи (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-директор по аналитике Сравни.
Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *