Repensando a Especificação de Produto: Por que precisamos ir além do documento

Explore como a especificação de produto tradicional precisa evoluir para protótipos de alta fidelidade, garantindo entregas mais eficazes e alinhadas.

A especificação de produto precisa urgentemente de uma renovação.

O problema não está na documentação em si, mas em como materializamos e comunicamos a solução do produto que queremos construir.

Eu não acho que o Product Manager seja o dono da solução, mas entendo que o Designer esteja mais próximo desse papel do que o PM. Contudo, o PM descreve O QUE iremos resolver e não o COMO, embora ele possa participar desse processo. Mesmo assim, ainda insistimos em tentar escrever documentos enormes que nos trazem uma impressão de que estamos no controle, mas na verdade é uma percepção falsa.

O problema com as especificações tradicionais

Nós temos uma série de formatos de documentos e estruturas de escrita de especificação no mercado: PRDs (Product Requirements Document), MRDs (Market Requirements Document), BRDs (Business Requirements Document) por exemplo, que podem ser usados por nós como bons templates para centralizar informações sobre um produto ou feature. Mas, entendo que esses formatos perderam seus propósitos originais.

Outro ponto é onde e como escrevemos esses documentos. Dependendo do sistema de gestão que você utiliza, não é possível criar uma base de conhecimento bem conectada, ou pior, pode ser que esses documentos não sejam acessíveis pra maioria das pessoas da empresa.

Embora o formato, estrutura, serviço que usamos para manter essas especificações possam ajudar até certo ponto, elas geralmente:

• Demoram muito para serem escritas;
• Raramente são lidas pela equipe;
• Não fornecem todos os detalhes necessários;
• Não abordam as questões mais difíceis ou informações críticas;
• Não são atualizadas na frequência e na qualidade que deveriam;

O mais preocupante é que a mera existência desses documentos serve como um falso indicador para a gestão e para o time de que tudo está progredindo bem.

Os fundamentos de uma boa especificação

Se você também entende que uma das responsabilidades de um Product Manager é entregar para o time uma especificação que descreva como o produto ou feature resolverá um determinado problema da empresa ou do usuário, você pode concordar que escrever e manter uma especificação completa e atualizada é praticamente impossível de se fazer nos percalços do dia a dia.

Contudo, entendo que uma boa especificação precisa:

1. Descrever claramente o contexto do problema que estamos tentando resolver;
2. Descrever a experiência completa do usuário. Isso inclui a interação do ponto de vista de quem vai usar o produto;
3. Representar com precisão o comportamento do software, não apenas os critérios de aceite, mas também a interação do usuário e principalmente o design;
4. Facilitar a comunicação efetiva para todas as áreas além de devs e QAs, mas também atendimento, marketing, operações e vendas;
5. Ser acessível e adaptável a mudanças - mesmo que as mudanças nesse documento possa diminuir depois que o desenvolvimento começa;
6. Deveria ser uma única fonte da verdade, minimizando confusão e problemas sobre como o produto funciona e motivos pelo qual determinadas decisões foram tomadas;
7. Deveria facilitar a derivação de outros materiais como apresentações, FAQs, manuais, treinamentos, melhorando todo o processo posterior a sua escrita;

Podemos listar outros motivos ou aspectos importantes que podem compor esse documento, como por exemplo, a adição do processo de upstream e também as especificações técnicas.

Protótipos como solução

No último ano, eu exercido uma série de papéis de produto. Meus dias tem sido uma viagem constante em várias camadas da construção de produto e negócio, saindo da estratégia, indo para o tático, avançando pra a execução e depois voltando novamente para estratégia. Isso tudo as vezes acontece no mesmo dia em questão de horas.

Dessa forma, procurar processos mais eficientes para escrever PRDs e Histórias para as tasks dos produtos e features que estávamos desenvolvendo, foi bastante desafiador, porque eu preciso escrever rápido as tasks que serão utilizadas por designers, devs e QAs, sem deixar tudo muito superficial. Confesso que falhei na missão uma série de vezes. Mas, nos últimos dias, eu percebi que um formato que mais tem se facilitado a minha vida e também a vida do time, é especificar utilizando protótipos e as telas já finalizadas do produto.

Combinei com as designers do time, de que eu passaria a escrever Critérios Gerais, sem dizer especificamente como sistema iria funcionar, mas abordando de forma ampla como a solução deveria ser. Isso meu deu mais tempo para investir em outros focos, deu mais liberdade pra elas explorarem não apenas um lado da solução, mas também encontrar cenários que só seria possível por quem está realmente materializando a jornada do usuário.

Eu sei que essa abordagem é a mais óbvia e cliché de todas. Mas é muito importante entender que o time, principalmente designers, precisam ter determinada maturidade de produto para entender que eles ganham uma responsabilidade de decisão importante. Não é meramente materializar uma tela, mas é decidir de verdade a decisão.

E é aí que entra, talvez, a única forma de especificação e documento que consegue entregar todos os aspectos que procuramos: o protótipo.

O Figma e outros similares já facilitam muito a criação de protótipos, ainda mais quando estamos utilizando algum design system para facilitar a dos layouts e das interações. Isso significa que é facilmente possível criar uma representação realista da experiência do usuário que estamos propondo. Não há motivo para não fazê-lo.

