É o documento que descreve o que será construído e por quê, alinhando negócio, design e engenharia antes do desenvolvimento.

Para que serve

Tornar claro o problema, os objetivos e o escopo.
Definir requisitos (funcionais e não funcionais) e critérios de aceitação.
Dar base para priorização, estimativas e testes.
Alinhar stakeholders e reduzir retrabalho.

Quem escreve

Geralmente Product Manager (com contribuições de design/UX, engenharia, dados, suporte e áreas de negócio).

Quando usar

Antes de iniciar um épico/feature relevante. Pode ser leve (1–3 páginas) para itens pequenos ou detalhado para features críticas.

Conteúdo típico (estrutura enxuta)

Contexto & Problema: por que isso importa; métricas atuais.
Objetivos & KPIs: resultados esperados (ex.: ↑ ativação em +10%).
Escopo: o que entra e o que não entra (out-of-scope).
Personas & Cenários: quem usa e como.
Requisitos Funcionais: histórias/épicos com critérios de aceitação (Given/When/Then).
Requisitos Não Funcionais: desempenho, segurança, privacidade, acessibilidade, compatibilidade.
Fluxos & Wireframes (links ou anexos).
Dependências & Riscos: técnicos, legais, operacionais.
Métricas & Telemetria: eventos, funis, dashboards.
Lançamento & Rollout: feature flags, milestones, plano de comunicação.
Experimentos: hipóteses, desenho A/B, sucesso/falha.
Aberto/Pendências: dúvidas, decisões a tomar.

Diferenças rápidas

MRD (Market Requirements): oportunidades de mercado e clientes-alvo.
BRD (Business Requirements): necessidades do negócio/processos.
PRD: traduz MRD/BRD em requisitos de produto.
FRD (Functional Requirements): detalha funções específicas (às vezes parte do PRD).
Especificação Técnica: “como” será implementado (feito pela engenharia após o PRD).

Boas práticas

Clareza sobre o problema antes da solução.
Medir resultados, não só entregar escopo.
Foco no usuário (JTBD, jornadas).
Critérios de aceitação testáveis.
Scope creep controlado (itens “fora do escopo”).
Versão viva: atualize conforme decisões mudam.

====================================================================================

PRD — Documento de Requisitos de Produto

Objetivo do PRD: alinhar o porquê e o o quê de uma iniciativa de produto antes do desenvolvimento, servindo como referência única para negócio, design e engenharia.

0) Metadados

Produto/Projeto: Ex.: Onboarding Mobile
Versão do PRD: 1.0
Status: Rascunho / Em revisão / Aprovado
Owner (PM): Nome
Stakeholders principais: Engenharia, Design, Dados, Operações, Suporte, Jurídico
Data da última atualização: AAAA-MM-DD
Links úteis: Roadmap, Jira/Epics, Repositório, Figma, Pesquisa, Métricas

1) Contexto & Problema

Resumo executivo (3–5 linhas):

Qual oportunidade, dor do usuário ou objetivo estratégico?
Evidências: dados de uso, NPS, pesquisas, tickets, benchmarks.

Problema a resolver:

Descreva claramente o problema do usuário/negócio, sem solução embutida.

Métricas atuais (baseline):

Ex.: ativação D7: 22%; conversão paywall: 1,6%; tempo médio de tarefa: 3m40s.

2) Objetivos & KPIs (Resultados)

Objetivo de produto (outcome):

Ex.: aumentar ativação D7 de 22% → 30%.

KPIs de sucesso (com metas e janela temporal):

KPI 1: Ativação D7 +8 pp até Q2.
KPI 2: Reduzir churn mês 1 em 10%.
KPI de qualidade: Taxa de erro < 0,1% no fluxo.

Nota: priorize resultados sobre entregas; evite metas sem baseline.

3) Escopo

Inclui (In):

Ex.: tutorial interativo no app, checklist de 5 passos.

Não inclui (Out):

Ex.: refatoração completa do backend; novo sistema de billing.

Definições de pronto:

Definition of Ready (DoR): Histórias com critérios de aceitação, dependências mapeadas.
Definition of Done (DoD): Testes passantes, telemetria instalada, documentação atualizada.

