Сценарий демонстрации продукта по вопросам клиентов
Как построить сценарий демонстрации продукта по discovery-звонкам: выбрать задачу, начальное состояние, короткий маршрут, проверяемый результат и вопросы.
Функции запоминаются хуже, чем понятный рабочий маршрут
Обзор всех разделов может выглядеть содержательно и при этом не отвечать на главный вопрос покупателя. Если клиенту важно передать итог встречи подрядчику, демонстрация должна показать именно этот путь и условия, а не десять соседних возможностей.
Расшифровки discovery-звонков помогают сохранить язык задачи и вопросы. Но сценарий нужно сверить с актуальной версией продукта: интерфейс, ограничения и доступные действия могут измениться. Не показывайте макет как работающую функцию.
Соберите короткий маршрут показа
Зафиксируйте договорённый контекст
Одним абзацем запишите роль, исходную ситуацию, желаемый результат и критерий. В начале показа подтвердите, что именно это полезно увидеть.
Выберите минимальный набор шагов
Оставьте только действия, без которых результат не понятен. Дополнительные функции вынесите в запас на вопросы.
Подготовьте безопасные данные и состояние
Используйте вымышленные или разрешённые данные. Проверьте доступ, роли, скорость соединения и запасной вариант объяснения на случай сбоя. Не открывайте личные записи клиентов.
Завершите проверкой и границами
Покажите итог, назовите ручные проверки и ограничения. Спросите, что соответствует процессу, а что отличается, затем согласуйте следующий шаг без искусственного давления.
Демо пути от встречи к рабочему итогу
Ниже — вымышленный учебный пример. Имена, условия и результаты приведены только для объяснения метода.
Нам важно после встречи за десять минут собрать решения и отправить подрядчику только финальную версию.
Сценарий может состоять из четырёх сцен: загрузить учебную запись, открыть текст, выделить решения, подготовить разрешённый формат передачи. Каждая сцена должна отвечать критерию клиента.
Нельзя обещать десять минут как универсальную скорость, если это лишь пожелание собеседника. На демонстрации лучше измерить конкретный пример и объяснить, какие шаги требуют проверки. Ситуация вымышленная.
| Сцена | Что показать | Проверочный вопрос |
|---|---|---|
| Контекст | Учебная запись и цель | Это похоже на ваш исходник? |
| Действие | Минимальный путь к решениям | Какой шаг отличается? |
| Контроль | Ручная сверка и границы | Кто проверяет результат? |
| Итог | Формат рабочего результата | Этого достаточно для следующего шага? |
Карточка сценария демо
Для каждой сцены свяжите действие с критерием клиента и подготовьте честную границу.
Аудитория и участники: Ситуация из discovery: Желаемый результат: Критерии клиента: Учебные данные: Сцена 1: исходное состояние: Сцена 2: ключевое действие: Сцена 3: проверка: Сцена 4: итог: Что не показываем и почему: Ограничения продукта: Запас на вопросы: Проверочный вопрос: Следующий шаг:
Отрепетируйте ценность и безопасность
- Каждая сцена связана с задачей клиента.
- Используются безопасные учебные данные.
- Интерфейс и ограничения проверены перед показом.
- В финале есть вопрос о соответствии критериям.
Разберём детали
Нужно ли показывать все функции?
Нет. Покажите те, что нужны для согласованной задачи. Остальные можно раскрыть по вопросу или на отдельной встрече.
Что делать, если демо сломалось?
Не скрывайте сбой и не выдавайте заранее записанный результат за живой. Объясните, на каком шаге остановились, используйте заранее согласованный безопасный материал и предложите повторную проверку.