Como escrever um DRP: Guia completo em 10 passos + sugestões de escrita com IA

Porque são os documentos de requisitos do produto (ou PRD) ferramentas tão essenciais para as equipas de produto? Porque, por mais claramente que consiga imaginar o estado futuro do seu produto, não haverá duas partes interessadas que o interpretem da mesma forma.

Tenho a certeza de que existem milhões de histórias assustadoras de gestores de produto que só perceberam demasiado tarde quão ineficazmente tinham comunicado os elementos críticos de um novo produto ou funcionalidade. 

É por isso que um Documento de Requisitos do Produto (PRD) é tão importante. Utiliza uma abordagem detalhada e sistemática para garantir que todos estão alinhados relativamente ao aspeto que o sucesso deve ter.

Neste guia, vamos ajudá-lo a criar um PRD excecional, com objetivos claros, requisitos e um plano de ação bem pensado. Além disso, para o ajudar a poupar o seu precioso tempo, temos também um conjunto de instruções para LLM que irá gerar a maior parte do PRD por si (ou, pelo menos, fornecer-lhe um primeiro rascunho sólido!).

O que é um Documento de Requisitos do Produto (PRD)?

Em termos simples, um documento de requisitos do produto detalha as funcionalidades que devem ser incluídas numa determinada versão do produto. É um ponto de referência central para todas as equipas envolvidas na conceção e no desenvolvimento de um determinado produto. É também essencial para definir o roteiro do produto.

Tradicionalmente utilizado num ambiente de projeto com uma metodologia em cascata — em que o processo de desenvolvimento do produto é sequencial —, também pode ser utilizado na gestão ágil de produtos.

A partir das informações registadas no PRD, podem ser criados vários outros documentos. A equipa de engenharia pode criar um Documento de Requisitos Técnicos que detalhe as especificações do produto e os requisitos do sistema.

Os analistas de negócio podem criar um Documento de Requisitos Funcionais que detalhe o que acontece quando um utilizador interage com o sistema, incluindo esquemas para apresentar a conceção do produto. 

Os designers de experiência do utilizador (UX) podem criar um Documento de Requisitos da Interface do Utilizador que explique o aspeto e a experiência que o produto deve proporcionar.

Quais são as vantagens de elaborar um PRD e o que contém?

Investir tempo na elaboração de um PRD completo oferece várias vantagens. Vejamos algumas:

1. Coloca todas as partes interessadas em sintonia.
2. Torna claro o que está fora do âmbito
3. Promove a colaboração entre equipas
4. Coloca a perspetiva do cliente no centro do produto

Em termos de estrutura, um PRD típico deve conter o seguinte:

• Metadados do documento, como data de edição, histórico de versões, etc.
• Objetivos do produto que pretende alcançar.
• Dados da investigação sobre os clientes, como as personas-alvo.
• Lista prioritária das funcionalidades que pretende desenvolver.
• Âmbito negativo das funcionalidades que não irá desenvolver.
• Métricas principais para testar estas hipóteses.
• Hipóteses principais que as suas funcionalidades testam.
• Estratégia de lançamento que indique quando e como a funcionalidade será disponibilizada.

Embora a maioria dos PRD contenha estes elementos, é perfeitamente aceitável adicionar ou remover elementos com base nas suas necessidades e na realidade do seu produto.

Qual é um exemplo de um documento de requisitos do produto?

Por vezes, é mais fácil compreender o que deve ser incluído num documento através de um elemento visual, por isso, apresentamos aqui um exemplo de um PRD concluído.

Como redigir um documento de requisitos do produto (com uma pequena ajuda dos LLM)

Mesmo com toda a informação que já partilhámos, elaborar o seu primeiro PRD pode parecer uma tarefa intimidante. Não se preocupe; nós ajudamo-lo! Apresentamos aqui a nossa lista de verificação de 10 passos para a utilização da IA na recolha de requisitos e para a criação de um PRD sólido. Além disso, incluímos um modelo para o ajudar a reunir toda a informação certa.

Passo 1: Clarifique o problema

Antes de fazer qualquer outra coisa, é fundamental ter clareza sobre o problema que está a tentar resolver e sobre as personas de utilizador para as quais está a tentar resolvê-lo. Isto irá influenciar exatamente que funcionalidades inclui no produto e quais prioriza para o lançamento. 

O Documento de Requisitos de Negócio deve conter uma declaração das necessidades que detalhe o problema enfrentado e a forma como o produto deve funcionar para o resolver. É importante rever o BRD e clarificar exatamente o que a empresa necessita do produto antes de elaborar o PRD.

Passo 2: Reveja a investigação de mercado e dos utilizadores

Quando estiver a redigir um PRD, já deverá ter preparada a sua investigação de mercado e as suas personas. No entanto, por vezes, a persona de uma funcionalidade específica pode ser diferente da persona geral que tem. Por isso, se for esse o seu caso, vamos gerar uma descrição de persona utilizando este pedido para LLM:

Eis as transcrições de várias entrevistas de descoberta de produto que realizei com os meus utilizadores.

{carregue as suas transcrições como ficheiros txt nesta mensagem}

Analise estas transcrições, identifique as características comuns entre elas e gere uma descrição de persona seguindo esta estrutura (delimitada por etiquetas XML):


<USER_PERSONA_STRUCTURE>

1. Nome:

(Fictício, mas realista, por exemplo, Ana, a Contabilista Ocupada)

2. Dados demográficos:

	•	Idade
	•	Género (opcional)
	•	Localização
	•	Profissão

3. Objetivos:
	•	Principal(is) objetivo(s) que pretende alcançar
	•	Objetivos secundários ou relacionados

4. Desafios/Pontos problemáticos:
	•	Principais obstáculos que enfrenta
	•	Frustrações ou necessidades

5. Comportamentos:
	•	Hábitos, preferências e padrões de utilização relevantes

6. Ferramentas/Plataformas preferidas:
	•	Aplicações, websites e dispositivos que utiliza frequentemente

7. Uma citação curta (opcional, mas poderosa):

Uma frase que capte o que sente relativamente às suas necessidades.

(Exemplo: “Só quero um sistema que me poupe tempo sem precisar de um manual.”)

</USER_PERSONA_STRUCTURE>


Exemplo:

Nome: Ana, a Contabilista Ocupada

Dados demográficos: 34 anos, vive em Chicago, CPA numa pequena empresa

Objetivos: Concluir o trabalho dos clientes mais rapidamente, minimizar as tarefas administrativas manuais

Desafios: Demasiada papelada, software difícil de utilizar, pressão de tempo

Comportamentos: Trabalha até tarde durante a época fiscal, prefere aplicações simples e acessíveis através de dispositivos móveis

Ferramentas preferidas: QuickBooks, Slack, Google Drive

Citação: “Se não for simples, não tenho tempo para isso.”


Requisitos para a criação da persona:

- utilize apenas as informações fornecidas nas transcrições e não invente informações que não estejam presentes.

- utilize apenas características que estejam presentes em pelo menos 80% das transcrições que partilhei consigo.

- se não encontrar informação suficiente para um elemento específico dos dados da persona, deixe-o em branco.

Como resultado, obterá uma descrição de persona que poderá incluir no seu documento de requisitos do produto. No entanto, verifique cuidadosamente o conteúdo gerado pelo LLM, pois poderá conter erros.

Passo 3: Envolva as partes interessadas funcionais

Como já referimos, os melhores PRD são desenvolvidos de forma colaborativa. Marque uma reunião multifuncional para recolher contributos de diferentes áreas da empresa e utilizá-los no seu documento de requisitos. 

Esta é uma excelente oportunidade para as partes interessadas identificarem quaisquer pressupostos, levantarem preocupações sobre riscos ou limitações e registarem quaisquer dependências que possam afetar o processo de desenvolvimento do produto. 

Passo 4: Defina a sua hipótese principal e as métricas do produto

Independentemente do tipo de funcionalidade que desenvolva, espera que esta tenha algum tipo de impacto nos seus utilizadores ou na sua empresa. Para conseguir medir esse impacto e verificar se a sua funcionalidade foi bem-sucedida ou não, precisa primeiro de definir uma hipótese testável.

