Суть. Работа над новым начинается не с требований, а с текста, который вы опубликуете в день запуска: что это, для кого, какую проблему снимает, и вопросы, которые задаст клиент. Документ пишется до разработки и служит проверкой: если объявление получается неубедительным, дальше идти незачем.
Структура документа
| Часть | Что в ней | Проверка |
|---|---|---|
| Заголовок | Одно предложение, понятное клиенту | Понятно без объяснения контекста |
| Проблема | Что было плохо до этого | Названа словами клиента, не вашими |
| Решение | Что теперь можно делать | Без списка функций |
| Цитата клиента | Что бы он сказал | Если звучит фальшиво — ценность не найдена |
| Вопросы клиента | Цена, сроки, ограничения, безопасность | Неудобные вопросы включены честно |
| Внутренние вопросы | Себестоимость, кто делает, что не делаем | Явно указано, что вне рамок |
Почему это работает
Текст нельзя написать убедительно, если ценность не понята: расплывчатость сразу видна. И он заставляет принять решения, которые обычно откладывают, — для кого именно, что не делаем, сколько стоит.
Когда применять
На старте новой инициативы, когда команда готова обсуждать техническое решение раньше, чем сформулировала, для кого и зачем оно нужно. Подход разворачивает порядок: сначала пишется итоговое сообщение для клиента, и только если оно убедительно — начинается работа.
Что пишется
| Документ | Что в нём | Объём |
|---|---|---|
| Сообщение о запуске | Что мы выпускаем, для кого, какую проблему это решает, цитата клиента | Одна страница |
| Частые вопросы для клиента | Что спросит покупатель: цена, ограничения, чем отличается | Одна страница |
| Внутренние вопросы | Экономика, риски, зависимости, что делаем, если не взлетит | Две-три страницы |
Правило: если сообщение о запуске звучит скучно для самой команды, продукт не нужен рынку. Это дешёвая проверка, которая экономит кварталы.
Порядок
- Написать сообщение о запуске так, будто продукт уже вышел.
- Написать вопросы клиента и честно ответить на самые неудобные.
- Прочитать документ в тишине на встрече, без презентации, и только потом обсуждать.
- Переписывать, пока команда не начнёт спорить о сути, а не о формулировках.
- Только после этого переходить к оценке сроков и архитектуре.
Чтение в тишине — не ритуал: презентация позволяет докладчику скрыть слабые места голосом, текст не позволяет.
Что даёт на практике
- Ранний отказ от идей, которые невозможно объяснить клиенту одной страницей.
- Общее понимание цели у всех участников, включая тех, кто подключится позже.
- Готовый материал для маркетинга и продаж к моменту выпуска.
- Список рисков, зафиксированный до, а не после того, как они реализовались.
Где ломается
Пишут после разработки. Тогда это пресс-релиз, а не инструмент решения.
Убирают неудобные вопросы. Именно они и есть ценная часть.
Превращают в ритуал. Документ на десять страниц по каждой мелочи убивает саму практику; она для крупных решений.
- Документ пишется после решения. Тогда он превращается в обоснование уже принятого и теряет смысл проверки.
- Цитата клиента придумана. Полезна только реальная формулировка из разговора; выдуманная маскирует отсутствие спроса.
- Обсуждение сводится к правкам текста. Признак, что участники не готовы спорить о самой идее.