Технические вопросы, на которые основатели должны ответить на demo day

Почему основатели спотыкаются на технических вопросах

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

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

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

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

Небольшой пример хорошо показывает проблему. Основатель говорит: «Мы интегрируемся с CRM-инструментами и автоматизируем follow up». Инвестор спрашивает, с каким именно CRM, какие данные синхронизируются и что ломается, если достигнут лимит API. Если реальный ответ такой: «Мы сделали одно базовое подключение и часть процесса все еще выполняем вручную», прежнее заявление уже выглядит завышенным.

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

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

Что уже обещает ваш питч

Ваши слайды что-то обещают даже тогда, когда вы не говорите это вслух. График с uptime 99,9%, скриншот AI-ассистента или ряд логотипов интеграций подают сигнал, что продукт уже работает определенным образом.

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

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

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

Применяйте тот же тест ко всем интеграциям и ИИ-функциям. Если в демо сказано, что продукт подключается к Slack, HubSpot, Stripe или кастомному ERP, знайте, какой именно инструмент стоит за этим. Если вывод ИИ идет из OpenAI, Anthropic или внутреннего model flow, это тоже нужно знать. Вам зададут один уточняющий вопрос, и расплывчатый ответ быстро подрывает доверие.

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

Один вопрос важнее, чем кажется: что работает сегодня, что еще требует помощи и что находится в road map. Пункты road map допустимы. Проблема начинается, когда команды смешивают их с уже выпущенными функциями.

Проверьте заявление об uptime

Uptime — один из самых простых показателей, который можно приукрасить. Слабый ответ звучит хуже, чем скромная, но реальная цифра. Если вы знаете свой uptime за последние 30 или 90 дней, скажите его прямо. Если пока не отслеживаете его, скажите и об этом, а затем объясните, что именно мониторите сейчас.

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

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

Вам также нужно знать, что ломается первым, когда растет нагрузка. Многие продукты не падают сразу целиком. Может замедлиться поиск. Могут накопиться фоновые задачи. Внешний API может упереться в rate limit. Если вы можете сказать: «Основной сценарий остается доступным, но первым задерживается формирование отчетов», вы звучите как человек, который знает систему, а не гадает на сцене.

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

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

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

Задайте четкие границы ИИ

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

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

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

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

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

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

Говорите прямо о провайдерах модели и работе с данными. Если вы используете OpenAI, Anthropic или open source модель, назовите ее. Скажите, отправляете ли вы полный текст клиента, замаскированные поля или только embeddings. Объясните, логируются ли промпты, как долго вы их храните и могут ли данные клиента обучать внешнюю модель.

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

Подтвердите каждую интеграцию в демо

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

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

Таблица помогает лучше, чем слайд. Для каждого пункта отметьте, сделали ли это вы сами или это делает vendor. Одна эта строка меняет историю. «Мы сделали workflow, Stripe обрабатывает платеж» звучит ясно. «Наша система делает платежи» звучит больше, чем реальность, и люди это замечают.

Потом проверьте скучные точки отказа: rate limits API при повторном использовании, sandbox-аккаунты, которые ведут себя не так, как live-аккаунты, истекшие токены, старые login sessions, отсутствующие permissions в Google или Microsoft auth и задержки синхронизации, из-за которых свежие данные выглядят сломанными.

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

Простой пример показывает это особенно ясно. В вашем демо клиент платит, затем видит invoice в своем аккаунте и запись в CRM. Этот сценарий может зависеть от платежного провайдера, email-сервиса, webhook, очереди, worker и CRM API. Если webhook задерживается на две минуты, вся история разваливается прямо на сцене.

Дайте себе по одному fallback на каждую внешнюю зависимость. Если social login не работает, используйте подготовленный тестовый аккаунт. Если платежный вызов зависает, переключитесь на записанную успешную транзакцию и объясните live-путь. Если sync ломается, покажите созданную запись локально и скажите, что внешний sync работает асинхронно.

Чистое демо — это хорошо. Демо, которое переживает один сломанный dependency, — лучше.

Проведите 30-минутную тренировку ответов

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

Откройте deck и прочитайте его слайдами по очереди. Останавливайтесь каждый раз, когда встречаете техническое предложение. Спрашивайте: «Откуда мы знаем, что это правда?» Если ответ расплывчатый, значит, и само заявление такое же.

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

Цифры успокаивают людей. «Быстрый onboarding» — расплывчато. «Большинство пользователей завершают настройку менее чем за 10 минут» — лучше, если вы можете это доказать. «Наш ИИ обрабатывает поддержку» — рискованно. «Наш ИИ делает черновики ответов, а человек утверждает их перед отправкой» — гораздо безопаснее, потому что граница понятна.

Эта сессия не про блеск. Она про правду под давлением. Если один слайд говорит, что у вас uptime 99,99%, инженер должен объяснить, откуда взялась эта цифра. Если слайд говорит, что вы интегрируетесь с инструментом клиента, кто-то должен подтвердить, что в демо используется реальное рабочее соединение, а не замоканный экран.

