Como OKR ajudou o Gmail a alcançar 1 bilhão de usuários: uma entrevista com Itamar Gilad

Itamar Gilad

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 entrei no Gmail, estávamos conversando sobre como aumentar o engajamento de usuários casuais, pessoas que usam email para fins pessoais, com o produto. Na época, o Facebook estava obtendo muito engajamento e acho que isso focou nossa atenção nessa métrica. Olhando com a visão de hoje, provavelmente não é uma boa base de comparação, já que o email e o Facebook são produtos muito diferentes.

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 consideramos foi o envio de mensagens. No entanto, as pessoas não precisam necessariamente enviar tantos emails pessoais hoje em dia. Elas têm chat e mídia social, então o número de emails enviados não significa necessariamente que o email não gere engajamento. 

Então, percebemos que talvez estivéssemos fazendo a pergunta errada. Fizemos pesquisas – entrevistamos pessoas e fizemos análises quantitativas – e percebemos que as pessoas tinham muitos emails promocionais e de notificação que lotavam suas caixas de entrada e dificultavam a localização das mensagens que realmente queriam ler. 

Percebemos que a meta principal que deveríamos definir não era aumentar engajamento, mas aumentar o engajamento com o tipo certo de email – permitindo que as pessoas lessem apenas os emails com os quais realmente se importavam e interagissem com os outros 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 pensávamos ser importantes, mas que acabavam não sendo. Falsos negativos são mensagens que pensávamos não ser importantes, mas que descobríamos que eram. 

Isso levou a um grande projeto, que acabou lançando a Caixa de Entrada com guias, que organiza seu email em Principal, Social, Promoções e outras guias. Inicialmente, era uma feature que planejávamos lançar apenas no desktop. Quando começamos os testes, percebemos que o problema era ainda maior no celular. Concluímos que isso precisava ser um OKR compartilhado com os times do Gmail do Android e iOS. 

Na época, o Gmail Android fazia parte da área de produtos Android, uma divisão completamente diferente do Google, que tinha seus próprios OKRs, então fui falar com eles. Apresentei o problema e perguntei se poderíamos compartilhar o OKR de aliviar a dor daqueles usuários casuais de email e, felizmente, eles concordaram. 

Quando ensino OKRs, digo que a coisa boa sobre OKRs compartilhados é que às vezes você recebe um “não” e então sabe que é algo em que não deveria se concentrar, pelo menos neste trimestre. Mas, neste caso específico, eles disseram que sim, e pudemos trabalhar juntos para lançar a nova Caixa de Entrada nos clientes do Gmail. Impactamos centenas de milhões de pessoas com essa grande mudança visual que 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 com as quais já trabalhei, o Google é aquela em que as pessoas estão mais “informadas”. Elas entendem o que a empresa está tentando alcançar e isso ajuda na comunicação entre os times e comunicação top-down. Uma das causas disso é que os gestores do Google gastam muito esforço comunicando tanto os OKRs, quanto por que eles são importantes. Isso não significa que sempre concordamos – muitas vezes há discussões, o que também é muito importante – mas você pode conversar com qualquer pessoa e ela provavelmente saberá por que seu produto tem determinados OKRs. 

Eu também diria que o processo cria muito alinhamento entre times diferentes. Por exemplo, se seu produto está ocupado com a melhoria do desempenho em mercados emergentes, há uma boa chance de que produtos semelhantes tenham herdado o mesmo objetivo, e isso torna mais fácil a colaboração (o que é importante, porque há muitas integrações entre produtos e sistemas do Google). Se todos estiverem puxando em direções completamente diferentes, a discussão seria mais difícil.

Como todas essas informações sobre OKRs são comunicadas?

Itamar: Existiam reuniões trimestrais, em que todos participavam. As análises dos OKRs da empresa eram transmitidas ao vivo e gravadas. O CEO e os vice-presidentes analisavam o desempenho dos OKRs do trimestre anterior e, em seguida, apresentavam os OKRs para o próximo trimestre. Havia extrema transparência.

No nível do produto, como o Gmail, tínhamos uma reunião geral específica para discutir nossos OKRs. No nível do time, também tínhamos reuniões para revisar os OKRs, portanto, havia muita comunicação. Depois de criados, os OKRs eram todos transparentes, para que qualquer pessoa pudesse abrir os OKRs de outra, sem haver segredos sobre eles. Era muito fácil entender no que as pessoas estavam 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 misturar atividades com Key Results ainda era a regra. Por essa razão, você podia encontrar esse tipo de problema no Google durante o tempo em que estive lá, embora eu acredite que as coisas tenham melhorado desde então. 

