Что я считаю полным циклом проверки гипотезы

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

Следующий вопрос неизбежен:

Хорошо, а как ты вообще понимаешь, что гипотеза проверена и работа завершена?

Этот вопрос важнее, чем кажется.

Потому что в стартапе очень легко считать прогрессом активность.

Мы провели встречу.

Разобрали данные.

Нашли интересный сигнал.

Сделали отчёт.

Обсудили его с клиентом.

Клиент согласился.

Команда получила задачу.

В календаре всё выглядит как большая проделанная работа.

Но ни один из этих пунктов сам по себе ещё не доказывает, что продукт создал ценность.

Для себя я фиксирую более жёсткое правило:

Полный цикл проверки гипотезы заканчивается не отчётом и не решением. Он заканчивается повторным измерением после реального изменения.

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

Почему встреча создаёт ощущение завершённости

Встреча психологически очень удобна.

До неё была неопределённость.

Во время разговора появились цифры, объяснения, гипотезы и решение.

К концу участники договорились, что делать дальше.

Возникает ощущение ясности.

Это полезный результат, но он промежуточный.

На встрече мы проверили только несколько вещей:

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

Мы ещё не проверили главное:

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

Поэтому встреча может завершить обсуждение.

Но не цикл.

Почему отчёт тоже ничего не доказывает сам по себе

Отчёт может быть технически корректным.

В нём могут быть:

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

Но отчёт показывает прошлое.

Он отвечает на вопрос:

Что происходило до того, как мы решили что-то изменить?

Это важная половина работы.

Без неё мы действуем вслепую.

Но сам отчёт не отвечает на вопрос:

Что изменилось после нашего решения?

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

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

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

Поэтому я не хочу считать количество подготовленных отчётов главным показателем прогресса.

Мне важнее количество завершённых циклов.

Где начинается один цикл

Один цикл начинается не с загрузки данных и не с открытия отчёта.

Он начинается с управленческой гипотезы.

Гипотеза - это не общий вопрос вроде:

Что у нас не так с продажами?

И не техническая задача:

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

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

Например:

Возможно, сделки зависают после отправки расчёта, потому что менеджер не фиксирует следующий контакт.

Или:

Возможно, сотрудники считают, что назначили следующий шаг, хотя клиент и менеджер не договорились о конкретном времени или действии.

Или:

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

Гипотеза не обязана оказаться верной.

Она должна быть проверяемой.

То есть мы должны заранее понимать:

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

Без этого у нас не цикл, а исследование без границ.

Моя структура полного цикла

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

1. Зафиксирована управленческая гипотеза

Мы формулируем, что именно хотим проверить и почему это важно.

Не «посмотреть звонки».

Не «проверить менеджеров».

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

Например:

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

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

Это только версия.

2. Гипотеза проверена на реальных коммуникациях

Мы смотрим не отдельный удачный или провальный звонок, а массив данных.

Проверяем:

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

Именно на этом этапе часто выясняется, что первоначальный вопрос был поставлен неверно.

Это не провал.

Это полезный результат исследования.

Иногда главный вывод первой проверки звучит так:

Мы пока измеряли не то.

3. Критерий откалиброван с руководителем

Даже хорошая гипотеза ничего не значит, если участники по-разному понимают критерий.

Например, фраза «следующий шаг назначен» может означать:

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

Для одного руководителя всё это считается выполнением.

Для другого - только конкретная договорённость.

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

Без калибровки цифра может быть точной технически, но бесполезной управленчески.

4. Выбрано одно конкретное действие

После анализа возникает искушение сразу изменить всё.

Переписать скрипт.

Провести обучение.

Добавить несколько критериев.

Изменить отчёт.

Внедрить новые правила.

Попросить менеджеров изучить конкурентов.

Но если мы меняем сразу десять элементов, то при следующем измерении не поймём, что именно повлияло на результат.

Поэтому в одном цикле должно быть выделено основное действие.

Например:

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

Дополнительные наблюдения можно сохранить.

Но основной цикл должен иметь один понятный фокус.

5. Изменение реально передано в работу

Решение на встрече ещё не означает внедрение.

