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

Почему этот запрос быстро усложняется

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

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

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

Скрытый счет обычно выглядит так:

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

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

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

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

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

Когда продукт начинает гнуться

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

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

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

Обновления тоже усложняются. Каждый релиз заставляет команду заново проверять эту кастомную ветку. Изменение, которое кажется не связанным, все равно может ее сломать. Например, вы обновляете права доступа, уведомления, биллинг или экспорт. И тут уже кто-то должен спросить: «А мы проверили особую настройку для того самого аккаунта?» Эта дополнительная проверка отнимает время на каждом релизе, а не только в день, когда вы создаете функцию.

Здесь помогает простое правило:

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

Когда все это накапливается, продукт начинает гнуться. Обычно именно в этот момент продуктовое контрпредложение имеет больше смысла, чем полноценная кастомная функция.

Признаки, что контрпредложение подходит лучше

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

Обычно это заметно заранее.

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

Настройки и роли закрывают больше запросов, чем команды ожидают. Клиент может просить отдельную админскую зону, когда ему нужен всего один дополнительный уровень прав. Или может хотеть кастомный экран заказов, хотя правило вроде «согласование менеджером выше $5,000» почти решает задачу. Часто это более выгодный обмен: меньше кода, меньше поддержки, меньше странных крайних случаев потом.

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

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

Если один из этих легких вариантов закрывает 80–90% потребности, кастомная функция обычно оказывается неверным решением. Более чистый ответ часто оказывается меньше самого запроса.

Что предложить вместо этого

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

Начните с самого маленького изменения

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

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

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

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

Используйте временный мост

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

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

Как собрать контрпредложение

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

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

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

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

Нарисуйте самый легкий вариант, который все же дает нужный результат. Сделайте его маленьким специально.

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

Потом проведите четкую границу между тем, что живет внутри продукта, и тем, что остается снаружи. Скажите это простыми словами. «Мы сгенерируем событие, когда заказ будет одобрен. Ваша команда или ваш подрядчик получит его и обновит ERP». Это сохраняет простоту продукта и одновременно дает клиенту путь вперед.

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

Команды, которые делают это хорошо, избегают расплывчатых обещаний. Oleg часто использует такой подход в консультационной работе: сузить запрос до самого маленького изменения, которое решает бизнес-проблему, а затем назначить каждый элемент реальному владельцу. Это делает сделку честной, а продукт — в порядке.

Простой пример из команды SaaS

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

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

Менеджер продукта задает лучший вопрос: какую проблему клиенту нужно решать каждый день?

Ответ оказывается намного меньше исходного запроса. Менеджерам нужно понимать, когда что-то требует согласования. Компании нужно хранить историю того, кто что и когда утвердил. Им также нужно, чтобы эта запись появлялась в их HR-системе.

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

Они выпускают:

• настраиваемые правила согласования
• email-уведомления для менеджеров
• API-хук, который отправляет события согласования в HR-систему клиента

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

Клиент все равно получает результат, который ему был важен. Менеджеры быстро получают уведомления. Бизнес сохраняет чистую историю согласований. HR-система остается синхронизированной. А SaaS-команда при этом избегает одноразового интерфейса, на уборку которого потом ушли бы месяцы.

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

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

Ошибки, которые портят разговор

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

Покупатель говорит, что ему нужен кастомный процесс согласования. Команда начинает спорить о таблицах, эндпоинтах и крайних случаях. Через десять минут никто уже не спросил, что именно они пытаются предотвратить, кто должен согласовывать и как часто это происходит. Иногда реальная потребность гораздо меньше: журнал аудита, API-хуки в другой инструмент или одно дополнительное правило в рабочем процессе.

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

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

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

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

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

Быстрая проверка перед тем, как соглашаться

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

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

Задайте эти вопросы простыми словами:

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

Если на большинство вопросов ответ «нет», сделайте паузу. Обычно это значит, что запрос лучше закрывать настройкой, API-хуками или изменениями в рабочем процессе, а не полноценной кастомной функцией.

Проверка на умение объяснить важнее, чем команды любят признавать. Если вашему sales lead нужно пять минут, чтобы описать вариант, поддержке будет трудно, документация разрастется, а новые клиенты его пропустят. Хорошие идеи продуктового контрпредложения легко произнести вслух. Например: «Вы можете запускать этот шаг через API-вызов и направлять согласования в отдельный статус». Это понятно. А вот «Мы добавили отдельный слой исключений с логикой под каждый аккаунт» — это уже начало проблем.

Проверка на сопровождение не менее жесткая. Каждый особый случай добавляет будущую работу для QA, поддержки, биллинга и миграций. Oleg Sotnikov часто описывает это не как проблему разработки, а как проблему операционных затрат: если изменение спасает одну сделку сегодня, но добавляет команде еженедельную мороку, математика очень быстро становится некрасивой.

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

Что делать дальше

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

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

Потом добавьте еще одно поле: «Что можно предложить вместо этого?» Этот вопрос меняет тон. Он уводит команду от «строить или отказать» к настройкам, API-хукам, изменениям в рабочем процессе или небольшому сервису вокруг продукта.

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

Простой процесс может выглядеть так:

• Фиксируйте каждый запрос в одном и том же шаблоне.
• Разбирайте новые запросы вместе по фиксированному графику.
• Записывайте, какое контрпредложение вы дали и почему.
• Отслеживайте, закрылся ли сделка, зависла или ушла позже.

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

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

Если одна и та же развилка снова и снова возвращается, прежде чем снова гнуть продукт, посмотрите на нее со стороны. Короткая консультация у fractional CTO advisor вроде Oleg Sotnikov поможет отделить реальные пробелы в продукте от дорогих обходных путей. Такой разбор особенно полезен, когда команда не может договориться, давление продаж велико или запрос затрагивает архитектуру.

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