prioritize

/prioritize

O que essa skill faz

Aplica RICE scoring (Reach, Impact, Confidence, Effort) + contexto de negócio para priorizar backlog.

Saída: Backlog priorizado com scores, trade-offs explícitos, e recomendação de sequência.

---

Quando usar

• Tem 5+ features/ideias e não sabe por onde começar
• Stakeholders discordam sobre prioridade
• Precisa explicar por quê escolheu A antes de B

---

Input esperado

Mínimo:

• Lista de features/ideias: Nomes e breves descrições
• Contexto de negócio: Metas desse trimestre
• Constraints: Team size, deadline

Opcional:

• Dados de impacto (churn reduction, revenue, CAC)
• Dependências técnicas
• Recursos de discovery já feitos

---

Processo

1. RICE scoring — Cada feature scores em 4 dimensões
2. Ranking: Divide by effort, ordena por score
3. Trade-offs: Se top 3 não cabem, qual deixa?
4. Sequência: Ordem de execução considerando dependências
5. Roadmap: Qual sprint faz qual feature?

---

Output

# Priorização: [Nome do Trimestre ou Iniciativa]

## Contexto

### Metas desse trimestre
- [Meta 1]
- [Meta 2]
- [Meta 3]

### Constraints
- Team: [X eng, Y design, Z PM]
- Timeline: [Semanas disponíveis]
- Dependências: [O que bloqueia]

---

## RICE Scoring

### Explicação de cada dimensão

**Reach** (alcance de usuários)
- 100+ = 3 pontos
- 10-100 = 2 pontos
- 1-10 = 1 ponto

**Impact** (tamanho do efeito em cada usuário)
- Massivo (+50% métrica) = 3 pontos
- Grande (+10-50%) = 2 pontos
- Pequeno (+1-10%) = 1 ponto

**Confidence** (quão certo você está dos números)
- Muito certo (dados/descoberta) = 100%
- Confiante (validação informal) = 80%
- Suposição (hipótese não testada) = 50%

**Effort** (semanas de trabalho)
- RICE = (Reach × Impact × Confidence) / Effort
- Maior score = maior prioridade

---

## Features Priorizadas

| # | Feature | Reach | Impact | Conf | Effort | Score | Razão |
|---|---------|-------|--------|------|--------|-------|-------|
| 1 | [Feature A] | 3 | 3 | 100% | 2 | **4.5** | Alinha com meta 1, dados sólidos |
| 2 | [Feature B] | 2 | 2 | 80% | 3 | **1.07** | Nice-to-have, menos urgente |
| 3 | [Feature C] | 3 | 1 | 50% | 5 | **0.3** | Risky, sem validação ainda |

---

## Top 3 Recomendados

### 1. [Feature A] — Score 4.5 ⭐ Recomendado

**Caso de negócio**
- Reach: 200+ usuários (30% da base)
- Impact: +25% engagement (de 60% para 75%)
- Esforço: 2 semanas
- Alinha com: Meta 1 (Aumentar engagement)

**Detalhe**
- Já temos descoberta completa
- Risk baixo (feature similar existe no competitor)
- Quick win 1º

**Se fizer agora**
- Go-live: Semana 2
- Impacto esperado: +X MRR em 30 dias

---

### 2. [Feature B] — Score 1.07 ⭐ Considerar se tempo sobra

**Caso de negócio**
- Reach: 50 usuários (7% da base)
- Impact: +15% NPS (de 35 para 50)
- Esforço: 3 semanas
- Alinha com: Meta 2 (Customer satisfaction)

**Detalhe**
- Valor alto para essas 50 users mas impacto baixo no todo
- Confiança: 80% (validação com 5 clientes)
- Medium risk (requer integração externa)

**Se fizer depois**
- Seria prioridade para Q2
- Mantém cliente quality alta

---

### 3. [Feature C] — Score 0.3 ❌ Defer para Q2

**Caso de negócio**
- Reach: 150+ usuários
- Impact: +5% conversão (de 10% para 15%)
- Esforço: 5 semanas
- Alinha com: Meta 3 (Growth)

**Detalhe**
- HUGE incerteza (hipótese não testada)
- Effort alto = risco
- Recomendação: Validar com experimento ANTES de PRD

**Se não fizer agora**
- Não afeta trimestre
- Ganho tempo para validar melhor no Q2

---

## Trade-offs Explícitos

### Cenário A: Time pode fazer 2 features em paralelo

Semana 1-2: Feature A (1ª eng + design) Semana 1-3: Feature B (2ª eng) Semana 4: Buffer/polish

✅ Vantagem: Máximo impacto, ambas saem no mês
❌ Desvantagem: Team estressado, possível delay

### Cenário B: Time faz 1 feature por vez

Semana 1-2: Feature A → go-live Semana 3-5: Feature B → go-live Semana 6: Buffer

✅ Vantagem: Menos stress, mais qualidade, time pode responder bugs
❌ Desvantagem: Feature B sai mais tarde, possível pierde market window

### Recomendação
**Scenario B** — Feature A é quick win, deixa time com morale boost. Feature B é lower priority assim.

---

## Roadmap recomendado

### Semana 1-2: Feature A (MVP)
- Lançamento: Final da semana 2
- Métrica target: 20% de users ativos
- Go/No-go: Se < 10% de users adoptam, voltar ao drawing board

### Semana 3-5: Feature B (se aprovado)
- Dependência: A saiu + feedback coletado
- Lançamento: Final da semana 5
- Métrica target: 50% de segment satisfaction

### Semana 6: Polish/buffer
- Bugs de A ou B
- Surpresas

---

## O que fazer com Feature C

**Não é "cancela", é "defer + validate"**

1. Semana 1: Desenhar experimento para testar hipótese de C
2. Week 2-3: Rodar experimento com 100 usuários
3. Week 4: Análise — se validado, goes para Q2 roadmap como P0

Dessa forma, Q2 começa com Feature C já validado, sem risco.

---

## Aprovação

- [ ] PM: Priorização alinhada com metas
- [ ] Eng Lead: Estimates realistas
- [ ] Executive: Trade-offs aceitáveis

**Decisão**: [Feature A] vai para próximo sprint
**Data**: ________
**Próxima review**: [2 semanas, ou quando nova ideia aparecer]