05 — Roadmap e Priorização

BDFU (Big Design Upfront): documente o produto inteiro aqui antes de codar. Cada módulo em 04-features-modules.md vira uma spec em specs/NNN-nome/ (índice em specs/README.md). Ordem de implementação = dependências entre specs, não "MVP mínimo". Ver PLAYBOOK.md Fases 2–4.

<!-- EXEMPLO: produto fictício "SiteScope". Substitua pelo roadmap real do seu produto. -->

Horizontes

Expand table full width

Timeline (Gantt — 12 meses)

Janela rolling: Jun/26 → Mai/27. Atualize rótulos dos meses na revisão mensal. Substitua linhas pelo roadmap real do fork.

Legenda: █ dev · ░ spec/planejamento · ● ship/marco · vazio = fora do escopo no mês

Dependências (ordem de implementação): Scanner → Dashboard → Agendamento → Alertas → Relatórios → v1 launch → v1.1 → v2.

Expand table full width

Notas

• Scanner já em spec — Jun reservado para fechar spec e kickoff de dev.
• v1 launch só após os cinco módulos de produto shipped + QA; marco em Mar/27 assume buffer de Fev.
• v2 (portal, GA4): spec/planejamento no fim da janela; dev entra na próxima revisão de 12 meses.

Framework de priorização

Usar score 1–5 em cada dimensão; somar ou usar RICE adaptado.

Expand table full width

Template de item de roadmap

### [Nome da iniciativa]

- **Pilar:** <!-- nome do pilar -->
- **Persona:** <!-- persona principal -->
- **Problema:** …
- **Resultado esperado:** …
- **Métrica de sucesso:** …
- **Spec:** specs/NNN-… ou TBD
- **Status:** idea | spec | dev | shipped

Backlog atual

Scanner — varredura on-demand

• Pilar: Diagnóstico
• Persona: Bruno (Especialista SEO)
• Problema: Hoje a agência roda Lighthouse manualmente por site, sem histórico centralizado.
• Resultado esperado: Varredura completa (SEO + CWV + crawl) em < 3 min com score e lista de issues.
• Métrica de sucesso: ≥ 80% dos usuários ativos rodam ao menos 1 varredura/semana nos primeiros 30 dias.
• Spec: specs/007-scanner
• Status: spec

Agendamento de varreduras

• Pilar: Automação
• Persona: Ana (Diretora de Agência)
• Problema: Sem agendamento, a agência precisa lembrar de rodar manualmente; regressões passam semanas sem ser detectadas.
• Resultado esperado: Jobs recorrentes confiáveis com < 0,5% de falha silenciosa.
• Métrica de sucesso: ≥ 60% das contas com ≥ 1 site com agendamento ativo em 30 dias após cadastro.
• Spec: specs/009-scan-scheduler
• Status: idea

Alertas por e-mail/Slack

• Pilar: Automação
• Persona: Bruno (Especialista SEO)
• Problema: A agência só descobre regressão quando o cliente reclama.
• Resultado esperado: Alerta entregue em < 5 min após detecção, com link direto para o relatório de diferença.
• Métrica de sucesso: Redução de 40% nos tickets de "site com problema não detectado" no primeiro trimestre pós-lançamento.
• Spec: specs/010-alerts
• Status: idea

Relatório PDF white-label

• Pilar: Relatórios e Colaboração
• Persona: Ana (Diretora de Agência)
• Problema: Relatórios atuais são prints e CSVs; cliente não percebe valor do serviço.
• Resultado esperado: PDF gerado em < 30 s, com logo e cores da agência, compartilhável por link.
• Métrica de sucesso: ≥ 50% das contas Pro+ enviam ao menos 1 relatório/mês para clientes.
• Spec: specs/011-reports
• Status: idea

O que não entra (explicit no)

• Refactors sem impacto em critério de pilar
• Integrações sem demanda de ICP validada (ex.: integração com ferramentas de CRM antes do v2)
• Features "de vitrine" sem métrica (ex.: modo dark no relatório do cliente)
• Monitoramento de infraestrutura do servidor do cliente (fora do escopo — ver anti-objetivos em 01)

Cadência de revisão

• Semanal: ajuste do backlog priorizado com eng
• Mensal: revisão de horizontes com fundadores + produto; incorporar dados de Hotjar e NPS
• Trimestral: realinhamento com 01-vision-value-proposition e métricas de 06-product-metrics

Links relacionados

• PLAYBOOK — fluxo BDFU
• specs/README.md — índice de specs
• 03 — Pilares e critérios
• 06 — Métricas de produto
• Marketing — Campanhas