Почему я выбрал горизонт в 100 циклов

Когда я говорю, что нам нужно пройти 100 полных циклов проверки, закономерно возникает вопрос:

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

Внешне это может выглядеть как попытка отложить момент, когда продукт должен доказать свою самостоятельность.

Сначала основатель лично участвует во внедрении.

Потом говорит, что нужно повторить результат.

Потом вводит горизонт в 100 циклов.

Можно справедливо спросить: не превращается ли всё это в бесконечное исследование, после которого всегда можно сказать, что данных пока недостаточно?

Для меня 100 циклов - не способ избежать ответа.

Наоборот.

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

Один хороший результат слишком легко переоценить

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

Есть вовлечённый собственник.

Есть команда, готовая меняться.

Есть качественные данные.

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

Результат появляется.

Клиент доволен.

В этот момент очень хочется сказать:

Мы нашли ценность. Теперь нужно масштабировать.

Но один результат может объясняться множеством причин.

Возможно, сработал сам продукт.

Возможно, сработал мой опыт.

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

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

Возможно, гипотеза попала в редкую, но удачную ситуацию.

Возможно, показатель изменился временно из-за внимания руководителя.

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

Ни один из этих вариантов не обесценивает результат.

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

Я уже проходил эту ошибку в других задачах

Раньше я писал о том, почему цифры начинают говорить только после большого количества встреч.

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

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

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

Пятая меняет акценты.

Двадцатая показывает повторяющиеся вопросы.

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

Эту логику я подробно разбирал в статье «Когда цифры начинают говорить: 100 встреч».

Сейчас я переношу тот же принцип на создание продукта.

Встреча даёт наблюдение.

Полный цикл даёт проверку.

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

Что именно должен доказать один цикл

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

В нём должны быть:

1. Управленческая гипотеза.
2. Проверка на реальных коммуникациях.
3. Калибровка критерия.
4. Конкретное действие.
5. Реальное внедрение.
6. Период наблюдения.
7. Повторное измерение.
8. Корректировка вывода.

Именно поэтому цикл для меня важнее встречи.

На встрече можно очень убедительно объяснить идею.

В цикле приходится проверить, изменила ли она реальность.

Один цикл отвечает на вопрос:

Возможно ли создать такой результат в этой ситуации?

Много циклов отвечают на другой вопрос:

Какие элементы результата повторяются и при каких условиях?

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

Почему десяти циклов может быть недостаточно

После десяти циклов уже можно увидеть первые повторения.

Можно заметить, что руководителям трудно формулировать критерии.

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

Можно понять, что без калибровки доверие к оценке AI остаётся низким.

Можно выделить типовой порядок первой встречи.

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

Но десять циклов всё ещё могут быть слишком однородными.

Например:

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

В таком массиве легко принять локальную закономерность за универсальную.

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

Что я ожидаю увидеть к 100 циклам

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

Но к этому моменту должно стать существенно яснее несколько вещей.

Какие проблемы повторяются

Например:

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

Если один и тот же разрыв встречается снова и снова, это уже не особенность клиента.

Это работа, которую должен лучше выполнять наш продукт или стандартный процесс внедрения.

Какие этапы обязательны

Может оказаться, что без определённого шага результат практически не возникает.

Например:

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

Такие этапы нельзя оставлять случайными.

Они становятся частью методологии, onboarding и интерфейса.

Где находятся границы применимости

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

Одно действие может быть полезным для коротких B2C-продаж и бесполезным для длинного B2B-цикла.

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

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

Большой массив циклов должен показать не только то, что работает, но и где это перестаёт работать.

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

Что зависит от моей личности

Это один из самых неприятных, но важных вопросов.

Клиент может получать результат потому, что я:

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

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

У нас сильная founder-led услуга, усиленная платформой.

Поэтому через циклы мне нужно увидеть, какие мои действия можно:

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

Моя задача - не доказать, что я хорошо работаю с клиентами.

Моя задача - отделить метод от собственной личности.

Сто циклов не равны ста клиентам

Это две разные цели серии.

