Atendendo a pedidos, aqui está a versão traduzida do artigo (os links apontam para materiais em inglês). Embora ele seja voltado para quem desenvolve produtos e serviços baseados em tecnologia, pessoas de outras áreas também podem aprender com o post.

A versão original do artigo está no site da SVPG.

Nota do Marty Cagan:

Meu coautor para este artigo é o consultor e mentor de produto Felipe Castro. Conheço Felipe há muitos anos, e ele colaborou comigo no conteúdo relacionado a outcomes e OKR em cada um dos meus livros. Felipe se especializa em ajudar empresas a migrarem de outputs para outcomes.

No nível mais alto, mudar para o modelo de produto significa mudar de outputs para outcomes.

Conceitualmente, isso é muito simples e o valor é intuitivamente claro para a maioria das pessoas, mas na prática, isso é difícil.

Temos falado e escrito sobre a transição para outcomes em todos os nossos livros há muitos anos.

A boa notícia é que muitas outras pessoas perceberam que apenas entregar funcionalidades que não ajudam de fato os clientes, ou não ajudam o negócio, não é muito significativo. E hoje, muitos times e empresas fortes mudaram com sucesso seu foco para outcomes.

Mas para muitas empresas, a mudança para outcomes rapidamente fica estagnada.

Neste artigo, gostaríamos de tentar abordar alguns dos erros e confusões mais comuns que surgem quando as organizações tentam mudar para outcomes.

Também discutiremos algumas das nuances importantes para aqueles que já pensaram sobre esses conceitos por algum tempo.

O Conceito de Outcomes

A ideia básica por trás de outcomes é fácil de explicar:

Todos sabemos que algumas das coisas que construímos fazem diferença, enquanto outras não. Essa diferença pode ser melhorar a vida de nossos clientes, melhorar a saúde do nosso negócio, ou até mesmo ajudar nossos times a trabalhar de forma mais efetiva.

Mudar de outputs para outcomes significa mudar nosso foco do que construímos (os outputs) para a diferença que queremos fazer (os outcomes).

Mas, como qualquer pessoa que já tentou mudar para outcomes pode confirmar, isso é muito mais fácil de falar do que de fazer.

Estruturando Outcomes

Quando falamos sobre um outcome, o estruturamos em torno de um problema a ser resolvido e as medidas de sucesso.

Especificamente, isso requer:

• Dar aos times problemas claros e significativos para resolver.

• Ajudar os times a definir como medirão se estão realmente resolvendo cada problema.

• Instrumentar o produto para que os times possam entender imediatamente se estão alcançando o outcome desejado (ou seja, resolvendo o problema) e fazer ajustes com base nos dados.

Embora essa estrutura possa parecer simples, muitas empresas enfrentam dificuldades, pois ela representa uma mudança significativa de comportamento e de cultura.

Erros Comuns ao Mudar para Outcomes

– Pensar Que Você Pode Mudar Para Outcomes Sem Mudar Para O Modelo De Produto

De longe, o problema mais comum é pensar que você pode fazer sua organização focar em outcomes sem realmente fazer o trabalho de mudar sua organização para o modelo de produto.

Isso é compreensível, já que outcomes são intuitivos e conceitualmente simples. À primeira vista, não é óbvio por que seria necessário fazer uma série de mudanças estruturais para viabilizar outcomes.

É exatamente isso que aconteceu com milhares de empresas que acharam que poderiam simplesmente adicionar a técnica de OKR por cima de seus processos existentes, baseados em output e esperar alguma mudança significativa. Esse erro é o que alimentou a reação negativa a OKR em tantas empresas.

Mas a técnica de OKR surgiu a partir do modelo de produto e depende dele.

A técnica de OKR é bastante simples se você já estabeleceu o modelo de produto como sua forma de trabalhar.

Mudar para o modelo de produto envolve mudanças significativas em como você decide quais problemas precisa resolver, como resolve esses problemas e como constrói, testa e faz o deploy de suas soluções. Mas perceba que cada aspecto da mudança para o modelo de produto existe para permitir que sua organização alcance outcomes.

Então, a coisa mais importante a entender é que mudar para outcomes é a consequência de mudar para o modelo de produto.

– Deixar Que Métricas Existentes Ditem os Problemas a Resolver

Frequentemente, vemos empresas se limitando aos outcomes que podem ser medidos por seus indicadores atuais. Para todo o resto, elas usam outputs.

No entanto, frequentemente descobrimos que alguns dos problemas mais urgentes de clientes ou de negócios ainda não estão adequadamente cobertos pelos KPIs existentes.

Líderes de produto fortes não deixam que métricas existentes ditem quais problemas resolver ou quais medidas de sucesso usar. Eles sabem que precisam focar nos problemas mais críticos, mesmo que isso exija criar novos indicadores ou fazer trabalho adicional de instrumentação.

Uma técnica simples é garantir que um problema claro e relevante seja definido antes de se comprometer com métricas específicas.

– Problemas Vagos ou Ambíguos

Empresas organizadas em times de funcionalidade geralmente estão cheias de metas vagas que nenhum executivo pode definir ou medir adequadamente (por exemplo, "fornecer plataformas integradas"). Quando tudo o que você mede é a conclusão do projeto, não importa se suas metas são vagas.

Já empresas que adotam o modelo de produto investem tempo antecipadamente para definir problemas claros. Isso garante que estão trabalhando nos problemas certos — e economiza muito tempo depois.

Aqui estão vários exemplos do que são problemas claros:

• Ajudar clientes a resolver problemas sem precisar nos contatar

• Aumentar o percentual de entregas feitas no dia seguinte

• Ajudar os pacientes a compartilhar dados com seus médicos de maneira simples e confiável

• Reduzir o custo para adquirir um novo cliente

• Reduzir os custos operacionais de atendimento

• Reduzir a taxa de cancelamento de assinantes

• Reduzir o tempo necessário para implantar um serviço novo ou atualizado em produção

• Conectar candidatos a vagas mais compatíveis com seu perfil

• Reduzir o tempo médio de atendimento em ligações ao suporte

• Reduzir o tempo para um usuário produzir seu primeiro relatório mensal

Note que os problemas existem em diferentes níveis de granularidade ou "altitude". Alguns problemas são mais específicos e podem ser abordados por um único time de produto, enquanto outros são mais amplos e precisam ser abordados por múltiplos times de produto colaborando estreitamente. E alguns envolvem colaboração próxima com outros na empresa além dos times de produto.

Problemas relacionados à otimização de métricas existentes geralmente são os mais fáceis de articular (por exemplo, aumentar a conversão na página de checkout). Em outros cenários, chegar a um problema claro pode ser bastante desafiador, mas frequentemente é onde estão as grandes oportunidades.

A maioria dos desafios de medição e alinhamento são, na verdade, desafios de clareza. Quando você tem uma definição clara do que está tentando alcançar, fica mais fácil medir o sucesso, criar alinhamento entre stakeholders e descobrir soluções eficazes. Alcançar outcomes requer clareza.

– Não Ter Uma Estratégia De Produto Intencional

Os exemplos acima são todos problemas potencialmente importantes para resolver, dependendo da estratégia de produto da empresa.

Mas, como discutimos muitas vezes antes, muitas empresas não têm uma estratégia de produto intencional ou explícita. Elas têm metas de negócio e têm roadmaps de ideias de produto que esperam gerar resultados positivos.

A estratégia de produto representa os dados, a lógica e as decisões que levam de nossas metas de negócio de alto nível aos problemas específicos a serem resolvidos e outcomes a serem alcançados pelos vários times de produto.

Quando algumas pessoas ouvem a palavra "outcomes", elas imediatamente pulam para definições de resultados de negócio de alto nível—receita e lucro sendo os principais exemplos.

Essas metas de alto nível são certamente exemplos de outcomes, mas são mais tipicamente o resultado final de muitos outcomes diferentes, em muitos níveis diferentes de granularidade, todos contribuindo para o resultado final.

Por exemplo, nossos clientes estão tendo suas necessidades atendidas com nossos produtos? Quanto tempo leva para vender nossos produtos? Quanto tempo leva para um cliente começar a receber o valor? Por quanto tempo nossos clientes continuam a usar nossos produtos? Todos esses são outcomes que podem contribuir com impacto real para resultados finais como receita e lucratividade.

Em vez de ver outcomes isoladamente, às vezes é mais fácil pensar neles como dominós, com cada peça ajudando a derrubar a próxima.

É aqui que a estratégia se torna essencial: uma estratégia de produto adequada ajuda a identificar os problemas mais críticos que precisam ser resolvidos para entregar os objetivos de negócio.

Outra dimensão importante ao escolher outcomes é se está ou não dentro da capacidade de um determinado time de produto impactar diretamente o outcome desejado.

Um time não se sentirá empoderado para criar uma solução eficaz e alcançar o outcome necessário se não tiver acesso ou capacidade para fazer as mudanças necessárias.

Eles também provavelmente não descobrirão uma solução que funcionará para o cliente e o negócio se não puderem medir se estão fazendo o impacto necessário.

– Medir As Coisas Erradas

Quando olhamos para as medidas de sucesso, estamos tentando definir como saberemos se realmente resolvemos o problema. Certamente, apenas lançar uma funcionalidade não é suficiente.

Algumas pessoas confundem outcomes com o conceito muito mais geral de KPIs (Key Performance Indicators ou Indicadores-Chave de Desempenho). KPIs são simplesmente métricas que medem algum aspecto de um produto ou negócio.

A maioria dos negócios tem centenas ou até milhares de KPIs relevantes, que ajudam os líderes a avaliar a saúde de um produto ou negócio. Enquanto outcomes são medidos com KPIs, a grande maioria dos KPIs não são medidas úteis de outcomes bem-sucedidos.

Cada KPI é um ponto de dados, e esse ponto de dados pode fornecer pistas ou informações de apoio, mas estamos procurando o KPI (ou KPIs) que são medidas verdadeiras de nossos outcomes desejados.

Como um exemplo simples, o medidor de gasolina e o tacômetro no painel de um carro (movido a gasolina) são KPIs, mas se o outcome que você se preocupa é melhorar a eficiência de combustível, esses KPIs não estão realmente medindo se você está resolvendo o problema (por exemplo, aumentando quilômetros por litro).

É por isso que queremos definir um problema claro para resolver antes de discutir as métricas. O objetivo é medir se estamos resolvendo o problema selecionado, mesmo que isso signifique definir novos KPIs que ainda não acompanhamos hoje.

Uma técnica útil para encontrar bons KPIs para medir outcome é pensar sobre as mudanças desejadas no comportamento do usuário (por exemplo, a porcentagem de nossos clientes fazendo compras no aplicativo).

Mas tenha em mente que muitos problemas importantes não necessariamente impactam o comportamento do usuário. Lembre-se também que problemas a serem resolvidos podem se referir a problemas do cliente e/ou problemas da nossa empresa.

– Negligenciar a Coleta de Dados

Outro item que se torna inegociável se você quer mudar para outcomes é a necessidade de instrumentar tudo o que lançamos (referido como telemetria) para que os times possam entender imediatamente se estão resolvendo o problema e fazer ajustes com base nos dados.

No entanto, muitas empresas ainda não estão coletando e analisando seus dados como precisam—focar em outputs permite que elas tratem analytics e relatórios como algo "desejável".

Além disso, como discutido acima, muitos times evitam adotar as medidas adequadas de sucesso simplesmente porque ainda não têm a instrumentação necessária.

Se você quer focar em outcomes, precisará se comprometer a melhorar continuamente a telemetria do seu produto, criando novos KPIs e coletando dados adicionais onde necessário para medir se você está resolvendo os problemas desejados.

Confusões Comuns Sobre Outcomes

– Outras Formas de Pensar Sobre Outcomes

Várias pessoas têm explorado os mecanismos e as consequências dessa mudança para outcomes, e conteúdo verdadeiramente útil tem sido escrito sobre o assunto.

Alguns dos nossos favoritos são os outputs vs outcomes vs impacto de Jeff Patton, e a distinção de Teresa Torres entre outcomes de produto e outcomes de negócio.

Frequentemente nos referimos aos outcomes abordados pelos times de produto como outcomes de produto, e eles se somam para contribuir com outcomes de negócio (ou "resultados de negócio").

Outra maneira de pensar sobre isso é distinguir entre outcomes (a diferença que fazemos ao resolver problemas importantes) e impacto (os resultados de negócio de alto nível que esses outcomes ajudam a alcançar).

Essas distinções conceituais e simplificações podem ajudar as pessoas a se sentirem mais confortáveis com seu papel na mudança para outcomes.

Mas também é importante perceber que queremos encorajar os times de produto a abraçar trabalhos fora de sua área direta, para entender o problema e o que podem e devem fazer para resolvê-lo.

Por exemplo, para entender o que será necessário para resolver um problema que está aparecendo durante o processo de vendas, não é incomum que um gerente de produto passe tempo com vendas, indo a reuniões com clientes, observando as interações, para ver onde o problema pode estar.

– Inputs vs Outputs

A Amazon é um dos melhores exemplos do modelo de produto, mas internamente eles usam alguma linguagem em torno do termo "output" que pode causar confusão quando pessoas da Amazon usam essa linguagem externamente.

A Amazon enfatiza a importância de focar nos inputs, não nos outputs.

Isso significa focar nas "métricas de input" (por exemplo, seleção, preço e conveniência) que influenciarão as "métricas de output" (por exemplo, pedidos, receita e lucro).

Quando a Amazon enfatiza a necessidade de "gerenciar os inputs, não os outputs", isso significa focar em gerenciar as causas, não os efeitos.

Este também é um ponto importante e se relaciona diretamente com a estratégia de produto, mas não deve ser confundido com a definição de outputs, que são as coisas que construímos.

– Manter A Operação Funcionando

É fundamental sempre lembrar que nem tudo precisa ser um problema a ser resolvido com um outcome.

Sempre haverá uma lista de itens de “manter a operação funcionando” — tarefas geralmente menores, mas necessárias para que nossos parceiros de negócio consigam manter tudo rodando.

Resumo

Não há dúvida de que entregar outcomes é muito mais difícil do que entregar output. Requer novas competências, novas habilidades e uma abordagem diferente para definir e atribuir trabalho.

Há vários outros itens relacionados a outcomes além do que estamos destacando aqui. O livro EMPODERADO: Pessoas Comuns, Produtos Extraordinários fornece uma explicação muito mais abrangente com exemplos detalhados e estudos de caso.

Mas para aqueles times de produto que estão seriamente comprometidos em entregar valor real, resolver o problema subjacente para nossos clientes ou nosso negócio, e entregar os resultados de negócio necessários é a única medida real de sucesso.

Conecte-se comigo

• Está conhecendo a newsletter agora? Assine gratuitamente

• Me siga no LinkedIn para mais insights

• Entre em contato para organizar um workshop ou uma palestra na sua empresa

Este post também está disponível em inglês.

Assine agora

No último anterior, vimos que a regra do 80/20 pode ajudar sua empresa a não perder o foco construindo barracas de limonada na frente da mina de ouro.

Aposto que você tem algumas minas de ouro bem na sua frente—um pequeno número de coisas que vão gerar a maior parte dos outcomes desejados.

As perguntas 80/20 ("Qual é o 80/20?" e "Quais são os fatores críticos de sucesso?") podem estimular ótimas conversas e ajudar você a encontrar essas pepitas de ouro que passam despercebidas.

A maneira clássica de aplicar a regra do 80/20 é fazendo uma análise quantitativa.

Mas usar a regra 80/20 como uma técnica qualitativa pode ser ainda mais poderoso, pois pode ajudar a deixar a estratégia mais clara, criando foco e alinhamento.

Vamos ver como você pode usar as duas opções na prática.

Como usar a regra 80/20 em uma análise quantitativa

Para um exemplo simples, imagine três times de produto tentando alcançar o mesmo outcome: reduzir a taxa de falhas (ou crashes) de seus aplicativos1.

Time #1

O time #1 decide andar rápido e começa a trabalhar em projetos que acreditam que reduzirão as falhas.

O time rastreia o número total de falhas, mas eles têm apenas uma compreensão superficial das causas. Quando a taxa de falhas flutua, eles têm dificuldade em explicar o porquê, pois não têm dados de apoio.

Time #2

O time #2 identifica 15 bugs "P1" causando falhas. Eles estabelecem um Key Result para reduzir esses bugs para zero, mas têm dificuldade em escolher qual corrigir primeiro.

Eles começam trabalhando nos 15 bugs em paralelo, mas isso faz com que eles andem muito devagar. Então, eles decidem corrigir os bugs mais fáceis primeiro, independentemente do seu impacto.

Time #3

O time #3 começa se perguntando sobre as questões 80/20: "Qual é o 80/20 aqui? Quais são nossos fatores críticos de sucesso?"

Para responder a essas perguntas, o time usa um método quantitativo simples para analisar os dados:

• Listar todos os bugs causando falhas.

• Calcular a porcentagem do total de falhas geradas por cada bug.

• Ordenar os bugs do maior para o menor impacto.

• Criar um gráfico para visualizar os fatores críticos de sucesso e o elenco de apoio.

  (Para uma explicação completa e templates, busque por gráfico de Pareto ou análise de Pareto.)

O gráfico mostra claramente que apenas quatro bugs são responsáveis por 86% das falhas:

Em vez de se distrair como os outros times, o time #3 foca nesses quatro bugs—seus fatores críticos de sucesso—para garantir que farão um impacto real.

Discutiremos como aplicar a regra 80/20 como uma técnica qualitativa após este breve intervalo.

Mude de projetos para outcomes

Desenvolva os músculos e mindsets que você precisa para focar em outcomes e obter melhores resultados com OKR participando de um dos meus workshops.

Eu criei meus workshops para ajudar você a desaprender o modelo onde times estão sempre correndo atrás de múltiplos prazos conflitantes.

Em vez disso, vou te ajudar a mudar para um modelo que faz com que todos remem na mesma direção, focando nos outcomes que realmente importam.

Entre em contato comigo para organizar um workshop interno ou palestra para o seu time.

Usando a regra 80/20 para tornar o implícito explícito

Minas de ouro geralmente permanecem implícitas. Elas podem estar presas na cabeça de alguém, enterradas sob uma pilha de "prioridades", ou perdidas na linguagem complicada usada para comunicar a estratégia.

Usar a regra 80/20 como técnica qualitativa pode ajudar a tornar o implícito explícito.

As perguntas 80/20 podem oferecer uma nova forma de pensar sobre prioridades e dar às pessoas uma linguagem clara para separar o que é crítico do que é meramente útil.

Um cenário comum é quando uma pessoa já identificou as minas de ouro, mas teve dificuldade em comunicá-las aos outros.

Me lembro de quando fiz as perguntas do 80/20 para um grupo de uma empresa de tecnologia. O diretor de engenharia respondeu na hora: "Os fatores críticos de sucesso para nossos pipelines de desenvolvimento são velocidade, segurança e facilidade de uso."

No entanto, os membros do time se olharam como se fosse a primeira vez que ouviam isso.

No fundo, eles provavelmente já sabiam desses fatores. Mas ninguém havia deixado eles explícitos, de maneira tão clara e simples.

As minas de ouro estavam escondidas sob uma pilha de “prioridades.”

Outro cenário comum é quando um grupo precisa trabalhar junto para deixar as minas de ouro explícitas. Usar as perguntas 80/20 combinadas com ferramentas visuais pode ser bastante poderoso.

Como um exemplo simplificado, eu estava trabalhando com uma empresa de serviços financeiros quando um time de produto pediu ajuda:

- Estamos com dificuldades para decidir em quais outcomes nosso time deve focar.

No final, queremos aumentar a receita, mas dependemos do time de vendas para isso. Poderíamos compartilhar a meta de receita com vendas, mas seria difícil saber se nosso time fez diferença.

- A regra do 80/20 pode ajudá-lo a identificar onde vocês devem focar.

Qual é o 80/20 aqui? Quais são os fatores críticos de sucesso para aumentar a receita do seu produto?

- Sabemos que a satisfação do cliente com o produto é crítica. O desempenho do time de vendas também é essencial, mas temos pouca influência sobre ele.

- Ok, então vamos nos aprofundar um pouco mais. Qual é o 80/20 para melhorar a satisfação do cliente? Quais são os fatores críticos de sucesso?

Após algum debate e algumas tentativas, o time chegou a uma conclusão.

- Os fatores críticos de sucesso para melhorar a satisfação do cliente são a facilidade de contratação, o tempo para concluir cada transação e a facilidade de gerir o contrato no pós-venda.

- Ótimo, vamos escrever cada um desses fatores em post-its para nos ajudar a visualizá-los:

O time então trabalhou para identificar as melhores métricas para medir cada um desses três outcomes que representavam suas "minas de ouro".

O diagrama acima é um exemplo de um mapa de outcomes (ou árvore de outcomes), uma ferramenta poderosa para deixar a estratégia mais clara e torná-la tangível para todos.

Em um artigo futuro, discutiremos como você pode usar o mapa de outcomes para ajudar as pessoas a entenderem como elas contribuem para o sucesso de sua empresa.

Mas antes isso, precisamos entender por que tantas pessoas deixam de aplicar a regra 80/20—não é porque são burras ou preguiçosas.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Compartilhar

Assine agora

As empresas costumam se distrair, deixando de focar no que é crítico. Elas acabam fazendo coisas que as afastam do que realmente querem alcançar.

A Netflix tem uma expressão criativa para descrever essas distrações incômodas que atrapalham alcançar o que realmente importa: a barraquinha de limonada na frente da mina de ouro.

Como explica Greg Peters, co-CEO da Netflix:

Nós temos expressão que chamamos de a barraquinha de limonada na frente da mina de ouro, ou seja não se distraia construindo barraquinhas de limonada na frente da mina de ouro—você quer encontrar as minas de ouro e é nisso que você realmente quer trabalhar.

O PayPal também teve que lidar com distrações, como explica o ex-executivo Matt Lerner:

No PayPal, todo o crescimento inicial veio de indicações e do eBay. A próxima onda foi de desenvolvedores, indicações de carrinho de compras e vendas diretas para algumas verticais. Foi isso—todo o crescimento do PayPal veio de 5 coisas.

Fizemos toneladas de outras coisas. Toneladas! A maioria foi uma distração enorme e cara.

A analogia da Netflix também se aplica aos times, já que eles podem se distrair construindo barraquinhas de limonada na frente suas pequenas jazidas de ouro.

Uma das razões pelas quais executivos e times se distraem é que a palavra prioridade perdeu todo o significado.

Tudo virou prioridade

Eu notei um padrão comum: as pessoas concordam que estão trabalhando em muitas coisas ao mesmo tempo, mas ficam presas decidindo onde focar.

Para elas, tudo no que estão trabalhando é uma "prioridade".

Com o tempo, percebi que a palavra prioridade havia perdido todo o significado.

As listas de prioridades se tornaram as “gavetas da bagunça” do mundo dos negócios. É onde as pessoas juntam o que é crítico com o que pode ser útil algum dia, em uma mistura caótica de dezenas de itens.

Tudo virou prioridade, então nada é.

Sem uma linguagem compartilhada para separar o que é crítico do que é meramente útil, as pessoas se distraem.

Alguns tentam numerar as prioridades (P0, P1, P2...), mas isso é como dizer que Usain Bolt e meu tio Bosco “são corredores.” Embora tecnicamente correto, esconde a enorme diferença no impacto de cada um.

Então, qual é a alternativa? Como você pode encontrar as minas de ouro e evitar se distrair?

Você pode estar pensando: "Encontrar minas de ouro e evitar distrações não é trabalho da estratégia?" E isso está certo.

Mas estratégia é difícil. Muitas empresas têm dificuldade ou não têm uma estratégia real.

E mesmo quando as empresas têm uma "estratégia", há outro problema: as pessoas costumam não ver as minas de ouro bem debaixo do nariz. Ou pior, elas encontram as minas de ouro, mas têm dificuldade em comunicá-las claramente para os times.

Há um princípio simples e poderoso que pode te ajudar a identificar o que realmente importa e focar.

Você pode ter ouvido falar desse conceito, mas aposto que não está aplicando ele de verdade.

A regra 80/20

As histórias da Netflix e do PayPal são ótimos exemplos de um conceito crucial que pode ajudar a responder a essas perguntas: o princípio de Pareto, também conhecido como regra 80/20.

O princípio, nomeado em homenagem a Vilfredo Pareto, sugere que em muitas situações 80% dos efeitos vêm de 20% das causas.

Em bom português, isso significa que muitas vezes 80% dos seus resultados vêm de 20% dos seus esforços.

No início dos anos 2000, o CEO da Microsoft, Steve Ballmer, escreveu um e-mail para os clientes destacando um caso claro do princípio de Pareto em ação:

Cerca de 20% dos bugs causam 80% de todos os erros e - isso me surpreendeu - 1% dos bugs causou metade de todos os erros.

Para ser claro, a regra 80/20 é apenas uma maneira simplificada de expressar o princípio de Pareto. A proporção exata não precisa ser 80/20.

Por exemplo, o app de idiomas Duolingo obtém 80% de sua receita anual de US$ 530 milhões de 9% de seus usuários.

Alguns podem argumentar que todo mundo conhece o princípio de Pareto ou até que ele é "óbvio".

Mas se sua empresa estivesse realmente aplicando a regra 80/20, você não estaria lidando com dezenas de prioridades.

Mude de projetos para outcomes

Desenvolva os músculos e mindsets que você precisa para focar em outcomes e obter melhores resultados com OKR participando de um dos meus workshops.

Eu criei meus workshops para ajudar você a desaprender o modelo onde times estão sempre correndo atrás de múltiplos prazos conflitantes.

Em vez disso, vou te ajudar a mudar para um modelo que faz com que todos remem na mesma direção, focando nos outcomes que realmente importam.

Entre em contato comigo para organizar um workshop interno ou palestra para o seu time.

Separando o que é crítico do que é meramente útil

A regra 80/20 pode te ajudar a evitar a armadilha de enterrar suas minas de ouro sob uma pilha de "prioridades".

Mas a verdade é que o princípio de Pareto pode parecer chato ou abstrato, especialmente para aqueles que não se consideram "boas com métricas."

Para que a regra 80/20 seja adotada, temos que torná-la mais memorável, combinando-a com a analogia da barraquinha de limonada e acrescentando outros termos marcantes.

Dessa forma, podemos dar às pessoas um modelo simples para separar o que é crítico do que é meramente útil, pensando em duas categorias:

• "Minas de ouro" ou fatores críticos de sucesso são os poucos elementos que vão gerar a maior parte do outcome e vão fazer a diferença.

  Esses são os personagens principais da sua estratégia e precisam ser tratados como tal.

  Eles também são chamados de "alavancas" ou "drivers", mas essas palavras são usadas de forma tão indiscriminada que raramente ajudam.

