Em produto, a gente passa rápido de uma oportunidade para outra.

Um cliente traz um pedido interessante. Um vendedor enxerga um mercado possível. O suporte identifica um incômodo recorrente. Uma análise no Mixpanel abre uma pista. Uma query SQL conta outra história. Alguém dispara um benchmark. Outra pessoa abre um Miro. Tudo isso é útil, às vezes. Mas, no fim, a empresa acaba com muito material, muitas discussões, muita energia gasta, e uma pergunta que volta sempre:

Quando é que a gente vai fazer isso?

O problema não é só a falta de tempo. O problema é a falta de uma direção legível.

Um time de produto pode ter trabalhado sério, acumulado estudos, workshops, análises e hipóteses, sem que a empresa saiba de verdade o que é prioritário. E quando nada é decidido com clareza, tudo continua mentalmente aberto. Os assuntos não são feitos, mas também não são abandonados. Ficam ali. Voltam nas reuniões. Apodrecem. Cansam.

Esse cansaço é intelectual, mas também é moral. De tanto trabalhar em assuntos que ninguém sabe se serão realmente feitos, a intensidade cai. A gente pensa: "De qualquer jeito, talvez isso nunca vire prioridade." O trabalho perde força porque não está mais ligado a uma decisão clara.

A roadmap Now / Next / Later responde a esse problema.

Mas só se entendermos bem o que ela é.

Uma roadmap NNL não é um cronograma

A roadmap Now / Next / Later, ou NNL, não busca dizer com precisão o que vai sair em tal dia, tal semana, tal mês.

Ela troca uma lógica de datas por uma lógica de horizontes de certeza.

• Now: o que o time está fazendo agora.
• Next: o que o time prepara ou considera a sério.
• Later: o que continua no campo dos possíveis, mas não é prioritário.

Essa estrutura parece simples. E é. É justamente aí que está a graça dela.

Mas a simplicidade do formato não deve esconder a sua verdadeira função. Uma roadmap NNL não é uma matriz de decisão. Ela não decide no lugar do product manager. Não substitui a estratégia de produto. Não substitui as arbitragens. Ela serve para tornar essas arbitragens visíveis, discutíveis e comunicáveis.

Uma boa roadmap NNL cabe em uma página. No ideal, ela deve poder ser entendida sem ler um documento de vinte páginas. Não é um banco de dados de produto, nem uma ferramenta de gestão de tickets, nem um inventário de tudo o que a empresa poderia fazer.

É um mapa de direção.

Now, Next, Later: o que cada coluna quer dizer

A coluna já carrega uma decisão. O card, por sua vez, explica o valor.

Esse é um ponto importante. Não devemos preencher os cards com informações que repetem o status da coluna. Se um card está em Now, já sabemos que ele está em andamento. Se está em Next, já sabemos que é candidato. Se está em Later, já sabemos que não é prioritário.

O card precisa, então, responder a outra pergunta: por que esse assunto merece um lugar aqui?

Now: o que a gente faz

Now é o trabalho em andamento.

Nesse ponto, já passamos da discussão vaga. Sabemos qual problema estamos tratando, qual valor queremos criar, para quem, com quais limites, e como vamos saber se o assunto funciona.

Um card Now precisa, portanto, ser concreto. Ele pode carregar uma feature, uma evolução de produto, uma melhoria estruturante, mas precisa, acima de tudo, carregar uma promessa de valor clara.

Você deve conseguir encontrar ali:

• a promessa de valor;
• o público-alvo;
• o problema atual;
• o que vai mudar;
• o que está incluído e o que não está;
• os benefícios esperados;
• os indicadores de sucesso;
• o que dá para dizer aos clientes;
• o que não se deve prometer.

O Now também é a coluna mais restrita. Ela é limitada pela capacidade real do time de produzir agora. Se um time consegue tratar três grandes assuntos, ele não deve exibir oito. Senão a roadmap não clarifica mais nada: ela fabrica uma ilusão de compromisso.

Next: o que a gente prepara

Next é o nível dos assuntos sérios.

Eles ainda não estão em andamento como o Now, mas não são simples ideias. Podem ainda estar no espaço do problema. Podem já apontar para uma solução. Mas precisam, no mínimo, ter sinais, um valor previsto e uma razão clara para serem olhados agora.

Um card Next pode conter:

