É muito comum encontrar Product Managers que raciocinam da seguinte maneira: o usuário tem um problema, então, faço uma funcionalidade/melhoria/mudança e resolvo o problema.

Mas não é só por que finalizamos e shipamos uma funcionalidade, que o problema será resolvido ou muito mais importante: que essa entrega causou o impacto desejado no comportamento do usuário e/ou trouxe impacto positivo financeiro ou de posicionamento para a empresa.

Direcionando seu produto por entregas e funcionalidades (outputs)

Quem nunca teve que preparar uma apresentação para a empresa - principalmente para os stakeholders - com um roadmap de entregas de funcionalidades? É comum as pessoas precisarem/desejarem ver quando e o que será entregue a fim de entender onde e quando teremos os resultados para o usuário ou para a empresa.

É melhor investir mais tempo no Upstream do processo, conhecendo mais o problema, entendendo seus meandros e motivos, para depois avançar para uma solução.

A quantidade de software (traduzido em funcionalidades, bugs, débitos técnicos, alinhamento de design…) entregue, não importa. O que importa é se essas entregas estão impactando o comportamento do usuário, que por sua vez impactam os indicadores de produto, que por sua vez devem impactar indicadores de negócio.

Direcionando seu produto por resultados (outcomes)

Os outcomes são definidos por indicadores mensuráveis pelo time, que é importante para o usuário ao mesmo tempo que para o negócio.

Isso é muito mais fácil dizer do que fazer. O correto é que a empresa tenha um alinhamento claro e transparente sobre os objetivos que precisam ser alcançados. Dessa forma o time pode decidir como impactar o usuário para alcançar os objetivos globais. O trabalho do Product Manager nesse ponto é instigar a liderança a definir e criar alinhamento sobre os objetivos que precisam ser atingidos. O time então expõe quais as oportunidades que podem ser exploradas que tem mais chances de dar um bom resultado.

A ideia é que você trabalhe para modificar resultados, e não meça sua performance por entregas de funcionalidades.

Você deve definir seus Outputs apenas depois de definir os Outcomes. Isso parece ser simples e óbvio, mas geralmente não é isso que acontece.

Contudo, a definição dos resultados que devemos atingir só vem depois de identificarmos os problemas e necessidades dos usuários. Muito por isso é tão importante conhecer bem a proposta de valor da empresa e qual o posicionamento que o produto deverá ter no mercado.

O problema da confiança

Um dos principais problemas de liderarmos nossos produtos por meio de outcomes é a falta de confiança que gestores e stakeholders tem em seus times.

Essa desconfiança cria um ambiente onde stakeholders e a liderança faça microgerenciamento dos outputs (entregas). Que por sua vez faz o time se afastar cada vez mais do principal objetivo que é entregar outcomes (resultados). Que faz os gestores e liderança terem ainda menos confiança.

Como líderes, devemos perguntar mais, e os times deveriam mostrar melhor seus resultados, não fixando os olhares nas entregas, mas nos objetivos alcançados. Enquanto a liderança define, de forma transparente e objetiva, o que deve ser alcançado, o time tem o direito de decidir o como você chegarão lá.

Referências:

• You Need to Manage Digital Projects for Outcomes, Not Outputs
• Everyone Thinks They’re Managing by Outcomes. Here’s How to Actually Do it.
• Managing digital product teams to outcomes instead of output
• Problem vs solution mindset