• "Barraquinhas de limonada" ou elenco de apoio são os muitos elementos restantes que respondem por uma pequena parte do resultado.

  Isso inclui todas as boas ideias que desempenham papéis secundários na sua estratégia. Elas podem ser úteis, mas não são críticas.

"Qual é o 80/20?"

Quando as pessoas estão com dificuldade para decidir onde focar, aprendi que é útil explicar esse modelo e depois perguntar: "Qual é o 80/20?"

Essa pergunta pode provocar ótimas conversas, ajudando a criar foco e alinhamento.

Não existe uma única expressão que funcione com todo mundo. Por isso, esse modelo permite que você teste versões diferentes da pergunta: "Quais são os fatores críticos de sucesso?" ou "Qual é a mina de ouro?"

Com engenheiros, simplesmente mencionar Pareto pode ser suficiente.

No próximo artigo, discutiremos como usar essa pergunta e colocar a regra 80/20 em prática, seguindo três passos críticos:

• Encontrar as minas de ouro: Identifique os fatores críticos de sucesso que provavelmente impulsionarão a maior parte do resultado. Alguns deles podem estar escondidos bem na sua frente.

• Ajudar os times a evitar distrações: Ajude-os a focar, deixando as minas de ouro cristalinas, em vez de juntá-las com outras "prioridades".

• Fazer renúncias: Aprenda a deixar de lado todas as boas ideias que não são críticas e diga não às barraquinhas de limonada.

Aprofundaremos como você pode seguir esses passos para se tornar mais focado. Também discutiremos os motivos pelos quais as pessoas geralmente falham em fazer isso.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Compartilhar

Você pode encontrar os dois primeiros artigos sobre foco aqui e aqui. Este post também está disponível em inglês.

Assine agora

"Que lições você aprendeu trabalhando com Steve Jobs?" o jornalista perguntou a Jony Ive, ex-Head de Design da Apple.

Ive deu uma resposta instigante:

Steve era a pessoa mais focada que eu já conheci.

E a questão do foco é que não é algo que você almeja ou que você simplesmente decide na segunda-feira, "sabe, eu vou ser focado."

Foco significa perguntar a cada minuto, "Por que estamos falando sobre isso? É nisso que estamos trabalhando."

Uma das coisas que Steve dizia - porque acho que ele estava preocupado que eu não estava focado - era: "Para quantas coisas você disse não?"

E, honestamente, eu teria essas coisas sacrificiais, e eu diria: "oh, eu disse não para isso, e não para aquilo." Mas ele sabia que eu não estava nem um pouco interessado em fazer aquelas coisas de qualquer maneira. Então não havia um sacrifício real.

O que foco significa é dizer não a algo que você acredita com cada fibra do seu corpo ser uma ideia fenomenal.

Você acorda pensando nisso, mas diz não porque está focando em outra coisa.

Mude de projetos para outcomes

Desenvolva os músculos e mindsets que você precisa para focar em outcomes e obter melhores resultados com OKR participando de um dos meus workshops.

Eu criei meus workshops para ajudar você a desaprender o modelo onde times estão sempre correndo atrás de múltiplos prazos conflitantes.

Em vez disso, vou te ajudar a mudar para um modelo que faz com que todos remem na mesma direção, focando nos outcomes que realmente importam.

Entre em contato comigo para organizar um workshop interno ou palestra para o seu time.

Aprendendo a fazer renúncias

Como Ive explicou, foco vai muito além de simplesmente "priorizar" ou dizer não a coisas pelas quais você não estava tão interessado de qualquer forma. Foco real requer fazer escolhas, até mesmo recusar ideias incríveis.

Para realmente focar, temos que aprender a fazer renúncias. Temos que aprender a abrir mão até mesmo das ideias que mais valorizamos.

A história da Apple fornece um ótimo exemplo.

Para focar no iPhone, os líderes da Apple tiveram que fazer renúncias, e produtos como o MacBook Pro e o MacBook Air passaram anos sem serem atualizados.

Imagine o quão difícil foi essa decisão. A Apple foi construída em cima do Mac, e o produto tem uma legião de fãs entre seus clientes.

Tenho certeza de que Jobs, Ive e muitos outros achavam que lançar novos MacBooks era uma ideia fenomenal. Mas ao dizer não, a empresa pôde focar no iPhone, o produto mais bem-sucedido de todos os tempos.

Renunciando a velhas premissas

Às vezes, dizer não significa fazer escolhas diferentes e renunciar a velhas premissas.

Quando a Apple lançou o primeiro iPhone, Nokia e Blackberry lideravam o mercado fazendo telefones com base em algumas crenças fundamentais. Os telefones precisavam de teclados físicos, tinham que saltar ilesos se caíssem no concreto e a bateria tinha que durar uma semana.

Como Benedict Evans aponta, ao rejeitar essas premissas, a Apple criou um produto tão atraente que as pessoas não hesitaram em fazer a mudança:

Aqui estamos vários anos depois e a bateria do iPhone dura um dia e se você o derrubar, ele quebra. Mas vale a pena pela experiência.

Criando uma lista de renúncias

Criar uma estratégia real envolve articular claramente no que você vai focar. Mas também envolve definir uma lista de renúncias que comunica claramente todas as ideias incríveis às quais você está dizendo não.

Mas as empresas muitas vezes varrem prioridades para debaixo do tapete, escondendo elas de várias maneiras.

Às vezes, as pessoas tentam intencionalmente esconder prioridades definindo um pequeno número de OKRs enquanto mantêm múltiplos projetos rodando "por fora". Com isso, elas criam a ilusão de foco sem ter que dizer não.

No entanto, também existem prioridades que estão tão escondidas que as pessoas nem percebem que elas existem.

KPIs são uma fonte comum para essas prioridades implícitas. Os times costumam definir dezenas deles e depois tentam mover todos ao mesmo tempo, transformando cada KPI em outra "prioridade".

Pessoas que varrem prioridades para debaixo do tapete estão apenas se enganando.

Elas podem dizer que estão focadas, mas ainda estão bebendo de muitas garrafas em paralelo e se perguntando por que não conseguem se mover mais rápido.

Para criar uma lista de renúncias real, você tem que cobrir as duas caixas de investimentos: todos os outcomes, métricas e projetos.

Como você pode saber se está focando de verdade?

Existe um teste simples para saber se você está realmente focando ou não. Como meu personal costumava dizer: "Se está fácil, está errado".

Se você está falando sobre uma ideia realmente fenomenal, significa que há uma necessidade real para ela. Rejeitá-la será doloroso.

Clientes e stakeholders lutarão pela ideia, assim como as pessoas que estão trabalhando naquele produto ou iniciativa.

Os fãs do Mac odiaram os atrasos no lançamento de novos modelos. Alguns até acusaram a Apple de abandonar o produto em favor do iPhone. Aposto que o time do Mac também não gostou nada disso.

Se você está dizendo não a uma ideia fenomenal, alguém vai resistir. Se dizer não parece fácil, você não está focando o suficiente.

"Eu não posso dizer não porque não controlo todas as minhas prioridades"

Às vezes as pessoas argumentam que não conseguem dizer não pois muitas das suas prioridades são definidas por outros: executivos, stakeholders, clientes ou órgãos regulatórios.

Mas existem prioridades que estão sob seu controle, e você deve começar tentando renunciar a algumas delas. Mesmo isso pode causar um grande impacto.

Você não precisa dizer não para sempre

Às vezes, dizer não é uma decisão definitiva. Por exemplo, quando uma empresa para de vender um determinado produto.

Mas você também pode dizer um não temporário, como a Apple fez quando decidiu adiar os novos modelos de Macbooks.

O planejamento trimestral torna mais fácil dizer não. Afinal, você não está dizendo não para sempre, apenas para o próximo trimestre.

E ao trabalhar em suas prioridades sequencialmente em vez de em paralelo, você se moverá mais rápido.

A OpenAI, criadora do ChatGPT, usou um visual claro para ilustrar sua decisão de trabalhar sequencialmente, focando em reduzir o preço (price) antes de melhorar a velocidade (speed).

Como explicou o CEO Sam Altman, eles tiveram que escolher um ou outro, então focaram no preço primeiro, com planos de trabalhar na velocidade em seguida.

Trabalhar sequencialmente pode ser uma ferramenta poderosa e relativamente fácil de implementar.

Para quantas coisas você disse não?

Agora é hora de se fazer a mesma pergunta que Steve Jobs fez a Jony Ive: para quantas coisas você disse não?

E lembre-se: não basta rejeitar ideias que outros amam, mas você não. Para focar, você tem que dizer não a ideias que você pessoalmente acredita serem fenomenais.

A seguir: como escolher onde focar?

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Compartilhar

Você pode encontrar a parte 1 deste artigo aqui. Este post também está disponível em Inglês.

Assine agora

A crença de que "mais é melhor" na hora de definir prioridades está sabotando a capacidade da sua organização de focar. E está custando muito mais do que você imagina.

Essa visão de mundo sugere que as empresas podem alcançar mais resultados em menos tempo trabalhando em dezenas de prioridades simultaneamente, ao invés de focar.

Pessoas com o mindset "mais é melhor" acreditam que "priorizar" significa adicionar coisas a uma lista já longa de prioridades.

Como Rich Mironov aponta, eles querem "priorizar para incluir":

"Estes itens são realmente importantes (para o meu departamento ou divisão), então precisamos incluir todos eles." (...)

Priorizar para incluir é sobre obter acordo para fazer mais, especialmente o que está na minha lista.

Como podemos ajudar as pessoas a entender a importância de desaprender essa forma de pensar, especialmente a liderança sênior?

Por anos, tenho usado um exercício poderoso para desafiar esse mindset e ilustrar o impacto do foco - usando nada mais do que algumas garrafas de whisky.

Aprendendo foco com garrafas de whisky

O exercício das 12 garrafas de whisky foi criado pelo meu amigo Paulo Caroli, consultor principal da ThoughtWorks e amante de whisky.

Um dia, enquanto se servia de uma dose de Macallan 12 anos, Caroli se perguntou: "Quanto tempo levo, em média, para beber uma garrafa de whisky?"

Gostaria da sua ajuda com essa questão. Aqui estão os detalhes:

O armário de whisky de Caroli tem espaço para 12 garrafas de whisky e ele sempre o mantém cheio.

Sempre que termina uma garrafa, ele a remove do bar, abre uma nova e a adiciona ao bar. A cada ano, ele bebe seis garrafas de whisky.

Agora, tente este rápido exercício:

Se o armário comporta 12 garrafas de whisky e Caroli bebe 6 garrafas por ano, quanto tempo ele leva, em média, para beber 1 garrafa?

Por favor, selecione uma opção antes de continuar:

A. 6 meses

B. 3 meses

C. 2 meses

D. 1 ano

E. 2 anos

Discutiremos as respostas após este breve intervalo.

Desenvolva os músculos e mindsets para focar em outcomes e ter resultados com OKR

Mude de um modelo focado em cumprir datas para um focado em alcançar outcomes. Entre em contato para organizar um workshop in-company ou uma palestra para seu time.

Se você é como a maioria das pessoas, escolheu a opção C, dois meses.

Como Caroli bebe 6 garrafas por ano e um ano tem 12 meses, parece lógico que ele levaria 2 meses para terminar cada garrafa (12 meses ÷ 6 garrafas = 2 meses por garrafa).

Essa seria a resposta correta, desde que ele continuasse bebendo de somente uma garrafa.

Mas e se ele beber de garrafas diferentes a cada dose em vez de focar em uma só?

Bebendo das 12 garrafas em paralelo, levaria dois anos para terminar cada garrafa, em média.

Trabalhando sequencialmente vs em paralelo

Imagine que Caroli tivesse um irmão que bebesse de todas as garrafas em paralelo enquanto Caroli bebia sequencialmente, terminando uma garrafa antes de passar para a próxima.

Em média, Caroli terminaria uma garrafa a cada dois meses, enquanto seu irmão ainda estaria com várias garrafas parcialmente bebidas. Quando o irmão terminasse sua primeira garrafa, Caroli teria terminado 12:

Você já viu uma dessas empresas onde as pessoas estão sempre reclamando que "tudo aqui demora demais"?

Onde fazer uma atualização simples no site pode levar meses e desenvolver uma funcionalidade do produto pode se arrastar por um ano?

A resposta pode ser bem simples: a empresa está bebendo de 12 garrafas ao mesmo tempo.

A falta de foco tem custos reais

Muitas organizações não enxergam o alto custo da falta de foco, enquanto se esforçam para cortar despesas em outros lugares.

O custo de trabalhar em várias prioridades simultaneamente pode ser demonstrado por mais do que apenas exemplos visuais.

O professor do MIT John Little provou matematicamente o que é conhecido como Lei de Little: em um sistema estável, há uma relação linear entre o número de itens no sistema e o tempo médio que cada item passa no sistema (o lead time).

Ou seja, quanto mais garrafas você bebe em paralelo, mais tempo levará para terminar cada uma.

Este é um exemplo do que os economistas chamam de custo de oportunidade. Para cada hora que você gasta trabalhando em uma "prioridade" que é útil, mas não crítica, você renuncia a uma hora de trabalho no que criará impacto real.

De "mais é melhor" para "comece menos, termine mais"

A Lei de Little e o exercício das 12 garrafas mostram o impacto de mudar nossos mindsets de "mais é melhor" para "comece menos, termine mais"1.

Começar menos e terminar mais significa que se você limitar a quantidade de trabalho que está em andamento, também conhecido como WIP (do inglês 'work in progress'), você vai melhorar seu throughput2.

Limitar o WIP é como restringir o número de garrafas de whisky que você bebe em paralelo. Ao limitar o número de garrafas parcialmente consumidas, seu WIP, você terminará cada uma mais rápido.

A importância de limitar o WIP é conhecida nos meios de manufatura enxuta e tecnologia há muitos anos. Na verdade, times de produto mais avançados muitas vezes limitam o número de itens ou histórias de usuário3 em que trabalham ao mesmo tempo.

Mas poucas organizações gerenciam o WIP no nível da empresa, distribuindo prioridades como balas no Halloween.

No entanto, líderes seniores podem desaprender esse mindset, como o executivo que teve um estalo em um dos meus workshops:

Talvez em vez de ter 20 projetos que se movem devagar, devêssemos ter 3 que se movem rápido.

"Temos múltiplos times, então podemos trabalhar em múltiplas prioridades"

Algumas pessoas argumentam que sua empresa pode trabalhar muitas prioridades ao mesmo tempo porque têm vários times. "Dedicaremos alguns times para cada prioridade", eles dizem. "Assim ninguém ficará sobrecarregado".

Existem duas grandes falhas nesse argumento.

Primeiro, espalhar uma fina camada de investimentos sobre várias prioridades significa que você nunca terá recursos suficientes para fazer a diferença em nada. A abordagem da “manteiga de amendoim” não é uma estratégia.

Em segundo lugar, na vida real, os times têm dependências. Para progredir, eles precisam que outras pessoas façam alguma coisa—seja construir algo novo, fornecer input ou tomar uma decisão.

Dependências somadas com múltiplas prioridades significam que alguém acabará bebendo de muitas garrafas em paralelo.

Pode ser um time de plataforma atendendo outros times de produto4. Ou pode ser uma executiva, stakeholder ou função central que precisa aprovar o trabalho antes que ele possa continuar.

Em ambos os casos, muitas pessoas ficarão esperando até que os times e stakeholders sobrecarregados esvaziem lentamente todas essas garrafas.

Como a maioria das organizações tem dependências demais, as garrafas de whisky se multiplicam por todo lado. Logo, tudo começa a andar a passos de tartaruga.

Focar e limitar o WIP é uma jornada, mas você pode avançar um passo de cada vez. Por um lado, você precisa trabalhar para eliminar dependências em vez de gerenciá-las, como a Amazon fez.

E como veremos no próximo artigo, você também tem que construir os músculos para dizer não—mesmo para idéias que você acha fenomenais.

Enquanto isso, pergunte a si mesmo: de quantas garrafas de whisky você e seu time estão bebendo em paralelo?

Links:

• Site do Paulo Caroli.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Compartilhar

Este post também está disponível em Inglês.

Assine agora

Eu conversei com centenas de empresas sobre os motivos pelos quais elas estavam adotando OKR. A falta de foco sempre está no topo da lista.

Os colaboradores se sentem puxados em várias direções por uma lista interminável de metas, projetos e KPIs. Tudo é prioridade, então nada é.

Por que é tão difícil focar?

Focar e ser outcome-driven têm muito em comum. Existem causas estruturais e mais profundas que tornam ambos incrivelmente desafiadores.

Assim como ser outcome-driven, focar de verdade nunca é fácil. Músculos fracos e mindsets errados deixam tudo mais difícil.

É impossível focar sem as habilidades e capacidades organizacionais adequadas, da mesma forma que não consegue ser outcome-driven sem elas.

E focar é quase impossível se suas crenças ou processos fazem você definir múltiplas prioridades. É semelhante a como o mindset sabe-tudo e práticas como orçamentos baseados em projetos fazem as pessoas focarem em cumprir datas em vez de alcançar outcomes.

Para realmente focar, precisamos desenvolver novos músculos e mindsets. Assim como precisamos fazer para nos tornarmos outcome-driven.

Precisamos desenvolver os músculos para identificar o pequeno número de metas que criarão impacto real e para dizer não às várias ótimas ideias que podem ser úteis, mas não são críticas.

Também precisamos desaprender mindsets antigos e abandonar qualquer prática que nos leve a distrações e à difusão de nossos esforços.

Primeiro, vamos explorar alguns dos mindsets que podem prejudicar nossa capacidade de focar.

Priorizar não é focar

Muitas pessoas acreditam que tudo o que precisam fazer para focar é "priorizar", o que geralmente significa criar uma extensa lista de dezenas de "prioridades".

Mas quando cada time adota essa abordagem, a organização rapidamente acaba com centenas de iniciativas concorrentes, espalhando investimentos em várias áreas.

No início dos anos 2000, o executivo de tecnologia Brad Garlinghouse alertou sobre uma situação semelhante dentro do Yahoo:

Nós não temos uma visão focada e coesa para nossa empresa. Queremos fazer tudo e ser tudo - para todos. (...)

Ouvi nossa estratégia descrita como espalhar manteiga de amendoim nas inúmeras oportunidades do mundo online. O resultado: uma fina camada de investimento espalhada por tudo o que fazemos e, portanto, não focamos em nada em particular.

Eu odeio manteiga de amendoim. Todos nós deveríamos odiar.

O fato de muitos leitores terem que pesquisar no Google o que é "Yahoo" mostra as consequências de espalhar demais os investimentos de uma empresa.

Focar é algo completamente diferente. Focar significa concentrar energia e recursos em um pequeno número de coisas decisivas que gerarão a maior parte dos resultados.

Uma estratégia não é uma lista de prioridades

Outra crença que torna o foco mais difícil é a de que formular estratégia é apenas fazer uma lista de metas ou prioridades.

Mas como explica Roger Martin, estratégia envolve fazer escolhas que se encaixam e reforçam umas as outras:

[Estratégia] não é uma lista de coisas que tornam uma empresa melhor. É um conjunto integrado de escolhas que, em combinação, cria uma maneira de vencer - onde a empresa escolheu atuar.

Espalhar recursos por uma lista de metas desconexas não é uma estratégia, mesmo que cada uma dessas metas tenha valor.

Muitas vezes sonhamos em ter uma ou duas metas centrais em torno das quais todos na empresa possam se unir. Mas a realidade é que as organizações geralmente têm ambições conflitantes que não podem ser todas alcançadas ao mesmo tempo.

Como afirma Richard Rumelt:

A maioria das pessoas e organizações tem "um pacote de ambições". Ou seja, elas têm múltiplas intenções, visões do futuro e coisas que gostariam de ver ou alcançar. Algumas coisas neste "pacote" entram em conflito umas com as outras - nem todas podem ser alcançadas juntas.

Uma vez trabalhei com uma empresa que definiu duas metas aparentemente razoáveis: mudar para o modelo de produto e fazer grandes reduções de custos em suas funções corporativas.

Mas essas metas acabaram entrando em conflito uma com a outra. O CTO estava tentando contratar centenas de engenheiros para apoiar a transformação para produto, enquanto o RH estava tentando reduzir drasticamente os investimentos em recrutamento para atingir as metas de redução de custos.

Uma estratégia real tem que fornecer orientações claras sobre como fazer essas inevitáveis escolhas difíceis.

Por exemplo, uma estratégia clara poderia envolver a redução dos custos de recrutamento para outras funções, mantendo ou até aumentando o investimento por engenheiro contratado. Essa é a diferença entre focar no que é realmente importante e apenas definir prioridades.

A abordagem comunista para redução de custos1 - dizer que todos têm que cortar custos em 20% - é um sinal claro da falta de estratégia. Ela espalha os cortes como se estivesse passando manteiga de amendoim, de forma uniforme e sem critério.

Foco não é "justo"

Outra confusão comum é acreditar que as organizações têm que dividir a capacidade dos times "de forma justa" entre diferentes stakeholders. Elas acabam espalhando uma fina camada de investimento sobre várias prioridades sem focar em nada em particular.

No livro EMPODERADO, Marty Cagan compartilhou um exemplo claro de uma empresa que estava priorizando sem focar:

Alguns anos atrás, um dos executivos do serviço de música Pandora compartilhou o "Processo de Priorização da Pandora" - o processo da empresa para decidir no que trabalhar e construir.

O processo envolvia deixar os stakeholders "comprarem" as funcionalidades que queriam dos times de funcionalidades até que seu orçamento acabasse.

(...) Reconheci imediatamente a completa e total ausência de estratégia de produto e especialmente foco. Não é uma má estratégia de produto - literalmente não há estratégia de produto.

Após anos de declínio no número de usuários e dificuldades para se tornar lucrativa, a Pandora acabou sendo vendida por pouco mais da metade do preço de seu IPO.

Foco e estratégia não são justos. Embora você precise equilibrar as necessidades de diferentes stakeholders, eles não são igualmente importantes. Você precisa mostrar empatia e franqueza, sem evitar as escolhas difíceis mas necessárias.

Para focar, precisamos desaprender

Para realmente focar, precisamos abandonar mindsets e práticas que nos fazem espalhar nossos recursos como manteiga de amendoim em uma fatia de pão.

Precisamos abandonar a crença de que fazer longas listas de "prioridades" é o mesmo que focar. Precisamos abrir mão da noção de ser "justo" e distribuir nossos investimentos entre diferentes stakeholders. E precisamos desaprender a ideia de que uma estratégia é simplesmente uma lista de metas.

Próximo: os músculos e mindsets do foco

Na próxima semana estarei de volta com a parte 2 deste artigo, abordando os músculos e mindsets do foco.

Enquanto isso, sinta-se à vontade para comentar abaixo ou me enviar um e-mail.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Assine agora

Temos falado sobre a necessidade de desenvolver seus músculos de outcome há algum tempo. Hoje, veremos como você e seu time podem fortalecer esses músculos com um exercício que uso em meus workshops.

Este post também está disponível em Inglês.

Se esta é a primeira vez que você lê minha newsletter, por favor, leia este artigo e este outro antes de continuar. O post de hoje se baseia em conceitos discutidos neles.

Assine agora

Como vimos, devemos começar com o fim em mente. Antes de pensarmos em projetos, precisamos definir claramente os outcomes desejados.

Mas você provavelmente já tem projetos planejados ou em andamento. O que você deve fazer com eles?

E o que você deve fazer se você ou um colega de trabalho ficar preso pensando em um projeto?

Perguntar "Por quê?" repetidamente pode ajudar times a mudar de projetos para outcomes. É um ótimo exercício para desenvolver músculos de outcome e desaprender mindsets e comportamentos antigos, se usado corretamente.

Para um exemplo simplificado, imagine que um analista de marketing pediu ajuda para sua gerente:

- Criei um Key Result que diz: "Escrever 5 posts no LinkedIn", mas agora eu sei que isso é um projeto, não um Key Result real. Você pode me ajudar a identificar o outcome?

- Por que você quer escrever 5 posts no LinkedIn?

- Para aumentar os seguidores.

- Por que você quer aumentar os seguidores?

- Para aumentar o engajamento.

- Por que você quer aumentar o engajamento?

- Para aumentar o brand awareness (o quanto a marca é reconhecida pelos clientes).

- Por que você quer aumentar o brand awareness?

- Para atrair clientes potenciais.

- Por que você quer atrair clientes potenciais?

- Para aumentar a receita.

Perguntar "por quê?" várias vezes ajuda a mapear uma sequência de outcomes que conectam o projeto original com um outcome de alto nível:

Esta técnica é chamada de Cinco Porquês (ou Five Whys, em inglês). Ela vem da Manufatura Enxuta (Lean Manufacturing, em inglês), onde é usada para identificar a causa raiz de um problema.

Vamos usar uma versão um pouco diferente focada em ajudar os times a identificar os outcomes desejados e conectar seu trabalho aos OKRs da empresa.

Outcomes são como uma sequência de dominós

Imagine uma sequência de dominós, onde a derrubada da primeira peça cria uma reação em cadeia, derrubando sequencialmente cada dominó até o último.

Em vez de ver os outcomes isoladamente, é melhor vê-los como uma sequência em cascata, como uma série de dominós caindo.

Ao definir nossos outcomes desejados, queremos selecionar intencionalmente aqueles que se apoiam uns nos outros, criando um poderoso efeito dominó.

Olhando para nosso exemplo novamente, podemos ver que respondemos a cada pergunta "por quê?" com um outcome claro. Cada item na sequência contém um benefício mensurável que queremos criar:

Esta sequência de outcomes funciona como uma série de dominós, onde a obtenção do primeiro outcome contribui para a obtenção do segundo e assim por diante, até chegarmos aos outcomes desejados pela empresa.

Os Cinco Porquês podem ser uma ótima ferramenta para desenvolver os times

Os times precisam de orientação, mentoria e apoio de seus gerentes para ter o melhor desempenho. E os Cinco Porquês podem ser uma ótima ferramenta de mentoria.

As pessoas geralmente entendem por que estão trabalhando em um projeto, mas têm dificuldade em expressar o outcome. A técnica Cinco Porquês pode ajudar a identificar esses outcomes.

Mas se um time está com dificuldades para responder até o primeiro "por quê", significa que eles não têm o entendimento básico do contexto de que precisam para focar em outcomes. Os líderes têm que intervir e corrigir isso, orientando os times.

Perguntar "Por quê?" é apenas o primeiro passo

Perguntar "Por quê?" é um ótimo começo, mas para focar em outcomes não podemos parar por aí.

Voltando ao nosso primeiro exemplo, o gerente de marketing continua orientando a analista após mapear a sequência de outcomes mostrada na imagem acima:

- Agora precisamos escolher em quais outcomes você vai se concentrar. Em qual "nível" da sequência você acha que deve focar?