• o problema ou a oportunidade;
• o valor previsto;
• os sinais disponíveis;
• as questões a decidir;
• as condições para passar para Now;
• o impacto de negócio potencial;
• o que dá para dizer internamente;
• o que não se deve dizer aos clientes.

O Next precisa continuar limitado. Se assuntos demais estão em Next, nada consegue avançar de verdade. A coluna vira um pré-backlog político: cada um coloca ali o seu assunto para ele continuar visível, mas ninguém assume a restrição.

Later: o campo dos possíveis

Later é o universo que a empresa aceita manter visível sem se comprometer.

Essa coluna é útil porque evita uma brutalidade desnecessária. Nem todo assunto não prioritário é absurdo. Alguns são interessantes. Alguns vão ficar importantes se o mercado mudar, se um grande cliente assinar, se surgir uma restrição regulatória, se uma dependência técnica desaparecer, ou se um salto tecnológico tornar possível de repente o que não era.

Mas Later não é uma promessa.

Um card Later precisa explicar:

• o valor possível;
• o público-alvo;
• por que o assunto continua visível;
• por que ele não é prioritário;
• os sinais disponíveis;
• os gatilhos de reavaliação.

Aqui também a coluna precisa ser limitada. Se Later vira uma lista infinita, a roadmap volta a ser um inventário.

O No: o que a gente não vai fazer

Na NNL, o mais importante nem sempre é o que está escrito.

O mais importante é, às vezes, o que não está ali.

O No não é uma coluna formal. Mas é o efeito central da roadmap: tudo o que não é Now, nem Next, nem Later está fora do escopo para o horizonte atual.

Isso não quer dizer que o assunto é bobo. Não quer dizer que nunca mais poderemos falar dele. Quer dizer: por enquanto, salvo uma grande ruptura, a gente não vai fazer.

Isso é essencial, porque o que a gente faz e o que a gente não faz são as duas faces da mesma decisão.

Se a empresa diz que quer avançar em automação, onboarding e redução do suporte, ela também está dizendo que não vai fazer agora a reformulação completa da interface, o marketplace de integrações, o módulo para contadores e os pedidos específicos de um pequeno segmento de clientes.

Essa renúncia não é um dano colateral. É o mecanismo que protege a concentração.

Uma roadmap que não permite dizer não, não serve para alinhar. Serve só para adiar os conflitos.

A restrição de capacidade é a primeira barreira de proteção

Uma roadmap NNL precisa estar fisicamente restrita.

O Now é fixado pela capacidade do time de produzir num dado momento. Não pela ambição da direção. Não pela pressão comercial. Não pelo número de assuntos interessantes.

Se o time tem capacidade de fazer dois grandes assuntos direito, o Now deve conter dois grandes assuntos. Talvez três, se os assuntos forem menores. Não dez.

A mesma lógica vale para Next e Later.

Um Next sobrecarregado bloqueia a circulação. Os assuntos de Later não conseguem mais subir. Os assuntos de Next continuam candidatos por tempo demais. O sistema dá uma impressão de movimento, mas não existe mais decisão de verdade.

A restrição de número obriga a justificar.

Ela obriga a se perguntar:

• por que esse assunto e não outro?
• qual problema ele atende?
• qual objetivo de negócio ele sustenta?
• qual risco ele reduz?
• qual valor ele traz?
• do que a gente abre mão ao dar esse lugar a ele?

Uma regra simples: a roadmap precisa continuar legível em uma página. Se transborda, ela não clarifica mais. Volta a ser um estoque.

A estratégia antes da lista

Uma roadmap NNL não é uma lista de assuntos arrumados em três colunas.

Se ela não estiver ligada a uma visão de produto e a uma estratégia de empresa, vira só uma apresentação mais bonita da bagunça que já existe.

Antes de preencher as colunas, é preciso saber o que a empresa está tentando alcançar. Crescimento? Retenção? Expansão em um segmento? Redução do suporte? Diferenciação? Segurança regulatória? Subida de gama? Redução de um atrito crítico?

Os assuntos devem então ser avaliados através de riscos claros.

Dá para retomar aqui os grandes riscos de produto popularizados por Marty Cagan:

• isso é bom para a empresa?
• o cliente quer comprar?
• o usuário quer usar?
• é viável tecnicamente?

