Я проверяю продуктовую гипотезу не интересом на встрече, а готовностью изменить привычный рабочий шаг
Интерес к идее на встрече — слабое доказательство. Человек может искренне кивнуть, назвать решение полезным и на следующий день вернуться к старому файлу, чату и привычной таблице. Поэтому продуктовую гипотезу я проверяю не вопросом «нравится ли вам», а вопросом «готовы ли вы изменить один конкретный рабочий шаг».
Это особенно важно в B2B. Здесь продукт редко покупают ради самого интерфейса. Его впускают в уже занятую жизнь: в цепочку согласований, ответственность за деньги, привычки отдела и сроки клиентов. Если новый путь не становится легче старого в нужный момент, красивое демо ничего не меняет. Похожий критерий важен и для самостоятельного пути клиента в SaaS.
Почему интерес ещё не означает спрос
Представим руководителя продаж. Он говорит, что ему очень нужен экран с прогнозом сделок. На встрече это звучит убедительно: цифры важны, старые отчёты долго собирать, команда растёт. Но полезная гипотеза начинается только дальше: какую именно встречу он перестанет проводить по старому шаблону? Какое решение примет раньше? Какая информация будет заполнена иначе?
Если ответ остаётся общим — «будем видеть картину», — перед нами пока желание, а не проверяемая задача. Такой запрос легко превратить в дорогой дашборд, который открывают перед планёркой и забывают до следующего понедельника.
Рабочая гипотеза звучит приземлённее. Например: «Перед еженедельной встречей руководитель выбирает пять сделок с риском из одного списка, а менеджер видит, какой следующий шаг нужно зафиксировать». Здесь уже есть человек, момент, действие и наблюдаемый результат. С этим можно работать.
Начинаю с одного шага, а не с полной схемы
Когда команда описывает процесс целиком, на доске быстро появляется полсотни стрелок. Это полезно для понимания контекста, но плохо для первой проверки. Большая схема позволяет спорить о будущем слишком долго.
Я выбираю один шаг, который одновременно отвечает трём условиям:
- он повторяется достаточно часто, чтобы результат было видно быстро;
- в нём есть цена ошибки, задержки или ручного труда;
- человек, который его делает, может попробовать новый путь без того, чтобы вся компания остановилась.
В учёте это может быть сверка статуса заказа до отгрузки. В SaaS — назначение ответственного за обращение клиента. В производстве — передача отклонения мастеру смены. Суть не в отрасли: мы не проверяем любовь к новой функции, мы проверяем изменение привычного действия.
Иногда такой шаг кажется слишком маленьким. Но именно на нём видны вещи, которые презентация скрывает: кто даёт исходные данные, что происходит при исключении, где пользователь теряет контекст и кому придётся отвечать, если решение окажется неверным.
Вопросы, которые отрезвляют идею
Перед разработкой я стараюсь получить короткие ответы на пять вопросов.
- Кто меняет действие? Не «отдел продаж», а конкретная роль: менеджер, диспетчер, бухгалтер, руководитель группы.
- В какой момент? Не «при работе с заказом», а после оплаты, перед выпуском в производство, на утренней планёрке.
- Что он делает сейчас? Нужно увидеть старый путь без украшений: звонок, Excel, заметка в мессенджере, память одного сотрудника.
- Что станет другим? Одно решение принимается быстрее, одна передача не теряется, один риск становится заметным раньше.
- По чему мы поймём, что не сработало? Если никто не использует новый путь, просит вернуть старый обход или не может объяснить, что делать при нестандартной ситуации, это тоже результат.
Последний вопрос часто неудобен. Он лишает команду возможности назвать успехом сам факт релиза. Но без заранее согласованного признака неудачи функция живёт в тумане: её не закрывают, не улучшают и не убирают.
Не путать активность с изменением работы
После запуска первой версии хочется смотреть на всё, что легко посчитать: сколько раз открыли экран, сколько нажали кнопок, сколько пользователей вошло в систему. Эти цифры могут быть полезны для диагностики, но сами по себе не доказывают ценность. Экран могут открывать потому, что он стоит на видном месте. Кнопку могут нажимать несколько раз, потому что непонятно, сработала ли она.
Я ищу признак в самом рабочем действии. Стала ли передача задачи короче без потери смысла? Перестал ли руководитель собирать данные вручную перед решением? Может ли сотрудник продолжить работу после типовой ошибки? Важно не обязательно ускорение. Иногда главный результат — меньше риск принять решение по устаревшей информации.
Для этого полезно сравнить несколько реальных случаев до и после. Не рисовать точность там, где её нет, а посмотреть на характер изменений. Если новый путь экономит пять минут, но заставляет трижды уточнять ответственного, он не стал лучше. Если путь занимает столько же, но оставляет понятную историю и снимает один ежедневный звонок, его ценность может быть выше.
Такой разговор помогает и с ожиданиями руководителя. Вместо обещания «функция повысит эффективность» появляется проверяемая договорённость: через две недели посмотрим, пользуются ли ей в конкретном моменте, какие исключения всплыли и какое решение примем дальше.
Договориться, кто принимает вывод
У теста должен быть не только исполнитель, но и человек, который готов принять вывод. Иначе команда собирает заметки, делает скриншоты, а затем спорит, достаточно ли данных. Обычно это тот, кто отвечает за процесс или продуктовый результат. Его задача не доказать собственную правоту, а вместе с командой выбрать один из трёх честных вариантов: развивать сценарий, изменить его или остановить.
Полезно зафиксировать это до начала работы одной фразой. Например: «Если после трёх недель менеджеры сами выбирают новый список на планёрке и в нём не теряются сделки, расширяем доступ; если нет — разбираем причину до следующей разработки». Такая договорённость снимает ложную драму с отрицательного результата. Остановка становится частью управления, а не чьим-то поражением.
Я также стараюсь не делать из ранней проверки голосование. Самый активный пользователь может хотеть новую функцию, а самый громкий скептик — защищать привычный порядок. Их мнение важно, но решающим остаётся наблюдение за конкретным действием и его последствиями для работы.
Хорошая гипотеза оставляет после себя больше, чем решение «делать» или «не делать». Она уточняет язык команды. После такого теста становится понятнее, что означает «готовый заказ», когда задача действительно передана, какой риск бизнес готов принять и какие данные нужны для решения. Даже если функция не выходит в продукт, это знание не пропадает.
Нужен не опрос, а наблюдение за работой
Слова пользователя важны, но я не ставлю их выше того, как устроен рабочий день. Люди разумно описывают желаемый результат, однако редко замечают собственные обходы. Менеджер может сказать, что карточка клиента заполнена, а потом найти старое условие в личной переписке. Руководитель может попросить автоматический отчёт, а на самом деле ему не хватает права остановить сомнительную операцию.
Поэтому для проверки полезнее попросить показать последний реальный случай. Не «как обычно проходит согласование», а «откройте вчерашнюю заявку, которая задержалась». В одном таком разборе часто видно, какие поля не нужны, где пропадает ответственность и почему правило пока существует только в голове опытного сотрудника.
Это не повод автоматизировать всё увиденное. Наоборот, наблюдение помогает выбрать границу. Иногда система должна взять на себя расчёт или контроль срока. Иногда ей достаточно сохранить контекст, а решение оставить человеку. Хорошая автоматизация не делает процесс безлюдным; она освобождает внимание для действительно спорных случаев.
Как выглядит честный первый тест
Первый тест не обязан быть полноценной разработкой. Если гипотеза про порядок выбора заявок, можно начать с простого списка и правила сортировки. Если нужно проверить новую передачу между ролями, иногда хватает прототипа и нескольких реальных задач. Важно, чтобы тест касался настоящей работы, а не проходил только в демонстрационной базе.
Я заранее ограничиваю эксперимент: для каких клиентов или задач он работает, сколько длится, кто собирает замечания и что станет решением по итогам. Это защищает команду от бесконечного «давайте ещё чуть-чуть подождём». В отдельной статье я разбирал, почему у пилота должен быть заранее названный критерий остановки.
Полезно разделить три вида сигналов. Первый — поведение: новый путь выбирают сами или только по напоминанию. Второй — качество: меньше ли возвратов, уточнений, потерянных статусов. Третий — понимание: может ли новый человек объяснить, зачем шаг нужен и что делать в исключении. Одной цифры обычно недостаточно.
Что делать, если люди вернулись к старому пути
Это не всегда провал исполнителей и не повод немедленно «дожать внедрение». Сначала стоит разобраться в причине. Возможно, в новом экране нет данных, которые нужны для решения. Возможно, последовательность шагов не совпадает с реальной ответственностью. Возможно, сценарий верный, но выбран не тот момент для подсказки.
Самая дорогая реакция — добавить ещё полей, кнопок и уведомлений, не поняв исходную проблему. Так продукт превращается в шкаф, куда складывают все просьбы. Гораздо полезнее вернуться к конкретному случаю и спросить: где именно человек свернул со сценария и что он пытался сохранить?
Иногда ответ честный: гипотеза не стоит дальнейших вложений. Это хороший исход. Он дешевле, чем функция, которую годами поддерживают только потому, что когда-то на неё потратили время.
Короткий чек-лист перед стартом
- Назван один конкретный рабочий шаг, а не абстрактная потребность.
- Понятно, кто выполняет шаг, в какой момент и чем пользуется сейчас.
- Есть реальный недавний пример, а не только мнение на встрече.
- У теста есть границы, срок и ответственный за вывод.
- Заранее определено, какой сигнал заставит доработать или остановить идею.
Проверка гипотезы не должна превращаться в бюрократию перед разработкой. Её задача проще: убедиться, что следующая функция меняет рабочую жизнь человека к лучшему, а не просто хорошо выглядит в списке релизов. С этого обычно и начинается продукт, которому находят место в реальном дне.
Обсудим?