- Aumentar os seguidores parece bom, mas isso é irrelevante sem construir relacionamentos com clientes potenciais. Vou focar em atrair clientes potenciais.

- Como você pode medir esse outcome? Quais métricas você poderia usar?

- Posso medir o número de pessoas que entram em contato conosco para agendar uma demonstração do nosso software ou o número de leads qualificados.

- Que outras ideias você poderia testar para atingir esse outcome? Queremos focar no outcome em vez de ficar presos em um único projeto.

- Podemos experimentar coisas diferentes, como publicar entrevistas com clientes de referência, realizar pequenos eventos online e fazer um vídeo de demonstração melhor do produto.

Exemplo dois

Para outro exemplo, imagine um time de produto tendo esta conversa:

- Estamos trabalhando para entregar uma nova ferramenta de atendimento ao cliente, mas estamos com dificuldades para definir os outcomes desejados. Vamos usar a técnica Cinco Porquês para tentar resolver isso.

- Por que queremos entregar uma nova ferramenta de atendimento ao cliente?

- Para simplificar o uso da ferramenta.

- Por que queremos simplificar o uso da ferramenta?

- Para ajudar os atendentes a encontrar as informações de que precisam mais rapidamente.

- Por que queremos ajudar os atendentes a encontrar informações mais rapidamente?

- Para resolver os problemas dos clientes mais rapidamente.

- Por que queremos resolver os problemas mais rapidamente?

- Para aumentar a satisfação do cliente.

- Por que queremos aumentar a satisfação do cliente?

- Para aumentar a retenção de clientes.

- Aqui está a sequência de outcomes que mapeamos. Em quais desses outcomes devemos focar?

- No final, queremos aumentar a retenção. No entanto, muitos fatores afetam a retenção, então talvez nunca saibamos se nosso time fez a diferença.

Podemos criar um OKR compartilhado com o time de atendimento ao cliente para resolver os problemas dos clientes mais rapidamente, mas medir nossa contribuição pode ser difícil.

Vamos focar nos dois outcomes no início da sequência: "simplificar o uso da ferramenta" e "encontrar as informações mais rápido".

- E como podemos medir esses outcomes? Quais métricas poderíamos usar?

- Poderíamos medir a taxa de conclusão de tarefas comuns, o tempo para concluir essas tarefas e o tempo para recuperar as informações necessárias.

- Que outras ideias poderíamos testar para atingir esse outcome?

- Podemos testar diferentes maneiras de treinar os agentes de atendimento ao cliente no uso da ferramenta.

Mas o ponto principal é que não podemos tratar o desenvolvimento da ferramenta como um projeto com funcionalidades predefinidas. Temos que experimentar ideias ou abordagens diferentes para atingir os outcomes que selecionamos e testar essas ideias com usuários reais.

Se você está sempre começando com um projeto, há algo errado

Os Cinco Porquês são uma ferramenta poderosa para ajudar os times a desenvolver seus músculos e mindsets de outcome. Mas geralmente ela é usada como uma técnica temporária durante a transição para outcomes.

À medida que os times se tornam mais fluentes em começar com o fim em mente (ou seja, definindo outcomes desejados desde o início), eles tendem naturalmente a usar menos essa técnica.

Não há problema em usar a técnica Cinco Porquês ocasionalmente, mas se você sempre começar com um projeto específico, há algo errado.

Algum processo ou ferramenta em sua organização pode estar forçando você a definir projetos específicos antes de identificar os outcomes desejados. Se isso acontece com frequência, é hora de revisar suas práticas atuais.

Talvez você precise desaprender ou repensar algumas delas.

Usando os Cinco Porquês na prática

Aqui estão algumas dicas:

Responda cada "por quê?" com um outcome claro

Você tem que responder a cada pergunta "por quê?" com um outcome claro: o benefício mensurável que você deseja criar, como fizemos nos exemplos acima.

Aprender a comunicar seus outcomes desejados usando uma linguagem clara é um dos músculos que você precisa desenvolver. Aproveite a oportunidade para praticar isso.

O verdadeiro desafio é mapear o meio da sequência

Geralmente, o verdadeiro desafio é identificar os outcomes no meio da sequência. Não desista facilmente: trabalhar na definição desses outcomes será um ótimo exercício.

Se você pular direto para o outcome de alto nível sem identificar os do meio, você está fazendo errado.

Você não precisa perguntar "por quê?" cinco vezes

Você não precisa perguntar "por quê?" exatamente cinco vezes. Muitos times fazem isso em quatro ou seis etapas, por exemplo.

Mas o objetivo é perguntar "por quê?" algumas vezes e mapear uma sequência de outcomes. Se você só perguntar "por quê?" uma vez e parar no primeiro outcome que encontrar, você está fazendo errado.

A sequência de outcomes não precisa ser uma linha reta

Coloquei os outcomes em uma linha reta nos meus exemplos para deixá-los mais simples. No entanto, você pode encontrar casos em que uma pergunta "por quê?" leva a múltiplos outcomes, criando uma "bifurcação" na sequência:

Os Cinco Porquês podem ajudar você a desaprender mindsets antigos

Ver as pessoas usando a técnica Cinco Porquês me lembra dos exercícios corretivos que meu fisioterapeuta me ensinou.

Exercícios corretivos são atividades físicas projetadas não apenas para fortalecer os músculos, mas também para retreinar o corpo a se mover de uma maneira mais saudável. Eles ajudam a corrigir desequilíbrios musculares, melhorar a postura e restaurar padrões de movimento adequados.

Exercícios corretivos ajudam a desaprender maus hábitos e padrões de comportamento que podem causar dor ou lesão.

E a técnica Cinco Porquês pode fazer o mesmo por você.

Se usada corretamente, ela pode ser um ótimo exercício corretivo para ajudar a desenvolver seus músculos de outcome e desaprender mindsets antigos ao mesmo tempo.

Agora é sua vez de usar os Cinco Porquês

A única maneira de desenvolver seus músculos de outcome é através de muita prática, então agora é sua vez de usar os Cinco Porquês.

Na minha experiência, a melhor maneira de fazer este exercício é formar um grupo de três a seis pessoas que trabalham juntas e pedir que elas usem os Cinco Porquês em um exemplo real.

Pegue um projeto real no qual você está trabalhando ou já planejou e siga os passos abaixo.

1. Pergunte "por quê?" repetidamente.

   Responda cada "por quê?" com um outcome claro, mapeando uma sequência de outcomes.

2. Olhando para a sequência de outcomes, selecione aquele(s) no(s) qual(is) você vai focar.

3. Como você pode medir o(s) outcome(s) selecionado(s)?

   Quais métricas você poderia usar? Você precisa criar novas métricas ou usar métricas diferentes das que normalmente usa?

4. Que outras ideias você poderia testar para atingir o(s) outcome(s) selecionado(s)?

Sinta-se à vontade para compartilhar sua experiência e insights do exercício nos comentários ou por e-mail. Estarei de volta em breve com outro post.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Compartilhar

Este post se baseia em conceitos discutidos aqui e aqui. Para aproveitá-lo ao máximo, recomendo começar por lá.

Este post também está disponível em inglês.

Assine agora

Stephen Covey capturou um dos princípios centrais por trás da abordagem de outcomes em sua famosa frase: "Comece com o fim em mente".

Comece definindo claramente o outcome desejado, por que ele é importante e as restrições e limites para alcançá-lo.

Então, trabalhe de trás para frente para descobrir como atingir o outcome. Experimente diferentes ideias ou abordagens para identificar quais ajudarão a alcançá-lo.

A Amazon é famosa por usar uma técnica similar chamada Working Backwards (trabalhando de trás para frente). A ideia é começar com as necessidades do cliente e trabalhar de trás para frente a partir delas (veja o texto explicativo no final do artigo).

Para entender melhor como começar com o fim em mente, vamos ver um exemplo:

Exemplo

Outcome desejado: Ajudar os clientes a resolverem problemas sem precisar entrar em contato conosco.

Possíveis métricas que poderíamos usar incluem:

• Taxa de sucesso de autoatendimento: o percentual de problemas do cliente resolvidos por canais de autoatendimento.

• Taxa de contato (contact rate em inglês): o número de vezes que os clientes entram em contato com a empresa para obter ajuda em um determinado período.

Por que é importante: Ajuda a melhorar a experiência do cliente e reduz custos ao mesmo tempo.

Restrições: Todas as soluções devem ser implementadas dentro da arquitetura de software atual.

Limites (ou salvaguardas): Evite práticas questionáveis, como dificultar excessivamente o contato dos clientes conosco.

As mudanças não devem impactar negativamente a experiência do cliente, conforme medido por métricas como pontuação de satisfação do cliente ou net promoter score (NPS).

Você não precisa usar exatamente este formato. Este é apenas um exemplo do tipo de conversa que você deve ter ao começar com o fim em mente.

Por que é importante começar com o fim em mente?

Nossos cérebros estão programados para pensar em projetos.

Quando vemos um problema, naturalmente começamos a pensar sobre o que podemos fazer, quem pode fazê-lo e qual é a data.

Muitas vezes operamos no piloto automático, fazendo o que sempre fizemos. Quando fazemos isso, trabalhamos mecanicamente sem questionar o que queremos alcançar ou como trabalhamos.

Também é extremamente fácil se apaixonar por nossas ideias e acreditar que todas farão a diferença.

Todos nós tendemos a cair no mindset sabe-tudo, assumindo que temos todas as respostas e que todos os nossos projetos gerarão resultados.

Gosto de dizer que temos um Coiote do desenho Papa-Léguas vivendo dentro de nossos cérebros.

O Coiote se apaixona pelos nossos projetos e começamos a pensar: "Claro que vai funcionar. É uma ideia brilhante!"

Já perdi a conta de quantas vezes ouvi pessoas dizerem que não precisavam medir o outcome de seu projeto porque ele obviamente seria bem-sucedido.

Todos nós tendemos a nos apaixonar por nossas ideias e acreditar nelas.

Não há problema em ser apaixonado pelo seu trabalho. O problema é pelo que você se apaixona.

Esta frase famosa de Ash Maurya é um aviso importante:

Ame o problema, não a sua solução. A vida é muito curta para construir algo que ninguém quer.

Então, apaixone-se pelo que você está tentando alcançar e pelo problema que está tentando resolver.

Se apaixone por fazer a diferença no seu trabalho e ajudar os clientes ou seus colegas. Mas não se apegue demais à sua solução específica ou ao projeto em que está trabalhando.

Começar com o fim em mente ajuda a combater nossa tendência de pensar em projetos, forçando-nos a fazer uma pausa e definir o outcome desejado.

Adicionar outcomes depois não é suficiente

Muitas pessoas definem seus OKRs na ordem errada. Elas começam selecionando os projetos em que trabalharão e depois definem OKRs com base nisso.

Por exemplo, as empresas geralmente começam criando um orçamento listando os projetos específicos em que investirão e depois criam OKRs com base neles.

Ao mesmo tempo, os times de produto geralmente começam com o que está em seu backlog e colocam isso em seus OKRs.

Isso acontece mesmo quando os líderes estão tentando dar autonomia aos times—os colaboradores individuais também tendem a se apaixonar por suas ideias.

Às vezes, as pessoas tentam consertar isso adicionando outcomes depois que os projetos já foram definidos. O problema é que elas geralmente acabam se prendendo a essa lista de projetos, independentemente do outcome.

Focar em outcomes significa experimentar diferentes maneiras para alcançá-los.

Se você não está testando diferentes ideias, ou diferentes maneiras de implementar a mesma ideia, você não está focando em outcomes.

Começar com o fim em mente é um conceito simples e poderoso que pode nos ajudar a focar em outcomes. Mas para aplicá-lo na prática, as empresas precisam desaprender velhos mindsets e abandonar práticas que reforçam comportamentos antigos.

Perguntas para refletir

Aqui estão duas perguntas para te ajudar a conversar sobre este artigo com seus colegas:

• Pense em seus OKRs mais recentes. Você começou com o fim em mente ou começou com uma lista de projetos?

• Analise seus processos de orçamento e planejamento. Eles ajudam os times a começar com o fim em mente? Que mudanças você poderia fazer para permitir que você comece definindo os outcomes desejados?

Estarei de volta em breve com outro post. Enquanto isso, sinta-se à vontade para compartilhar seus pensamentos nos comentários ou me enviar um e-mail.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Compartilhar

Este post se baseia em conceitos discutidos aqui e aqui. Para aproveitá-lo ao máximo, recomendo começar por lá.

Este post também está disponível em inglês.

Assine agora

Como já vimos, o mindset outcome-driven é uma maneira fundamentalmente diferente de liderar pessoas e gerenciar o trabalho.

Ele não se encaixa nos modelos operacionais, capacidades organizacionais, processos ou culturas existentes na maioria das empresas. Ele também não corresponde às competências e mindsets atuais da maioria dos indivíduos.

Infelizmente, a maioria das pessoas não entende isso e acaba caindo em uma armadilha comum que eu chamo de abordagem Tinker Bell:

Jogue um pouco desse pó de pirlimpimpim sobre sua antiga maneira de trabalhar sem mudar mais nada.

Sua organização passará magicamente a trabalhar como as melhores empresas do mundo. Instantaneamente, todas as pessoas ficarão mais alinhadas, inovadoras, focadas e definirão metas mais ambiciosas.

A abordagem Tinker Bell parece uma piada, mas algumas pessoas realmente a utilizam. Elas dizem que querem outcomes, mas continuam focando em cumprir datas de projetos como sempre fizeram.

As pessoas aplicam a abordagem Tinker Bell não apenas com outcomes, mas também com OKR, o modelo de produto, Agile e qualquer coisa que se torne moda no mundo dos negócios.

Há alguns anos, o "modelo do Spotify" se tornou o pó de pirlimpimpim mais popular. Várias empresas começaram a chamar seus times de "squads" sem fazer nenhuma mudança significativa.

O mesmo padrão está começando a se repetir com o modelo de produto. Algumas organizações estão dizendo aos colaboradores que eles agora são product managers, sem sequer perguntar se eles querem ser PMs.

Como aquela definição popular de insanidade, essas empresas continuam fazendo a mesma coisa e esperam resultados diferentes.

Mas meu exemplo favorito é o banco que utilizava um painel de KPIs na sua área de tecnologia há muitos anos. De um dia para o outro, um executivo decidiu alterar o título do painel de "KPIs" para "OKRs"—sem mudar mais nada. Então, ele apresentou o painel para o time, dizendo "Aqui estão nossos OKRs".

Como você pode imaginar, o banco não obteve resultados com OKR.

Abandonando o pensamento legado

Várias organizações investiram para abandonar sistemas legados, mas a maioria não abandonou o pensamento legado.

À medida que as empresas crescem, muitas vezes têm que lidar com sistemas legados, softwares desatualizados ainda em uso.

Para scale-ups, pode ser uma plataforma desenvolvida às pressas durante uma fase de alto crescimento. Para empresas tradicionais, pode ser um aplicativo desenvolvido nos anos 90.

O pensamento legado é algo muito semelhante. Ele inclui mindsets, crenças, práticas e processos desatualizados ainda em uso.

Assim como os sistemas legados, o pensamento legado pode cumprir seu propósito inicial. Mas ele é incompatível com abordagens modernas e limita a capacidade da organização de inovar e mudar.

Exemplos de pensamento legado incluem:

• Tratar os times como tiradores de pedidos que simplesmente entregam projetos.

• Acreditar que não há necessidade de medir outcomes ou fazer experimentos pois “o projeto obviamente vai gerar resultado.”

• Alocar orçamento para projetos específicos em vez de outcomes.

Para focar em outcomes, as organizações precisam lidar com o pensamento legado com a mesma seriedade com que lidam com sistemas legados.

Para focar em outcomes, você precisa desaprender

Se você simplesmente quer dizer que está focando em outcomes—ou usando OKR—a abordagem Tinker Bell é perfeita para você.

Mas se você quer se beneficiar de outcomes e obter resultados com OKR, você deve mudar o modelo operacional e a cultura de sua organização em um nível fundamental.

Começa desenvolvendo seus músculos de outcome, como temos falado— aqui, aqui, aqui e aqui, por exemplo. Mas isso não é suficiente.

Para focar em outcomes—e ter sucesso com OKR—você precisa desaprender.

A melhor definição de desaprender vem do meu amigo Barry O'Reilly, autor do livro Unlearn:

Abandonar mindsets e comportamentos que eram efetivos no passado, mas agora limitam nosso sucesso.

Temos uma série de mindsets, comportamentos e práticas de gestão que eram efetivos há 10, 20 ou 50 anos, mas agora estão limitando nosso sucesso. Precisamos desaprendê-los.

Muitas das técnicas, abordagens e processos que nos ensinaram são como sistemas legados. Eles ainda atendem às necessidades para as quais foram originalmente concebidos, mas agora estão limitando nosso sucesso.

Não estou dizendo que tudo o que você está fazendo agora está errado ou que você precisa desaprender tudo.

Mas desaprender é difícil e você precisa se comprometer a desaprender o que está prejudicando sua capacidade de ter sucesso.

Os líderes precisam se comprometer a desaprender

A relutância dos líderes em mudar seus próprios comportamentos é uma das principais causas de fracasso para grandes iniciativas e transformações de mudança.

Como afirma Patrick Lencioni:

O maior fator que determina se uma organização vai ficar mais saudável - ou não - é o compromisso genuíno e o envolvimento ativo da pessoa responsável.

Para focar em outcomes e obter resultados com OKR, os líderes precisam se comprometer a desaprender.

Uma das coisas que precisamos desaprender é a ideia de que os líderes precisam saber tudo e ter todas as respostas. Em vez disso, os líderes devem estar dispostos a aprender tudo.

Como gosta de dizer Satya Nadella, CEO da Microsoft:

Não seja um sabe-tudo. Seja um aprende-tudo.

Líderes seniores e colaboradores individuais precisam desaprender os mindsets, comportamentos e métodos que estão limitando seu sucesso.

A organização também deve abandonar qualquer prática que reforce o pensamento legado. Se um processo, método, framework, fluxo de trabalho, métrica ou incentivo estimula comportamentos antigos, você deve descartá-lo.

A tabela abaixo lista algumas das coisas que precisamos desaprender se quisermos focar em outcomes:

O que mais você precisa desaprender?

E quanto a você, o que mais precisa desaprender para poder focar em outcomes?

Estarei de volta em breve com outro post. Enquanto isso, sinta-se à vontade para compartilhar seus pensamentos nos comentários ou me enviar um e-mail.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Compartilhar

Bem-vindo! Caso você esteja lendo este blog pela primeira vez, recomendo ler os artigos abaixo primeiro, já que o post de hoje se baseia em conceitos discutidos neles:

• É hora de ser outcome driven.

• Um OKR deve medir o outcome, não o projeto.

• E se você não conseguir medir o outcome?

Este post também está disponível em inglês.

Assine agora

Após o artigo da semana passada, recebi várias perguntas sobre como usar a técnica das duas caixas na prática. Vou tentar respondê-las neste post.

Barry (não é seu nome real) compartilhou uma situação comum:

Estou curioso para saber como usar as duas caixas se compara a um método diferente que aprendi, onde você conecta explicitamente projetos a cada Key Result, como mostrado neste exemplo:

O método acima parece bom em teoria, mas na prática cria dois desafios:

1. Algumas pessoas acabam se focando nos projetos. Elas ignoram ou não se importam realmente com os Key Results.

2. Temos alguns projetos essenciais que não se relacionam a um OKR e não está claro o que devemos fazer com eles.

Sua abordagem de duas caixas ajuda a resolver o item 2. Mas como podemos alcançar nossos OKRs se não tivermos projetos explicitamente conectados a eles?

Para responder às perguntas do Barry, precisamos entender que focar em outcomes requer uma mudança fundamental de mindset.

Admitindo que não conseguimos saber de tudo com antecedência

Você provavelmente já viu material parecido com o exemplo compartilhado por Barry na imagem acima.

Dizem para você mapear uma lista de projetos sob cada Key Result para que você possa planejar exatamente o que vai fazer para alcançar seu OKR.

O problema é que as pessoas frequentemente acabam se prendendo a essa lista predefinida de projetos, independentemente do outcome. Quando fazem isso, elas focam em projetos, não em outcomes.

Elas estão usando OKR apenas no papel.

A empresa pode ter OKRs, mas as pessoas não se apropriam deles e focam em projetos. OKR é visto como uma mera formalidade que não orienta o trabalho do dia a dia.

Esta é outra situação que mostra que precisamos desenvolver novos músculos e mindsets, já que a maioria das organizações não está pronta para outcomes.

Focar verdadeiramente em outcomes requer uma mudança fundamental de mindset.

Usar a abordagem de outcomes requer admitir que não conseguimos saber de tudo com antecedência e que nem todos os nossos projetos gerarão os outcomes esperados.

Na vida real, até ideias que parecem óbvias e são executadas perfeitamente podem falhar em atender às expectativas.

Isso significa que não podemos criar uma lista de todos os projetos que entregaremos no trimestre e nos prender a ela. Em vez disso, temos que testar rapidamente diferentes ideias para descobrir quais delas ajudarão a alcançar o outcome.

Para fazer isso, temos que desenvolver novos músculos: as habilidades individuais e capacidades organizacionais para possibilitar que as pessoas realizem experimentos e testem ideias rapidamente.

A tabela abaixo contrasta as premissas implícitas por trás da abordagem de outcomes e da abordagem de datas.

Como usar as duas caixas

Sempre tento manter as coisas o mais simples possível em meus artigos. No entanto, talvez eu tenha ido longe demais ao tentar simplificar meu último post.

Algumas coisas ficaram implícitas e isso dificultou que as pessoas entendessem completamente os conceitos.

Vou corrigir isso com uma explicação mais detalhada sobre como usar as duas caixas, usando palavras ligeiramente diferentes das que usei antes.

A ideia central é imaginar que vamos colocar nossos investimentos e prioridades em duas "caixas":

Na primeira caixa, colocaremos os investimentos focados em alcançar outcomes e que serão gerenciados usando a abordagem de outcomes.

Na segunda caixa, colocaremos os investimentos focados em cumprir prazos de projetos e que serão gerenciados usando a abordagem de datas (também conhecida como "abordagem PMO").

Investimentos com outcomes que podemos medir vão para a caixa de outcomes, enquanto investimentos com outcomes que não podemos medir — pelo menos por enquanto — vão para a caixa focada em datas.

Ambas as caixas contêm projetos

Para ser claro, ambas as abordagens para gerenciar o trabalho usam projetos, mas elas fazem isso de maneiras completamente diferentes.

Uma forma de visualizar isso é imaginar que temos duas "camadas" dentro de ambas as caixas. No topo, você tem seus outcomes desejados, e abaixo deles, você tem projetos para ajudar a alcançar esses outcomes:

Dentro da caixa de outcomes, temos um OKR no topo e projetos na parte inferior. Esses projetos são apenas ideias para alcançar o outcome, e temos que descobrir quais dessas ideias nos ajudarão a fazer isso.

A lista de ideias pode mudar a qualquer momento. Podemos testar diferentes ideias ou testar diferentes formas de implementar a mesma ideia.

Por exemplo, digamos que uma de suas ideias seja redesenhar o fluxo de cadastro de conta do seu aplicativo. Existem várias maneiras de fazer isso e você pode querer testar rapidamente diferentes opções para descobrir qual ajudará a alcançar o outcome.

Dentro da caixa focada em datas, encontramos algo diferente: projetos onde não existe uma conexão com outcomes. É por isso que os chamo de "projetos sem outcomes".

O outcome desejado pode não estar claro ou pode ser difícil de medir com os músculos que temos hoje. Em alguns casos, o outcome é deixado de lado mesmo que ele tenha sido previamente definido e medido.

Sem um outcome associado a eles, esses projetos se tornam a meta. Os times focam em completar uma lista predefinida de entregas, em vez de fazer discovery e testar diferentes ideias.

Usar a abordagem de datas não é um problema. O problema é usá-la em excesso.

Às vezes, existem projetos que simplesmente precisamos entregar. E há alguns tipos de trabalho que são melhor geridos usando datas.

Mas existem muitos investimentos que "deveriam" ser geridos usando outcomes, mas não são.

Além do OKR, temos que entregar os projetos sem outcomes

Aqui está um exemplo das duas caixas:

Além de alcançar nosso OKR, também temos que entregar esses projetos sem outcomes, ou apenas projetos, para abreviar.

Para fazer isso, temos que fazer duas coisas.

Primeiro, temos que incluir os projetos sem outcomes junto com nossos OKRs ao definir OKRs no início do trimestre e ao acompanhar o progresso durante os check-ins semanais.

Segundo, temos que garantir que vamos testar diferentes maneiras de alcançar o OKR. Nossa lista de ideias deve permanecer flexível em vez de se transformar em um roadmap fixo de projetos.

Isso nos permite permanecer focados no outcome em vez de apenas completar tarefas predefinidas.

Para alcançar essas duas coisas, temos que começar a pensar em OKR + Projetos.

O formato OKR + Projetos nos permite comunicar e acompanhar o outcome desejado e os projetos sem outcomes lado a lado:

O formato OKR + Projetos não inclui a lista de ideias, e isso é intencional.

Queremos ter conversas separadas sobre nosso OKR + Projetos (em azul) e nossas ideias ou experimentos para alcançar o OKR (em verde):

Temos que nos focar em nosso OKR + Projetos ao discutir nossas prioridades para o trimestre e durante os check-ins semanais.

Os times podem mencionar brevemente as ideias que estão testando ou planejam testar, mas devem evitar explicações detalhadas que podem levar muito tempo e retirar o foco dos outcomes.

Devemos resistir à tentação de transformar essas conversas em revisões detalhadas de projetos ou sessões de brainstorming para definir novas ideias a serem testadas.

Nossos cérebros estão programados para pensar em projetos, e é extremamente fácil começar a prescrever soluções específicas para os times. Todos nós caímos nessa armadilha de tempos em tempos, e eu não sou exceção.

Os líderes podem optar por "Mergulhar Fundo" e ajudar os times com os detalhes das ideias sendo testadas, mas isso tem que ser uma conversa separada do check-in.

Esse mergulho profundo deve focar em entender o que os times aprenderam, os dados disponíveis, os experimentos realizados e as principais hipóteses.

Vamos colocar isso em prática

A melhor maneira de colocar este artigo em prática é discutindo seus principais pontos com seus colegas ou amigos.

Aqui estão algumas perguntas para ajudar:

1. Você está usando OKR apenas no papel? Você está focando em projetos em vez de usar OKR para guiar suas decisões do dia a dia?

2. Você se sente confortável com a ideia de não saber tudo com antecedência e adaptar os planos conforme avança? Que passos você poderia dar para adotar esse mindset?

3. Como você pode usar o formato OKR + Projetos para comunicar melhor as prioridades e acompanhar o progresso?

4. O que você pode fazer para garantir que continue testando diferentes maneiras de alcançar seu OKR? Como você pode evitar transformar sua lista de ideias em um roadmap fixo de projetos?

5. Como você pode evitar prescrever soluções específicas para os times?

Voltarei em breve com outro post. Enquanto isso, fique à vontade para comentar abaixo ou me enviar um e-mail.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Compartilhar

Bem-vindo a mais um artigo sobre como construir organizações outcome-driven e obter resultados com OKR.

Este post se baseia em conceitos discutidos nos artigos abaixo. Para aproveitá-lo ao máximo, recomendo lê-los primeiro:

• É hora de ser outcome driven. (o primeiro artigo da série)

• Um OKR deve medir o outcome, não o projeto.

Este post também está disponível em Inglês.

Assine agora

Há uma jornada comum quando as pessoas começam a desenvolver seus músculos de outcome1.

No início, as organizações geralmente agem como se qualquer coisa pudesse ser um OKR.

Seus Key Results incluem projetos, como "Lançar nosso novo site", e métricas de projetos, como "Mover 100% dos servidores para a nuvem". Alguns OKRs são tão confusos que é difícil entender o que eles significam.

Infelizmente, a maioria das empresas nunca vai além desse estágio e se pergunta por que não estão obtendo resultados com OKR.

À medida que as pessoas começam a desenvolver novos músculos e mindsets, todos os seus OKRs se tornam outcomes.

Mas só acompanhar outcomes leva a um desafio comum.

Nesse estágio, as pessoas geralmente não podem ou não sabem como medir os outcomes de muitos de seus investimentos.

Às vezes, o outcome não é claro, a organização não tem métricas para ele ou não coleta os dados para medi-lo.

Como consequência, uma grande parte dos investimentos da empresa— e boa parte do que os times estão trabalhando—não está representada nos OKRs.

Uma grande parte dos investimentos e prioridades da organização desaparece da vista ao acompanhar OKRs.

Essa falta de visibilidade pode causar confusão, desalinhamento e frustração entre os times, fazendo com que sintam que seu trabalho não importa.

O que você deve fazer se não puder medir os outcomes dos seus investimentos?

Coloque os investimentos em duas caixas

Uma analogia útil é imaginar que vamos colocar nossos investimentos e prioridades em duas "caixas", representando as abordagens para gerenciar o trabalho.

Se o termo "investimentos" soa um pouco estranho para você, pense nas prioridades do seu time. Onde você está investindo seu tempo?

Na primeira caixa, colocaremos os investimentos focados em alcançar outcomes e que serão gerenciados usando a abordagem de outcomes.

Na segunda caixa, colocaremos os investimentos focados em cumprir prazos de projetos e que serão gerenciados usando a abordagem de datas (também conhecida como "abordagem PMO").

Aqui temos projetos que não têm um outcome diretamente associado a eles, pelo menos por enquanto. Esses são os "projetos sem outcomes".

Investimentos com outcomes que conseguimos medir vão para a caixa de outcomes.

Já os investimentos com outcomes que não conseguimos medir — pelo menos por enquanto — vão para a caixa focada em datas.

Gerindo duas caixas: OKR + Projetos

Para gerir essas duas caixas, precisamos começar a pensar em OKR + Projetos.

A ideia é que além de alcançar nosso OKR, também temos que entregar esses projetos em outcomes, ou apenas projetos, para abreviar.

Aqui está um exemplo:

Usar as duas caixas pode trazer vários benefícios

Adotar a técnica das duas caixas é uma pequena mudança que pode trazer vários benefícios. Só é preciso um pouco de disciplina.

Primeiro, as duas caixas dão visibilidade a todos os seus investimentos e prioridades importantes, sejam eles geridos por outcomes ou datas.

Muitos times optam por acompanhar as duas caixas durante a verificação de OKR para simplificar.

Pensar em OKR + Projetos também ajuda a desenvolver os músculos e mindsets necessários para focar em outcomes. Usar as duas caixas força você a separar outcomes de projetos e métricas de projetos.

Usar essa técnica significa que não há absolutamente nenhuma razão para colocar projetos em seus OKRs. Basta colocá-los na caixa de datas—um projeto com outro nome ainda é um projeto.

Usar as duas caixas também pode ajudar você a focar.

Uma armadilha comum é limitar o número de seus OKRs para mostrar que você está focado, mas manter vários projetos em paralelo "por fora". Dessa forma, você evita ter que dizer não.

Visualizar todos os projetos em andamento pode ser uma ferramenta poderosa para ajudá-lo a focar, limitando o trabalho em andamento (work in progress ou WIP em inglês).

Por fim, as duas caixas ajudam você a entender para onde estão indo seus investimentos. Você está investindo para alcançar outcomes ou apenas para cumprir datas?

Elas também possibilitam uma conversa importante sobre se você está usando a melhor abordagem para gerir cada investimento.

"Como devemos gerir este investimento?"

Separar seus investimentos em duas caixas permite que você revise cada um deles e pergunte: como devemos gerir este investimento?

A maioria das empresas percebe que está usando muito mais datas do que deveria. Existem muitos investimentos que "deveriam" ser geridos usando outcomes, mas não são.

Embora não haja uma única resposta certa, é comum que muitos investimentos sejam naturalmente mais compatíveis com uma gestão por outcomes ou por datas.

Por exemplo, se você está investindo em um novo aplicativo de autoatendimento para ajudar os clientes a resolver problemas sem precisar entrar em contato com o suporte, provavelmente deve se focar nesse outcome.

Mas há casos em que tentar aplicar a abordagem de outcomes traz pouco benefício.

Pequenas dependências devem ser geridas usando datas

Uma situação comum é quando você precisa fazer algo pequeno para ajudar outro time a alcançar o outcome deles.

Essas pequenas dependências costumam ser mais bem administradas usando datas. Se ajudar o outro time tomará muito do seu tempo, muitas vezes faz sentido criar um OKR compartilhado com eles e trabalhar juntos por um outcome comum.

Mas você não pode usar OKRs compartilhados para cada pequena dependência, ou acabará com dezenas de OKRs.

Por exemplo, digamos que a advogada da empresa tenha que revisar vários pequenos contratos com fornecedores ou parceiros que outros times precisam para atingir seus outcomes. Gerir esses contratos usando datas provavelmente é a melhor escolha.

Porém, se a advogada estiver ajudando o time de vendas a negociar um contrato multimilionário com seu maior cliente de todos os tempos, um OKR compartilhado seria uma ótima opção.

Alguns tipos de trabalho são melhor geridos usando datas

Outro exemplo comum é quando os engenheiros têm que aplicar correções de segurança para eliminar vulnerabilidades em um aplicativo.

O time pode tentar medir o número de atualizações de segurança concluídas, mas isso é apenas uma métrica de projeto. Ela mede o trabalho realizado, mas não se ele fez a diferença.

Grande parte do trabalho relacionado a compliance, risco ou demandas regulatórias é semelhante. Muitas vezes, há uma longa lista de tarefas que precisam ser feitas e as métricas disponíveis simplesmente medem a conclusão dessas atividades.

Muitas vezes é mais fácil gerir esses exemplos como projetos sem outcomes em vez de tentar forçar para que se tornem outcomes.

Isso não significa que esse tipo de trabalho não seja importante—apenas significa que muitas vezes é melhor geri-lo usando a abordagem de datas.

Mas os times não devem simplesmente seguir ordens. Líderes devem ajudar os times de produto a colaborar com os stakeholders para entender como reduzir o risco ou cumprir a regulamentação, ao mesmo tempo em que fornecem uma boa experiência ao cliente.

À medida que você desenvolve seus músculos e mindsets de outcome, poderá passar para o próximo estágio da sua jornada.

Mais Outcomes, Menos Datas

Separar seus investimentos em duas caixas deixa abundantemente claro quando você está usando datas em excesso.

À medida que as empresas continuam a desenvolver novos músculos e mindsets, elas trabalham para Mais Outcomes, Menos Datas. Elas aumentam intencionalmente a "parcela" de seus investimentos gerenciados com outcomes e dados ao longo do tempo.

Não estamos falando de zero datas, mas de menos datas.

Mais Outcomes, Menos Datas trata de escolher deliberadamente a melhor abordagem para cada contexto e desenvolver os músculos e mindsets para fazer isso acontecer.

Isso significa desenvolver novas habilidades e modelos mentais nas pessoas, mas também construir as capacidades e mecanismos na organização para possibilitar o uso dessas habilidades.

Na minha experiência, muitas empresas podem aumentar o uso de outcomes no primeiro trimestre após adotar as duas caixas.

As mudanças iniciais necessárias geralmente são simples. Por exemplo, criar uma nova métrica com base nos dados existentes ou acompanhar outcomes que a empresa já estava medindo, mas que tinham sido ignorados.

Outras mudanças levam tempo, pois exigem mudanças mais profundas no modelo operacional e na cultura da organização. Você não chegará lá da noite para o dia, mas é possível fazer melhorias a cada trimestre.

Entraremos mais a fundo em Mais Outcomes, Menos Datas em um próximo artigo. Também discutiremos como medir outcomes difíceis de medir. Por enquanto, vamos esclarecer algumas coisas.

Talvez você tenha que trabalhar em um projeto agora para poder focar em um outcome mais tarde

Geralmente há algum trabalho preliminar necessário antes que você possa medir um outcome pela primeira vez.

As pessoas geralmente têm que coletar os dados necessários, criar relatórios ou definir uma nova métrica. Esses são todos exemplos de desenvolver os músculos de outcome um passo de cada vez.

Muitas vezes não há tempo para concluir esse set up inicial para todos os Key Results antes do início do trimestre. A solução é adicionar essas tarefas preliminares à sua lista de projetos sem outcomes garantir que não sejam esquecidas.

Você tem que trabalhar nesse projeto de preparação agora para poder focar no outcome desejado mais tarde.

No entanto, você não precisa esperar até o próximo trimestre para começar a trabalhar nesse outcome. Assim que esse set up inicial for concluído, você pode adicionar um novo Key Result ao seu OKR e começar a acompanhá-lo.

Não há problema em adicionar um novo Key Result no meio do trimestre, desde que seja realmente importante e você não acabe com Key Results demais.

Cumprir uma data pode ser tão crucial quanto qualquer outcome

Colocar algo na caixa de datas não o torna menos importante. Cumprir um prazo pode ser tão crucial quanto qualquer outcome.

Anos atrás, trabalhei com uma empresa de pagamentos que não podia se dar ao luxo de perder alguns prazos críticos.

Visa e MasterCard emitiam atualizações obrigatórias a cada seis meses, mais ou menos. Se essas atualizações não fossem implementadas a tempo, a empresa corria o risco de perder a capacidade de processar pagamentos com cartões—algo que realmente não pode acontecer com uma empresa de pagamentos.

A empresa utilizou a técnica das duas caixas e passou a acompanhar esses projetos críticos lado a lado com seus OKRs, garantindo que eles fossem visíveis para todos.

Os times de produto precisam de tempo para fazer discovery antes de se comprometer com datas

A empresa de pagamentos não está sozinha. Todas as empresas têm que se comprometer com datas de vez em quando, e cumprir esses prazos é crucial para passar para o modelo de produto.

Isso significa que times de produto empoderados precisam ser capazes de fazer o que Marty Cagan chama de compromissos de alta integridade.

Um compromisso de alta integridade é uma promessa feita por um time de produto de cumprir um prazo crítico de negócios tendo alta confiança em sua capacidade de entregar.

Para garantir que os líderes possam contar com essas datas, os times de produto precisam de tempo para fazer product discovery antes de se comprometer com datas.

Como Marty Cagan escreveu no livro Empoderado:

Uma vez que o time de produto acredita que entende a solução o suficiente, eles podem estimar com alta confiança quanto tempo levará para eles cumprirem esse compromisso (viabilidade) e também se essa solução funcionará para o cliente (valor e usabilidade) e funcionará para sua empresa (viabilidade).

Compromissos de alta integridade devem ser a exceção, não a regra. Eles devem ser usados apenas para prazos críticos.

Cumprir a data geralmente não é suficiente — você também deve alcançar o outcome desejado

Na maioria das vezes, você não pode simplesmente se comprometer a cumprir uma data. Você também tem que alcançar o outcome desejado.

Por exemplo, muitas empresas precisam garantir que seus sites estejam prontos a tempo para a Black Friday. Isso significa que todas as ofertas especiais devem estar disponíveis, mas também que o site seja capaz de lidar com todo o tráfego adicional.

Simplesmente entregar uma funcionalidade na data combinada não é suficiente. A funcionalidade também deve alcançar o outcome pretendido: qual é o benefício mensurável que você deseja criar para o cliente e/ou para o negócio?

Sem disciplina, você acabará com uma longa lista de projetos e datas

Nossos cérebros são programados para pensar em projetos e datas. Sem disciplina, você vai se apegar aos seus hábitos e acabar com uma longa lista de entregáveis e prazos.

Aqui estão cinco dicas para te ajudar:

1) Nunca pare de desenvolver seus músculos e mindsets

Se você quer se beneficiar de outcomes ou OKR, nunca deve parar de desenvolver seus músculos e mindsets de outcome. Melhoria contínua é a chave.

As pessoas costumam parar após uma vitória inicial, mas as melhores empresas continuam evoluindo trimestre após trimestre.

2) Nunca misture outcomes (ou OKRs) com projetos

Nunca inclua projetos ou métricas de projetos em seus OKRs. Sempre gerencie as duas caixas separadamente.

Lembre-se: afirmar que seu projeto é um Key Result não traz benefício.

3) Só desista depois de tentar definir o outcome por 30 minutos

Antes de decidir gerir um investimento usando datas, quero que você pare e dedique tempo para tentar definir o outcome desejado.

A maioria das pessoas desiste em 30 segundos. Eu quero que você gaste pelo menos 30 minutos.

No mínimo, isso ajudará a desenvolver seus músculos e mindsets de outcome.

Você também pode aprender que precisa fazer algum trabalho de preparação agora para poder focar no outcome mais tarde.

Se 30 minutos parecerem muito, pergunte-se se o investimento é realmente importante. Talvez você não deva trabalhar nisso.

Alguns investimentos são melhor geridos usando datas, mas você só pode tomar essa decisão depois de dedicar tempo para tentar para definir o outcome.

4) Quando estiver em dúvida, coloque na caixa de datas

É natural não ter certeza se algo é um outcome, especialmente no início. Se você não tem certeza se algo é um outcome, coloque-o na caixa de datas.

5) Execute limpezas trimestrais de projetos

A maioria das empresas tem muito mais projetos em andamento do que deveria.

Essas empresas espalham seus investimentos por várias prioridades em vez de se concentrar no pequeno número de coisas que vão mover o ponteiro.

É por isso que você deve realizar limpezas trimestrais de projetos. Uma vez por trimestre, revise todos os itens em sua caixa de datas—todos os seus projetos em andamento—e reduza drasticamente seu número.

Quais projetos não estão alinhados com a estratégia? Quais são desejáveis, mas não críticos?

Vamos colocar isso em prática

Voltaremos em breve com outro post. Enquanto isso, a melhor maneira de colocar este artigo em prática é discutir as ideias principais com seus colegas ou amigos.

Aqui estão algumas perguntas para ajudar:

• Verifique seus OKRs atuais. Há algum projeto ou métrica de projeto que deveria ser movido para a caixa de datas?

• Separe seus investimentos ou prioridades nas duas caixas. Quanto do seu trabalho é gerido usando outcomes vs. datas?

• Revise os itens em sua caixa de datas. Você consegue identificar mudanças simples que poderia fazer para medir outcomes?

• Quais projetos você pode eliminar?

Fique à vontade para comentar abaixo ou me enviar um e-mail.

A seguir

Aprenda como usar a técnica das duas caixas na prática no nosso próximo artigo.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Assine agora

Bem-vindo a mais um artigo da nossa série sobre como construir organizações outcome driven e obter resultados com OKR. Se você ainda não leu o primeiro artigo, recomendo começar por ele.

Este post também está disponível em Inglês.

Assine agora

A maioria das empresas está recebendo uma overdose de datas sem perceber.

Como me disse a VP de RH de uma empresa global de bens de consumo:

70% das metas individuais dos nossos colaboradores envolvem uma data de entrega de projeto. E não estamos falando de grandes projetos estratégicos, mas de entregas menores que sozinhas não significam muito.

O uso excessivo de datas constrói uma cultura que valoriza a entrega de projetos em vez de fazer a diferença.

Isso também prejudica o retorno sobre o investimento e mata a inovação. Líderes não conseguem saber quais investimentos estão funcionando ou não, enquanto os colaboradores são tratados como meros tiradores de pedidos sem autonomia alguma.

Essa epidemia de datas é tão difundida que até líderes que acham que dominam OKR costumam cair nela. Lembro-me de uma troca de e-mails com um CEO de uma "scale-up" em rápido crescimento:

CEO: Temos um nível avançado de maturidade com OKR. Aqui estão os OKRs da nossa empresa e das nossas duas linhas de produtos.

Felipe: As pessoas costumam achar que "já sabem" OKR, mas, infelizmente, é uma ilusão.

A armadilha mais comum é usar OKR para acompanhar projetos e datas em vez de alcançar outcomes. Você também está caindo nessa armadilha— todo mundo cai.

Em uma avaliação preliminar:

• 8 dos 19 "Key Results" da empresa são baseados em projeto. Por exemplo, "Implementar o novo processo no Salesforce até junho."

• 5 dos 13 "Key Results" do produto A são baseados em projeto. Por exemplo, "Implementar o novo MVP do app mobile até 30 de março."

• 8 dos 15 "Key Results" do produto B são baseados em projeto. Por exemplo, "Desenvolver e implantar o novo modelo de previsão de churn no Q2."

Você também precisa focar. Há coisas demais aqui.

CEO: Eu não tinha percebido isso. Esses OKRs me pareciam bons. Acho que precisamos de mais ajuda do que eu imaginava.

Sua empresa provavelmente está em uma situação semelhante, com muitos OKRs (ou metas) focados em cumprir prazos de projetos.

Para resolver esse problema, precisamos desenvolver novos músculos e mindsets.

Líderes e colaboradores devem desenvolver as habilidades necessárias para focar em outcomes. Enquanto isso, a organização precisa desenvolver as capacidades e mecanismos para viabilizar o uso dessas habilidades.

Líderes e colaboradores também precisam desaprender os mindsets que contribuíram para essa situação.

Neste artigo, começaremos a desenvolver seus músculos e mindsets de outcomes.

Primeiro, vamos fazer uma rápida revisão. Sinta-se à vontade para pular para a próxima seção se você acabou de ler o primeiro artigo desta série.

Revisão

Todas as empresas usam duas abordagens para gerenciar trabalho. Uma abordagem se concentra em alcançar outcomes, enquanto a outra simplesmente se concentra em cumprir datas de entrega. Na abordagem de datas, não importa se nossos projetos fizeram a diferença ou não.

O problema é que seus "músculos de outcome" provavelmente estão muito fracos, enquanto seus "músculos de datas" estão muito fortes.

Essa fraqueza faz com que sua organização se apoie demais em datas, especialmente quando combinada com os mindsets errados.

A maioria das organizações concentra uma grande parte de seus investimentos em cumprir prazos e assume implicitamente que todos os projetos gerarão resultados.

O primeiro passo para resolver um problema é reconhecer que ele existe

O primeiro passo para desenvolver seus músculos de outcome é aprender a separar outcomes de projetos e métricas de projeto. Por que isso é importante?

Você não pode resolver um problema que não consegue enxergar.

Imagine que sua médica disse que você precisa comer de forma mais saudável, mas você não sabe diferenciar junk food de opções mais saudáveis. Pizza, hambúrguer, carne, frango, frutas, vegetais — para você, é tudo comida.

Melhorar sua saúde nessa situação seria muito difícil.

Agora imagine que sua médica ajudou você a aprender a diferença entre proteínas, carboidratos e gorduras, e a prestar atenção de onde vêm suas calorias.

Conforme você começa a fazer isso, começa a entender a sua situação atual hoje e onde pode melhorar.

Essa história pode parecer um pouco exagerada, mas maioria das organizações está em uma situação semelhante com OKRs. Elas querem resultados, mas não sabem diferenciar OKRs "junk food" dos saudáveis. Agem como se qualquer coisa pudesse ser um OKR.

A consequência é que essas empresas têm dificuldade em entender para onde seus investimentos estão indo. Estamos investindo para alcançar outcomes ou somente cumprir datas?

Os Key Results dessas empresas incluem outcomes, projetos, métricas sem importância, coisas não mensuráveis e qualquer outra coisa que você possa imaginar. Às vezes, é difícil entender o que eles significam.

Até mesmo o livro nº 1 sobre OKR, Avalie o que importa, age como se qualquer coisa pudesse ser um OKR. Aqui está um exemplo do livro:

OBJETIVO

Instituir uma cultura que atraia e retenha colaboradores de nível A.

RESULTADOS-CHAVE

• Focar na contratação de gerentes/líderes de nível A.

• Otimizar a função de recrutamento para atrair talentos de nível A.

• Refazer todas as descrições de cargos.

• Treinar todos os envolvidos no processo de entrevistas.

• Garantir oportunidades de coaching/orientação contínuas.

• Criar uma cultura de aprendizado para o desenvolvimento de novos e antigos funcionários.

Não há um único número em todo o OKR. Não há métricas para medir outcomes ou acompanhar o progresso.

Isso é apenas uma lista de projetos e frases vagas e genéricas que soam bem, mas não definem claramente o outcome desejado.

Por exemplo, qual é a utilidade de dizer que você vai "focar na contratação"?

Posso imaginar a conversa dentro da empresa:

Gestor: Oi João, você já contratou alguém “de nível A"?

João: Não, chefe. Mas estou bem focado nisso. E é tudo o que tenho que fazer de acordo com meu Key Result.

Algo semelhante provavelmente está acontecendo na sua empresa neste momento. Não é culpa sua, mas você precisa corrigir isso se quiser obter resultados com OKR.

O primeiro passo é aprender a distinguir outcomes de projetos e também distinguir outcomes de métricas de projeto.

Projetos são o que você faz, outcomes são os benefícios mensuráveis criados pelo que você fez

Há muita confusão sobre o que são outcomes. Felizmente, encontrei uma definição precisa e acionável inspirada no trabalho de Robert M. Penna com organizações sem fins lucrativos:

Outcomes são os benefícios mensuráveis que queremos criar.

Isso inclui os benefícios que você deseja criar para seus clientes, sua organização ou outros colaboradores.

Outcomes direcionam a conversa em torno de duas perguntas:

• Que benefício queremos criar?

• Como vamos medi-lo?

É importante separar essas duas perguntas porque facilita pensar primeiro no benefício qualitativo que você deseja criar e depois definir as métricas.

Por exemplo, digamos que o benefício que queríamos criar fosse tornar nosso aplicativo mais fácil de usar.

As possíveis métricas que poderíamos usar neste caso incluem:

• Número de solicitações de suporte.

• Porcentagem de usuários que concluem com sucesso o registro da conta.

• Tempo gasto para concluir uma compra.

Separando outcomes de projetos

Precisamos fazer a distinção crucial entre projetos e outcomes:

• Projetos são o que você faz.

• Outcomes são os benefícios mensuráveis criados pelo que você fez.

Estou usando "projeto" como um termo abrangente para tudo o que fazemos, grande ou pequeno. Isso inclui atividades, tarefas, programas, iniciativas, entregas, ações, épicos, funcionalidades, itens de backlog, etc.

Por exemplo, "Redesenhar o fluxo de registro da conta" é um projeto. "Tornar nosso aplicativo mais fácil de usar" é um outcome (com diferentes métricas associadas a ele).

A distinção principal é entre coisas que você faz e os benefícios mensuráveis criados pelo que você fez.

Se pode entrar no seu backlog, não é um outcome

Existe um teste simples e poderoso para separar projetos de outcomes:

Se pode entrar no seu backlog, não é um outcome.

Outcomes são as consequências do que você fez. Um outcome não é algo que você possa fazer—ou colocar no seu backlog.

Projetos não são o problema—o problema é focar em projetos

Quando as pessoas aprendem sobre outcomes pela primeira vez, às vezes pensam que projetos são "ruins". Mas precisamos trabalhar em projetos para alcançar nossos outcomes (claro).

Projetos não são o problema. O problema é focar em projetos.

Como Marty Cagan me disse:

A abordagem de outcomes consiste em focar na diferença que queremos fazer e nunca perdê-la de vista.

No entanto, as pessoas costumam se concentrar em projetos mesmo quando os outcomes desejados são claros e fáceis de medir.

Um cliente me contou uma história que ilustra isso:

Um dia, a CEO de uma startup descobriu que o número de novos leads de vendas estava muito abaixo da meta e o tráfego do site estava caindo.

Ela decidiu questionar o gerente de marketing:

CEO: O número de novos leads está muito abaixo da meta. E o tráfego do site está caindo.

Gerente de marketing: Mas atingimos nosso OKR. Nós publicamos 15 posts e três vídeos, fizemos dois webinars e cumprimos todos os prazos.

CEO: Mas os leads e o tráfego estão péssimos.

Gerente de marketing: Mas esses não estão no nosso OKR!

O outcome desejado não era apenas fácil de medir, mas a empresa já media o outcome. Nem todos os casos são tão simples, mas essa situação acontece com mais frequência do que você imagina.

Quando o projeto é apenas um meio para alcançar o outcome

Quando nos concentramos em projetos, agimos como se a meta fosse entregá-los.

Mas ser outcome-driven é acreditar que trabalhamos para fazer a diferença, não apenas para concluir projetos.

Isso significa que, na maioria das vezes, a meta não é entregar o projeto. O projeto é apenas um meio para alcançar o outcome desejado.

(No próximo artigo, discutiremos como lidar com os casos específicos em que a meta é realmente entregar um projeto.)

Nossos cérebros estão programados para pensar em projetos, então focar em outcomes requer esforço consciente e deliberado.

Um truque poderoso é fazer uma pausa e perguntar:

Esse projeto é realmente nossa meta ou apenas um meio de alcançar um outcome?

Esse projeto é apenas uma ideia para alcançar o outcome?

A tabela abaixo contrasta ver o projeto como a meta versus vê-lo como um meio de alcançar o outcome.

Focar em outcomes significa que você deve testar ideias diferentes

A ideia central de focar em outcomes é que você tem que ajustar a rota com base nos dados. Temos que testar diferentes opções até alcançarmos o outcome.

Se algo está funcionando, você continua fazendo. Se não, você tenta outra coisa.

Mas quando as pessoas acreditam que seu objetivo é simplesmente cumprir prazos de projetos, elas costumam fazer o oposto. Elas definem tudo o que vão entregar no trimestre com antecedência e seguem o plano, mesmo quando as coisas não estão funcionando como esperado.

Elas não testam novas ideias ou ajustam o backlog com base nos dados.

