Гипотезы
Всё, что вы вписали в Lean Canvas и Value Proposition Canvas в модуле 1 — не факты. Это пучок предположений, которые кажутся очевидными, пока вы их не проверили. Этот модуль — о том, как превратить предположения в проверяемые гипотезы и решить, какую проверять первой.
Урок 1: Как формулировать гипотезу, которую можно опровергнуть
«Людям нужен удобный инструмент» — не гипотеза. Это вера. У веры нет способа оказаться неверной — а значит, её нельзя проверить, только обсудить.
Гипотеза отличается одним: у неё есть способ провалиться. Стандартный шаблон, который заставляет писать честно:
Мы верим, что [действие/фича] для [сегмент] приведёт к [измеримый результат]. Мы поймём, что правы, если увидим [конкретный сигнал/метрика].
«Люди хотят удобства» не проходит через этот шаблон никак — непонятно, какой сигнал докажет или опровергнет. «30% пользователей, которые увидят кнопку «book a call», нажмут её в течение недели» — проходит. Разница не в оптимизме, а в том, что вторая фраза заранее говорит, что считать победой, а что — проигрышем.
Откуда брать гипотезы: каждый блок Lean Canvas и каждая ячейка Value Proposition Canvas из модуля 1 — это связка непроверенных утверждений. Вы не придумываете гипотезы заново — вы переформулируете то, что уже написали, в проверяемую форму. Но источников для новых гипотез больше, чем два канваса:
| Источник | Что даёт |
|---|---|
| Пользователи и интервью | Самый богатый источник — но каждую идею всё равно нужно проверять отдельно, а не верить на слово |
| Конкуренты | Наблюдать и проверять на своей аудитории, не копировать вслепую — то, что взлетело у них, не обязано взлететь у вас |
| Аналитика и данные | Поведение пользователей иногда говорит больше, чем их слова в интервью |
| Команда и коллеги | Свежий взгляд со стороны от тех, кто не пользуется продуктом каждый день |
| Смежные отрасли | Решение, которое работает в другой нише, можно адаптировать под свой продукт |
| Озарение | Годится как источник идеи, но не как замена проверке — даже отличная на вид идея остаётся гипотезой, а не фактом |
HADI-цикл: как гипотеза превращается в решение
Сформулировать гипотезу — только первый шаг. Дальше она проходит четыре стадии по кругу — цикл замыкается сам на себя, потому что выводы последней стадии почти всегда рождают следующую гипотезу:
| Буква | Стадия | Что происходит |
|---|---|---|
| H | Hypothesis — гипотеза | Формулируете по шаблону выше |
| A | Action — действие | Вносите конкретное изменение в продукт или процесс |
| D | Data — данные | Собираете цифры за заранее оговорённый период |
| I | Insights — выводы | Сравниваете цифры с тем сигналом, что определили в гипотезе, и решаете: подтвердилась или нет |
HADI для мастерской Насти. H: если добавить на карточку в Яндекс.Картах фото трёх последних работ, доля заявок с этого канала вырастет с 5% до 15% за месяц. A: Настя загрузила фото и обновила описание карточки. D: через месяц заявки с карточки выросли с 5% до 9% от общего числа. I: гипотеза подтвердилась частично — рост есть, но не такой, как ожидали; следующая гипотеза — добавить в карточку цены «от», раз одних фото оказалось недостаточно.
Важная деталь цикла: даже если гипотеза не подтвердилась (I показывает «нет роста»), это тоже результат, а не провал — вы честно закрыли вопрос и не будете возвращаться к нему на ощущениях.
Самопроверка: почему «гипотеза не подтвердилась» на стадии Insights — это тоже полезный результат, а не потерянное время?
Потому что до эксперимента это был открытый вопрос, на который вы тратили бы силы снова и снова, полагаясь на ощущения. После HADI-цикла вопрос закрыт данными — вы точно знаете, что этот путь не работает, и можете направить время на следующую гипотезу, а не спорить о том же самом.
Самопроверка: почему «пользователям понравится новая функция» — плохая гипотеза, даже если вы в неё верите?
Нет сигнала, по которому можно понять, что гипотеза не подтвердилась. «Понравится» — любой результат можно задним числом объявить победой.
Задание: возьмите три предположения из вашего Lean Canvas или Value Proposition Canvas и перепишите каждое по шаблону выше, с конкретным измеримым сигналом правоты/неправоты. Для одной из них распишите полный HADI: что именно сделаете (A), какие данные соберёте (D) и через какой срок.
Урок 2: Приоритизация гипотез — ICE и RICE
Времени не хватит проверить всё сразу. Нужен способ решить, что проверять первым — не по настроению, а по цифрам.
ICE — каждую гипотезу оцениваете от 1 до 10 по трём осям:
| Ось | Вопрос |
|---|---|
| Impact (влияние) | Насколько сильно это повлияет на цель, если гипотеза подтвердится? |
| Confidence (уверенность) | Насколько есть реальных данных (а не ощущений), что это правда? |
| Ease (лёгкость) | Насколько быстро и дёшево это проверить? |
Скор = среднее трёх чисел. Выше скор — проверяете раньше.
RICE — то же самое, но точнее: добавляется Reach (сколько людей затронет за период), а Ease заменяется на Effort (человеко-часы) — и ставится в знаменатель, не умножается:
RICE = (Reach × Impact × Confidence) / Effort
Effort в знаменателе, потому что большая трудозатратность должна снижать приоритет, а не просто входить в общий счёт. ICE быстрее и грубее — хорош для соло-разработки за выходные. RICE нужен, когда есть реальные данные об аудитории и цена ошибки высока.
Главная ловушка: путать Confidence с личной убеждённостью. Если вы верите в гипотезу, но не говорили ни с одним человеком из целевой аудитории — Confidence не выше 3. Реальные данные для этой оценки даёт только модуль про исследования — следующий.
Пример:
| Гипотеза | Impact | Confidence | Ease | ICE |
|---|---|---|---|---|
| Добавить напоминания — снизит отток | 7 | 4 | 9 | 6.7 |
| Сделать платную подписку — люди заплатят | 9 | 3 | 5 | 5.7 |
Первая гипотеза выигрывает не потому, что она важнее — а потому что дешевле проверить и вы увереннее в ней.
Самопроверка: почему в RICE Effort ставится в знаменатель, а не умножается с остальными?
Потому что большая трудозатратность должна СНИЖАТЬ приоритет, а не просто учитываться наравне с пользой. Деление делает именно это: чем больше Effort в знаменателе, тем ниже итоговый скор, даже при высоком Impact.
Задание: возьмите гипотезы из задания урока 1 и оцените каждую по ICE. Составьте таблицу как в примере выше, отсортируйте по скору и обведите ту, что будете проверять первой. Если лидер оказался тем, что вам меньше всего нравилось — это нормально, цифры для того и считают, чтобы обходить личные предпочтения.
Урок 3: A/B-тест — как проверить гипотезу на практике
Гипотезу можно проверить интервью, MVP или прямым наблюдением — но когда речь о выборе между двумя вариантами (заголовок, кнопка, цена), самый честный способ — A/B-тест: одной части аудитории показываете вариант A, другой — вариант B, и сравниваете результат.
Алгоритм простой на бумаге: 1) сформулировать гипотезу по шаблону из урока 1 → 2) провести тест → 3) проанализировать результат. Ловушка — в шаге 3: без понимания размера выборки легко принять случайный шум за победу.
Реальный кейс с самой высокой ставкой: предвыборный сайт Обамы, 2008. Команда digital-аналитики тестировала не что-то мелкое, а саму форму на главной странице — какая кнопка и какая картинка лучше всего конвертируют посетителя в подписчика рассылки. Проверили 4 варианта текста кнопки и 6 вариантов медиа (24 комбинации). Победила простая замена: кнопка «Learn More» вместо привычной «Sign Up Now» подняла конверсию с 8.26% до 11.6% — на 40.6% относительно. Разница в 3.3 процентных пункта на многомиллионной аудитории превратилась в 2.88 млн дополнительных email-адресов, а те — в порядка $60 млн дополнительных пожертвований. Показательно не число, а то, что победила самая нескромная на вид гипотеза: команда до теста была уверена, что выиграет эмоциональное видео с речью кандидата, а не скучный текст на кнопке.
Самопроверка: почему в кейсе Обамы именно 3.3 процентных пункта разницы превратились в такие большие деньги, хотя в других случаях такая же разница может быть незаметна?
Потому что эффект A/B-теста всегда умножается на размер аудитории. На форме с 50 посетителями в день 3.3 п.п. — это заметить почти невозможно, эффект потеряется в шуме. На форме с миллионами посетителей та же самая относительная разница даёт огромный абсолютный результат. Именно поэтому расчёт выборки из этого урока настолько важен: без него нельзя понять, увидите ли вы вообще эффект такого масштаба на своём реальном трафике.
Сколько нужно людей, чтобы результату можно было верить
n = 16 × p × (1 − p) / δ²
Где p — текущая конверсия, δ — минимальный прирост, который вы хотите обнаружить, n — нужное число участников в каждой группе.
Пример для сайта Насти. Сейчас 4% посетителей сайта нажимают кнопку «Записаться» (p = 0.04). Настя хочет проверить, поднимет ли крупная цветная кнопка конверсию минимум на 1.5 процентных пункта (δ = 0.015). Считаем: n = 16 × 0.04 × 0.96 / 0.015² = 0.6144 / 0.000225 ≈ 2731 человек в каждой группе. Если у сайта 50 посетителей в день, тест займёт больше двух месяцев — и тут становится ясно, почему для маленького трафика A/B-тест часто не лучший инструмент проверки.
Самая частая ошибка — остановить тест раньше, чем набралась нужная выборка, потому что «уже видно, какой вариант лучше». На малой выборке разница почти всегда объясняется случайностью, а не реальным эффектом.
Кроме классического A/B, есть смежные форматы: A/A-тест — показываете одинаковый вариант двум группам, чтобы проверить, что деление трафика вообще однородное (полезно как проверка перед настоящим A/B); A/A/B-тест — совмещает обе проверки сразу; тест с контрольной группой — когда часть аудитории вообще не видит изменение, что помогает отличить эффект от сезонности.
Самопроверка: почему нельзя останавливать A/B-тест сразу, как только один вариант вырвался вперёд?
Потому что на малой выборке разница между вариантами почти всегда объясняется случайными колебаниями, а не реальным эффектом. Формула расчёта выборки как раз и определяет, сколько наблюдений нужно, чтобы отличить настоящий эффект от шума — остановка раньше этого числа означает, что вы, скорее всего, делаете вывод по случайности.
Практика: у Насти всего 50 посетителей сайта в день, а расчёт по формуле требует 2731 человека в группу. Что ей делать — не проверять гипотезу вообще?
Не обязательно A/B-тест — при таком трафике его пришлось бы гонять больше двух месяцев на группу, теряя время. Альтернативы: MVP-подход из модуля 1 (например, «имитация сервера» — показать кнопку и вручную обработать первые заявки), интервью с реальными клиентками про удобство записи, или наблюдение за поведением небольшой группы вживую. A/B-тест — не единственный способ проверки, а один из них, и подходит не при любом объёме трафика.
Задание: возьмите гипотезу из своего ICE-списка, которую в принципе можно проверить A/B-тестом. Оцените вашу текущую конверсию (p) и минимальный прирост, который хотите обнаружить (δ), и посчитайте нужный размер выборки по формуле выше. Если цифра оказалась нереалистичной при вашем трафике — выберите другой способ проверки той же гипотезы.
Урок 4: Бэклог — куда складывать гипотезы, которые пока не в работе
Проверить больше 2-3 гипотез в месяц редко получается даже у команды — а гипотез всегда больше. Нужен упорядоченный список — бэклог — и способ время от времени пересматривать приоритеты. Бэклог без ответственного человека и без регулярного пересмотра «умирает»: им просто перестают пользоваться, потому что список расходится с реальностью.
ICE и RICE из урока 2 — не единственные способы расставить приоритеты. Два простых дополнения на случай, когда числовой скоринг неудобен:
MoSCoW — делит гипотезы и фичи на 4 группы:
| Группа | Значение |
|---|---|
| Must have | Без этого продукт не работает |
| Should have | Важно, но не критично прямо сейчас — со временем станет Must |
| Could have | Сделаем, если останутся время и ресурсы |
| Won't have | Не в этом релизе — возможно, в следующем |
MoSCoW для сайта записи Насти. Must have: форма онлайн-записи с выбором даты. Should have: SMS-напоминание о визите за день. Could have: выбор конкретного мастера, если их станет больше одного. Won't have: программа лояльности с баллами — красиво, но не сейчас.
Модель Кано — иначе смотрит на то же самое, через ожидания клиента:
| Категория | Как ведёт себя клиент |
|---|---|
| Основные | Считает само собой разумеющимся — не радуется, если есть, но сильно недоволен, если нет |
| Необходимые | Прямо ожидает — есть, значит доволен, нет — недоволен |
| Восхищающие | Не ждёт вообще — если появляется, вызывает восторг; если нет, никто не заметит |
Для мастерской: основное — то, что мастер вообще приезжает на замер; необходимое — SMS-напоминание; восхищающее — если Настя вместе с замером сразу предложит бесплатный совет по подбору цвета, которого клиентка не просила.
MoSCoW и Кано удобны, пока гипотез не больше 10-15 и решение принимаете вы один. Если гипотез становится больше — возвращайтесь к числовому скорингу ICE/RICE из урока 2: с цифрами меньше пространства для бесконечных споров о том, что «важнее».
Самопроверка: чем модель Кано отличается от MoSCoW по сути вопроса, который она задаёт?
MoSCoW спрашивает «насколько это критично для релиза» — вопрос про приоритет. Кано спрашивает «как отреагирует клиент, если это увидит или не увидит» — вопрос про ожидания. Одна и та же фича может быть Must have по MoSCoW и одновременно «основной» по Кано — категории отвечают на разные вопросы, а не заменяют друг друга.
Задание: возьмите список функций или гипотез для своего продукта и распределите их по MoSCoW. Затем для трёх самых спорных — тех, где не очевидно Must это или Should — прогоните через модель Кано: как отреагирует клиент, если функции не будет вообще?
У вас есть ранжированный список гипотез, понимание, что проверять первым, и представление о том, как проверить это A/B-тестом, если трафик позволяет. Следующий модуль — как реально проверить гипотезу другими способами: качественные и количественные исследования и Customer Development.