B2B Growth · Strategy · Revenue · AI Automation Маркетинг с 2008 года
Шаблоны и инструменты

Бриф запуска продукта (Product Launch Brief Template)

Зачем нужен
Product Launch Brief синхронизирует Product, Marketing, Sales и Customer Success вокруг scope запуска, аудитории, сообщения, каналов, readiness и метрик.

Готовый шаблон

Бриф запуска продукта
Что запускаем
Product/feature/package, scope и ограничения.
Почему сейчас
Customer evidence, market trigger или strategic reason.
Целевая аудитория
ICP, personas, existing/new customers.
Use cases
Какие задачи решает запуск.
Positioning & message
Как объясняем ценность и отличие.
Launch tier
Major / medium / minor и требуемый уровень поддержки.
GTM motions
Sales-led, product-led, partner, lifecycle, paid/owned.
Readiness
Product, docs, support, legal, analytics, sales enablement.
Metrics
Adoption, pipeline, revenue, activation, retention или другие outcomes.
Timeline & owners
Milestones, dependencies, launch date, accountable owner.

Чек-лист готовности к запуску (Launch Readiness Checklist)

  • Product доступен нужной аудитории.
  • Tracking проверен.
  • Pricing и contracts готовы.
  • Sales знает qualification и demo.
  • Support/CS знает сценарии.
  • Landing/content соответствует positioning.
  • Есть rollback/escalation plan.

Главная ошибка

Считать запуск датой публикации пресс-релиза. Launch — coordinated change across product, market communication and revenue teams.

Когда шаблон особенно полезен

Шаблон особенно полезен при запуске нового продукта или сегмента, пересборке позиционирования, изменении pricing/packaging и подготовке материалов для Sales. Он даёт наибольшую пользу там, где несколько функций должны одинаково понимать клиента и ценность. Для небольшого локального изменения используйте сокращённую версию: не усложняйте документ, если решение можно принять на одной странице.

Как внедрить шаблон в рабочий процесс

  • Начните с конкретного сегмента, продукта и бизнес-задачи. Один шаблон не должен одновременно обслуживать несколько принципиально разных аудиторий.
  • Заполняйте спорные поля только после проверки источников: интервью, win/loss, CRM, продуктовой аналитики, коммерческих данных или подтверждённых кейсов.
  • Проведите короткое согласование с Product, Sales и Customer Success, если документ влияет на обещания рынку или работу с клиентом.
  • Отдельно пометьте факты, интерпретации и гипотезы. Гипотеза не должна превращаться в маркетинговый claim только потому, что попала в документ.
  • После использования сравните ожидаемый эффект с фактическим и обновите шаблон: хороший артефакт становится точнее после каждого запуска, сделки или исследования.

Практический пример

При запуске нового AI-модуля команда заранее описывает target accounts, use cases, readiness, enablement, rollout, metrics и support. Это позволяет отличить «релиз функции» от полноценного выхода на рынок.

Что должно получиться на выходе

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

Проверка качества перед использованием

  • Есть конкретный target segment и контекст использования.
  • Ключевые claims связаны с evidence, а не только с мнением команды.
  • Документ различает value, feature и proof.
  • Sales и Product одинаково понимают основные формулировки.
  • Указана дата актуализации и источник новых данных.

Как поддерживать шаблон в актуальном состоянии

Пересматривайте документ после нового исследования, заметного изменения продукта, pricing/packaging, нового сегмента или серии win/loss-интервью. Для активно продаваемого продукта полезен плановый review не реже одного раза в квартал.

Частые вопросы (FAQ)

Нужно ли заполнять все поля?

Нет. Обязательны поля, которые влияют на решение или коммуникацию. Если блок не нужен для конкретного продукта, лучше явно поставить N/A, чем заполнять его формально.

Кто должен быть владельцем?

Обычно PMM или владелец соответствующего market-facing процесса, но ключевые поля должны быть согласованы с Product, Sales и при необходимости Customer Success.

Можно ли использовать один документ для нескольких сегментов?

Только если их jobs, decision criteria и value logic действительно совпадают. Иначе лучше вести отдельные версии, чтобы не получить усреднённое позиционирование.

Связанные шаблоны

Связанные фреймворки

Связанные понятия

Продуктовый маркетинг