Essas perguntas evitam preencher a roadmap com os assuntos mais barulhentos. Um pedido comercial importante pode ser legítimo. Uma dor do suporte pode ser crítica. Uma oportunidade de mercado pode ser real. Mas a roadmap não deve ser a soma das pressões que chegam.

Ela deve ser a tradução visível de uma estratégia.

Como preencher um card sem virar burocracia

A armadilha clássica é transformar a roadmap em formulário.

Em produto, às vezes a gente adora criar campos, status, tags, workflows, subcategorias, regras de validação. Isso dá uma impressão de seriedade. Mas se a informação não ajuda nem a decidir, nem a entender, nem a comunicar, ela só pesa no sistema.

A boa regra é simples: a coluna carrega a decisão, o card explica o valor.

Não é preciso, portanto, colocar em cada card:

• o seu horizonte;
• o seu nível de compromisso;
• o seu papel;
• a sua natureza burocrática;
• uma repetição do status.

O card deve, em vez disso, tornar o assunto compreensível.

Para um card Now, você deve conseguir entender o que vai mudar e como vamos medir o sucesso.

Para um card Next, você deve conseguir entender por que o assunto é sério, o que ainda falta decidir e o que o faria passar para Now.

Para um card Later, você deve conseguir entender por que o assunto continua visível e por que ele não é prioritário.

Todo o resto deve continuar leve. Às vezes, uma tag basta.

Roadmap NNL e backlog: dois objetos diferentes

A roadmap NNL não é um backlog.

A roadmap seleciona os grandes assuntos que merecem atenção. O backlog organiza o trabalho a fazer nos assuntos selecionados.

A diferença é importante.

Na roadmap, você pode ter uma iniciativa como:

Automatizar a entrada dos documentos em papel.

No backlog, essa iniciativa vai ser fatiada em problemas, funcionalidades, tarefas técnicas, tickets de design, stories, critérios de aceitação, dependências, testes, correções, iterações.

O backlog é mais fino. É operacional. Serve para produzir.

A roadmap, por sua vez, serve para alinhar.

O risco é transformar o backlog no lixo da roadmap. Um assunto não está em Now, nem em Next, nem em Later, mas a gente não quer matar ele de verdade. Então joga no backlog. Ele vai ficar ali. Vai envelhecer. Alguém vai reencontrá-lo seis meses depois. Vai ser preciso rediscutir. A carga mental volta.

Se um assunto não está na NNL, ele não deve entrar automaticamente no backlog.

Senão o backlog absorve todas as renúncias que a roadmap não assumiu.

Roadmap interna e roadmap para o cliente

Provavelmente são necessárias duas roadmaps.

Uma roadmap interna e uma roadmap para o cliente.

A roadmap interna pode ser mais completa, mais estratégica, mais cheia de nuances. Pode conter hipóteses, arbitragens, limites, motivos de não priorização, assuntos sensíveis, debates ainda abertos.

A roadmap para o cliente precisa ser uma tradução.

Não uma extração automática. Não uma cópia filtrada. Uma tradução manual, prudente, de produto e comercial.

Esse trabalho é sutil demais para ser automatizado direito. O que dá para dizer a um cliente depende do nível de compromisso real, do risco de promessa implícita, do contexto comercial, do segmento, da maturidade do assunto e da capacidade da empresa de sustentar a mensagem.

Um assunto em Now muitas vezes pode ser comunicado, com limites claros.

Um assunto em Next às vezes pode ser mencionado como direção de reflexão, mas não deve ser vendido como compromisso.

Um assunto em Later precisa ser tratado com prudência. O simples fato de mostrá-lo já pode criar uma expectativa.

Aqui também, o que a gente não faz conta tanto quanto o que a gente faz. A comunicação com o cliente muda conforme as escolhas assumidas pela roadmap.

Governança: quem decide, e em que ritmo?

Uma roadmap NNL precisa de um dono.

Todo mundo pode propor. Todo mundo pode contestar. Os vendedores precisam poder trazer o que veem. O suporte precisa poder levantar os incômodos recorrentes. Os desenvolvedores precisam poder alertar sobre os riscos técnicos. Os líderes precisam poder lembrar a estratégia. Os clientes precisam poder influenciar por meio dos seus problemas reais.

Mas, no fim, é preciso alguém que decida.

Na maioria das organizações de produto, esse tomador de decisão deve ser o product manager, ou a pessoa que carrega de fato a arbitragem de produto. Ele precisa ouvir todo mundo, mas também precisa decidir. Senão a roadmap vira um compromisso mole entre jogos de influência.

O ritmo de revisão precisa ser lento o bastante para evitar a discussão permanente, mas regular o bastante para continuar conectado à realidade.

Um ritmo trimestral costuma ser uma boa base.

Curto demais, corremos o risco de transformar a roadmap em debate político ou em conversa de bar. Longo demais, corremos o risco de manter assuntos que não estão mais alinhados com a estratégia, o mercado ou a capacidade real.

Pontos mensais podem existir com os vendedores e os stakeholders, desde que não virem um jogo de poder. O papel deles deve ser trazer sinais, não derrubar a roadmap a cada nova oportunidade.

As regras de entrada e de saída devem continuar simples.

Um assunto entra na NNL se tiver valor, sinais, ligação estratégica e capacidade disponível o bastante para merecer um lugar.

Um assunto sai se um assunto mais forte entra, se a estratégia muda, se os sinais desaparecem, se a viabilidade desmorona, ou se uma grande ruptura redistribui as prioridades.

Não é preciso criar burocracia demais. Uma nota curta ou uma tag pode bastar para explicar por que um assunto saiu.

A fraqueza de uma roadmap: ela fixa as coisas

Uma roadmap serve para fixar uma direção.

Essa é a sua força.

Mas também é o seu limite.

Até uma boa roadmap NNL pode criar um efeito de travamento. Ela protege contra a dispersão, mas também pode impedir de tratar pequenas melhorias óbvias, muito úteis, muito esperadas, mas pequenas demais ou oportunistas demais para virarem assuntos de roadmap.

É aí que um modo comando pode fazer sentido.

Não como uma coluna a mais. Não como uma exceção permanente. Não como uma forma de contornar as arbitragens.

Como uma respiração controlada fora da roadmap.

Por exemplo: um tempo sagrado na sexta-feira, um time mínimo, um diálogo direto, pouca burocracia, um assunto escolhido a critério do product manager, uma forte convicção de valor, um esforço limitado, e um corte nas solicitações de sempre.

A graça é tratar essas pequenas coisas que fazem o produto se mexer e mostram aos clientes que a empresa está avançando. Não os grandes projetos incertos. Não as apostas estratégicas. Os assuntos em que já sabemos que existe valor, porque a dor volta com frequência, porque o suporte a enxerga, porque os clientes a formulam, porque o time conhece o produto.

Exemplo simples: um cliente precisa produzir um documento administrativo e buscar dados em dez telas diferentes. A solução ideal talvez fosse um módulo completo. Mas uma exportação em texto ou Markdown, mesmo imperfeita, já pode fazer ele economizar várias horas.

Isso não é a roadmap.

É uma respiração em volta da roadmap.

E os bugs?

A teoria é limpa. A realidade nem tanto.

Na vida real, existem os bugs, a manutenção, as regressões, as urgências, os incômodos, a dívida técnica.

A roadmap NNL não substitui a gestão operacional do produto.

Os bugs costumam ser tratados no dia a dia, conforme a sua gravidade, o seu impacto no cliente, a sua frequência, o seu risco e a sua visibilidade. Nem todo bug tem que entrar na roadmap. Se todos entram, a roadmap deixa de ser uma ferramenta de direção.

A dívida técnica pede outro tratamento. Uma dívida só é de fato uma dívida quando decidimos quitá-la. Antes disso, costuma ser um desconforto, um risco latente, uma complexidade, uma fraqueza de arquitetura, às vezes conhecida há muito tempo. Ela vira um assunto de produto quando a empresa decide que o seu custo agora é maior do que o custo de tratá-la.

Alguns assuntos técnicos podem, portanto, entrar na NNL. Por exemplo, se bloqueiam uma estratégia, deixam o time muito mais lento, expõem a empresa a um risco, degradam a qualidade para o cliente, ou impedem uma mudança importante de produto.

Mas aqui também é preciso ser claro: a roadmap carrega uma direção. Ela precisa coexistir com uma gestão diária dos bugs e uma estratégia explícita de tratamento da dívida técnica.

Esses dois assuntos merecem seus próprios artigos.

Exemplo: uma roadmap NNL simples

Vamos pegar um SaaS B2B de gestão administrativa.