4) Personas & Cenários

Persona(s):

Nome curto: “Ana, gestora financeira” — Objetivo: Conferir notas em 5 min. — Dores: Planilhas manuais, retrabalho.

Cenários/Jornadas principais:

Primeiro acesso → onboarding → primeira ação de valor (Aha! moment).
Retorno ao produto → completar configuração.

5) Requisitos Funcionais (Histórias)

Escreva em nível de épico/feature e detalhe histórias com Gherkin (Given/When/Then).

Épico 1 — Onboarding guiado

História 1: Como novo usuário, quero um checklist para concluir a configuração em até 5 min.
- Critérios de aceitação:
  - Dado que acessei o app pela 1ª vez, quando concluir os 5 passos, então devo ver o selo “Configuração 100%”.
  - Dado que abandonei um passo, quando retornar, então o sistema retoma do ponto exato.
- Métricas/telemetria: event_onboarding_step_x, funnel_onboarding
História 2: …

Anexo: link para wireframes / protótipos / fluxos.

6) Requisitos Não Funcionais

Desempenho: P95 < 400 ms no endpoint /onboarding.
Disponibilidade: 99,9% mensal.
Segurança & Privacidade: LGPD, mínimo de privilégios, criptografia em trânsito/repouso.
Acessibilidade: WCAG AA; navegação por teclado; contraste adequado.
Compatibilidade: iOS 15+, Android 9+, navegadores Evergreen.
Observabilidade: Logs estruturados, tracing distribuído, alertas SLO.

7) Restrições, Suposições & Compliance

Restrições: Janela de lançamento no Q2; budget limitado.
Suposições: Usuários completam onboarding em 1 sessão.
Compliance: Políticas internas, LGPD, normas setoriais.

8) Experimentos & Validação

Hipóteses: H1: checklist aumenta ativação D7; H2: nudges por e-mail reduzem abandono.
Desenho de testes: A/B com 50/50; horizonte 2 semanas; power ≥ 0,8.
Critérios de sucesso/falha: uplift ≥ +8pp; se < +3pp, reavaliar solução.
Riscos e mitigação: Baixa adesão → instruções in-app; impacto em performance → lazy-load.

9) Métricas & Instrumentação

Eventos: onboarding_step_view/start/complete; checklist_complete.
Funis/dashboards: Amplitude/GA/DBT/Metabase links.
Governança de dados: Nomenclatura, owner de métricas, definição de ativo.

10) Plano de Lançamento & Rollout

Estratégia: Feature flags; dark launch; progressive rollout (1% → 5% → 25% → 100%).
Suporte & Operações: Playbook de incidentes; FAQ; treinamento do suporte.
Comunicação: Release notes, e-mail in-product, changelog.
Backout Plan: Toggle da flag; rollback de versão; plano de hotfix.

11) Dependências & Impactos

Dependências internas: Equipe de Dados, SRE, Billing.
Dependências externas: Fornecedor de envio de e-mails.
Impactos em áreas: Financeiro (custos de envio), Jurídico (termos).

12) Abertos & Decisões

A decidir: Ex.: copiar importador legado ou reconstruir? Prazo: AAAA-MM-DD.
Decisões tomadas (com data): Ex.: adotar design system v2 (2025-10-01).

13) Anexos

Pesquisa UX: Links e resumos.
Wireframes/Protótipos: Figma/Links.
Referências: Benchmarks, documentos, RFCs.

14) Glossário

Ativação D7: Usuário que completou ação-chave em até 7 dias.
Aha! Moment: Primeira percepção clara de valor.
DoR/DoD: Definições de pronto e concluído.

15) Changelog

Data	Versão	Autor	Resumo
AAAA-MM-DD	1.0	Nome	Rascunho inicial

Checklist Rápido

Problema e objetivo claros
KPIs com baseline e meta
Escopo In/Out definidos
Histórias com critérios testáveis
Requisitos não funcionais
Telemetria definida
Dependências mapeadas
Plano de rollout e rollback
Riscos e mitigação
Itens em aberto com responsáveis e datas

PRD = Product Requirements Document (Documento de Requisitos de Produto).