Há pouco tempo, eu estava trabalhando com uma organização muito orientada à demanda.
A empresa está justamente num movimento de transição: buscando trabalhar mais com uma lógica de produto, mais orientada a objetivos e resultados.
E foi nessa conversa que uma tensão ficou muito clara para mim.
De um lado, a organização ainda funciona fortemente a partir de demandas, projetos, prioridades e entregas.
Do outro, começa a surgir uma lógica diferente, alinhada ao que hoje se discute como Product Operating Model: partir de objetivos, dar mais contexto aos times e orientar decisões pelo resultado que se quer alcançar.
Foi daí que nasceu a provocação deste artigo: objetivo versus demanda.
Não como uma disputa entre dois modelos.
Mas como uma mudança na lógica de decisão.
O que significa ser orientado a demanda
A lógica orientada a demanda é muito familiar.
Alguém pede alguma coisa. A demanda é registrada, entra numa fila ou lista de trabalho, é analisada, priorizada, planejada, executada e entregue.
Esse modelo faz sentido. Ele está presente na gestão de projetos, em operações, em tecnologia e em praticamente qualquer organização grande.
Clientes fazem pedidos. Áreas internas fazem pedidos. Regulação gera demandas. Problemas técnicos geram demandas. A operação do dia a dia gera demandas.
Então o problema não é a demanda.
Demandas fazem parte da realidade de qualquer organização.
O problema começa quando a demanda vira a principal unidade de decisão.
Quando a lógica passa a ser:
“Essa demanda chegou. Precisamos executá-la.”
Mas muitas vezes uma pergunta importante fica de fora:
“Que objetivo essa demanda ajuda a alcançar?”
Uma organização orientada a demanda organiza o trabalho a partir do que precisa ser feito.
Uma organização orientada a objetivo começa pelo que precisa alcançar. A partir daí, decide o que vale a pena fazer.
Ser bom em entregar não é o mesmo que ser bom em alcançar objetivos
Em uma organização orientada a demanda, boa parte das conversas começa pelo trabalho.
O que precisa ser feito? Qual o prazo? Quem vai executar? Quanto vai custar? Quais são as dependências?
Em uma organização orientada a objetivo, a conversa começa um pouco antes.
O que queremos alcançar?
Como vamos saber se estamos avançando?
E só então:
O que vale a pena fazer para chegar lá?
Essa inversão parece simples, mas muda o ponto de partida da decisão.
Uma coisa é concluir o que foi planejado.
Outra é alcançar o resultado que justificou aquele trabalho.
Quando o trabalho vem antes do resultado
Imagine que alguém diga:
“Precisamos criar um novo portal para clientes.”
Em uma lógica orientada a demanda, a conversa normalmente segue para escopo, funcionalidades, prazo, orçamento, responsáveis e data de entrega.
Nada disso está errado.
Mas repare no ponto de partida.
O trabalho já foi definido.
Agora imagine começar por outro lugar:
“Queremos reduzir em 30% o esforço que os clientes fazem para resolver solicitações simples.”
A conversa muda.
Talvez um novo portal faça sentido.
Talvez seja melhor melhorar o portal atual.
Talvez seja automação.
Talvez seja simplificar o processo interno.
Talvez seja eliminar completamente a necessidade daquela solicitação.
O objetivo abre espaço para escolha.
A demanda, muitas vezes, já chega com um caminho definido.
Na lógica da demanda, primeiro definimos o que fazer e depois discutimos o resultado.
Na lógica orientada a objetivo, a ordem se inverte.
Primeiro buscamos clareza sobre o que queremos alcançar.
Depois decidimos o que vale a pena fazer para chegar lá.
Alvo ao tiro
Existe uma imagem que uso no meu livro Team OKR em Ação para representar um erro comum.
tiro ao alvo pu alvo ao tiro?
Imagine alguém que atira uma flecha numa parede de madeira. Depois que vê onde ela acertou, vai até lá e pinta um alvo em volta.
Parece que acertou na mosca.
Mas o alvo veio depois do tiro.
Eu chamo isso de alvo ao tiro.
Em muitas organizações orientadas a demanda, acontece algo parecido.
Primeiro definimos o que será feito.
Depois planejamos.
Depois executamos.
E, só então, tentamos conectar aquilo a um objetivo ou mostrar qual resultado aquela entrega gerou.
Primeiro vem o tiro. Depois pintamos o alvo.
O problema é que isso pode criar uma aparência de alinhamento quando, na verdade, o resultado não orientou a decisão desde o início.
Na lógica orientada a objetivo, primeiro deixamos claro o resultado que buscamos. Depois decidimos como agir.
A ordem importa: objetivo antes do backlog
Outro erro comum é começar pelo que já está na lista de trabalho, no to-do list ou no backlog.
Backlog é um termo muito usado em tecnologia e gestão de produtos para representar a lista de itens de trabalho que estão na fila: demandas, tarefas, melhorias, problemas e outras coisas que o time pode precisar fazer.
O time já tem uma série de itens acumulados nessa lista.
Então alguém olha para tudo isso e pergunta:
“Qual é o objetivo por trás desses itens de trabalho?”
O problema é que, nesse momento, o trabalho já foi escolhido.
O objetivo entra depois, quase como uma justificativa.
E muitas vezes nem existe um objetivo único que realmente conecte tudo. O backlog parece mais uma colcha de retalhos: demandas de origens diferentes, prioridades diferentes, urgências diferentes.
No meu livro Team OKR em Ação, uso uma imagem simples para representar essa diferença.
O backlog não deve definir o Team OKR. O Team OKR deve orientar o que pertence ao backlog.
A ideia é simples.
Não comece pela lista do que precisa ser feito para depois tentar encontrar um objetivo que combine com ela.
Comece pelo objetivo.
Depois pergunte:
“Dado esse objetivo, o que realmente deveria entrar na nossa lista de trabalho?”
O backlog deixa de ser apenas um lugar onde acumulamos demandas e passa a refletir, de forma mais clara, a direção que escolhemos seguir.
Onde entra o OKR
Se a lógica é começar pelo objetivo, vale tornar esse objetivo explícito.
É aqui que o OKR pode ajudar.
OKR significa Objectives and Key Results, em português, Objetivos e Resultados-Chave.
Mas, para esta conversa, o mais importante não é o framework em si.
É a lógica que ele traz.
O Objetivo responde:
“O que queremos alcançar?”
Os Key Results ajudam a responder:
“Como vamos saber se estamos avançando?”
Ou seja, o objetivo dá direção e os resultados-chave trazem evidências de progresso.
Primeiro deixamos claro o que queremos alcançar.
Depois, como vamos saber se estamos avançando.
E só então faz sentido discutir o trabalho.
Da demanda à iniciativa
Nem toda demanda deveria entrar diretamente no backlog.
Uma demanda é algo que chega ao time: um pedido, uma necessidade, uma exigência, uma ideia, uma solicitação.
Ela pode ser importante.
Pode ser urgente.
Pode até ser obrigatória.
Mas, antes de simplesmente transformá-la em trabalho, vale perguntar:
“Que objetivo essa demanda ajuda a alcançar?”
Essa pergunta muda o papel da demanda.
Ela deixa de ser automaticamente uma ordem de execução e passa a ser entendida dentro de uma direção.
Quando essa conexão fica clara, a demanda pode se transformar em uma iniciativa do time.
Ou seja:
demanda é entrada.
iniciativa é escolha.
A iniciativa representa aquilo que o time decide fazer porque acredita que pode ajudar a alcançar um objetivo.
E é aí que gosto de usar um template simples:
Acreditamos que [INICIATIVA]
vai nos ajudar a alcançar [OBJETIVO].
Sabemos que estamos avançando quando vemos progresso em [KEY RESULTS].
Esse é o template que apresento no Team OKR em Ação para conectar iniciativa, objetivo e evidência de progresso.
A primeira palavra importa:
Acreditamos.
Porque uma iniciativa não é uma certeza.
É uma aposta.
Estamos dizendo que, com o que sabemos hoje, acreditamos que fazer aquilo pode ajudar a alcançar o resultado que buscamos.
Isso é bem diferente de simplesmente receber uma demanda e concluir:
“Temos que fazer isso.”
O template força uma conversa importante:
- Qual objetivo essa demanda ajuda a alcançar?
- Que iniciativa faz mais sentido diante desse objetivo?
- Que resultados esperamos observar?
- Como vamos saber se estamos avançando?
Nem sempre a resposta será fazer exatamente o que foi pedido.
E esse talvez seja um dos pontos mais importantes da transição de uma lógica orientada a demanda para uma lógica orientada a objetivo.
Entregar não é o mesmo que alcançar resultado
Na lógica orientada a demanda, a pergunta costuma ser:
“Entregamos?”
Na lógica orientada a objetivo:
“Alcançamos o resultado?”
O portal foi entregue. Mas os clientes passaram a resolver seus problemas com menos esforço?
A nova funcionalidade foi lançada. Mas aumentou a retenção?
O novo processo foi implantado. Mas reduziu o tempo de atendimento?
Modernizamos o sistema. Mas isso melhorou a experiência do usuário?
O projeto terminou. Mas o resultado esperado aconteceu?
Entregar é importante.
Sem entrega, nada muda.
Mas a entrega, por si só, não garante resultado.
Entrega é meio. Resultado é o que justifica a entrega.
A demanda não desaparece. Ela ganha um filtro
Uma organização orientada a objetivo pode continuar recebendo demandas.
A diferença é que cada demanda não entra automaticamente como trabalho a ser executado.
Antes, algumas perguntas ajudam:
- Que objetivo essa demanda ajuda a alcançar?
- Que resultado esperamos gerar com ela?
- Como vamos saber se estamos avançando?
- Existe outra forma de alcançar o mesmo resultado?
Isso não significa burocratizar a entrada de trabalho.
Significa qualificar a decisão antes da execução.
Algumas demandas continuarão entrando quase diretamente no backlog, especialmente as obrigatórias, regulatórias ou operacionais.
Outras vão precisar ser discutidas, agrupadas, reformuladas ou até descartadas.
O objetivo passa a funcionar como um filtro para ajudar a decidir o que deve ser feito, o que pode esperar e o que talvez nem precise entrar na lista de trabalho.
Onde entra o Product Operating Model
Boa parte da discussão atual sobre Product Operating Model nasce exatamente dessa mudança de lógica.
Não é simplesmente trocar projetos por produtos.
Não é trocar demandas por objetivos.
Não é renomear equipes como squads.
Não é eliminar planejamento.
E não é abandonar gestão.
É mudar a lógica de decisão.
A demanda continua existindo, mas deixa de ser o principal ponto de partida.
O objetivo passa a orientar o que merece atenção, o que deve ser priorizado e onde vale a pena colocar energia.
E isso vem acompanhado de outra mudança importante: mais autonomia e mais responsabilidade para os times de produto.
Em vez de receber apenas demandas para executar, esses times passam a entender melhor o contexto, os objetivos e os resultados esperados. Com isso, ganham espaço para decidir como contribuir dentro de um escopo claro de atuação.
Para simplificar, imagine uma caixa com tudo aquilo pelo qual o time é responsável. Essa “caixa” é o produto do time.
Como definir bem essa “caixa”, especialmente em organizações grandes, com muitas áreas, estruturas e topologias de times mais complexas, é assunto para outro artigo.
Aqui, o ponto é outro.
Dentro dessa área de responsabilidade, o time precisa ter espaço para decidir como melhor contribuir para os objetivos.
Autonomia, nesse caso, não é liberdade para fazer qualquer coisa.
É liberdade para escolher o melhor caminho dentro de uma direção clara.
E responsabilidade é assumir compromisso não só com a entrega, mas também com o resultado.
Objetivo não significa ausência de controle
Às vezes, quando se fala em times mais orientados a objetivo, parece que a liderança simplesmente define uma direção e diz:
“Esse é o objetivo. Se virem.”
Não é isso.
Objetivo não elimina gestão.
Ele muda o que a gestão acompanha e como as decisões são discutidas.
Em vez de olhar apenas para atividades concluídas, passa a ser importante acompanhar também:
- o que estamos tentando alcançar;
- quais resultados estamos observando;
- o que estamos aprendendo;
- e se o caminho escolhido ainda faz sentido.
A gestão continua existindo.
Mas a conversa deixa de ser apenas sobre controle da execução e passa a incluir também a qualidade das decisões, o progresso em direção ao objetivo e os resultados alcançados.
Dar mais autonomia sem clareza gera confusão.
Cobrar mais responsabilidade sem dar espaço para decisão gera frustração.
O equilíbrio está justamente aí:
direção clara, autonomia para decidir e responsabilidade pelos resultados.
Demanda é trabalho chegando. Objetivo é direção escolhida.
Talvez essa seja a forma mais simples de resumir a diferença.
Demanda é trabalho chegando.
Objetivo é direção escolhida.
Toda organização precisa lidar com os dois.
Novos pedidos, necessidades, problemas, obrigações e oportunidades vão aparecer o tempo todo.
O ponto não é eliminar isso.
É não deixar que cada nova demanda, por si só, defina a direção.
Quando o objetivo está claro, a demanda ganha contexto.
E surgem perguntas melhores:
- O que merece atenção agora?
- O que deve ser priorizado?
- O que pode esperar?
- O que não faz mais sentido?
E, principalmente:
- o que realmente nos aproxima do resultado que queremos alcançar?
Uma mudança simples de pergunta
Talvez a transição de uma organização orientada a demanda para uma mais orientada a produto comece com uma mudança simples.
Em vez de perguntar primeiro:
“O que precisamos fazer?”
Pergunte:
“O que queremos alcançar?”
Depois:
“Como saberemos que estamos avançando?”
E só então:
“O que vale a pena fazer para chegar lá?”
Não é sobre parar de atender demandas.
É sobre não deixar que as demandas, sozinhas, determinem a direção.
Objetivos dão direção.
Iniciativas são apostas sobre como avançar.
E o backlog organiza o trabalho necessário para colocar essas apostas em prática.
Essa ordem importa.
Porque, quando começamos pela demanda, corremos o risco de atirar primeiro e pintar o alvo depois.
Quando começamos pelo objetivo, o alvo está claro — e podemos escolher, aprender e ajustar os tiros ao longo do caminho.
—————————-
Se você gostou deste artigo e quer se aprofundar, há alguns caminhos possíveis.
📘 Se gosta de ler, confira meus livros Lean Inception e Team OKR.
🎥 Se prefere aprender com vídeos, mentorias e troca com outras pessoas, conheça o Hub Lean Inception e o Hub Team OKR.
💼 E se você quer levar essa discussão para o seu time ou organização, conheça os serviços que ofereço. Ou, se preferir, me chama no LinkedIn ou pelo Caroli.org e marcamos um papo.
