É 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.
Quando funcionalidades estão no centro do nosso backlog e das nossas discussões, estamos gerenciando nosso produto por Outputs (que eu chamo aqui de entregas, por falta de tradução melhor).
Managers don’t care how they achieve their business goals; they just want to achieve them. — Jeff Gothelf e Josh Seiden
Ser apaixonado pela solução é um erro comum entre novos e velhos Product Managers. Mais correto (e difícil) é ser apaixonado pelo problema. Isso quer dizer que é 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. Aquela velha história de pensar duas vezes pra cortar uma.
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.
Mesmo que as funcionalidade sejam pautadas em necessidades reais do usuário, que foram descobertas em entrevistas de mercado e validadas por dados, você como Product Manager deveria gerenciar seus produtos tendo em vista Resultados (Outcomes).
Direcionando seu produto por resultados (outcomes)
Gerenciar um produto por resultados é direcionar a empresa e o time para alcançar um determinado objetivo, mudando um determinado indicador de produto que por sua vez muda o negócio.
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.
É melhor investir mais tempo no Upstream do processo, para conhecer mais o problema, entendendo seus meandros e motivos, para depois avançar para uma solução. – compartilhe no twitter
Isso é muito mais fácil dizer do que fazer. Se o seu time faz isso sozinho, tem grandes chances de fracassar ou ter entraves bem grandes. 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. Quando uma empresa trabalha com qualquer framework que coloque objetivos e resultados em primeiro lugar - como por exemplo OKRs - definir, medir e monitorar o que será feito fica bem mais fácil e inteligente.
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. Geralmente é uma desconfiança velada sobre a capacidade e competência de deixar o time definir como os outcomes serão alcançados.
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.
Esse é um problema importante que só pode ser resolvido com uma mudança de cultura, comportamento da liderança e também dos times, todos agindo em conjunto e não de modo individual.
Mas existem outros problemas que fazem com que a cobrança por entregas seja maior que por resultados, uma delas é a senioridade e nível de maturidade dos integrantes do times.
Trabalhar com os eixos de Autonomia e Alinhamento não é algo fácil e deve ser exercitado por todos os níveis da empresa. Uma cultura de confiança deve ser criada, mas confiança não vem sozinha, precisa existir uma dose gigante de responsabilidade. Isso quer dizer que ninguém erra sozinho.
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á.
Discussão dos membros