Lembro-me de uma conversa durante um check-in de OKR com um cliente:

Membro do time: O time de infraestrutura teve que despriorizar o projeto de migração do servidor, então não vamos conseguir alcançar nosso Key Result.

Gestor: Mas ainda temos dois meses até o final do trimestre. O que mais podemos fazer para alcançar o outcome? Queremos focar no outcome, não em um único projeto.

Há também o caso comum em que um projeto não faz diferença. Eles poderiam ter migrado os servidores e ainda assim não ter alcançado o outcome.

É por isso que empresas outcome-driven tratam projetos como experimentos. Elas testam rapidamente ideias para descobrir quais ajudarão a alcançar seus outcomes desejados (no modelo de produto, isso é chamado de discovery de produto).

Agora que cobrimos a diferença entre outcomes e projetos, vamos discutir as métricas de projeto.

Nem todas as métricas medem outcomes

As pessoas costumam acreditar que basta tornar seus Key Results "mensuráveis". Afinal, fomos ensinados a focar em metas mensuráveis.

Mas só porque algo é "mensurável", não significa que seja um outcome. É por isso que precisamos entender a diferença entre outcomes e métricas de projeto:

• Outcomes (juntamente com as métricas associadas) medem o benefício que queremos criar. Eles medem se estamos fazendo a diferença.

• Métricas de projeto medem o progresso do projeto. Elas medem quantas coisas fizemos.

Aqui estão alguns exemplos de métricas de projeto:

• Treinar 100% dos gerentes em OKR.

• Publicar 10 posts.

• Mover 100% dos servidores para a nuvem.

• Aumentar o número de APIs publicadas de X para Y.

As perguntas que você precisa fazer são: estamos medindo se estamos fazendo a diferença? Ou estamos apenas contando quantos projetos ou atividades fizemos?

Um OKR real comunica o outcome que você deseja alcançar e como você vai medi-lo

A Intel criou uma fórmula para ajudar as pessoas a definir boas metas. É a melhor maneira de explicar a estrutura de um OKR:

Eu vou ________ medido por ____________

A ideia é que uma meta adequada deve descrever o outcome que você deseja alcançar e como você vai medi-lo. Por isso, as palavras "conforme medido por" são tão importantes.

Poderíamos reescrever a fórmula como:

Eu vou alcançar este outcome medido por estas métricas.

Os dois componentes do OKR, o Objective e os Key Results, se encaixam perfeitamente na fórmula "medido por":

Eu vou Objetivo medido por Key Results.

Podemos ver que o Objetivo comunica o outcome que queremos alcançar, enquanto os Key Results mostram como você vai medi-lo.

Ou, para colocar de outra forma:

Um OKR real comunica o outcome que você deseja alcançar e como você vai medi-lo.

Por exemplo, poderíamos facilmente pegar o outcome que vimos antes e reescrevê-lo no formato OKR:

Objetivo: (Qual é o outcome?)

Tornar nosso aplicativo mais fácil de usar.

Key Results: (Como vamos medi-lo?)

• Reduzir as solicitações de suporte do usuário de X para Y.

• Aumentar a % de usuários que concluem com sucesso o registro da conta de X% para Y%.

• Reduzir o tempo gasto para concluir uma compra de X para Y.

E aqui está um exemplo hipotético de OKR da Uber:

Objetivo: (Qual é o outcome?)

Fornecer viagens mais rápidas e baratas

Key Results: (Como vamos medi-lo?)

• Reduzir o tempo médio de espera durante os horários de pico de X para Y.

• Reduzir as viagens canceladas pelos motoristas de X% para Y%.

• Reduzir o preço médio por quilômetro durante os horários de pico de X para Y.

Não há benefício em dizer que seus projetos são "Key Results"

Vamos contrastar os dois OKRs acima com outro mau exemplo do livro Avalie o que importa:

OBJETIVO

Entregar soluções e estratégias especiais e tecnológicas da força de trabalho, de ponta a ponta.

RESULTADOS-CHAVE

• Implementar o piloto Box para os 100 primeiros usuários até o meio do trimestre.

• Concluir a implementação do BlueJeans para os usuários finais até o final do trimestre.

• Transferir os primeiros 50 usuários de contas individuais do Google para a conta corporativa até o final do trimestre.

• Finalizar o contrato Slack até o final do 1° mês e concluir a implementação até o final do trimestre.

Isso não é um OKR real.

O Objetivo se concentra em "entregar soluções" em vez de comunicar o outcome. Os Key Results são apenas um monte de projetos, métricas de projeto e datas.

Não há benefício em dizer que seus projetos agora são "Key Results." Um projeto com outro nome ainda é um projeto.

OKR deve medir o outcome, não o trabalho

OKR é apenas uma ferramenta e os resultados que você obtém dependem de como você o usa.

OKR pode cultivar uma cultura outcome-driven ou reforçar uma cultura tarefeira. Tudo depende de como você o usa.

A melhor maneira de colocar este artigo em prática é discutir as ideias principais com seus colegas ou amigos.

Aqui estão algumas perguntas para ajudar:

• Avalie os Key Results (ou metas) existentes em sua organização. Quantos deles são projetos em vez de outcomes?

• Pense em um projeto recente. O objetivo era apenas terminá-lo ou gerar um outcome? Que outcome você estava buscando?

• Os times dentro da sua organização mudam a rota com base nos dados ou seguem o plano independentemente dos resultados?

• Avalie as métricas usadas dentro da sua organização. Quantas delas medem o progresso do projeto em vez de outcomes?

• A forma como sua organização usa OKR está reforçando uma cultura focada em projetos e prazos?

• Pense nos processos internos da sua empresa. Os times são capazes de ajustar os planos com base nos resultados? O que precisaria mudar para permitir uma abordagem mais outcome-driven?

Fique à vontade para comentar abaixo ou me enviar um e-mail.

A seguir

Nosso próximo artigo aborda um desafio comum: E se você não conseguir medir o outcome?

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Assine agora

Este post também está disponível em Inglês.

Assine agora

Líderes outcome-driven definem o sucesso com base em outcomes, mas não param por aí. Eles também tratam as organizações como produtos—algo que eles podem alterar, testar e evoluir.

Steve Jobs é o maior exemplo de um líder que geria a empresa como um produto. Quando perguntado sobre de qual produto ele tinha mais orgulho, ele respondeu:

Fazer um produto é difícil, mas criar um time que possa fazer produtos continuamente é ainda mais difícil. O produto do qual tenho mais orgulho é a Apple e o time que construí na Apple.

Líderes outcome-driven tratam cada elemento da organização como uma "funcionalidade do produto" que existe para ajudar a organização a ter sucesso.

Essas "funcionalidades organizacionais" incluem coisas como processos, métricas, rituais, relatórios, estrutura, dados, ferramentas, habilidades e comportamentos.

Parafraseando Dharmesh Shah, co-fundador e CTO da HubSpot:

Toda empresa desenvolve dois produtos: um é o produto que elas desenvolvem para seus clientes e o outro é um produto que elas desenvolvem para seu time.

A cultura e o modelo operacional da sua empresa formam juntos o produto que você desenvolve para o seu time. Eles existem para ajudar as ótimas pessoas que você tem a fazer coisas incríveis para seus clientes e sua empresa.

Neste artigo, discutiremos o que significa tratar sua organização como um produto e os mindsets e comportamentos que impedem as pessoas de fazer isso.

Líderes outcome-driven desenham intencionalmente como a organização opera

Todas as empresas têm uma cultura e um modelo operacional, sejam intencionalmente pensados ou não.

A diferença é que os líderes outcome-driven desenham intencionalmente cada elemento de suas empresas. Eles evoluem deliberadamente sua cultura e formas de trabalhar para facilitar a obtenção de outcomes.

Como explica o blogueiro de tecnologia John Gruber, Steve Jobs foi muito intencional sobre como a Apple deveria funcionar:

O mesmo pensamento, cuidado e atenção meticulosa aos detalhes que Steve Jobs trouxe para questões como "Como um computador deve funcionar?", "Como um telefone deve funcionar?", "Como devemos comprar música e aplicativos na era digital?" ele também trouxe para a questão mais importante: "Como deve funcionar uma empresa que cria tais coisas?"

Líderes outcome-driven regularmente fazem perguntas como:

• Quais comportamentos queremos reforçar e encorajar nas pessoas? Quais queremos inibir?

• Quais fatores estão dificultando nosso desempenho? Quais estão ajudando?

• Como podemos criar um ambiente onde os times possam ter o melhor desempenho?

Vamos nos aprofundar em uma pergunta ainda mais poderosa.

Isso vai ajudar a alcançar nossos outcomes?

Ben Hunt-Davis é um coach de liderança que ganhou uma medalha de ouro como parte do time britânico de remo nas Olimpíadas de 2000. Seu princípio principal é: "Isso vai fazer o barco ir mais rápido?" Ou seja, isso ajudará a organização a ter sucesso?

Líderes outcome-driven fazem algo semelhante. Eles questionam tudo o que suas organizações fazem—ou não fazem— com a pergunta: "Isso vai ajudar a alcançar nossos outcomes?"

Se algo ajuda a alcançar os outcomes desejados, eles continuam fazendo. Se não, eles tentam algo diferente.

Essa filosofia se aplica no que eles trabalham (funcionalidades de produtos ou projetos) e também em como eles trabalham (seu modelo operacional ou maneira de trabalhar).

Cada elemento do modelo operacional ou da cultura da sua empresa existe por uma razão: ajudar a organização a alcançar sua missão e os outcomes desejados.

Líderes outcome-driven estão dispostos a mudar ou abandonar qualquer coisa que não esteja ajudando suas organizações a fazer a diferença. Eles também estão prontos para desaprender antigos mindsets e comportamentos.

Essa forma de pensar não é nova. Há cem anos, Henry Ford pregava algo semelhante:

Esteja pronto para rever qualquer sistema, descartar qualquer método, abandonar qualquer teoria, se o sucesso do trabalho exigir.

Essa flexibilidade permitiu que Ford alcançasse um milagre de produtividade com sua linha de montagem de movimento contínuo, diminuindo em quase 90% as horas de trabalho necessárias para produzir um carro Modelo T.

Líderes outcome-driven trabalham em duas frentes ao mesmo tempo

Há uma outra forma de entender o que está acontecendo: líderes outcome-driven trabalham em duas frentes ao mesmo tempo. Eles trabalham para alcançar os outcomes desejados, mas também para otimizar a organização para alcançar outcomes (meu obrigado a Marty Cagan pela expressão).

Um velho ditado nos ajuda a entender o que isso significa: "Se eu tivesse cinco minutos para cortar madeira, eu gastaria os primeiros dois minutos e meio afiando meu machado”.

Seguindo essa analogia, líderes outcome-driven equilibram o trabalho em duas frentes:

• Alcançar outcomes ("Cortar madeira"): Trabalhar para atingir seus outcomes pretendidos usando práticas e fluxos de trabalho atuais.

• Otimizar a organização para alcançar outcomes ("Afiar o machado"): Trabalhar para melhorar como a organização opera, evoluindo sua cultura e maneiras de trabalhar para facilitar o atingimento dos outcomes.

Steve Jobs se referia a essas duas frentes quando falou sobre "fazer um produto" (cortar madeira) versus "criar um time que possa continuamente fazer produtos" (afiar o machado).

Empresas de sucesso usam OKR para afiar o machado

Você pode estar se perguntando como OKR se encaixa nessa discussão.

Tenho ajudado empresas ao redor do mundo a adotar OKR e outcomes desde 2014. Depois de treinar e mentorar milhares de pessoas, notei um padrão claro que separa as empresas que têm sucesso com OKR das demais:

Empresas de sucesso usam OKR para afiar o machado, evoluindo sua cultura e formas de trabalhar.

Mas a grande maioria das pessoas adapta OKR à sua maneira antiga de trabalhar. Como aquela famosa definição de insanidade, eles continuam fazendo a mesma coisa repetidamente enquanto esperam resultados diferentes.

OKR pode ser uma ferramenta poderosa para ajudar a construir uma cultura outcome-driven e otimizar sua organização. Mas também pode ajudar a manter as coisas exatamente como estão. Tudo depende de como você o usa.

Algumas pessoas se referem às duas frentes acima como operar o negócio vs. mudar o negócio. Mas a maioria das empresas faz mudanças limitadas na forma como trabalham, e o resultado é que 70% das transformações falham, de acordo com pesquisas.

Tenho encontrado repetidamente um exemplo irônico dessa falta de afiar o machado enquanto trabalho com clientes.

Muitas empresas investiram em "transformação” e é claro que todas diziam usar OKR. Mas em vez de usar esses investimentos como uma forma de se tornarem mais outcome-driven, a maioria das organizações foca em datas em vez de outcomes.

Frequentemente, a meta é simplesmente "migrar para a nuvem até o final do ano". Não importa se essa migração fez a diferença ou não.

Muitas iniciativas de transformação assumem implicitamente que todos os projetos terão sucesso. Em vez de fazer discovery e testar ideias rapidamente, elas se baseiam em projetos que não entregam valor por 12-18 meses e raramente medem os outcomes desses projetos.

Olhe mais de perto e você verá que essas empresas estão usando técnicas “Ágeis” para entregar projetos waterfall—não há nada que se assemelhe a entrega contínua de valor.

Toda essa situação é um caso clássico do mindset sabe-tudo, onde acreditamos que temos todas as respostas. A premissa oculta é: “Não precisamos medir ou experimentar, sabemos o que estamos fazendo”. Não há muita transformação aí.

Esse problema não se limita a corporações tradicionais. Muitas empresas mais novas fazem coisas semelhantes, mesmo as que são “powered by tecnologia”.

Temos que lembrar que a maioria das organizações não está pronta para outcomes. Se você quer se beneficiar de ser outcome-driven, você deve mudar radicalmente sua organização—ajustes superficiais não serão suficientes.

Você pode evoluir passo a passo, mas tem que dar esses passos.

Por que as pessoas deixam de afiar o machado?

Transformação é difícil. Às vezes, os líderes resistem à mudança ou não sabem o que fazer.

Mas também existem outras razões pelas quais as pessoas deixam de afiar o machado:

• Operando no piloto automático: As pessoas costumam trabalhar mecanicamente em vez de serem intencionais sobre o que querem alcançar e como trabalham.

• Mindset fixo: Muitas pessoas veem sua organização como algo fixo que não pode ser mudado, em vez de um produto que pode ser alterado e melhorado.

• Fobia de retrabalho: Às vezes, as pessoas resistem em afiar o machado porque odeiam retrabalho, mesmo quando sabem que vai ser bom para elas.

• Percepção de falta de autonomia: Algumas pessoas se sentem como se fossem apenas uma engrenagem na máquina e acreditam que não há nada que possam fazer.

Vamos discutir cada um desses pontos com mais detalhes.

As pessoas costumam operar no piloto automático

A maioria das pessoas não é intencional sobre como trabalha. Todos nós temos uma tendência a operar no piloto automático, fazendo o que sempre fizemos.

Quando fazemos isso, trabalhamos mecanicamente e sem questionar o que queremos alcançar ou como trabalhamos.

As pessoas costumam ignorar uma pergunta básica: Qual problema estamos tentando resolver?

Essa pergunta é tão clichê que está listada em livros sobre como parecer inteligente no trabalho. E ainda assim, quando operamos no piloto automático deixamos de fazer essa pergunta fundamental.

Uma consequência da falta dessa pergunta é que as pessoas muitas vezes não sabem por que um processo ou métrica existe.

Como o fundador da Amazon, Jeff Bezos, explica:

É muito comum, especialmente em grandes empresas, que elas estejam gerenciando métricas que não entendem realmente. Elas realmente não sabem por que existem, e o mundo pode ter mudado um pouco e as métricas não são mais tão relevantes quanto eram quando alguém as inventou 10 anos atrás.

Bezos novamente:

Você tem que estar alerta para isso. Você tem que saber: “Ok, eu realmente não me importo com essa métrica. Eu me preocupo com a felicidade do cliente e só vale a pena investir energia, acompanhar e melhorar essa métrica se realmente afetar a felicidade do cliente”.

É extremamente fácil perder de vista a diferença que queremos fazer. Trabalhamos mecanicamente sem questionar por que uma métrica ou processo existe.

A solução é sempre começar definindo claramente o outcome que queremos alcançar, por que ele é importante e as restrições para alcançá-lo.

As métricas são “funcionalidades organizacionais” críticas, mas as pessoas não as discutem o suficiente na hora de definir OKRs. Eles podem discutir os números, mas não discutem as métricas.

Há muita discussão do tipo “no mês passado esta métrica era 10, agora é 12”, mas falta perguntar “esta é a métrica certa?”.

Muitas vezes há pouca discussão sobre processos ou práticas atuais, mesmo quando claramente há um problema. Vamos ver um exemplo que pode parecer muito tático, mas tem um impacto enorme: reuniões.

E se você gerir as reuniões como um produto?

Pesquisas mostram que os executivos passam em média quase 23 horas por semana em reuniões, e mesmo assim todo mundo as odeia.

Como o expert em produtos John Cutler explica, se as reuniões fossem um produto, ninguém compraria ou renovaria. Elas não têm product-market fit—as pessoas aparecem, não recebem valor e reclamam. Duvido que você possa encontrar um produto com notas de satisfação do cliente piores.

E se você intencionalmente repensar suas reuniões, fazendo experimentos?

Empresas como Dropbox e Asana descobriram que cada colaborador poderia economizar de 3 a 11 horas por mês cancelando ou repensando reuniões de baixo valor.

Empresas como Amazon e Stripe são conhecidas por terem reinventado suas reuniões. Todas as reuniões começam com os participantes lendo um documento, o que é mais rápido e permite um debate mais profundo do que assistir alguém apresentar slides.

E se você levar essa ideia além das reuniões e repensar intencionalmente outras "funcionalidades" da sua organização?

A maioria das pessoas vê organizações e times como algo fixo

Líderes outcome-driven enxergam as organizações como produtos que podem modificar, testar e melhorar, mas isso é radicalmente diferente da forma como a maioria das pessoas pensa.

A psicóloga Carol Dweck popularizou a ideia de que algumas pessoas têm um mindset fixo e enxergam suas habilidades como traços fixos que não podem mudar. A pesquisa de Dweck é sobre indivíduos, mas notei que as pessoas costumam aplicar um mindset semelhante quando pensam sobre o trabalho.

Pessoas com um "mindset fixo para trabalho" enxergam a maneira como sua organização opera como algo que está essencialmente escrito em pedra e não pode ser mudado. Muitos colaboradores individuais enxergam seus times de forma semelhante.

Por exemplo, quando converso com líderes de empresas grandes ou médias, muitos reclamam que não podem usar OKR ou focar em outcomes porque têm muitas dependências entre os times.

A solução tradicional é "gerir” essas dependências—gastar muito tempo coordenando o trabalho entre várias equipes.

Essa abordagem não apenas deixa tudo muito mais lento, mas também faz com que seja muito difícil que os times possam se apropriar de um outcome, já que tudo depende de todos os outros.

E, no entanto, executivos com um mindset fixo para trabalho acreditam que não há nada que possam fazer.

As pessoas da Amazon tinham um mindset diferente. Diante do mesmo problema, eles perceberam que não havia nenhuma lei dizendo que todo projeto tinha que envolver tantos times diferentes.

Por volta de 2002, Jeff Bezos e os outros executivos se cansaram de gerir dependências e decidiram remover dependências.

A Amazon investiu para reduzir drasticamente as dependências, fazendo mudanças profundas na forma como desenvolvia software e adotando uma nova arquitetura de software, adotando APIs1.

A empresa também reduziu dependências mudando a topologia do time—a forma como as organizações dividem o trabalho entre diferentes equipes, incluindo sua estrutura e escopo.

O objetivo era criar o que a Amazon chama de times separáveis, times que precisam de pouquíssima coordenação com os demais e que têm um alto grau de autonomia e senso de propriedade sobre seu trabalho.

O mindset fixo para trabalho afeta executivos e colaboradores individuais igualmente

O mindset fixo para trabalho não discrimina. Ele afeta executivos e colaboradores individuais igualmente.

Claro, há um limite sobre o que os times e os colaboradores individuais podem mudar em uma organização. Mas as pessoas com um mindset fixo enxergam a maneira como seus times operam como algo escrito em pedra, mesmo coisas que poderiam mudar.

A tabela abaixo traz alguns exemplos comuns de coisas que as pessoas falam quando enxergam a organização como uma coisa fixa.

Pare um minuto e se pergunte: você já disse ou pensou coisas parecidas?

Algumas pessoas odeiam retrabalho, mesmo quando é bom para elas

Às vezes, as pessoas resistem em afiar seus machados porque odeiam fazer mudanças em algo em que já trabalharam—mesmo quando sabem que será bom para elas.

Pessoas que trabalharam em projetos por muito tempo tendem a desenvolver retrabalhofobia.

Retrabalhofobia (substantivo):

• Medo ou ódio irracional de fazer mudanças em algo em que você já trabalhou.

• A crença equivocada de que todo retrabalho é ruim e deve ser evitado a todo custo.

Pessoas com retrabalhofobia costumam dizer coisas como: "Não podemos mudar nossos OKRs agora, já gastamos tanto tempo neles!”

Elas também dizem: "Trabalhamos duro para definir nossa estratégia, é frustrante aprender que está errada. Se mudarmos agora, as pessoas vão pensar que fizemos um trabalho ruim”.

Outra fala comum é: "Não podemos definir OKRs trimestrais porque não vamos entregar nada nos próximos nove meses. Mas não podemos mudar nossos projetos agora porque gastamos muito tempo planejando-os”. (Esse problema é tão comum que decidi mencioná-lo duas vezes neste artigo.)

No mundo dos projetos, o retrabalho é sempre ruim porque significa que alguém cometeu um erro e você tem que fazer o trabalho novamente. Podem até te responsabilizar por algo que não foi sua culpa.

O mesmo acontece na manufatura, onde o retrabalho é o processo de correção de itens defeituosos. A expectativa é que projetos e itens manufaturados sejam resolvidos em uma tacada só: você faz as coisas uma vez e pronto.

Mas produtos nunca estão "prontos", eles continuam evoluindo. Trabalhar em uma nova versão é natural no mundo dos produtos.

As pessoas na Netflix não dizem: "Gastamos tanto tempo na funcionalidade de recomendação, não podemos mudá-la agora!" Eles continuam evoluindo a funcionalidade.

O mindset outcome-driven envolve entender que é impossível saber tudo com antecedência, mas você pode aprender. O retrabalho nem sempre implica em um erro, talvez você tenha aprendido algo novo.

Como o guru do desenvolvimento de software Kent Beck diz:

A única maneira de tudo acontecer de acordo com o plano é se você não aprender nada.

Existe retrabalho bom e retrabalho ruim

Líderes outcome-driven entendem a diferença entre retrabalho bom e retrabalho ruim.

O retrabalho bom é intencional e envolve aprendizado e melhoria contínuos. Por exemplo, o retrabalho bom acontece quando aprendemos coisas novas, aprimoramos nossos produtos, nos adaptamos às mudanças ou usamos o desenvolvimento iterativo para melhorar e refinar nosso produto a cada ciclo.

O retrabalho ruim é não intencional e vem de práticas inadequadas. Por exemplo, o retrabalho ruim acontece quando não nos alinhamos em torno de um outcome claro, mudamos as prioridades com frequência, temos que corrigir os mesmos problemas repetidamente ou não fazemos discovery e acabamos construindo algo que ninguém quer.

Não estou dizendo que você deve passar todo o seu tempo reescrevendo seus OKRs ou redefinindo sua estratégia. Você precisa equilibrar a otimização de sua organização com o atingimento dos outcomes.

Se você passa todo o tempo "afiando seu machado" sem "cortar nenhuma lenha", está fazendo errado.

Você tem mais autonomia do que imagina

Às vezes, as pessoas sentem que são apenas uma engrenagem na máquina e não há nada que possam fazer. Eu também já me senti assim.

Mas quero encerrar este artigo lembrando que você tem mais autonomia do que imagina, mesmo como um colaborador individual em uma empresa enorme.

Me lembro de uma excelente história contada por Teresa Torres. É mais ou menos assim:

A única maneira de tudo acontecer de acordo com o plano é se você não aprender nada.

Um time reclamou para Teresa que não poderia fazer discovery de produto de maneira adequada porque a empresa não permitia que os times falassem diretamente com os clientes. Eles estavam proibidos de entrevistar os clientes finais e acreditavam que não havia nada que pudessem fazer.

Teresa perguntou ao time: existe alguma regra proibindo entrevistar os clientes de seus concorrentes?

Você pode aprender muito conversando com pessoas que não são seus clientes. Você pode aprender sobre suas necessidades, desejos e pontos problemáticos com o produto que estão usando atualmente.

Idealmente, você também deve entrevistar seus próprios clientes, mas não deixe que isso o impeça de aprender.

Você tem mais autonomia do que imagina.

Perguntas para discussão em grupo

Em breve, voltaremos com outro post. Enquanto isso, a melhor maneira de colocar este artigo em prática é discutir as ideias principais com seus colegas ou amigos.

Aqui estão algumas perguntas para ajudar:

• Como seria seu trabalho se você tratasse sua organização ou time como um produto?

• Questione algumas coisas que você faz - ou não faz - perguntando: "Isso ajudará a alcançar nossos outcomes desejados?" Depois de fazer a pergunta, o que você mudaria?

• Você está gastando tempo suficiente afiando seu machado?

• Você está usando OKR para evoluir como trabalha ou para manter as coisas como estão?

• Quais produtos organizacionais estão com data de validade vencida?

• De que maneiras você pode estar operando involuntariamente com um mindset fixo para trabalho?

• Onde você está resistindo ao bom retrabalho? Você está sendo vítima de retrabalhofobia?

Fique à vontade para comentar abaixo ou me enviar um e-mail.

Para os mais dedicados, segue abaixo uma lista de leitura com os links mencionados neste artigo (em inglês).

Abraço,

Felipe

Lista de leitura e links (em inglês):

• Big Think: Walter Isaacson on Steve Jobs’ Favorite Product: The Apple Team.

• Lenny’s Podcast: Zigging vs. zagging: How HubSpot built a $30B company | Dharmesh Shah (co-founder/CTO).

• Dharmesh Shah: Culture is a product you build for your people.

• John Gruber: Resigned.

• Ben Hunt-Davis: Will it make the boat go faster?

• Benedict Evans: Office, messaging and verbs.

• Mckinsey: 70% of transformations fail.

• Lex Fridman Podcast: Jeff Bezos: Amazon and Blue Origin

• Harvard Business Review: Meeting Overload Is a Fixable Problem.

• Carol Dweck: A Summary of Growth and Fixed Mindsets.

• Teresa Torres’ website.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Assine agora

Bem-vindo ao segundo artigo da série sobre como construir organizações outcome driven e obter resultados com OKR. 

