Product Growth Strategy Playbook

Так-с, я тут наткнулся на крутецкий док про стратегию!

💡 Суть
Плейбук - это инструкция для тех, кто понял:
"Мы же не можем просто добавлять фичи и называть это стратегией."
Бэклог - это история твоих компромиссов,
а стратегия — это история твоих выборов.

Пример: команда Cloud Platform тратит месяцы на «поддержку всех сценариев»,
вместо того чтобы выбрать один - разработчик создает прод-готовый сервис за день.
И вот это уже стратегическая ставка.

⚙️ Структура (и немного боли)
Context & Bets - где ты вообще находишься и зачем живёшь: Run / Grow / Transform.

Run - удержание стабильности. Пример: команда Billing сокращает ручные операции на 80%, чтобы высвободить 2 FTE и ускорить закрытие месяца.

Grow - масштабирование ядра. Пример: PAAS добавляет CLI и шаблоны сервисов, чтобы скорость старта новых проектов выросла в 3 раза.

Transform - смена игры.
Пример: «Платформа пеиестала быть инструментом для инженера, а стала сервисом для РО, позволяющим в 3 клика создать прототип».

Vision - не лозунг «мы меняем мир», а состояние, которое можно измерить.

Пример: «через два года 70% разработчиков деплоят без тикетов и без чьего-либо участия, NPS DevX выше 60, SLA платформы 99.95%».
Вот это - видение. Короткое, измеримое, вдохновляющее и без буллшита.
———————
Strategy Map - формула: Direction → Goal → Metric → Tactics.

Пример: «Уменьшить Time to Market (Direction) → довести median time до 1 дня (Goal) → считать время от репозитория до прода (Metric) → внедрить сервис-шаблоны и auto-QA (Tactics).»
Всё. Понятно и измеримо.

Execution - здесь стратегия превращается в результаты, а не в «релиз-ноты».
Пример: не «мы запустили новый портал мониторинга»,
а «мы сократили время на локализацию деградации с 1 часа до 8 минут».
Разница колоссальная.
—————
🔩 Любимые инструменты (и как ими пользоваться на самом деле)
SCQ(A): Situation – Complication – Question – (Answer)
Ты садишься с командой и не обсуждаешь «почему всё плохо»,
а формулируешь конкретный вызов.
Пример: «Сейчас запуск нового сервиса занимает 3 дня (S). Команды обходят пайплайн вручную, чтобы ускориться (C). Как сделать деплой за 15 минут без тикетов (Q)? → Создать Golden Path с шаблонами и CLI-деплоем (A).»
Это дисциплинирует мышление: теперь не обсуждаем «всё подряд», а решаем одну задачу.

RGT - Run / Grow / Transform
У каждой команды должно быть честное определение своей стадии.
Пример: команда DBAAS долго пыталась «инновировать», пока не признала, что сейчас её миссия - Run, то есть автоматизировать и стабилизировать ядро.
Через квартал 80% тикетов закрываются автоматически.
А вот команда Internal Tools выбрала Grow: вложилась в developer onboarding и за полгода удвоила adoption платформы.
Главная сила этого инструмента - он заставляет признаться себе, где ты реально, а не где хочется быть.

GEM-фокус - Growth, Engagement, Monetization
Ты не можешь улучшать всё сразу.
Пример: Slack в 2015 выбрал Engagement - не рост, не деньги, а глубину использования.
И вся стратегия была построена вокруг «как сделать, чтобы пользователи возвращались».
А потом уже пришёл рост и монетизация.
Если у тебя внутренняя платформа - скорее всего твой GEM-фокус сейчас Engagement: сделай так, чтобы разработчикам реально хотелось использовать твой продукт.

Killer Features (D-D-M): Delight, Defensibility, Monetization
Это фильтр против фич-инфляции.
Пример: у Figma три killer-фичи - real-time collaboration (Delight), community templates (Defensibility) и paid teams (Monetization).
Всё остальное - приятный шум.
Для платформы это может быть: «CLI-first experience», «observability by default» и «встроенные cost-метрики».
Если твоя фича не попадает хотя бы в один из D-D-M - она лишняя.

Vision Canvas
Не формулируй миссию - рисуй картину.
Пример: «Сегодня запуск нового сервиса требует 4 часа и 3 человека. Через год — 15 минут и один человек. Ключевые барьеры - ручные approvals и разрозненные пайплайны. Наша ставка - единый Golden Path + CLI + auto-approvals.»
Становится сразу видно, где ты, куда идёшь и что мешает.

Документ реально офигенный, без булшита!