Roadmap de 90 dias

Trecho real do TRACKING.md do CEAP, mostrando como uma timeline curta aparece num projeto vivo:

| Phase | Features            | Status   | Notes                       |
|-------|---------------------|----------|-----------------------------|
| 1     | Visão Geral         | **LIVE** | Deployed 2026-01-11         |
| 2     | + Deputados         | Ready    | Enable flag and deploy      |
| 3     | + Padrões           | Ready    | 6 sub-tabs included         |
| 4     | + Rede, Metodologia | Ready    | Network graph + docs        |
| 5     | + DeepDive          | 4/5      | Weekend anomalies missing   |

Repare em quatro coisas neste trecho. Cada fase entrega algo usável (não "backend pronto"). Cada fase adiciona sobre a anterior (+ Deputados, + Padrões). A fase 1 já está live antes da fase 2 sair. E a fase 5 está honesta sobre o que falta (4/5). Esse é o formato do docs/roadmap.md que você vai escrever agora: 3 fatias de cerca de 30 dias cada, em vez de 5, com horizonte total de 90 dias.

A escolha de 90 dias (em vez de 12 meses) é prática: os primeiros 30 dias de execução costumam revelar informações sobre o usuário, sobre a stack e sobre o produto que invalidam previsões mais longas. 90 dias é o horizonte em que você ainda consegue planejar com alguma confiança.

A estrutura: 3 fatias verticais

Uma é um pedaço do produto que funciona ponta a ponta: usuário entra, faz uma coisa inteira, sai com um resultado. O corte horizontal ("primeiro a UI, depois o backend, depois auth") deixa você sem nada usável até o final.

Cada fatia precisa ter três atributos.

Atributo 2: cabe em 30 dias de trabalho real

"Trabalho real" considera dias com baixa produtividade, bugs não previstos, pequenos retrabalhos. Use a regra de inflar em ~40%: o seu chute de 30 dias de execução perfeita vira 30 × 1,4 ≈ 42 dias de trabalho real. Se isso passa de 30, a fatia está grande demais e precisa ser cortada.

O fator 1,4 é uma regra prática, não um número medido: vem da tendência conhecida de subestimar tarefas (planning fallacy) e serve só pra te lembrar de cortar antes de começar. Se você já tem histórico do seu próprio ritmo, use o seu fator no lugar.

Como cortar: pegue o entregável e remova uma feature que parece essencial mas não é. Sem login na primeira fatia? Mande link mágico por email. Sem editor rico? Caixa de texto simples. Sem cobrança? Sem cobrança ainda.

Passo 1: crie o esqueleto do `docs/roadmap.md`

prompt · text

Crie o arquivo `docs/roadmap.md` na pasta `docs/` com este esqueleto:

# Roadmap: próximos 90 dias

> Cada fatia é vertical: usuário entra, faz uma coisa inteira, sai com resultado.
> Cada fatia cabe em cerca de 30 dias de trabalho real (não execução perfeita).

## Fatia 1 (dias 0-30)

**Entrega:** <!-- TODO -->

**Inclui:**
- <!-- TODO -->

**NÃO inclui (corta da fatia 1):**
- <!-- TODO -->

## Fatia 2 (dias 30-60)

**Entrega:** <!-- TODO -->

**Inclui:**
- <!-- TODO -->

**NÃO inclui:**
- <!-- TODO -->

## Fatia 3 (dias 60-90)

**Entrega:** <!-- TODO -->

**Inclui:**
- <!-- TODO -->

**NÃO inclui:**
- <!-- TODO -->

Mostre o diff antes de criar.

Aprove com y.

Passo 2: Claude propõe as 3 fatias

Claude lê o docs/product.md que você escreveu na L02 e propõe 3 fatias verticais. Você refina depois.

prompt · text

Leia o arquivo `docs/product.md` deste projeto. Com base no Problema, Usuário, Wedge e Não-objetivos descritos lá, proponha 3 fatias verticais para o `docs/roadmap.md`, seguindo estas regras:

1. **Cada fatia tem uma entrega que funciona ponta a ponta:** uma frase curta que descreve um caminho completo (usuário entra, faz uma tarefa inteira, sai com resultado). Não pode ser "modelo de dados," "API," ou "componente."

2. **A fatia 1 deve ser a versão mais curta possível do wedge:** o caminho mínimo que valida o wedge com 1 usuário real.

3. **Cada fatia cabe em cerca de 30 dias de trabalho real**. Se uma fatia parece grande, corte uma feature óbvia. Indique explicitamente o que ficou de fora em "NÃO inclui."

4. **Nenhuma fatia depende de fatia futura para ter sentido sozinha.** Aplique o teste: se eu parasse na fatia 1, ela já seria útil para alguém? Se a resposta for não, refaça o corte.

5. **Respeite os Não-objetivos do `docs/product.md`.** Nada na fatia 1, 2 ou 3 pode estar listado como Não-objetivo.

Saída: três blocos (Fatia 1, 2, 3), cada um com Entrega + Inclui + NÃO inclui. **Não edite o arquivo ainda**, proponha no chat. Vou refinar e te peço para escrever depois.

Claude responde com 3 fatias. Leia com atenção. Os erros mais comuns:

A fatia 1 ficou grande demais porque Claude tendeu a juntar features para "ficar mais útil." Corte.
Uma fatia disfarçada de horizontal (ex: "fatia 1 = backend + UI base"). Aplique o teste do valor isolado e peça uma versão vertical.
NÃO inclui vazio em alguma fatia. Peça 2 ou 3 itens em cada.

Passo 3: refine cada fatia até passar nos 3 testes

Para cada fatia, faça mentalmente os 3 testes e peça ajuste se falhar:

Funciona ponta a ponta? Alguém pode usar isso? Se a resposta for "depois de configurar 3 coisas," não está pronto.
Cabe em 30 dias reais? Considere dias ruins, bugs e retrabalho. Se o chute foi 22 dias de execução perfeita, multiplique por 1,4 = aproximadamente 31 dias. Borderline. Corte mais.
Tem valor isolado? Se você parasse aqui, alguém usaria? Se a resposta é "não, falta a fatia 2," não está vertical.

Quando uma fatia falha em algum dos testes, peça ajuste específico:

prompt · text

A fatia 1 falha no teste de valor isolado: ela só fica útil depois que a fatia 2 estiver pronta. Refaça só a fatia 1: a entrega tem que ser usável sozinha, mesmo que pequena. Mantenha as fatias 2 e 3 como estão.

Repita até as 3 fatias passarem nos 3 testes.

Outcomes vs outputs (John Cutler)

John Cutler (Amplitude / The Beautiful Mess) popularizou em 2020-2024 a distinção que organiza produto moderno:

= "lançar feature X." Mensurável, mas pode estar errado.
Outcome = "X% dos clientes B2B emitem recibos mensalmente." Mensurável e diretamente conectado ao valor.

Roadmap de output ("Q1: builder. Q2: PostHog. Q3: faturas") envelhece feio quando você descobre que a feature errou. Roadmap de outcome ("ate dia 60, 5 contadores reais emitiram 100+ recibos cada") consegue se adaptar: se a primeira fatia não chegou lá, você reorganiza próximas fatias sem perder direção.

Pra solo builder, o horizonte máximo onde outcomes ainda fazem sentido planejar é 90 dias. Além disso vira fantasia.

Aplicação prática nesta lição: tente reescrever cada fatia do seu roadmap como outcome esperado em vez de lista de features. Se ficar travado ("não sei que outcome esperar"), você ainda não conhece bem o usuário; volta na L01.

Passo 4: Claude escreve o `docs/roadmap.md` final

prompt · text

As 3 fatias estão refinadas. Agora escreva o conteúdo final em `docs/roadmap.md`, substituindo todos os `<!-- TODO -->`. Mantenha a estrutura exata do esqueleto (Entrega / Inclui / NÃO inclui). Mostre o diff antes de aplicar.

Aprove com y. O arquivo é gravado em disco.

Passo 5: faça o commit

prompt · text

Faça commit de `docs/roadmap.md` seguindo Conventional Commits. Stage só esse arquivo, com mensagem `docs(roadmap): 90-day roadmap`.

Aprove git add e git commit. Confira no GitHub.

Pegadinha brasileira: NF-e, MEI e amigos

Tentação comum em produto BR: "a fatia 1 vai ter integração com NF-e / NFS-e / SPED / MEI, porque sem isso o usuário não usa."

Quase nunca é verdade. A fatia 1 é o caminho mais curto que valida o wedge; uma versão de produção polida vem depois. Lance a fatia 1 com o equivalente brasileiro de uma versão simplificada (recibo em PDF, sem integração fiscal) e converse com 5 usuários reais. Se 4 pedirem NF-e, ela entra na fatia 2. Se nenhum pedir, você economizou 3 semanas de integração com sistema municipal que ninguém ia usar.

