Discovery é o feijão com arroz do trabalho de produto. É preciso descobrir e clarificar o problema, bem como a melhor solução para o problema. Por isso perguntamos para diversos product managers:
Aqui estão os resultados das técnicas “queridinhas” de cada gerente de produto:
“Usei durante minha trajetória na Creditas para trazer alinhamento entre diversas áreas sobre a melhor forma de atacarmos diversas métricas de negócios. Partíamos de um objetivo que queríamos atingir (aumentar taxa de conversão, aumentar produtividade de uma determinada área, etc) e então começávamos a explorar, em conjunto, quais as oportunidades existentes e potenciais soluções para atingir aquele objetivo.
O resultado foi ótimo porque permitiu que diversas áreas enxergassem, de uma forma extremamente visual, todas as possibilidades que tínhamos na mesa. Isso nos ajudou a abrir um leque enorme de alternativas (algumas super fáceis de serem testadas, inclusive) e nos permitiu mudar nosso mindset de foco em solução para foco em problema. Também trouxe um super alinhamento entre os times de Produto e as demais áreas da empresa.”
– Maria Luísa Cantadori, Product Manager @ Stripe
“Com menos de 1 ano como PM, fui buscar qual ferramenta/framework se encaixava no processo que seguia e percebi que era muito parecido com a Opportunity Solution Tree proposta pela Teresa Torres: Desired Outcome, Opportunity, Solutions, Experiments.
Eu começo buscando as oportunidades para atingir meu objetivo principal. Faço isso através de:- Análise de dados: conversão, cobertura, assertividade, etc.;- Avaliação do comportamento do usuário;- Review (ou análise) dos modelos/features/etc utilizados;- E muito cruzamento e comparativo de dados.
Depois de definido o problema ou oportunidade, as primeiras soluções aparecem de forma orgânica e com trocas – entre pares, entre PM-Engineering, entre PM-operações – são definidas hipóteses.Quando possível, essas hipóteses são testadas pelo PM na base de dados (offline) utilizada para descobrir o problema/oportunidade e só a partir dessa primeira visão de benefícios potenciais que partimos para os experimentos.”
– Karyn Serratine, Product Manager @ DiDi
Quer saber mais sobre a árvore de oportunidades? Veja este vídeo da Product Starter onde eu explico como funciona. Além disso tenho o curso Árvore de Oportunidades na Prática que ensina de A a Z como usar a framework.
“No começo de todo discovery, eu gosto de partir de uma Matriz CSD. Esse é um framework extremamente simples, mas acho que cumpre muito bem a função de reunir tudo o que a equipe sabe e a organizar as dúvidas e suposições que são mais críticas e que precisam ser respondidas primeiro. Para mim, a Matriz CSD estrutura o conhecimento do time e direciona o discovery para o que realmente precisamos saber antes, evitando que a gente tente descobrir tudo ao mesmo tempo. Já usei no começo do discovery de uma nova funcionalidade. Aqui, o principal era descobrir a jornada do usuário que o Produto não atendia e entender o resultado esperado, assim, as dúvidas e suposições relacionadas a isso eram as primeiras que precisavam responder. Já agora estou trabalhando em uma funcionalidade bem madura e as principais dúvidas estão nos pontos de atrito com o Produto e o que não atendemos dessa etapa da jornada. Em ambos os casos, a Matriz CSD se aplica e ela é ainda mais útil quando revisitamos ao longo do discovery, porque as novas Certezas costumam gerar novas Dúvidas.”
– Bruna Gonçalves, Product Manager @ Involves
“Gosto de começar as iniciativas com a equipe usando a matriz CSD, assim a gente não coloca barreiras de evidências, dados etc. Uma coisa que acaba gerando também é o engajamento das pessoas de desenvolvimento durante todo o processo, já que desde o primeiro momento elas estão participando com idéias. Dessas suposições criadas a gente evolui para as hipóteses que vamos testar, onde vamos validá-las ou não, gerando todo o aprendizado/descobertas.
Um exemplo prático disso foi em uma iniciativa de melhorar os endereços dos anúncios do portal Viva Real e ZAP imóveis, a gente tinha várias suposições, dúvidas e algumas poucas certezas. De todas as suposições que criamos , saíram algumas hipóteses que geraram várias descobertas e uma definição de qual era a melhor forma de lidar com os endereços dos anúncios. O resultado final foi conseguir entender o quê era um bom endereço, e como isso impactava a vida de nosso cliente.”
– Diego Poblete, Product Manager @ PicPay
“Pra mim um bom trabalho inicial, mais especificamente por meio de uma opportunity assessment, impacta muito o restante do processo. Um exemplo disto foi quando o CEO priorizou a redução do CAC como métrica. Depois de horas em cima de funis e queries no banco de dados, descobri que havia dezenas de coisas que poderiam ser melhoradas. Conversando com stakeholders, também surgiram muitas sugestões que se embasavam em conhecimentos intrínsecos e aspectos qualitativos. Juntei então o pessoal como o objetivo de mostrar quantitativamente onde haviam oportunidades relevantes para que juntos pudéssemos escolher uma oportunidade específica com maior potencial.
Como analisamos a oportunidade que mais teria impacto através de uma avaliação de oportunidade, tivemos um resultado ótimo de ativação e que contribuiu para a redução do CAC.”
– Daniel Salengue, Product Manager @ Umbler
“Para desenvolvermos a solução de extrato da Conta PJ falamos com inúmeros clientes para aprender mais sobre os Jobs-to-be-Done relacionados a essa feature. Com isso descobrimos que os dois principais jobs dos nossos clientes eram:
No caso do extrato, devido a esse grande e importante Job to be Done de contabilidade, a partir das entrevistas com clientes, decidimos que era importante conversar também com contadores, o que tornou nosso desenvolvimento de produto muito mais assertivo para essa tipo de atividade!”
– Rawley L S Martos, Product Manager @ Nubank
Quer aprender a fazer as entrevistas de Jobs-to-be-Done? Faça que nem o Rawley e se inscreva no curso Jobs-to-be-Done na Prática:
“No meu caso, estamos focados em fazer o redesign de algumas telas do aplicativo do Nubank para atender algumas demandas do negócio. Nesse cenário o que funcionou muito bem foi rodar um processo bem estruturado de Design Thinking.
Basicamente começamos esse processo levantando muita informação sobre as demandas do business, dores dos clientes, tendências do mercado, etc. A partir disso convergimos em algumas soluções, validamos com pesquisa, iteramos novamente e rodamos mais pesquisa com usuários.
Ainda não implementamos completamente as nossas soluções, mas acredito que já tivemos bons resultados porque conseguimos o alinhamento da empresa sobre a solução proposta e os testes com usuários tiveram resultados bem positivos.”
– Caio Flores, Product Manager @ Nubank
E você? Qual a ferramenta ou framework de discovery que você se vê usando com mais frequência?