O meu formato preferido para uma hipótese chama-se Se-então-porque. Tem o seguinte aspeto:

Acreditamos que, se [desenvolvermos a funcionalidade A], então a [métrica principal B] irá [aumentar/diminuir] em [quantidade C], porque [explique porquê].

Por exemplo, se estivesse a trabalhar no Spotify, poderia ser algo assim.

Acreditamos que, se desenvolvermos listas de reprodução para a rotina matinal, a retenção diária aumentará 5%, porque mais pessoas utilizarão o Spotify todas as manhãs.

Para automatizar este processo com IA, explique simplesmente, pelas suas próprias palavras, o que espera que a funcionalidade alcance e peça-lhe para o formular no formato Se-então-porque. Eis o pedido:

{insira aqui a explicação da sua funcionalidade}

Formule uma hipótese utilizando o formato se-então-porque.

Requisitos:

- A hipótese não deve ter mais de 100 palavras.

- Utilize apenas o contexto que forneci.

Com a hipótese pronta, também precisa de definir as métricas do produto que pretende medir para essa funcionalidade.

Obviamente, pretende medir a métrica que a sua hipótese visa (retenção, no caso do Spotify). Mas também existem 3 métricas fundamentais de que precisa para qualquer funcionalidade:

• Adoção
• Retenção
• Interação

Pode pedir à IA que o ajude a escolher a métrica certa, juntamente com os eventos que a sua ferramenta de análise deve acionar para medir essas métricas. Eis um pedido que pode utilizar.

{insira aqui a explicação da sua funcionalidade}

Eis a hipótese:

{insira aqui a hipótese do pedido anterior}

Sugira métricas a acompanhar, juntamente com os respetivos acionadores de eventos. Sugira métricas nestas categorias:

- Adoção

- Retenção

- Interação

Tenha em consideração que vou adicionar estas métricas ao Documento de Requisitos do Produto relativo à funcionalidade que descrevi.

No nosso exemplo do Spotify, as métricas seriam as seguintes:

Adoção: % de utilizadores que iniciaram uma lista de reprodução matinal. O acionador do evento é o momento em que o utilizador inicia a lista de reprodução.

Retenção: % de utilizadores que utilizaram a lista de reprodução matinal durante 7, 14 e 30 dias. O acionador do evento é o momento em que o utilizador inicia a lista de reprodução.

Interação: Média de minutos que os utilizadores ouviram a lista de reprodução. Os acionadores dos eventos são o início e a paragem da lista de reprodução.

Passo 5: Prepare os seus designs

Nenhum PRD fica completo sem design — se a funcionalidade precisar dele. Algumas equipas anexam os designs finais; outras preferem incluir apenas conceitos de alto nível ou um protótipo, aperfeiçoando os detalhes mais tarde com a equipa.

Ambas as abordagens têm vantagens e desvantagens. Os designs finais oferecem clareza, mas tornam a entrega do PRD mais lenta. Os conceitos iniciais aceleram a passagem para a equipa, mas podem originar interpretações erradas e retrabalho.

Qual é o equilíbrio ideal? Partilhe designs que cubram a jornada principal do utilizador e os estados mais importantes, deixando de fora elementos secundários, como estados vazios ou de erro. Felizmente, as modernas ferramentas de design UX permitem obter um protótipo e um design em simultâneo.

Desta forma, entrega o design e o PRD à sua equipa mais cedo, minimizando simultaneamente o risco de ambiguidades.

Passo 6: Divida a sua ideia em funcionalidades independentes

Não creio que seja necessário explicar aos PMs experientes as vantagens de dividir uma funcionalidade grande em histórias de utilizador mais pequenas e fáceis de gerir. Se é novo na gestão de produto, eis algumas:

• As histórias pequenas são mais fáceis de estimar para a sua equipa.
• São mais fáceis de entregar, uma vez que a equipa pode concentrar-se numa história de cada vez e concluí-las sem dificuldades.
• São mais rápidas de testar, pois os seus QAs podem testar uma história enquanto a equipa desenvolve a seguinte — paralelizando o trabalho dos testadores e dos programadores.
• Dão-lhe a flexibilidade de remover as menos importantes do âmbito para acelerar a entrega.

Dividir a funcionalidade é excelente, mas é apenas metade do trabalho. A segunda metade consiste em estabelecer prioridades. Nem todas as histórias têm a mesma importância. Algumas partes da sua funcionalidade representam a jornada principal, enquanto outras são complementos úteis, mas não essenciais. No nosso exemplo do Spotify, esta será a lista de histórias importantes e não importantes utilizando o método de priorização MoSCoW.

Ao analisar a lista, é evidente que a possibilidade de os utilizadores verem a lista de reprodução matinal e lhe acederem com um único toque é muito mais importante do que a possibilidade de editarem a lista de reprodução.

Por isso, se enfrentar uma limitação de tempo e precisar de lançar rapidamente, pode remover a história de utilizador relativa à edição da sua versão e passá-la para versões futuras.

Algumas pessoas criam esta lista numa folha de cálculo. No entanto, recomendo a utilização de uma ferramenta especializada de roteiro de produto, uma vez que também inclui funcionalidades nativas de priorização e integração.

Passo 7: Defina a estratégia de lançamento

Os lançamentos na vida real raramente são simples — concluir toda a funcionalidade e lançá-la em produção. Na maioria das vezes, o lançamento de uma funcionalidade grande (digna do seu próprio PRD) é um processo composto por várias fases que pode incluir potencialmente o seguinte:

• Desenvolver a versão MVP, contendo apenas as histórias indispensáveis, e realizar um lançamento beta.
• Recolher feedback, corrigir os problemas, adicionar as histórias que deveriam estar incluídas e preparar o lançamento em produção.
• Realizar um lançamento gradual em produção, dividido em várias fases.
• Adicionar as funcionalidades que poderiam ser incluídas, caso verifique que são necessárias.

Para acelerar o processo de criação de uma estratégia de lançamento, pode pedir ajuda ao seu LLM utilizando esta instrução.

Quero criar {insira aqui a explicação da sua funcionalidade}.

Eis uma lista de histórias de utilizador para essa funcionalidade, priorizadas utilizando o MoSCoW:

{insira aqui a lista de funcionalidades do passo anterior}

Crie uma estratégia de lançamento para esta funcionalidade. A estratégia deve:

- Agrupar as funcionalidades da lista acima em vários lançamentos, incluindo a versão MVP.

- Se considerar necessário, incluir uma fase de lançamento beta

- Se considerar necessário, incluir uma implementação gradual com 2 ou mais fases, incluindo os respetivos prazos, as percentagens de utilizadores a abranger em cada fase, bem como a descrição dos tipos de utilizadores a incluir em cada fase de implementação.

Critérios para decidir se é necessário um lançamento beta (em formato CSV, delimitado por etiquetas XML):

<BETA_RELEASE_CRITERIA>

Critério,Lançamento beta,Lançamento direto em produção

Risco para o utilizador,Médio a elevado – impacto incerto nos utilizadores ou possíveis regressões,Baixo – a funcionalidade foi bem testada e apresenta baixo risco para os utilizadores

Maturidade da funcionalidade,MVP ou experimental; pode não estar totalmente aperfeiçoada ou ter uma experiência de utilizador incompleta,Totalmente desenvolvida e estável

Necessidade de feedback,Elevada – o feedback inicial dos utilizadores é essencial para validar a direção ou as opções de experiência de utilizador,Baixa – existe confiança no valor e na facilidade de utilização da funcionalidade

Confiança na garantia de qualidade,Moderada – são necessários testes em situações reais para complementar a garantia de qualidade interna,Elevada – foi testada exaustivamente internamente

Incerteza quanto ao impacto no negócio,Não é claro se terá impacto nos principais indicadores-chave de desempenho (retenção, conversão, etc.),É esperado um impacto positivo ou neutro, sustentado por validação anterior

</BETA_RELEASE_CRITERIA>