Mesma lógica vale para: integração bancária (boleto, Pix), assinatura digital (ICP-Brasil), notificação por SMS, exportação para o contador. Versão simplificada primeiro; integração depois, quando o uso real provar que vale.

Verificação: a fatia 1 vira a próxima lição

Pegue a entrega da fatia 1 e peça ao Claude 3 nomes possíveis para o arquivo de plano (em plans/) que implementa essa fatia. Se você consegue identificar um nome claro entre os três, está pronto para a L04.

prompt · text

Pegue esta entrega da fatia 1 do meu `docs/roadmap.md`:

> 

Proponha 3 nomes possíveis para um arquivo de plano (em `plans/`) que implementa essa fatia. Cada nome em kebab-case, com até 12 palavras, descrevendo a entrada, a saída, ou um edge case brasileiro, não apenas "a feature." Marque com ⭐ o nome mais específico dos três.

Não me dê nomes vagos tipo `feat-add-recibo.md` ou `feat-implement-pdf.md`. Quero algo como `feat-pdf-recibo-MEI-com-dados-do-cliente-pre-preenchidos`.

DELIVERABLE_FATIA_1[DELIVERABLE_FATIA_1]— cole a entrega da sua fatia 1 do docs/roadmap.md, exatamente como está escrita.

Leia os 3 nomes. Se o ⭐ está claro o suficiente para você dizer "sim, é isso que vou construir," anote. Você vai usá-lo na L04.

Build Diary: como o CEAP foi cortado em fatias progressivas

O CEAP não foi construído numa única jornada. O autor cortou o trabalho em 7 notebooks Jupyter executados em ordem, cada um com função específica. Trecho real do NOTAS_DO_AUTOR.md do projeto explicando a lógica:

01-02: Fundação. Antes de detectar anomalias, você precisa conhecer os dados. Quais categorias existem? Qual a distribuição típica de valores? Sem esse contexto, qualquer "anomalia" pode ser comportamento normal que você não conhecia.

03: Lei de Benford. Introduz o conceito central: dados naturais têm padrões previsíveis. É uma mudança de perspectiva que informa todas as análises seguintes.

04: Concentração HHI. Aplica um conceito mais intuitivo: "este deputado concentra X% dos gastos em um único fornecedor." Agora você tem duas lentes: estatística (Benford) e estrutural (HHI).

05: Estudo de Caso. Integra as técnicas numa investigação real. Mostra como combinar os indicadores, quando cada um é útil.

06-07: Expansão. Adiciona validação externa (CNPJ/CNAE) e ensina a construir seu próprio sistema de scoring. Você sai com um framework replicável.

A lógica do CEAP é a mesma do roadmap de 90 dias: cada fatia tem valor isolado (você pode parar no notebook 03 e já tem detecção via Benford funcionando), e cada fatia depende da anterior pra fazer sentido completo sem depender da seguinte.

A ordem específica veio de uma decisão que o autor explica no mesmo arquivo: tentou começar pelo notebook 03 (Benford direto, mais "interessante") mas percebeu que sem os notebooks 01-02 (conhecer os dados), os leitores não conseguiam interpretar o resultado de Benford: qualquer desvio parecia anomalia. O corte progressivo foi descoberto pela tentativa, não previsto.

Quando você cortar suas 3 fatias, lembre que a ordem importa. A fatia 1 precisa ser o caminho que ensina o usuário a interpretar o resultado, não necessariamente a feature mais impressionante. Se o usuário não entende o resultado da fatia 1, ele não vai esperar a fatia 2: abandona. As fatias 2 e 3 expandem a fundação, não a substituem.

Takeaways

90 dias é o horizonte máximo onde planejamento ainda bate com a realidade; além disso, vira fantasia que envelhece em 30 dias de execução.
Fatia vertical = caminho completo (usuário entra, faz, sai com resultado). Corte horizontal (backend + UI + auth) deixa você sem nada usável até o final.
Cada fatia precisa ter os 3 atributos: ponta a ponta, cabe em 30 dias reais, valor isolado. Se falhar em algum, corte uma feature.
Outcome ("5 contadores emitiram 100+ recibos") aguenta melhor que output ("lançar feature X"), porque se adapta se a hipótese estava errada.

Você terminou quando

O docs/roadmap.md está commitado no repositório com 3 fatias verticais; cada fatia cabe em cerca de 30 dias e tem entrega que funciona ponta a ponta e tem valor isolado.

Auto-checagem: você consegue responder?