HADI-циклы: как проверять гипотезы и превращать данные в решения

Команда месяц спорит о новой функции. Квартал её разрабатывает. Ещё квартал ждёт отчёта, чтобы понять, сработала ли она.

За полгода рынок успевает измениться.

HADI-цикл сжимает путь от идеи до решения до одной-двух недель. Одна гипотеза, одно действие, одна метрика, один вывод — и следующий цикл.

В этой статье разберём, как устроен HADI-цикл, какие бывают типы гипотез и чем проверять каждый, как сформулировать гипотезу и как встроить HADI в еженедельный ритм команды. Внутри — шаблоны, примеры с наших воркшопов и чек-лист ошибок.

HADI — аббревиатура четырёх шагов проверки гипотезы.

• Hypothesis — гипотеза. Предположение, в котором вы сомневаетесь и которое хотите проверить.
• Action — действие. Эксперимент, который даст ответ: что делаем, кто делает, какими инструментами.
• Data — данные. Измеримый результат эксперимента.
• Insights — выводы. Что мы теперь знаем и какое решение принимаем.

Вывод одного цикла становится основой следующей гипотезы. Так проверка превращается в непрерывный механизм обучения.

Главный принцип метода: результат цикла — вывод. Действие служит способом его получить.

Сравните два отчёта.

«Сделали 40 звонков по новой базе» — отчёт о работе.

«Из 40 звонков 6 закончились встречей. Конверсия 15 % при пороге 10 %. Канал берём в работу и расширяем базу» — результат HADI-цикла.

HADI — близкий родственник двух известных циклов. Первый — цикл «создать — измерить — научиться» (Build — Measure — Learn) Эрика Риса, автора метода Lean Startup. Второй — цикл PDCA (Plan — Do — Check — Act: планируй — делай — проверяй — действуй), который популяризировал Эдвард Деминг.

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

Каждая гипотеза — ставка ресурсами команды. Чем дольше проверка, тем дороже ошибка.

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

HADI решает три задачи.

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

Связывает действия с метрикой. Каждое действие отвечает на конкретный вопрос и двигает конкретный показатель.

Доводит исследования до решений. Выводы попадают в бэклог с ответственным и датой. Отчёт начинает работать на бизнес.

Ориентир, который мы рекомендуем корпоративным командам: от старта исследования до первого инсайта — до 14 дней, от инсайта до изменения в продукте — до 30 дней.

Эрик Рис в книге «Бизнес с нуля. Метод Lean Startup» выделяет два главных допущения любого нового продукта.

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

Разница — в предмете проверки, метриках и методах.

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

На практике каждую группу удобно разложить на типы. У каждого типа свой вопрос, шаблон формулировки и способ проверки. Все примеры ниже — про один условный продукт: сервис автоматической сверки актов и оплат для проектных компаний. Так видно, как гипотезы складываются в цепочку. Цифры в примерах условные.

Гипотеза сегмента. Кто наш клиент. Шаблон для B2B: «Компании из отрасли {А} с оборотом {Б} и штатом {В}, которые тратят на решение проблемы {Г} рублей в год». Пример: «Проектные компании со штатом от 50 человек, которые закрывают больше 30 договоров в месяц и тратят на ручную сверку от 200 тыс. ₽ в год». Чем проверять: анализ рынка, экспертные интервью, разбор воронки по сегментам.

Гипотеза проблемы. У клиента есть важная нерешённая проблема. Шаблон: «{Пользователь} сталкивается с {проблемой} в {ситуации}. Чтобы её решить, он делает {действия}, и это обходится ему в {X рублей} или {Y часов}». Пример: «Бухгалтер проектной компании вручную сверяет закрытые проекты с оплатами и актами. Сверка занимает два рабочих дня в месяц». Чем проверять: проблемные глубинные интервью.

Гипотеза технологии. Технология решает задачу с нужными характеристиками. Шаблон: «{Технология} позволит выполнить {задачу} с {целевой характеристикой}». Пример: «Распознавание документов позволит сопоставлять акты с платежами автоматически с точностью от 95 %». Чем проверять: proof of concept (проверка работоспособности идеи), лабораторный прототип.

Гипотеза продукта. Наше решение закрывает проблему и даёт выгоду. Шаблон: «{Продукт} решает {проблему} для {сегмента} с помощью {технологии} и даёт {выгоду 1, выгоду 2}». Пример: «Сервис сверки решает проблему ручного контроля актов для проектных компаний с помощью интеграции с банком и электронным документооборотом и сокращает сверку с двух дней до двух часов». Чем проверять: решенческие интервью, прототип, MVP (минимально жизнеспособный продукт).

