Product Discovery 101 — Princípios Fundamentais
O desenvolvimento de produtos possui duas grandes fases, o Discovery e o Delivery, cada uma com seus objetivos, ferramentas e resultado esperado.
Acredito que a etapa do delivery esteja bem clara para a maioria dos times de produto, com toda a metodologia ágil e de continuous delivery. Porém, a etapa de discovery é a que, muitas das vezes, é a menos falada — mas, a mais importante — etapa no desenvolvimento de um produto, é nela que decidimos o que construir, entendemos o porque estamos construindo e qual o impacto que pode causar, tanto para o usuário quanto para o negócio.
Em poucas palavras, essas duas etapas se diferem:
Discovery
Decidir o que construir
O objetivo é aprender rápido
Delivery
Construir
O objetivo é construir rápido
Essa imagem — que está num artigo do SVPG — mostra bem o que precisamos validar em cada etapa e, principalmente, mostra a importância do discovery para entregarmos a coisa certa para o delivery — e para nossos usuários. Fora que, essa desconstrução do que é um MVP é certeira pelo Marty Cagan, pois ela mostra que a cada protótipo do discovery temos um MVP — que para o Cagan é minimum viable prototype — e usamos ele para validar algumas hipóteses e reduzirmos os riscos de produto.
Quando passamos para o delivery, estamos entregando um produto final de maneira contínua (continuous delivery).
A maioria dos times de produtos tem uma noção muito melhor de como realizar o segundo objetivo de entregar produto sólido do que como realizar o primeiro objetivo de experimentação e descoberta rápidas.
Para esses times, há dois desafios muito significativos a serem enfrentados:
1 - Descobrir em detalhes qual é a solução que o cliente precisa. Isso inclui tudo, desde garantir que haja clientes suficientes que precisam dessa solução (demanda) e, em seguida, criar uma solução que funcione para esses clientes e para o negócio.
Ainda mais difícil, precisamos garantir uma solução única que funcione para muitos clientes. Para fazer isso, precisamos ser capazes de testar muitas ideias e precisamos fazer isso de forma rápida e barata.
2 - Precisamos garantir que entregamos um produto robusto e escalável do qual nossos clientes possam confiar que entregue valor de maneira constante.
É preciso aprender rápido, mas também lançar esse produto com confiança do valor que está sendo entregue.
Estamos sempre com muita pressa para lançar algo para aprender o que funciona e o que não funciona. No entanto, não queremos lançar algo que não esteja pronto e que arrisque prejudicar nossos clientes e nossa marca.
Fazer todo esse trabalho quando o product manager não tem certeza de que essa é a solução que o cliente deseja ou precisa é uma receita para falhas no produto e grandes desperdícios. Portanto, o objetivo do discovery é garantir que tenhamos evidências de que, o product backlog que vai para o delivery é de fato o que precisamos construir e o esforço do time de desenvolvimento não será desperdiçado. E é para atingirmos esse objetivo temos muitas técnicas diferentes no discovery.
Temos técnicas para obter uma compreensão muito mais profunda dos usuários e clientes e para validar as ideias que temos, tanto qualitativa quanto quantitativamente — a parte de técnicas da um artigo aparte.
Em resumo, para termos um discovery eficaz é importante sempre estarmos próximo dos clientes sem tentar levar experimentos rápidos para à produção. Se você deseja fazer um ótimo product discovery é realmente essencial que você leve suas ideias diante de usuários e clientes reais, com antecedência e frequência — foco na frequência!
Product Discovery Principles
O objetivo do discovery é abordar os quatro riscos de produto — para mitigá-los, que são:
- O cliente vai comprar ou escolher usá-lo? (Risco de valor)
- O usuário consegue usá-lo com facilidade? (Risco de usabilidade)
- Podemos construí-lo? (Risco de viabilidade)
- Esta solução funciona para os nossos negócios? (Risco de negócio)
E não basta que seja apenas a opinião do time de produto sobre essas questões, nós precisamos coletar evidências! Porém, é importante saber a hora que o conhecimento que temos sobre algo já basta como evidência para evitarmos validações ou aprofundamentos desnecessário que acabam diminuindo a eficiência do discovery.
Quando se trata de como fazemos o discovery, há um conjunto de princípios básicos que orientam como podemos trabalhar nessa fase. Se você entender esses princípios, entenderá não apenas como fazer o discovery bem hoje, mas também como incorporar facilmente novas técnicas à medida que elas forem surgindo — e o que mais acontece é o surgimento de novas técnicas, e é importante saber utilizá-las e principalmente entender qual é o resultado esperado delas.
Esses são os dez princípios do product discovery listados pelo Marty Cagan em seu livro Inspired — que recomendo a todos que querem trabalhar com desenvolvimento de produtos, ele é o guru nessa área.
1. Não podemos contar com nossos clientes (ou executivos ou stakeholders) para nos dizer o que construir.
Os clientes não sabem o que é possível e, pensando nas tecnologias que temos envolvidas nos produtos modernos, nenhum de nós sabe o que realmente quer ou é possível até que realmente o veja materializado.
Isso não quer dizer que os clientes ou nossos executivos estejam errados; é que é nosso dever, como time de produto, garantir que a solução que fornecemos resolva algum problema.
Este é provavelmente o princípio mais fundamental em todos os produtos modernos.
2. O mais importante é estabelecer um valor atrativo.
Quando falamos em desenvolvimento de produto, nada é fácil, mas a parte mais difícil de todas é criar o valor necessário para que os clientes escolham comprar ou usar seu produto. É possível sobreviver por um tempo com problemas de usabilidade ou desempenho, mas sem entregar o valor principal, realmente não temos nada.
Já deu pra perceber que é aqui que precisamos gastar a maior parte do tempo de discovery, né?
3. Por mais difícil e importante que seja a engenharia, criar uma boa experiência do usuário geralmente é ainda mais difícil e mais crítico para o sucesso.
Embora toda equipe de produto tenha engenheiros, nem toda equipe possui as habilidades necessárias para o design do produto — desde UI a UX, e mesmo quando temos essas habilidades no time, elas estão sendo usadas da maneira correta? Estamos tirando o maior proveito dessas habilidades no processo?
4. Funcionalidade, design e tecnologia estão totalmente interligados.
No modelo waterfall, o mercado impulsiona a funcionalidade (também conhecida como requisitos), que impulsiona o design, que impulsiona a implementação.
Hoje, com os modelos ágeis, sabemos que a tecnologia impulsiona (e habilita) a funcionalidade tanto quanto ao contrário. Sabemos que a tecnologia impulsiona (e possibilita) o design. Sabemos que o design impulsiona (e habilita) a funcionalidade.
O ponto é que todos esses três estão completamente interligados. Esse é o maior motivo para nos esforçarmos para que o product manager, o product designer e o tech lead se sentem fisicamente perto um ao outro.
5. Espera-se que muitas das ideias não funcionem, e as que funcionarem, exigirão várias iterações.
Não podemos saber com antecedência quais de nossas ideias funcionarão com os clientes e quais não. Portanto, abordamos o discovery com a mentalidade de que muitas, se não a maioria, de nossas ideias não darão certo. O motivo mais comum para isso é o valor — como já foi citado no item 2, mas às vezes o design é muito complicado, às vezes irá levar muito tempo para ser construído e, às vezes, acabam sendo problemas legais ou de privacidade. O ponto é que precisamos estar abertos para resolver o problema de diferentes maneiras.
6. Devemos validar nossas ideias com usuários e clientes reais.
Uma das armadilhas mais comuns em produtos é acreditar que podemos antecipar a resposta real de nossos clientes ao nossos produtos. Podemos basear isso em pesquisas reais com clientes ou em nossas próprias experiências, mas, em qualquer caso, sabemos hoje que devemos validar nossas ideias com usuários e clientes reais. Precisamos fazer isso antes de gastar tempo e dinheiro para construir um produto final, e não depois.
7. Nosso objetivo no discovery é validar nossas ideias da maneira mais rápida e barata possível.
O discovery é sobre a necessidade por velocidade. Isso nos permite experimentar muitas ideias e, para as promissoras, experimentar diferentes abordagens. Existem muitos tipos diferentes de ideias, muitos tipos diferentes de produtos e uma variedade de riscos diferentes que precisamos abordar (risco de valor, risco de usabilidade, risco de viabilidade e risco de negócio). Portanto, temos diversas técnicas, cada uma adequada a essas situações.
8. Precisamos validar a viabilidade de nossas ideias durante o discovery, não depois.
Se a primeira vez que os desenvolvedores entrarem em contato com alguma ideia for no planejamento da sprint, você falhou. É preciso garantir a viabilidade antes de decidirmos construir, não depois. Isso não apenas economiza muito tempo, mas obter a perspectiva do time desenvolvimento o mais cedo possível também tende a melhorar a solução — de acordo com Cagan, os engenheiros são a maior fonte de inovação no produto — e é fundamental para o aprendizado compartilhado.
9. Precisamos validar a viabilidade de negócio de nossas ideais durante o discovery, não depois.
Da mesma forma, é absolutamente essencial garantir que a solução que construímos atenda às necessidades do negócios — antes de dedicar tempo e dinheiro para construir esse produto. A viabilidade de negócio inclui considerações financeiras, marketing (considerações de marca e entrada no mercado), vendas, jurídico, desenvolvimento de negócios e executivos.
10. É sobre aprendizado compartilhado.
Uma das chaves para ter uma equipe de missionários e não uma equipe de mercenários é que a equipe aprende junto. Eles entendem a dor do cliente, viram juntos algumas ideias fracassarem e outras funcionarem, e todos entendem o contexto do porquê esse produto é importante e o que precisa ser feito.
Takeaways
Sabendo desses princípios fundamentais o time de produto está apto para conseguir tirar melhor proveito do discovery, lembrando que tudo isso é mais questão de mudança de mindset do que aprender uma hard skill, por exemplo.
Coloque em prática cada princípio, lembre-se em cada ação ou decisão que for tomar se você está levando em conta o que foi falado aqui e principalmente, se cada ferramenta ou técnica nova que você queira usar está de acordo com os princípios.
Acha que ficou faltando algum princípio? Conta ai pra gente :)
Quer aprender mais sobre Product Management? Recomendo o livro Inspired do Marty Cagan
Recomendo a leitura do artigo UX Research 101 do Mauro Tavares, ele traz um conteúdo legal sobre UX Research, que é super importante nessa etapa de discovery.
Siga-nos no Instagram: @bzzprdct
Referências:
Cagan, M. (2018). INSPIRED: How to Create Tech Products Customers Love. 2nd ed. Wiley.
“An Introduction to Modern Product Discovery” by Teresa Torres
“An Introduction to Modern Product Discovery” by Teresa Torres | Productized Blog
