Product Lens — Pense Antes de Construir

Esta área é responsável pelo diagnóstico do produto, não pela escrita de especificações prontas para implementação.

Se o usuário precisar de um artefato durável de PRD para SRS ou contrato de capacidade, passe para product-capability.

Quando Usar

• Antes de iniciar qualquer funcionalidade — valide o "porquê"
• Revisão semanal do produto — estamos construindo a coisa certa?
• Ao ficar preso na escolha entre funcionalidades
• Antes de um lançamento — verificação de sanidade da jornada do usuário
• Ao converter uma ideia vaga em um resumo do produto antes que o planejamento de engenharia comece

Como Funciona

Modo 1: Diagnóstico do Produto

Como as "office hours" do YC, mas automatizado. Faz as perguntas difíceis:

1. Who is this for? (specific person, not "developers")
2. What's the pain? (quantify: how often, how bad, what do they do today?)
3. Why now? (what changed that makes this possible/necessary?)
4. What's the 10-star version? (if money/time were unlimited)
5. What's the MVP? (smallest thing that proves the thesis)
6. What's the anti-goal? (what are you explicitly NOT building?)
7. How do you know it's working? (metric, not vibes)

Saída: um PRODUCT-BRIEF.md com respostas, riscos e uma recomendação de ir/não ir.

Se o resultado for "sim, construa isso", a próxima área é product-capability, não mais "founder-theater".

Modo 2: Revisão do Fundador

Revisa seu projeto atual através da lente de um fundador:

1. Read README, CLAUDE.md, package.json, recent commits
2. Infer: what is this trying to be?
3. Score: product-market fit signals (0-10)
   - Usage growth trajectory
   - Retention indicators (repeat contributors, return users)
   - Revenue signals (pricing page, billing code, Stripe integration)
   - Competitive moat (what's hard to copy?)
4. Identify: the one thing that would 10x this
5. Flag: things you're building that don't matter

Modo 3: Auditoria da Jornada do Usuário

Mapeia a experiência real do usuário:

1. Clone/install the product as a new user
2. Document every friction point (confusing steps, errors, missing docs)
3. Time each step
4. Compare to competitor onboarding
5. Score: time-to-value (how long until the user gets their first win?)
6. Recommend: top 3 fixes for onboarding

Modo 4: Priorização de Funcionalidades

Quando você tem 10 ideias e precisa escolher 2:

1. List all candidate features
2. Score each on: impact (1-5) × confidence (1-5) ÷ effort (1-5)
3. Rank by ICE score
4. Apply constraints: runway, team size, dependencies
5. Output: prioritized roadmap with rationale

Saída

Todos os modos produzem documentos acionáveis, não ensaios. Cada recomendação tem um próximo passo específico.

Integração

Combine com:

• /browser-qa para verificar os achados da auditoria da jornada do usuário
• /design-system audit para avaliação de polimento visual
• /canary-watch para monitoramento pós-lançamento
• product-capability quando o resumo do produto precisar se tornar um plano de capacidade pronto para implementação