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

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.

---

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.

---