Outro dia, em um LinkedIn qualquer, compartilharam a imagem abaixo. A imagem é bastante legal no primeiro momento e acho que deve servir para explicar muita coisa. Mas o problema com ela, ao meu ver, que ela sugere que só o futuro trará valor pro cliente, e que esse valor vem apenas de “negócios genuinamente novos”. Eu discordo inteiramente dessa ideia, às vezes você não precisa de negócios genuinamente novos para direcionar a entrega da proposta de valor do negócio para o cliente. EMBORA você precisa entender muito bem as ondas de inovação e estagnação do seu produto.

A manutenção dos principais negócios pode sim entregar muito valor para o cliente. Quantas vezes você já ouviu alguém dizer que “precisamos fazer o básico bem feito”? A imagem não está errada, mas eu diria que ela estaria incompleta, mostrando uma parte muito curta de um processo não linear, longo e complexo.

Eu vou falar de estratégia de produto mais pra frente, mas a imagem de cima é derivação, bem simplista, do desenho que o Matt Hunter tem na palestra dele sobre estratégia de produto.

Aqui, ele explica um framework que se chama “Modelo dos Três Horizontes”. Esse modelo mostra que existem 3 fases de um negócio e consequentemente que é seguido pelo produto.

No horizonte 1, é onde trabalhamos com o core do nosso negócio. O horizonte 2, nós exploramos modelos de negócio adjacentes, que acrescentam valor para o nosso core. E o horizonte 3 são aqueles negócios totalmente novos. Negócios e ideias que realmente não estão sendo feitas por ninguém.

Mas vamos falar de coisas mais simples.

Foco no errado

O livro Outcomes Over Outputs do Josh Seiden, começa com o relato de caso que aconteceu com ele (e com certeza com muitos de nós). Ele diz que trabalhava em 2006 em uma Startup no mercado financeiro em Wall Street, ela já estava começando a fazer bastante sucesso e principalmente dinheiro, mas logo eles perceberam que o produto deles não permitia que os clientes fizessem vários tipo de operação de trade. Então, o CEO, que ele descreve como um visionário empreendedor de sucesso, sugeriu a criação de um novo aplicativo, com um novo modelo diferente de trade, sendo uma solução real, podendo criar um novo modelo de negócio para a empresa e permitindo que o cliente pudesse diversificar suas operações no mercado financeiro.

Logo o time de produtos começou a trabalhar. Tudo o que você pode imaginar foi feito: um bom discovery, um ótimo design, além pesquisas de mercado, tecnologia de ponta e tudo mais para entregar um produto ambicioso que pudesse proteger o negócio deles de um provável futuro trágico.

Isso tudo demorou dois anos e o novo projeto, que criaria um novo negócio para empresa, foi descontinuado. O que foi feito de errado? Ué, eles passaram dois anos sem entregar absolutamente nada.

Contudo, mesmo se eles entregassem algo em fases, de forma progressiva e evolutiva como manda a cartilha, não funcionaria, exatamente por que eles estavam se focando na coisa errada a se fazer. E quando se foca na coisa errada a se fazer, não adianta criar um novo negócio, um novo produto, um novo time, uma nova funcionalidade.

A dinâmica de pensar em Outcomes é mais difícil do que parece

Entregar outcomes é mudar um comportamento do usuário que criará resultados para o negócio. O negócio usado como exemplo no início do texto, já estava dando certo antes, eles poderiam ter melhorado e evoluído o que já estava trazendo outcomes (resultados) para empresa e para os usuários. Manja feijão com arroz bem temperado? Pois é.

Outcomes não tem nada a ver em criar coisas (produtos, negócios e funcionalidades) novas. Em vez disso, outcomes tem a ver com criar mudanças de comportamento dos usuários que direcionam bons resultados para o negócio.

A imagem abaixo está no meu Miro. Se você não conhece o meu Miro, devia conhecer. Assim como esse drive, eu mantenho um board no Miro que tem uma série de imagens bonitas sobre gestão de produtos digitais. Visite.

