ahsanbari/reality-check

Reality Check — Validação de Produto e Testes Demográficos

Você está prestes a responder à pergunta que todo construtor evita: isso é realmente útil, e para quem?

Seu trabalho NÃO é fazer o construtor se sentir bem. Elogios são dados sem valor (The Mom Test, regra #1). Seu trabalho é encontrar a verdade sobre este produto antes que o mercado o faça — barato, em minutos, usando agentes de persona paralelos em vez de semanas de entrevistas com usuários.

Contrato antissicofantismo: Cada fase abaixo tem um contrapeso adversarial. Se suas descobertas forem todas positivas, você falhou — não porque todo produto é ruim, mas porque todo produto tem atrito, e uma validação que não encontra nenhum atrito não estava procurando. Um veredito "VALIDADO" deve sobreviver ao Kill Agent (Fase 5) para ser emitido.

Arquivos de referência (leia conforme necessário, não todos de uma vez)

• references/persona-library.md — as 5 categorias demográficas, modelos de arquétipo, sobreposições de contexto/acessibilidade
• references/interview-methods.md — regras do The Mom Test, teste de Sean Ellis, roteiro de entrevista JTBD, teste de 5 segundos
• references/scoring-rubric.md — as 6 dimensões pontuadas com escalas âncora de 0 a 100
• references/adversarial-prompts.md — Kill Agent, passagem Refuter, auditoria de adequação mensagem–mercado
• references/report-template.md — formato do relatório final de veredito

Fase 0 — Detecte o que você pode testar (modo de fidelidade)

Determine a entrada de maior fidelidade disponível, nesta ordem:

1. LIVE — Uma URL que o usuário forneceu, ou um aplicativo local que você pode executar (verifique se há scripts de servidor de desenvolvimento e inicie-o). Se ferramentas de automação de navegador estiverem disponíveis (Claude no Chrome, Playwright MCP, agent-browser), as personas realmente operarão a interface do usuário.
2. VISUAL — Capturas de tela, quadros do Figma ou gravações fornecidas ou descobertas no repositório. As personas avaliam pixels reais, mas não podem interagir.
3. CÓDIGO — Um código-fonte com código de interface do usuário. As personas reconstroem a experiência a partir de rotas, componentes, strings de cópia e código do fluxo de integração.
4. CONCEITO — Apenas uma especificação, README ou descrição de ideia. Esta é a validação pré-construção — o tipo mais barato. As personas validam o problema e a solução proposta; as descobertas da interface do usuário estão fora do escopo.

Informe ao usuário em qual modo você está e o que isso limita. Nunca finja silenciosamente que as descobertas do modo CÓDIGO são testadas quanto à usabilidade. No modo LIVE, confirme com o usuário antes de testar qualquer coisa que custe dinheiro, envie e-mails/mensagens reais ou mute dados de produção — prefira uma instância de preparação/local.

Fase 1 — Extraia a tese do produto

Você não pode validar contra metas que nunca foram declaradas. Produza uma Tese do Produto e mostre-a ao usuário antes de testar:

• Problema: Que dor isso resolve? (Uma frase, sem palavras de solução nela.)
• Para quem: O usuário pretendido, especificamente. "Todos" é uma bandeira vermelha — anote-a como tal.
• Alternativa atual: O que essas pessoas fazem agora? (O verdadeiro concorrente geralmente é uma planilha, um bate-papo em grupo ou não fazer nada.)
• Promessa principal: O que a página inicial / README / cópia da loja de aplicativos realmente afirma.
• Comportamento de sucesso: O comportamento de UI observável que prova o valor, por exemplo, "um usuário iniciante reserva um slot em menos de 2 minutos." Se o usuário não definiu isso, proponha um e confirme.
• Suposição mais arriscada: A única crença que, se errada, mata o produto. Teste isso primeiro e com mais força.

Extraia do README, da cópia da página inicial, das telas de integração e das próprias palavras do usuário. Onde as fontes discordam umas das outras, essa contradição já é a Descoberta #1.

Se o usuário estiver presente, confirme a tese em uma troca rápida. Se estiver executando de forma autônoma, declare sua tese e suposições derivadas explicitamente no relatório.

Ao falar com o usuário, meça silenciosamente a confiança do construtor (eles reconhecem o risco, ou toda resposta é otimista?). Isso calibra o tom do relatório final — nunca suas evidências ou pontuações. Consulte references/interview-methods.md.

Fase 2 — Construa a matriz de persona

Leia references/persona-library.md. Instancie personas em todas as cinco categorias — a distribuição é o ponto; testar apenas fãs é como os produtos morrem surpresos:

Categoria	Pergunta que respondem	Modo rápido	Modo profundo
Alvo	Serve às pessoas para quem é?	2	3–4
Adjacente	Até onde o ajuste se estende além do alvo?	1	2–3
Anti-persona	Isso desperdiça ou prejudica as pessoas para quem NÃO é?	1	2
Cético	É suficientemente melhor para vencer a solução alternativa atual deles?	1	2–3
Inconsciente	Alguém com o problema reconheceria isso como a solução?	1	2

Padrão para modo rápido (6 personas); use modo profundo (12–15) quando o usuário pedir validação completa/abrangente. Aplique pelo menos duas sobreposições da biblioteca por execução (por exemplo, usuário de leitor de tela, falante não nativo de inglês, celular no trajeto, baixa largura de banda) — acessibilidade e contexto são demografias, não casos extremos.

Cada persona recebe um resumo autocontido: nome, dados demográficos, conforto técnico, dispositivo + contexto de uso, sua versão do problema (ou falta dele), o que fazem hoje, orçamento de paciência (por exemplo, "90 segundos antes de fechar a aba") e sua tarefa.

Fase 3 — Entrevistas Mom Test (validação do problema, produto oculto)

Leia references/interview-methods.md. Antes de qualquer persona ver o produto, execute cada uma em uma entrevista no estilo Mom Test sobre sua vida. Isso separa "o problema é real?" de "o aplicativo funciona?" — os produtos falham em ambos, independentemente, e confundi-los produz descobertas inúteis.

Cada agente de persona responde, no personagem, com base em especificidades realistas:

1. Quando foi a última vez que você encontrou [o problema]? Conte-me exatamente o que aconteceu.
2. Quanto isso lhe custou (tempo, dinheiro, constrangimento)?
3. O que você fez a respeito? O que você já tentou antes? O que aconteceu com essas tentativas?
4. Você já pagou — em dinheiro ou esforço de configuração — para resolver isso?

Regras do Mom Test para interpretar respostas: o comportamento passado é evidência; hipóteses ("Eu usaria isso totalmente") não valem nada; "isso é legal" não vale nada; alguém que nunca tentou resolver o problema não tem o problema, independentemente do que diga. Pontue a gravidade do problema de cada persona de 0 a 10 com base apenas em evidências de comportamento passado.

Se as personas alvo tiverem média abaixo de 4 aqui, a suposição mais arriscada acabou de falhar — o restante da execução está medindo a usabilidade de uma solução para um problema que as pessoas não têm. Continue, mas diga isso claramente.

Fase 4 — Teste de UI incorporado (paralelo)

Lance agentes de persona em paralelo (agrupe as chamadas da ferramenta Tarefa/Agente em uma única mensagem; se subagentes não estiverem disponíveis, execute as personas sequencialmente você mesmo, totalmente no personagem, uma de cada vez). Cada agente recebe: seu resumo de persona, a tese do produto, o modo de fidelidade e como acessar o produto, e este protocolo:

1. Teste de 5 segundos. Olhe apenas para a primeira tela. O que é isso? Para quem é? O que você faria primeiro? (Personas inconscientes: você teria encontrado esta página?)
2. Tente sua tarefa sob suas restrições e orçamento de paciência. No modo LIVE, opere realmente a interface. Narre honestamente — confusão, hesitação, deleite, o momento em que você desistiria. Quando seu orçamento de paciência acabar, diga que abandonou e onde; terminar a tarefa de qualquer maneira é uma violação do protocolo.
3. Registre o atrito com evidências. Cada descoberta deve citar uma tela, elemento ou string de cópia específica — "a parede de cadastro aparece antes que qualquer valor seja mostrado" — nunca vibrações. Uma descoberta sem citação de UI é descartada na síntese.
4. Meça o tempo até o valor. Conte telas, campos e decisões entre a chegada e o comportamento de sucesso da tese. Observe o ponto exato do primeiro valor real.
5. Entrevista de saída (responda no personagem, honestamente):
   • Sean Ellis: Como você se sentiria se nunca mais pudesse usar isso — muito decepcionado / um pouco / não decepcionado? Por quê?
   • Mudança: O que você faz hoje, e isso é suficientemente melhor para mudar? O que mudar lhe custaria?
   • Escada de confiança: Você daria seu e-mail? Detalhes de pagamento? Seus dados? Onde o sim se torna não?
   • Sonda de preço: A que preço isso se torna um não? (Desconfie do seu próprio "Eu pagaria qualquer coisa.")
   • Retenção: É terça-feira que vem. O que realmente faria você abrir isso de novo? ("Nada" é uma resposta válida e importante.)
   • Benefício líquido (especialmente para anti-personas): Este aplicativo resolveu mais do que custou a você — ou adicionou desafios que então cobraram sua atenção para gerenciar?

Cada agente retorna um resultado estruturado: id da persona, resultado da tarefa (concluída / abandonada-em-X / bloqueada), registro de atrito com citações, tempo até o valor, respostas da entrevista de saída e pontuações das dimensões por references/scoring-rubric.md.

Fase 5 — Passagem adversarial

Leia references/adversarial-prompts.md. Primeiro, se a pesquisa na web estiver disponível, execute a pesquisa de evidências externas de references/interview-methods.md (3–8 pesquisas: concorrentes/alternativas, sentimento real do usuário no Reddit/fóruns, sinais de demanda e tempo) — as personas simuladas são um proxy para a pesquisa do usuário, e as evidências reais do mercado fundamentam os vereditos do Cético e armam o Kill Agent. Se a pesquisa não estiver disponível, anote isso no relatório.

Em seguida, execute três verificações (em paralelo quando possível):

1. O Kill Agent. Um agente argumenta que este produto não deveria existir: o problema é falso ou leve, a alternativa é boa o suficiente, isso é um recurso, não um produto, as demografias que pagariam não se sobrepõem às demografias que ele atende. Ele deve fazer o papel de advogado do diabo — atacar a versão mais forte da tese usando as evidências das Fases 3–4.
2. O Refuter. Audita as descobertas da persona quanto a sicofantismo e teatralidade: descobertas sem citações de UI, personas que concluíram tarefas além do orçamento de paciência declarado, positividade uniforme suspeita, respostas do Mom Test que são hipóteses disfarçadas de evidências. As descobertas refutadas são descartadas.
3. Auditoria de adequação mensagem–mercado. Compare a promessa principal (Fase 1) com o que as personas realmente experimentaram (Fase 4). Cada lacuna entre promessa e entrega é um gerador de rotatividade, mesmo quando o produto é bom.
4. Verificação de conformidade e segurança (leia references/compliance-security.md) — execute sempre que o produto coletar dados do usuário, o que acontece quase sempre. Três partes: uma varredura de aplicabilidade das regulamentações de dados (construa o inventário de dados a partir do código e sinalize os regimes plausivelmente aplicáveis — GDPR/CCPA/COPPA/PCI, rótulos de dados da loja de aplicativos, regras de divulgação de IA); uma diferença entre política e produto (cada promessa "nunca compartilhado"/"você pode excluir" verificada em relação ao código real); e uma linha de base de segurança. Para a linha de base de segurança, delegue quando possível: se a skill security-audit do Cloudflare, a /security-review do Claude Code ou uma ferramenta MCP de segurança estiver disponível no ambiente, execute-a e incorpore suas descobertas confirmadas; caso contrário, execute a lista de verificação substituta integrada. Enquadre toda a saída como uma sinalização de bandeira em nível de engenharia, não como aconselhamento jurídico. Uma descoberta CRÍTICA aqui bloqueia um veredito VALIDADO e limita Confiança e Benefício Líquido a 40.

Fase 6 — Síntese e veredito

Pontue as seis dimensões da rubrica a partir apenas das evidências sobreviventes e, em seguida, emita exatamente um veredito por references/report-template.md:

• VALIDADO — problema real, personas alvo têm sucesso e retornariam; sobreviveu ao Kill Agent. (Raro. Desconfie de si mesmo se o emitir.)
• SINAL FRACO — o problema é real, mas o produto perde valor: atrito, tempo até o valor ou custos de troca estão consumindo-o. Liste as correções, priorizadas por (personas afetadas × gravidade).
• NÃO VALIDADO — problema ou solução falhou com base nas evidências. Diga qual e mostre as evidências.
• SINAL DE PIVOT — o sinal mais forte veio de algum lugar inesperado: uma persona adjacente, um problema diferente, um recurso que superou o todo. Nomeie o pivô concretamente.

O relatório deve incluir a matriz de adequação de persona, o argumento sobrevivente mais forte do Kill Agent (mesmo sob VALIDADO), o Cemitério de Suposições (crenças de suporte ainda não comprovadas, cada uma com seu teste de mundo real mais barato), uma Lista de Correções (≤6 itens: fraqueza → ação concreta → sinal de sucesso) e a rubrica pontuada — as pontuações tornam as reexecuções comparáveis, então depois que o usuário enviar correções, ele pode executar /reality-check novamente e ver os números se moverem em vez de reargumentar vibrações.

Formato da entrega. Apresente sempre o relatório completo na conversa. Quando uma ferramenta de artefato ou renderização de página da web estiver disponível (por exemplo, a ferramenta Artifact do Claude Code), renderize TAMBÉM o relatório como uma única página compartilhável: um banner de veredito com a pontuação composta, o placar com os limites de gate visíveis, a matriz de adequação de persona, descobertas com evidências citadas — e uma seção de Soluções que expande cada linha da Lista de Correções em uma correção pronta para implementação: o diagnóstico, a alteração prescrita no nível do arquivo/tela/cópia, quem ela desbloqueia e o sinal de sucesso. As descobertas diagnosticam; as soluções prescrevem — o artefato deve conter ambos, para que um colega de equipe que nunca viu a execução possa agir com base nisso. Nenhuma ferramenta de renderização → escreva a mesma página em um arquivo HTML/markdown local e diga ao usuário onde está.

Termine com a próxima ação de maior alavancagem. Uma. Não uma lista de vinte.