Roadmap de produto: o que ele promete e o que não é

Um roadmap de produto é a resposta para “o que vamos resolver nos próximos meses e por quê”. Ele não é a lista de entregas com data, embora quase sempre seja pedido assim. Essa diferença parece semântica e decide se o documento vai ajudar a empresa a decidir ou apenas a cobrar prazo.

Este texto mostra o que o roadmap promete de fato, os três formatos usados na prática e para quem cada um serve, como priorizar sem que a decisão vire disputa política, e o que fazer quando alguém de fora exige datas para o ano inteiro.

O que ele é, e o que ele não é

O roadmap é um instrumento de comunicação de intenção. Ele diz quais problemas o produto vai atacar, em que ordem e com qual objetivo, para que todo mundo na empresa possa se organizar em torno disso. É um documento de direção, e direção admite mudança quando a realidade informa algo novo.

O que ele não é: um cronograma de obra. Cronograma pressupõe escopo conhecido e execução previsível, o que descreve mal a construção de software, onde boa parte do aprendizado acontece durante a construção. Tratar o roadmap como cronograma produz um documento que ou é honesto e vira mentira em três meses, ou é conservador o bastante para ser inútil.

Há também o que ele não substitui: a decisão sobre o que construir. Essa vem antes, do trabalho de investigar o problema e o usuário, que é o product discovery, e é delimitada em como definir o escopo de um produto digital. O recorte da primeira versão está em o que é um MVP.

Os três formatos, e para quem servem

O formato por horizonte é o que mais funciona no dia a dia, porque admite o óbvio: o que está sendo feito agora é conhecido em detalhe, o que vem depois é conhecido em linhas gerais, e o que está no fim do ano é uma aposta. Ele comunica isso na própria estrutura, em vez de fingir precisão uniforme.

O formato por data não é errado, é caro. Ele só deve ser usado onde a data existe de verdade fora do produto, como uma obrigação regulatória ou um contrato assinado. Usá-lo por padrão transforma toda conversa de produto em negociação de prazo.

Como priorizar sem virar disputa

Sem critério explícito, a priorização é decidida por quem fala mais alto ou por quem é mais importante na hierarquia. Um critério simples, escrito e usado sempre resolve isso melhor que qualquer método elaborado. Quatro perguntas bastam para comparar duas ideias.

• Que problema isso resolve, e de quem? Se a resposta for “todo mundo”, ainda não foi definido.
• Qual o tamanho do efeito? Quantas pessoas, com que frequência, quanto vale.
• Qual o custo, em ordem de grandeza? Dias, semanas ou meses. Precisão maior é ilusão nessa etapa.
• O que aprendemos se estivermos errados? Iniciativa que não ensina nada quando falha é aposta pura.

A quarta pergunta é a que costuma faltar e a que mais protege o orçamento. Quando duas iniciativas empatam nas três primeiras, escolher a que gera aprendizado é quase sempre a decisão certa, porque o roadmap seguinte fica melhor informado.

Quando as quatro perguntas não bastam para desempatar, o que costuma resolver é o custo de atraso: quanto a empresa deixa de ganhar, ou passa a perder, por mês, enquanto aquilo não existe. É a única pergunta que trata tempo como dinheiro, e ela reordena a fila com frequência. Uma correção que faz dez clientes ameaçarem sair tem custo de atraso alto e esforço baixo; uma funcionalidade elegante que ninguém pediu tem custo de atraso zero, por mais atraente que pareça na reunião.

Na prática, três faixas bastam para cada eixo, e a nota some assim que a conversa acontece:

O número final importa pouco. O valor do exercício está em obrigar quem pede a responder as quatro perguntas em voz alta, na frente de quem pede outra coisa. A maior parte das disputas de roadmap se dissolve aí, porque fica visível que duas iniciativas não estavam competindo pelo mesmo objetivo. E o que sobrevive ao exercício chega à construção com o problema já descrito, que é metade do trabalho de definir escopo.

Vale reservar capacidade fixa para o que não aparece em nenhum critério: correção, manutenção e dívida técnica. Uma fatia declarada de cada ciclo, em vez de uma disputa a cada quinze dias.

De onde vêm os pedidos, e o que fazer com cada um

Priorizar bem não adianta se a fila de entrada é caótica. Os pedidos chegam de quatro lugares, e cada um exige um tratamento diferente porque carrega uma informação diferente.