Esse é um modelo lógico de programa que o Josh Seiden explica no livro dele para exemplificar como podemos pensar sobre outcomes. A história seguinte ajuda muito a gente a fixar a ideia de Outcomes como mudança de comportamento.

Imagine que você trabalha em uma organização de caridade e você foi procurado para construir um sistema moderno de bombeamento de água para um vilarejo. Logo, o time percebeu que as pessoas do vilarejo gastavam muito tempo todos os dias indo até o rio para pegar e carregar a água até suas casas. Seu time então acredita que se as pessoas tivessem acesso a água no centro do vilarejo, eles não precisariam mais percorrer longas distâncias e então poderiam usar melhor o seu tempo em outras atividades que permitiriam aumentar seu padrão de vida.

Os níveis de visão de geração de resultados ou pelo menos que usamos para perceber evolução de produtos podem ser divididas nessas três entidades:

• Outputs: entregas finais, que criam outcomes para o produto. É basicamente o objeto resultante das atividades executadas. Resultado final da produção do trabalho. Geralmente esse nível está localizado na fase de entrega, testes de hipóteses, construção de features etc. Basicamente é tudo quanto é tarefa entregue, seja de desenvolvimento, de planejamento, de design etc;
• Outcomes: o resultado final da mudança de comportamento do usuário quando ele usufrui do valor entregue pelo serviço e isso acaba finalizando na geração de resultado pro negócio. Geralmente está no âmbito de uma região da empresa, no domínio de alguns times especialistas que trabalham colaborativamente ou de forma independente;
• Impactos: o que realmente esperamos que aconteça quando os outcomes se realizarem, seja no negócio ou na vida das pessoas (os clientes que usam seu produto, no caso da história, as pessoas do vilarejo). Geralmente está em um âmbito muito mais de estratégia e que impacta a empresa como um todo;

Há bastante confusão no dia a dia de produto incluindo essas três entidades. A diretoria ou algumas áreas da empresa tem uma visão apenas no âmbito de Impacto e isso não é errado. Alguns deles, eventualmente, trazem junto com essa visão de Impacto uma lista de Outputs, como “sugestão” sobre como eles acham que esses Outcomes devem ser feitos. Muitos PMs tratam isso como Top Down. Mas pela minha experiência, posso dizer que na maioria das vezes isso acontece por causa do desconhecimento dessa lógica de desdobramento.

É importante que nesse momento as pessoas de produto consigam trazer de volta a discussão para o nível de impacto, para que elas tenham margem para tratar do nível de Outcomes.

Para entender bem como criar bons outcomes, a seguinte frase ajuda: Quais comportamentos do usuário essa iniciativa pode criar para direcionar resultados para o negócio?

Conclusão

Há muito espaço para conversa aqui e esse é um assunto muito mais interessante do que parece. Sugiro que você leia o livro do Josh Seiden indicado nesse artigo. Para mim esse livro é a bíblia sobre esse outros assuntos. Ele dá uma visão, que pra mim é essencialmente, o trabalho do PM.

Além disso, tente perceber quais os momentos você confundiu microgerenciamento partindo dos líderes e outras áreas, que na verdade, era desconhecimento sobre os níveis de desdobramento de resultado. Isso vai te ajudar a se comunicar e a se relacionar melhor em ocasiões futuras, já resolvendo na raiz o problema do microgerenciamento não intencional.

Referências

• To Write Better OKRs, use Outcomes | by Josh Seiden | Medium
• Livro: Outcomes Over Outputs
• When Performance Is Measured By Results | Silicon Valley Product Group
• Empower Product Teams with Product Outcomes, Not Business Outcomes | Product Talk
• OUTCOME BASED ROADMAPS : Unleash the Power of a Shared Vision and Purpose | by Jason Doherty | The Startup | Medium