Os 10 princípios do Product Discovery
Em um ambiente Ágil falamos bastante em dar eficiência ao processo de desenvolvimento de produtos. Falamos em métodos, cerimônias, ferramentas e práticas. Neste artigo eu não quero falar de eficiência. Eu quero falar de eficácia.
Falar em eficácia é falar em “fazer as coisas certas”. É falar em explorar dados, encontrar oportunidades, gerar hipóteses. É falar em idear soluções e decidir quais estão aptas a irem para desenvolvimento e quais requerem mais validação. Falar em eficácia é falar sobre Product Discovery.
Você já ouviu falar sobre Product Discovery? 🧐
Product Discovery é uma jornada de aprendizado contínuo sobre a nossa usuária. Esse aprendizado nos permite elaborar soluções mais eficazes para os seus problemas. (FERMANN, Roberto. Hoje, agora mesmo)
Na prática, times de Produto costumam ter um fluxo de Continuous Discovery que faz com que eles aumentem a certeza sobre a solução para um determinado problema antes de investir no desenvolvimento final. Esses times estão em constante aprendizado, em constante "modo de experimentação". E à medida que vão aprendendo e validando suas hipóteses vão "alimentando" o fluxo de Continuous Delivery.
Manter essas duas tracks acontecendo de forma simultânea, ambas com participação do time, é um grande desafio. A isso chamamos Dual Track Agile. O grande benefício de trabalhar desta forma é equilibrar o aprendizado sobre a usuária com o time-to-market que a empresa precisa.
Mas vamos falar mais sobre Product Discovery 👅
Um fluxo simples de Product Discovery poderia ser assim:
Etapa 01: Entendimento (Research & Opportunities)
Nesta etapa vamos coletar Inputs de todas as partes interessadas, vamos avaliar os Outputs do produto atual caso exista (ex: dados da Analytics) e vamos entender muito bem os resultados esperados — os Desired Outcomes. Vamos montar um mapa de oportunidades, entender cada uma delas e selecionar as principais apostas. Vale lembrar que fazer produto é fazer trade-offs: se priorizamos a iniciativa X, despriorizamos a iniciativa Y por falta de capacidade— e a iniciativa Y poderia ser até mais potente do que a X. Portanto, essa etapa de entendimento é muito estratégica e pode determinar nosso sucesso ou fracasso.
Etapa 02: Ideação
Idear é um processo de divergir e convergir na busca de soluções. Para isso é importante analisar a concorrência, olhar para o mercado, estabelecer premissas, criar hipóteses. E debater soluções potentes. É hora de criar e abusar dos recursos e ferramentas disponíveis para isso. Aqui vale trabalhar com Personas, Jornada de Usuária, Service Blueprint, Jobs to Be Done. Aqui vale fazer Brainstormings, Value Proposition Canvas, Product Canvas, Elevator Pitch, enfim, o objetivo é conseguir dar vida às melhores ideias.
Etapa 03: Prototipação
As nossas ideias são boas antes de serem testadas? Acredito que não. Antes de serem testadas são só ideias. Portanto precisamos validar com usuárias nossas ideias para ganhar confiança de leva-las a desenvolvimento. A prototipação pode ser feita de diferentes formas e existem ferramentas que nos ajudam bastante a criar protótipos baratos, navegáveis e bem realistas. Eu já trabalhei com o InVision, com o Marvel e com o Zeplin. São ferramentas bem legais para o contexto digital.
Etapa 04: Validação
É a hora da verdade. Aqui o importante é o aprendizado. Observar e escutar usuárias reais interagindo com os nossos protótipos é sensacional. É a melhor forma de aprender e entender como nosso produto vai se comportar antes mesmo dele existir.
Esse processo, sendo contínuo, requer iterações. Através delas vamos ganhar confiança sobre nossa solução.
Nota importante: Discovery não é um processo apenas de Design! No fim das contas, queremos uma solução Usável, Valiosa, Factível e Viável. Por isso precisamos do envolvimento de pessoas de Negócio, de Design e de Engenharia.
Eu quero defender mais o Product Discovery antes de contar os 10 princípios! 😎
Recentemente eu participei de um curso ministrado por um Product Manager muito experiente, chamado Bernard De Luna. Ele apresentou um dado de uma pesquisa que dizia que 64% das funcionalidades que desenvolvemos nunca ou quase nunca são usadas pelas pessoas usuárias.
SES-SEN-TA-E-QUA-TRO-POR-CENTO!
É muito trabalho sem valor e sem utilidade! É muito desperdício!
O Marty Cagan defende a descoberta como base para o sucesso. Ele fala sobre a importância de validar nossas ideias antes de desenvolver o produto, pois fazer mudanças depois de tê-lo criado é muito mais custoso. Outro guru, Roman Pichler, também defende o Discovery como uma forma de determinar se e por que um produto deve ser desenvolvido.
A grande mensagem aqui é que não estamos falando sobre usabilidade, não estamos falando sobre funcionalidades, não é sobre isso. Estamos falando algo que interessa muito para o negócio: Product Discovery é sobre Redução de Riscos.
Sem Discovery a gente corre muito risco! Sem Discovery a gente não tem evidências que sustentem nossas hipóteses. A gente tá indo pro tudo ou nada, arriscando fazer mais uma funcionalidade que vai somar àqueles 64% de inutilidades sem valor. Sem Discovery estamos nos arriscando a criar algo que não é viável para o negócio, ou que não é factível em um prazo aceitável. Ou pior ainda: algo sem valor para a usuária.
Os 10 princípios do Product Discovery 👊
Se você acredita que podemos nos beneficiar de uma jornada de aprendizado e descoberta, você precisa conhecer os 10 princípios básicos de Product Discovery para não escorregar. Lá vai:
- Não podemos contar com nossos clientes para nos dizer o que construir, por que eles simplesmente não sabem. Se dizemos sim para tudo o que os clientes pedem, nosso produto vira um verdadeiro Frankenstein!
- O mais importante é criar valor para a usuária. É gerando valor para a usuária que vamos conseguir gerar resultados para a nossa empresa. Sem uma boa proposta de valor, sem solucionar uma dor, sem gerar um benefício explícito para a usuária, não rola.
- Desenvolvimento de software é difícil, importante e crítico. Mas criar uma boa experiência para a usuária é ainda mais crítico para o sucesso do produto. A verdade é que a complexidade técnica precisa ficar do nosso lado. Essa complexidade não é valorizada pela usuária. Um produto com uma bela arquitetura e com a melhor tech-stack não vale de nada se a experiência de uso for repleta de fricção.
- Funcionalidade, Design e Tecnologia estão totalmente interligadas. Uma solução final precisa ser construída por várias mãos e com distintos pontos de vista. Não podemos trabalhar apenas orientadas ao negócio, ou ao desenho, ou às limitações técnicas. Precisamos considerar tudo isso ao mesmo tempo quando vamos construir um produto. Não há mais espaço para silos!
- Muitas ideias não funcionarão e as que funcionarem exigirão várias e várias iterações. Não adianta acreditar que vamos encontrar uma bala de prata. A solução vem do aprendizado, que vem da jornada de descoberta. É necessário iterar frequente e rapidamente. É necessário gerar o máximo de ideias, prioriza-las e testa-las. Bastante.
- Valide as suas ideias com clientes reais. Não, você não é um cliente real. Os seus colegas não são clientes reais. O cliente real está fora do prédio. Você pode encontrá-lo na rua, na sua base nossa base ou procurando por um perfil que se encaixe na sua descrição de público-alvo.
- Valide as suas ideias de maneira mais rápida e barata possível. Gente, isso é sério. Validar é justo para não ter que desenvolver. Se a precisamos desenvolver 80% do código para testar, escolhemos o formato de teste errado. Aqui vale ser criativo!
- Use técnicas quantitativas e qualitativas no seu processo de validação. As técnicas quantitativas nos ajudarão a entender o que está acontecendo, enquanto as técnicas qualitativas nos ajudam a entender o motivo. Saber o O QUE e o POR QUE será a base da nossa descoberta.
- Valide suas ideias, tanto do ponto de vista de negócio quanto técnico, durante o Discovery — e não depois. Envolver desenvolvedoras é necessário NESSA etapa, não depois quando já estiver tudo definido. Pivotar uma ideia em Delivery é bem mais caro do que pivotar em Discovery.
- É tudo sobre aprendizado compartilhado. Trabalhar junto, conversar, debater ideias no papel, rabiscar junto … isso gera uma bagagem gigantesca de entendimento por trás de cada ideia. Esse acúmulo de experiência e aprendizado gera inteligência para a nossa empresa.
Eu acredito muito no processo de Product Discovery e sonho com o dia em que não precisarei justificar a sua necessidade. Mais que tudo, eu entendo que Product Discovery é um mindset. E um mindset é algo que podemos ter dentro de nós mesmos.
A PM3 está lançando um curso focado em Product Discovery. Quem quiser aprender tudo sobre o assunto dá uma conferida no site deles: https://www.cursospm3.com.br/curso-de-product-discovery