fbpx

OKRs para times de produto: como usá-las da forma correta

Francisco Homem de Mello

Kiko from Qulture.Rocks

Este é o primeiro artigo de uma série sobre os problemas mais comuns que startups encaram quando implementam OKRs. Esse primeiro fala sobre os desafios de usar OKRs para gerir times de produto. Fique ligado nos próximos conforme forem lançados!

Há alguns meses atrás, passei dois dias no The Creamery, em São Francisco, ajudando mais de vinte colegas fundadores de startups aceleradas pela Y Combinator a acertar as OKRs de suas empresas. Eu sentei com equipes que estão construindo redes sociais, jogos, produtos D2C, APIs de segurança cibernética e até ajudando a melhorar a educação na África; e depois de dois dias cansativos de 10 horas de trabalho focado, decidi escrever artigos sobre os desafios mais comuns que eles enfrentaram, e esse é o primeiro artigo dessa série.

O desafio número 1 desses fundadores foi definir OKRs para suas equipes de produto de software. Geralmente era assim: confundir OKRs com listas de tarefas que definem os recursos a serem entregues. E é honestamente um desafio muito difícil que também enfrentamos na Qulture.Rocks. Mas estamos aprendendo e acho que agora podemos ajudar outras equipes que enfrentam os mesmos problemas.

Em times de produto, OKRs não são sobre recursos a serem entregues

Um grande desafio é que as OKRs são uma disciplina difícil e a maioria das pessoas erra ao tentar usá-las em equipes de produto. O ecossistema de OKR também não ajuda – uma rápida pesquisa na Internet me levou ao site de um concorrente, onde encontrei o exemplo a seguir como inspiração para uma boa OKR [1]:

“Objetivo: implementar um novo processo de planejamento de produto 360º

Resultados-chave:

– Documentar clara divisão de papéis entre vendas, marketing, design e desenvolvimento (sic)

– Decidir e documentar o processo de métodos de entrada de vendas, marketing, design e desenvolvimento (sic) voltado ao gerenciamento de produto

– Integrar o teste de usuário em todas as atividades na fase de planejamento e design do produto

– Integrar testes com usuários na fase de testes pré-lançamento”

Site do concorrente 🙁

Sem mencionar o site re:Work, mantido pelo Google (a empresa que basicamente ajudou o evangelho da OKR a se espalhar pelo Vale do Silício), que cita “comer 5 tortas” como exemplo de um ótimo objetivo, mas deixarei isso para outro post (se você quiser aprender o básico sobre OKRs, leia nosso livro, OKRs, da Missão às Métricas).

De qualquer forma, a maioria das OKRs de equipes de produto são mais ou menos assim:

Objetivo: Entregar novo aplicativo

Resultados-chave:

– Desenhar primeiro conceito
– Codar MVP (Minimum Viable Product)
– Obter testadores beta
– Publicar o aplicativo até novembro nas lojas de aplicativos

O que há de errado com isso?

(Produto) Todas OKRs são sobre RESULTADOS

Se você ler Inspired, um ótimo livro sobre gerenciamento de produto, de Marty Kagan, fundador do Silicon Valley Product Group e um grande sucesso, você entenderá que devemos abandonar roadmaps como os conhecemos (longas listas de recursos a serem construídos ) e substituí-los por OKRs.

O que ele está dizendo é que os roadmaps são ruins para as equipes de produto porque não são uma direção que os times possam seguir. Os roadmaps são geralmente construídos por uma mistura de intuição, palpites e opiniões das pessoas-mais bem-pagas-na-sala.

Em vez de um roadmap, os times de produto e seus líderes devem definir OKRs claras – ou resultados esperados – e permitir que suas equipes de produto descubram o que fazer – ou o que construir – para alcançá-las.

Entregar recursos é um *esforço* que, esperançosamente, produzirá *resultados* futuramente. Vamos chamar os recursos, ou o esforço das equipes de produto, de “output”.

Mas definir OKRs apropriadas é difícil e, geralmente, as equipes voltam para algum tipo de confusão entre OKRs e um roadmap. E roadmaps são coleções de esforços.

Quando entregamos um novo recurso, não há garantia de que ele gerará algum impacto em nossos negócios, bom ou ruim. Os usuários podem nem usá-lo (e sabemos da maneira mais difícil que isso costuma acontecer).

Portanto, não confunda esforços e resultados, roadmaps e impacto: ao gerir equipes de produtos – na verdade, sempre -, as OKRs devem ser sobre resultados e não esforços. Entregar recursos é um *esforço* que, esperançosamente, produzirá *resultados* futuramente. Vamos chamar os recursos, ou o esforço das equipes de produtos, de “output”.

