Dicas valiosas sobre Product Discovery que nunca te contaram
Parte 1: Definição e Teoria
Trabalhando com desenvolvimento há pouco mais de seis anos, pude observar um padrão que acontece em todas as empresas e que já foi dito por Jeff Patton:
“Uma das tragédias no desenvolvimento de software e no desenvolvimento de todos os produtos é que muito do que construímos não oferece o resultado/benefício que esperávamos. Então, isso é um problema. “
Nesse cenário, observei alguns patterns:
1- Stakeholder herói
Com a sua varinha mágica de ideias super fantásticas. Quem nunca, não é mesmo? E com aquele poder de dar um super-power-top-down e cortar todo o planejamento de produto. E bem, não sei se existe um final feliz nessa história…
2- Quanto mais outputs (features) melhor!
Feature sendo desenvolvida igual pastel: “vê mais cinco, amigo!”. Esse perfil de stakeholder imagina que salvar a nação é criar mais e mais funcionalidades, independente se são ou não necessárias para o cliente final.
3- O importante é o delivery, depois discutimos o resultado
Durante o desenvolvimento surgem várias dúvidas relacionadas à entrega de valor do que está sendo construído, assim como a real necessidade do produto. E muitas vezes o importante mesmo é alcançar uma meta e uma data, entregar no tempo, mesmo que o que está sendo desenvolvido não tenha valor algum o usuário/cliente.
E isso é só um pouco do que acontece, entre muitos outros cenários… Mas acredito que, como todo produteiro desse mundão, pelo menos um deles você já vivenciou, né? (Ou os três ao mesmo tempo? :( )
Com essas situações um tanto caóticas, aprendi uma lição bem importante:
“A maneira mais cara de testar sua ideia é colocar em produção um software de qualidade que não entrega valor.”
Mas perae, então como testamos as nossas ideias antes de pôr em produção?
É para isso que serve a Descoberta de Produto, conhecido com Product Discovery na gringa. E pra começar um pouco sobre a teoria, segue a definição:
“Product Discovery é um processo para fazer com que o novo produto ou funcionalidade a ser lançado(a) seja não só usável (que seja fácil de usar e tenha uma boa experiência visual) mas principalmente útil para o cliente/usuário — que ele enxergue o valor e de fato o utilize.”
E o que caracteriza o processo como Discovery é descobrir e validar hipóteses dos usuários. Se não envolve o usuário, não é Discovery, é consenso, refinamento, ou o que você quiser chamar…
Para isso, é necessário que você envolva o cliente, entreviste, entenda o contexto, observe e os inclua de fato no processo de criação — afinal, é para ele que você quer mudar o mundo, certo?
E os pilares que você precisa sempre ter em mente na validação do produto são baseados na pergunta: oque quero desenvolver é:
- Valioso? Como medir?
- Utilizável? Quanto engajar?
- Viável (inclusive viável tecnicamente)? Quanto custa?
O processo de descoberta é dinâmico e permite que você falhe, mas rapidamente! E também se o que você tem em mãos são mais certezas que hipóteses, bem provável que não é necessário realizar um discovery para isso, não é mesmo? Então tenha em mente que esse processo te auxilia a criar produtos de qualidade e de valor e não provar que uma ideia é legal.
Tá, mas como funciona na prática esse tal de Product Discovery?
Eis que tentarei resumir pra você todo o processo. Só relembrando: Product Discovery é pra ajudar a construir produtos que façam sentido para o cliente/usuário, beleza?
Mas vamos lá: o que eu descobri iterando?
Usando o conceito de Design Thinking (thanks, IDEO!), eu gosto de trazer uma imagem que faz bastante sentido no processo de descoberta, que é chamado de Duplo Diamante. Mas, antes disso, quero mostrar as quatro palavrinhas mágicas:
- Descobrir: que hipóteses queremos validar?
- Definir: identificando o problema
- Elaborar: prototipando ideias
- Entregar: solução final
E como elas se encaixam no duplo diamante?
Para isso, existe o conceito de Divergir (criar alternativas — Descobrir e Elaborar) e Convergir (fazer escolhas — Definir e Entregar).
Na etapa de Discovery, o primeiro passo é colocar todo mundo na mesma página — o time e os stakeholders estão construindo o software com você, e é necessário garantir que todos tenham a clareza, o propósito e o entendimento do que vocês querem atingir. Lembrando:
“Toda a equipe é responsável pelos resultados do produto, não apenas pela entrega no prazo”.
E, como falei anteriormente, se existe consenso que não existem riscos atrelados ao que estão desenvolvendo, então não tem a necessidade de realizar um Discovery.
Mas e se o risco existir? Os clientes vão querer usar essa solução? E se tivermos o risco financeiro? Quanto tempo irá durar essa descoberta? E que riscos são esses?
De acordo com o Marty Cagan, o risco pode ser:
- De valor;
- De usabilidade;
- De viabilidade técnica;
- De negócio;
Para cada um existe um cenário importante a ser validado e descoberto. Por isso essa etapa é tão importante, principalmente no quesito mitigar riscos e aumentar a chance de sucesso do produto.
Bom, acredito que com essa pequena introdução, no próximo artigo, que sai semana que vem, você possa ter uma ideia mais Concrete (concreta, ops) do processo! (desculpa o trocadilho, rs)
E pra finalizar, segue uma frase que me inspira diariamente:
“Remember: at the end of the day, your job isn’t to get the requirements right — your job is to change the world.”
Jeff Patton ❤
Ficou alguma dúvida ou tem algo para colaborar? Deixe um comentário! Até a próxima ;)
—
Para ler a continuação desse artigo, leia aqui:
