Todos sabemos que roadmap de produtos não devem ser cronogramas com listas de fatures. Mas em muitas organizações, é isso que os executivos e os stakeholders querem, ou mesmo exigem. Portanto, se você não pode vencer a batalha na estrutura do roadmap, este post analisará como quebrar as regras no roadmap, sem quebrar os princípios (e mante-lo flexível)
O debate sobre o roadmap do produto
Se você quiser incitar um debate entre os gerentes de produto, basta dizer a palavra “roadmaps”.
À medida que nossa prática amadureceu, deixamos de aceitar que os roadmaps de produtos devem ser listas de solicitações de features com datas anexadas e desenvolvemos princípios que nos ajudam a alinhar conversas, focar nos resultados que estamos tentando alcançar e manter a flexibilidade de que precisamos para responder a novas informações e pesquisas.
Essas ideias são boas, mas muitas vezes nos prendemos ao dogma de como são apresentadas.
Embora formatos flexíveis por design como “Agora, Próximo, Depois” sejam ótimos, a dura realidade é que muitos gerentes de produto não trabalham em organizações preparadas para aceitar esse nível de imprecisão.
Ao tentar forçar um formato diferente, podemos acabar alienando nossos stakeholders e atrapalhando as conversas reais que um roadmap deve conduzir: como podemos fornecer melhor valor para nossos clientes?
Mas perder a batalha do formato não significa que você tenha que abandonar completamente os princípios. Você apenas tem que ser muito intencional sobre como você quebra as regras.
Segredo: datas em roadmaps não vão matar seu produto
A regra nº 1 de um roadmap para muitos líderes de produtos é “Sem datas em seu roadmap”. A razão para isso é que nossas datas são pura ficção. Os humanos são terríveis em estimar o tempo.
Sua caminhada de 10 minutos é provavelmente de 20 minutos, e toda receita que afirma que leva 30 minutos para cozinhar está mentindo. Então, quando lançamos um roadmap em janeiro que afirma saber o que acontecerá em outubro, nos preparamos totalmente para o fracasso.
Nossos stakeholders, por outro lado, adoram datas. Dá-lhes uma ilusão de certeza que eles podem usar para planejar. E é aí que reside o atrito: nossa insistência de que não podemos fornecer nem uma linha do tempo vaga de atividades torna a vida incrivelmente difícil para nossos colegas.
Ao nos apegarmos muito a esse conceito, nos tornamos o espinho nas pessoas com quem precisamos colaborar e, na pior das hipóteses, podemos ser anulados e forçados a fazer um roadmap baseado em datas.
Então, se você se encontra em uma posição em que discute mais sobre o fato de não estar dando nenhuma data do que sobre os itens reais no roadmap… talvez apenas coloque datas nele.
“Agora; Próximo; Depois” disfarçado
Depois de colocar datas em seu roadmap, o desafio se torna como você dá às pessoas o conforto das datas sem o compromisso implícito de entrega. Meu segredo é tratar meu roadmap baseado em datas como um roadmap “agora, próximo, depois” disfarçado.
Isso pode ser complicado, e você definitivamente precisa de apoio de liderança para fazer isso funcionar. Mas é possível:
Pense em um roadmap que mostre janeiro, fevereiro e março com uma boa quantidade de detalhes, depois mostre o segundo trimestre com um pouco menos de detalhes e, em seguida, o terceiro e quarto trimestres em alto nível.
PARABENS, você acabou de criar um roadmap flexível! E ao mostrar apenas detalhes completos nos próximos três meses, você garantiu que terá que revisitar o roadmap regularmente, à medida que adiciona mais detalhes aos trimestres posteriores.
Vamos dar um passo adiante: como você trabalha com um roadmap que é construído 12 meses por vez? É possível tratá-lo da mesma maneira, mas exige que você seja um comunicador excessivo.
Você precisa reforçar consistentemente e constantemente sua mensagem sobre seus níveis de confiança e como o roadmap deve ser usado. Quando eu tinha um roadmap de 12 meses, eu sempre falava para todo mundo que me perguntava:
- Se for exibido nos próximos três meses, está em trabalho e sabemos muito a essa altura. É bem provável que aconteça dentro de algumas semanas do que esperamos, e comunicaremos se algo mudar.
- Se for de três a seis meses, pretendemos trabalhar nisso e provavelmente acontecerá, mas o momento é realmente incerto. À medida que aprendemos novas informações, mudamos as prioridades ou se outras coisas demoram mais do que esperamos, há uma boa chance de que o tempo mude.Você pode falar sobre isso como algo que estamos analisando, mas não tente garantir o tempo.
- Se estiver no roadmap por seis meses ou mais… é um experimento mental. Não diga a um cliente que está no roadmap para este ano, nem pense em tentar dar um prazo. É pura ficção neste momento ver como seria nosso roadmap se nada mudar e nos dar direção à medida que moldamos nossas futuras pesquisas e experimentações.
Agora = <3 meses. Próximo = 3-6 meses. Depois = 6+ meses.
Mostre aos stakeholders que o roadmap não é estático
Você não pode criar um roadmap baseado em datas uma vez por ano, dizer às pessoas que não é um compromisso e não tocá-lo por mais um ano. Para fazê-lo funcionar, você precisa revisitar ativamente e recomunicar regularmente seu roadmap.
Você também precisa mostrar que há mudanças regulares; principalmente porque haverá mudanças (sejamos honestos), mas também para reforçar que este é um documento vivo e as pessoas não devem se apegar muito a ele.
Eu geralmente revisitaria um roadmap baseado em data todo mês para ver se as coisas ainda parecem válidas e se algum item no intervalo “agora” mudou.
Então, a cada trimestre, faço uma reorganização maior:
- Empurro as coisas no intervalo “próximo” para a frente, adio os itens que não estão realmente se movendo para “agora” e retiro algumas coisas do último ou reorganizo as coisas.
Mais importante, eu me certifico de que todos estejam cientes das mudanças. Quando seus stakeholders eventualmente entenderão como o roadmap é usado quando virem movimento suficiente.
O apoio da liderança é necessário
Especialmente se você está apenas começando a tentar transformar seu roadmap baseado em datas em um roadmap flexível, você precisa garantir que seus líderes estejam alinhados desde o início.
Mesmo que você faça tudo certo – você explica constantemente como seu roadmap deve ser usado, faz mudanças regulares e comunica essas mudanças – posso garantir que alguém voltará no primeiro ano e tentará dizer “mas estava no roadmap para outubro e esse cliente não vai assinar se não conseguirmos entregar então”.
Se sua liderança não estiver a bordo e o dominar (ou se você for o líder e ignorar a equipe), isso se tornará o novo manual de como construir algo. Mas se, na primeira vez que isso acontece, a resposta de quem quer que seja é: “Bem, isso parece uma conversa muito difícil com esse cliente.
Devemos começar a falar sobre como podemos agregar valor a eles com o que temos hoje e pintar uma visão para onde estamos indo”, essas conversas no estilo brecha acabarão por desaparecer.
Conclusão: Quebrar bem as regras requer habilidade
É fácil quebrar as regras comuns do roadmap, especialmente quando isso deixa seus executivos felizes.
É muito difícil fazê-lo bem e não deixar que isso o leve ao caminho de se tornar uma fábrica de features. Mas se você realmente entender os problemas que está tentando resolver em um roadmap flexível, poderá encontrar maneiras de atingir seus objetivos sem aderir ao formato “perfeito”.
Contanto que você permaneça fiel aos princípios subjacentes, seu roadmap ainda será uma boa ferramenta de alinhamento… mesmo que tenha datas.