Resultados financeiros não são bons objetivos para se buscar

Maravilhoso. Agora sabemos que as OKRs de equipes de produto não devem parecer roadmaps ou recursos a serem entregues.

Temos que encontrar resultados com os quais trabalhar. Então, quais resultados um recurso entregue pode produzir?

No nível mais alto, e sendo bastante simplista, os recursos devem gerar mais receita ou menos custos para a empresa proprietária do produto. Esse impacto nos resultados pode vir rápido, como por exemplo mais conversões para um site de comércio eletrônico neste trimestre, ou pode demorar um pouco mais, como mais qualidade percebida na linha do tempo de uma rede social que reduzirá o churn e, assim, produzirá mais receitas no futuro.

Mas esses tipos de resultados de negócios são realmente difíceis de se relacionar ou otimizar. É difícil mapear o impacto dos recursos para a linha superior ou inferior da empresa. (Obviamente, algumas exceções devem existir: quando uma equipe trabalha para corrigir bugs terríveis no fluxo de check-out de um site, elas podem afetar as vendas diretamente, na forma de fazer com que os clientes fechem em vez de comprarem em outros lugares. Mas geralmente as coisas são um pouco mais sutis.)

Outro problema é que os resultados financeiros vêm de muitas variáveis. Não podemos atribuir à equipe de checkout quanta receita os clientes estão trazendo para uma operação de comércio eletrônico. O resultado também é impactado pelo mix de produtos, pela usabilidade geral da loja, pelos custos de envio e pela velocidade, apenas para citar alguns exemplos. Não seria justo nem útil.

Portanto, precisamos encontrar outros resultados para basear as OKRs de nossos produtos.

Resultados

Joshua Seiden tem um ótimo livro chamado “Outcomes over Output” que nos ajudará a progredir [2]. É honestamente uma leitura obrigatória para todos os times de produto.

Seiden chama os resultados de negócios, como receitas, lucros e custos, de “Impactos” (vamos iniciar com letra maiúscula os termos que ele utiliza em seu livro quando os usarmos conforme sua especificação). Ele também chama as coisas que as equipes de produto constroem (recursos), como “Output”.

Mas Seiden não para por aí: ele sugere que há algo entre Outputs e Impacto que devemos estar cientes: Resultados. A definição de um resultado é bastante simples: “os comportamentos humanos que geram resultados nos negócios”. Ele continua dizendo que “queremos que nossos clientes acessem nosso site com mais frequência, ou que coloquem um item extra no carrinho de compras, ou compartilhem um artigo interessante com um amigo, ou façam upload de uma foto, ou concluam uma tarefa em menos tempo. O que todas essas coisas têm em comum? São todas as medidas do comportamento do cliente. Podem ser pequenas mudanças em um grande sistema, mas são específicas e permitem que nossas equipes tenham a flexibilidade para descobrir a maneira mais eficiente de resolver o problema, oferecer a mudança de comportamento que procuramos e fazer uma contribuição significativa para os impactos (receita, lucratividade) com os quais nossos líderes executivos se preocupam.”

Em nosso negócio (software que ajuda times a implementar 1:1s, feedback contínuo e reconhecimento entre colaboradores), alguns exemplos de Resultados para os quais construímos são:

  • Número de feedbacks fornecidos pelos usuários
  • Número de 1:1s efetuados pontualmente pelos usuários
  • Porcentagem de usuários da persona de “liderados” que receberam feedback nos últimos 30 dias

Você entendeu. Resultados são comportamentos do usuário que acreditamos que gerarão impacto (ou resultados de negócios). Como regra geral, se suas OKRs – mais especificamente, seus resultados-chave – não saem do Mixpanel, você provavelmente está fazendo isso errado.

OKRs, Resultados, experimentos e MVPs

Você leu certo: acreditamos que os Resultados levarão ao Impacto.

O que separa ótimos times de produto dos medíocres é a frequência com que essas suposições são acertadas e/ou a rapidez com que iteram quando estão errados.

Como regra geral, se suas OKRs – mais especificamente, seus resultados-chave – não saem do Mixpanel, você provavelmente está fazendo isso errado.

Voltando a Marty Kagan, o fato de que nem sempre as entregas levam a Resultados, nem os Resultados a Impacto, é o motivo pelo qual as equipes de produto devem preferir as OKRs em vez de um roadmap: os roadmaps devem ser flexíveis e não estarem em pedra, pois eles mudarão frequentemente na jornada de maximização para o Impacto.