Se você ainda não leu o primeiro artigo, é melhor voltar e lê-lo primeiro.

Este post também está disponível em Inglês.

Assine agora

Imagine se você pudesse aprender liderança com o homem que foi mentor dos fundadores da Apple (Steve Jobs), Amazon (Jeff Bezos) e Google (Larry Page e Sergey Brin). Você pode – pelo menos indiretamente.

Bill Campbell, "o Coach do Vale do Silício", faleceu em 2016, mas deixou uma história incrível que ilustra a essência da liderança outcome driven. Do livro Trillion Dollar Coach (ênfase minha):

[Bill Campbell] gostava de contar uma história sobre quando ele era [CEO] na Intuit e eles começaram a entrar em produtos bancários. Eles contrataram alguns gerentes de produto com experiência em bancos. Um dia, Bill estava em uma reunião com um desses gerentes de produto, que apresentou aos engenheiros uma lista de funcionalidades que ele queria que eles desenvolvessem.

Bill disse ao pobre gerente de produto: se você algum dia disser a um engenheiro na Intuit quais features você quer, te jogo na rua.

Você diz a eles qual problema o consumidor tem. Você dá a eles o contexto de quem é o consumidor. Então deixe que eles descubram as funcionalidades. Eles vão te dar uma solução muito melhor do que você jamais obterá dizendo a eles o que construir.

Isso não significa que você deixa os engenheiros saírem por aí, sem restrições, fazendo o que quiserem. Pelo contrário, os times de produto precisam atuar em parceria com [times como vendas, marketing e finanças] desde o início, integrados a um grupo multifuncional que impulsiona novas ideias que resolvem problemas e aproveitam oportunidades.

Diga às pessoas o que alcançar, não o que fazer

Em sua essência, construir uma organização outcome driven é uma questão de liderança. As atitudes dos times geralmente refletem sua liderança, então nada mudará a menos que os líderes se comprometam a desaprender e adotar uma maneira diferente de liderar.

Eu amo a história de Bill Campbell porque é um resumo nítido dessa forma diferente de liderar: liderança outcome driven.

A história é sobre times de produto em uma empresa “powered by” tecnologia, mas suas lições se aplicam a outros papéis também. Se você substituir "funcionalidades" por "projetos" e "o que construir" por "o que fazer", verá que qualquer líder pode aprender com essa história.

Líderes outcome driven dizem às pessoas o que alcançar em vez de dizer a elas o que fazer.

O gerente de produto na história queria dar aos times uma lista de funcionalidades para construir, mas Bill Campbell disse a ele para explicar o que ele queria alcançar:

Você diz a eles qual problema o consumidor tem. Você dá a eles o contexto de quem é o consumidor. Então deixe que eles descubram as funcionalidades.

Campbell também destacou por que isso é importante:

Eles vão te dar uma solução muito melhor do que você jamais obterá dizendo a eles o que construir.

Ao longo da história, diferentes grupos lidando com incerteza chegaram à mesma conclusão, embora com nomes diferentes. O autor Stephen Bungay chama isso de "liderar por meio da intenção". O exército moderno chama de "comando de missão", enquanto o exército prussiano do século 19 se referia a isso como auftragstaktik, ou táticas do tipo missão, onde a ênfase está no outcome de uma missão, e não nos meios específicos de alcançá-la.

Na liderança outcome-driven, começamos definindo claramente o outcome que queremos alcançar, por que é importante e as restrições e limites que temos para alcançá-lo.

Na vida real, sempre há restrições sobre o que podemos fazer. Por exemplo, você pode ter que alcançar o outcome até o final do trimestre ou dentro de um determinado orçamento.

Os líderes devem trabalhar em conjunto com os times e stakeholders de diferentes áreas para definir claramente essas restrições e estabelecer as diretrizes necessárias.

Bill Campbell acreditava que o caminho para o sucesso é "formar times de alto desempenho e dar a eles os recursos e a liberdade para fazer grandes coisas". Mas ele deixou claro que os líderes precisam estabelecer limites:

Isso não significa que você deixa os engenheiros saírem por aí, sem restrições, fazendo o que quiserem. Pelo contrário, os times de produto precisam atuar em parceria com [times como vendas, marketing e finanças] desde o início [...]

Dizer às pessoas o que alcançar é um ponto de partida crucial, mas os líderes também devem encontrar o equilíbrio certo no gerenciamento dos times para alcançar esses outcomes.

O Princípio de Cachinhos Dourados

Um dos meus temas recorrentes é que as pessoas tendem a ver as coisas em preto e branco, considerando-as totalmente boas ou totalmente ruins. Mas a solução não é ir para os extremos. A solução é encontrar o equilíbrio certo.

Essa ideia é frequentemente chamada de Princípio de Cachinhos Dourados, em referência à história em que uma garotinha—a Cachinhos Dourados—experimenta três tigelas diferentes de mingau e descobre que prefere aquela que está "na medida certa," nem muito quente nem muito fria.

Assim como a Cachinhos Dourados, times de alto desempenho precisam que as intervenções da gestão sejam feitas "na medida certa". Como Bill Campbell explicou, os líderes não devem dizer aos times quais funcionalidades construir, mas também não devem deixar os times fazerem o que quiserem.

Mas muitas pessoas acreditam que adotar OKR ou o modelo de produto significa que os líderes devem ser completamente hands-off ou "delargar." Fornecer qualquer direção ou orientação seria cometer uma ofensa imperdoável: microgerenciamento (micromanagement, em inglês).

No entanto, microgerenciamento não é a palavra certa. Ela implica que focar nos detalhes—as coisas micro—está sempre errado. Mas se os líderes querem construir uma cultura que valoriza a qualidade e a experiência do cliente, eles têm que prestar atenção aos detalhes.

Esse conceito está embutido em um dos princípios de liderança da Amazon, Mergulhar Fundo (ênfase minha):

Mergulhar fundo

Líderes operam em todos os níveis, estão atentos aos detalhes, monitoram o tempo todo e desconfiam quando as percepções não refletem as métricas. Nenhuma tarefa é pequena demais para eles.

Ninguém era mais obcecado por detalhes do que Steve Jobs. Tony Fadell, que liderou o desenvolvimento do iPod e do iPhone, descreve isso em seu livro Criar:

Examinar o produto em grande detalhe e se importar profundamente com a qualidade do que seu time está produzindo não é microgerenciamento. É exatamente o que você deveria estar fazendo. Lembro-me de Steve Jobs tirando uma lupa de joalheiro e olhando pixels individuais em uma tela para garantir que os gráficos da interface do usuário estivessem desenhados corretamente. Ele mostrava o mesmo nível de atenção a cada peça de hardware, cada palavra na embalagem. Foi assim que aprendemos o nível de detalhe que era esperado na Apple. E foi isso que começamos a esperar de nós mesmos.

Não estou dizendo que todo líder deve fazer o que Jobs fez, mas gerenciar as coisas micro e prestar atenção extrema aos detalhes nem sempre é errado.

Em vez de microgerenciamento, é útil pensar em termos de gerenciamento demais e gerenciamento de menos. Quando temos gerenciamento demais, os gestores intervêm em excesso ou nos lugares errados. Quando temos gerenciamento de menos, os gestores não intervêm o suficiente.

A tabela abaixo resume alguns sintomas que indicam quando temos gerenciamento demais ou de menos. 

Gestão na medida certa

Os líderes são responsáveis por criar as condições nas quais os times possam ter o melhor desempenho.

Isso significa que precisam buscar a gestão na medida certa—encontrar o equilíbrio certo de gestão para cada contexto, nem demais, nem de menos. 

Tony Fadell enfatizou a importância de encontrar esse equilíbrio:

Uma das partes mais difíceis da gestão é desapegar. Não fazer o trabalho você mesmo. Você tem que moderar seu medo de que se tornar mais hands-off fará com que o produto sofra ou que o projeto falhe. Você tem que confiar no seu time—dar a eles espaço para serem criativos e oportunidades para brilhar.

Mas você não pode exagerar—você não pode criar tanto espaço a ponto de não saber o que está acontecendo ou ser surpreendido pelo produto final. Você não pode deixar que ele deslize para a mediocridade porque você está preocupado em parecer autoritário demais. Mesmo que suas mãos não estejam no produto, elas ainda devem estar no volante.

Fadell novamente:

Como gestor, você deve estar focado em garantir que o time esteja produzindo o melhor produto possível. O outcome é seu negócio. Como o time alcança esse outcome é problema do time.

Isso não significa que o gestor sempre escolha o outcome sem nenhuma participação do time. Significa que o gestor é, em última análise, responsável pelo desempenho do time e pela realização do outcome.

Os perigos do excesso e da falta de gestão

Outro princípio da liderança outcome driven é não desperdice talento. Não jogue fora o talento de todas as pessoas competentes e dedicadas da sua organização.

Quando vamos aos extremos de gerir demais ou de menos, desperdiçamos talento. 

Conversar com diferentes times pode tornar essa discussão mais concreta. Vamos usar um excelente exemplo de Henrik Kniberg, que eu adaptei.

Imagine fazer a mesma pergunta para três times: No que vocês estão trabalhando e por quê?

Perguntamos ao primeiro time e eles nos dizem que estão implementando os requisitos do app de autoatendimento porque os stakeholders pediram. Eles dizem: “Nossa meta é entregar o projeto até 15 de junho.”

Os líderes trataram o time como tiradores de pedidos, dizendo a eles quais funcionalidades queriam. Essa atitude é típica de executivos sabe-tudo e é exatamente o que fez Bill Campbell querer jogar o gerente de produto na rua.

Quando os líderes tratam os times como tiradores de pedidos, eles obstruem o talento dos colaboradores e matam a inovação. Como Kent Beck explica:

Se você tratar as pessoas como peças de xadrez, não se surpreenda se elas mostrarem a iniciativa e a criatividade de peças de xadrez.

Gerenciamento de menos também desperdiça talento

A maioria das pessoas não percebe, mas as empresas também desperdiçam talento quando líderes não gerenciam o suficiente os times. Vamos conversar com o segundo time para entender por quê.

O segundo time diz que está trabalhando em um app de Bitcoin porque acham que é uma boa ideia. "Queremos lançá-lo até o fim do ano", dizem eles.

O problema aqui é que o time tomou uma decisão sem considerar as necessidades dos clientes ou do negócio, e sem evidências sólidas que apoiassem esta decisão. Os líderes adotaram uma abordagem completamente hands-off, ignorando o alerta de Bill Campbell e permitindo que o time fizesse o que quisesse.

No entanto, quando os líderes não gerenciam o suficiente, eles desperdiçam talento. Os times precisam de orientação, treinamento e apoio para ter o melhor desempenho. Você não obtém times de alto desempenho de graça—você tem que trabalhar para isso.

Atletas e artistas de alto desempenho sempre têm treinadores e gestores que os orientam e apoiam. Times de alto desempenho não são diferentes. Vamos conversar com o terceiro time para ver um exemplo.

O terceiro time diz que está testando ideias para o aplicativo de autoatendimento para reduzir a taxa de contato (contact rate em inglês). Esta métrica mede o número de vezes que os clientes contatam uma empresa buscando ajuda em um determinado período, e o time explica que isso é importante para melhorar a experiência do cliente e reduzir custos.

Este time:

• Está focado em fazer a diferença, não apenas cumprir prazos. 

• Explicou claramente o outcome que queriam alcançar e por que ele é importante.

• Entende as necessidades dos clientes e do negócio.

• Compreende as métricas principais associadas ao seu trabalho.

• Entende como seu trabalho contribui para o sucesso da organização.

Isso foi possível porque os líderes orientaram e mentoraram o time, ajudando-os a desenvolver os músculos e mindsets necessários para ter o melhor desempenho.

Alinhamento não acontece por acaso

Outro problema em deixar os times livres sem restrições é que o alinhamento não acontece magicamente. Sem orientação, cada time seguirá numa direção diferente, e vamos desperdiçar seu talento. Sem direcionamento top-down, não existe alinhamento.

A liderança sênior da Amazon tomou cuidados especiais anos atrás ao fazer a transição para times autônomos—times criados para operar com pouca ou nenhuma coordenação com outros. Como escreveram os ex-executivos Colin Bryar e Bill Carr no livro Obsessão pelo cliente:

Times autônomos são construídos para serem rápidos. Quando estão alinhados em direção a um destino comum, podem avançar muito em pouco tempo. Mas, quando estão mal alinhados, o time pode se desviar do curso rapidamente. Portanto, eles precisam ser direcionados para o caminho certo e ter as ferramentas para corrigir rapidamente o curso quando necessário.

Para garantir o alinhamento, cada novo time autônomo tinha que se reunir com o CEO Jeff Bezos e o executivo sênior que liderava o time. Juntos, eles discutiam a composição do time, o propósito e as métricas usadas para medir o progresso.

Hoje em dia, é impossível para cada novo time ter reuniões com o CEO, dado o tamanho da Amazon. Mas os diferentes gestores podem adotar uma abordagem semelhante para criar alinhamento.

A maioria das empresas já sofre com a falta de alinhamento. Você acha que deixar as pessoas fazerem o que quiserem vai melhorar a situação?

Encontrando o equilíbrio certo de gestão para cada contexto

Gerenciamento demais ou de menos são conceitos relativos. O que é gestão "na medida certa" para uma situação pode ser excessivo ou insuficiente para outra.

Precisamos encontrar o equilíbrio certo para cada contexto. Em alguns casos, os times podem precisar de orientações mais específicas e monitoramento mais próximo.

Por exemplo, a Intuit1 de Bill Campbell fornece um produto para declarações do imposto de renda americano (o TurboTax), então eles precisam seguir regulamentações, que podem incluir funcionalidades obrigatórias.

Não informar os times sobre as funcionalidades obrigatórias seria um caso grave de gerenciamento de menos. Mas dar a eles uma especificação fixa de como construir as funcionalidades poderia ser gerenciamento demais.

Líderes fortes buscam o equilíbrio certo. Eles ajudam os times de produto a colaborar com o jurídico para entender como cumprir os regulamentos enquanto fornecem uma boa experiência ao cliente.  Mas se o governo exige alguma informação sobre o usuário, os líderes garantem que os times a coletem.

O produto também tem uma data de entrega clara: tudo precisa estar pronto bem antes de 15 de abril, quando os americanos precisam enviar suas declarações de imposto de renda. Este é um ótimo lembrete de que todas as organizações usam tanto outcomes quanto datas para gerenciar o trabalho. Sempre há casos em que precisamos nos comprometer com datas devido a regulamentos, contratos ou eventos como a entrega do imposto de renda. 

A diferença é que essas datas e funcionalidades obrigatórias não são arbitrárias. Elas não são apenas algo que um executivo sabe-tudo considera importante baseado em pouca ou nenhuma evidência.

Também não podemos desperdiçar o talento dos líderes

Empresas que adotam uma abordagem completamente "bottom-up" também estão desperdiçando o talento da liderança. Quando os reportes diretos deixam de trabalhar junto com seus gestores ou solicitar ajuda, eles fazem o mesmo.

Existem muitos maus gerentes por aí, mas isso não significa que todos trabalhem para o chefe do Dilbert. Há muitos líderes talentosos e experientes, e não podemos desperdiçar seu talento.

Os times estão mais próximos do problema e conhecem detalhes locais e específicos, enquanto os líderes entendem a visão geral e possuem mais senioridade. O verdadeiro poder vem da colaboração entre eles.

Como Marty Cagan explica no livro Empowered, times de alto desempenho não precisam de menos gestão. Eles precisam de uma gestão melhor. Eles precisam de gestores que possam ajudar os times a ter o melhor desempenho.

Isso significa que líderes também precisam desenvolver os músculos e mindsets necessários para que possam orientar, apoiar e alinhar os times adequadamente.

Os gestores de nível médio são essenciais

Falamos muito sobre líderes, mas tudo o que discutimos se aplica a qualquer pessoa que seja um gestor de pessoas, alguém que supervisiona uma equipe de colaboradores.

Os gestores de nível médio (ou middle management) são cruciais para manter as organizações funcionando, como os fundadores do Google descobriram em 2001.

Naquele ano, Larry Page e Sergey Brin decidiram que 130 engenheiros reportariam diretamente ao VP Wayne Rosing. Gerentes não eram mais necessários, já que os engenheiros se "auto-organizariam".

Bill Campbell, que estava mentorando os fundadores, não ficou feliz com a ideia, então ele e Page decidiram perguntar a opinião dos engenheiros. Um após o outro, os engenheiros disseram que queriam ter um gerente. Eles queriam alguém com quem pudessem aprender e precisavam de alguém para ajudar quando as discussões com colegas chegassem a um impasse.

Page seguiu com o plano mesmo assim, mas a ideia de "auto-organização" não saiu como esperado. Alguns engenheiros gostaram de não serem excessivamente gerenciados por chefes ruins, mas muitos detestaram as consequências de ficarem sem gestão alguma.

Como Douglas Edwards, funcionário número 59 do Google, escreveu em "I’m Feeling Lucky" (ênfase minha):

Era o sonho ou um pouco de pesadelo de um engenheiro, dependendo para quem você perguntasse. Nenhum chefe desinformado poderia interferir e estragar tudo, mas não havia sinais claros vindos de cima sobre o que era importante e o que era urgente e o que era ambos. Grupos lutavam por recursos e combatiam redundâncias. Alguns engenheiros queriam mais feedback sobre o que estavam fazendo e sobre seu desempenho, e outros se perguntavam sobre oportunidades de crescimento.

No final, o experimento durou pouco tempo. O Google rapidamente entendeu os problemas causados por gerenciamento de menos e em seis semanas os gerentes estavam de volta2.

Em breve estaremos de volta

Em breve estarei de volta com outro artigo em nossa série sobre como construir organizações outcome driven e obter resultados com OKR.

Enquanto isso, adoraria ouvir de você. Sinta-se à vontade para deixar seus comentários abaixo ou me enviar um e-mail.

Um agradecimento especial a Itamar Gilad por revisar os rascunhos deste artigo, e a Carlos Accioly e Melissa Suzuno por ajudarem na sua edição e desenvolvimento.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Assine agora

Este post também está disponível em Inglês.

Assine agora

Você provavelmente já percebeu que OKR não é uma bala de prata capaz de resolver magicamente todos os seus problemas.

Parece que todo mundo está usando OKR. Infelizmente, a maioria das empresas que tentaram usar OKR ficaram decepcionadas com os resultados.

No entanto, embora OKR normalmente não corresponda às expectativas (muitas vezes irrealistas), os desafios que criam a demanda por OKR são reais.

Nos últimos dez anos, conversei com centenas de empresas sobre quais problemas elas queriam resolver com OKR. Os mesmos 12 desafios apareceram repetidamente, independentemente de a empresa usar ou não OKR.

Aposto que você vai se identificar com alguns deles:

1. Os concorrentes estão inovando mais rápido do que você.

2. Os colaboradores não entendem como seu trabalho contribui para a estratégia.

3. As pessoas não estão se movendo na mesma direção. Os times geralmente definem prioridades conflitantes.

4. A organização tem prioridades demais.

5. A CFO está frustrada com os baixos retornos dos investimentos em tecnologia.

6. Uma grande parte do orçamento é alocada para projetos, mas a organização não consegue medir os resultados desses projetos.

7. Muitos OKRs (ou metas) dentro da organização são baseados em projetos, como “Lançar o novo site”, “Implantar o MVP” ou “Migrar 100% dos servidores para a nuvem”.

8. A organização frequentemente avalia os colaboradores com base em sua capacidade de cumprir prazos. Não importa se eles ajudaram a empresa ou não.

9. A empresa tem muitos dashboards, mas muitas vezes as pessoas não usam dados para orientar as decisões do dia a dia ou obter insights.

10. Os colaboradores estão pedindo mais autonomia e um propósito claro.

11. Os colaboradores resistem a estabelecer OKRs (ou metas) ambiciosos, admitir erros ou fazer perguntas.

12. As pessoas não assumem a responsabilidade por seus OKRs (ou metas). As pessoas os veem como uma formalidade e não como algo que orienta seu trabalho diário.

Se esses desafios soam muito próximos da sua realidade, não se sinta mal. Não é culpa sua.

Mas você precisa fazer algo a respeito.

OKR é uma ferramenta, não uma bala de prata

Dada toda a decepção com OKR, algumas pessoas estão procurando alternativas melhores.

Mas quer você opte por usar OKR ou qualquer outra técnica, você precisa entender que elas não são balas de prata. Eles são apenas ferramentas, e os resultados obtidos com qualquer ferramenta dependem de como você a usa.

Como diz Benedict Evans, as pessoas têm uma tendência clara quando obtêm novas ferramentas:

Há um velho ditado que diz que, quando adquirimos uma nova ferramenta, começamos adaptando a ferramenta à maneira antiga de trabalhar e depois mudamos a forma como trabalhamos para se adequar à nova ferramenta.

99% das pessoas adaptam OKR à sua maneira antiga de trabalhar. Como aquela definição popular de insanidade, eles continuam fazendo a mesma coisa e esperam resultados diferentes.

É compreensível que tantos fiquem desapontados. E provavelmente também ficarão desapontados com a próxima ferramenta.

Tentar enfrentar esses 12 desafios apenas com OKR é como tentar curar uma perna quebrada com uma bolsa de gelo.

Embora OKR possa ajudar a aliviar alguns sintomas se usado corretamente — e esse é um “se” enorme — ele não é suficiente para endereçar as causas estruturais e mais profundas.

Se você perdeu completamente a fé em OKR, pode optar por usar outra coisa. Mas você precisa entender que substituir OKR por outra ferramenta é como comprar uma bolsa de gelo diferente. Sozinha, ela não vai mudar muita coisa.

Você tem que endereçar as causas mais profundas

Esta situação é semelhante a uma experiência que tive recentemente com uma fisioterapeuta. Ela me disse que eu tinha que desaprender a maneira como andava.

Eu vinha tendo fortes dores nas costas há anos. Às vezes, o lado direito das minhas costas travava e eu não conseguia me mover. Não era nada divertido.

A principal causa are que os músculos do meu lado esquerdo estavam muito fracos, enquanto os do lado direito eram muito fortes. Isso me fazia inclinar para a direita enquanto andava, ficava em pé ou sentava, causando muita dor.

Você também está lidando com músculos fracos

Você e sua organização também estão lidando com músculos fracos, começando pelos “músculos de outcome”. Mas o que isso significa?

Todas as organizações utilizam duas abordagens para gerenciar o trabalho, muitas vezes sem perceber.

Primeiro, existe a abordagem de datas, onde o objetivo é cumprir prazos. Se você trabalha em uma empresa tradicional, talvez a conheça por um nome diferente: abordagem PMO (Project Management Office ou escritório de projetos).

Algumas pessoas chamam isso de abordagem de outputs, mas pode ser um termo confuso (veja o texto explicativo no final do artigo).

Quando usamos a abordagem de datas, não importa se nosso projeto fez diferença ou não. Nosso objetivo é simplesmente concluir projetos dentro do prazo, orçamento e escopo.

Aqui, as datas dizem se tivemos sucesso.

A segunda abordagem é a abordagem de outcomes, onde o objetivo é fazer a diferença. Como Marty Cagan me disse uma vez:

Todos sabemos que fazemos coisas e que algumas delas fazem a diferença, enquanto outras não. A abordagem de outcomes consiste em focar na diferença que estamos tentando fazer e não perdê-la de vista.

Quando usamos a abordagem de outcomes, nosso trabalho não termina quando concluímos os projetos. Temos que ir testando diferentes opções até alcançarmos o resultado. Entregar projetos é importante, mas não é o objetivo.

Aqui, os dados dizem se tivemos sucesso.

Todas as empresas usam as duas abordagens para gerenciar o trabalho, mas seus “músculos de outcomes” provavelmente estão muito fracos, enquanto seus “músculos de datas” são muito fortes.

Essa fraqueza está fazendo com que sua organização dependa fortemente da abordagem de datas. Você está tendo uma overdose de datas.

As empresas têm muitos dashboards, mas a maioria ainda gerencia o trabalho com base em datas. Muitas vezes temos algo parecido com a imagem abaixo, onde a organização gerencia involuntariamente uma grande parte de seus investimentos usando datas.

Mais Outcomes, Menos Datas™

Há um “slogan” que representa a mudança para resultados, facilitando o diálogo sobre a nova cultura: Mais Outcomes, Menos Datas™.

A ideia central por trás de Mais Outcomes, Menos Datas™ é aumentar intencionalmente a “parcela” de nossos investimentos gerenciados com resultados e dados ao longo do tempo.

Não estamos falando de zero datas, mas de menos datas.

É da natureza humana querer tornar tudo binário: as coisas são completamente boas ou completamente ruins. Este desejo de simplificar demais as coisas cria várias confusões que temos que esclarecer.

Vamos começar com a primeira: a ideia de que você precisa usar zero datas.

Todas as organizações utilizam as duas abordagens para gerir trabalho. A menos que você seja uma agência governamental na Coreia do Norte, não poderá sobreviver gerenciando 100% do trabalho usando datas.

Da mesma forma, nenhuma organização gerencia 100% dos seus investimentos somente com base em outcomes. Sempre há casos em que precisamos nos comprometer com datas, seja por causa de eventos como a Black Friday ou para cumprir regulamentações e contratos.

A solução não é ir para os extremos. A solução é encontrar o equilíbrio certo. Isso não significa uma divisão precisa 50/50, significa que você tem que escolher a abordagem certa para cada contexto.

Mais Outcomes, Menos Datas foca em escolher deliberadamente a melhor abordagem para cada situação. E para que isso aconteça, temos que desenvolver não apenas novos músculos, mas também novos mindsets.

Seus músculos fracos não são a única coisa que causa a overdose de datas

Existe outra causa estrutural e mais profunda para os seus desafios: o mindset sabe-tudo, onde acreditamos ter todas as respostas e entender de tudo.

As marcas do mindset sabe-tudo são frases como “Isso obviamente vai funcionar, não precisamos medir”, “Sabemos o que estamos fazendo” e “Sempre fizemos assim”.

Quando você se pega usando frases como essas, é um sinal de que você entrou no modo sabe-tudo. Todos nós agimos como sabe-tudo de vez em quando—com mais frequência do que percebemos.

Quando adotamos o mindset sabe-tudo, assumimos implicitamente que nossos projetos terão sucesso, desde que cumpram o prazo e o orçamento. Entregar projetos passa a ser sinônimo de gerar resultados, e nos baseamos ainda mais em datas. 

O mindset sabe-tudo não está apenas na cabeça das pessoas. Também está profundamente enraizado nas culturas e processos da maioria das organizações. Podemos dizer que estamos lidando com sabetudismo estrutural.

Pense nisso: quantos incentivos da sua organização reforçam o mindset sabe-tudo? Quantos processos assumem que entregar projetos é sinônimo de gerar resultados? Com que frequência você mede se cada projeto realmente alcançou os resultados desejados?

