Roadmap de produto: não tenha medo, ele é seu aliado! 

Nos últimos meses tenho visto e ajudado outros POs sobre o que é o Roadmap de produto. Com isso, percebi alguns problemas em comum e decidi escrever um pouco sobre eles para tentar ajudar nossos leitores. 

Roadmap: o que é?  

Ao construir um software é comum termos muitas pessoas de diferentes áreas envolvidas, direta ou indiretamente. Por isso, um dos papeis fundamentais de um PM é alinhar as expectativas de todas as pessoas de tribos e interesses distintos. Essa tarefa não é fácil e precisa de um cuidado especial. O roadmap deve representar a estratégia do seu produto, deixando claro como pretende-se chegar ao objetivo, endereçando interesses de negócio e usuários. 

Uma das ferramentas que gosto de usar para isso é um roadmap de produtos claro e transparente: Ele é uma ótima ferramenta para comunicar para o time e para outras pessoas interessadas quais são os planos do time de produto e para onde ele está apontando atualmente. A palavra “atualmente” é muito importante aqui, pois um roadmap deve mostrar a realidade atual e se esta realidade mudar, (bem comum em produtos digitais complexos à medida que realizamos os processos de Discovery e aprendemos mais) precisamos alterar a rota, atualizando o roadmap seus marcos e suas prioridades.

Modelos de Roadmap de produto

Existem diversos modelos de roadmap, um formato mais leve pode ser o modelo de 3 colunas nomeadas de now-next-later conhecido como Lean Outcome Roadmap. Neste formato, podemos dar uma visão de prioridade para as pessoas. E mostrar a elas quais são as dores que iremos atuar imediatamente e quais virão em seguida.

Entendo que muitos interessados em seu roadmap precisam de uma noção de datas. Então se no seu contexto você não conseguir deixar sem datas fixas, cada uma destas colunas pode representar 3 meses (um quarter). Assim temos um meio termo entre datas muito fixas e nenhuma data. 

Aqui estão outras dicas importantes: 

• Procurem evitar entregáveis no roadmap:

Use resultados esperados (outcomes) para representar as entregas, assim caso o entregável se altere, mas o resultado do entregável não, o roadmap ainda vai representar a realidade, sendo mais robusto. Sendo assim, ao invés de colocar: “Integração com SAP” Você pode tentar descrever o que o negócio espera com essa integração, algo como “Reduzir tempo de registro de ordens de serviço no SAP”. Parece sutil, mas isso traz uma pitada a mais em resolver o problema e não somente de “integrar dois sistemas”. 

• Nunca atribuam metas das pessoas aos entregáveis do roadmap:

  Em muitos casos os itens que prevemos no roadmap além de 3-4 meses são hipóteses, coisas que podem mudar à medida que o tempo passe. Se “amarrarmos” estes entregáveis em metas (principalmente de remuneração variável das pessoas) iremos incentivar uma cultura de “entrega cega”. Isto é,  não nos preocupar em resolver de fato os problemas que descobrirmos, mas sim em entregar aquele relatório x solicitado. Que inclusive pode não fazer mais sentido em alguns meses. 

• Use o roadmap de produtos a seu favor!

  É comum outras unidades de negócio cobrarem status das entregas e quererem saber quando aquela funcionalidade que eles tanto esperam estará pronta. Acontece que, ficar respondendo essas perguntas e explicando sua estratégia, toda reunião de sincronismo pode ser ineficiente. Devemos usar roadmap para sincronizar e dar visão a estes times. Outros times extremamente importantes que precisamos comunicar são o de engenharia habilitadora, como arquitetos, pessoal do marketing e comunicação e PMs de outros times que possuem dependência dos seus produtos. Sobre os arquitetos, comunicar previamente quando determinadas dores serão tratadas pode ajudar a evitar o conhecido over engineering que é quando constroem excessos de arquitetura de software que tem um potencial de não ser necessária naquele momento. 

 Roadmap de produto pode estar a seu favor! 

Um roadmap pode ser concebido após as definições de proposta de valor e definição das hipóteses de solução do seu produto, assim o time pode tirar proveito de uma maneira visual e distribuída para atacar as dores. Designers e PMs podem se orientar e planejar os discoverys com mais foco, sabendo que existem dores que serão tratadas apenas no futuro. Com isso, reduzimos a ansiedade e nos permitimos a pensar de forma mais sistêmica. Gosto de usar a frase “este é um problema para o nosso time do futuro”. 

Na medida que novas dores e soluções forem descobertas, atualize o seu roadmap e garanta que todos interessados tenham acesso a estas atualizações sempre que precisarem. Lembre-se: Seu roadmap deve prover alinhamento, foco e previsibilidade para os times e se estiver desatualizado ou sem um nível de profundidade para um bom entendimento poderá atrapalhá-lo.

Tome cuidado com datas fortes. Como foi dito, datas fortes imprimem compromisso com “datas” e não em resolver o problema. Uma Sprint atrasar 2 semanas porque encontramos uma maneira muito melhor de realmente resolver o problema faz mais sentido do que um problema mal resolvido com o “entregável” em produção bem na data prometida. Não estou negando a importância do compromisso e entregas constantes. Apenas estou defendendo a entrega de um produto bom com uma flexibilidade de prazo ao invés de entregar o produto ruim no prazo correto. 

Em Roadmap de produto, todo cuidado é pouco 

Mas atenção: se em seu contexto seu roadmap não tem uma flexibilidade de data, descrição dos outcomes e se os times interessados estão mais preocupados com o compromisso fixo em datas sem se preocupar tanto com os problemas certos endereçados, eu diria para não usar um roadmap. Caso contrário, você vai acabar com um gráfico gantt no estilo gestão de projetos com datas e sequência de atividades, escopo fixo com um desenvolvimento em cascata sem a abertura para aprendizado, redução de riscos e alteração da rota.  

Para conhecer o modelo citado, procurem por “Lean Outcome Roadmap” que vocês vão encontrar exemplos visuais. Mas, o mais importante é entender o conceito por trás, usando o roadmap como uma ferramenta de comunicação e sincronismo dos times, garantindo que todos saibam como vocês estão planejando alcançar o objetivo e a visão do produto.  

Recentemente, participei de um episódio do podcast Os Agilistas, em que falei um pouco sobre entregar o produto certo, comentando sobre métricas e principalmente sobre as armadilhas de um roadmap, caso queira ouvir acesse clicando aqui. 

Além do episódio sobre roadmaps, Os Agilistas traz insights gerais sobre a metodologia ágil em diferentes áreas organizacionais. Dê o play em sua plataforma de áudio favorita! Você também tem interesse em fazer parte de um time que fomenta o crescimento constante e dá espaço para trabalhar com roadmap? Se inscreva em nossa página de carreiras e escolha a vaga que mais combina com você. Venha ser dti!