Critérios para decidir se é necessária uma implementação gradual (em formato CSV, delimitado por etiquetas XML):

<GRADUAL_RELEASE_CRITERIA>

Critério,Implementação gradual,Implementação imediata completa

Risco para o utilizador,Elevado – a funcionalidade pode causar regressões, erros ou confusão se for disponibilizada em grande escala,Baixo – a perturbação para os utilizadores é mínima mesmo que ocorram problemas inesperados

Risco de carga do sistema,Elevado – a funcionalidade pode aumentar a carga no servidor ou no sistema de retaguarda; comportamento de escalabilidade desconhecido,Baixo – o desempenho foi validado nas condições de pico esperadas

Âmbito da alteração,Grande – afeta percursos críticos, fluxos principais da experiência de utilizador ou lógica do sistema de retaguarda,Pequeno – autónomo, opcional ou limitado no âmbito

Preparação para a monitorização,As métricas, os alertas e os registos estão prontos para detetar problemas em pequenos grupos de utilizadores,Não é essencial – baixo risco de falhas silenciosas ou regressões difíceis de detetar

Complexidade da reversão,Elevada – difícil de reverter depois de totalmente disponibilizada (por exemplo, migrações de esquema ou alterações de dados),Baixa – fácil de desativar ou corrigir se algo correr mal

</GRADUAL_RELEASE_CRITERIA>

Muito provavelmente, os prazos fornecidos pelo LLM seriam irrealistas. Por isso, sinta-se à vontade para os alterar com base na capacidade da sua equipa e nos objetivos do seu produto.

Passo 8: Elaborar o PRD

Utilizando as informações recolhidas no passo anterior, pode agora elaborar o PRD.

Mais uma vez, para poupar tempo, pediremos ao LLM da nossa escolha que o faça por nós utilizando este pedido.

Crie um Documento de Requisitos do Produto utilizando esta estrutura (delimitada por etiquetas XML):


<PRD_STRUCTURE>

1. Objetivo

    - Visão
    - Objetivos
    - Persona(s)

2. Funcionalidades (tabela com as seguintes colunas)

    - Nome abreviado da história de utilizador
    - Descrição breve da história de utilizador
    - Prioridade da história de utilizador

3. Fluxo do utilizador e design

    - Deixe aqui um texto de marcador de posição "insira aqui o percurso do utilizador e as ligações para o design"

4. Estratégia de lançamento

    - Fases de lançamento com o respetivo âmbito. Inclua o lançamento beta se tiver fornecido um no contexto de lançamento abaixo
    - estratégia de implementação gradual se tiver fornecido uma no contexto de lançamento abaixo. Se a implementação gradual for relevante, inclua as percentagens de utilizadores a abranger em cada fase, bem como a descrição dos tipos de utilizadores a incluir em cada fase de implementação.

5. Análise

    - Hipóteses fundamentais
(tabela com estas colunas)
    - Métrica
    - Alteração pretendida
    - Gatilho do evento

</PRD_STRUCTURE>


Utilize estas informações contextuais para gerar o PRD (delimitadas por etiquetas XML):

<USER_PERSONAS>

{insira aqui a descrição da persona}

</USER_PERSONAS>


<CORE_HYPOTHESIS>

{copie e cole aqui a hipótese fundamental dos passos anteriores}

</CORE_HYPOTHESIS>


<KEY_METRICS>

{copie e cole aqui a lista de métricas-chave dos passos anteriores}

</KEY_METRICS>


<USER_STORIES>

{copie e cole aqui a lista de histórias de utilizador dos passos anteriores}

</USER_STORIES>


<RELEASE_STRATEGY>

{copie e cole aqui a estratégia de lançamento dos passos anteriores}

</RELEASE_STRATEGY>

Tudo o que lhe resta fazer é rever rapidamente o conteúdo do PRD. Preste especial atenção à visão e aos objetivos, uma vez que o LLM tentará gerá-los com base nas descrições da sua funcionalidade. Se não gostar deles, sinta-se à vontade para os editar.

Passo 9: Obter a aprovação formal

