Como criar um roadmap de produto a partir do feedback

Criar um roadmap de produto se resume a isto: reúna o que os clientes já pediram, agrupe por problema por trás de cada pedido, ordene os grupos com uma regra que você consiga explicar, decida o quanto está seguro de cada um e publique o resultado num formato que combine com quem o lê. A ordem importa. Equipes que começam por um layout e o enchem de ideias ficam com um documento que parece pronto e não carrega evidência alguma. Equipes que começam pelos pedidos ficam com um roadmap mais curto, com um motivo por trás de cada linha.

Por onde começar a criar um roadmap de produto?

Comece pela evidência que você já tem, não por uma página em branco. Pedidos de funcionalidades abertos, conversas de suporte marcadas com a mesma reclamação, anotações de ligações de vendas e dados de uso do seu próprio produto são todos insumos. Junte tudo numa lista e anote de onde veio cada item.

Os pedidos raramente chegam num formato utilizável. “Adicionar integração com Slack” e “avisar minha equipe quando uma tarefa mudar” podem ser a mesma necessidade. Por isso o próximo passo é agrupar, e por isso vale ter um tracker que una duplicatas; pedidos de funcionalidade duplicados mostra como. Lembre também que tickets de suporte e pedidos de funcionalidades trazem tipos diferentes de sinal, e um roadmap feito só com um deles vai pender para o lado errado.

Como transformar pedidos em itens do roadmap de produto?

Agrupe os pedidos pelo problema, nomeie cada grupo como um resultado e guarde a contagem. Um grupo de catorze pedidos que descrevem a perda de um filtro após recarregar a página vira um item: “Manter o filtro usado da última vez”. A contagem vai na coluna de origem, para quem lê o roadmap ver o peso por trás dele.

Escreva o resultado com as palavras do cliente. “Implementar persistência de visão salva” diz ao engenheiro o que construir e não diz nada ao cliente. Formular o resultado também força uma pergunta útil: se você não consegue dizer o que muda para o cliente, talvez seja uma tarefa interna que pertence a outra lista.

Como decidir o que vem primeiro?

Escolha uma regra de pontuação, escreva-a e aplique-a a todos os itens. O RICE, que pontua alcance, impacto, confiança e esforço, é o mais comum; o texto da Intercom sobre o RICE é a fonte original. Uma regra mais simples funciona igualmente bem se você souber explicá-la: número de pedidos, ponderado pelo fato de o autor ser uma conta paga ativa, dividido pelo esforço aproximado.

O que importa é que a regra esteja declarada, porque o primeiro cliente a perguntar por que o pedido dele não está na lista vai querer uma resposta. Onde a regra e o seu julgamento divergem, diga isso na linha. Priorizar pedidos de funcionalidades percorre métodos de pontuação, a questão da ponderação por receita e o que os votos dizem e não dizem.

Quão seguro você está de cada item?

Rotule cada item com sua confiança antes de publicar qualquer coisa. Uma escala simples de três valores basta: comprometido significa que a equipe ficaria surpresa se não entregasse na janela, previsão significa que é o plano a menos que algo mude, e explorando significa que não há promessa.

Essa única coluna evita a maior parte do estrago em roadmaps. Sem ela, o cliente lê um item em exploração como compromisso, vendas o cita e um trimestre depois ele vira reclamação. O ensaio de Marty Cagan sobre a alternativa aos roadmaps faz o argumento de fundo: uma lista de funcionalidades com datas é uma lista de palpites apresentados como planos, e o remédio é ser explícito sobre o que você sabe.

Que formato o roadmap deve ter?

Escolha o layout por último, conforme o leitor. Clientes que perguntam se vocês os ouviram precisam de uma visão pública curta. A liderança que pergunta por que este trabalho precisa de temas ou resultados. Uma equipe que muda de direção todo mês se dá bem com Now, Next e Later e sem datas. Exemplos de roadmap de produto mostra seis formatos com itens realistas e como cada um falha, e o modelo de roadmap de produto traz os campos para copiar depois de escolher.

A maioria das equipes acaba com dois documentos: um roadmap estratégico para leitores internos e um público reduzido, que mostra só o que vocês aceitam ser cobrados. Se publicar um, roadmap público descreve como alimentá-lo com etiquetas nas issues que você já acompanha.

Como evitar que o roadmap fique obsoleto?

Dê a cada linha uma data de revisão e mantenha o roadmap onde o trabalho já está. Um roadmap atualizado à mão numa ferramenta separada fica obsoleto porque o trabalho diário de ninguém o inclui. Se cada coluna corresponde a uma etiqueta na issue, o roadmap muda quando a etiqueta muda.

Feche o ciclo quando um item for lançado. Quem pediu deve ficar sabendo, e a entrada do changelog é o lugar de costume; o ciclo de feedback do cliente descreve o caminho inteiro. Se decidir não construir algo, diga isso também. Um não claro é útil para quem pediu, e recusar pedidos de funcionalidade cobre a redação.

FAQ

Quais são os passos para criar um roadmap de produto? Reúna pedidos e dados, agrupe-os pelo problema por trás de cada um, ordene com uma regra escrita, rotule cada item com o quanto você está seguro, escolha um formato para o leitor e marque uma data de revisão. Partir da evidência mantém o roadmap curto e defensável.

No que um roadmap de produto deve se basear? Em pedidos de clientes, temas de suporte, dados de uso e na sua estratégia, nesta ordem de quanto costumam ser ignorados. Um roadmap sem origem por trás das linhas é uma lista de desejos.

Quanto tempo um roadmap de produto deve cobrir? O bastante para ser útil e pouco o bastante para ser crível. Para muitas equipes pequenas, é o trimestre atual em detalhe e um ou dois seguintes como temas. O que estiver mais longe vai em “later”, sem datas.

Quem deve participar da criação de um roadmap de produto? O dono do produto decide, a engenharia avalia viabilidade e esforço, e suporte e vendas trazem os pedidos e temas que ouvem. Os clientes veem o resultado numa versão pública, mas não o editam.

As afirmações técnicas deste artigo não foram revisadas de forma independente. Se algo estiver errado, avise a gente e vamos corrigir.

Relacionado na changeloop: Documentação para desenvolvedores, Exemplos de changelog