Roadmap não é lista de features: como comunicar direção sem prometer datas
"Então em março vocês entregam X?" é a pergunta que quebra roadmaps. O formato por horizontes de confiança que comunica direção honestamente, sem prometer o que ninguém controla.
Toda reunião de roadmap tem o mesmo momento de tensão: alguém aponta a planilha e pergunta "então em março vocês entregam X?". E ali, o roadmap que deveria comunicar direção vira uma promessa de datas, a primeira que vai quebrar e a última que alguém vai lembrar.
O roadmap que a maioria constrói (e por que ele trai)
O formato clássico, feature por mês numa linha do tempo, tem um defeito de origem: trata incerteza como certeza. Ele promete que a feature 3 do trimestre existirá exatamente como imaginada hoje, ignorando que o Discovery entre agora e março pode revelar que ela não resolve o problema, ou que resolve de outro jeito.
Quando a data escorrega (e ela sempre escorrega, é matemática de projeto, não incompetência), a confiança no roadmap inteiro desmorona, e a próxima versão já nasce sob suspeita.
A alternativa: roadmap por temas e resultados
O formato que sobrevive ao contato com a realidade organiza o roadmap em três horizontes, não em meses:
- Agora (alta confiança): o que está em Discovery avançado ou em desenvolvimento. Aqui cabe até uma janela de data, porque a incerteza já foi resolvida.
- Próximo (média confiança): temas validados, priorizados, ainda sem solução fechada. Comunica-se o problema que será atacado, não a feature específica.
- Depois (baixa confiança): direção estratégica, hipóteses grandes. Existe para alinhar expectativa, não para virar cobrança.
Cada linha do roadmap não é "Feature X em Março"; é "Reduzir o atrito de checkout", com o horizonte que indica quando o time vai atacar. A pergunta "o que exatamente vocês vão construir?" só tem resposta fechada no horizonte "Agora", porque só ali a resposta é honesta.
O vocabulário que muda a conversa
Substitua três palavras no seu próximo roadmap e observe a diferença de reação:
| Em vez de... | Use... |
|---|---|
| "Vamos lançar X em março" | "Vamos atacar o problema Y no próximo trimestre" |
| Lista de features | Lista de resultados esperados |
| Data de entrega | Horizonte de confiança |
Essa mudança não é cosmética: ela redistribui o risco de forma honesta. Prometer feature e data é prometer o que você não controla (o resultado do Discovery, a complexidade real, os bugs que só aparecem em produção). Prometer problema e horizonte é prometer o que você controla: prioridade e atenção.
Como apresentar isso para quem só quer a data
A objeção mais comum vem de vendas e de diretoria: "o cliente quer saber quando". A resposta madura tem duas partes:
- Para compromissos reais (contrato, integração crítica), o horizonte "Agora" já responde com data, porque só ali a confiança existe.
- Para o resto, ofereça o que é verdadeiro e ainda assim útil: o problema que está sendo resolvido, o motivo dele importar, e quando revisitaremos a prioridade. É menos satisfatório que uma data fictícia, e muito mais confiável no longo prazo, o mesmo trade-off da comunicação de risco em qualquer decisão de produto.
O erro que destrói a credibilidade do formato
Roadmap por horizontes só funciona se ele for revisitado com a mesma disciplina de um backlog. Times que o tratam como documento estático (escrito uma vez, ignorado depois) recriam o mesmo problema com roupa nova: o horizonte "Próximo" vira uma promessa implícita se ninguém o atualiza por dois trimestres seguidos. A régua: revisão de roadmap tão rotineira quanto priorização de backlog, não um evento anual.
Comunicação como parte do trabalho de produto
Desenhar esse roadmap (e o ritual que o mantém vivo) faz parte do que estruturamos junto com o time no nosso serviço de Discovery e Product Owner.
Seu roadmap atual tem mais datas do que problemas nomeados? Descreva-o para a IA da Rabelo Digital, aqui no canto da tela, e ela ajuda a reescrever por horizontes. Sem formulário, sem espera.
Deixe um Comentário