A overdose de datas causa muitos problemas

O uso excessivo de datas contribui para muitos dos 12 desafios que vimos no início do artigo.

As empresas com músculos de outcomes fracos têm dificuldade para medir os resultados dos seus investimentos. Isso significa que eles não sabem o que está funcionando ou não, levando a baixos retornos.

Parafraseando John Wanamaker, metade do dinheiro que eu gasto em projetos é desperdiçado. O problema é que não sei qual metade. E essa pode ser uma avaliação conservadora, visto que algumas fontes alegam que o desperdício é muito maior.

Executivos que sabem tudo muitas vezes tratam os colaboradores como tiradores de pedidos que simplesmente entregam projetos. Esta mentalidade reduz drasticamente sua autonomia e mata a inovação – fatores críticos para alcançar resultados.

A abordagem de datas muitas vezes faz com que os colaboradores se sintam como hamsters, correndo sem parar em suas rodas, mas nunca chegando a lugar nenhum. Isto rouba seu senso de propósito, prejudicando seu engajamento e retenção.

E, quando as pessoas só conseguem ver projetos e datas, elas têm dificuldade para entender a estratégia ou como contribuem para ela.

Finalmente, o uso excessivo de datas também constrói a cultura errada: uma cultura que valoriza entregar projetos ao invés de fazer a diferença. Cumprir prazos é mais fácil do que alcançar resultados.

As melhores empresas entendem todos os problemas causados pela overdose de datas e pelo mindset sabe-tudo. É por isso que adotam um mindset completamente diferente para liderar pessoas, gerir o trabalho e desenvolver produtos.

As melhores empresas de hoje são outcome driven

As organizações mais bem-sucedidas no mundo atual, como Amazon e Apple, são outcome driven1.

Ser outcome driven significa ser movido pela vontade de fazer a diferença, não apenas por concluir projetos. Significa focar intencionalmente nos outcomes que você deseja alcançar, em vez de apenas realizar tarefas mecanicamente, sem pensar muito.

As empresas outcome driven definem o sucesso com base em outcomes, mas não param por aí. Eles também alinham toda a organização para alcançar estes outcomes: todas as decisões, ações, processos e práticas.

O mindset outcome driven requer esforço deliberado e um ambiente que o apoie

Os seres humanos não são naturalmente programados para serem outcome driven. Sem direção, nossos cérebros tendem a cair no mindset sabe-tudo, assim como costumamos cair no vício de passar horas em nossos smartphones.

Não evoluímos para sermos outcome driven, da mesma forma que não evoluímos para lidar com o mundo dos smartphones e das redes sociais.

Qualquer pessoa pode adotar o mindset outcome driven, mas isso requer um esforço consciente e deliberado.

No entanto, não basta dedicação individual. A organização também precisa ter uma cultura e mecanismos que apoiem o mindset outcome driven. Mas a maioria das empresas não tem isso.

A maioria das organizações não está preparada para outcomes

O mindset outcome driven é uma maneira fundamentalmente diferente de liderar pessoas e gerenciar o trabalho. Ele não se encaixa nas capacidades organizacionais, processos ou culturas existentes na maioria das empresas. Também não corresponde às competências e mindsets da maioria dos indivíduos.

Isso deixa você com duas opções: se você quiser dizer que é outcome driven, pode simplesmente diluir o conceito para que se adeque à sua maneira tradicional de trabalhar.

Mas para se beneficiar de ser outcome driven, você precisa mudar radicalmente a cultura e a maneira de operar da sua organização.

A primeira coisa a fazer é desenvolver aqueles músculos fracos de que falamos.

Líderes e colaboradores precisam desenvolver as competências necessárias, mas treinamento é somente parte da solução. Você também precisa mudar a forma como as pessoas trabalham para que possam aplicar essas novas habilidades. 

A empresa também precisa desenvolver as capacidades organizacionais necessárias. Por exemplo, a empresa coleta todos os dados necessários para saber se os seus investimentos estão fazendo a diferença?

Desenvolver os músculos fracos não basta, assim como não bastou para mim.

Assim como eu tive que desaprender a maneira como eu andava, você precisa desaprender a maneira como você trabalha.

Os líderes seniores e os colaboradores individuais têm de desaprender os mindsets, comportamentos e métodos que contribuíram para esta situação.

A organização também precisa abandonar qualquer prática que reforce comportamentos antigos. Se um processo, fluxo de trabalho, métrica ou incentivo estimula comportamentos antigos, você precisa abandoná-lo.

Você pode progredir aos poucos

Depois de ler este artigo, você pode sentir que construir uma cultura outcome driven é impossível, enquanto outros podem pensar que é algo fácil. Este é mais um daqueles casos em que a resposta não está nos extremos, mas em algum ponto intermediário.

Construir uma cultura outcome driven é uma jornada, mas o progresso pode ser feito gradualmente. 

Não é uma mudança que acontece da noite para o dia, mas é possível melhorar a cada trimestre.

O que ler em seguida

Estou escrevendo mais artigos sobre como construir organizações outcome-driven e obter resultados com OKR.

Quero que este post atue como uma "central" que te direciona para o que ler em seguida.

Aqui estão os artigos que publiquei até agora, agrupados em diferentes tópicos.

Liderança outcome-driven

Ser outcome driven está fundamentalmente ligado à liderança. Nada vai mudar a menos que os líderes se comprometam a adotar uma nova forma diferente de liderar. Os dois artigos abaixo falam sobre o que isso significa.

• Você está desperdiçando talento com OKR?

Times de alto desempenho precisam de gestão na medida certa, nem demais, nem de menos.

• Por que você deve tratar sua empresa como um produto.

Líderes outcome-driven enxergam as organizações como algo que eles podem alterar, testar e evoluir. Como um produto.

Entendendo outcomes

Existe muita confusão sobre o que outcomes realmente são. Os artigos abaixo podem ajudar a esclarecer isso.

• Um OKR deve medir o outcome, não o projeto.

Desenvolva seus músculos de outcome aprendendo a separar outcomes de projetos e métricas de projeto

• E se você não conseguir medir o outcome?

Coloque seus investimentos em duas "caixas”: OKR + Projetos

Quero seu feedback

Você tem alguma dúvida ou opinião sobre este artigo? Alguma sugestão para tópicos futuros?

Sinta-se à vontade para deixar seus comentários abaixo ou me enviar um e-mail. E se você achar este artigo útil, por favor compartilhe com outras pessoas.

Agradecimento

Agradecimentos especiais a Marty Cagan, Itamar Gilad, Ian Harvey e André Carregal por revisarem os rascunhos deste artigo, e a Carlos Accioly e Melissa Suzuno por ajudarem na sua edição e desenvolvimento.

Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.

Assine agora

Como funciona OKR na prática na empresa que o popularizou? Eu sei que muitos leitores têm curiosidade sobre o uso de OKR no Google, então fico feliz em apresentá-los a Itamar Gilad, o qual, como ex-gerente de produto e líder de expansão do Gmail, ajudou, entre outras coisas, a lançar a funcionalidade de Caixa de Entrada com Guias e fazer o Gmail passar de 400 milhões a 1 bilhão de usuários.

Como coach em gestão de produto e estratégia, treinador e palestrante, Itamar desenvolveu diversas ferramentas que auxiliam os times a tomar decisões melhores sobre os produtos. Melissa Suzuno, minha editora do blog, recentemente conversou com Itamar para discutir suas experiências com OKR no Google.

Nos fale um pouco sobre você.

Itamar: Eu me formei como engenheiro de software e trabalhei como gerente de engenharia e desenvolvimento de software por cinco anos. Então, eu me dei conta de que gerenciar desenvolvedores não era a minha praia e troquei para gerenciamento de produto, o que foi provavelmente uma boa ideia, porque eu me mantive nessa área nos 15 anos seguintes em diversas companhias, incluindo Google e Microsoft. No Google, eu era líder de produto e de expansão para o Gmail. Desde que eu saí do Google, há três anos, eu tenho trabalhado como coach de gestão de produto e estratégia, escritor e palestrante. 

Como era o processo de OKR no Gmail quando você estava lá?

Itamar: O Google usa OKRs em múltiplos níveis: Empresa, Área de Produto (o que é similar a uma divisão - Android, Chrome e Geo como exemplos de áreas de produto) e Produto (tais como Gmail, Maps e Chrome). Então, dentro dos produtos, pode haver outros subníveis, mas no mínimo cada time de produto (geralmente 3 a 15 pessoas) deve ter seus próprios OKRs. Quando eu estava no Google, algumas pessoas usavam OKRs pessoais e outras não.

Você esperaria que, com todos esses níveis, o processo seria complicado e demorado, com longas rodadas de revisão, mas na verdade não é. Diferentes áreas de produtos e produtos podem usar diferentes abordagens. O Google geralmente confia que seus colaboradores e times sabem o que fazem e raramente impõe o mesmo processo sobre o quadro inteiro.

O Google geralmente confia que seus colaboradores e times sabem o que fazem e raramente impõe o mesmo processo sobre o quadro inteiro.

No Gmail, normalmente durante a temporada de OKR, normalmente eu recebia um rascunho do OKR geral do Gmail dos meus gestores. Algumas das coisas desse rascunho eram derivadas de níveis superiores e algumas eram específicas do Gmail. Em seguida, eu discutia com meus colegas quais OKRs eram aplicáveis ​​à minha área de responsabilidade e copiava essas partes (Objetivos, Key Results ou ambos) em um documento, mas também podia e devia criar meus próprios OKRs. Alguns Key Results podem propagar até o OKR do produto, o OKR da área do produto ou mesmo os OKRs da empresa.

Por exemplo, como head de growth, eu projetava os usuários ativos mensais e semanais do Gmail até o final do trimestre, e esses números costumavam propagar até os OKRs do Google. Muitas discussões e negociações eram feitas por email. Em um ciclo normal de OKR, passávamos algumas horas (todos juntos) no nível do time e alguns dias acima, na hierarquia.

Nós também usávamos OKRs compartilhados para coordenar times, grupos e produtos ao redor de uma meta comum. Trata-se de uma ferramenta muito poderosa quando usada corretamente.

Você pode nos dar um exemplo de como era na prática?

Itamar: Quando em entrei no Gmail, nós estávamos falando sobre impulsionar o engajamento de usuários casuais, pessoas que usam e-mail para fins pessoais, por meio do produto. Naquele tempo, o Facebook estava conseguindo muito engajamento e eu acho que isso fez com que concentrássemos nossa atenção nessa métrica-chave. São produtos muito diferentes e, olhando para trás, provavelmente não era a base certa de comparação.

O Objetivo era fácil - queríamos aumentar o nível de engajamento dos usuários casuais. Mas, quando se tratava dos Key Results, não era tão simples. Devíamos focar em fazer com que os usuários lessem mais mensagens? Esse não era necessariamente um bom Key Result, porque “ler mais mensagens” pode ser o resultado de obter mais emails promocionais e notificações sociais. Os usuários poderiam estar engajados, mas pelos motivos errados.

Outra métrica que considerávamos eram as mensagens enviadas. No entanto, as pessoas não necessariamente precisam enviar tantas mensagens pessoais atualmente. Elas têm chats e mídias sociais, então o número de e-mails enviados não significa necessariamente que o programa de e-mail não seja atraente.

Então percebemos que talvez estivéssemos fazendo a pergunta errada. Fizemos uma pesquisa – entrevistamos pessoas e fizemos uma análise quantitativa, e nos demos conta de que as pessoas tinham muitos e-mails de propaganda e notificações, que lotavam as caixas delas e dificultavam que elas encontrassem as mensagens que realmente queriam ler.

Percebemos que a meta principal que deveríamos estabelecer não era impulsionar engajamento, mas fomentar o engajamento com o tipo certo de e-mail – permitindo que as pessoas lessem apenas os e-mails com os quais realmente se importassem e interagissem umas com as outras de uma maneira diferente.

Percebemos que a meta principal que deveríamos estabelecer não era impulsionar engajamento, mas fomentar o engajamento com o tipo certo de e-mail.

Portanto, criamos um OKR parecido com o exemplo abaixo:

Usuários casuais tem fácil acesso aos seus mais importantes

• Atingir uma percentagem das mensagens “Principais” lidas > X%

• Atingir uma taxa de falsos positivos < Y%

• Atingir uma taxa de falsos negativos < Z%

Falsos positivos são mensagens que achamos que seriam importantes, mas acabaram não sendo. Falsos negativos são mensagens que achamos que não seriam importantes, mas acabaram sendo.

Isso nos levou a um grande projeto que culminou com o lançamento da caixa de entrada com guias inteligentes, que dividem seus e-mails em Principal, Social, Promoções e outra guias. Inicialmente, era uma funcionalidade que planejávamos lançar somente na versão desktop. Mas conforme começamos a testar, percebemos que o problema era ainda maior na versão mobile. Concluímos que isso precisava ser um OKR compartilhado com os times do Gmail para Android e iOS.

Naquela época, o Gmail para Android era parte da área de produto do Android, uma divisão completamente diferente no Google e que tinha seu próprio conjunto de objetivos, então, eu fui até eles. Apresentei o problema e perguntei se poderíamos compartilhar o OKR de aliviar a dor desses usuários de e-mail casuais e, felizmente, eles concordaram.

Quando eu ensino OKRs, eu digo que o lado bom dos OKRs compartilhados é que às vezes você recebe um “não” e então você sabe que isso não deve ser seu foco, pelo menos não naquele trimestre. Mas, nesse caso particular, eles disseram sim, e nós co-lançamos a nova caixa de entrada para os clientes do Gmail. Impactamos centenas de milhões de pessoas com essa mudança grande e visível, a qual foi muito bem recebida, graças ao poder dos OKRs compartilhados.

Como você descreveria o alinhamento no Google, incluindo entre times?

Itamar: De todas as empresas em que eu já trabalhei, o Google é onde as pessoas estão mais “por dentro.” As pessoas entendem o que a companhia está tentando alcançar e isso ajuda na comunicação entre times, e de cima para baixo, e isso se deve em parte ao fato de a gestão do Google investir um grande esforço compartilhando tanto metas quanto a motivação por trás delas. Isso não significa que nós sempre concordávamos – frequentemente havia discussão, o que é muito importante também – mas você pode falar com qualquer um e ele provavelmente sabe por que o seu produto tem certas metas estabelecidas.

Eu também diria que o processo cria muito alinhamento entre os times. Por exemplo, se o seu produto está ocupado em melhorar o desempenho em mercados emergentes, há uma boa chance de que outros produtos similares tenham herdado a mesma meta, e isso facilita na colaboração (o que é importante porque há muitas integrações entre os produtos e sistemas do Google). Se todos estão seguindo direções completamente diferentes, a discussão se torna mais difícil.

Como todas essas informações sobre OKRs são comunicadas?

Itamar: Havia reuniões trimestrais com todo mundo. As análises de OKR em nível de empresa eram transmitidas ao vivo e gravadas. O CEO e os vice-presidentes seniors analisavam os OKRs do trimestre anterior e como nos saímos e, em seguida, definiam os OKRs para o próximo trimestre. Há uma transparência extrema.

Em nível de produto, como o Gmail, nos reuníamos todos de um produto específico para discutir nossos OKRs. Em nível de time, também tínhamos reuniões para revisar OKRs, então havia muita comunicação. Uma vez que você cria seus OKRs, eles são todos transparentes, então qualquer um pode abrir os OKRs de qualquer outra pessoas e nunca há segredo sobre eles. É muito fácil entender em que as pessoas estão trabalhando.

Em sua visão, como o Google poderia melhorar a maneira como usa OKR?

Itamar: O Google começou a usar OKR em uma época em que OKRs de entrega (OKRs que especificam atividades mais do que resultados) ainda eram a regra. Por essa razão, você podia encontrar OKRs de entrega no Google durante o tempo em que estive lá, embora eu acredite que as coisas tenham melhorado desde então.

OKRs de entrega são algo que encontro muito em quase todas as empresas. A maioria das pessoas tem consciência de que especificar “Lançar X” não é um bom Key Result e tentam evitá-lo, mas há muitas maneiras de disfarçar OKRs de entrega como OKRs de resultado – eu sei, porque eu também já fiz isso.

O cenário clássico é quando você se apaixona por uma ideia, constrói um projeto em torno dela, e o OKR é lembrado somente depois. Já nos convencemos de que esta é a ideia certa, mas agora precisamos de um OKR. Se for muito difícil para você escrever OKRs, pode ser que você tenha ido um passo além e já tenha decidido as atividades.

Se for muito difícil para você escrever OKRs, pode ser que você tenha ido um passo além e já tenha decidido as atividades.

Existem maneiras sutis de contornar essa questão. Por exemplo, um Key Result como “No próximo trimestre nós esperamos que 45% de nossos usuários usem o novo fluxo de integração”. Parece ótimo – é um resultado, é mensurável – mas quem realmente disse que esse novo fluxo de integração é uma coisa boa?

Esse OKR está na verdade disfarçando o fato de que nossa missão é lançar o novo fluxo de integração. Então não é um bom resultado. Um bom resultado seria baseado no que o novo fluxo de integração proporciona aos usuários – reduziria o tempo de integração? Aumentaria a taxa de sucesso da integração? Algum outro benefício? Esse tipo de OKR é válido apenas se você já o testou minuciosamente e possui evidências muito fortes de que o novo fluxo de integração está realmente ajudando essas outras métricas importantes.

O Google também conta muito com grandes temas para conduzir a estratégia da empresa. Por exemplo, no passado, Mobile-first/Mobile-only era sobre a criação de recursos e capacidades para pessoas que usavam principalmente ou apenas o produto no celular. Hoje, isso parece óbvio, mas no início de 2010, esse era um bom tema para se concentrar.

Os temas eram geralmente refletidos nos OKRs como metas. O risco aqui é que às vezes as pessoas criam coisas porque elas se alinham com o tema, mesmo que não ajudem de fato os usuários ou os negócios.

Um exemplo seria um produto predominantemente para desktop, que congela o desenvolvimento de todos os produtos para computadores, a fim de se concentrar nos usuários que usam dispositivos móveis, mesmo que não haja evidências de que esse segmento de mercado esteja prestes a se tornar importante o suficiente para justificar um investimento tão grande.

Supõe-se que o alinhamento com o tema seja evidência suficiente, mas, na minha opinião, esse raramente é o caso. Existem muitos produtos criados com base em temas (pense em blockchain, chatbots, VR …) e não têm mérito algum. A abordagem correta (e, eu presumo, a que o Google acredita) é que você deve deixar o tema direcioná-lo, mas deve definir apenas metas que façam sentido para o seu produto e mercado.

Mesmo quando as pessoas criam bons OKRs, baseados em resultados, elas geralmente lutam para decidir o que fazer em seguida, em quais atividades trabalhar. E tendem a tomar decisões sem dados, com base apenas na opinião de alguém – normalmente do chefe. O que as equipes devem fazer após criar OKRs? 

Itamar: O problema principal é que, em tecnologia, como em muitas outras indústrias, a realidade está cada vez mais incerta, complexa e em rápida mudança. Os mercados estão evoluindo rapidamente, os concorrentes estão entrando e saindo, as tecnologias estão mudando. Nunca realmente sabemos se o nosso software consegue fazer o que queremos que faça, quantos bugs haverá – há muita incerteza.

Eu vejo que muitas empresas não estão lidando muito bem com essa realidade. Elas dependem de planejamento vertical, decisões de comitês, opiniões, heurísticas fracas e vieses cognitivos. É por isso que eu desenvolvi a estrutura GIST para ajudar as empresas a sistematicamente direcionar seus produtos para o impacto nos negócios e no mercado. O sistema tem quatro camadas: Metas (Goals), Ideias (Ideas), Passos (Steps) e Tarefas (Tasks). Metas incluem OKRs e métricas. Ideias se referem a reunir e avaliar muitas ideias rapidamente usando evidências. Passos são miniprojetos desenvolvendo a ideia e a testando ao mesmo tempo (implementando os princípios de Lean Startup e Design Thinking), e Tarefas são as atividades do dia a dia que implementam os passos. Você pode ler mais sobre GIST aqui (em Inglês). Meu livro sobre esse assunto será lançado na primavera. 

O Confidence Meter (medidor de confiança) é uma ferramenta que eu desenvolvi para permitir que as pessoas avaliem a força da evidência para suporte de suas ideias. Por exemplo, opiniões e apoio temático (a área azul do lado direito superior) nos dá uma evidência fraca e portanto pouquíssima confiança. Testes e experimentos (vermelho no lado esquerdo superior) nos dá evidência forte e muito mais confiança. A estrutura GIST guia você a testar ideias iterativamente em loops de criar-medir-aprender e, em seguida, reavaliá-las usando essa ferramenta.

Você pode baixar a ferramenta grátis (com instruções) aqui (em Inglês): confidence calculator.

Para saber mais sobre Itamar Gilad, visite seu site (em inglês): itamargilad.com e se inscreva para receber sua newsletter onde ele compartilha artigos e ferramentas.

O objetivo de adotar OKR é nos ajudar a focar em outcomes. Primeiro definimos o que queremos alcançar e por que isso é importante. Depois, permitimos que os times testem rapidamente ideias diferentes, para que descubram quais vão "mover o ponteiro".

Se você estiver usando OKR corretamente, os times não terão uma lista de projetos ou features para entregar. Para terem sucesso, eles vão precisar executar diferentes experimentos para testar ideias. Caso contrário, eles perderão tempo e dinheiro indo na direção errada.

Quando um time diz que não consegue atingir outcomes em um único trimestre, geralmente é porque não sabe como realizar experimentos. Não se trata de um problema com OKR, mas com experimentos.

Felizmente, David J. Bland se juntou a Alex Osterwalder, criador do Business Model Canvas, para abordar esse tópico em seu livro Testing Business Ideas, disponível em Português. A editora do meu blog, Melissa Suzuno, conversou com David para aprender mais sobre o livro e seus conselhos sobre experimentos em um ambiente de negócios.

Conte-nos um pouco sobre você e como começou sua jornada com experimentos.

David: Assim que me formei em design, eu acabei entrando em uma startup, onde fiz um pouco de tudo - de design, desenvolvimento front-end, desenvolvimento web, liderança de times, até fechar negócios. Essa experiência foi muito influente na minha carreira. Quando você está em uma startup, está tentando buscar um modelo de negócios, os clientes certos. Agora, como consultor, tento usar tudo o que aprendi nas startups para lidar com a incerteza e como testar ideias. 

Independentemente do tipo de empresa que estou trabalhando, foco em identificar o que eles têm de mais arriscado e em como testar, para que não descubram muito mais tarde que estão errados e falhem lentamente.

Você pode nos contar um pouco sobre o seu livro e nos dar uma rápida visão geral do que ele trata?

David: Fui procurado por Alex Osterwalder, que criou o Business Model Canvas e o Value Proposition Canvas. Ele disse: “Existe uma necessidade no mercado, pois as pessoas não sabem quais experimentos realizar e quando devem realizá-los”. Nossa meta não era construir uma enciclopédia gigante de experimentos, mas ajudar as pessoas a entender como escolher um experimento e como executá-lo. Começamos com isso e terminamos com essa lista de 44 experimentos com uma taxonomia que ajuda as pessoas a entender se um experimento as ajudará a determinar o tipo de risco - se algo é desejável, viável ou factível.

A ideia é que alguém diga: “Eu corro esse tipo de risco. Que tipo de experimentos estão disponíveis para mim?” E o livro o ajudará a ver quais experimentos pode usar e como executá-los.

O núcleo do livro é a lista de experimentos, mas a embalagem em torno desse conteúdo aborda questões como: De que tipo de time eu preciso? Como faço para começar? Que tipo de cerimônias isso envolve? Como posso fazer disso um processo reproduzível?

Por que os experimentos são tão cruciais para obter alta performance?

David:  Normalmente, quando você está começando algo novo - se você pensar nisso como exploração versus validação - você provavelmente está fazendo muito trabalho de exploração com o intuito de entender se há um problema ali. E então, à medida que aprende mais, você quer poder mostrar um protótipo para os clientes, obter feedback e coletar evidências cada vez mais fortes de que você está indo na direção certa. 

Não queremos apenas descobrir se as pessoas querem o produto, mas também se vão pagar por ele e se conseguimos realmente entregar o que os clientes querem.  

Na verdade, esse processo nunca para. Mesmo quando a empresa não é mais uma startup, ela não está apenas no piloto automático. Sempre vão existir perguntas como “e se quiséssemos adicionar uma feature, como ficaria?” e “como testaríamos antes de apenas adicionar mais features?”.

Nunca pare de experimentar. Não é uma fase. É algo que você precisa continuar a fazer. É importante que você entenda quais são as coisas em seu roadmap ou estratégia que o deixam realmente nervoso e que você pode fazer para aprender mais rápido sobre elas.

Em uma visão moderna de OKR, os gestores não devem dizer aos times quais features devem ser desenvolvidas ou projetos nos quais trabalhar, mas, em vez disso, devem concordar sobre os outcomes que desejam alcançar. Em sua opinião, qual o papel dos experimentos nesse tipo de cenário?

David: Quando você foca em outcomes, é essencial saber onde você está direcionando  seu modelo de negócios. Por exemplo, você está focando no "encaixe" entre sua proposta de valor e o segmento de clientes? Você está focando nos canais e em como pode desenvolvê-los? Você está focando em construir relacionamentos? Você está focando em testar o pricing e entender como é sua receita? Você está focando nos bastidores, onde precisa de recursos e atividades e em entender quanto isso vai custar? 

Todos esses elementos do modelo de negócios são baseados em outcomes. Por exemplo, se estamos tentando atingir determinado nível de preço, em uma estratégia de baixo custo, qual é o menor teste que podemos executar para verificar se isso é verdade?

Se é isso que prevemos que vai acontecer, podemos fazer alguns experimentos e ver o quão longe estamos. Estamos perto de atingir esse número ou de atingir o resultado? Quando você vai modelar o negócio, você deve sempre tentar focar nos outcomes e em entender quais são as evidências que podem ser usadas para informar sua estratégia. Você não quer apenas dar a um time uma lista de experimentos para executar. Em vez disso, você quer explicar que está tentando testar esse outcome e perguntar quais seriam algumas maneiras de fazermos isso.

Isso é válido porque coloca algumas restrições, mas não necessariamente diz a eles quais experimentos devem executar. É mais útil usar sua criatividade, sua habilidade e a de seu time para descobrir quais experimentos diferentes poderiam ser feitos se vocês estivessem tentando alcançar esse outcome, como acompanhariam o progresso. Em seguida, você volta aos stakeholders com suas hipóteses. Você pode explicar os experimentos que realizou, os resultados que observou e o que você recomendou a seguir. Torna-se mais uma conversa em que você explica como fez seu progresso e não necessariamente apenas sendo responsabilizado pela execução de um monte de experimentos.