Нужно проверить:

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

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

Этот разрыв часто и есть главная причина, почему правильная идея не создаёт результата.

6. Прошёл достаточный период наблюдения

Повторное измерение нельзя делать в произвольный момент.

Если посмотреть слишком рано, команда может ещё не успеть внедрить изменение.

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

Период зависит от:

• количества коммуникаций;
• длины цикла сделки;
• частоты нужного действия;
• размера команды;
• сложности изменения;
• объёма данных.

Для одного критерия достаточно недели.

Для другого нужен месяц.

Для длинного B2B-цикла потребуется больше времени.

Главное - определить период до того, как мы увидим результат и захотим подстроить правило под удобный вывод.

7. Проведено повторное измерение и скорректирован вывод

Это последний обязательный этап.

Мы возвращаемся к тем же данным и проверяем:

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

Только после этого цикл завершён.

Не обязательно успешно.

Но завершён.

Завершённый цикл не обязан подтвердить гипотезу

Это принципиально важно.

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

Он мог показать:

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

Завершённый неуспешный цикл лучше незавершённого успешного впечатления.

Потому что он снижает неопределённость.

Мы понимаем, чего не нужно масштабировать.

Для разработки продукта это полноценный результат.

Как выглядит незавершённый цикл

Цикл нельзя считать завершённым, если:

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

Такие случаи важны.

Но в счёт 100 полных циклов я бы их не включал.

Иначе мы быстро наберём красивое число и не получим повторяемую модель.

Один клиент может пройти несколько циклов

Сто циклов не означают сто клиентов.

Одна компания может пройти несколько последовательных проверок.

Например:

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

Это четыре разных цикла.

У каждого своя гипотеза, действие и повторное измерение.

При этом нельзя искусственно дробить одну работу на множество мелких циклов ради статистики.

Единица должна оставаться управленчески значимой.

То есть результат цикла должен менять хотя бы одно из следующего:

• понимание клиента;
• поведение команды;
• методологию;
• сценарий внедрения;
• интерфейс;
• ограничения продукта;
• решение о следующем этапе.

Что мы должны фиксировать по каждому циклу

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

Нужен короткий паспорт цикла.

Минимально в нём должны быть:

1. Клиентский контекст.
2. Управленческая гипотеза.
3. Исходные данные.
4. Критерий и его версия.
5. Результат первичного измерения.
6. Выбранное действие.
7. Кто внедрял изменение.
8. Период наблюдения.
9. Результат повторного измерения.
10. Итог: подтверждено, опровергнуто, уточнено или не завершено.
11. Что изменилось в методологии.
12. Что изменилось в продукте.
13. Что можно передать сотруднику.
14. Какой следующий цикл нужен.

Такая фиксация важна не ради отчётности.

Она помогает отделить реальную повторяемость от моего ощущения, что «это мы уже видели».

Как цикл превращается в продуктовую разработку

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

Например, в нескольких циклах повторяется одно и то же:

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

Тогда появляются продуктовые задачи:

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

В backlog должна попадать не просьба конкретного клиента.

Туда должна попадать повторяемая работа, которую продукт пока выполняет недостаточно хорошо.

Как цикл помогает понять, что пора делегировать

Один из главных результатов серии циклов - границы процесса.

Через повторения становится видно:

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

После этого часть процесса можно передавать.

Например:

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

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

Так делегирование начинается не по календарю и не по количеству сотрудников.

Оно начинается по мере накопления завершённых циклов.

Как я оцениваю прогресс продукта

Я не хочу оценивать ранний продукт только по числу функций.

Функции можно выпускать быстро.

Но они не обязательно приближают нас к повторяемой ценности.

На текущем этапе для меня важнее:

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

Это более честная картина развития сложного B2B SaaS.

Почему нам нужны 100 циклов

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

Несколько циклов показывают, что он может повторяться.

Десятки циклов начинают показывать:

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

Поэтому следующий горизонт для нас - не просто провести больше встреч.

Нам нужно пройти 100 полноценных циклов проверки.

Не ради красивой цифры.

А чтобы к моменту масштабирования мы понимали, что именно собираемся повторять.

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