Introdução à especificação e documentação de Produtos Digitais

Um produto digital não tem fim. Ele evolui todos os dias. Ele é direcionado para novas posições de mercado. O objetivo inicial pode ter sido transformado em algo maior do que o objetivo original. Com isso, é necessário dar visibilidade de onde estamos e para onde estamos indo, quais os próximos passos e qual o planejamento tático que vamos seguir para tentar alcançar os objetivos definidos.

O problema da visibilidade

Sem uma especificação, o produto se transforma em improviso. Embora o time tenha clareza dos objetivos da empresa e o PM saiba exatamente para onde o produto deve caminhar, pessoas entram e saem da empresa, mudanças de ideia, escopo, prioridades acontecem o tempo todo. Se não houver uma espécie de manual, que mostre os motivos das decisões e principalmente como isso será executado, você perde.

Nos primórdios, a especificação do produto era feita diretamente no sistema de workflow que o time usava - geralmente o Jira (mal necessário). Isso fazia com que o único histórico que tínhamos eram histórias mal escritas, sem definição dos objetivos e dos verdadeiros motivos estratégicos pelos quais o time estava executando as tarefas. Tudo isso ficava perdido dentro de um Trello da vida, onde apenas o time tinha visibilidade. Só que apenas o time ter visibilidade gera um trabalho extra pegajoso para o Product Manager: gerir expectativas dos Stakeholders.

Gerir expectativas é um trabalho ingrato. Se você estiver bem preparado, você vai ter respostas na ponta da língua, mas na grande parte das vezes não será o suficiente, levando o PM a passar horas criando apresentações de reports, repetindo sempre as mesmas coisas para refrescar a memória dos diretores sobre os motivos das decisões já tomadas anteriormente.

Se o PM não estiver preparado, gerir expectativas se transforma em um trabalho de criação da melhor desculpa esfarrapada possível, torcendo para que os stakeholders sejam tão preguiçosos e displicentes quanto o PM, para não darem a devida atenção para o trabalho tático. Esse cenário é péssimo e só mostra que o trabalho mais básico do PM, que é conhecer o seu próprio produto, não está sendo feito com atenção.

A visibilidade do Produto deve existir não apenas para o time ou para os stakeholders, mas para toda a empresa. Em empresas de tecnologia, o Produto Digital é a ponta da empresa que faz interface com o mundo. É por lá que o mercado tem o primeiro contato e a empresa tem a oportunidade única de mostrar e levar valor para as pessoas. Você, como PM, precisa dar visibilidade dos seguintes pontos para toda a empresa, de forma constante e fundamentada:

• Futuro: Quais os problemas e KPIs vamos atacar em seguida, mostrando as hipóteses que estamos validando agora e testando com os usuários a fim de entender oportunidades de soluções. Basicamente aqui entramos no Upstream do Produto;
• Pré-presente: O que já está validado pelos stakeholders e usuários, mas está aguardando priorização para ser construído. Também é necessário mostrar os objetivos e KPIs de negócio que se pretende alcançar;
• Presente: O que já foi validado e estamos fazendo agora, lembrando por que isso está sendo feito, mostrando objetivos e KPIs de negócio que pretendemos alcançar;
• Passado: Histórico do que foi colocado, bem como os indicadores e métricas de antes e depois dessa solução ser publicada, indicando se os objetivos pretendidos foram alcançados;

Basicamente estamos falando de dar visibilidade do Upstream e do Downstream do produto, de forma que todos saibam impactos, esforço e tarefas que estão sendo ou que já foram construídas pelos times.

Toda essa visibilidade é importante para que o time possa ser blindado e as demandas que surgem de última hora possam ser priorizadas de uma forma mais eficiente. Além disso, isso já gere as expectativas de áreas que demandam para você diretamente, além das outras áreas que acham que podem ter o direito de usar seu time para cumprir com os objetivos deles. Isso é normal. Existem várias áreas que precisam da sua ajuda para resolver problemas que estão impactando algum processo interno. Essas áreas, não sabendo qual o objetivo do time ou a qual carga de trabalho o time está submetido, se apropriam do direto de demandar diretamente para vocês essas tarefas improvisadas. Essa visibilidade exposta para a empresa inteira previne ou mitigue muito problemas como esse.

Product Requirements Document

O PRD é um documento feito pelos Product Managers para manter não um simples histórico do que foi feito do produto, mas para manter visível para o time e para os stakeholders o que o produto é e o que ele será.

Não existe uma regra específica para escrevermos um PRD. Cada empresa e cada time tem suas próprias prioridades e necessidades. Mas um bom PRD cobrem os seguintes tópicos: