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

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

Почему ты как основатель сам проводишь столько встреч, разбираешь клиентские данные, участвуешь во внедрении и объясняешь руководителям, как использовать продукт? Разве это не должен делать сотрудник? Разве это не консалтинг вместо SaaS?

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

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

Наша цель - не заработать на внедрении

Долгосрочная цель продукта - 1 млрд рублей годовой выручки. К такой цели нельзя прийти за счёт того, что мы сто раз возьмём с клиента по 50 тысяч рублей за внедрение. Это может дать разовую выручку. Но не создаст большую компанию.

Большая компания появляется тогда, когда найден повторяемый механизм:

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

Поэтому на текущем этапе я оптимизирую работу не под максимальную разовую оплату. Я оптимизирую её под скорость поиска повторяемой модели ценности.

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

Почему сложный B2B SaaS нельзя просто отдать клиенту

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

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

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

Поэтому для нас недостаточно просто дать клиенту доступ и показать интерфейс. Самостоятельное нажатие кнопок ещё не означает создание управленческой ценности.

Сначала мы должны доказать, что весь путь работает:

данные -> гипотеза -> критерий -> калибровка -> действие -> изменение поведения -> повторное измерение.

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

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

Что я на самом деле делаю с клиентами

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

Мы движемся по стандартному исследовательскому циклу:

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

Меняется контекст бизнеса. Но базовая логика исследования остаётся одной и той же.

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

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

Один успешный клиент ничего не доказывает

Мы уже проходили это в другой части работы.

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

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

Поэтому я опираюсь на ту же логику, о которой писал раньше в статье «Когда цифры начинают говорить: 100 встреч».

Чтобы увидеть повторяемость, нужен не один эпизод, а серия циклов. Для себя я зафиксировал ориентир: 100 полных циклов проверки.

Один цикл выглядит так:

1. Есть управленческая гипотеза.
2. Она проверяется на реальных коммуникациях.
3. Выбирается конкретное изменение.
4. Изменение внедряется.
5. Результат измеряется повторно.
6. Вывод подтверждается, уточняется или отбрасывается.

Только после достаточного количества таких циклов становится видно:

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

Число 100 здесь не магическая константа. Это дисциплина. Способ не объявить первую красивую гипотезу готовой моделью.

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

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

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

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

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

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

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

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

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

Когда начнётся делегирование

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

Для этого должно быть понятно:

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

После этого другой сотрудник проходит процесс на реальном клиенте. Не читает инструкцию. Не пересказывает методологию. А воспроизводит результат.

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

Следующий шаг после делегирования - перенос повторяемых элементов в продукт:

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

Но порядок именно такой в стартапе, где ограниченные ресурсы:

сначала сделать самому -> повторить -> понять -> описать -> передать -> проверить -> автоматизировать.

Не наоборот.

Где действительно проходит граница между продуктом и консалтингом

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

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

Для меня граница проходит по накопительному результату. После каждого клиентского цикла должно становиться яснее:

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

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

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

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

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

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

Основатель опять всё сделал за клиента.

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

После каждого цикла команда должна видеть:

1. Какую гипотезу мы проверяли.
2. Что показали данные.
3. Какое действие выбрали.
4. Что произошло после внедрения.
5. Как изменилось наше понимание.
6. Что стало частью методологии.
7. Что попало в продукт.
8. Что пока остаётся на основателе.
9. Какой следующий цикл нужен.

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

Что я отвечаю внешним экспертам

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

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

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

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

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

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

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

И только после этого превращать его в систему, которая способна дойти до 100 активных платящих клиентов и дальше - к компании с выручкой 1 млрд рублей в год.

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