Первая цель - пройти 100 полных циклов проверки.

Вторая - дойти до 100 активных платящих клиентов.

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

Например, сначала мы проверяем фиксацию следующего шага.

Потом синхронизируем понимание критерия.

Затем проверяем резюме разговора.

После этого смотрим, сохраняется ли изменение без постоянного давления руководителя.

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

И наоборот, клиент может заплатить, подключиться и не пройти ни одного полного цикла.

Формально клиент есть.

Доказанной ценности нет.

Поэтому я не хочу смешивать коммерческую метрику с исследовательской.

100 циклов нужны, чтобы построить модель.

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

Почему число 100 не является научным законом

Я не утверждаю, что на девяносто девятом цикле мы ничего не знаем, а на сотом узнаём всё.

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

Число 100 для меня выполняет другую функцию.

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

Заставляет собирать разные контексты.

Создаёт дисциплину фиксации.

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

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

К этому моменту мы должны иметь не ощущения, а карту:

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

В этом смысле 100 - не магическая цифра, а управленческий контракт с собой и командой.

Нужно ли ждать 100 циклов перед любым делегированием

Нет.

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

Передавать нужно постепенно.

Как только отдельный блок повторяется, у него появляется:

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

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

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

Поэтому 100 циклов - горизонт доказательства общей модели.

А делегирование отдельных элементов начинается раньше.

Что нельзя передавать слишком рано

Есть части, где преждевременная передача особенно опасна.

Например:

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

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

Оба варианта маскируют отсутствие процесса.

Передавать нужно не внешнее действие, а способность воспроизводить заданный результат.

Что мы должны фиксировать, чтобы 100 циклов имели смысл

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

Поэтому по каждому циклу нужен единый минимальный набор данных:

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

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

Увидим, где мы сами повторяем одну ошибку.

Какие объяснения каждый раз приходится давать вручную.

Какие продуктовые задачи действительно повторяются.

Где мы переоцениваем причинность.

Что является обязательным условием результата.

Как я отличаю сильный паттерн от красивого наблюдения

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

Но для продукта этого недостаточно.

Паттерн становится сильнее, если:

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

Это не доказывает абсолютную причинность.

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

Почему провальные циклы особенно важны

Успешные кейсы легко любить.

Они дают энергию команде, материалы для продаж и подтверждение, что работа не напрасна.

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

Он показывает:

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

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

Поэтому в 100 циклов должны входить не только подтверждения.

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

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

Как этот горизонт связан с целью в 1 млрд рублей

Цель в 1 млрд рублей годовой выручки требует не отдельных героических продаж.

Она требует системы.

Система должна:

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

Сто циклов не приведут автоматически к миллиарду.

Но без них мы рискуем масштабировать недоказанную конструкцию.

Можно раньше времени нанять команду.

Запустить рекламу.

Поднять цену внедрения.

Добавить функции.

Получить несколько десятков клиентов.

А затем обнаружить, что результат держался на ручной работе, отдельных сильных руководителях и моём личном участии.

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

Как я пойму, что горизонт был пройден не зря

К моменту, когда накопится 100 завершённых циклов, я ожидаю увидеть следующее:

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

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

Мы просто много работали.

Поэтому цель не в том, чтобы досчитать до ста.

Цель - к каждому следующему циклу уменьшать объём неизвестности и увеличивать объём передаваемой системы.

Что я хочу, чтобы понимала команда

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

Каждый цикл должен быть видимым.

Команда должна понимать:

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

Иначе 100 циклов останутся моей личной насмотренностью.

А задача ровно противоположная.

Превратить личную насмотренность в общую систему.

Мой ответ на вопрос «почему так долго»

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

Не хочу автоматизировать первую убедительную гипотезу.

Не хочу выдавать способность основателя вручную создавать пользу за повторяемость продукта.

И не хочу ждать идеальной уверенности до бесконечности.

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

Сто полных циклов.

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

Достаточно конкретно, чтобы команда могла считать прогресс.

Достаточно жёстко, чтобы после этого нельзя было продолжать объяснять всё ранней стадией.

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