Гипотеза выгоды. Пользователь получает обещанную пользу в реальной работе. Шаблон: «В пилоте {сегмент} получит {выгоду}, измеренную как {метрика}». Пример: «В пилоте с тремя компаниями время сверки сократится с двух рабочих дней до двух часов в месяц, а число просроченных оплат — на треть». Чем проверять: альфа- и бета-тест, пилот с замером «до» и «после».

Гипотеза канала. Где и по какой цене мы находим клиентов. Шаблон: «{Канал} даст {X} % конверсии в {заявку / встречу}» или «В {канале 1} привлечение дешевле, чем в {канале 2}». Пример: «Вебинар для финансовых директоров проектных компаний даст 5 % конверсии из регистрации в демонстрацию продукта». Чем проверять: тестовая кампания с ограниченным бюджетом, аутрич, выступление с лид-формой.

Гипотеза конверсии. Что увеличит долю пользователей, совершивших целевое действие. Шаблон: «Если {изменение}, то {конверсия в действие} вырастет на {X} %». Пример: «Если показывать результат сверки на данных клиента прямо на демонстрации, конверсия в пробный период вырастет на 20 %». Чем проверять: A/B-тест, анализ микроконверсий в воронке.

Гипотеза удержания. Что заставит клиентов возвращаться. Шаблон: «{Механика} увеличит долю вернувшихся клиентов на {X} % за {период}». Пример: «Еженедельный отчёт о найденных расхождениях увеличит долю компаний, продливших подписку после первого месяца, на 15 %». Чем проверять: когортный анализ.

Гипотеза виральности. Что заставит клиентов приводить других. Шаблон: «Если давать {бонус} за приглашение, {X} % пользователей пригласят хотя бы одного знакомого». Пример: «Если давать месяц бесплатно за приглашённую компанию, 10 % клиентов пригласят хотя бы одну». Чем проверять: реферальная механика на части аудитории.

Гипотеза монетизации. Сколько и за что клиент готов платить. Шаблон: «{Тариф / цена / способ оплаты} увеличит {средний чек / конверсию в оплату} на {X} %». Пример: «Оплата за каждый сверенный договор увеличит конверсию в оплату на 10 % по сравнению с фиксированной подпиской». Чем проверять: ценовой тест, предзаказ, «фальшивая дверь» — кнопка покупки тарифа, который ещё в разработке.

В B2B две гипотезы подтверждены заранее: бизнес хочет зарабатывать больше и тратить меньше.

Проверять стоит, как именно компания собирается это делать. Ответ лежит в KPI топ-менеджмента и в стратегии компании. Из них вырастают задачи сотрудников, а значит, и проблемы, за решение которых платят.

Деление на ценность и рост — главное, но есть ещё две полезные классификации.

Шесть областей Стива Бланка. Автор Customer Development в книге «Четыре шага к озарению» предлагает перед стартом записать гипотезы в шести областях:

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

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

Воронка AARRR. Гипотезы роста удобно раскладывать по этапам «пиратской» воронки AARRR Дейва Макклюра (2007). «Пиратской» её называют за звучание аббревиатуры — как пиратское «А-р-р-р!». Этапы:

• Acquisition — как пользователи нас находят;
• Activation — хорош ли первый опыт;
• Retention — возвращаются ли они;
• Referral — рекомендуют ли продукт другим;
• Revenue — как мы зарабатываем.

Каждый этап — отдельная метрика, а значит, отдельный поток гипотез, которые можно проверять параллельно.

Сильные гипотезы вырастают из фактов. Четыре главных источника:

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

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

• мозговой штурм и World Café — для большого числа идей за короткое время;
• «5 почему» и диаграмма Исикавы — для поиска корневой причины проблемы;
• дерево текущей реальности — для связи симптомов с причинами;
• майндмэппинг и метод ассоциаций — для выхода за пределы очевидного.

Хорошая сессия генерации даёт 20–50 гипотез разных типов. Дальше их нужно отобрать.

Порядок такой: бизнес-цель → цель исследования → вопросы → гипотезы → метод проверки.

Пример на том же сервисе сверки.

• Бизнес-цель — получить 20 платящих клиентов среди проектных компаний за полгода.
• Цель исследования — понять, какую проблему в учёте актов и оплат компании готовы решать за деньги.
• Вопросы — как сейчас устроена сверка, сколько она стоит компании, кто принимает решение о покупке.
• Гипотезы — гипотеза сегмента и гипотеза проблемы из примеров выше.
• Метод — проблемные интервью с финансовыми директорами и бухгалтерами, 6–8 на сегмент.

