Дорожная карта ломается не от того, что продавцы просят слишком много, а от того, что в компании нет общего правила, по которому просьба превращается в задачу. Пока правила нет, побеждает тот, кто громче или чья сделка ближе к подписанию. Рабочая схема простая: любое требование от продаж приходит одним и тем же путём — сделка, деньги, срок, число других клиентов с той же болью — и получает оценку по единой шкале. Всё, что пришло мимо этого пути, в карту не попадает.
Откуда берётся давление
На узком рынке у продавца мало сделок, и каждая весит несоразмерно много. Потерять одну — значит потерять квартал. Поэтому продавец приносит требование заказчика не как гипотезу, а как ультиматум: «без этого не подпишут». Половина таких ультиматумов настоящие, половина — пересказ вежливого отказа, который заказчик придумал, чтобы не объяснять реальную причину.
Продуктовая команда не может отличить одно от другого на слух. Значит, отличать надо процедурой.
Четыре вопроса, без ответов на которые требование не рассматривается
| Вопрос | Что он проверяет | Плохой ответ |
|---|---|---|
| Какая сделка и на какую сумму зависит от этой доработки? | Есть ли вообще деньги за требованием | «Пока обсуждаем, но перспективы большие» |
| Что именно заказчик пытается сделать и почему сейчас не может? | Задачу или решение нам принесли | Пересказ технического задания без объяснения цели |
| Сколько других клиентов и лидов просили то же самое? | Единичный случай или закономерность | «Наверняка всем нужно» |
| Что произойдёт, если мы сделаем это через два квартала? | Реальность срока | «Тогда уйдут», без даты и повода |
Четвёртый вопрос отсекает больше всего шума. Если на «а через два квартала?» продавец отвечает «ну, наверное, подождут» — требование не срочное, оно просто громкое.
Как выстроить процесс
- Один вход. Все запросы от продаж и внедрения попадают в один список — не в личные сообщения продакту, не в разговор в коридоре. Запрос без автора и без сделки не принимается.
- Формулировка через задачу заказчика. Продавец описывает, чего клиент пытается добиться, а не какую кнопку хочет. Здесь помогает язык Jobs to be Done: работа, которую клиент «нанимает» продукт выполнять.
- Регулярный разбор. Раз в две недели продукт и коммерция вместе проходят список. Не переписка, а встреча с решением по каждому пункту: берём, откладываем, отказываем.
- Оценка по одной шкале. Охват, влияние, уверенность, трудоёмкость — модель RICE и ICE подходит именно потому, что она грубая: она не даёт точного ответа, но заставляет всех считать по одним правилам.
- Публичный отказ. Отказ фиксируется письменно с причиной и датой. Через полгода это спасает: видно, что просили пять раз и каждый раз отказывали, — значит, пора пересмотреть.
- Обратный канал. Продавец узнаёт судьбу своего запроса от продукта, а не от клиента. Иначе он перестанет приносить запросы и начнёт обещать напрямую.
Отдельная строка бюджета разработки под «коммерческие обязательства» — обычно от десяти до двадцати процентов ёмкости команды — снимает половину конфликта. Продажи знают, что у них есть гарантированная доля, и перестают воевать за каждую задачу.
Что делать с требованием одного крупного клиента
Отдельный разговор — доработка, которая нужна ровно одному заказчику и никому больше. Здесь есть три честных варианта, и все три нормальны.
- Сделать за деньги отдельным проектом. Не в продукте, а в контуре заказчика или как отдельный модуль. Стоимость считается как работа, а не как «мы всё равно собирались».
- Сделать в продукте, если требование обобщается. Часто под частной просьбой лежит общая потребность: не «выгрузка в такой-то формат», а «данные должны уходить во внешнюю систему без ручной работы».
- Отказать и принять риск. Иногда сделка того не стоит. Продукт, собранный из требований трёх крупных клиентов, невозможно продать четвёртому.
Модель Кано помогает разложить требования на обязательные, линейные и восхищающие: обязательное отсутствие убивает сделку, восхищающее её не спасёт, если базовое не работает.
Связанное
- RICE и ICE — шкала приоритизации
- Модель Кано — типы требований
- Jobs to be Done — язык описания задачи клиента
- Управление жизненным циклом продукта
- Роль: продуктовый маркетолог
Дорожная карта защищается не отказами, а процедурой. Один вход, четыре вопроса, регулярный разбор и письменный отказ с причиной — этого достаточно, чтобы отделить настоящие блокеры от громких просьб.