Como escrever um documento de roadmap que explica as contrapartidas
6 min de leitura
A maioria dos documentos de roadmap é uma lista ordenada sem nenhum raciocínio visível. Isso funciona bem até um stakeholder perguntar por que a funcionalidade B está acima da funcionalidade A, e a resposta honesta é uma mistura de instinto com quem perguntou mais recentemente, o que não se sustenta bem na reunião. Um PM apresentando um roadmap de seis itens a uma sala de stakeholders, cada um com sua funcionalidade favorita, pode passar a reunião inteira defendendo verbalmente a ordem em vez de apontar para um raciocínio que já estava na página.
Atenção
Uma lista ordenada sem raciocínio não é uma decisão, é um espaço reservado para uma. A primeira pergunta difícil na sala revela se a ordem foi realmente bem pensada.
Um roadmap que não consegue explicar sua própria ordem não é um roadmap. É uma lista esperando para ser discutida de novo.
Por que um motivo não registrado é discutido de novo todas as vezes
Ordenar por instinto pode até estar certo, mas ninguém mais consegue avaliar isso, então todo stakeholder com uma intuição diferente tem motivo para questionar. Sem raciocínio visível, a mesma conversa sobre contrapartidas se repete na próxima reunião, e na seguinte. Um roadmap apresentado como uma lista ordenada pura e simples convida exatamente o tipo de debate que um roadmap bem fundamentado evita, já que não há nada na página para um stakeholder desconfiado discutir além da memória do PM sobre por que tomou cada decisão.
Imagine uma revisão trimestral de roadmap em que um líder de engenharia pergunta por que uma funcionalidade de menor impacto está classificada acima de uma com alcance esperado claramente maior. Se a resposta honesta existe só na cabeça do PM, "simplesmente pareceu mais urgente", a reunião se transforma numa negociação em tempo real com quem pressionar mais forte. Se a mesma pergunta já está respondida na página, "a funcionalidade A fica em posição mais alta mesmo com alcance menor porque desbloqueia uma integração com parceiro com prazo contratual no mês que vem", a conversa se move para se esse raciocínio se sustenta, o que é um lugar muito mais produtivo para ela ir.
Antes: classificar funcionalidades por instinto, apresentar a lista, passar a reunião defendendo a ordem do zero.
Depois: dar ao Claude as funcionalidades candidatas com esforço e impacto, receber de volta um roadmap classificado com o raciocínio de cada posição por escrito, e entrar na reunião com as contrapartidas já na página.
Um processo para um roadmap com raciocínio visível
- 1
Liste as candidatas com estimativas reais de esforço e impacto
Dê números reais, mesmo que aproximados, semanas de engenharia para esforço, usuários afetados esperados para impacto, em vez de rótulos vagos como "grande" ou "pequeno". Entradas vagas produzem uma classificação sem nada sólido por trás.
- 2
Peça uma classificação com um motivo declarado por item
Peça duas frases de justificativa por funcionalidade, não só uma lista ordenada. O raciocínio é o que torna o roadmap defensável numa sala cheia de pessoas com suas próprias opiniões.
- 3
Pergunte o que mudaria a classificação
Com uma primeira versão em mãos, pergunte quais funcionalidades estão mais próximas de trocar de posição, e o que precisaria ser verdade para isso acontecer. É aqui que as contrapartidas reais, não só a ordem final, ficam visíveis.
- 4
Confira o raciocínio contra o que os stakeholders realmente valorizam
Compare o raciocínio declarado com o que você sabe que importa para as pessoas na sala, receita, retenção, dívida técnica. Uma classificação que só reflete esforço e impacto ainda pode perder a conversa real.
Aqui estão 6 funcionalidades candidatas com estimativas aproximadas de esforço e impacto esperado. Classifique-as num roadmap do terceiro trimestre, e escreva duas frases justificando cada posição.
”Se um stakeholder específico é conhecido por dar mais peso a uma dimensão do que a outras, digamos, a liderança de engenharia se importa mais com redução de dívida técnica do que a lista de funcionalidades bruta sugere, vale a pena pedir ao Claude para ponderar a classificação com essa prioridade explicitamente nomeada, em vez de apresentar uma única classificação que implicitamente assume que todo mundo compartilha as mesmas prioridades.
A liderança de engenharia sinalizou dívida técnica como uma prioridade maior do que essa classificação atualmente reflete. Me mostre como a ordem mudaria se reduzir dívida técnica fosse ponderado tão pesadamente quanto o impacto no usuário, para que eu possa comparar as duas versões antes da reunião.
”
Dentro do Claude Tutorial
Tornar visível o raciocínio por trás de uma classificação é transferível.
Transformar uma decisão por instinto numa com raciocínio declarado e verificável se aplica muito além de roadmaps. O app tem uma aula completa sobre isso, com prática que vale para qualquer decisão de priorização que você precise defender.
Quando duas funcionalidades estão genuinamente próximas
Às vezes a resposta honesta é que duas funcionalidades estão próximas o suficiente para que qualquer ordem seja defensável. Vale a pena dizer isso diretamente em vez de apresentar uma confiança falsa numa posição específica. Um roadmap que apresenta toda classificação com a mesma certeza convida um stakeholder a pressionar forte numa decisão apertada como se fosse uma decisão já fechada, quando o movimento mais honesto e, no fim, mais persuasivo é nomeá-la como uma decisão apertada desde o início.
Dica
Peça ao Claude para sinalizar quais classificações são decisões apertadas e quais são claras. Um roadmap honesto sobre suas decisões apertadas é mais credível do que um que apresenta toda classificação com a mesma certeza.
Olhando essa lista classificada de 6 funcionalidades, quais pares estão próximos o suficiente para que a ordem pudesse razoavelmente se inverter? Seja específico sobre o que precisaria mudar para isso acontecer.
”Para um par genuinamente próximo, vale a pena perguntar se existe um critério de desempate além de esforço e impacto que resolveria isso com mais confiança, uma dependência, um prazo sazonal, um compromisso já firmado com um cliente, em vez de deixar o roadmap apoiado numa ordem decidida por sorteio.
Essas duas funcionalidades estão essencialmente empatadas em esforço e impacto. Existe um critério de desempate prático, uma dependência entre elas, um prazo externo, qualquer coisa além dos números, que tornaria uma claramente a melhor escolha para construir primeiro?
”Continue lendo
- Transformando tickets de suporte em temas priorizados: de onde costumam vir as estimativas de impacto das quais uma classificação de roadmap depende.
- Transformando uma funcionalidade lançada em notas de versão e uma atualização para stakeholders: o que acontece quando um item do roadmap de fato é lançado.
- Escrevendo um PRD a partir de um pedido de funcionalidade de uma linha: transformando um lugar no roadmap numa especificação depois de priorizado.