A empresa atende clientes que precisam produzir documentos com regularidade, centralizar informações e reduzir trabalho manual. O time de produto é limitado: não consegue tocar cinco grandes projetos em paralelo. A estratégia do trimestre é reduzir o atrito para o usuário e reforçar o valor percebido nos usos recorrentes.

Uma roadmap NNL poderia se parecer com isto.

Now

Exportação fiscal simplificada

Promessa: permitir que o usuário gere rapidamente um arquivo com as informações necessárias para um trâmite administrativo.

Valor: evitar várias horas de busca e de copiar e colar em telas diferentes.

Limite: ainda não é um módulo fiscal completo. É uma exportação útil, confiável, compreensível.

Indicadores: número de exportações, queda dos pedidos de suporte ligados a esse trâmite, retornos qualitativos dos clientes envolvidos.

Redução de um incômodo de onboarding

Promessa: reduzir o tempo necessário para concluir a primeira configuração.

Valor: melhorar a ativação e reduzir os travamentos precoces.

Limite: a gente não refaz todo o onboarding, trata o principal ponto de travamento.

Indicadores: taxa de ativação, tempo até o primeiro valor, tickets de suporte na etapa envolvida.

Next

Automação de entrada documental

Valor previsto: reduzir o trabalho manual com documentos em papel ou PDF.

Sinais: pedidos recorrentes de clientes, tempo de suporte alto, oportunidade de diferenciação.

Questões a decidir: nível de automação realista, qualidade esperada, viabilidade técnica, custo de erro aceitável.

Condição para passar para Now: escopo reduzido, valor claro, solução tecnicamente dominável.

Relatórios de atividade aprimorados

Valor previsto: dar aos clientes uma visão mais clara da sua atividade e dos seus pontos de travamento.

Sinais: pedidos comerciais, feedbacks de clientes, uso frequente das exportações existentes.

Questões a decidir: quais indicadores são de fato acionáveis, para quais perfis, com que frequência de uso?

Later

Módulo avançado de IA

Valor possível: automatizar ainda mais a análise e a preparação de documentos.

Por que continua visível: assunto estratégico possível, evolução rápida do mercado.

Por que não é prioritário: dependências técnicas fortes, risco de promessa exagerada, valor ainda pouco delimitado.

Gatilho: salto tecnológico, forte demanda de um segmento prioritário, prova de uso em um caso reduzido.

Marketplace de integrações

Valor possível: conectar o produto a mais ferramentas dos clientes.

Por que continua visível: pode sustentar a expansão.

Por que não é prioritário: custo alto, dispersão provável, necessidade do cliente ainda heterogênea demais.

Gatilho: concentração clara dos pedidos em algumas integrações críticas.

Portal para contadores

Valor possível: criar uma experiência dedicada a um ator externo importante.

Por que continua visível: assunto interessante para alguns segmentos.

Por que não é prioritário: impacto ainda incerto, risco de complicar o produto principal.

Gatilho: assinatura de um grande cliente ou estratégia explícita para esse segmento.

Fora da NNL

Alguns assuntos não estão na roadmap.

Por exemplo:

• reformulação completa da interface;
• pedidos específicos de um pequeno cliente;
• funcionalidades avançadas para um segmento não prioritário;
• integrações isoladas sem sinal de mercado;
• experimentação de IA geral demais.

Esses assuntos podem ser interessantes. Só não estão na direção atual.

E é justamente isso que torna a roadmap útil.

Conclusão

Uma roadmap NNL bem-sucedida não dá a ilusão de que tudo é possível.

Ela dá à empresa a força de fazer poucas coisas, mas de fazê-las de verdade.

Ela clarifica o que está em andamento, o que se prepara, o que continua possível, e o que está fora do escopo. Ela reduz a dispersão. Ela protege o backlog. Ela torna as renúncias discutíveis em vez de escondê-las. Ela dá ao product manager um quadro para ouvir, arbitrar e comunicar.

A NNL não é perfeita. Ela não resolve os bugs, a dívida técnica, as urgências, nem as pequenas oportunidades de alto valor. Mas ela dá uma coisa rara: uma direção clara o bastante para que a empresa possa avançar sem reabrir tudo o tempo todo.

E em muitas organizações de produto, isso já é enorme.

Para saber mais

As ferramentas de coerência organizacional O backlog não é um depósito de lixo: é uma ferramenta de ação Por que as organizações preferem decisões frouxas