Como criar um roadmap de produto que sobrevive ao trimestre

Quase todo roadmap é escrito com mais certeza do que o produto realmente tem. No dia da apresentação, tudo parece organizado: Q2, Q3, Q4, cada linha com uma funcionalidade, um prazo e uma posição aparentemente precisa no futuro. Dois meses depois, uma investigação muda o escopo, um cliente importante expõe outro problema, engenharia descobre uma dependência, uma regra externa muda. E o documento deixa de descrever o que o time está fazendo.

Ninguém anuncia que o roadmap morreu. Ele só para de ser aberto. O problema nem sempre é falta de disciplina. Muitas vezes é o formato. O roadmap prometeu um nível de certeza que não existia quando foi escrito.

O problema começa quando distância não muda o nível de precisão

Compare duas coisas:

Nova gestão de permissões, em desenvolvimento agora.

e:

Motor de automações, outubro.

Na primeira, o time talvez já tenha problema validado, escopo, fluxo, restrições técnicas, responsáveis, primeiras estimativas e dependências conhecidas. Na segunda, talvez exista apenas uma frase numa apresentação. Mesmo assim, um roadmap em linha do tempo pode representar os dois com a mesma aparência: uma barra, um nome, uma data. Visualmente, parecem igualmente comprometidos. Não são.

Quanto mais distante está uma iniciativa, mais coisas ainda podem ser descobertas sobre ela. O roadmap deveria comunicar essa diferença em vez de escondê-la.

Data não é o problema. Data sem confiança é.

Existe uma reação comum a roadmaps ruins:

então nunca coloque data.

Eu evitaria transformar isso em regra universal. Existem situações em que data importa de verdade: uma mudança regulatória entra em vigor, existe contrato, marketing organizou um lançamento, uma migração precisa terminar antes do desligamento de uma infraestrutura, outro time depende da entrega. Nesses casos, prazo não é decoração. É restrição.

O problema é colocar uma data específica numa iniciativa que ainda não foi investigada apenas porque o formato exige uma. Um bom roadmap precisa diferenciar compromisso, previsão e intenção. Quando os três parecem iguais, o conflito começa.

Now, Next, Later transforma tempo em confiança

Em 2012, Janna Bastow e Simon Cast desenvolveram no ProdPad o formato que ficou conhecido como Now, Next, Later. A lógica é simples: quanto mais distante uma iniciativa está, menor tende a ser a confiança sobre sua forma final. Por isso as colunas funcionam melhor como horizontes de confiança do que como calendário disfarçado.

Now

É o que está em andamento ou suficientemente compreendido para receber atenção imediata. O problema está bem entendido, existe trabalho concreto acontecendo, o nível de confiança é alto em relação às outras colunas. Isso não significa que nada possa mudar. Significa que o time já atravessou parte relevante da incerteza.

Next

São oportunidades ou problemas que ganharam prioridade e estão mais próximos. Existe intenção real de trabalhar neles, mas ainda pode haver perguntas importantes sobre solução, escopo, esforço ou sequência.

Later

São problemas, oportunidades ou apostas estratégicas que fazem sentido manter no radar, mas ainda possuem incerteza maior. Aqui, especificar solução detalhada cedo demais pode fazer mais mal que bem. Later deveria dizer:

acreditamos que vale investigar isso.

Não:

garantimos esta funcionalidade para novembro.

O maior ganho não são as três colunas

É a conversa que elas forçam. Num roadmap por trimestre, a pergunta dominante tende a ser:

quando isso sai?

Num roadmap orientado por confiança, aparecem outras: por que isso está no Next? O que falta aprender para ir para Now? Que evidência mantém isso no Later? O que mudou para esta iniciativa perder prioridade? Estamos comprometidos com o problema ou já estamos comprometidos com esta solução específica?

Essas perguntas ajudam mais a gerir produto do que movimentar barras de um Gantt depois que o plano mudou.

Não transforme Now, Next, Later em backlog com três cores

É bastante fácil pegar um roadmap ruim e apenas trocar as colunas. Antes: Q2, Q3, Q4. Depois: Now, Next, Later. E continuar colocando “Exportação CSV”, “Dashboard novo”, “Dark mode”, “Integração X”, “Novo onboarding”. Agora você tem a mesma lista de funcionalidades sem as datas. A estrutura mudou. A lógica não.

A diferença aparece quando o roadmap começa a guardar problemas, oportunidades ou resultados desejados, especialmente nos horizontes mais incertos. Compare:

Exportação em CSV.

com:

Equipes financeiras precisam levar os dados para outro sistema toda semana porque não conseguem concluir o fechamento dentro do produto.

A primeira já escolheu uma implementação. A segunda mantém aberta a pergunta sobre qual solução vale construir. Talvez seja CSV, talvez integração, talvez API — talvez o próprio produto consiga eliminar o trabalho externo. Quanto menos você sabe, mais perigoso é comprometer o roadmap com a solução.

Solução pode ficar mais específica conforme a confiança aumenta

Isso não significa proibir features no roadmap. No Now, talvez a solução já tenha sido definida. Faz sentido mostrar:

Problema: administradores não conseguem controlar permissões por operação.

Solução em desenvolvimento: papéis customizáveis com permissões granulares.

O time investigou, tomou uma decisão e agora está executando. No Later, talvez seja apenas:

Empresas maiores não conseguem representar sua estrutura de acesso no modelo atual de permissões.

A diferença de detalhe comunica uma diferença real de conhecimento. Isso é muito mais honesto que fazer o Later parecer especificado só para deixar o documento mais completo.

Cada iniciativa deveria explicar por que merece espaço

Eu gosto de roadmaps em que cada item consegue responder algumas perguntas básicas.

Qual problema ou oportunidade estamos tratando? Não precisa virar um documento de discovery inteiro. Uma ou duas frases.

Para quem isso importa? “Clientes” normalmente é amplo demais. Talvez sejam contas enterprise com múltiplas unidades, novos usuários tentando ativar, ou operadores que conciliam centenas de transações.

Que resultado esperamos mudar? Não apenas “entregar nova tela”, mas reduzir tempo de configuração, aumentar ativação, diminuir trabalho manual, reduzir falha de pagamento.

Que evidência sustenta esta prioridade? Pode ser dados, pesquisa, receita, risco, estratégia, regulação ou volume de suporte.

O que ainda precisamos aprender? Essa pergunta é especialmente importante em Next e Later.

Um item de Next deveria ter uma pergunta aberta

Imagine:

Problema: escritórios que administram várias empresas precisam fazer logout e login para alternar entre contas.

Público: organizações com múltiplas contas administradas pela mesma pessoa.

Resultado esperado: reduzir esforço para alternar contexto e diminuir chamados relacionados a acesso.

Pergunta em aberto: os usuários realmente precisam alternar rapidamente entre contas ou precisam visualizar informações de várias contas ao mesmo tempo?

Essa última linha muda tudo. Se a resposta for a segunda opção, construir um simples seletor de conta pode resolver o problema errado com muita eficiência. Enquanto essa pergunta continua aberta, o item ainda não está pronto para receber o mesmo grau de especificidade de algo em execução.

Roadmap e backlog não fazem o mesmo trabalho

Outra confusão comum é usar o roadmap como backlog executivo. O backlog pode ter bugs, melhorias pequenas, dívida técnica, tarefas, experimentos, ajustes, histórias e itens operacionais. Pode ter centenas de coisas. O roadmap tem outro trabalho. Ele deveria permitir que alguém entenda: em quais problemas estamos investindo, qual é a ordem relativa, qual é o grau de confiança e como isso se conecta à estratégia.

Um stakeholder não deveria precisar ler 87 cards para descobrir a direção do produto. Se roadmap e backlog parecem iguais, provavelmente um deles está fazendo trabalho demais.

Roadmap também é interface entre Produto e o resto da empresa

Produto não é o único público.

Vendas

Quer saber:

o que posso dizer para um prospect?

Essa é uma pergunta legítima. O roadmap precisa deixar claro o que é compromisso e o que ainda é direção. Se não deixa, alguém fará essa interpretação sozinho. E normalmente a interpretação mais otimista ajuda mais a fechar a venda hoje. O custo chega no time de produto depois.

Customer Success e suporte

Querem saber:

existe alguma resposta para esse problema recorrente?

“Está no roadmap” é perigoso quando significa apenas “existe um card no Later”. Melhor comunicar o estado real: estamos investigando, está priorizado como próximo problema, existe trabalho em andamento, existe previsão com determinada confiança.

Liderança

Quer saber:

onde estamos colocando capacidade e o que esperamos obter em troca?

Uma lista de vinte funcionalidades não responde bem. Problema, objetivo e resultado esperado ajudam muito mais.

Engenharia

Precisa enxergar o que pode estar chegando para preparar arquitetura e dependências sem interpretar cada item como especificação fechada.

Cada público lê o mesmo documento procurando uma resposta diferente. Isso também é design de informação.

Cuidado com “Now é a única coluna com data”

Pode funcionar em algumas empresas, mas eu não colocaria como regra. O próprio Now-Next-Later nasceu como alternativa a roadmaps dependentes de datas exatas. Você pode manter previsão de delivery em outro nível: roadmap para direção, planejamento de delivery para execução, release plan para lançamento, backlog para trabalho detalhado.

Quando existe uma data realmente comprometida, ela pode aparecer. O importante é que alguém consiga distinguir visualmente comprometido para 15 de outubro de estimativa atual: outubro, confiança média de direção futura, sem previsão. Essas três coisas não deveriam usar o mesmo componente.

“Confiança” pode ser mais útil que fingir precisão

Em alguns contextos, stakeholders realmente precisam de previsão. Responder apenas:

não trabalhamos com datas.

pode ser tão ruim quanto inventá-las. Uma alternativa é comunicar incerteza explicitamente. Por exemplo:

Previsão: segunda quinzena de outubro
Confiança: alta

ou:

Previsão atual: Q1
Confiança: baixa
Discovery ainda não iniciado

Não existe uma escala universal. O valor está em tornar visível que estimativa não é garantia. Isso também cria uma conversa importante: o que aumentaria nossa confiança? Talvez discovery, spike técnico, definição regulatória, validação com cliente, decisão de fornecedor. A incerteza deixa de parecer incompetência. Vira parte gerenciável do trabalho.

Nem todo pedido de data é realmente sobre data

Quando uma liderança pergunta:

quando isso fica pronto?

talvez esteja tentando responder: posso prometer isso para o cliente? Precisamos contratar? Marketing deve preparar campanha? Teremos retorno ainda este ano? Outra equipe pode depender disso? A data é uma forma de pedir previsibilidade. Às vezes existe uma resposta melhor.

Até o fim do trimestre queremos reduzir pela metade o tempo até a primeira integração.

Isso comunica um compromisso de resultado sem definir prematuramente qual solução produzirá o resultado. Mas também não é substituto universal para data. Se outra equipe precisa da API em 1º de novembro, dizer apenas:

nosso objetivo é melhorar developer experience no trimestre

não resolve a dependência. Resultado e entrega convivem. Um bom roadmap sabe qual dos dois está prometendo.

Mudança de roadmap não deveria parecer desaparecimento

Roadmap bom muda. Isso não é falha. Produto aprende, mercado muda, hipótese cai, prioridade muda. A perda de confiança aparece quando uma iniciativa some e ninguém explica por quê. Uma pequena trilha de decisão ajuda muito.

Movido de Next para Later: integração deixou de bloquear os três clientes que sustentavam a prioridade.

Removido: pesquisa mostrou que o problema estava na configuração, não na ausência da feature.

Entrou em Now: nova exigência regulatória muda o prazo da operação.

Isso preserva contexto. A pessoa que pediu algo não precisa concordar com a decisão. Mas consegue entender que houve uma.

Mudança de escopo e mudança de prioridade são coisas diferentes

Imagine uma iniciativa no Now. Durante discovery técnico, o time descobre que será duas vezes mais complexa. Talvez a prioridade continue exatamente igual. O escopo mudou. Agora imagine que outro problema passou a afetar metade da receita. A iniciativa sai do Now. A prioridade mudou.

Nos dois casos, a data pode se mover. Mas o motivo é diferente. Quando roadmap registra apenas:

atrasou.

perde informação importante sobre a qualidade da decisão.

Revisão não precisa virar cerimônia pesada

Roadmap vivo precisa ser revisado. A frequência depende da velocidade do produto. Para alguns times, mensal funciona bem. Para outros, quinzenal. Produto com ciclos longos talvez precise menos. O importante é não esperar que alguém reclame para descobrir que o documento está desatualizado.

Numa revisão, eu olharia principalmente para movimentos. Alguma coisa deveria sair? Alguma coisa ficou mais importante? Algum item ganhou evidência suficiente para avançar? Alguma hipótese caiu? Alguma coisa está parada porque ninguém sabe qual é o próximo aprendizado? Não precisa reapresentar todo o roadmap do zero. A conversa deveria estar nas mudanças.

Later não deveria ser o cemitério das ideias educadas

Existe uma dinâmica comum. Ninguém quer dizer não. Então o pedido vai para o Later. Todo mundo fica feliz. Ninguém trabalha nele. Dois anos depois, existem cinquenta cards. Isso destrói a utilidade da coluna.

Um item em Later deveria continuar tendo uma razão estratégica para estar visível. Caso contrário, pode ir para um espaço de ideias, feedback ou oportunidades futuras. Roadmap não precisa registrar tudo que a empresa já cogitou fazer. Ele precisa comunicar as escolhas atuais. Remover também é trabalho de produto.

Uma pergunta boa para cada coluna

Se eu precisasse revisar um Now-Next-Later rapidamente, usaria três perguntas.

Now

Ainda estamos convencidos de que este é um dos melhores usos da nossa capacidade neste momento? Não apenas “já começamos?”.

Next

O que ainda precisa ser verdade ou aprendido para assumirmos este compromisso? Se ninguém sabe, o item talvez ainda esteja cedo demais.

Later

Por que esta oportunidade merece continuar no roadmap? Se a resposta for “alguém pediu uma vez”, talvez não mereça.

Essas perguntas mantêm o roadmap como ferramenta de decisão.

Um roadmap não deveria tentar prever o futuro inteiro

O trabalho dele é mais modesto e mais útil: mostrar o que importa agora, o que provavelmente vem depois, o que está no horizonte, por que essas coisas foram escolhidas e qual é o grau de confiança em cada uma. Essa visão continua útil mesmo quando a realidade muda. É isso que faz um roadmap sobreviver ao trimestre. Não a capacidade de acertar em janeiro exatamente o que será construído em novembro.

Roadmap não deveria ser uma promessa de que aprendemos tudo antes de começar. Deveria mostrar como as prioridades mudam conforme aprendemos. Se o seu documento exige ser completamente refeito toda vez que surge informação nova, provavelmente ele não está representando o processo de produto. Está representando uma fotografia antiga dele.

E se quiser começar por um lugar, comece pelo Later. Leia card por card e pergunte: que evidência faria isso avançar? Se ninguém consegue responder e ninguém está tentando descobrir, talvez aquilo não seja roadmap. Seja apenas uma ideia que ainda não precisa ocupar espaço ali.

Para conectar essa priorização com o que o time realmente acompanha depois do lançamento, vale continuar pelo artigo Métricas de produto para time pequeno: o que olhar primeiro.

Fontes

ProdPad / Janna Bastow. Why I Invented the Now-Next-Later Roadmap. Janna Bastow descreve a criação do formato como alternativa aos roadmaps baseados em timeline e datas rígidas, com foco em discovery e em comunicar níveis diferentes de incerteza.

ProdPad. Now-Next-Later Roadmap. Referência atual para o formato. Define as colunas como horizontes de confiança: Now para trabalho em andamento, Next para oportunidades mais próximas em exploração e Later para apostas estratégicas com menor confiança.

ProdPad. História da empresa e do formato Now-Next-Later. Registra que Janna Bastow e Simon Cast desenvolveram a abordagem em 2012 enquanto construíam o ProdPad.

ProdPad. The Ultimate Guide to Product Roadmaps. Referência para a distinção entre roadmaps orientados a problemas e resultados e roadmaps baseados apenas em features e deadlines.