Темы воркшопов для нетехнических основателей перед демо-днем

Почему основатели теряют зал

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

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

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

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

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

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

Опытный приглашённый CTO может помочь именно здесь. Его задача не в том, чтобы сделать питч более техническим. Его задача — сделать его честным, простым и вызывающим доверие.

Что людям нужно понять

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

Во-первых, им нужна одна простая фраза о том, что делает продукт. Пропустите большое видение. Пропустите стек. «Мы помогаем отделам продаж отвечать на RFP за минуты, а не за дни» — этого достаточно. Если для фразы нужна доска, она всё ещё слишком запутана.

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

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

В-четвёртых, нужны честные заявления об ИИ. Скажите, что делает модель, где она помогает и где люди всё ещё проверяют результат. Например, ассистент может составлять ответы или сортировать обращения в поддержку, а человек всё ещё утверждает чувствительные сообщения. Одна такая фраза показывает инвесторам и клиентам, что вы понимаете ограничения.

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

Какой формат сессии подходит какой теме

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

Лучше сделать несколько коротких сессий, и у каждой должна быть одна понятная задача. Держите их короче 45 минут. Это заставляет говорить проще и не даёт комнате уйти в споры о второстепенных деталях.

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

Для рисков запуска хорошо работает обзор по схеме красный-жёлтый-зелёный. Красный — это реальный блокер или отсутствующая зависимость. Жёлтый — команда может запуститься, но сроки или масштаб могут сдвинуться. Зелёный — работа понятна и под контролем. Всё просто, и в этом смысл. Такой формат помогает основателям говорить о рисках без туманности и защиты.

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

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

Как объяснить архитектуру простыми словами

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

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

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

Простой язык обычно работает лучше, чем системные термины. «Сохраняет файл» понятнее, чем «записывает в object storage». «Перенаправляет запрос» понятнее, чем «оркеструет workflow». «Проверяет прошлые записи» понятнее, чем «делает запрос к базе данных». А «использует модель ИИ, чтобы составить ответ» лучше, чем «запускает инференс через model pipeline».

Это не значит, что нужно скрывать сложность. Её нужно переводить. Основатель, который говорит «у нас три сервиса и retrieval layer», часто теряет зал. Основатель, который говорит «мы подтягиваем карточку клиента, находим похожие прошлые случаи и составляем ответ», обычно удерживает внимание.

Держите готовым один запасной ответ на более глубокие вопросы. Вам нужен только один уровень глубже. Если кто-то спрашивает: «Что произойдёт, если ИИ ошибётся?», достаточно понятного ответа: «Мы сохраняем исходный источник, показываем черновик пользователю и отправляем крайние случаи человеку».

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

Как говорить о рисках запуска ясно

Инвесторы не ждут абсолютной уверенности. Они ждут план, который звучит реалистично.

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

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

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

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

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

Такой ответ звучит спокойно, конкретно и вызывает доверие.

Как делать заявления об ИИ честными и понятными

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

Один простой способ объяснить это — разделить систему на три части: что делает модель, что по-прежнему делают правила или люди и где она может ошибиться.

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

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

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

Также назовите, что проверяет человек. Это может быть каждый результат, только помеченные случаи или небольшая выборка. Будьте конкретны. «Менеджер утверждает решения по возвратам» говорит больше, чем «human in the loop».

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

Как проводить эти воркшопы

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

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

Начните с холодного питча. Дайте основателю пять минут, чтобы объяснить тему ровно так, как он сделал бы это на демо-дне. Без слайдов. Без спасательных подсказок. Без перебиваний, пока не закончится таймер.

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

Хорошо работает простой ритм: пять минут на первую попытку, 15–20 минут на вопросы и переписывание, 10 минут на новую версию и две минуты, чтобы ужать её для демо-дня.

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

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

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

Простой пример перед демо-днем

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

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

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

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

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

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

Ошибки, которые подводят основателей

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

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

Когда риск звучит расплывчато

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

Заявления об ИИ тоже быстро создают проблемы. Если основатель говорит, что продукт «использует ИИ для автоматизации поддержки», но никогда не объясняет ограничения, люди начинают думать, что команда что-то скрывает. Скажите, что может модель, где она ошибается и что по-прежнему проверяет человек.

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

Ещё одна частая проблема появляется, когда основатель и техлид называют одну и ту же вещь разными словами. Если один говорит «workflow engine», а другой — «AI agent», аудитория начинает разбираться в терминах вместо того, чтобы слушать.

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

Такая чистка может полностью изменить атмосферу в комнате.

Что проверить утром в день демо

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

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

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

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

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

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

Один маленький запрет очень помогает: уберите слова-паразиты, которые прячут слабое мышление. «Умный», «продвинутый» и «powered by AI» сами по себе ничего не объясняют. Заменяйте их на то, что система реально делает.

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

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

Что делать после пробной сессии

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

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

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

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

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

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