Como fazer um bom processo de definição de OKRs em times de produto

Published in

Ship It!

6 min readJul 10, 2018

Esse post faz parte de uma série de artigos sobre o que nós da Resultados Digitais aprendemos com o lendário Marty Cagan, seja participando do workshop ministrado por ele em SP ou na visita que ele fez à RD em Floripa para participar de uma sessão de Ask Me Anything.

Outros posts da série:

A metodologia de OKRs é bastante difundida no Brasil (se você não conhece, recomendo o artigo OKR: o que é e como a metodologia pode ajudar sua empresa a ter mais resultados). Porém ainda que seja simples entender o que são OKRs, o processo de definição deles na empresa, principalmente no time de produto, tem algumas armadilhas que muitas empresas caem. É natural, se não fosse comum muitas empresas errarem ao usar OKRs, o Marty Cagan não teria usado parte do tempo do seu workshop para falar sobre isso.

Passo 1: OKRs da empresa

A metodologia de OKRs é ótima para alinhamento do que é importante, portanto isso deve ser feito antes. Os OKRs da empresa são definidos pelo time executivo e geralmente têm uma duração de um ano. Os outros passos geralmente acontecem a cada trimestre:

Passo 2: definir os “O”s (Objectives) de cada time de produto

Baseados nas prioridades da empresa, os líderes de produto (heads de produto, engenharia, design, QA, etc) chegam em um acordo sobre quais objetivos cada time deve ser responsável. Aqui é onde muitas empresas escorregam de duas formas diferentes:

1. Cada gestor (heads de produto, engenharia, design, QA, etc) define seus próprios OKRs e delega isso para seus liderados. Por exemplo, o chefe de engenharia decide acabar com X% dos bugs críticos e distribui essa meta entre seus tech leaders, enquanto o head de produto define que a meta é aumentar a adoção em X% nos primeiros 6 meses da conta e passa isso para os PMs que são seus liderados. O problema é que o tech leader e o PM liderados por esses heads trabalham no mesmo time, o que vai gerar conflitos sobre o que a equipe deve focar de fato. Por isso é essencial que os OKRs não sejam definidos nas diferentes organizações, mas sim que cada time tenha seus OKRs.

2. Outra forma onde muitas empresas se embananam no processo é deixando os próprios times definirem seus OKRs. Isso é super bacana em termos de autonomia, mas é um desastre em alinhamento. Por isso é necessário que os heads de produto, engenharia, design, QA, etc entrem em um acordo e definam os objetivos que cada time deve perseguir (note que são os objetivos, não os key results). Afinal, os líderes estão em uma posição privilegiada para avaliar quais recursos devem investir para gerar valor para o negócio.

Passo 3: os times definem seus KRs (key results)

Baseados nos objetivos que receberam, cada um dos times define como vai medir que chegou nesses objetivos. Aqui alguns times também cometem seus escorregões, como:

1. Definir KRs baseados em entregas, não em resultados (outcome > output). Exemplo: entregar a feature XYZ. Quando definimos objetivos e key results, é bem comum que ainda precisamos descobrir qual é a solução (ou as soluções) para atingir esses resultados — precisamos fazer discovery. Por definição, “discovery” significa que ainda não sabemos a resposta. Portanto nunca foque em o que será entregue, mas sim nos objetivos de negócio que o time deseja alcançar.

2. KRs não desafiadores. O mindset de um time que precisa entregar uma melhoria de 1% em uma métrica vai ser bem diferente de um time que precisa entregar 40% de melhora. Por isso é comum definir KRs do estilo moonshot, ou seja, uma meta inspiracional e que a empresa vai considerar como um grande sucesso se for alcançado 50–70% dela. Por isso que os OKRs não devem ser usadas como métrica de desempenho de pessoas. Se isso for feito, os times só aceitarão definir key results conservadores e que têm certeza que atingirão.

Passo 4: negociação final

Uma vez que os times definiram seus key results baseados nos objetivos que a liderança atribuiu aos times, agora é a hora de negociar: a gerência pode dizer que o KR precisa ser mais agressivo, o time pode contrabalancear pedindo então que um dos KRs seja removido, etc. É uma negociação, cujo objetivo final é garantir que cada time tem o objetivo e metas mais importantes para caminhar em direção ao atingimento das metas da empresa e ao mesmo tempo manter os times empolgados e acreditando que, apesar de desafiador, conseguem trabalhar para atingir seus OKRs.

Exemplos de OKRs de time (Uber)

Driver Team:

O: Aumentar o número total de motoristas

KR: +20% de motoristas de regiões ativas
KR: Média de >26 horas/semana dirigidas

O: Aumentar a felicidade dos motoristas

KR: Média de satisfação no percentil 75

Rider Team:

O: Aumentar número de passageiros nas novas regiões

KR: Aumentar em 30% o número de primeiras-viagens

O: Aumentar engajamento do passageiro

KR: Média de viagens/semana +15%
KR: falhas em pedidos de viagem <5%
KR: Espera em horário de pico <10 min

O: Aumentar felicidade dos passageiros

KR: média de satisfação no percentil 90

Fechamento

Não se preocupe se o seu processo não parece nada com isso hoje. Apesar de OKRs ser uma metodologia antiga, faz bem pouco tempo que muitas empresas começaram a utilizá-lo. É comum que nem tudo saia perfeito das primeiras vezes. Espero que esse post ajude a sua empresa a definir OKRs de uma forma mais fácil e que possibilite uma alta autonomia aos times de produto, ao mesmo tempo em que proporciona um alto alinhamento com os objetivos da empresa.

Curtiu? Clica no coraçãozinho ali embaixo e acompanhe o que eu escrevo aqui.