Как вы решаете, какие функции внедрять, а какие нет?

Как решать, какие фичи внедрять, а какие нет

Это один из самых важных вопросов в Product Management. Ежедневно я получаю десятки предложений: от пользователей, от команды, от CEO. Нужна система выбора, иначе будешь разрываться.

Расскажу свой процесс и frameworkы, которыми я пользуюсь.

1. Источники идей и первичная фильтрация

Откуда приходят идеи:

• User requests (most common source)
• Support/customer success feedback
• Аналитика: где падают пользователи, что игнорируют
• Конкуренты и тренды в индустрии
• Интуиция и vision PM

Первичная фильтрация (за 5 минут):

Есть простые вопросы, которые сразу отсеивают 80% идей:

1. Это решает проблему пользователей или это vanity feature?

   • Хороший сигнал: "Это заняло у меня 30 минут, я хочу сэкономить"
   • Плохой сигнал: "Было бы красиво, если бы..."

2. Это входит в наш vision продукта?

   • Если мы позиционируем себя как analytics tool, не строим marketplace
   • Нет = отклонить, даже если это запросили

3. Это критично или можно ждать?

   • Critical fix = приоритет
   • Nice-to-have = в очередь

После первичной фильтрации: Идеи, которые пролезли через эти три вопроса, идут в backlog на глубокий анализ.

2. Framework RICE для приоритизации

Это мой основной инструмент. RICE расшифровывается как:

R — Reach (охват) Сколько пользователей затронет эта фича в определённый период (месяц)?

• Оценка: в пользователях или в % активной базы
• Пример: "1000 пользователей в месяц" или "10% базы"

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

• 3x = massive impact (меняет основную боль)
• 2x = high impact (значительное улучшение)
• 1x = medium impact (заметное улучшение)
• 0.5x = low impact (nice-to-have)

C — Confidence (уверенность) Насколько ты уверен в своих оценках?

• 100% = точно знаю
• 50% = размытая информация
• 25% = угадываю

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

• В идеале 1-4 недели на одну фичу

Формула: RICE Score = (Reach × Impact × Confidence) / Effort

Пример 1: Добавить экспорт в PDF

• Reach: 500 пользователей в месяц (5% базы)
• Impact: 1x (nice-to-have, не решает боль)
• Confidence: 90%
• Effort: 1 неделя
• RICE = (500 × 1 × 0.9) / 1 = 450

Пример 2: Улучшить скорость загрузки отчётов

• Reach: 5000 пользователей в месяц (50% базы)
• Impact: 2x (сокращает время ожидания)
• Confidence: 100%
• Effort: 2 недели
• RICE = (5000 × 2 × 1.0) / 2 = 5000

Пример 2 намного выше, поэтому он имеет приоритет.

3. Framework Jobs to be Done (JTBD)

Это более качественный подход. Вместо "что пользователь просит", я спрашиваю "какую работу пользователь хочет выполнить?"

Пример: Пользователь просит: "Добавьте встроенный калькулятор."

Вопрос: "Зачем тебе калькулятор?" Ответ: "Мне нужно быстро проверить, что эти числа складываются правильно."

Реальная работа: "Я хочу убедиться в корректности данных без переключения в другое приложение."

Решение: не калькулятор, а встроенная проверка формул и validation.

Как это помогает: Зачастую предложенное решение не лучшее. JTBD помогает найти корневую причину и правильное решение.

4. Data-driven анализ

Данные говорят лучше, чем интуиция.

Что я анализирую:

1. Feature adoption: какой % пользователей использует текущие фичи?

   • Если новая фича похожа на старую, которую 10% используют, зачем делать?

2. Correlation analysis: коррелирует ли использование фичи с retention или revenue?

   • Пользователи, которые используют Feature X, имеют 30% выше retention
   • Это signal, что Feature X важна

3. Churn анализ: почему уходят пользователи?

   • Если 30% ушли из-за отсутствия API, это priority
   • Если 2% ушли из-за missing calculator, это низкий приоритет

4. Request frequency: как часто просят эту фичу?

   • 1 запрос в месяц = не приоритет
   • 10 запросов в неделю = attention required

5. Вес разных категорий фич

Не все фичи одинаковые. Я классифицирую их:

Tier 1 — Critical (ДЕЛАЮ ВСЕГДА)

• Баги, которые ломают основную функциональность
• Pain points, которые приводят к churn
• Интеграции, которые просят крупные клиенты

Tier 2 — Valuable (ДЕЛАЮ ЧАСТО)

• Фичи, которые 10%+ пользователей просили
• Функции, которые коррелируют с revenue
• Улучшения, которые заметно улучшают UX

Tier 3 — Nice-to-have (ДЕЛАЮ РЕДКО)

• Фичи, которые просили < 5% пользователей
• Polish and polish features
• Фичи, которые не влияют на основную боль

Tier 4 — Vanity (НЕ ДЕЛАЮ)

• "Было бы красиво"
• Очень дорогие в разработке
• Не входят в vision

6. Стратегический контекст

Даже если фича имеет высокий RICE score, нужно спросить: "Входит ли это в нашу квартальную стратегию?"

Пример: Маркетинг просит мобильное приложение (высокий потенциал). Но наша стратегия на Q3: "Стать лидером по B2B аудитории". Мобильное приложение отвлекает от этой цели.

Решение: отложить мобильное приложение на Q4.

OKR alignment: Каждая фича должна коррелировать минимум с одним OKR квартала.

• OKR: "Увеличить revenue на 50%"
• Фича: "Premium план с Advanced analytics"
• Alignment: ясный

7. Customer segmentation

Разные сегменты нуждаются в разных фичах.

Пример:

• Enterprise просит API, white-label, SSO
• SMB просит простоту, быстроту, low cost
• Startup просит flexibility, growth tools

Я не могу сделать всё для всех. Приоритизирую сегмент, который приносит больше дохода или имеет выше potential.

Если 80% revenue из Enterprise: Capitalize на Enterprise запросах.

Если растущий сегмент — Startup: Инвестирую в их нужды, даже если текущий revenue меньше.

8. Technical debt vs features

Это вечный баланс.

Когда приоритизирую техдолг:

• Техдолг блокирует новые фичи (e.g., архитектура)
• Техдолг приводит к багам (e.g., legacy code)
• Техдолг замедляет разработку (e.g., медленная БД)

Правило: 80/20 Обычно я выделяю 20% capacity на техдолг, 80% на фичи.

Если техдолг критичен, балансирую.

9. Как я коммуницирую отказ

Не просто говорю "нет", объясняю "почему не сейчас":

"Спасибо за идею экспорта в PDF. Я вижу ценность. Сейчас мы фокусируемся на улучшении core analytics, потому что это основная боль для 50% пользователей. PDF экспорт может подождать Q4. Если до тогда будет достаточно просьб, переоценим приоритет."

Это дает:

• Уважение к идее
• Ясную логику
• Условие, при котором это может измениться

10. Матрица приоритизации (быстро)

Для быстрого выбора из нескольких фич:

DO FIRST: высокий impact, низкий effort (quick wins) SCHEDULE: важно, но дорого DROP: низкий impact или вне vision

Практический пример моего выбора

Месячный backlog (15+ идей):

1. Баг: экспорт рушится на больших файлах → КРИТИЧНО (Tier 1)
2. Просьба от top-5 клиента: SSO → ПРИОРИТЕТ (Tier 1, revenue-driven)
3. UX улучшение: dark mode → NICE (Tier 2, 5% просили)
4. Маркетинговая идея: встроенный чат → ОТЛОЖИТЬ (не входит в vision)
5. Запрос: встроенный курс в продукте → SCHEDULE Q4 (Tier 3)

Финальный список на месяц:

1. Fix баг (3 дня)
2. SSO интеграция (2 недели)
3. Dark mode (1 неделя)
4. Техдолг на БД (1 неделя)

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

Приоритизация фич это не просто выбор, это стратегия. Хороший PM:

1. Использует frameworks (RICE, JTBD, Impact/Effort matrix)
2. Основывается на данных (usage, churn, requests)
3. Слушает пользователей, но не рабски (JTBD подход)
4. Защищает vision (не идёт на поводу
5. Быстро говорит нет (к фичам не входящим в план)
6. Коммуницирует обоснование (даже в отказах)
7. Пересматривает при новой информации (не закрепляется за старыми решениями)

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