OKRs versus roadmaps em times de produto
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:
“OKRs versus roadmap, como equilibrar os dois no time?” essa pergunta é uma piada interna dos PMs da RD, que utilizam ela pra dizer que algo é polêmico ou que não existe uma resposta clara. Isso aconteceu porque por cerca de 1 ano nós usamos tanto roadmaps quanto OKRs no time de produto, o que gerava bastante tensão entre o que dizíamos que íamos fazer no roadmap e os objetivos que tínhamos que atingir nos OKRs. Hoje essa não é mais uma tensão pra gente, mas com certeza é em várias empresas. Esse post tem como objetivo responder essa pergunta de forma clara e inequívoca, sem ficar se esquivando ou dizendo coisas como “depende do que funciona pra sua empresa e seu time”.
Por que usar roadmaps?
Muitas empresas usam roadmaps de 3–6 meses, algumas têm até roadmaps de 2 anos no futuro. Mas por que eles existem? Roadmaps são uma ferramenta confortável para a gerência, pois tornam possível dizer o que cada time está fazendo, o que será feito na sequência e se estamos atrasados. Isso ajuda na comunicação com a diretoria, clientes e até o resto da empresa.
Porém há um problema fatal com roadmaps: eles focam em output (o que vamos fazer) ao invés de outcome (o que vamos atingir) (Tweet This). Desta forma é possível entregar todos os itens do roadmap antes do prazo, mas sem mover de forma significativa nenhuma métrica relevante do negócio. Por conta desse foco em output, segundo o próprio Marty Cagan, se ele precisasse escolher só uma causa para o fracasso da maioria dos produtos, ele colocaria a culpa nos roadmaps.
80% do seu roadmap (na melhor das hipóteses) está errado
Marty dá o exemplo de dois times de produto que ele conversou e que disseram a mesma coisa para ele: só 10% das iniciativas do roadmap surtiram o efeito de negócio desejado. Isso significa 90% de falha. E esses times não eram amadores, é o time do Google Cloud e do Bing. Digamos que seu time de produto tenha o dobro da competência deles, mesmo assim isso significa que no seu roadmap só 20% das iniciativas vão trazer resultado para o negócio.
Como inverter essa proporção e aumentar o número de iniciativas que dão certo? Veja o post sobre agile em discovery.
Roadmap não é o problema
O roadmap em si não é o problema, roadmap é só uma ferramenta. O problema é o foco em output, não em outcome. É possível por exemplo fazer roadmaps baseados em outcome (quais objetivos de negócio queremos atingir). Porém essa troca de output por outcome não é fácil, pois ela é desconfortável pra todo mundo: é mais difícil para comunicar o que está sendo feito para os clientes, é mais difícil para os executivos pois eles precisam depositar confiança no time de produto e é mais difícil para o próprio time, pois não será cobrado por entregar uma feature ou projeto, mas sim se a feature/projeto atingiu os resultados esperados para o negócio.
E é nesse contexto que OKRs são úteis:
OKRs, uma alternativa ao roadmap
Vou parafrasear o Marty Cagan, porque isso é importante deixar claro: “se vocês estão usando tanto OKRs quanto roadmaps, vocês estão fazendo algo errado. OKRs são uma alternativa aos roadmaps” (Tweet This). Ou seja, não há nenhuma tensão entre OKRs e roadmaps, pois eles são mutuamente excludentes. Ou você usa um ou outro, não os dois.
Marty é um defensor dos OKRs, pois ele torna mais fácil fazer com que os times foquem em outcome, não em output como é comum com roadmaps. Os OKRs possibilitam comunicar os objetivos a serem atingidos (o que é importante), sem prender o time com uma possível promessa de solução que pode ou não resolver o problema. Ele dá diversos exemplos no workshop e no seu livro, Inspired, sobre como essa diferença foi essencial para produtos que trouxeram grandes resultados, como Adwords e Netflix. Vou apresentar aqui o exemplo que ele deu da Netflix (e que também aparece no livro Inspired):
Em 1999, quando a Netflix ainda nem sonhava em ser um serviço de streaming, eles eram um serviço de aluguel de DVDs pelo correio. Porém o envio pelo correio não era um valor tão grande ao consumidor assim, que muitas vezes poderia passar na Blockbuster do seu bairro. Foi aí que o time de produto de uma PM chamada Kate Arnold recebeu a missão de aumentar o número de clientes e receita. O time de Kate foi responsável por transformar a Netflix de um produto onde se pagava por DVD alugado, para um de assinatura, onde o cliente pagava um valor fixo todo mês. Isso aumentou bastante o número de assinantes e a receita da empresa, mas criou um novo problema: as pessoas queriam os filmes mais novos, que eram bem mais caros para a Netflix do que filmes antigos. O time de Kate recebeu a missão de reduzir o custo de inventário, foi então que o time bolou a funcionalidade de lista de espera e também de recomendação (para recomendar bons filmes mais antigos, logo mais baratos e com menos demanda para a Netflix).
Você acha que se o time de Kate fosse focado em entregar funcionalidades do roadmap ao invés de perseguir objetivos de negócio, eles teriam conseguido criar soluções tão boas? Marty duvida bastante. Por isso ele é um defensor da metodologia de OKRs e, principalmente, que times de produto parem de focar em entregas, mas foquem sim em objetivos. Porém, setar OKRs é uma arte em si e nesse outro post eu entro em detalhes de como Marty sugeriu realizar um bom processo de OKRs na empresa.
Curtiu? Clica no ícone das palmas e acompanhe o que eu escrevo aqui.
Jabá: quer aprender a extrair insights de produto de entrevistas?
Eu tenho um curso online de como realizar entrevistas baseadas em jobs-to-be-done. Se você quer aprender mais a fundo como realizar essas entrevistas, se inscreva lá.
Aqui estão alguns dos reviews do curso Jobs-to-be-Done na prática:
