Программа обучения продуктовых команд: от идеи до релиза
Обучили 4 продуктовые команды (32 человека) методам product discovery и работе с метриками. Time-to-market сократился на 35% по итогам двух кварталов.
Задача
IT-компания с 4 продуктовыми командами (32 человека) и SaaS-платформой для HR страдала от «кладбища фич»: разрабатывали много, но 60% фич не использовались после релиза. Команды строили не то, что нужно пользователям, а то, что громче всего просили стейкхолдеры.
- Нет культуры валидации гипотез — фичи попадали в разработку по запросу стейкхолдеров без проверки на реальных пользователях
- User research формальный — проводился 1–2 раза в квартал для отчёта, результаты не влияли на roadmap
- Метрики не связаны с бизнесом — продуктовые команды отслеживали количество релизов вместо adoption и retention
- Roadmap «по крикам» — топ-5 клиентов диктовали приоритеты, остальные 200+ клиентов игнорировались
- Медленный time-to-market — от идеи до релиза проходило 4–6 месяцев, при этом 60% фич использовались менее чем 5% пользователей
VP Product оценивал потери от ненужных фич в 40–50% инженерного бюджета — около 30 млн ₽ в год на разработку того, чем никто не пользуется.
Решение
Провели 8-недельное обучение с немедленным применением на реальных продуктах компании. Каждая неделя заканчивалась практическим артефактом.
Неделя 1–2: Discovery и исследование пользователей
- Jobs-to-be-done фреймворк: как выявить настоящие задачи пользователей
- Customer interviews: скрипты, техники, анализ результатов
- Практика: каждая команда провела 5 проблемных интервью с реальными клиентами
Неделя 3–4: Гипотезы и эксперименты
- Формулирование гипотез в формате «Мы верим, что... Мы узнаем это, если...»
- Дизайн экспериментов: A/B-тесты, smoke tests, fake door, Wizard of Oz
- MVP-мышление: минимальная проверка ценности до начала полноценной разработки
- Практика: каждая команда спроектировала и запустила 2 эксперимента
Неделя 5–6: Продуктовые метрики
- North Star Metric: как выбрать единую метрику продукта, связанную с бизнес-целью
- Дерево метрик: декомпозиция NSM на actionable метрики для каждой команды
- Настройка Amplitude для отслеживания ключевых событий
- Практика: каждая команда построила дашборд с ключевыми метриками
Неделя 7–8: Приоритизация и roadmap
- Фреймворки RICE и ICE: как объективно ранжировать backlog
- Data-driven roadmap: от метрик к приоритетам
- Работа с стейкхолдерами: как говорить «нет» с данными
- Финальная защита: каждая команда представила обновлённый roadmap с обоснованием
Методология «Teach by doing»
Принципиальное отличие от обычного обучения — всё делается на реальном продукте. Команды не изучают абстрактные примеры, а проводят интервью с собственными клиентами, запускают эксперименты на своём продукте и строят дашборды с живыми данными. К концу 8-й недели каждая команда имеет обновлённый roadmap, обоснованный данными, а не мнениями стейкхолдеров.
Культурный сдвиг
Главный результат — не навыки, а изменение культуры. До обучения фраза «клиент попросил» была достаточным основанием для фичи. После — команды требуют данные: сколько клиентов затронуто, какой impact на NSM, результаты эксперимента. VP Product зафиксировал: количество фич, попадающих в roadmap без валидации, снизилось с 80% до 15%.
Результаты через 2 квартала
- Time-to-market сократился на 35% — от идеи до релиза 2–3 месяца вместо 4–6
- Adoption новых фич вырос с 40% до 81% — команды строят то, что реально нужно
- «Кладбище фич» сократилось: только 15% релизов имеют adoption ниже 10% (было 60%)
- 4 команды самостоятельно проводят customer interviews каждый спринт
- Roadmap строится на данных Amplitude, а не на мнениях стейкхолдеров
"Мы перестали строить то, что не нужно. Это звучит просто, но изменить привычку команды — это большая работа."