Obviamente, as equipes de produto – ou a maioria das equipes de produto hoje em dia – ainda terão algum tipo de backlog de recursos para criar. Mas esse backlog não será simplesmente uma materialização refinada do roadmap: esperamos que seja uma lista de recursos que foram comprovados, na medida do possível, para gerar Resultados.

O processo de descobrir se os recursos realmente produzirão resultados é chamado descoberta. A descoberta acontece por meio de experimentos ou dos menores esforços (ou seja, tempo da equipe) que podem provar nossas hipóteses sobre quais recursos impulsionarão os Resultados, e quais  Resultados gerarão Impacto. As equipes de produto sempre devem executar experimentos que testam essas hipóteses, com o mínimo de código possível.

A propósito, uma equipe de produto deve trabalhar em seus esforços de descoberta em paralelo aos seus esforços de entrega. A descoberta está constatando quais recursos levarão a Resultados. Entrega está construindo esses recursos com qualidade no nível de produção. O bom é que os Resultados, nos quais suas OKRs devem se basear, mudam com muito menos frequência. Eles tendem a ser métricas que otimizaremos a médio e longo prazo. É difícil pensar que o Facebook não maximize o tempo que os usuários passam rolando em seus Feeds de Notícias [3] ou o número de postagens a que um usuário reage em uma determinada sessão ativa.

Definindo OKRs com base em Resultados

Está bem. Chega de falar termos técnicos de produto. Então, como é uma OKR adequada para um time de produto?

Pergunte a si mesmo quais Resultados queremos criar com este “output” (recurso)? E então qual Impacto queremos criar no negócio com este Resultado?

Digamos que temos uma equipe de produto na Qulture.Rocks [4] composta por um gerente de produto, um designer e alguns engenheiros de front e back-end. Digamos também que as OKRs da Qulture.Rocks neste trimestre giram em torno do crescimento de MRR de novos clientes, crescimento de MRR de clientes existentes (via expansão líquida) e queima de menos de uma determinada quantia de dinheiro a cada mês, a fim de preservar o tempo de vida da empresa. O objetivo deles [5] poderia se parecer com o seguinte:

Aumentar a taxa de ativação de líderes técnicos com nosso produto

De onde veio esse objetivo?

Os membros da equipe executiva descobriram que os líderes das equipes de tecnologia são uma ótima persona para otimizar: eles convertem a um baixo custo (CAC) e dão muito pouco churn quando ativados adequadamente (o processo que começa com uma inscrição e termina com um usuário feliz, ativo e retido). Eles também descobriram que não são muito bem-sucedidos na ativação de líderes técnicos: mais de 50% dos que se inscrevem acabam abandonando o produto antes de experimentar seu valor.

Certo. Agora, quais resultados-chave [6] a equipe possui?

Resultado-chave: taxa líquida de ativação de usuários classificados como “líderes técnicos” de 50% para 70%

O interessante dessa OKR é que nosso time de produto pode executar um grande número de experimentos sobre o que eles poderiam fazer para melhorar nossa taxa de ativação. Eles podem criar um fluxo de integração específico para os líderes técnicos; eles poderiam ligar para cada líder técnico no telefone para explicar o valor do produto para eles; eles poderiam pré-carregar o aplicativo com as OKRs da equipe do produto para que os líderes técnicos vejam rapidamente o valor; ou eles poderiam trabalhar em uma campanha de e-mail para recuperar esses usuários do produto (reativá-los).

Como as OKRs devem ser alinhadas (ou desdobradas, conforme preferir), essa OKR pode ser alinhada – ou contribuir – para a seguinte OKR:

Objetivo: Melhorar a retenção de clientes

Resultado-chave: taxa de churn mensal bruta, de 2% para 1,4%

E essa OKR de “churn” pode ser alinhada a seguinte OKR de toda a empresa:

Objetivo: Melhorar nosso MRR de acordo com o que há de melhor no mercado

Resultado-chave: MRR, de US$240 mil para US$330 mil

E se já tivermos um roadmap?

Provavelmente, se está lendo este artigo, você já possui um roadmap. Quero deixar claro que você não precisa cortar seu roadmap em pedaços imediatamente, mesmo que isso fosse legal.

O que você pode fazer é ver o que vem a seguir em seu roadmap. Pergunte a si mesmo: quais Resultados queremos criar com este “output” (recurso)? E então qual Impacto queremos criar no negócio com este Resultado? Essas perguntas permitirão que você primeiro defina a linha de pensamento correta e, em segundo lugar, verifique se o seu roadmap faz sentido para o negócio. Em seguida, você deve parar gradualmente de atualizar seu roadmap e definir OKRs no lugar dele.