Небольшой пример быстро показывает разрыв. Основатель говорит: «Мы подключаемся к любому CRM за минуты». Инженер замолкает. После пяти минут вопросов команда меняет это на: «Сегодня мы поддерживаем HubSpot, а остальные варианты можем добавить через кастомную работу». Вторая фраза звучит менее эффектно. Зато она реальна.

К концу 30 минут у вас должен быть слайд deck с пометками, короткий лист ответов на сложные вопросы и меньше обещаний. Это хороший результат. Более плотный питч с меньшим количеством обещаний обычно вызывает больше доверия, чем большой питч, который разваливается на Q&A.

Простой пример перед demo day

Небольшая команда делает AI sales assistant для локальных магазинов. В демо он читает общий inbox, пишет черновики ответов и записывает follow up звонки. Выглядит плавно.

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

У модели есть и blind spot. Она неплохо пишет ответы на простые вопросы о продажах, но спотыкается на возвратах. Спросите про refund, exchange или поврежденный товар — и ответ становится шатким. Иногда он звучит уверенно, даже когда ошибается.

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

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

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

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

Ошибки, которые подрывают доверие

Инвесторы редко ждут идеальных систем. Но они ждут прямых ответов. Доверие падает быстро, если команда делает смелое заявление, а потом не может показать, откуда знает, что это правда.

Большинство follow up вопросов простые. Они проверяют, совпадает ли ваша история с продуктом. Если ответы звучат рыхло, питч тоже кажется рыхлым.

Частая ошибка — называть «99,99% uptime», потому что это звучит серьезно. Если никто в команде не может показать логи, алерты или dashboard, эта цифра выглядит выдуманной. Лучше ответить тише и правдоподобнее: сказать, что именно вы измеряете, как долго это измеряете и что произошло во время последнего сбоя.

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

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

Противоречивые ответы внутри команды вредят сильнее, чем слабый metric. Если основатель говорит, что продукт готов для крупных клиентов, а CTO говорит, что access control пока базовый, это сразу замечают все. Перед demo day оба человека должны использовать один и тот же простой язык для uptime, проверки ИИ, интеграций и безопасности.

Большие обещания по безопасности создают ту же проблему. Если вы говорите, что готовы к крупным клиентам, ждите вопросов про permissions, audit logs, backups и про то, кто получает алерты, когда что-то ломается. Вам не нужна огромная инфраструктура. Вам нужны базовые controls и понятный план.

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

Быстрые проверки накануне вечером

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

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

Финальный review должен закрыть пять вещей:

• Откройте реальный demo account на устройстве, которое будете использовать на сцене, а не чистую резервную настройку.
• Обновите токены, логины и permissions, а затем прогоните sample data от начала до конца.
• Запишите один недавний сбой одним предложением: причина и исправление.
• Назовите внешнюю службу, чей сбой быстрее всего сломает демо, если она упадет.
• Уберите слайдами все заявления, которые относятся к road map, а не к продукту сегодня.

Третья проверка важнее, чем кажется большинству основателей. Если кто-то спросит про надежность, честный ответ быстро вызывает доверие. «На прошлой неделе наша синхронизация остановилась на 12 минут после истечения токена. Мы добавили алерт и автоматический retry» звучит реально. «У нас отличный uptime» звучит как уход от ответа.

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

Еще одна деталь постоянно подводит команды: зависимость от vendor. Многие демо выглядят самодостаточными, но один auth provider, один model API или один billing service может положить весь flow. Знайте, какой сбой ударит по вам первым, и держите готовую фразу.

Если какое-то заявление имеет смысл только при будущей доработке, уберите его сегодня вечером. Меньший питч с чистыми доказательствами лучше, чем больший, который разваливается после одного follow up вопроса.

Что делать дальше, если ответы все еще слабые

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

Часто это значит не полировать deck, а сокращать его. Меньшее заявление, которое можно защитить, лучше, чем большое, которое разваливается, когда кто-то задает один follow up вопрос.

Если ваша команда говорит, что приложение «на базе ИИ», назовите точную задачу ИИ. Если вы говорите, что интеграции готовы, подтвердите, какие из них работают в live-продукте, а какие все еще ручные. Если вы упоминаете uptime, используйте ту цифру, которую можно подтвердить реальными логами, а не ту, что лучше всего звучит на сцене.

Быстрый фильтр помогает. Уберите заявления, которые зависят от будущей работы. Замените широкие слова точными ограничениями. Отметьте demo only flows, чтобы никто не называл их живыми функциями. Оставьте один proof point на каждое техническое обещание.

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

Хороший advisor задаст прямые вопросы. Что сломается, если за раз зарегистрируются 100 пользователей? Что делает модель ИИ, когда input грязный? Какая интеграция все еще требует человека в цикле? Это и есть важные вопросы.

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

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