Как приоритизировал фичи?

Как я приоритизировал фичи

Приоритизация фич — один из самых важных навыков Product Manager. Если приоритизировать неправильно, можно потратить целый квартал на то, что никому не нужно, а срочные проблемы остаются нерешённые.

Мой фреймворк приоритизации

Я использую комбинированный подход, который сочетает количественные и качественные методы.

Фаза 1: Генерация идей (Backlog)

Все идеи накапливаются в одном месте — backlog продукта:

• Запросы от пользователей (feedback, support tickets)
• Запросы от бизнеса (CEO, investors, sales)
• Собственные идеи команды (инженеры, дизайнеры)
• Конкурентный анализ (что делают конкуренты)
• Метрики и аналитика (что не работает хорошо)

На этом этапе я не отсеиваю ничего — просто собираю всё.

Фаза 2: Предварительная фильтрация (Feasibility)

Перед тем как глубоко анализировать, проверяю:

• Это вообще технически возможно? — спрашиваю Lead Engineer
• Это соответствует стратегии продукта? — или это случайная идея
• Это прямо сейчас критично? — может быть, это срочно

Отсеиваю явно плохие идеи (нереалистичные, off-strategy).

Фаза 3: Глубокий анализ (RICE или WSJF)

Для оставшихся идей я считаю две метрики: RICE и потенциальный доход.

RICE Framework

RICE = (Reach × Impact × Confidence) / Effort

Reach (Охват) — сколько пользователей это затронет?

• 10% базы юзеров = 1 балл
• 50% базы = 5 баллов
• 100% базы = 10 баллов

Impact (Влияние) — как сильно это повлияет на каждого пользователя?

• Минимальное = 1
• Среднее = 3
• Максимальное = 5

Confidence (Уверенность) — насколько я уверен в оценках Reach и Impact?

• Высокая (есть данные) = 100% = 1.0
• Средняя (есть гипотезы) = 50% = 0.5
• Низкая (просто предположение) = 25% = 0.25

Effort (Усилия) — сколько недель инженеров нужно на разработку?

• 1 неделя = 1
• 4 недели = 4
• 12 недель = 12

Пример расчёта RICE

Фича: "Рекомендации курсов"

• Reach = 8 (затронет 80% активных юзеров)
• Impact = 5 (сильно улучшит experience)
• Confidence = 0.8 (есть тесты, знаем ЧТО нужно, но не НА 100%)
• Effort = 8 недель

RICE = (8 × 5 × 0.8) / 8 = 32 / 8 = **4.0**

Фича: "Экспорт в PDF"

• Reach = 2 (нужна только 20% юзеров)
• Impact = 2 (улучшит, но не критично)
• Confidence = 0.9 (простая фича, уверены)
• Effort = 2 недели

RICE = (2 × 2 × 0.9) / 2 = 3.6 / 2 = **1.8**

Вывод: "Рекомендации курсов" важнее → делаем её первой, несмотря на большой effort.

Дополнительные критерии

RICE хороша, но это не всё. Я учитываю ещё:

1. Strategic Alignment (Стратегическое выравнивание)

Есть ли фича в roadmap компании на этот квартал?

• Aligned = приоритет выше
• Not aligned = может быть отложена

2. Dependencies (Зависимости)

Эта фича блокирует другие?

• Если она блокирует 3 других фич → приоритет выше
• Если она зависит от 5 других → может быть отложена

3. Time Sensitivity (Чувствительность ко времени)

Это срочно? Есть deadline?

• Регуляторные требования → СРОЧНО
• Договор с клиентом → СРОЧНО
• Конкуренты делают → ВАЖНО
• Интересная идея → может подождать

4. Risk Mitigation (Снижение рисков)

Эта фича снижает какие-то критические риски?

• Churn пользователей в фичи X → фиксим приоритет
• Падение выручки → фиксим приоритет
• Маркетинговая проблема → может быть другое решение

5. Team Velocity (Скорость команды)

Может ли команда это сделать сейчас?

• Инженеры перегружены → жди
• Дизайнер в отпуске → жди
• Есть capacity → делаем

Мой реальный процесс (Пример)

Ситуация: У нас есть 6 идей в backlog, sprint на 8 недель, team из 5 инженеров (40 недель capacity).

Моя приоритизация:

1. API для partners (10 недель) — time-sensitive, договор, хотя effort большой
2. Рекомендации (8 недель) — высокий RICE и revenue impact
3. Search (6 недель) — хороший RICE, улучшит experience
4. Analytics (4 недели) — нужно для принятия решений
5. Экспорт PDF (2 недели) — простая, low-hanging fruit
6. Dark mode (1 неделя) — nice to have, если будет время

Все, кроме Dark mode, влезят в 8 недель (10+8+6+4+2 = 30 недель < 40).

Инструменты для приоритизации

Я использую:

• Spreadsheet или Notion — простой RICE калькулятор
• Jira / Linear — для управления backlog
• Figma — для просмотра дизайна
• Metrics dashboard — для поиска влияния на revenue/retention
• Customer interviews — для валидации гипотез

Важные принципы

1. Переговариваемость

Приоритизация — это не ёинственное решение Product Manager. Я:

• Обсуждаю с инженерами (они иногда видят что-то, чего я не вижу)
• Проверяю с дизайном (может быть, дизайнеру нужно время на подготовку)
• Согласую с бизнесом (Sales может сказать, что клиент потеряется, если не сделаем)

2. Регулярный пересмотр

Приоритизация не случается один раз в квартал. Я пересматриваю её:

• Каждый спринт (2 недели) — если появилась критичная проблема
• Каждый месяц (планирование) — если изменилась стратегия
• При изменении данных (метрики, feedback) — если видим новое

3. Transparency (Прозрачность)

Все знают, почему мы делаем именно эту фичу в этот момент:

• Документирую решения
• Объясняю reasoning в спринт планировании
• Обновляю roadmap публично

Когда приоритизация может измениться

• Новая критичная ошибка — падает revenue или security issue
• Клиент потеряется — большой контракт, если не сделаем фичу
• Конкурент выпустил — нужно быстро ответить
• Инжиниры нашли неэффективность — они говорят: "если сейчас не сделаем, потом будет сложнее"

Итог

Хорошая приоритизация — это баланс:

• Данные (RICE, метрики) + интуиция (опыт, стратегия)
• Влияние (на юзеров, на revenue) + усилия (сколько стоит сделать)
• Долгосрочное видение + краткосрочные потребности (баги, критичные фичи)
• Мнение Product Manager + мнение команды + мнение бизнеса

Когда балансируешь все эти факторы, приоритизация становится эффективным инструментом для максимизации impact при ограниченных ресурсах.