Assim que o PRD estiver concluído, certifique-se de que é aprovado formalmente pelo cliente. No caso de um projeto interno, poderá tratar-se do patrocinador do projeto ou da equipa de liderança sénior. Isto ajuda a garantir o alinhamento empresarial e o apoio ao processo de desenvolvimento do produto. 

A aceitação dos critérios de lançamento é extremamente importante para que não existam mal-entendidos sobre aquilo que o produto conseguirá fazer em termos de funcionalidade, facilidade de utilização e desempenho no final do processo de desenvolvimento.

Passo 10: Partilhar e comunicar

Depois de o PRD ser aprovado formalmente, partilhe o local onde será armazenado e comunique o processo para aceder, consultar e alterar o PRD durante o processo de desenvolvimento do produto. 

O PRD finalizado deve ser utilizado como ponto de referência ao longo de todo o projeto e pode ser atualizado em tempo real caso os requisitos se alterem. No entanto, deve existir sempre uma forma de identificar aquilo que foi originalmente acordado, e quaisquer alterações efetuadas devem ser devidamente documentadas e acompanhadas de uma justificação para a alteração.

Boas práticas para documentos de requisitos do produto

Esperamos ter esclarecido exatamente o que deve conter um PRD, por isso vamos analisar algumas boas práticas para o elaborar.

• Obtenha contributos das partes interessadas. Os melhores PRD são criados com contributos de todas as principais partes interessadas. Não vale a pena criar uma longa lista de funcionalidades críticas apenas para os engenheiros explicarem que não são viáveis. Envolver outras equipas desde o início traz clareza e permite sinalizar pressupostos, restrições e dependências.
• Aproveite as ferramentas modernas. Felizmente, existem muitas ferramentas de documentação orientadas para software que nos ajudam a criar e gerir PRD. O Notion, por exemplo, inclui modelos de PRD prontos a utilizar, bem como tabelas com formatação avançada onde pode listar os seus pressupostos ou funcionalidades. O Confluence, por outro lado, inclui integração nativa com o Jira e o BitBucket, permitindo incorporar tarefas e versões no documento.

• Faça iterações conforme necessário. O PRD deve ser um documento vivo. A alteração dos requisitos dos clientes ou do mercado pode significar que as capacidades do produto têm de ser aumentadas, repriorizadas ou totalmente abandonadas. O prazo pode ter de ser encurtado para garantir uma entrada no mercado ou prolongado caso um pressuposto não se concretize.

• Utilize o controlo de versões. Embora seja importante que o PRD seja revisto e alterado conforme necessário, é fundamental que o gestor de produto possa consultar sempre aquilo que foi originalmente acordado. Utilizar o controlo de versões e garantir níveis de acesso adequados significa que existe sempre um registo do que foi acordado no passado, do que foi alterado e do motivo.

• Mantenha-o visível. Um PRD não é um documento que se cria uma única vez e se guarda numa gaveta depois da reunião de planeamento do projeto — é um recurso essencial para a gestão do projeto. Como já referimos, o seu PRD funciona como um ponto de referência para todos os membros da equipa que trabalham no produto, pelo que é fundamental mantê-lo visível. 

Modelo de documento de requisitos do produto

Para concluir, apresentamos um modelo de PRD que pode utilizar para começar hoje a elaborar o seu primeiro documento de requisitos do produto. 

Personalize-o de acordo com as necessidades do seu projeto, adicionando e removendo secções conforme necessário para garantir clareza.

Modelo de documento de requisitos do produto

Esclareça hoje os requisitos do seu produto

Se leu atentamente todas as informações acima, está no bom caminho para criar um excelente documento de requisitos do produto.

Embora possa exigir algum tempo inicialmente, os benefícios compensam o esforço, e o nosso modelo de exemplo pode ajudá-lo a planear e desenvolver o seu próximo grande produto.

Somos uma comunidade de profissionais de produto (tal como você!), por isso, se considerou estas informações úteis, subscreva a nossa newsletter. Mantê-lo-emos atualizado com artigos úteis, guias práticos, análises de ferramentas e muito mais.