Peça a qualquer empresa o roadmap do produto e, na maioria das vezes, chega uma planilha com colunas de meses e caixinhas de funcionalidades: login social em março, painel em abril, integração com o ERP em junho. Parece organizado. É fácil de apresentar para a diretoria. E costuma estar errado já na segunda semana.
O problema não é a planilha, é o que ela promete. Um roadmap de funcionalidades com data assume que a equipe já sabe o que o usuário precisa, como resolver e quanto tempo vai levar. Num produto novo, as três coisas ainda são hipóteses. Este texto mostra por que vale trocar a lista de entregas por uma lista de problemas, como montar esse roadmap na prática e como ele fica no caso mais delicado de todos: o do MVP.
O que é roadmap de produto?
Roadmap de produto é o plano que mostra como um produto deve evoluir ao longo do tempo. Ele responde três perguntas para quem não está no dia a dia da equipe: aonde o produto quer chegar, em que ordem os problemas serão atacados e como se vai saber que cada etapa deu resultado.
Duas qualidades separam um roadmap útil de um enfeite de apresentação. A primeira é que ele explica também o que não será feito agora, e isso protege a equipe de pedidos que chegam por fora. A segunda é que ele é fácil de mudar. Um roadmap que ninguém atualiza deixa de ser plano e vira registro histórico do que se imaginava meses atrás.
Ele vale para qualquer produto digital: um aplicativo, uma plataforma SaaS, um sistema interno, um portal de clientes. Muda o público que vai lê-lo, mas a estrutura é a mesma.
Qual a diferença entre roadmap, backlog e cronograma?
Os três aparecem juntos em quase todo projeto e são confundidos com frequência. A confusão mais cara é tratar o roadmap como um backlog com datas, porque aí ele herda o nível de detalhe do backlog e a rigidez do cronograma ao mesmo tempo.
| Roadmap | Backlog | Cronograma | |
|---|---|---|---|
| Pergunta que responde | Para onde vamos e por quê? | O que a equipe faz a seguir? | Quando cada tarefa termina? |
| Unidade | Problema ou objetivo com métrica | Item de trabalho (história, tarefa, correção) | Atividade com início e fim |
| Horizonte | Meses, em blocos | Próximas semanas | Do início ao fim do projeto |
| Quem lê | Diretoria, investidor, áreas parceiras, equipe | Equipe de desenvolvimento | Gestão do projeto e fornecedores |
| Quando funciona bem | Quando o caminho ainda está sendo descoberto | Sempre, como fila de execução | Quando o escopo é conhecido e estável |
| Como dá errado | Vira lista de funcionalidades com data | Vira depósito de ideias sem ordem | Vira promessa num terreno incerto |
Cronograma não é ruim. Ele é a ferramenta certa quando o escopo é conhecido, como numa migração de sistema ou numa obra com projeto fechado. O erro é usá-lo para planejar um produto cujo valor ainda precisa ser provado. Aí a data passa a ser a meta, e entregar no prazo vira sinônimo de sucesso, mesmo quando ninguém usa o que foi entregue.
Por que o roadmap de funcionalidades com data falha?
Porque ele compromete a equipe com soluções antes de saber se elas resolvem alguma coisa. E há um dado que mostra o tamanho do risco, desde que lido com o ano e o recorte certos.
O recorte importa. O número descreve o software médio da base analisada pela Pendo, ou seja, empresas que já pagam para medir o uso do próprio produto. Não é um censo do mercado, e o relatório é de 2019. Ainda assim, a direção é difícil de ignorar: a maior parte do que se constrói não é usada.
Agora leve isso para o roadmap. Se ele é uma sequência de funcionalidades com data, ele é, em boa parte, um cronograma do que ninguém vai usar. Pior: como cada caixinha tem data, a equipe é cobrada por entregá-la, não por descobrir que ela não era necessária. O roadmap premia a entrega e pune o aprendizado.
Há ainda um efeito político. Funcionalidade com data vira promessa para cliente, para vendedor e para investidor. Tirar uma caixinha do roadmap passa a custar uma conversa difícil, e a funcionalidade é construída por compromisso, não por evidência. O resultado aparece meses depois, em forma de produto inchado e manutenção cara.
O que a orientação do governo britânico ensina sobre roadmap?
Uma das referências públicas mais claras sobre o assunto não vem de uma consultoria nem de uma ferramenta de gestão, e sim do Government Digital Service, a área de serviços digitais do governo do Reino Unido. O Service Manual do GOV.UK tem uma página só sobre como desenvolver um roadmap, com doze princípios.
Quatro desses princípios, traduzidos para o dia a dia de uma empresa, resolvem a maior parte dos problemas de roadmap:
- Intenção, não solução. O roadmap diz o que se quer alcançar para o usuário. Como alcançar é decisão que se toma perto da hora, com o que se aprendeu até lá.
- Objetivo claro em cada etapa. O manual pede que cada iteração tenha uma meta, muitas vezes um problema a resolver, e uma explicação de como o progresso será medido.
- Incerteza crescente. Quanto mais longe no tempo, menos se sabe. Itens podem entrar e sair do roadmap, e isso é o roadmap funcionando, não falhando.
- Revisão regular. No GDS, a revisão acontece ao menos a cada trimestre, e o trabalho usa o que vem de pesquisa com usuários e da análise de desempenho.
O texto é de 2017 e foi escrito para serviços públicos, mas nada nele depende disso. Ele também recomenda que o roadmap explique para quem é, como deve ser lido, quem o mantém e com que frequência é atualizado. São quatro linhas no topo do documento que evitam meses de mal-entendido.
Como é um roadmap orientado a problemas?
Cada item deixa de ser “o que vamos construir” e passa a ser “o que queremos mudar para o usuário ou para o negócio, e como vamos saber que mudou”. A solução continua existindo, mas como hipótese, não como compromisso.
Na prática, cada item do roadmap ganha quatro campos. Não precisa de ferramenta especial: uma planilha resolve.
| Campo | Roadmap de funcionalidades | Roadmap de problemas |
|---|---|---|
| Título do item | “Agendamento online” | “Pacientes desistem de marcar por telefone” |
| Por que está aqui | Um cliente pediu | Evidência de pesquisa, suporte ou dados de uso |
| Como saber se deu certo | Entregue na data | Métrica que deve mudar e em que direção |
| Solução | Definida e prometida | Hipótese atual, que pode ser trocada |
| Prazo | Data fechada | Horizonte: agora, próximo ou depois |
O ganho mais visível é na conversa com quem pede funcionalidades. Em vez de discutir se “a integração entra em junho”, a pergunta passa a ser “que problema a integração resolve e ele está à frente dos outros?”. Às vezes está, e a integração sobe. Muitas vezes o problema real é outro, e se resolve com algo mais simples.
Como montar um roadmap de produto na prática?
O roteiro abaixo serve para um produto que já existe e também para um que ainda vai nascer. A diferença do MVP está na seção seguinte.
1. Escreva a visão em uma frase
Para quem é o produto e que mudança ele promete na vida dessa pessoa ou empresa. Se a frase precisar de vírgulas demais, a visão ainda não está clara, e nenhum roadmap vai consertar isso.
2. Liste os problemas com evidência
Reúna o que se sabe: entrevistas, chamados de suporte, motivos de cancelamento, dados de uso, objeções que o comercial ouve. Escreva cada problema do ponto de vista de quem o sente. Pedido de funcionalidade entra também, mas traduzido para o problema que está por trás dele.
3. Dê a cada problema uma métrica
Que número deve mudar se o problema for resolvido: taxa de conclusão de um fluxo, tempo até a primeira entrega de valor, cancelamentos, chamados sobre o mesmo tema. Se não existe forma de medir, isso já é o primeiro item do roadmap: instrumentar o produto.
4. Ordene por critério declarado
Qualquer método serve, desde que seja o mesmo para todos os itens e esteja escrito: impacto esperado contra esforço, risco que o item reduz, dependência técnica. O que não serve é ordenar pela voz mais alta da reunião. O GOV.UK pede que a forma de priorizar seja consistente e transparente, e é exatamente isso.
5. Distribua em três horizontes
Agora, próximo e depois. O “agora” pode ter solução esboçada e escopo definido. O “próximo” tem o problema e a métrica, com a solução em aberto. O “depois” tem só temas. Se quiser marcar tempo, use blocos (trimestres, por exemplo), nunca dias.
6. Combine a revisão e publique
Defina quem mantém o roadmap, de quanto em quanto tempo ele é revisto e onde está a versão oficial. Deixe essas informações no topo do documento. Um roadmap que existe em três versões diferentes, uma em cada apresentação, é um roadmap que ninguém segue.
Como fica o roadmap do MVP?
É aqui que o roadmap de funcionalidades faz mais estrago, e onde quase nenhum material sobre o tema chega. O roadmap de um MVP costuma ser desenhado como uma lista de telas divididas em fases: fase 1 com cadastro e agendamento, fase 2 com pagamento, fase 3 com relatórios. Parece prudente, mas pressupõe que a fase 1 vai dar certo e que a fase 2 é a consequência natural.
Um MVP existe para testar uma hipótese. Então o primeiro horizonte do roadmap não deveria ser uma lista do que construir, e sim o critério que decide se a ideia segue, muda ou para. Tudo o que vem depois depende do resultado desse teste e, por isso, fica como problema e tema, não como funcionalidade.
Veja um exemplo ilustrativo: uma plataforma de agendamento para clínicas pequenas.
- Agora: validar a hipótese principal. Pacientes marcariam consulta sozinhos, por link, se a clínica oferecesse. Métrica: proporção de agendamentos feitos pelo link nas clínicas piloto. Critério combinado antes de começar: o patamar que faz a ideia seguir, o que pede ajuste e o que encerra. Escopo: só o necessário para medir isso.
- Próximo, se a hipótese passar: reduzir faltas. Problema: horários marcados e não comparecidos. Métrica: taxa de faltas. Solução ainda em aberto: lembrete, confirmação, lista de espera.
- Próximo, se a hipótese passar: a clínica pagar sem atrito. Problema: cobrança manual da assinatura. Métrica: inadimplência e tempo de ativação.
- Depois: temas. Relatórios para o dono da clínica, integração com sistemas de prontuário, outras especialidades. Sem escopo, sem data.
Repare no que mudou. Se o teste do “agora” falhar, o roadmap não fica errado; ele já previa essa possibilidade e aponta o caminho, que é revisar a hipótese antes de construir mais. No modelo por fases, a falha da fase 1 deixa a equipe com um plano inteiro de funcionalidades que não fazem mais sentido, e a tentação de construí-las mesmo assim.
O critério de validação não nasce no roadmap. Ele vem do trabalho anterior: do discovery de produto, que define o que entra e o que fica fora da primeira versão, e da conversa sobre o critério de parada do produto mínimo viável. O roadmap é onde esse critério fica visível para todos, com a ordem do que vem depois.
Quem decide a prioridade do roadmap?
É a pergunta que os guias costumam pular, e a que mais trava projeto na prática. A resposta curta: muita gente contribui, uma pessoa decide.
O Service Manual do GOV.UK descreve a criação do roadmap como trabalho colaborativo, em geral conduzido pelo gerente de produto, com a equipe de desenvolvimento e as partes interessadas envolvidas. Contribuir não é o mesmo que decidir. Diretoria, comercial, suporte e clientes trazem problemas e evidências; quem ordena precisa ser alguém com mandato para dizer não.
Em empresas sem gerente de produto, essa pessoa costuma ser o fundador ou o diretor que patrocina o projeto. Funciona, desde que duas condições estejam claras: o critério de priorização é público, e quem pede um item fora da ordem sabe o que sai para ele entrar. Sem isso, o roadmap vira uma soma de pedidos, e a soma de pedidos é justamente o caminho para os 80% de funcionalidades pouco usadas.
Quando o desenvolvimento é feito por uma empresa contratada, há um cuidado extra. O fornecedor pode e deve propor ordem e apontar dependências técnicas, mas a decisão de prioridade é de quem responde pelo resultado do negócio. Fornecedor que decide sozinho a prioridade tende a ordenar pelo que é mais fácil de entregar.
Como fica o roadmap de produto no Scrum?
O Scrum não define roadmap. O Guia do Scrum de 2020, de Ken Schwaber e Jeff Sutherland, não usa a palavra. O que ele define é a Meta do Produto, o objetivo de longo prazo do time, e o Backlog do Produto, a lista ordenada do que é necessário para chegar lá.
O guia é explícito sobre quem ordena: o Product Owner responde pela gestão do Backlog do Produto, o que inclui desenvolver e comunicar a Meta do Produto e ordenar os itens. Ele é uma pessoa, não um comitê, e o texto diz que a organização inteira precisa respeitar suas decisões. Quem quiser mudar o backlog tem de convencer o Product Owner. A íntegra está no Guia do Scrum.
Na prática, o roadmap ocupa o espaço entre a Meta do Produto e o backlog. A meta diz aonde ir; o roadmap mostra os problemas que serão atacados no caminho, em que ordem e como se mede cada um; o backlog detalha o trabalho do “agora”. A cada revisão de sprint, o que se aprendeu volta para o roadmap. Se o roadmap nunca muda depois das revisões, ou a equipe não está aprendendo nada, ou o aprendizado não está chegando a quem decide.
Quais os erros mais comuns no roadmap de produto?
- Prometer data para o que está longe. O item do “depois” com dia marcado cria uma expectativa que a equipe ainda não tem como sustentar.
- Detalhar demais o futuro. Escopo fechado para algo que vai acontecer daqui a meses é trabalho jogado fora: até lá, o que se sabe terá mudado.
- Usar o backlog como roadmap. Centenas de itens não comunicam direção para ninguém fora da equipe.
- Não ter métrica. Sem número que deveria mudar, não há como saber se o item resolveu algo, e o roadmap só registra o que foi entregue.
- Ter vários roadmaps. Uma versão para a diretoria, outra para clientes, outra para a equipe, cada uma desatualizada de um jeito.
- Nunca revisar. O roadmap montado no início do ano e reaberto só no fim dele é um documento de arquivo, não de gestão.
- Priorizar por quem pede mais alto. Sem critério escrito, a ordem reflete a hierarquia, não o valor.
Quase todos esses erros têm a mesma raiz: tratar o roadmap como compromisso de entrega em vez de declaração de intenção. Corrigida a raiz, a maioria dos sintomas some sozinha.
Roadmap bom não diz o que vai ser construído em junho. Diz qual problema vale mais resolver agora e como se vai saber que ele foi resolvido.
Por onde começar hoje
Não é preciso jogar fora o roadmap atual. Pegue a planilha que existe e, item por item, escreva ao lado o problema que ele resolve e a métrica que deveria mudar. Os itens em que essas duas colunas ficarem vazias são os candidatos a sair, ou a voltar para pesquisa antes de qualquer código.
Depois, troque as datas dos itens distantes por horizontes e marque a primeira revisão na agenda. Se o produto ainda não existe, comece pelo critério de validação do MVP e deixe o resto como problemas e temas.
A Alliance planeja e desenvolve produtos digitais a partir dessa lógica, do critério de validação ao primeiro lançamento, no serviço de desenvolvimento de MVP. E, se a dúvida for anterior ao produto, sobre posicionamento, canais e onde está o gargalo do negócio, o diagnóstico de marketing gratuito da Alliance é um bom ponto de partida.