Lição 2 de 8: Descrever o produto

Trecho do docs/product.md real do CEAP, um dos produtos que serve de substrato pro curso:

## Overview
**Project:** Análise de Dados Públicos - CEAP
**Focus:** Government transparency, fraud detection methodology, data analysis education

## Data Sources
- **Name:** Portal Dados Abertos - Câmara dos Deputados
- **Period:** 2023-2025
- **Records:** ~166,000+ transactions
- **Total Value Analyzed:** R$ 500M+ in parliamentary spending

Repara em quatro coisas neste trecho: o usuário está implícito em Focus (jornalistas, pesquisadores, auditores, não "qualquer interessado em política"), o problema vem com número (166 mil transações, R$ 500M), a fonte tem URL (qualquer pessoa reproduz), e nenhuma promessa de feature aparece, de propósito. Essa é a forma do docs/product.md que você vai escrever agora pro seu produto, com 4 seções: Problema, Usuário, Wedge, Não-objetivosA decisão registrada do que o produto NÃO vai fazer nesta versão. Protege contra a expansão de escopo: a feature óbvia que você corta hoje fica documentada pra sua versão futura não readicionar sem pensar..

Claude vai te entrevistar (6-8 perguntas curtas) e preencher o arquivo. No fim, Claude começa cada sessão citando o seu produto pelo nome, sem você dar contexto.

Na L01 você aprendeu o modelo do wedge. Agora vai registrá-lo num arquivo do repositório, pra que Claude tenha esse contexto a cada sessão. O docs/product.md segue a mesma lógica do CLAUDE.md da L05 do Módulo 1: contexto em disco, lido na abertura. O CLAUDE.md descreve stack e convenções; o docs/product.md descreve o produto.

As 4 seções do docs/product.md

Antes do prompt de entrevista, veja o formato do que você vai escrever. Cada seção tem uma função.

Passo 1: crie a pasta docs/ e o arquivo

Antes da entrevista, prepare o terreno. Cole no Claude:

Crie a pasta `docs/` (se ainda não existir) e o arquivo `docs/product.md` com este esqueleto inicial:

# Product Brief

## Problema

<!-- TODO -->

## Usuário

<!-- TODO -->

## Wedge

> usuário × tarefa × canal de aquisição

<!-- TODO -->

## Não-objetivos

<!-- TODO -->

Mostre o diff antes de criar.

Claude vai pedir aprovação para criar o arquivo:

Create file docs/product.md
+ # Product Brief
+
+ ## Problema
+ <!-- TODO -->
+ ...

Do you want to proceed? [y/n]

Aprove com y.

Passo 2: a entrevista

Em vez de você ficar encarando a página em branco, Claude vai te entrevistar. Ele faz 6 a 8 perguntas curtas e preenche as 4 seções com base nas suas respostas.

Preencha os 2 campos abaixo com a sua ideia atual. Mesmo que ainda esteja vaga, a entrevista é onde você vai especificar.

Vou preencher o `docs/product.md`: você me entrevista, eu respondo. Aqui está o que eu sei:

- **Ideia inicial:** [IDEIA_INICIAL]
- **Usuário que tenho em mente:** [USUARIO_QUE_VOCE_TEM_EM_MENTE]

Faça isto, em ordem:

1. **Me entrevista.** 6 a 8 perguntas curtas, **uma por vez**, esperando minha resposta antes de fazer a próxima. Cubra estes quatro tópicos, nessa ordem: número/tempo/dinheiro do problema atual; tamanho/idade/região do usuário; canal de aquisição específico (recuse "redes sociais" ou "marketing digital", peça algo mais concreto); 3 a 5 coisas óbvias que eu NÃO vou fazer nesta versão.

2. **Quando eu disser "ok, escreve":** preenche as 4 seções de `docs/product.md` com base nas respostas. Remova os comentários `<!-- TODO -->`. A seção Wedge deve ser uma frase única no formato `[usuário] × [tarefa] × [canal]`. A seção Não-objetivos deve ter 3 a 5 itens em bullets.

3. **Mostra o diff antes de aplicar.** Se eu rejeitar alguma seção, refazemos só aquela, não o arquivo todo.

4. **Se em algum momento eu der uma resposta vaga** (ex: "qualquer pequeno negócio," "marketing digital genérico"), me alerta com uma frase curta: "essa resposta vai gerar um wedge vago. Quer especificar?", sem sermão, só um lembrete.

Comece pela primeira pergunta.

Cole o prompt e responda às perguntas do Claude. Costuma levar de 5 a 8 minutos. Algumas dicas:

• Quando você não souber, diga "não sei ainda." Claude vai propor 2 ou 3 hipóteses, e você escolhe uma. Uma hipótese definida agora vale mais do que ficar na vagueza.
• Se uma pergunta te travar por mais de 30 segundos, anote e siga em frente. É sinal de que essa parte do produto ainda não está clara, e você volta depois do Módulo 3, com mais informação do mercado.
• Se Claude começar a fazer perguntas sobre features ("você vai ter dashboard?"), corte: "foco no wedge primeiro, features depois."

Quando terminar de responder, escreva ok, escreve. Claude propõe o docs/product.md preenchido em formato de diff.

Passo 3: revisão do draft

Antes de aprovar a edição, leia o draft com olhar crítico. Três erros aparecem com frequência:

Quando o draft estiver bom nas 4 seções, aprove com y. O arquivo é gravado em disco.

Passo 4: faça o commit

Este é o seu primeiro commit de conteúdo de produto no main. Os commits anteriores (Módulo 1) eram setup técnico.

Faça commit de `docs/product.md` seguindo Conventional Commits. Stage só esse arquivo, com mensagem `docs(product): initial product brief`.

Claude vai pedir aprovação para os dois comandos:

Bash command
git add docs/product.md
Stage the product brief

Do you want to proceed? [y/n]

Bash command
git commit -m "docs(product): initial product brief"
Commit the staged changes

Do you want to proceed? [y/n]

Aprove os dois. Confira no GitHub: https://github.com/seu-usuario/{nome-do-projeto}/commits/main. O commit docs(product) deve aparecer.

Passo 5: feche o Claude e abra de novo

Mesmo procedimento da L05 do Módulo 1. Encerre a sessão atual:

• Cursor / VS Code: feche o painel do Claude.
• Desktop app: feche a janela.
• Terminal: aperte Ctrl+D (ou digite exit).

Abra uma sessão nova no mesmo projeto. Cole este prompt:

Em uma frase, descreva o usuário deste produto e qual é o wedge.

A resposta deve descrever o seu usuário específico (com as características concretas que você escreveu no docs/product.md) e citar o triângulo do wedge. Não pode vir algo genérico tipo "o usuário é uma pequena empresa que precisa de gestão."

Se a resposta veio genérica, faça um segundo teste:

Quais 3 coisas eu decidi NÃO fazer nesta versão do produto?

Aqui Claude precisa listar 3 itens da sua seção Não-objetivos. Se não listar, ou listar coisas inventadas, o docs/product.md não foi lido. Veja o troubleshooting logo abaixo.

Build Diary: Não-objetivos como regras operacionais

O trecho do CEAP que abriu a lição não mostra a seção de Não-objetivos. Ela está em outra parte do arquivo, com regras como "Use language like 'warrants investigation' not 'is fraudulent'" e "All findings need verification by proper authorities." Essas regras evitam que a ferramenta vire acusação automática. É um Não-objetivo concreto pra produto de transparência, registrado em forma operacional: mexe em tom de UI, copy do site, estrutura de relatório.

Takeaways

• O docs/product.md é a hipótese inicial do produto em 4 seções (Problema, Usuário, Wedge, Não-objetivos), lida por Claude a cada sessão futura.
• Uma persona com 2-3 características concretas serve melhor que uma categoria. O teste prático: você consegue mandar mensagem direto pra essa pessoa na primeira semana? Se a descrição abrange milhões, você não consegue.
• Não-objetivos protege contra a sua versão futura, que vai querer adicionar a feature óbvia que você cortou hoje.
• Verificação: sessão nova do Claude descreve o seu usuário e cita 3 não-objetivos sem você dar contexto.

Você terminou quando

O docs/product.md está no GitHub com as 4 seções preenchidas, e uma sessão nova do Claude descreve o seu usuário usando as características que você escreveu, sem você precisar passar contexto.