Sem priorização = time constrói features que ninguém usa.
Dados Pendo (2023): 40% das features desenvolvidas são raramente ou nunca usadas.
Custo: R$ 80-200K desperdiçados por ano em features erradas.
Com priorização estruturada:
- Features de alto impacto primeiro
- Alinhamento time/stakeholders
- ROI mensurável
Este artigo mostra framework completo de priorização de features.
O problema: Feature factory
Sintomas:
- “Precisamos de X” → Time desenvolve X sem questionar
- Roadmap = wishlist de stakeholders
- Features lançadas mas não usadas
- Time frustra-do (trabalho não gera impacto)
Exemplo real: SaaS gastou R$ 120K desenvolvendo “exportar para Excel” porque 1 cliente enterprise pediu. Resultado: 8% dos usuários usaram (1x apenas).
Custo de oportunidade: Poderia ter feito feature Y (pedida por 60% dos usuários, usado semanalmente).
Framework RICE (priorização)
RICE = Reach × Impact × Confidence / Effort
Fórmula:
RICE Score = (Reach × Impact × Confidence) / Effort
Reach: Quantas pessoas afeta por trimestre?
Impact: Quanto impacta cada pessoa? (0.25, 0.5, 1, 2, 3)
Confidence: Quão certo você está? (50%, 80%, 100%)
Effort: Quanto tempo (person-weeks)?Exemplo prático:
// lib/prioritization/rice.ts
interface Feature {
name: string
reach: number // Usuários afetados/trimestre
impact: number // 0.25 (minimal), 0.5 (low), 1 (medium), 2 (high), 3 (massive)
confidence: number // 0.5 (low), 0.8 (medium), 1 (high)
effort: number // Person-weeks
}
function calculateRICE(feature: Feature): number {
return (feature.reach * feature.impact * feature.confidence) / feature.effort
}
// Exemplos
const features: Feature[] = [
{
name: 'Exportar para Excel',
reach: 80, // 80 usuários/trimestre
impact: 0.5, // Low impact (uso pontual)
confidence: 1.0, // Alta certeza (cliente pediu)
effort: 8 // 8 person-weeks
},
{
name: 'Notificações push',
reach: 1200, // Todos os usuários
impact: 2, // High impact (engagement)
confidence: 0.8, // Média certeza (não validado)
effort: 4 // 4 person-weeks
},
{
name: 'Dark mode',
reach: 600, // 50% usuários (mobile)
impact: 0.5, // Low impact (nice-to-have)
confidence: 1.0,
effort: 2 // 2 person-weeks
},
{
name: 'Busca avançada (filtros)',
reach: 900, // 75% usuários
impact: 2, // High (core feature)
confidence: 1.0, // Alta (dados de analytics)
effort: 6 // 6 person-weeks
}
]
// Calcula RICE para todas
const prioritized = features
.map(f => ({
...f,
riceScore: calculateRICE(f)
}))
.sort((a, b) => b.riceScore - a.riceScore)
/*
Resultado:
1. Busca avançada: 300 (900 × 2 × 1 / 6)
2. Notificações push: 480 (1200 × 2 × 0.8 / 4)
3. Dark mode: 150 (600 × 0.5 × 1 / 2)
4. Exportar Excel: 5 (80 × 0.5 × 1 / 8)
Prioridade: Notificações > Busca > Dark mode > Excel
*/Insight: “Exportar Excel” tem RICE baixíssimo (5) vs “Notificações push” (480). Fazer push primeiro.
Jobs-to-be-Done (entender o porquê)
Framework JTBD: Pessoas “contratam” produtos para fazer um “job” (trabalho).
Pergunta certa: “Que job o cliente está tentando fazer?”
Exemplo:
Feature pedida: “Quero integração com Google Calendar”
Job real: “Preciso saber minha agenda sem abrir 3 apps”
Soluções possíveis:
- Integração Google Calendar (8 weeks)
- Widget de agenda (2 weeks) ← Resolve 80% do job em 25% do tempo
Como descobrir JTBD:
Entrevista (30min com 10-20 clientes):
P: Por que você usa [produto]?
R: Para gerenciar agendamentos.
P: O que você fazia antes de usar nosso produto?
R: Planilha Excel + WhatsApp.
P: O que te motivou a mudar?
R: Muitos no-shows (20%), perdia R$ 3K/mês.
P: Como nosso produto resolve isso?
R: Confirmação automática reduziu no-shows para 4%.
✅ Job real: "Reduzir no-shows" (não "gerenciar agendamentos")Priorização baseada em JTBD:
- Features que resolvem job principal = alta prioridade
- Features que resolvem job secundário = média
- Features “nice-to-have” = baixa
Fontes de input (de onde vêm as ideias)
1. Clientes (direto):
- Tickets de suporte (padrões)
- Entrevistas (10-20/mês)
- NPS feedback (detratores dizem o que falta)
2. Analytics:
- Features mais usadas → dobrar investimento
- Drop-off points → o que está quebrado
- Feature adoption rate → o que não funciona
3. Competidores:
- O que eles têm que você não tem?
- Cuidado: Copiar cegamente = perder diferenciação
4. Visão de produto:
- Onde queremos estar em 12 meses?
- Bets estratégicas (nem tudo vem de dados)
Template de feature request:
# Feature Request: [Nome]
## Solicitante
- Tipo: Cliente / Time interno / Stakeholder
- Fonte: Suporte ticket #123 / Entrevista / Analytics
## Problema
[Qual dor/job o cliente está tentando resolver?]
## Solução proposta
[O que cliente acha que resolve]
## Contexto
- Quantos clientes pediram: 12
- Frequência: Mensal / Semanal / Diária
- Segmento: Enterprise / SMB / Todos
## Impacto esperado
- Métrica: Retenção / Engagement / Conversão / NPS
- Estimativa: +15% retenção
## Alternativas
[Outras formas de resolver mesmo problema]
## RICE Score
- Reach: 800/trimestre
- Impact: 2 (high)
- Confidence: 80%
- Effort: 6 weeks
- **Score**: 213Roadmap trimestral (3 meses)
Estrutura: Temas, não features.
Exemplo (Q1 2027):
# Roadmap Q1 2027 (Jan-Mar)
## Tema 1: Reduzir churn (40% do capacity)
**Objetivo**: Churn de 5,2% → 3,5%
Features:
- [x] Health score automático (2 weeks)
- [x] Email re-engagement (at-risk users) (1 week)
- [ ] Onboarding v2 (feature tour) (4 weeks)
- [ ] In-app help widget (2 weeks)
**Meta de sucesso**: Churn <4% em março.
## Tema 2: Expansão de receita (30% capacity)
**Objetivo**: +R$ 15K MRR via upsell
Features:
- [ ] Plano Enterprise (features: SSO, SLA) (6 weeks)
- [ ] Usage-based pricing (API calls) (3 weeks)
- [ ] Self-serve upgrade flow (1 week)
**Meta**: 10 upgrades (R$ 1.5K each).
## Tema 3: Performance (20% capacity)
**Objetivo**: LCP <1.5s (atualmente 2.8s)
Features:
- [ ] Image optimization (WebP) (1 week)
- [ ] Code splitting (lazy loading) (2 weeks)
- [ ] CDN setup (Cloudflare) (1 week)
**Meta**: Core Web Vitals "Good" em todas as métricas.
## Tema 4: Debt técnico (10% capacity)
**Objetivo**: Reduzir bugs em 30%
- [ ] Refatorar autenticação (3 weeks)
- [ ] Testes E2E (checkout flow) (2 weeks)Alocação:
- 40% retention (maior ROI)
- 30% expansion
- 20% performance
- 10% tech debt
O que NÃO entra no roadmap: Features com RICE menor que 50.
Comunicação de roadmap
Interno (time)
Weekly planning (1h, segunda-feira):
- Review última semana (shipped, blocked)
- Plan esta semana (prioridades)
- RICE de novas features (se houver)
Sprint (2 weeks):
- Começa segunda, termina sexta
- Demo sexta (mostra o que foi feito)
- Retro (o que melhorar)
Externo (clientes)
Changelog público:
# Novidades - Dezembro 2026
## ✨ Notificações push
Agora você recebe alertas de novas aulas diretamente no celular!
Ative em: Configurações → Notificações
## 🔍 Busca avançada
Filtre professores por:
- Preço (R$ 50-200)
- Disponibilidade (manhã, tarde, noite)
- Avaliação (4.5+ estrelas)
## 🐛 Bugs corrigidos
- Pagamento com PIX agora processa em <5min
- Calendario não carregava em Safari (resolvido)Roadmap público (para clientes enterprise):
# Roadmap Q1 2027
🚀 **Em desenvolvimento**
- SSO (Single Sign-On)
- Relatórios avançados (BI)
🔮 **Planejado**
- Mobile app (iOS/Android)
- Integração Salesforce
💡 **Sob consideração**
- White-label
- API pública
Quer influenciar? Vote aqui: [link]Board de votação (Canny, Frill):
- Clientes votam em features
- Comentam casos de uso
- Você prioriza baseado em votos + RICE
Dizer “não” (a maior parte das ideias)
Regra 1:1:100: Para cada 100 ideias, 1 vira feature, 1 fica em backlog, 98 são rejeitadas.
Como dizer não:
Email de rejeição (mas mantém relacionamento):
Olá [Nome],
Obrigado pela sugestão de [feature X]!
Analisamos e, por enquanto, não vamos priorizar porque:
- Afeta apenas 5% dos usuários (reach baixo)
- Não está alinhado com nosso foco atual (reduzir churn)
Mas adoramos o feedback! Casos de uso assim nos ajudam
a entender melhor as dores.
Se houver outra forma de resolver seu problema, podemos
explorar juntos?
Abraço,
[PM]Alternativa: Ofereça workaround.
Enquanto [feature X] não está no roadmap, você pode:
1. Exportar dados via API
2. Usar integração com Zapier
3. [Workaround manual]
Precisa de ajuda para configurar?Métricas de roadmap
Trailing indicators (olham para trás):
- % features shipped on-time (meta: >80%)
- % features usadas (meta: >60% adoption em 3 meses)
- Impact score real vs estimado (validação de RICE)
Leading indicators (predizem sucesso):
- % do backlog com RICE calculado (meta: 100%)
- Tempo médio de decisão (pitch → aprovado/rejeitado) (meta: menos de 1 semana)
- % capacity alocado a high-RICE features (meta: mais de 70%)
Dashboard:
// Dashboard de produto
export const productMetrics = {
// Roadmap health
featuresShippedOnTime: 82, // % (meta: >80)
avgFeatureAdoption: 67, // % em 3 meses (meta: >60)
// Backlog health
backlogSize: 45, // Features total
highRICE: 12, // RICE >100
mediumRICE: 18, // RICE 50-100
lowRICE: 15, // RICE <50
// Execution
avgCycleTime: 3.2, // Semanas (ideia → produção)
scopeCreep: 15, // % features com scope aumentado
// Impact
featureROI: {
'Notificações push': {
effort: 4, // Weeks
impact: '+18% DAU',
roi: '450%' // Engagement vs custo
},
'Dark mode': {
effort: 2,
impact: '+3% NPS',
roi: '80%'
}
}
}Erros comuns
Erro 1: Roadmap de 12 meses
Problema: Mercado muda, 70% do roadmap vira obsoleto.
Correto: Roadmap trimestral (3 meses). Temas para 12 meses, features para 3.
Erro 2: Priorizar por HiPPO
HiPPO = Highest Paid Person’s Opinion.
Problema: CEO pede feature X, time faz sem questionar. X não é usado.
Correto: CEO sugere, PM analisa RICE, decide baseado em dados.
Erro 3: Feature creep
Sintoma: Feature simples vira complexa.
Exemplo:
- Original: “Exportar CSV” (2 days)
- Após creep: “Exportar CSV/Excel/PDF com templates customizáveis” (3 weeks)
Correto: Ship MVP, itera se houver demanda.
Erro 4: Não medir impacto
Problema: Lançou feature, nunca mediu se funcionou.
Correto: Toda feature tem success metric definida antes de desenvolver.
# Feature: Notificações push
**Hipótese**: Usuários que recebem notificações voltam 2x mais.
**Métrica de sucesso**: DAU/MAU aumenta de 42% para 50%
**Como medir**: Cohort analysis (push enabled vs disabled)
**Prazo**: 30 dias após lançamento
**Resultado real** (após 30 dias): DAU/MAU 48% (+14% vs baseline)
✅ Sucesso (não atingiu 50%, mas +14% é significativo)Template de roadmap (Notion/Linear/Jira)
# Roadmap Q1 2027
## Temas
### 🎯 Tema 1: Reduzir churn
**Owner**: PM João
**Capacity**: 40% (16 weeks total)
**Goal**: Churn 5.2% → 3.5%
| Feature | RICE | Status | Owner | ETA |
|---------|------|--------|-------|-----|
| Health score | 280 | ✅ Shipped | Dev A | Jan 15 |
| Email re-engagement | 180 | ✅ Shipped | Dev B | Jan 22 |
| Onboarding v2 | 320 | 🟡 In progress | Dev C | Feb 12 |
| Help widget | 150 | 📋 Planned | - | Mar 5 |
**Metrics**:
- Baseline: 5.2% churn
- Target: 3.5%
- Current: 4.1% ✅ On track
### 🚀 Tema 2: Expansão
[...]
## Backlog (RICE >100, não priorizadas este trimestre)
| Feature | RICE | Requester | Notes |
|---------|------|-----------|-------|
| API pública | 120 | 5 clientes enterprise | Q2 talvez |
| White-label | 105 | Cliente X (R$ 15K MRR) | Avaliar custo |
## Rejected (RICE <50)
| Feature | RICE | Why rejected |
|---------|------|--------------|
| Exportar Excel | 5 | Low reach, low impact |
| Integração Slack | 35 | Low confidence, better alternatives |Próximos passos
- Levantar todas as ideias (backlog)
- Calcular RICE para cada uma
- Priorizar top 10 (RICE >100)
- Definir temas trimestrais
- Alocar capacity (40% retention, 30% growth, 20% perf, 10% debt)
- Comunicar roadmap (interno + externo)
- Executar → Medir impacto → Iterar
Lembre-se: Roadmap é hipótese, não compromisso. Muda conforme você aprende.
Objetivo: Maximizar impacto (outcome), não output (quantidade de features).
Mantra: “Dizer não a 98% das ideias para dizer sim excelente aos 2% certos.”