Вы узнаете, как накапливать знания о продукте и не терять достигнутые результаты, как настроить синхронизацию команд на уровне фреймворка и отслеживать реальный прогресс и изменения, даже если состав команды меняется.

Артефакты

• Ключевой дашборд
  • У вас должен быть ровно один дашборд, где на одном экране видны все ключевые цели команды, планы, статус и прогресс по ним (это может быть документ в Google Sheets, а может быть дашборд в Tableau).
  • Обеспечьте моделирование движения по каждой цели с гранулярностью до ваших итераций (недельные/двухнедельные).
  • Проектные цели каскадируются в роадмап по итерациям, метрики — в модель изменения.

• Реестр знаний
  • Продуктовые команды обязаны генерировать огромное количество информации: CustDev, эксперименты, исследования рынка, провалившиеся гипотезы, аналитика — это бесценный ресурс, но только если каждый член команды может быстро найти нужное и загрузить себе в мозг.
  •  Реестр должен быть:
    • Простым.
    • Легкодоступным.
    • Обеспечивать быстрый поиск.
  • Это такая база данных, мы, например, ведем её в Notion.

• Визуализация каскадирования целей
  • Команда должны всегда знать и понимать, как цели каскадируются друг от друга. Для этого им нужна визуализация.
  • В идеале это дерево целей (в Miro, например), где у каждой цели есть ссылка на дашборд с метрикой (если цель в метрике), либо DoD (если это проект).

• Реестр принципов принятия решений
  • Список правил, по которым мы работаем, с информацией о том, как принцип этот появился.

• Описание вашего фреймворка управления
  • В идеале это схема с визуализацией всего процесса, по которому идет задача / гипотеза / проект, с циклами итераций и встречами.
  • В базовом варианте — документ, где этот процесс описан текстом.

Пример визуализации каскадирования целей и процесса (часть схемы с описанием месячного планирования)

Принципы и процесс их дополнения

Рекомендую прочитать книгу Рэя Далио «Принципы», чтобы понять, зачем они вообще нужны.

Базовые принципы, которые можно применять с самого начала

• На каждой встрече жестко зафиксированы: ведущий встречи, Agenda и тайминг.
• Любая продуктовая гипотеза должна пройти стадии Research → Development → Valuation.
  • Тут ключевой смысл в том, что нельзя бросаться рисовать / разрабатывать, не проведя исследование. И нельзя разработать, выкатить и не подвести итог (откатываем, оставляем, смотрим, как поменялись метрики и т.д.).

• Любая продуктовая гипотеза должна закончиться резолюцией, а также коротким итогом: какие новые знания мы получили. Итог должен быть внесен в реестр знаний.
• Любой проведенный ресерч должен быть внесен в реестр знаний, протегирован, сопровожден краткой выжимкой.
• Любая гипотеза до старта дизайна или разработки должна быть описана в терминах решаемой проблемы пользователя и влияния на целевую метрику.
• Мы не берем в работу гипотезы и просто задачи, которые не направлены на наши проектные цели или целевые метрики.
• Дизайнер не может начать рисовать макет, не прочитав доступные исследования на тему поставленной проблемы пользователя.
• Разработчик не может взять в работу задачу, если не понимает ее бизнес-ценность.
• Каждая гипотеза в статусе Valuation должна иметь ссылку на дашборд с отслеживаемой метрикой.

Ключевая задача принципов — сделать прозрачным и простым процесс принятия решений. Реестр принципов — это основа вашего уникального фреймворка.

Процесс изменения принципов должен быть аналогичным работе над продуктом, каждую ретроспективу команда собирается и проходит цикл:

• Анализ изменений принципов с предыдущей ретроспективы (как повлияло на процесс, какие итоги итерации).
• Генерация новых изменений принципов (Start, Stop, Continue).
• Фиксация их в реестр принципов (новые добавили, лишние удалили, обновленные поменяли).
• Работа в новой итерации по новым принципам.

Проверьте себя

• У вас есть регулярные встречи по всем циклам планирования. Пример: год, квартал, неделя.
  • По каждой есть Agenda и ведущий.
  • У вас есть регулярные f2f встречи с сотрудниками.

• По ключевым проектам — отдельные регулярные синки.
• Каждый цикл есть ретроспектива.
• Есть ключевой дашборд команды.
• Есть реестры знаний и принципов.
• Визуализировано и обновляется каскадирование целей.
• Каждый сотрудник легко может:
  • Сказать какие у команды цели и в какой они зоне (красная / зеленая).
  • Найти любое известное знание о пользователях / рынке / конкурентах.
  • Какие встречи он должен посещать в рамках фреймворка управления.