По каким параметрам будешь оценивать фичи

Параметры оценки фич: фреймворк для приоритизации

Это фундаментальный вопрос для PM'а. Как выбрать какую фичу делать? Это зависит от многих факторов. Давайте разберемся в деталях.

My RICE Framework для оценки фич

Я использую RICE, который пришел из Intercom (Carta Yates, product leader):

RICE = (Reach × Impact × Confidence) / Effort

Каждый параметр:

R — Reach (охват): Сколько люди будут affected?

• Измеряю в: users/month, % of user base, customer segments affected
• Пример:
  • Фича для 10% users = 10
  • Фича для 100% users = 100
  • Фича для premium users only = 30

I — Impact (влияние): Какой impact на user, business?

• Массивный: 3x improvement (e.g., 3x faster loading)
• Значительный: 2x improvement
• Средний: 1.5x improvement
• Минимальный: 1.25x improvement
• Пример:
  • Фича что спасает 1 час в день для user = Massive (3)
  • Фича что улучшает process на 20% = Significant (2)
  • Фича что nice-to-have = Minimal (1)

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

• High confidence: 100% (мы знаем это от customers)
• Medium confidence: 50% (educated guess)
• Low confidence: 25% (диких спекуляции)
• Пример:
  • 100 customers просили feature = High (100%)
  • 5 customers просили, но не sure = Medium (50%)
  • Boss said может быть нужна = Low (25%)

E — Effort (затраты): Сколько work нужно?

• Измеряю в: weeks, months, engineer-months
• Пример:
  • 1 неделя = 1
  • 4 недели = 4
  • 3 месяца = 12

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

Фича A: Improve search results

Reach: 60% of users (60)
Impact: Significant (2x better UX) = 2
Confidence: 80% (we know search is problem) = 80%
Effort: 4 weeks = 4

RICE = (60 × 2 × 0.8) / 4 = 96 / 4 = 24

Фича B: New export format

Reach: 15% of users (15)
Impact: Significant (solves real problem) = 2
Confidence: 100% (customers requesting) = 100%
Effort: 1 week = 1

RICE = (15 × 2 × 1) / 1 = 30 / 1 = 30

Фича C: Dark mode

Reach: 40% of users (40)
Impact: Minimal (nice-to-have) = 1
Confidence: 60% (assume 60% want) = 60%
Effort: 2 weeks = 2

RICE = (40 × 1 × 0.6) / 2 = 24 / 2 = 12

Ranking:

1. Фича B (30) — лучший score
2. Фича A (24) — второй
3. Фича C (12) — третий

Это не говорит что C bad, но B and A выше priority.

Дополнительные параметры (кроме RICE)

Beyond RICE, я смотрю на:

1. Strategic Alignment

• Aligned ли фича с company strategy и vision?
• Если strategy это "improve retention", то retention features > growth features
• Пример: "We're focusing on enterprise this year" → features for enterprise get boost

2. Customer Requests (Frequency & Importance)

• Как много customers просили эту фичу?
• Насколько important это для них?
• Если 10% customers просили, но это make-or-break для них → important
• Если 50% customers просили, но это nice-to-have → less important

3. Competitive Necessity

• Есть ли фича у конкурентов?
• Это hurting нас в sales?
• Пример: "Competitor имеет feature, losing deals because of it" → higher priority

4. Technical Debt Payoff

• Улучшит ли фича our technical foundation?
• Будет ли она enable future features?
• Иногда low-reach feature имеет high strategic value

5. Team Velocity Impact

• Если фича улучшает productivity инженеров → может быть worth doing
• Пример: "Better testing tools" (нет direct user impact но helps team move faster)

6. Risk & Dependencies

• Есть ли технические риски?
• Зависит ли от других features?
• Может ли break existing functionality?
• High-risk фичи нужны более careful planning

Я использую Multi-Dimensional Grid

Не хочу relying on RICE scores alone (это может быть misleading).

Я создаю матрицу:

              VALUE (Impact + Reach + Alignment)
           Low    │    Medium    │    High
    ────────────────────────────────────────────
    Low  │  Skip  │   Maybe     │  Do it!
 E       │        │             │
 F      ────────────────────────────────────────
 F    Medium│Maybe   │    Do it!   │ Top priority
 O    │        │             │
 R    ────────────────────────────────────────
 T  High │  Skip  │  Consider   │ MUST DO
        │        │             │

Interpretation:

• Low effort + High value: Do immediately
• High effort + High value: Plan properly, do it
• Low effort + Low value: Skip (time wasters)
• High effort + Low value: Avoid (unless strategic)

Пример из реальной жизни

Сценарий: Planning next quarter

Нас просят 10 features.

Ranking:

1. Feature C (RICE 40, Low effort) → Do first
2. Feature A (RICE 37.5, Strategic) → Do second
3. Feature D (RICE 25, Strategic) → Do third
4. Feature B (RICE 18, Low strategic) → Backlog
5. Feature E (RICE 2.5, Low value) → Skip

Когда RICE breaks down

There are exceptions где я не слушаю RICE:

1. Regulatory/Compliance

• Must have регулятивный requirement? → Do it regardless of RICE
• Пример: "GDPR требует feature X" → Do it

2. Critical Bugs/Issues

• Много customers complaining? → Fix immediately
• Production down? → Drop everything

3. Strategic Bets

• Company making big bet? → Support it even if RICE low
• Пример: "CEO decided to enter new market" → build features for that

4. Team Morale

• Sometimes build fun feature team requested? → OK for morale
• But don't overdo it

Коммуникация оценки

Когда я present RICE scores к team:

❌ Не делаю:

• "Math says Feature X, so we doing it" (sounds robotic)

✅ Делаю:

• "Based on our analysis, Feature C solves immediate pain for most users"
• "Here's the RICE breakdown, but let's discuss if I missed anything"
• "This one has low score, but strategic value. Here's why we should still consider it."

My recommendation framework

Ideal scenario:

1. All features evaluated using RICE
2. Top features discussed с team
3. Strategic alignment reviewed
4. Dependencies checked
5. Final decision made together (not just by PM)

Quarterly planning:

• Pick top 3-5 features with high RICE
• Ensure mix of strategic value
• Ensure no dependencies conflicts
• Leave 20% capacity for bugs, tech debt

Conclusion

RICE это good framework, но не perfect. I use it as starting point, then apply judgment based on:

• Strategic alignment
• Customer feedback
• Competitive landscape
• Technical considerations
• Team capacity
• Risk assessment

Best PM's don't blindly follow scores. They use frameworks as guide, then apply their judgment, experience, и data combined.