Este post se baseia em conceitos discutidos aqui e aqui. Para aproveitá-lo ao máximo, recomendo começar por lá.
Este post também está disponível em inglês.
Stephen Covey capturou um dos princípios centrais por trás da abordagem de outcomes em sua famosa frase: "Comece com o fim em mente".
Comece definindo claramente o outcome desejado, por que ele é importante e as restrições e limites para alcançá-lo.
Então, trabalhe de trás para frente para descobrir como atingir o outcome. Experimente diferentes ideias ou abordagens para identificar quais ajudarão a alcançá-lo.
A Amazon é famosa por usar uma técnica similar chamada Working Backwards (trabalhando de trás para frente). A ideia é começar com as necessidades do cliente e trabalhar de trás para frente a partir delas (veja o texto explicativo no final do artigo).
Para entender melhor como começar com o fim em mente, vamos ver um exemplo:
Exemplo
Outcome desejado: Ajudar os clientes a resolverem problemas sem precisar entrar em contato conosco.
Possíveis métricas que poderíamos usar incluem:
Taxa de sucesso de autoatendimento: o percentual de problemas do cliente resolvidos por canais de autoatendimento.
Taxa de contato (contact rate em inglês): o número de vezes que os clientes entram em contato com a empresa para obter ajuda em um determinado período.
Por que é importante: Ajuda a melhorar a experiência do cliente e reduz custos ao mesmo tempo.
Restrições: Todas as soluções devem ser implementadas dentro da arquitetura de software atual.
Limites (ou salvaguardas): Evite práticas questionáveis, como dificultar excessivamente o contato dos clientes conosco.
As mudanças não devem impactar negativamente a experiência do cliente, conforme medido por métricas como pontuação de satisfação do cliente ou net promoter score (NPS).
Você não precisa usar exatamente este formato. Este é apenas um exemplo do tipo de conversa que você deve ter ao começar com o fim em mente.
Por que é importante começar com o fim em mente?
Nossos cérebros estão programados para pensar em projetos.
Quando vemos um problema, naturalmente começamos a pensar sobre o que podemos fazer, quem pode fazê-lo e qual é a data.
Muitas vezes operamos no piloto automático, fazendo o que sempre fizemos. Quando fazemos isso, trabalhamos mecanicamente sem questionar o que queremos alcançar ou como trabalhamos.
Também é extremamente fácil se apaixonar por nossas ideias e acreditar que todas farão a diferença.
Todos nós tendemos a cair no mindset sabe-tudo, assumindo que temos todas as respostas e que todos os nossos projetos gerarão resultados.
Gosto de dizer que temos um Coiote do desenho Papa-Léguas vivendo dentro de nossos cérebros.
O Coiote se apaixona pelos nossos projetos e começamos a pensar: "Claro que vai funcionar. É uma ideia brilhante!"
Já perdi a conta de quantas vezes ouvi pessoas dizerem que não precisavam medir o outcome de seu projeto porque ele obviamente seria bem-sucedido.
Todos nós tendemos a nos apaixonar por nossas ideias e acreditar nelas.
Não há problema em ser apaixonado pelo seu trabalho. O problema é pelo que você se apaixona.
Esta frase famosa de Ash Maurya é um aviso importante:
Ame o problema, não a sua solução. A vida é muito curta para construir algo que ninguém quer.
Então, apaixone-se pelo que você está tentando alcançar e pelo problema que está tentando resolver.
Se apaixone por fazer a diferença no seu trabalho e ajudar os clientes ou seus colegas. Mas não se apegue demais à sua solução específica ou ao projeto em que está trabalhando.
Começar com o fim em mente ajuda a combater nossa tendência de pensar em projetos, forçando-nos a fazer uma pausa e definir o outcome desejado.
Adicionar outcomes depois não é suficiente
Muitas pessoas definem seus OKRs na ordem errada. Elas começam selecionando os projetos em que trabalharão e depois definem OKRs com base nisso.
Por exemplo, as empresas geralmente começam criando um orçamento listando os projetos específicos em que investirão e depois criam OKRs com base neles.
Ao mesmo tempo, os times de produto geralmente começam com o que está em seu backlog e colocam isso em seus OKRs.
Isso acontece mesmo quando os líderes estão tentando dar autonomia aos times—os colaboradores individuais também tendem a se apaixonar por suas ideias.
Às vezes, as pessoas tentam consertar isso adicionando outcomes depois que os projetos já foram definidos. O problema é que elas geralmente acabam se prendendo a essa lista de projetos, independentemente do outcome.
Focar em outcomes significa experimentar diferentes maneiras para alcançá-los.
Se você não está testando diferentes ideias, ou diferentes maneiras de implementar a mesma ideia, você não está focando em outcomes.
Começar com o fim em mente é um conceito simples e poderoso que pode nos ajudar a focar em outcomes. Mas para aplicá-lo na prática, as empresas precisam desaprender velhos mindsets e abandonar práticas que reforçam comportamentos antigos.
Perguntas para refletir
Aqui estão duas perguntas para te ajudar a conversar sobre este artigo com seus colegas:
Pense em seus OKRs mais recentes. Você começou com o fim em mente ou começou com uma lista de projetos?
Analise seus processos de orçamento e planejamento. Eles ajudam os times a começar com o fim em mente? Que mudanças você poderia fazer para permitir que você comece definindo os outcomes desejados?
Estarei de volta em breve com outro post. Enquanto isso, sinta-se à vontade para compartilhar seus pensamentos nos comentários ou me enviar um e-mail.
Se você gostou deste artigo, compartilhe com amigos. Se alguém te encaminhou este post, assine minha newsletter para receber mais conteúdo direto no seu email.