Dicas e lições aprendidas de como ir do Output driven ao Outcome driven

Durante toda minha carreira como Gerente de Produto fui evoluindo cada vez mais para o lado de entregar resultados ao invés de simplesmente entregar funcionalidades. Quem mais me ensinou isso foi o Thomas Floracks, VP de Produto e Fundador do VivaReal, que sempre fez as perguntas certas para me fazer refletir “Nós queremos ser output driven ou outcome driven?”. Conforme fui mudando a forma de pensar para focar em resultados (outcome) fui percebendo que é um trabalho muito mais difícil porque você precisa pensar muito mais no cliente e se aprofundar nos problemas deles.

Recentemente fui ao Lean Startup Conference de 2017 e participei de um Workshop com Bruce McCarthy, um dos autores do livro Product Roadmaps Relaunched. O Workshop abriu ainda mais a minha mente sobre como criar roadmaps focados em resultados ao invés de meras funcionalidades.

No final do Workshop algumas pessoas ganharam o livro e eu fui um dos sortudos. Desde então esse livro virou uma grande referência para mim — super recomendo a leitura. Porém tem um trecho que discordo e é justamente quando ele fala como transformar soluções (output) em resultados (outcomes).

Vou usar o livro como base para explicar como você pode criar iniciativas, hipóteses ou experimentos mais voltados para resultados do que soluções e aproveitar para apontar uma pequena mudança no que foi proposto pelos autores do livro.

No exemplo do livro está dessa forma:

O problema é que eu não acredito que a descrição de outcomes devessem ser tão fracas assim. Acredito que eles precisam ter um racional mais bem explicado. No livro os autores usam a terminologia “Themes” para criar hipóteses. Para chegar onde eu quero primeiro vou explicar antes um simples conceito de Hipóteses Fracas vs Hipóteses Fortes

Existem dois tipos de hipóteses

Hipotese fraca

Se o funil de compra tiver menos páginas, vamos aumentar a conversão de compra da loja

Hipótese forte

Se a navegação for removida das páginas de checkout, a taxa de conversão em cada passo vai aumentar porque o analytics do site mostra que uma porção desses usuários está deixando a página antes de clicar no link de navegação dessas páginas
Você percebe a diferença?

Criando hipóteses

“Se [variável], então [resultado], porque [racional].”

Variável

  • O elemento que vai ser modificado
  • Isole essa variável para testar sua hipótese (pode ser através de A/B test ou prototipagem)
  • Pense no Call to action, visual ou formulário

Resultado

  • Preveja o resultado
  • Use dados para determinar o efeito dele
  • Mais e-mails? Mais signups? Mais CTA? Mais conversão? Mais CTR?

Racional

  • Demonstre o quanto você conhece os seus usuários
  • O que vai estar provado ser incorreto caso o experimento seja igual ou inferior ao atual?

Exemplo de como formular hipóteses

“Se as imagens chamarem mais atenção, então a taxa de clique vai aumentar, porque sabemos que as imagens são um dos fatores mais importantes para quem busca um imóvel.”

Acima é um exemplo real de pesquisas que fizemos no VivaReal quando eu ainda era Product Manager lá. Você consegue notar a diferença entre uma hipótese fraca com racional quase nulo versus uma hipótese forte com um racional que faz sentido e possui evidências?

Um bom Gerente de Produto precisa gostar de ser questionado e desafiado. Quando você apresenta uma hipótese mais forte, com um estudo e evidências por trás, você está se abrindo mais para tomar porradas com questionamentos do que simplesmente feedbacks como “ah, eu não concordo”. Dessa maneira você basicamente enriquece todo o processo de definição dos próximos passos do seu produto.

A minha alteração para a tabela que foi proposta no livro é a seguinte:

Parece uma mudança pequena mas não é. Gerentes de Produto são canalizadores de boa parte da comunicação dentro de uma empresa e as vezes até mesmo para fora. Pequenas melhorias na comunicação podem ter um efeito enorme no alinhamento e buy-in.

Acredito muito que a melhor forma de identificar se um gerente de produto é bem-sucedido é o feedback que você ouve das outras áreas e engenheiros que trabalham com ele. Eles entendem como e porque o PM está tomando certas decisões? Ele é flexível o suficiente para lidar com o roadmap e fazer todo mundo estar na alinhado em relação ao que foi decidido?

Independente se você trabalha em B2B ou B2C você precisa conseguir se comunicar bem. Explicar o porquê de você estar tomando determinadas decisões, seja no seu roadmap ou durante reuniões, é o que vai fazer a diferença. Comunicação é chave.

Não tem problema ter funcionalidades no seu roadmapÀs vezes vai ser necessário incluir soluções no seu roadmap ao invés de apenas outcomes guiados pelas necessidades do usuário. Por exemplo, supondo que você esteja implementando um novo sistema de busca, pode ser que o time já tenha decidido usar o Elasticsearch e portanto no seu roadmap você poderia colocar, sem problema algum, algo como “Elasticsearch: Prova de conceito”. Vamos supor outro exemplo no qual seria criar um sistema de pagamento para o seu produto. Nesse caso você também poderia ser mais especifico escrevendo algo como ” Billing: Integrar com Pagar.me”

Desde que exista uma justificativa explicando por que você está definindo uma solução está tudo bem colocar elas no roadmap. Não precisa forçar a barra para sempre criar outcomes.

1 — E você? Tem feito um planejamento guiado por resultados e evidências ao invés de apenas funcionalidades? Se precisar de ajuda ou simplesmente quiser trocar ideia sobre isso é só me procurar no Linkedin ou Twitter.
2 — Quer se aprofundar nesse assunto? Eu falo sobre isso, roadmap e priorização no melhor curso de Product Manager online, o Cursos PM3.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>