O protótipo pode (e deve) simular o processamento e os dados do backend, desde que a experiência do usuário seja plausível. Minha perspectiva evoluiu de prototipar apenas alguns componentes críticos da experiência do usuário para agora tentar defender a prototipagem de praticamente tudo - todas as telas e todos os principais casos de uso. Designers que me perdoem.

Como executamos esse processo

O PM escreve uma PRD que é a parte mais essencial e inicial do processo. Esse PRD deve seguir o formato que vocês definirem, mas pensa que ele deve ser a especificação mais ampla e completa do que uma história obviamente.

Nessa PRD não deve haver detalhes do COMO. Esses detalhes devem ficarão na história, que pode ser uma versão mini da PRD, mas que detalha só uma parte da solução. Equanto que a PRD deve representar o que contempla POR QUÊ daquela solução existir como um todo, não apenas uma parte da feature ou da iniciativa.

A partir dessa PRD, os designers já conseguem ter uma boa base para construir a solução e preparar layouts e o protótipo.

Esse protótipo vai ser incrementado conforme escrevemos e aprofundamos os detalhes de como o usuário vai interagir. Então, a parte do PRD pode até ser dispensável, por que nem toda solução precisa ter uma especificação macro como a PRD, sendo possível ir direto pra o contexto de história.

As histórias de usuário que eu me refiro aqui, não são aquelas histórias tradicionais de "Eu como usuário XYZ, quando eu fizer determinada ação, então deve acontecer ABC... Eu não escrevo histórias assim faz tempo. Basicamente minhas histórias consistem em 3 grandes blocos:

• Contexto da oportunidade ou do problema: onde eu detalhe o que está nos motivando a criar aquela solução. Dois parágrafos bastam. Lembre-se que o motivo maior estará na PRD. Aqui é mais focado naquela tarefa, iniciativa, pedaço específico.
• Solução: também só um ou dois parágrafos, descrevendo qual é a solução que será construída.
• Critérios gerais: Os critérios, regras e aspectos gerais descrevendo as delimitações e informações essencais e relevantes, numa visão mais ampla, que permeia toda a solução, deve ter a atenção do time no momento da construção;
• Critérios de funcionamento: aqui são os critérios de funcionamento do ponto vista da pessoa que vai usar aquele pedaço do produto, dividos em cenários, jornadas e também, quando necessário, em personas diferentes. Exemplo: se a solução envolve uma atividade que o Backoffice vai faze no Dashboards que irá afetar o B2C em outra plataforma.

E aqui vem a parte mais importante: os critérios de funcionamento, eu só tentao escrever após os layouts e protótipo que o designer entregar. O motivo disso é o que eu já disse: o designer é o responsável pela solução. Se o PM fala por quê devemos construir, e o dev diz como contruir, o designer diz o que construir.

Dessa forma, eu consigo escrever posteriormente os critérios de funcionamento baseados exatamente nos comportamentos reais do usuário. Ideal aqui, se fossem os próprios designers que escrevessem. E eu tenho pra mim, que até os QAs poderiam fazer essa parte em vez dos PMs, dado que eles devem testar e garantir que a funcionalidade saia como planejado. Mas essa é uma opinião muito polêmica

Os benefícios dessa abordagem

Essa abordagem do protótipo (que nem precisa ser algo navegável e todo cheio de frescura, podendo ser só um fluxo descrito com os layouts finais, e as devidas instruções de cenários) traz benefícios claros:

• Pode ser testado com usuários reais antes do desenvolvimento;
• Fornece uma referência clara e não ambígua para devs;
• Facilita o trabalho de QA ao definir claramente o comportamento esperado;
• Permite que marketing, vendas e suporte aprendam o produto mais cedo;
• Ajuda executivos a demonstrarem o produto para investidores e parceiros;
• Serve como documentação ou complemento da documentação;
• É um formato que garantimos que será atualizado sempre que há mudanças no produto;
• É possível entender o funcionamento do produto, sem precisar ter critérios escritos de forma clara;

O mais surpreendente é que criar uma especificação dessa forma geralmente reduz significativamente o tempo de lançamento no mercado. Isso acontece porque as questões difíceis e os detalhes críticos são abordados e resolvidos antes do desenvolvimento, evitando mudanças constantes durante a fase de construção.

Conclusão

A especificação tradicional de produto precisa evoluir. Em vez de gastar semanas trabalhando em um documento gigante que poucos lerão e que ainda está longe de ser real e testável, trabalhe com seu designer para criar um protótipo do produto que você está propondo. É como construir uma casa: é muito mais eficiente resolver questões de design e estrutura na planta do que quando as paredes já estão erguidas.

Não se apegue a fazer algo navegável, mas a ter telas e fluxos bem descritos no Figma (ou similar), que ensine por meio dos layouts prontos, além de dar instruções de funcionamento mais próximos do que será o resultado final.

Algumas perguntas para refletir:

• Como sua empresa documenta especificações de produto hoje?
• Quais são os principais pontos de atrito na comunicação entre produto, desenvolvimento e outras áreas?
• Que benefícios você vê em adotar uma abordagem baseada em protótipos ou fluxos de alta fidelidade ANTES de você escrever os critérios finais?
• Como você poderia começar a implementar essa mudança em seu contexto atual?