Um grande desafio para as OKRs de times de produto: software corporativo

Por fim, vamos falar sobre alguns desafios que times de produto corporativos podem enfrentar nessa jornada de usar OKRs para mudar de Output para Resultados para Impacto.

Fazer isso corretamente em um software corporativo é  mais difícil por dois motivos: a conexão de Resultados e Impactos pode ser fraca ou difícil de provar e/ou os Resultados podem ser difíceis de medir adequadamente. Isso ocorre porque, respectivamente, em um software corporativo, os compradores raramente usam o produto (confira este tweet) e o uso geralmente é afetado por fatores externos.

Para explicar o primeiro caso, vamos imaginar Jane, a CFO, que trabalha para o Jalmart (personagens fictícios). Ela compra o Oriple ERP porque deseja ter todas as suas informações financeiras organizadas em um único local (o empregador está se preparando para uma abertura de capital). Agora vamos para um time de produto nos escritórios de New Dehli da Oriple, que cuida de um recurso específico que lida com contas a pagar. Digamos também que essa equipe queira melhorar a taxa de faturas inseridas corretamente no sistema na mesma sessão ativa. Se eles fizerem isso, os analistas de contas a pagar das empresas que usam a Oriple provavelmente adorarão o quão fácil ficou esse fluxo de trabalho. Mas isso realmente afetará as receitas da Oriple? Ou sua taxa de churn? Jane, a diretora financeira, provavelmente nunca verá esse recurso. E serão necessários muitos “chutes” e “gritos” de toda a empresa para que ela mude de ERP, especialmente após o pesadelo do processo de implementação que a Agzzenture executou por dois anos.

Nesses casos, é difícil testar a suposição sobre se um Resultado gerará Impacto. As equipes de produto terão que confiar em sua intuição (e nas tendências de mercado que apontam para a consumerização do TI corporativo) para realizar o trabalho.

Para explicar o segundo caso, vamos imaginar Ned, o analista. Ele “usa” o Facelook Wordplace porque o departamento de RH da Jowen and Co. implementou a rede social corporativa em toda a empresa. “Usa” entre aspas porque Ned raramente faz login. Ele acha chato. No mês seguinte, a CEO da empresa, Gretta, anuncia sua saída em um post estranho no Wordplace, e todos os funcionários da empresa fazem login para lê-lo e fofocar.

Agora vamos para um time de produto em crescimento no Facelook que lida com o Wordplace, um produto jovem com cerca de 15 clientes. Eles têm uma OKR que gira em torno de reativar usuários inativos e estão realizando várias experiências com campanhas de email e notificações por push. A equipe achou que tinha alguns resultados promissores no teste A/B com os pushs e estava prestes a definir um recurso completo para o backlog quando soube do post na Jowen. Eles terão que abandonar a OKR por completo e seguir em frente com pura fé, ou interromper tudo o que estão fazendo e aguardar mais resultados dos testes.

Não há resposta certa para esta pergunta.

Você pode pensar que isso é incomum, mas existem muitos produtos corporativos que têm métricas de uso poluídas por comportamentos “offline” e pode ser muito difícil limpar as métricas e obter algo significativo. Softwares de RH são especialmente complicados, como podemos atestar.

É isso aí. Espero que isso ajude você a usar OKRs para gerir suas equipes de produto 🙂 Não hesite em entrar em contato comigo pelo e-mail kiko@qulturerocks.com caso você queira fazer qualquer comentário ou sugestão!


Notas

[1] Talvez eles devam mudar seu negócio para consultoria em SEO 😉

[2] Como costumamos fazer na Qulture.Rocks, adquirimos cinco cópias do livro para nossa equipe de produto compartilhar.

[3] É preciso um movimento de “time well spent” para mudar isso.

[4] Nós temos um exatamente assim.

[5] Lembre-se: um objetivo é uma meta qualitativa, geralmente começando com um verbo e terminando com uma descrição não numérica de um aspecto do negócio a ser aprimorado. Alguns exemplos: “aumentar a adoção”, “reduzir nossa queima de caixa” ou “aumentar a satisfação de nossos clientes”.

[6] Lembremos também: um resultado-chave é a soma de um KPI (por exemplo, “lucro líquido da empresa em 2020”), um valor base (“100.000”) e um alvo (“200.000”). Acreditamos que os objetivos devem ter um escopo suficientemente estreito para gerar um ou dois resultados-chave. Se seu objetivo tiver mais de dois resultados-chave, você provavelmente tem um escopo muito grande.

Muito obrigado a Sam, Aaron, Marty e Hugo pela leitura dos rascunhos deste artigo.