• Do cliente grande. Carrega receita e carrega risco de virar software sob encomenda para um só. O filtro é perguntar se o problema descrito existe em mais três clientes. Se existir, é produto; se não, é projeto, e deve ser tratado e cobrado como tal.
• Da área comercial. Carrega o que faz perder negócio, que é informação valiosa e quase sempre mal formulada. Vale pedir a lista do que foi perdido no trimestre com o motivo declarado, em vez da funcionalidade que o vendedor imaginou.
• Do suporte. Carrega o custo invisível: o que gera chamado repetido drena time e reputação sem aparecer em nenhum indicador de produto. É a fonte com melhor relação entre esforço e efeito, e a mais ignorada.
• De dentro do time. Carrega dívida técnica e melhoria de base. Não compete em pé de igualdade com o resto porque o benefício é indireto, e por isso precisa da fatia reservada, não da disputa.

Nenhuma das quatro fontes decide sozinha, e nenhuma delas é dispensável. O que a priorização faz é traduzir os quatro idiomas para o mesmo: qual problema, de quem, com que efeito e a que custo. Quando um pedido não sobrevive a essa tradução, o mais honesto é dizer não com o motivo escrito, e não deixá-lo pendurado no fim da lista por dois anos. O trabalho de descobrir o que de fato está sendo pedido, antes de construir, é o de product discovery.

O que fazer quando exigem datas

A exigência de datas raramente é sobre datas. É sobre previsibilidade e coordenação: alguém precisa planejar uma campanha, contratar gente ou responder a um cliente. Reconhecer o que está sendo pedido de verdade abre uma saída melhor que dizer não.

Três respostas funcionam. Dar data onde ela existe, nos itens que já estão em construção e têm escopo definido. Dar faixa no horizonte seguinte, com a incerteza declarada em vez de escondida. E oferecer compromisso de resultado em vez de compromisso de entrega, quando o que a outra área precisa é que o problema esteja resolvido, não que uma tela específica exista.

Quando a data é inegociável e vem de fora, a variável de ajuste passa a ser o escopo. Essa é a conversa que precisa acontecer no início e não na semana anterior, e ela costuma ser mais fácil quando o custo das opções está claro, como em quanto custa desenvolver um aplicativo.

Quem participa da construção

Roadmap escrito por uma pessoa só costuma falhar por um de dois motivos: subestima o custo do que promete ou ignora o que o mercado está pedindo. A composição mínima envolve três perspectivas, e nenhuma delas precisa de reunião longa.

• Quem conhece o cliente. Comercial e atendimento sabem o que aparece toda semana na conversa e o que faz negócio ser perdido.
• Quem constrói. Só quem vai executar consegue dizer se algo custa dias ou meses, e é onde a ordem de grandeza deixa de ser palpite.
• Quem responde pelo negócio. Alguém precisa decidir entre duas coisas boas quando não cabem as duas, e essa decisão não é técnica.

Um formato que funciona bem é uma sessão trimestral de duas horas com as três perspectivas na sala, seguida de uma versão escrita circulada para comentário. Mais que isso vira processo; menos que isso vira lista de desejos de uma área só.

A rotina que mantém o roadmap vivo

Roadmap que não é revisto vira decoração em dois meses. A rotina mínima tem três momentos.

• A cada ciclo, confirmar o que está em construção e ajustar a fila imediata.
• A cada trimestre, revisar os temas: o que foi resolvido, o que mudou de tamanho, o que deixou de importar.
• Sempre que um dado novo aparecer, mudar sem cerimônia e explicar a mudança. Roadmap que nunca muda não está sendo informado por nada.

Vale manter, ao lado do roadmap, uma lista curta do que foi decidido não fazer e por quê. Ela responde antecipadamente metade das perguntas que chegam e impede que a mesma discussão volte a cada dois meses.

Os erros mais comuns

• Virar lista de funcionalidades. Sem o problema por trás, ninguém consegue avaliar se ainda faz sentido.
• Prometer precisão que não existe. Data para o quarto trimestre com a mesma firmeza da próxima semana destrói confiança quando falha.
• Ser feito só pela área de produto. Sem quem constrói, o custo é chutado; sem quem vende, a prioridade ignora o mercado.
• Ignorar manutenção. O que não entra no roadmap acontece do mesmo jeito, só que sem espaço reservado.
• Não comunicar mudança. Mudar é saudável; mudar em silêncio é o que faz a empresa parar de acreditar no documento.

Para o passo anterior, quando ainda não está claro qual produto merece roadmap, os critérios estão em quando a ferramenta interna tem potencial de produto e em produto digital e negócio digital. Para o momento seguinte, de validar o que foi priorizado antes de construir tudo, vale validação de MVP. E se a dúvida for como remunerar o que está sendo construído, modelos de monetização digital traz os caminhos.

Perguntas frequentes