Короткая форма: «Если {делаем X}, то {метрика} изменится на {Y} за {срок}».

Хорошая гипотеза конкретная, измеримая, достижимая, связанная с целью и ограниченная по времени.

SMART защищает от пяти ловушек:

1. Придумали гипотезу, а провести проверку нечем.
2. Провели проверку без измеримого результата.
3. Получили результат, который уводит от цели.
4. Двигаемся к цели слишком медленно.
5. Проверили то, что и так очевидно.

Ещё одно свойство сильной гипотезы — простота: один тезис, одна метрика. Сложную гипотезу дробите на несколько.

Слева — формулировки, которые регулярно звучат на наших воркшопах. Справа — те же мысли в проверяемом виде. Цифры условные.

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

Три вида формулировок похожи на гипотезы, а по сути относятся к задачам.

• Очевидность. «Если спустимся по лестнице, окажемся на улице». Результат известен заранее.
• Проверенный факт. Команда давно прозванивает базу и знает свою конверсию. Продолжение прозвона — текущая работа.
• Желание. «Хотим поехать на форум в Сочи» становится гипотезой, когда появляется метрика: сколько встреч и сделок должна принести поездка.

«Гипотеза — это вопрос бизнесу и рынку».

Гипотез всегда больше, чем ресурсов. Выбирать помогают два инструмента.

RAT (Riskiest Assumption Test) — проверка допущения, ошибка в котором обнуляет весь продукт.

Обычно таких допущений четыре:

1. Есть достаточно большой сегмент с выраженной потребностью.
2. Мы можем создать продукт, который этот сегмент купит.
3. Юнит-экономика сходится даже в пессимистичном сценарии.
4. Проект даёт приемлемую окупаемость.

Задача RAT — попытаться провалить гипотезу, на которой держится продукт. Выдержала проверку — у продукта есть будущее.

Кейс. Основатель кикшеринга в Новой Москве проверял спрос по принципу «сначала продажи». Он договорился с владельцем проката, взял пять самокатов и поставил их у метро. Первая продажа случилась в первый же день. Запуск на 200 самокатов прошёл в следующем сезоне — после того как спрос подтвердился.

Оцените каждую гипотезу из бэклога по трём критериям от 1 до 10:

• Impact — насколько сильно гипотеза повлияет на ключевую метрику;
• Confidence — насколько вы уверены в своей оценке;
• Ease — насколько легко её проверить.

Итоговый балл — произведение или среднее трёх оценок. Выберите один способ и держитесь его.

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

Для большого бэклога подходит RICE: к трём критериям добавляется охват. Подробно — в нашем разборе приоритизации по модели RICE.

Формулируете гипотезу по шаблону. До старта фиксируете метрику, порог успеха и критерии «стоп / продолжаем».

Здесь же записываете план Б: что делаете, если гипотеза будет опровергнута.

Опишите, что делаете, кто отвечает и какие инструменты используете. Уложите действия в одну-две недели.

Самые быстрые способы проверки обходятся без разработки:

• лендинг и тестовая реклама;
• «фальшивая дверь»: кнопка будущей функции со счётчиком кликов;
• предзаказ;
• консьерж-сервис: команда вручную оказывает услугу, которую позже автоматизирует;
• ручные продажи и личные встречи;
• экспертные и пользовательские интервью;
• выступление на конференции и статья с лид-формой;
• «продажа конкурента»: команда предлагает клиенту решение ещё до того, как сделала свой продукт. Клиент готов купить — спрос подтверждён, а сделку передают конкуренту с готовым продуктом за комиссию.

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

Записывайте всё, включая то, что кажется очевидным. Через месяц анализировать можно только записанное.

Сравнивать результат можно двумя способами:

• с тем, что было: «как было — как стало»;
• с заранее заданным порогом: «гипотеза подтверждена, если конверсия достигнет X %». Порог фиксируется до старта, иначе проверка превращается в гадание на кофейной гуще.

В B2B метрики часто проектируют под задачу. Для системы управления инцидентами это время реакции и время восстановления сервиса. Для электронного документооборота — длительность цикла сделки и затраты на бумажный обмен. Для колл-центра — время ожидания клиента и доля потерянных звонков.

Ради этого шага затевается весь цикл.

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

Решений три: внедряем и масштабируем, переформулируем гипотезу, закрываем направление. Каждое решение получает ответственного, дату и метрику. Удобный формат: один инсайт — одно действие — одна метрика.