Costumo encontrar atividades listadas como Key Results em quase todas as empresas. A maioria das pessoas tem consciência de que “Lançar X” não é um bom Key Result e tentam evitá-lo, mas há muitas maneiras de disfarçar atividades como resultados – eu sei, porque eu também já fiz isso.

O cenário clássico é aquele em que você se apaixona por uma ideia, constrói um projeto em torno dela e só pensa no OKR depois. Já nos convencemos de que essa é a ideia certa, mas agora precisamos de um OKR. Se for muito difícil para você escrever OKRs, pode ser que você tenha ido longe demais 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 as pessoas contornarem esse problema. Por exemplo, um Key Result como “No próximo trimestre, esperamos que 45% de nossos usuários usem o novo fluxo de onboarding” parece ótimo. Ele é um resultado e é mensurável, mas quem realmente disse que esse novo fluxo de onboarding é uma coisa boa? 

Este OKR está, na verdade, disfarçando o fato de que nossa missão é lançar o novo fluxo de onboarding. Portanto, esse não é um bom resultado. Um bom resultado seria baseado no que o novo fluxo de onboarding forneceria aos usuários – reduziria o tempo de onboarding? Aumentaria a taxa de sucesso da onboarding? Qualquer outro benefício? Esse tipo de OKR é adequado apenas se você já o testou exaustivamente e tem evidências muito fortes de que o novo fluxo de onboarding está realmente ajudando essas outras métricas importantes.

O Google também utiliza temas para conduzir a estratégia da empresa. Por exemplo, no passado, o tema Mobile-first / Mobile-only focava em features e capabilities 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 focar. 

Os temas são frequentemente refletidos nos OKRs. O risco é que às vezes as pessoas constroem coisas apenas porque estão alinhadas com o tema, mesmo que não ajudem realmente os usuários ou a empresa. 

Um exemplo seria um produto pensado predominantemente para desktop que pare o desenvolvimento de produtos para desktop a fim de focar em usuários mobile-first / mobile-only, embora não haja nenhuma evidência de que este segmento de mercado esteja prestes a se tornar importante o suficiente para justificar um investimento tão grande. 

Existe uma suposição de que o alinhamento com o tema é evidência suficiente, mas, em minha opinião, raramente é o caso. Existem muitos produtos que são construídos com base em temas (pense em blockchain, chatbots, VR…) e não têm mérito. A abordagem certa (e suponho que a que o Google acredita) é que você deve deixar o tema direcioná-lo, mas só deve definir OKRs que façam sentido para o seu produto e mercado.

Mesmo quando as pessoas criam bons OKRs baseados em resultados, muitas vezes têm dificuldade para decidir o que fazer a seguir, em quais atividades trabalhar. E tendem a tomar decisões sem dados, com base apenas na opinião de alguém – geralmente do chefe. O que os times devem fazer após criar OKRs? 

Itamar:

O problema principal é que, em tecnologia, assim como em muitos outros setores, a realidade é cada vez mais incerta, complexa e muda rapidamente. Os mercados estão evoluindo rapidamente, os concorrentes estão entrando e saindo, as tecnologias estão mudando. Nunca sabemos realmente se nosso software pode fazer o que queremos, quantos bugs haverá – há muita incerteza. 

Eu vejo muitas empresas não sabendo lidar com essa realidade. Elas dependem muito de planejamento top-down, decisões por comitê, opiniões, heurísticas fracas e vieses cognitivos. É por isso que desenvolvi o framework GIST para ajudar as empresas a direcionar sistematicamente seus produtos para o impacto nos negócios e no mercado. O sistema possui quatro camadas: Metas, Ideias, Etapas e Tarefas. As metas incluem OKRs e métricas. As ideias são sobre como coletar e avaliar muitas ideias rapidamente, usando evidências. As etapas são miniprojetos desenvolvendo a ideia e testando-a ao mesmo tempo (implementando os princípios de Lean Startup e Design Thinking), e as tarefas são as atividades do dia a dia que implementam as etapas. Você pode ler mais sobre GIST aqui (em Inglês). 

A Calculadora de Confiança é uma ferramenta que desenvolvi para possibilitar que as pessoas avaliem a força das evidências que apoiam suas ideias. Por exemplo, as opiniões e o suporte temático (a área azul no canto superior direito) nos fornecem evidências fracas e, portanto, muito pouca confiança. Testes e experimentos (vermelho-escuro no canto superior esquerdo) nos fornecem evidências fortes e muito mais confiança. A estrutura GIST o orienta para testar ideias iterativamente, em loops “construir-medir-aprender” e, em seguida, reavaliá-las usando esta 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