Конфликт основателя и CTO: как срываются обещания по дорожной карте

Почему этот конфликт возникает так часто

Одно предложение на звонке с продажами может испортить всю неделю.

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

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

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

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

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

На ранних стадиях это случается особенно часто, потому что роли пересекаются. Основатели продают, формируют продукт, успокаивают инвесторов и отвечают клиентам. CTO отвечает за поставку результата, но при этом еще защищает здоровье системы, темп команды и кучу технического долга, о котором никто не хочет говорить. Без четких правил каждое обещание по roadmap начинает восприниматься лично.

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

Где размываются полномочия

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

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

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

Многие команды усугубляют ситуацию, смешивая разные решения в одно:

• Цена — это бизнес-решение.
• Объем работ — это продуктовое решение.
• Срок поставки и технический подход — это инженерные решения.
• Язык договора должен учитывать все три вещи, прежде чем кто-то скажет «да».

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

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

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

С fractional CTO все становится еще сложнее. Если основатель не проговорил вслух, какие технические решения этот человек может закрывать сам, каждая сложная сделка превращается в спор о статусе, а не в рабочее решение.

Что продажам можно обещать, а что нельзя

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

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

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

Лучше работает простой язык, чем расплывчатый оптимизм. Вместо обещаний раньше времени можно сказать: «Сегодня мы поддерживаем X». Или: «Нам нужно, чтобы продукт и разработка проверили Y, прежде чем мы что-то обещаем». Или: «Кастомная работа проходит отдельную проверку по объему и цене». Или просто: «Я дам вам точный ответ к четвергу».

Такие формулировки решают две задачи. Они сохраняют доверие клиента и защищают команду от внезапных дедлайнов.

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

Как заранее поставить правила

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

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

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

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

Стоит определить и само слово «обязательство». Во многих стартапах сырые идеи постепенно превращаются в обещания по roadmap просто потому, что никто их не останавливает. Обязательство — это то, что зафиксировано письменно. И основатель, и CTO подтверждают его, если объем изменился. Клиент получает те же формулировки, что видела команда. Если идея все еще на проверке, так и пишите. А если речь идет о сроках, у них должен быть конкретный владелец.

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

Потом пересмотрите правила после первых нескольких сделок. Обычно три звонка быстро показывают слабые места. Именно такую настройку Oleg Sotnikov на oleg.is часто помогает основателям сделать как fractional CTO: четкие правила согласования, более аккуратная передача запросов и меньше обещаний, которые команда вовсе не собиралась давать.

Какой ритм встреч убирает сюрпризы

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

Назначьте один короткий еженедельный обзор roadmap. Тридцати минут обычно достаточно, если обе стороны приходят подготовленными. Основатель приносит давление клиентов, открытые сделки и все обещания, которые были даны на звонках. CTO приносит риски поставки, загрузку команды и работы, которые могут сдвинуться.

На встрече нужно ответить на четыре простых вопроса:

• Что мы обещали на прошлой неделе?
• Какие новые запросы пришли от продаж, демо или поддержки?
• Какие запросы сейчас рискованные, неясные или слишком дорогие?
• Что мы говорим клиентам сегодня: да, нет или позже?

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

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

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

Закрывать цикл не менее важно, чем проводить саму встречу. После каждого решения отправляйте короткий follow-up в продажи и всем, кто общается с клиентами. Для «да» нужны объем и сроки. Для «нет» нужна простая причина. Для «позже» — условие, например «после исправлений онбординга» или «после инфраструктурных работ в третьем квартале».

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

Реалистичный пример со звонка продаж

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

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

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

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

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

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

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

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

Ошибки, которые все ухудшают

Конфликт становится острее, когда кто-то называет дату раньше, чем кто-либо оценил работу. Основатель хочет сохранить темп. Продажи хотят удержать сделку. Потом CTO слышит: «Мы уже сказали им — к следующему месяцу», — и у него остаются два плохих варианта: разочаровать клиента или загнать команду в спешку. Оба варианта подрывают доверие.

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

Обычно все становится личным, когда основатель и CTO спорят при всей команде. Разработчики начинают читать не приоритеты, а тон. Менеджеры продукта перестают задавать прямые вопросы и начинают угадывать, у кого на самом деле полномочия. Это угадывание очень быстро распространяется.

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

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

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

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

Короткая проверка перед любым обещанием по roadmap

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

Сделайте паузу, прежде чем кто-то скажет «да». На столе должны быть четыре вещи:

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

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

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

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

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

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

Держите встречу короткой. Решите, кто что может обещать, кто дает финальное «да» по объему работ и что происходит, когда продажи слышат от клиента «это нужно прямо сейчас». Если вы уйдете только с расплывчатым согласием, следующий конфликт вернется уже в следующей сделке.

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

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

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

Если один и тот же конфликт снова и снова возвращается, привлеките внешнего специалиста. Fractional CTO может посмотреть на процесс работы с roadmap, разобраться в правах на принятие решений и увидеть, где снова сталкиваются полномочия, технический риск и давление клиентов. Oleg Sotnikov делает такую работу через oleg.is для стартапов, которым нужен более спокойный и понятный способ управлять обещаниями по продукту.

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