Existe um padrão que se repete em empresas de tecnologia (e, cada vez mais, fora deste segmento): quando faltam decisões explícitas, a organização tenta compensar com artefatos. De repente, OKR vira plano, roadmap vira promessa de valor e cronograma vira estratégia.
O resultado é previsível: as pessoas passam a discutir “datas” como se estivessem discutindo “direção”, e a execução vira uma sequência de renegociações. O problema parece prazo, mas quase sempre é outro: decisão tardia, trade-off mal definido e governança confusa sobre quem decide o quê.
Trata-se de um problema estrutural e, por isso, facilmente reconhecível. Pior: ele tende a se agravar justamente quando atacamos o problema errado. Em A Quinta Disciplina, Peter Senge descreve o arquétipo sistêmico do “Deslocamento de Encargo” (Shifting the Burden): tratamos o sintoma (o atraso) com mais controle e mais camadas de gestão, em vez de tratar a causa fundamental (a falta de clareza sistêmica, decisões explícitas e priorização real).
Este artigo propõe uma forma simples de recolocar as coisas nos seus lugares, para que metas, priorização e execução se reforcem mutuamente, em vez de se sabotarem.
Três conceitos que se parecem, mas não são a mesma coisa
OKR é um sistema de direção (outcome), não de execução (output)
OKRs existem para declarar o que precisa mudar no mundo (resultado observável), não para listar entregas. Quando um KR vira “entregar X até dia Y”, a empresa está, na prática, trocando resultado por tarefa. Isso dá sensação de controle, mas não garante impacto.
● Outcome: Mudança em comportamento, eficiência, adoção, receita, qualidade, risco.
● Output: Entregas que podem contribuir para esse outcome (features, automações, melhorias).
● Plano: Como organizar trabalho para entregar outputs com risco e capacidade considerados.
É importante apenas lembrar que a existência de um depende intimamente do outro, não existe outcome sem output, logo não há como planejar entrega de resultado se não existir capacidade de entrega para tal.
Roadmap é priorização e intenção com níveis de confiança, não “calendário oficial”
Roadmap deveria ser a expressão pública das apostas que o time escolheu perseguir, e da ordem em que elas tendem a acontecer. Quando o roadmap é tratado como um contrato de datas fixas, ele perde seu valor mais importante: promover alinhamento por decisão, não por promessa.
Um roadmap isolado é perigoso. Ele precisa estar conectado ao portfólio da empresa para garantir que as apostas de um produto não disputem, silenciosamente, os mesmos recursos escassos de outro, e para tornar explícitos os trade-offs que, de todo modo, já estão acontecendo.
E um roadmap “de verdade” não é uma vitrine de funcionalidades. Para ser viável, ele precisa tornar visível o fluxo completo do trabalho: Features, Defeitos, Riscos e Dívida Técnica. Se o roadmap só exibe o que brilha para o cliente e esconde o esforço necessário para manter a plataforma de pé (estabilidade, correções, mitigação de riscos e sustentação técnica) então ele não é um instrumento de gestão: é uma peça de marketing com consequências operacionais.
Cronograma é uma ferramenta de coordenação, não uma declaração de porquê
Cronograma serve para organizar dependências, capacidade, riscos e sequenciamento. Ele não substitui estratégia, porque não responde à pergunta: “por que isso importa agora?” Ele responde: “como vamos executar o que já foi decidido?”
Por que as empresas confundem Produto com Projetos (e pagam o preço)
Essa confusão não é “ignorância”; ela é um efeito colateral de como as organizações buscam previsibilidade em ambientes incertos. A confusão entre artefatos de gestão e decisões estratégicas costuma nascer, primeiro, da ansiedade por previsibilidade. A liderança precisa comunicar datas a clientes, áreas internas ou ao conselho e, para reduzir desconforto e incerteza, acaba transformando qualquer artefato disponível em “promessa”, como se um roadmap, um cronograma ou um OKR fossem compromissos fechados, e não hipóteses guiadas por opções (negativas ou positivas) explícitas.
Esse movimento se agrava quando há uma governança sem dono. Se não está claro quem decide os trade-offs entre escopo, prazo e capacidade, as decisões “escorrem” para quem está mais perto do trabalho, normalmente o Product Manager. O problema é que esse não deveria ser o desenho de responsabilidade: o Product Manager decide principalmente o escopo (o “o quê” e o “por quê”), enquanto prazo e, sobretudo, capacidade são definidos no nível acima da gestão de produto, porque exigem coordenação entre times, prioridades concorrentes e limites organizacionais que extrapolam um único produto.
Além disso, a maturidade dos times é desigual e isso distorce a leitura de previsibilidade. Equipes com boa engenharia e gestão de fluxo conseguem estimar e ajustar com responsabilidade; já equipes com dívida técnica alta e baixa observabilidade tendem a confundir plano com desejo, porque o custo real do trabalho e os riscos não aparecem cedo o bastante. O erro, nesse caso, não é “o time não cumprir”, mas a gestão tratar produtos com diferentes condições estruturais como se todos respondessem do mesmo jeito aos mesmos rituais e artefatos.
Há também um modelo mental de fábrica operando por trás: quando a cultura enxerga software como linha de produção, pressupõe que planejar mais resolve a incerteza, como se o problema fosse apenas detalhamento, e não descoberta, complexidade e variabilidade. Por fim, estruturas e incentivos mal desenhados cristalizam o problema: o Product Manager passa a ser cobrado por prazo e entrega como se fosse Project Manager, enquanto gerentes de projetos são cobrados por impactos e resultados como se fossem gerentes de produto.
Quando cada papel é medido pelo que não controla, a organização perde clareza, empurra decisões para baixo e usa artefatos como substitutos de governança.
O custo disso aparece em sintomas comuns: roadmap muda toda semana, “commitments” viram discussões intermináveis, e metas de negócio viram checklists de entrega.
O elefante na sala: por que roadmaps mudam (e por que isso é normal, até certo ponto)
Roadmaps mudam por duas razões. Uma é legítima; a outra é falha de gestão.
Mesmo com uma gestão muito competente, mudanças em roadmap são, em parte, inevitáveis e, em muitos casos, legítimas. O desenvolvimento de produto é um processo de descoberta: o trabalho revela informações que simplesmente não estavam disponíveis no momento do planejamento. Isso inclui incertezas técnicas, como integrações que se mostram mais frágeis do que o previsto, problemas de performance, limites de escalabilidade e detalhes de arquitetura que só aparecem quando se implementa de fato. Inclui também incertezas de produto: o usuário pode não reagir como esperado, uma hipótese pode falhar em teste, um fluxo “óbvio” pode gerar baixa adoção, e o que parecia valor se mostra irrelevante.
Além disso, há dependências externas (plataforma, parceiros, segurança, compliance) que podem alterar prioridades ou bloquear entregas, e existe a complexidade emergente típica de sistemas vivos, na qual efeitos colaterais e interações entre módulos criam trabalho adicional inesperado. Se o roadmap não puder mudar quando a evidência muda, ele deixa de ser instrumento de alinhamento e passa a ser teatro.
Mas nem toda mudança é descoberta: existe um segundo tipo, que nasce de falhas de gestão e de instabilidade estrutural. A dívida técnica, quando acumulada além de certo ponto, empurra o time para um modo reativo: bugs recorrentes, retrabalho, refatorações urgentes e um custo de mudança que cresce continuamente. Nesse cenário, o que parecia “pequeno” vira grande, e o que era grande vira imprevisível, porque a base do sistema deixa de sustentar evolução incremental.
Em paralelo, a instabilidade de equipe (troca constante de desenvolvedores e QAs, realocação frequente, squads desmontados e remontados) fragiliza qualquer previsão: a velocidade aparente oscila, o conhecimento tácito se perde, o contexto se dilui e as estimativas deixam de ter lastro. O resultado é que o roadmap muda não porque o time aprendeu, mas porque o sistema organizacional e técnico não oferece condições mínimas para sustentar um plano.
E aqui entra um ponto frequentemente ignorado: Previsibilidade não é propriedade do roadmap; é propriedade do sistema de trabalho. Se pessoas-chave são movidas com frequência, muitas vezes por decisão da própria direção, a organização reduz a chance de cumprir o que ela mesma quer cobrar. Você não pode otimizar o fluxo de valor se destrói continuamente a estrutura que gera esse valor.
Quando a liderança olha um roadmap, é natural esperar proximidade com as datas planejadas. O que não pode acontecer é exigir essa proximidade sem proteger os pré-requisitos que a tornam possível: Constância de equipe, controle de WIP, gestão ativa de dependências e redução sistemática de dívida técnica.
Papéis e responsabilidades: quem decide o quê (e por que isso muda tudo)
Uma das razões para PM virar “dono de prazo” é simples: O vácuo de decisão é sempre preenchido. Se a diretoria não assume o papel ativo de decisão, alguém no nível operacional será forçado a “decidir por omissão”, e depois será cobrado pelo resultado. A autoridade deve ir para onde está a informação. O papel da liderança não é dar a ordem tática, mas prover a clareza estratégica (e as condições certas) para que o time tenha a “intenção” correta.
A clareza abaixo não é burocracia; é eficiência.
Head de Produto: Papel ativo e inegociável nas decisões
O Head de Produto tem um papel ativo e inegociável nas decisões: ele não existe para “apenas escalonar” conflitos ou arbitrar discussões operacionais. Sua função central é proteger a qualidade das escolhas estratégicas, garantindo que trade-offs sejam explícitos e que a organização não substitua decisão por negociação contínua. Na prática, ele é o guardião das decisões difíceis, aquelas que definem o que a empresa realmente vai perseguir agora, e o que vai ficar de fora.
Isso começa por definir (ou validar) quais outcomes importam neste momento e por quê, para que prioridades não sejam uma coleção de opiniões ou urgências do dia. A partir daí, o Head de Produto lidera decisões entre apostas concorrentes, inclusive exercendo o “não” como ferramenta legítima de estratégia: se tudo é prioridade, nada é prioridade. Ele também estabelece regras claras de compromisso, distinguindo o que é commit do que é forecast e qual o nível de confiança aceitável em cada caso, reduzindo a tendência de transformar previsões em promessas.
Outro ponto essencial é proteger a integridade do sistema de execução. Isso significa limitar WIP, impedir que urgências fragmentem o foco e evitar que a estratégia seja corroída por demandas simultâneas. Inclui, de forma deliberada, garantir que a distribuição de fluxo (flow distribution) seja respeitada: tempo investido em dívida técnica e mitigação de riscos não pode acontecer “nas sombras” como trabalho invisível, mas deve ser uma decisão estratégica assumida, comunicada e defendida. E quando a organização exige previsibilidade, cabe ao Head articular e cobrar (junto à diretoria e ao CTO) a estabilidade mínima dos times, porque previsibilidade não se decreta: ela depende de continuidade, capacidade estável e contexto preservado.
Por fim, o Head de Produto precisa ser o “dono do corte”. Quando a realidade muda (seja por dívida técnica, riscos materializados, dependências externas ou capacidade menor do que o previsto) é ele quem decide o que sai para manter coerência e preservar outcomes, em vez de empurrar essa carga para o Product Manager isoladamente. Sem esse papel ativo, a empresa entra no modo em que planejamento vira uma negociação infinita, e o roadmap deixa de orientar decisões para apenas refletir pressões.
Product Manager: dono do problema e do resultado, não “gerente de Gantt”
O Product Manager deve ser cobrado por resultado de produto (outcomes) e pela qualidade das decisões que toma, não por atividades típicas de gerenciamento de projetos como se essa fosse sua função primária. Quando o PM é avaliado por “cumprir cronograma” acima de entregar impacto, a organização incentiva previsibilidade artificial, empurra riscos para baixo e transforma decisões estratégicas em disputas operacionais sobre prazo. O papel do PM é maximizar valor sob incerteza, e isso exige autonomia para formular boas escolhas e responsabilidade por medir o que mudou de fato para o usuário e para o negócio.
Nesse sentido, as responsabilidades centrais do PM começam por entender profundamente o problema, o público, o contexto e a proposta de valor, formulando hipóteses e critérios claros de sucesso. A partir disso, ele prioriza dentro do seu espaço de atuação com base em impacto e evidência, mantendo alinhamento com o portfólio para que as escolhas locais não conflitem com apostas maiores da empresa. Também cabe ao PM definir o que significa “pronto” do ponto de vista de usuário e negócio (não apenas “entregue”) estabelecendo padrões de qualidade, usabilidade e aderência aos objetivos. Em parceria com engenharia, ele trabalha para reduzir a incerteza cedo, explorando riscos, alternativas e sequenciamento para evitar surpresas tardias. Por fim, mede o impacto pós-entrega, aprende com o resultado e ajusta a direção, fechando o ciclo que diferencia “entrega” de “progresso”.
O PM participa do planejamento e do sequenciamento, mas não deveria ser o responsável final por gestão formal de cronograma, controle de recursos e alocações, gestão de dependências organizacionais em larga escala, ou pela coerção de prazos quando não tem autoridade para proteger capacidade e estabilidade do time. Cobrar do PM esse pacote equivale a tratá-lo como Project Manager sem lhe dar as alavancas de governança que tornam esse papel viável. Product Manager não é Project Manager; quando a organização faz essa cobrança, ela não está aumentando accountability, está apenas deslocando um problema de governança para baixo, sem atacar a causa raiz.
Project Manager (ou função equivalente): Dono da coordenação e previsibilidade do delivery
A função de Project Manager (ou equivalente) é a dona da coordenação e da previsibilidade do delivery. Em contextos com alta complexidade, múltiplas dependências e muitos stakeholders, projetos funcionam como o “sistema nervoso” da execução: conectam partes que não se coordenam sozinhas, sincronizam decisões e reduzem o custo organizacional de transformar intenção em entrega consistente. Não se trata de “cobrar prazo” por si só, mas de criar um ambiente onde a capacidade finita dos times não seja esmagada por uma demanda infinita e desorganizada.
Na prática, o Project Manager pega uma decisão de produto, uma aposta definida e priorizada, e a torna executável como plano e como sistema: marcos, riscos, dependências, sequenciamento e critérios de acompanhamento. Ele trabalha a relação entre capacidade e previsibilidade usando conceitos e métricas de fluxo (como limites de WIP, lead time e throughput) para evitar que a organização opere em modo de multitarefa crônica, que reduz produtividade e aumenta a variabilidade. Também desenha mecanismos de acompanhamento que diminuem a surpresa sem aumentar burocracia: o objetivo não é produzir relatórios do que já aconteceu, mas revelar gargalos, sinais de risco e desvios cedo o bastante para que decisões possam ser tomadas antes que virem crise.
Um componente essencial desse papel é garantir alinhamento transversal e remover impedimentos organizacionais. Muitas vezes, os maiores atrasos não são técnicos, mas surgem de dependências entre áreas que não respondem aos mesmos incentivos, têm prioridades diferentes ou competem por recursos. O Project Manager atua justamente nessa camada “política” e estrutural, negociando acordos, organizando compromissos e criando clareza sobre responsabilidades. Além disso, opera a governança de mudanças: o que muda, quando muda e como comunicar, preservando o alinhamento do projeto com a tese de investimento original ou, quando a evidência mostra perda de valor, ajudando a decidir se o correto é encerrar ou redesenhar o esforço.
Quando bem exercida, a função de projetos não “manda no produto”. Ela torna o produto executável, protegendo o fluxo de trabalho contra atritos organizacionais desnecessários e garantindo que decisões estratégicas se convertam em execução previsível, com transparência real sobre riscos e capacidade.
O que fazer na prática: Um modelo simples para alinhar outcome, output e plano
Um jeito direto de parar a confusão é declarar e operar três camadas, com linguagens diferentes:
- Outcome (OKR): Qual mudança queremos ver?
- Output (Roadmap): Quais apostas/entregas podem causar essa mudança?
- Plan (Cronograma): Como vamos executar essas apostas considerando capacidade, risco e dependências?
- Portfolio (Governança): Estamos alocando nossa capacidade nas apostas certas ou apenas mantendo todos ocupados?
E, principalmente, explicitar dois regimes no roadmap:
● Commit (janela curta, alta confiança): Coisas que têm risco conhecido, capacidade protegida e critérios claros.
● Forecast (janela média, confiança moderada): Intenção sujeita a descoberta, dívida técnica, dependências e mudanças de capacidade.
A maior parte das frustrações nasce quando a liderança trata forecast como commit.
A regra de ouro da previsibilidade: Proteja o time ou aceite a variância
Quer cobrar um roadmap “próximo das datas”? Ótimo, mas então a empresa precisa escolher conscientemente:
Se a direção decide mover pessoas entre times com frequência e, ao mesmo tempo, cobra o roadmap como contrato, ela está exigindo previsibilidade de um sistema que ela mesma tornou instável.
Conclusão: Estratégia não é documento, é decisão sustentada
OKR não é plano. Roadmap não é valor. Cronograma não é estratégia. Esses artefatos são úteis, mas só funcionam quando a organização assume o que evita assumir: DECIDIR.
Estratégia real requer a disciplina de enxergar o todo. Não adianta otimizar a “linha de código” se a decisão de negócio é lenta ou desconectada da capacidade real de execução. Decidir é escolher o que entra e, dolorosamente, o que sai. É declarar trade-offs. É proteger a capacidade cognitiva do time.
Precisamos mover a liderança de uma postura de “controle de tarefas” para “controle de contexto”. É dar ao PM autoridade para conduzir outcome, ao PjM autoridade para, quando necessário, conduzir o fluxo, e exigir que a Diretoria pare de agir como gerente de tarefas de luxo e assuma seu papel real: definir a intenção estratégica e garantir que a estrutura organizacional permita, e não impeça, a entrega de valor.
Sem essa clareza de papéis e fluxo, não existe estratégia. Só existe um calendário colorido e um time exausto correndo atrás de datas inventadas.
Sem decisão, não há estratégia. Só há calendário.
