Como OKR ajudou o Gmail a alcançar 1 bilhão de usuários: uma entrevista com Itamar Gilad
Como funciona OKR na prática na empresa que o popularizou?
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.