Felipe Castro: Um comentário rápido. O Business Model Canvas é opcional e nem todos os times o utilizam. É uma ferramenta muito poderosa e amplamente adotada, mas você pode utilizar OKR e experimentos sem ela.

Quais são alguns dos erros mais comuns que as pessoas cometem ao testar ideias de negócios?

David: Existem três grandes padrões que surgem repetidamente. Um é o viés de confirmação, quando você está apenas confirmando o que você já acreditava. E, então, o risco que existe é validar prematuramente sua hipótese, definindo um nível de exigência muito baixo.

O viés de excesso de confiança aparece frequentemente. A percepção de sua capacidade de avaliação é muito maior do que realmente é, então você tem confiança excessiva em suas próprias decisões e pode questionar se precisa mesmo rodar experimentos. 

Finalmente, há o viés do experimentador. Ao realizar a pesquisa, você pode ter influenciado inconscientemente os resultados. Neste caso, você descarta qualquer coisa que não esteja de acordo com sua hipótese. Uma das maneiras de lidar com isso é convidar diferentes perspectivas para o processo quando você for avaliar os dados. Não faça isso sozinho. Executar vários experimentos também ajuda nisso.

Como as empresas podem melhorar a adoção de uma cultura de experimentação?

David: Eu sinto que há uma lacuna: as empresas que estão adotando a experimentação estão ficando cada vez mais à frente das que não estão dispostas a fazê-lo. A lacuna está ficando cada vez maior e isso será um problema, porque as empresas que não adotarem a experimentação ou o fizerem tarde demais, tendem a ficar para trás e a passar por um período muito difícil. 

Para mudar isso, é preciso rever a cultura e a mentalidade da sua empresa. Se você tiver algo que acha que tentou resolver de algumas maneiras diferentes e simplesmente não funcionou, geralmente é porque você não entende o problema muito bem. Portanto, recomendo pensar profundamente sobre ele, tentar realizar experimentos e gerar mais algumas evidências sobre qual poderia ser a solução. Muitas vezes, não entendemos o problema o suficiente e chegamos à solução muito cedo.

Para os líderes, a melhor coisa que pode ser feita é tentar criar um ambiente em sua organização onde a experimentação possa ocorrer. Dar às pessoas tempo para trabalhar nisso, não microgerenciar e liderar com perguntas em vez de respostas são bons exemplos. E isso realmente desafia a liderança sênior, porque se você sentir que sempre tem que saber a resposta, provavelmente terá dificuldade em dizer “vamos apenas experimentar e aprender”, porque você sempre terá um desejo inerente de dizer qual poderia ser a resposta. 

Se há algo que você gostaria que as pessoas absorvessem de seu livro, o que é?

David: Estar aberto à ideia de estar errado. Acho que a maneira como fomos ensinados nas escolas sempre recompensava quem tinha a resposta certa. E geralmente havia uma única resposta certa. Mas, em sua organização e em seu negócio - e também em sua vida -, raramente há uma resposta certa. Elas são apenas escolhas. 

Eu adoraria que as pessoas percebessem que podem realmente aplicar sua criatividade e que tudo bem se elas estiverem erradas. Não é o fim do mundo. É realmente um pequeno teste que você está executando. Como aprender com isso e tentar novamente?

Nós usamos a estrutura Jobs to Be Done e definimos que para o leitor, o trabalho a ser feito pelo livro era: “Quando tenho uma ideia de negócio, quero poder testá-la rapidamente para que não construa algo que ninguém queira”.

Você pode encontrar a edição Português de Testing Business Ideas aqui.

Foto de Adi Goldstein via Unsplash

Um conselho comum sobre OKRs – e metas em geral – é que você deve “focar em metas que você pode controlar sozinho”. As empresas não querem, por exemplo, que o time de marketing diga que não alcançou seus OKRs porque a engenharia não fez sua parte, então eles pedem a cada time que foque no que pode controlar. O problema é que, por definição, essa abordagem cria silos. Se cada time – ou indivíduo – se concentra apenas no que pode controlar, todos os problemas que exigem coordenação entre times ficam abandonados.

Qualquer que seja a estrutura organizacional, há sempre “espaço em branco” entre diferentes times e departamentos. As empresas precisam aprender a gerenciar esse espaço em branco, pois todos dependemos um do outro de alguma forma, especialmente à medida que as empresas escalam. Precisamos permitir que os times resolvam dependências e trabalhem juntas em prioridades comuns.

OKRs compartilhados nos alinham em torno dos resultados 

É por isso que um dos princípios fundamentais de OKR é que alinhamos em torno dos resultados, não dos silos. Começamos pensando no que queremos alcançar e, em seguida, alinhamos nossos OKRs com outros indivíduos ou equipes – mesmo que eles trabalhem em outras funções, departamentos ou unidades de negócios.

Um dos princípios fundamentais de OKR é que alinhamos  em torno dos resultados, não dos silos. 

As abordagens tradicionais geralmente se concentram no alinhamento vertical: garantir que suas metas se alinhem com as metas da sua chefe e com as metas da chefe dela, o que pode criar silos. OKR foca no alinhamento 360º – para cima, para baixo e para os lados – eliminando silos e resolvendo interdependências.

Os OKRs compartilhados são a ferramenta mais eficaz para criar alinhamento entre diferentes times ou funções. Em um OKR compartilhado, dois ou mais times compartilham o mesmo OKR, mas cada um possui atividades diferentes. Você pode compartilhar todo o OKR (ou seja, o Objetivo e um conjunto de Key Results) ou pode compartilhar apenas um único KR.

Quando você decide um OKR compartilhado, está criando uma equipe ad hoc que durará enquanto você tiver esse OKR compartilhado. Pense nisso como ativar um “squad virtual” com todas os times / indivíduos necessários para atingir o OKR compartilhado.

Definindo OKRs compartilhados

Lembre-se de que OKR não é tudo o que você faz, portanto, as pequenas coisas não precisam ser incluídas nos seus OKRs compartilhados. Por exemplo, se o time de marketing deseja melhorar as taxas de conversão em seu site e precisa de engenheiros para concluir determinadas atividades, isso significa que eles identificaram uma dependência e precisam resolvê-la. Se estamos lidando com algo pequeno, como alterar um formulário, geralmente significa que a equipe de engenharia pode acompanhar essa atividade como parte de seu trabalho diário e não precisamos de um OKR compartilhado para isso.

O que constituiria uma dependência grande o suficiente para ser considerada uma OKR compartilhada entre esses dois times? Imagine se o time de marketing estivesse tentando aumentar o uso de uma funcionalidade, o que provavelmente exigiria não apenas promover essa feature, mas também melhorá-la. Expandir o uso dessa funcionalidade seria um excelente exemplo de um OKR compartilhado entre marketing e um time multifuncional de produtos (que geralmente também inclui engenharia e UX).

Como outro exemplo, imagine que você trabalha como gerente de recrutamento de uma grande empresa. Se todos que tivessem uma posição aberta decidissem compartilhar esse OKR com você, você poderia acabar com dezenas de Key Results, o que iria contra nosso desejo de definir prioridades claras. Portanto, contratar uma única pessoa geralmente não seria um OKR compartilhado, enquanto contratar 100 provavelmente precisa fazer parte de um OKR.

Enquanto falamos de terminologia, gostaria de mencionar que os termos OKRs “multifuncionais” ou “multidisciplinares” podem ser enganosos. Existem muitas dependências dentro da mesma função ou departamento, o que significa que geralmente precisamos de OKR compartilhado dentro da mesma função ou disciplina. O exemplo mais comum são as grandes organizações de produtos em que um time de produtos depende de outro, mas isso também ocorre em outras funções, como marketing, finanças ou jurídico.

Sua empresa deve usar OKRs compartilhados?

Criar alinhamento é uma das principais razões pelas quais as empresas adotam o OKR em primeiro lugar, mas sem os OKRs compartilhados, eles estão apenas brincando de teatro de alinhamento – dando a ilusão de buscar alinhamento – enquanto continuam trabalhando em silos como sempre.

OKRs compartilhados existem para resolver dependências. Quanto mais dependências você tiver, mais precisará de OKRs compartilhados. Por exemplo, empresas organizadas em torno de estruturas funcionais geralmente precisam de muitos OKRs compartilhados, enquanto empresas que usam times multifuncionais ou “squads” tendem a ter menos dependências e, portanto, menos OKRs compartilhados. Dependências sempre existem, portanto, você sempre precisa compartilhar OKRs.

Compartilharmento é um dos segredos do mundo OKR. É um conceito crucial, mas poucas organizações o utilizam bem. As pessoas estão tão presas na mentalidade do silo que uma vez que alguém discutiu comigo no Twitter que OKRs compartilhados não existiam e só desistiu quando eu o apontei para os artigos no meu blog (confira o post Dicas de um ex-Googler: Alinhando Times com OKRs Compartilhados para ler mais sobre este tópico).

Fazendo OKRs compartilhados funcionarem

Lembre-se de que um OKR compartilhado cria um time ad hoc. Assim como qualquer outro time, as pessoas que compartilham um OKR devem fazer check-ins regulares para acompanhar resultados e ajustar as atividades correspondentes “pela duração do OKR compartilhado”, que geralmente é de um trimestre, mas pode variar dependendo da complexidade do OKR.

Um OKR compartilhado significa que um grupo de pessoas compartilha a propriedade e responsabilidade por ele. As pessoas estão obcecadas com a responsabilidade individual em relação aos OKRs, mas você não pode usar uma abordagem de tamanho único. Algumas pessoas praticam esportes individuais e outras praticam esportes de equipe. Se você joga tênis, tem um placar individual, mas se joga basquete, tem um placar do time. O que importa é ajudar o time a vencer. As pessoas que argumentam que você sempre precisa ter um único indivíduo responsável parecem esquecer que as pessoas jogam em equipes desde a infância e entendem muito bem a dinâmica da responsabilidade dentro de um time.

Se você joga tênis, tem um placar individual, mas se joga basquete, tem um placar do time. O que importa é ajudar o time a vencer

Algumas armadilhas a evitar

O erro mais comum é não usar OKRs compartilhados e não ensinar os funcionários a usá-los. Para as empresas que já estão usando OKRs compartilhados, vejo algumas armadilhas comuns.

O primeiro está em não mapear de todas as dependências. Às vezes, as pessoas assumem que outro time poderá ajudar sem falar com eles primeiro. Isso geralmente não termina bem. Tenho uma ótima história sobre uma equipe do Google Maps que não conseguiu atingir seus OKRs porque eles não mapearam todas as dependências.

O erro oposto também é comum: as pessoas querem compartilhar sua OKR com todos times da empresa, o que também não faz sentido.

Finalmente, às vezes as empresas criam OKRs compartilhados que são tão grandes que a difusão de responsabilidade entra em ação e os indivíduos assumem que outros são responsáveis por agir. É por isso que sempre tentamos dividir os OKRs compartilhados em pedaços menores. Se isso não for possível, podemos precisar de um gerente de programa forte para liderar o OKR compartilhado.

As pessoas estão sempre pedindo exemplos OKRs de vendas, então quando ouvi que o Googler Sameer Rane fez uma apresentação sobre como sua equipe usa OKR em vendas, decidi entrar em contato com ele.

Estou muito feliz em anunciar que Sameer, Gerente de Estratégia e Operações de Vendas Para os mercados nórdicos e Benelux no Google, concordou em escrever um guest post em conjunto com sua colega Noelia Fernandez Arroyo, diretora de Vendas para Grandes Clientes do Norte da Europa. A maneira correta de usar OKR em vendas é pensar além das cotas de vendas – que normalmente são mantidos à parte dos OKRs – e concentrar-se nas mudanças de comportamento e processos que irão gerar receitas. Neste post, Sameer e Noelia compartilham histórias reais de como OKRs tiveram sucesso – e falharam – em fazer isso.

Por favor, note que times diferentes usam OKR de maneiras diferentes dentro do Google e de muitas outras empresas líderes. O post representa a opinião e as experiências dos autores com OKR.

Com vocês, Sameer e Noelia.

Este post tem como objetivo fornecer alguns exemplos práticos de como as organizações de vendas podem usar OKRs para gerar impacto sustentável de negócios com base em nossa experiência de trabalho no Google no norte da Europa.

Neste post, cobrimos dois exemplos que funcionaram bem e um que não funcionou para nós. Para cada caso, descrevemos o contexto de negócios que levou a equipe a selecionar esse OKR e os resultados que foram conduzidos por ele.

Exemplo de OKRs de Vendas #1

Contexto de Negócios: o Google tem utilizando machine learning para gerar oportunidades automatizadas para as equipes de vendas. No entanto, um alto grau de mudança de comportamento foi necessário para gerar confiança nas equipes de vendas que estas passaem a acreditar nas oportunidades geradas por máquinas.

Meta final: Tornar as oportunidades recomendadas por machine learning em um componente essencial do pipeline de vendas para o negócio.

OKR Utilizado e Como Ele Evoluiu:

Objetivo: Fazer com que as equipes de vendas adotem oportunidades recomendadas por machine learning como parte de seu modelo operacional principal.

Key Result:

Aumentar a taxa de revisão das oportunidades recomendadas pela máquina de X para Y.

Queríamos rastrear a adoção das oportunidades recomendadas por machine learning pelos vendedores. Este OKR foi monitorado em etapas inicialmente medindo a taxa de revisão dessas oportunidades, onde os times marcaram como “Aceito” ou “Não Aceito”. Eventualmente, à medida que os times ficaram mais confortáveis em utiliza a “taxa de revisão” como Key Result, mudamos para “taxa de apresentação”, em que começamos a rastrear o número e o valor em dólar das oportunidades nas quais fizemos uma apresentação de vendas. Posteriormente, isso foi atualizado para “Taxa implementada” como o Key Result, onde rastreamos a implementação final ou o fechamento dessas oportunidades.

Resultados: Ao definir e acompanhar esse OKR em um período de mais de 24 meses, a liderança de vendas conseguiu promover uma mudança de comportamento sustentável entre os times de vendas, na medida em que as oportunidades geradas por machine learning agora formam um componente integral do pipeline de vendas. A  prova mais forte para essa mudança é o fato de que esse modelo operacional se tornou um componente integral do comportamento dos times de vendas e não precisamos mais utilizar um OKR específico para ele.

O maior benefício de negócios dessa mudança foi que as equipes de vendas podem se concentrar agora em impulsionar negócios de valor mais alto confiando no machine learninga para identificar oportunidades escaláveis.

Exemplo de OKRs de Vendas #2

Contexto de Negócios: Como parte da criação de uma equipe de especialistas em vendas de produtos na região, nossa ambição era impulsionar a adoção mais alta de produtos em um nível geral de mercado que abrange vários canais, ou seja, um portfolio de clientes grandes, médios e pequenos. No entanto, o escopo de remuneração para as equipes de vendas estava vinculado a um único canal e, portanto, precisávamos de um mecanismo alternativo para atingir a meta.

Meta Final: Fazer com que a equipe de Especialistas operasse em múltiplos canais para conduzir a adoção do produto, mantendo o modelo de remuneração original.

Key Result utilizado: Aumentar a adoção de produtos “cross-channel” para métricas de produtos prioritárias de X a Y

Resultados: Ao definir OKRs que envolviam múltiplos canais enquanto mantinhamos a remuneração atrelada ao canal principal, a equipe foi incentivada a identificar formas escaláveis e inovadoras de impulsionar a adoção de produtos em todos os canais. Isso levou a um maior grau de colaboração com agências de publicidade que operam independentemente dos canais. As equipes incluíram clientes de outro canal para sessões de treinamento de produtos. Isso resultou em liderança global para nossa região em algumas das métricas de produtos de alta prioridade.

Exemplo de OKRs de Vendas #3

Infelizmente, nem todos os OKRs funcionam como esperado. Este último exemplo é sobre um OKR que não produziu o impacto nos negócios como previsto inicialmente. E conhecer o “porquê do fracasso” é fundamental quando visamos o nosso objetivo de conseguir mudar comportamentos.

Contexto de Negócios: Para criar uma mentalidade de vendas mais forte, as equipes de vendas foram incentivadas a fazer o upselling em cima dos orçamentos já acordados com os clientes.

Meta Final: Tornar o upselling um componente essencial do modelo operacional da equipe de vendas.

Key Result utilizado: Gerar um incremento de dólares de upselling de X.

Resultados: Depois de acompanhar esse Key Result  por alguns trimestres, não conseguimos estabelecer um impacto comercial claro sobre a receita de upsell sendo contabilizada pelas equipes de vendas. Em retrospectiva, houve dois desafios principais que influenciaram a execução deste OKR. O primeiro desafio foi em torno de relatórios confiáveis de oportunidades de upsell. A medição dependia de as equipes de vendas marcarem uma oportunidade de upsell, por exemplo, [Qx UPSELL]. No entanto, as equipes de vendas nem sempre colocaram as tags ou digitaram incorretamente, levando à representação incorreta da atividade upsell real. O segundo e maior desafio, no entanto, foi o de risco moral, em que os times podiam reportar um valor menor em um contrato de vendas e adicionar o componente restante como um upsell para “mostrar” sucesso com o OKR.

Lições Aprendidas

Em resumo, um OKR deve ser um mecanismo para criar um impacto  sustentável de negócios que gera valor para a organização e fornece uma linha de visão clara para as equipes priorizarem seu trabalho. E mais importante, que todos na organização entendam o porquê dos OKRs.

Em última análise, o sucesso é comprovado quando os comportamentos mudaram e você não precisa mais incluir esse tópico em seus OKRs. Você definitivamente precisará acompanhar esse comportamento como parte da gestão de rotina (reuniões de revisão de negócios, revisões trimestrais, etc.)  para garantir que nada esteja caindo no desempenho do negócio. Mas definitivamente, nós adotamos OKR como uma forma muito inteligente de motivar e orientar nossos negócios e equipes.

[Comentário do Felipe: O que Sameer e Noelia estão dizendo é que se você tiver sucesso, você terá criado mudanças sustentáveis e poderá converter seu Key Result em um KPI de monitoramento/health metric.]

Sameer pode ser encontrado no LinkedIn aqui; Noelia pode ser encontrada aqui.

O KPI, ou Key Performance Indicator, é um desses acrônimos de três letras que parecem ser usados por todas as organizações do planeta. É natural que as pessoas questionem a diferença entre OKR e KPIs. O desafio é que “KPI” pode significar coisas diferentes para pessoas diferentes, o que é confuso.

Ao longo dos anos, testei diferentes maneiras de responder a essa pergunta e finalmente encontrei uma que parece funcionar com as pessoas, então decidi escrever sobre ela.

Não esqueça o K

A primeira coisa que você precisa entender é que OKR é um sistema que o força a separar o que realmente importa do resto e a definir prioridades claras. Para fazer isso, você tem que aprender a dizer não – muitas vezes.

Se tudo é uma prioridade, nada é.

Essa abordagem é uma mudança significativa do modo como muitas organizações acompanham resultados. As empresas costumam ter uma reunião mensal em que os funcionários repassam página após página de KPIs, em um exercício chatíssimo  que pode durar horas. Há tanta coisa acontecendo que os funcionários perdem de vista o que é importante. Eles estão se afogando em um mar de métricas e prioridades conflitantes.

Meu conselho claro: Não Esqueça o K.

A letra k em KPI – e OKR – significa chave: poucos, alguns, os mais importantes. O uso de KPIs deveria forçá-lo a separar o que realmente importa (os indicadores-chave) dos demais, mas muitas pessoas esquecem disso. Se você tem 30 “KPIs”, você não tem nenhum – você só tem indicadores.

É por isso que no OKR nós limitamos o número de Key Results. Concordo com minha amiga Christina Wokdte: um time individual ou “squad” deve ter apenas um Objetivo em um determinado trimestre, com até cinco Key Results.

O trabalho do dia-a-dia é como ir ao supermercado

OKR não é sobre acompanhar tudo o que você faz. Caso contrário, os OKRs da empresa teriam que incluir os Key Results para manter as luzes acesas, limpar o escritório, etc.

Uma excelente maneira de entender a diferença entre seus OKRs e o trabalho do dia-a-dia é pensar nas metas que você tem em sua vida pessoal: você pode economizar dinheiro para uma viagem, passar mais tempo com sua família ou perder peso. Aposto que ir ao supermercado não é uma das suas metas, mas você ainda tem que fazê-lo. E se as suas idas ao supermercado começarem a ocupar muito do seu tempo e começar a prejudicar seus objetivos pessoais, você terá que mudar a forma como compra mantimentos.

Quando as pessoas dizem que não podem alcançar seus OKRs porque o trabalho do dia-a-dia fica no caminho, é porque eles não entenderam OKR. Bons OKRs forçam você a reavaliar atividades de baixa prioridade ou sem valor agregado e reduzir, automatizar ou terceirizar essas atividades para que você possa se concentrar no que realmente importa.

 Não deixe o trabalho do dia-a-dia atrapalhar o que é mais importante.

Diferentes funções poderão dedicar mais tempo à OKR do que outras. Por exemplo, um time multifuncional de produtos pode dedicar 80% do seu tempo à OKR e 20% ao trabalho do dia-a-dia, enquanto alguém em contas a pagar pode estar na situação oposta: 20% do seu tempo é dedicado à OKR e 80% ao trabalho do dia-a-dia.

Este é apenas um exemplo hipotético e não um guideline. Esses números podem variar muito dependendo do contexto.

OKR foca em criar mudanças sustentáveis no desempenho

OKR não é sobre o acompanhar tudo o que você faz, mas também não é focar em somente uma coisa e deixar todo o resto cair.

Digamos que você tenha uma métrica crítica que está flutuando um pouco, mas há uma tendência clara:

Um OKR deve melhorar o desempenho em relação à tendência atual:

OKR é sobre criar mudanças sustentáveis no desempenho. Isso significa que usar truques ara produzir uma melhora temporária não é suficiente. OKR trata da mudança de comportamentos, sistemas, ferramentas ou processos para que você possa manter novos níveis de desempenho. Mas você tem que fazer isso sem atrapalhar todo o resto, então você deve atingir seus OKRs enquanto os outros aspectos do seu negócio mantêm seus níveis anteriores de desempenho.

O livro As 4 Disciplinas da Execução tem uma ótima pergunta para ajudar a estruturar este problema (tradução minha):

“Se todas as outras áreas da nossa operação permanecessem no nível atual de desempenho, qual é a única área em que a mudança teria o maior impacto?”

Para definir bons OKRs, você deve avaliar os diferentes aspectos do seu negócio e identificar aqueles onde uma mudança no desempenho teria o maior impacto, mantendo os outros elementos em um estado estável:

O que acontece quando uma métrica / KPI que não está em seus OKRs começa a se afastar da tendência anterior? Então você precisa agir sobre isso, e você pode até ter que incluí-lo em seus OKRs para garantir que ele volte para onde deveria estar. E se uma métrica estiver instável, você pode criar um OKR para recuperá-lo para esse “estado estável”. Para entender como fazer isso na prática, vamos fazer uma viagem.

A viagem: estratégia, OKRs e KPIs de monitoramento

Imagine que você quer fazer uma viagem de carro. A primeira coisa que você precisa decidir é onde você quer ir, então use um guia de viagem e escolha viajar de São Francisco pela Costa do Pacífico.

Depois de ter decidido para onde quer ir, você entra no seu carro e insere o destino no seu GPS, o que o ajudará a rastrear se você está no caminho certo e a corrigir o curso, se necessário.

Por fim, à medida que você dirige até seu destino escolhido, seu carro também tem um painel que rastreia muitas outras métricas e informa, por exemplo, a quantidade de combustível que você tem. Desde que os mostradores do painel estejam dentro de certos limites, você não se preocupa com eles – afinal, o que importa é chegar ao seu destino. Mas se o seu painel mostra que você está ficando sem combustível, então você tem que ajustar o seu curso e encontrar um posto de gasolina.

Essa analogia é uma ótima maneira de entender a diferença entre estratégia, OKRs e KPIs de Monitoramento:

• Estratégia é o processo de decidir seu destino. Ela ajuda você a decidir onde você quer ir.

• OKR é o seu GPS, o sistema de navegação do seu carro: ele irá ajudá-lo a rastrear se você está no caminho certo e corrigir o curso, se necessário. E, assim como um GPS, o OKR não vai te ajudar a decidir o destino e não o ajudará a formular sua estratégia.

• KPIs de Monitoramento são os mostradores no painel do seu carro – eles informam se tudo está OK.

(Obrigado a meus amigos da Booking.com e da Perdoo por criarem a versão original dessa analogia.)

Health Metrics

Os KPIs de Monitoramento às vezes são chamados de health metrics , pois ajudam a acompanhar a saúde do negócio. Pense neles como um check-up médico: você os medirá regularmente e poderá incluí-los em relatórios também. Mas, enquanto eles permanecerem dentro dos limites predefinidos, você não precisará agir.

Exemplos de Key Results vs. KPIs de Monitoramento 

Exemplo 1

O tráfego no seu website está indo bem, então você decide se concentrar na conversão:

Exemplo 2

Seu produto é estável, então você decide se concentrar no aumento do engajamento do cliente:

Exemplo 3

Sua empresa vende um serviço de assinatura e, embora você possa atrair novos clientes suficientes, a taxa de cancelamento é muito alta. Você decide se concentrar em aumentar a retenção:

O que fazer com seus KPIs atuais?

Uma pequena parte de seus KPIs existentes são os que realmente importam, e eles se tornarão parte do seu OKR (seu GPS). Suas prioridades podem mudar de um trimentre para o outro, e seus OKRs representarão isso. Enquanto os KPIs tendem a ser os mesmos trimestre após trimestre, o OKR é adaptativo e pode mudar para ajudá-lo a se concentrar no que realmente importa.

A maioria dos seus KPIs existentes são apenas coisas que você precisa monitorar e eles farão parte do seu painel de monitoramento. Você os acompanhará regularmente e poderá denunciá-los também, mas, desde que permaneçam dentro de certos limites, você não se preocupará com eles.

Finalmente, alguns dos seus KPIs existentes terão que ser substituídos ou abandonados. Eles podem ser irrelevantes ou apenas métricas ruins – por exemplo, indicadores que simplesmente medem atividades em vez de resultados.

Sucesso é criar mudanças duradouras

Quero encerrar este post com algo que aprendi recentemente com Noelia Fernandez, diretora de vendas de grandes clientes do Google para o norte da Europa, que escreveu um guest post para esta publicação com seu colega Sameer Rane:

Em última análise, o sucesso é comprovado quando os comportamentos mudaram, e você não precisa mais incluir esse tópico em seus OKRs – tudo o que você precisa é de alguma disciplina básica de gestão para garantir que nada esteja saindo da rota. Mais importante, sucesso é quando todos na organização entendem o porquê dos OKRs.