Как вы расставляете приоритеты в бэклоге продукта?

Как расставлять приоритеты в бэклоге продукта

Это один из самых важных навыков PM. Каждый день я получаю больше идей, чем способна разработать команда. Нужна система приоритизации, иначе бэклог станет хаосом.

Уровень 1: Триаж (быстрая фильтрация)

Вопросы триажа:

1. Это критичный баг?
2. Это решает реальную боль пользователей?
3. Это входит в нашу стратегию?
4. У нас есть capacity это сделать?

После триажа:

• 80% идей отклоняю (слишком нишевые, не стратегические, вне vision)
• 15% идей идут в бэклог
• 5% идей идут сразу в sprint (критичные)

Уровень 2: Категоризация

1. Critical Bugs & Security

• Пользователи не могут работать
• Приоритет: СЕГОДНЯ

2. High-Impact Features

• Решают главную боль
• Улучшают revenue
• Приоритет: СПРИНТ

3. Maintenance & Tech Debt

• Рефакторинг, оптимизация
• Приоритет: 20% capacity в спринте

4. Nice-to-have & Polish

• UX улучшения, которые неявные
• Приоритет: КОГДА-НИБУДЬ

5. Experimentation & Research

• Новые направления, A/B тесты
• Приоритет: 10% capacity

Уровень 3: RICE Scoring

RICE = (Reach × Impact × Confidence) / Effort

Пример:

Идея A: Email templates

• Reach: 2000 пользователей в месяц
• Impact: 2x (сокращает время)
• Confidence: 90%
• Effort: 2 недели
• RICE = (2000 × 2 × 0.9) / 2 = 1800

Идея B: Slack интеграция

• Reach: 500 пользователей
• Impact: 1x
• Confidence: 80%
• Effort: 3 недели
• RICE = (500 × 1 × 0.8) / 3 = 133

Идея A имеет приоритет (RICE в 13x выше).

Уровень 4: Qualitative Factors

1. Strategic Alignment

• Входит ли в OKR квартала?
• Если да, приоритет растёт

2. Dependency Tracking

• Если фича A нужна для B, A идёт первой

3. Customer Segment Value

• 80% revenue из Enterprise → их запросы выше
• Но не игнорирую меньшие сегменты

4. Urgency of Bugs

• Баг ломает 50% пользователей → сегодня
• Баг ломает 1% → планово

5. Competitive Pressure

• Конкурент запустил фичу → может быть выше приоритета

Уровень 5: Sprint Planning

Распределение capacity:

• 70%: высокоприоритетные фичи
• 20%: техдолг
• 10%: экспериментация

Процесс:

1. Берём top фичи из отсортированного бэклога
2. Обсуждаем с разработчиками
3. Делаем task breakdown
4. Проверяем dependencies
5. Финальная оценка

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

30 идей входит → 15 остаётся после triager

Топ 3 после RICE scoring:

1. Fix slow reports (RICE 4500)
2. Email templates (RICE 1800)
3. Improve search (RICE 1425)

После qualitative adjustment:

1. Fix slow reports (1 неделя)
2. Database migration (2 недели)
3. Improve search (2 недели)
4. Email templates (1 неделя)
5. Techdebt: API improvements (0.5 недели)

В бэклог (later):

• Slack integration
• Dark mode
• Остальные идеи

Уровень 6: Continuous Reprioritization

Каждую неделю я пересматриваю:

• Появились ли новые баги?
• Появилась ли новая информация?
• Изменилась ли стратегия?

Это не значит, что я меняю приоритеты каждый день. Но я готов адаптировать.

Частые ошибки

1. Ловушка громких голосов CEO просит фичу → не должна автоматически идти в top. Оцениваю impact и alignment.

2. Ловушка просто потому что просили 5 запросов на feature X не значит это важно для 5000 пользователей. Проверяю % от базы.

3. Ловушка технолог влюбился Техдолг важен, но не всегда top приоритета. Распределение: 70% фичи, 20% техдолг, 10% эксперименты.

4. Ловушка слишком много экспериментов Хочу тестировать всё, но это замораживает разработку. 10% capacity экспериментация и не больше.

Коммуникация приоритетов

"Вот наш бэклог на месяц.

Sprint 1 (top приоритет):

1. Исправить баг с медленными отчётами (30% пользователей)
2. Database migration (техдолг, нужна для поиска)

Sprint 2: 3. Email templates (экономит 2 часа в неделю) 4. Улучшить поиск (50% пользователей просили)

Потом (lower приоритет): 5. Slack integration (8% пользователей) 6. Dark mode (nice-to-have)

Если у вас есть идея выше, расскажите. Я пересчитаю."

Ключевой вывод

Приоритизация это комбинация:

1. Данных (RICE, метрики)
2. Стратегии (OKR alignment)
3. Интуиции (знание пользователей)
4. Политики (CEO, board, customers)
5. Реальности (что может разработать команда)

Хороший PM:

• Использует фреймворки, но не рабски
• Пересматривает при новой информации
• Коммуницирует обоснование
• Защищает бэклог от хаоса
• Признаёт ошибки в приоритизации

Лучший способ расставить приоритеты — иметь ясное видение продукта и дисциплину его придерживаться.