Я начинаю продуктовый эксперимент с ограничения, которое готов принять клиент

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

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

Ограничение — это не недостаток эксперимента

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

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

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

Что именно стоит ограничить

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

• Аудитория. Не все клиенты, а одна группа с похожей задачей.
• Сценарий. Не весь путь заказа, а момент, где сотрудник делает решение.
• Ответственность. Система готовит вариант, а человек подтверждает его.
• Срок. Проверяем не «когда-нибудь», а в течение двух рабочих недель.
• Последствие ошибки. Не затрагиваем деньги, обязательства или критичные данные, пока не убедились в самом сценарии.

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

Сначала вопрос, потом макет

Полезный вопрос звучит конкретно: «Согласится ли руководитель отдела продаж использовать готовый черновик предложения, если финальную цену пока проверяет специалист?» В нём есть человек, действие и условие.

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

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

Как выглядит честная первая версия

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

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

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

Какие сигналы я считаю важными

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

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

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

Не путать ограничение с экономией на качестве

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

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

Четыре вопроса перед стартом

1. Какое решение мы сможем принять после этой проверки?
2. Что намеренно не делаем в первой версии?
3. Кто и в какой момент заметит, что новый сценарий не помогает?
4. Как вернёмся к привычному порядку, если проверка остановится?

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

Вместо большого обещания

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

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