Не ждали? А вот оно, возвращение в тг-канал с громким заголовком:

"Как Product Ops и метрики потока сократили время разработки фичей в 4 раза"

Хочу поделиться интересным кейсом, как выстроенные процессы операционной работы над продуктовм (Product Ops) помогли нам в Metamap в 2022-2023 сократить время реализации фичей с 244 до 93 дней.

В чем была проблема?

Классическая ситуация: продажники обещают клиентам новые функции, инженеры не успевают их реализовать, приоритеты постоянно меняются, короче - все недовольные и злые.

Если измерить время реализации большинства фичей - оно достигало 8 месяцев! Для стартапа с ограниченным финансированием это катастрофа (я пару лет назад писал что наступила венчурная зима).

Чего мы сделали: выстроили процесс Product Ops через метрики потока:

1️⃣ Провели STATIK*-воркшоп

STATIK-это стандартный инструмент внедрения Kanban. Это фактически несколько этапов, на которых мы рисуем наш e2e процесс, смотрим на бутылочные горлышки, обсуждаем текущую картину (и в идеале To Be картину).

Я будучи Product Ops-лидом провел воркшоп, собрав вместе отделы продаж, продукта и разработки. Мы совместно составили карту реального рабочего процесса от рождения идеи до замера её эффективности на проде. Ну и выявили узкие места, разумеется.

2️⃣ Создание единого источника правды

Для трекера / тикетной системы мы выбрали Jira Product Discovery - тогда еще сырой и в beta-версии, он уже умел интегрироваться с кучей инструментов и давал возможность сделать ICE/RICE.

Так, все запросы на фичи оказались собраны в одном месте с интеграцией с Salesforce, Gong (система звонков и продаж), HubSpot. Это обеспечило полную прозрачность для всех отделов: тыкаешь в Idea / Feature Request в жире - видишь сколько денег принесет идея, какие клиенты её хотят, какой горизонт прогноза прибыли.

3️⃣ С боем и кровью договорились про правила приоритизации

Правило "3×3":
1. функция продвигается только если её запросили 3+ активных клиента,
2. с ожидаемым ARR (Annual Recurring Revenue - ожидаемая прибыль, которая повторяется каждый год) выше порогового значения
3. Фича прямо связана с ключевыми метриками продукта (от которых у нас построены цели на год+).

4️⃣ Визуализировали ключевые метрики потока

• Пропускная способность (Throughput): количество реализованных фичей в месяц
• Время цикла (Cycle Time): с целью не более 90 дней
• Ограничение WIP: не более 2 фичей на команду одновременно

Почесали репу, посмотрели на данные исторически:
Инженерная команда могла обработать только 1/4 поступающих запросов, и визуализация этого факта помогла обосновать необходимость жестких правил приоритизации.

В итоге получилось вот что:

✅ Время выполнения сократилось в 2,6 раза (до 93 дней)
✅ 76% выпущенных фичей напрямую связаны с ключевыми метриками (было ниже 40%)
✅ Продажники перестали обещать нереализуемые сроки (ведь мы потом смотрели на данные и проверяли прогнозы)
✅ Выросло доверие между отделами (это, наверное, стало самым классным инструментом синергии внутри компании)

Итого, вот вам рецептик:
1. Интегрируйте системы для создания единой картины (CRM + тикет-система)
2. Визуализируйте метрики потока для всех отделов — это устраняет эмоции и домыслы
3. Внедряйте строгую дисциплину приоритизации
4. Обязательно измеряйте результат после внедрения фичей

Если ваша команда страдает от затянутых сроков разработки и конфликтов между отделами, внедрение Product Ops-подходов с фокусом на метрики потока может стать решением проблемы. Тут у Анвара есть целый пост про книжку про Product Operations.