HADI-циклы: Проверка гипотез без ошибок!
В предыдущем посте я уже немного рассказал про гипотезы. HADI-циклы — это подход, который состоит из 4 шагов (есть еще 2 дополнительных), проходя которые, вы можете проверить свои гипотезы.
Как расшифровывается HADI?
- H (Hypothesis) — гипотеза. Сама гипотеза, идея, предположение, которое нужно проверить;
- A (Action) — действия. Этап, на котором нужно определить методологию проверки гипотезы;
- D (Data) — данные. На этом этапе нужно определить метрики, которые будем измерять и на которые предположительно повлияет внедрение гипотезы в продукт;
- I (Insight) — инсайт, выводы. Заключительный этап, по итогам которого анализируем полученные данные, подтверждаем или опровергаем гипотезу или формулируем новую.
Как я уже говорил ранее, есть еще 2 важных шага:
- Faith / Confidence — определяют его по-разному, но если говорить просто, то это уверенность вашей команды в том, что гипотеза сработает. Чаще всего оценивают в процентах;
- Easy / Complexity — опять же, называют по-разному. Фактически это сложность проверки гипотезы. Обычно это среднее значение от 0 до 5 или 10.
Алгоритм действий, по которому я проверяю гипотезы в рамках HADI-циклов.
1.Формулирование гипотезы. Чаще всего я формулирую гипотезы по шаблону «Если…, то…». По сути, если формулировать гипотезу в таком формате, то сразу появляется понимание шага 3, то есть действий, и шага 4 — метрик. Дополнительно можно прогнать гипотезу по SMART.
2.Определение, насколько вы или вся команда верите в гипотезу и насколько сложно её проверить. Эти 2 параметра я всегда оцениваю сразу, до того как начать описывать методологию проверки и все другие подготовки. Так как если на старте понятно, что проверить сложно, а команда ещё и не верит в гипотезу, то не вижу смысла тратить время на проработку других пунктов.
3.Описание способов проверки/валидации гипотезы. Описание всего плана и действий, которые нужно сделать, чтобы проверить её.
4.Определение метрик и референсных значений, по которым будем определять успешность гипотезы.
5.Подготовка среды для проверки гипотезы. Тут все зависит от гипотезы и выбранной методологии. Предположим, вы хотите проверить потенциальный спрос на новую услугу, фичу и т.д. В этом случае нужно подготовить лендинг, презентацию и провести пресейлы или пользовательские интервью с предложением купить продукт в конце. Если у вас задача улучшения пользовательского опыта, и ваша гипотеза касается этого, то помогут юзабилити-тестирование или A/B-тесты. В общем, суть поняли.
6.Проверка гипотезы.
7.Выводы, инсайты. Удалось ли нам достичь референсных значений? Если да, то что дальше? Имплементируем в продукт, масштабируем? Если нет, то что? Выяснили ли мы еще что-то? И т.д.
Вы все умные, и, думаю, не стоит говорить, что не нужно проверять очевидные гипотезы, проводить проверку гипотез взаимосвязанных вещей и давать другие банальные советы.
Подписывайся на мой ТГ, блог на тему продакт-менеджмента и проектного управления - Dovzhenko vision