Por que roadmaps deveriam ser abolidos da gestão de produto
Assim como o desenvolvimento de produto em modo cascata, os roadmaps de feature deveriam ser encarados como algo que foi superado e que, hoje, fazem mais mal do que bem.
“O que vai ser entregue nos próximos 12 meses?” é uma pergunta comum da gestão para um time de produto e que geralmente significa “quais features/modificações esperamos lançar nos próximos 12 meses?” A pergunta pode ser comum e plenamente compreensível, pois é a forma que os gerentes/executivos acreditam ser a melhor forma de manter o time de produto accountable, como qualquer área de uma empresa precisa ser. E a resposta natural dessa pergunta é criar um roadmap listando várias funcionalidades que serão entregues. Alguns mostram essa lista de features por quarter, mas o mais comum hoje em dia é listar 3 horizontes: um de mais curto prazo, um de médio prazo e outro bem de possibilidades futuras:
Ainda que essa listagem de features que chamamos de roadmap seja a resposta mais comum para a pergunta dos executivos, investidores e mercado, ela não é uma boa resposta. O motivo é que a pergunta está fundamentalmente errada por se basear em algumas premissas falsas, como:
- É possível saber com grande antecedência que a funcionalidade/modificação X vai entregar o resultado desejado Y
(só é verdadeiro em ambientes de extrema certeza, como compliance regulatório e fiscal. Ex.: adaptar-se às normas de GDPR). - O time de produto gera valor para o negócio ao entregar funcionalidades/modificações para o cliente.
É impossível saber de antemão o que vai fazer sentido daqui a 12 meses
A única constante nos negócios é a mudança: novas tecnologias surgem, novos competidores, funcionários com diferentes habilidades pedem demissão/são contratados, o que era hype hoje amanhã está esquecido, as prioridades do negócio mudam, o que foi prometido ser entregue no primeiro trimestre atrasa para o segundo… em resumo, o mundo será diferente do que você pensa. Tentar prever todas as permutações possíveis é um exercício em futilidade (e uma tremenda perda de tempo). Por isso não faz sentido ter um “master plan” a ser executado — não se você deseja atingir o sucesso.
No livro Tao of Charlie Munger existe um capítulo sobre master plans que começa assim:
No Berkshire nunca houve um master plan. Nós demitíamos qualquer um que quisesse criar um, porque o master plan toma vida própria e não cobre nova realidade. Nós queremos que as pessoas levem em consideração novas informações.
Master plans — como roadmaps de features — em ambientes de alta incerteza são um erro, pois encorajam que as pessoas sigam o plano quando ele não é mais o melhor caminho (Tweet This). Em ambientes de alta incerteza, o melhor approach é o de adaptação à realidade atual. Inclusive isso já era conhecido no século 19, quando o pensador militar Carl Von Clausewitz escreveu que “nenhum plano sobrevive ao primeiro contato com o inimigo”.
Master plans cheios de detalhes já foram inclusive superados no mundo dos negócios, onde longos planos de negócio foram substituídos pelo business model canvas ou algo similar. Então por que a insistência em criar master plans em produto na forma de roadmaps de features?
O papel de um time de produto não é entregar features ou modificações
Quando o time de gestão quer saber o que vai ser entregue daqui a 12 meses, o pensamento é que se o time entregar X até a data Y, então com certeza obteremos o resultado de negócio Z. Mas isso não é verdade em ambientes de alta incerteza. É apenas uma possibilidade entre muitas outras.
Se para o negócio o seu time de produto precisa aumentar a retenção em 20%, talvez uma nova feature de notificações ajude a atingir essa meta, porém pode não funcionar — ou pode haver outras possibilidades melhores (que aumentam mais a retenção ou que aumentam tanto quanto notificações, mas são mais rápidas de fazer). “Travar” a mente para “vamos entregar notificações” leva somente a um resultado:
O time entrega a funcionalidade como der e lava as mãos quando ela não atinge o resultado, partindo para o próximo item no roadmap. Por isso um time de produto não deve ser cobrado por entregas, mas sim por resultados — assim como outras áreas do negócio (tweet this). O resultado final apresentado para o time executivo/board de um time de vendas é quantidade de vendas, não quantas ligações foram feitas. O resultado final apresentado pelo time de marketing é a quantidade de novos leads e oportunidades geradas para vendas, não quantas campanhas foram feitas.
O que acontece em qualquer área do negócio se as metas não estão sendo batidas? O plano é revisto, novas iniciativas/projetos surgem, campanhas de incentivo são criadas… esses times se adaptam à nova realidade, pois são centrados em resultados, não em entregas (outcome vs output). Por que para o time de produto focamos em o que está entregue e não nos resultados dessas entregas?
Se focarmos em um roadmap de entrega de features, o comportamento não será de se adaptar à nova realidade para atingir o objetivo, mas de entregar a feature. Isso leva a um produto cheio de features, mas que não entrega valor. (Tweet this)
A própria palavra “roadmap” não faz sentido quando listamos features
A palavra “roadmap” significa “roteiro” ou seja uma rota para um destino. Porém, da forma com que a maioria das empresas faz roadmaps, o destino (objetivos) é esquecido e a única coisa que fica em foco no roadmap são as “ruas” ou os caminhos (uma lista de features a entregar). Esse efeito colateral é natural, pois roadmaps de features são simplificados e perde-se o contexto de por que aquele item precisa ser feito agora e o outro item precisa ser feito depois disso.
Roadmap de features seria como o Waze mostrar uma rota que você não sabe onde vai dar — o que não seria só inútil, mas tornaria impossível do Waze recalcular a rota para um caminho ideal, já que o destino (objetivo) não está claro. Por não ter um destino claro, é bem comum nesse tipo de empresa alguns pedidos que furam o roadmap porque alguém importante acha que a feature XYZ é absolutamente essencial.
“Mas roadmaps de feature são úteis para comunicar com os executivos / board / clientes / mercado / etc”
Temos de convir que de fato listar as features são úteis para comunicar o que está sendo feito e o que será feito no produto. Porém na prática esse tipo de lista tem somente dois resultados possíveis, como disse David Cancel (CEO da Drift e ex-CPO da Hubspot): “ou eu vou desapontar você entregando exatamente o que pensamos há 6 meses que era a melhor solução quando ela não é, ou mudando o rumo e tendo mentido pra você”.
Se uma lista de features a serem feitos nos próximos 12 meses não faz sentido, o que podemos fazer para comunicar bem com outros stakeholders?
Representações diferentes para níveis de certeza diferentes
Se um dos problemas básicos do roadmap é a falsa sensação de certeza para algo que é basicamente incerto, devemos representar esses níveis de incerteza de alguma forma.
Não há nada de errado em listar uma feature que será lançada em breve quando o time já está trabalhando nela e já reduziu bastante seus riscos de valor, usabilidade, viabilidade e negócio. Isso pode (e até deve) ser comunicado para outros stakeholders. Se você quiser chamar isso de “roadmap de curtíssimo prazo”, tudo bem, mas isso é basicamente um “o que estamos construindo”, não um roadmap no sentido tradicional.
Agora, para comunicar o que é incerto (e praticamente tudo que não está sendo construído agora é incerto) existem alternativas interessantes. Um exemplo é o roadmap de temas, onde são listadas questões mais amplas, como dores do cliente ou seus jobs-to-be-done que pretendemos atacar. Mas nunca o que vamos fazer especificamente pra atacar essas dores ou jobs.
Então levando em conta esses dois níveis de certeza, poderíamos ter um roadmap onde as features com baixo risco e que estão sendo construídas são listadas, mas os objetivos/dores que queremos atacar é que são listados (e comunicados) além disso:
Outra alternativa à roadmaps é usar OKRs, que é essencialmente uma metodologia que olha para objetivos e como medir se esses objetivos foram alcançados. Falo bastante sobre isso no post OKRs versus Roadmap em times de produto.
O mais importante é que a alternativa não é a ferramenta XYZ (a famosa bala de prata). O problema não é com a ferramenta roadmap, o problema é com a premissa de que listar features/modificações no longo prazo é a melhor forma de extrair valor de um time de produto. Não é. Um time de produto deve ser um time com uma missão e objetivos claros — e ser cobrado por atingi-los. Isso é muito menos confortável tanto para a gestão quanto para o time, mas é o que vai trazer melhores resultados para as empresas e seus clientes.
Curtiu? Clica no ícone das palmas e acompanhe o que eu escrevo aqui.
Jabá: quer aprender a extrair insights de produto de entrevistas?
Eu tenho um curso online de como realizar entrevistas baseadas em jobs-to-be-done. Se você quer aprender mais a fundo como realizar essas entrevistas, se inscreva lá.
Aqui estão alguns dos reviews do curso Jobs-to-be-Done na prática:
