Технический сооснователь в customer discovery: что он должен брать на себя

Почему эту роль часто понимают неправильно

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

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

За простым на вид запросом часто скрывается более серьезный. «Сможете поддержать on-premises?» может означать другую модель ценообразования, более долгий онбординг и более сложную поддержку. «Сможете интегрироваться с нашей ERP?» может означать кастомную работу, долгие тесты и обещания, которые команде не стоит давать легкомысленно.

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

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

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

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

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

Когда стоит подключаться к звонку

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

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

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

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

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

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

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

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

Что именно вы должны брать на себя

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

Это значит, что нужно слушать, что стоит под запросом. Когда покупатель просит «real time dashboards» или «enterprise security», он может иметь в виду совсем разные вещи. Одна компания хочет обновления раз в 15 минут. Другая — данные по секундам, audit logs, single sign on и approval flows. Это совершенно разные проекты.

Вы отвечаете за перевод. Сначала превращайте расплывчатые запросы в конкретные трудозатраты, зависимости и пограничные случаи. Затем объясняйте компромиссы простым языком. Что станет быстрее, дешевле или проще, а чем покупателю придется пожертвовать? Третий шаг — оценить по времени. Это нужно в первый день, позже или вообще просто приятно иметь? И наконец, защищайте границу обещаний. Останавливайте звонок, когда разговор скатывается в «конечно, мы можем это добавить», а «небольшая» доработка на деле означает месяцы дополнительной работы.

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

Вам также нужно проверять заявленные предпочтения. Запрос может звучать как жесткое требование, хотя на самом деле это привычка. Если потенциальный клиент говорит, что ему нужен on-premises hosting, спросите почему. Иногда настоящая потребность — контроль над данными, проверка поставщика или более низкие ежемесячные расходы. Когда вы понимаете причину, можно обсудить более простые варианты.

Это один из тех случаев, где может помочь опытный Fractional CTO. Oleg Sotnikov at oleg.is часто работает именно на таком уровне, где одно архитектурное решение влияет на uptime, расходы на облако и то, насколько компактной может оставаться команда.

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

Вопросы, которые вскрывают реальные ограничения

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

Хороший стартовый вопрос: «Что должно работать в первый день, чтобы вы сказали да?» Он заставляет покупателя отделить обязательное от желательного. Иногда ответ — не функция вообще. Это может быть single sign on, импорт из таблицы или обещанный срок ответа.

Потом спросите: «Вокруг каких инструментов или ручных шагов это должно встроиться?» У большинства команд уже есть запутанный процесс. Они используют почту, таблицы, Slack, старую ERP или одного человека, который вручную чинит проблемы. Если ваш продукт ломает этот поток, внедрение быстро буксует.

Еще один полезный вопрос: «Кто будет проверять вопросы безопасности, надежности или закупок?» Человек на звонке может любить продукт и при этом не контролировать решение. Юристы, IT, security, финансы или закупки могут остановить сделку позже. Вам нужны эти имена заранее, а не после устного «да».

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

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

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

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

Как вести свою часть звонка

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

Если покупателю нужны single sign on, audit logs и одобрение внутреннего IT до того, как кто-то сможет протестировать продукт, это не мелочи. Это влияет на внедрение и даже на то, имеет ли сделка смысл вообще.

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

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

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

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

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

Простой пример

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

Технический сооснователь должен немного притормозить. Первый полезный вопрос — не про графики. Он про то, где сейчас лежат данные.

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

Теперь форма сделки уже другая.

Вы больше не оцениваете легкий дашборд. Вы оцениваете проект по интеграции с историей аудита, ожиданиями по uptime и реальными потребностями в поддержке. Работа все еще может быть стоящей, но цена, план запуска и обещания по срокам должны измениться.

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

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

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

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

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

Ошибки, которые убивают звонок

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

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

Расплывчатые слова тоже вредят. Если кто-то говорит, что ему нужна «enterprise» настройка или «безопасный» продукт, не кивайте и не идите дальше. Спросите, что эти слова значат именно внутри их компании. Может быть, речь о single sign on, audit logs, согласовании с юристами, региональном хостинге или письменной цели по реакции на инциденты. Каждый из этих пунктов меняет объем работ по-своему.

Звонок можно испортить и спором с покупателем, когда запрос звучит странно. Допустим, они просят CSV-выгрузки каждую пятницу, а вы думаете, что dashboard решил бы задачу лучше. Не превращайте это в спор. Спросите, зачем им этот файл. Вы можете узнать, что finance-команда загружает его в старую систему, или что партнер не дает прямой доступ. Причина важнее самого запроса.

Перед тем как все закончат, закрепите владельца за каждым открытым вопросом. Вы подтверждаете, подходит ли single sign on текущему продукту. Клиент уточняет, кто утверждает security review. Коммерческий лидер отправляет цену по обсужденным вариантам поставки. Если у следующего шага нет владельца, фоллоу-ап расползается, и покупатель начинает терять уверенность.

Короткая проверка перед подключением

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

Поможет простой чек-лист:

• Может ли техническое ограничение изменить предложение, цену или план запуска?
• Будет ли покупатель просить доказательства по безопасности, надежности или интеграциям?
• Может ли основатель ответить на вероятные вопросы достаточно ясно без вас?
• Усилит ли ваше присутствие доверие или только затянет разговор?
• Какое решение должно выйти из этой встречи?

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

Если на большинство вопросов ответ «нет», пропустите звонок и разберите его потом. Если на два или три — «да», подключайтесь и держите свою роль узкой.

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

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

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

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

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

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

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