Внимательный разбор данных иногда приносит больше, чем исходная гипотеза. Препарат «Силденафил» компания Pfizer разрабатывала как средство от стенокардии. В клинических испытаниях исследователи зафиксировали неожиданный побочный эффект, сменили гипотезу — и в 1998 году на рынок вышла «Виагра».

Условный пример для онлайн-сервиса.

• H. Мы верим, что длинная регистрация отсеивает новых пользователей. Если сократить её с пяти шагов до двух, доля завершивших регистрацию вырастет на 25 % за две недели.
• A. Дизайнер собирает короткую форму, аналитик запускает A/B-тест на половине нового трафика. Срок — 14 дней.
• D. Доля завершивших регистрацию в обеих группах, число обращений в поддержку, полнота заполненных профилей.
• I. Рост на 25 % и выше — переводим всех на новую форму и берём следующую гипотезу: как короткий профиль влияет на активацию. Рост ниже порога — смотрим записи сессий и формулируем гипотезу о точке, где теряются пользователи.

С 2020 года мы ведём HADI-трекинг команд: акселераторы, корпоративные программы, программы Сколково и МФТИ, преакселератор Центрального университета. Рабочий инструмент — простая таблица.

Над таблицей — цель на период по SMART и стратегия её достижения. Столбцы — недели. Строки:

• H — какие гипотезы проверяем на этой неделе;
• A — что сделали, что подтвердили или опровергли;
• D — какие результаты получили: цифры и факты;
• I — инсайты и выводы;
• Запрос — какая помощь нужна от руководителя или трекера.

Типичная история первой недели: в строку H попадают задачи. «Определить критерии партнёра», «сделать срез конкурентов» — это работа, которая готовит гипотезу.

К третьей неделе формулировки взрослеют. Например: «Если у продавцов будет инструмент для мгновенных ответов на вопросы о клиенте, у них освободится два часа рабочего времени на продуктивные коммуникации». Такую гипотезу можно проверить и измерить.

По той же логике мы ведём HADI по собственному сайту. Гипотезы про реальные фотографии команды вместо иконок, видеоотзывы клиентов и навигацию по кейсам с тегами. Каждая строка связывает изменение с ценностью для клиента и с метрикой — числом заявок или временем на сайте.

Несколько гипотез на одну метрику дают смешанный результат: изменение видно, причина теряется. Поэтому правило простое: одна метрика — одна гипотеза за цикл.

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

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

Дальше три шага.

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

Эрик Рис называет такой поворот пивотом и описывает его виды. Самые частые:

• сегмент — продукт востребован другой аудиторией;
• проблема — найдена более острая проблема той же аудитории;
• канал — меняется путь продукта к клиенту;
• монетизация — меняется способ зарабатывать на ценности;
• zoom-in — одна функция становится самостоятельным продуктом;
• zoom-out — продукт становится частью более широкого решения.

Чем HADI отличается от Build — Measure — Learn и PDCA? Все три — циклы обучения через эксперимент. HADI ставит в центр гипотезу и вывод: в начале цикла фиксируется проверяемое предположение с метрикой, в конце — решение. Поэтому метод удобен для еженедельного ритма команды.

Сколько длится один цикл? Одну-две недели. Гипотезу, которая требует больше времени, стоит раздробить. В B2B с длинным циклом сделки измеряйте промежуточные метрики: встречу, пилот, согласование бюджета.

Подходит ли HADI для корпораций? Да, и там он особенно полезен: сокращает путь от исследования до решения. Помогают пилот за периметром, метрики под задачу и спонсор решения среди руководителей.

Где вести HADI? В таблице, трекере задач или базе знаний. Формат важнее инструмента: четыре поля, неделя, ответственный.

Как HADI связан с исследованиями? HADI задаёт рамку проверки, исследования её наполняют. Глубинные интервью дают гипотезы проблемы и ценности, продуктовая аналитика — гипотезы роста.

HADI-цикл превращает работу с гипотезами в управляемый процесс: гипотеза с метрикой, действие на одну-две недели, записанные данные и вывод с решением.

Чем быстрее команда проходит цикл, тем быстрее растёт бизнес.

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

В «Фабрике Гипотез» мы проверяем гипотезы ценности через глубинные интервью и рыночную аналитику, проводим воркшопы по генерации гипотез и трекинг HADI для корпоративных команд. Оставьте заявку — разберём, какую гипотезу вашего продукта проверить первой. Инсайты, фреймворки и чек-листы — в нашем телеграм-канале.