Итак, ситуация… Небольшая компания, на рынке давно, клиенты её знают и доверяют. Но конкуренты потихоньку выкатывают то, чего компания пока предложить не может. В ней нет модных бизнес-аналитиков, продакт-менеджеров и проджектов. Продавцы сами собирают хотелки, сами формулируют задачи, сами тестируют результат. Разработчиков — несколько человек. Они делают что могут и как могут.
И начинается гонка ⚔️
— Сделайте как у них — и мы останемся с вами
— Будет к марту
Клиент соглашается продлить договор. Проходит март. Затем апрель. Май. Уже июнь на исходе — а обновление либо не готово, либо решает совсем не ту проблему. Менеджер снова возвращается с пустыми руками 🤷♂️
ИТОГ: клиент — теряет доверие, продавец — мотивацию, компания — деньги!
Знакомая ситуация? То, что мы видим — негатив клиентов, уныние продавцов, срыв сроков — это следствия. Настоящие ограничения системы лежат куда глубже.
Ограничение 1. Стратегия «догнать» через обещания
В разработке ПО продажа обещаний — рабочий инструмент, если она идёт от реальных возможностей. Происходит настройка под запрос. Клиент знает, что получит, и ждёт.
Здесь же стратегия другая: «Выведем сырой продукт, чтобы обогнать конкурентов»
Она не про клиента, а про гонку — когда мы не знаем, что именно нужно рынку, но мы должны быть «как они, только лучше». Обещания продаются без понимания, сможет ли производство их выполнить. Это ловушка, которая загоняет систему в вечный цейтнот. Догонять бесконечно — значит всегда быть в положении догоняющего. И когда первый же срок срывается — стратегия начинает работать против вас.
Ограничение 2. Разработка стала узким горлышком
Продажи задают темп быстрее, чем разработка может выдать результат. Разработка — ФИЗИЧЕСКОЕ ограничение системы. Но проблема не в том, что сотрудников мало или они плохие.
Часто руководитель разработки вообще не осознаёт цену задержки. Или ему забывают о ней сказать. Для него это просто ещё одна задача в очереди. Он не видит, что каждая неделя просрочки — это конкретные клиенты и вполне конкретные деньги.
Ограничение 3. Разрыв ответственности между бизнесом и производством
Запрос поступил в разработку. Разработчики сделали «как поняли», отдают готовое. Продавцы принимают — но проверяют, работает ли код, а не решает ли он проблему клиента. В итоге фича есть, а боль клиента осталась.
Виной — отсутствие хозяина процесса. Никто в производстве не отвечает за то, чтобы фича решала проблему.
ЧТО ДЕЛАТЬ?
Дорожная карта
ШАГ 1. Вводим пожарный режим — здесь и сейчас
Главная задача — сохранить доверие, а не выбить 100% выручки любой ценой. Будущие деньги важнее сиюминутной маржи. Что делаем:
⏺ Поднимаем уровень общения на ступеньку выше. С клиентом говорил менеджер? Пусть теперь говорит РОП. С другим общался РОП? Теперь с ним пусть говорит генеральный. Клиент должен услышать: проблему понимают, над ней работают, гарант результата — первые лица компании. В разговоре не оправдываемся, а признаём ошибку + называем новый реалистичный срок (с запасом) и предлагаем конкретную компенсацию за задержку.
⏺ Предлагаем асимметричный бартер. Не просим 100% оплаты сейчас. Фиксируем текущую цену в допсоглашении. Саму оплату делим:
50% сейчас — подтверждение намерений
50% — после фактического выхода обновления
⏺ Даём гарантии. Если релиз запаздывает ещё раз — вторая половина платежа становится БЕСПЛАТНОЙ для клиента. Или ему обещается скидка 30% на следующий год.
ШАГ 2. Перешиваем процессы — чтобы пожар не повторился
Что делаем:
⏺ Вводим правило денег. В договорах делим: «продление текущего функционала» — оплачивается сейчас, «апдейт» — оплачивается по факту выхода релиза.
⏺ Вводим правило буфера. Любая дата от разработки — ×2 для клиента. Срыв срока становится внутренней проблемой разработки, а не внешней проблемой продавца.
⏺ Вводим новый KPI для РОПа. Снимаем KPI по «сумме собранных денег во время пожара». Добавляем временный KPI: «Количество клиентов, подписавших отложенное соглашение (50/50)».
⏺ Доносим до руководителя разработки стоимость потери клиента. Считаем в рублях, сколько компания теряет, если функция не готова к сроку, и кладём ему на стол. Чтобы он видел не задачу — а деньги.
ШАГ 3. Отказываемся от стратегии «догнать любой ценой»
Что делаем:
⏺ Выбираем свою ЦА под текущий продукт. Да, как есть! Продаём текущую ценность, а не ОБЕЩАНИЯ. Нужно искать клиента, чьи потребности продукт может закрыть прямо сейчас, без всяких доработок. Не пытаемся угодить всем — находим СВОЙ сегмент.
⏺ Ищем УТП, но точно не «мы дешевле». Уникальность может быть в скорости поддержки, в удобстве интеграции, в экспертизе в конкретной нише — но не в цене. Дешевле всегда найдётся кто-то другой.
⏺ Выстраиваем процесс передачи «эстафетной палочки». Как должно быть:
Бизнес-запрос → перевод на язык разработки → оценка → принятие → выполнение → приёмка
Это простой процесс. Но его должен кто-то выстроить. Самый надежный путь — дать мандат ответственному сотруднику (например, РОПу или коммерческому директору) и сделать его хозяином этого процесса. Найм отдельного продакт-менеджера — опция, но не панацея, если нет чёткой ответственности.
Узнали себя? Пишите в личку — будем это менять. Подскажу, что именно.
