Como criar um processo de Discovery para o seu time de produto

Notei nas últimas semanas uma crescente busca por ferramentas e processos para se fazer um discovery de produto. E acho que, por ser algo que as empresas não costumam dispor muito tempo e esforço, esse tema acaba gerando um pouco de misticismo. Não quero dizer que fazer um discovery é fácil, mas também não é algo que vai exigir que você compre um curso online ou vá para um workshop.

Pelas experiências que tive, discovery é sobre definir qual problema você quer resolver e se apaixonar por este problema, e não pelas criativas possíveis soluções para ele. Digo isso porque é muito comum, e talvez a maior fonte de erros no caminho para o sucesso de um produto, que diversos stakeholders, inclusive o próprio PM, tentem fornecer soluções para o problema. Soluções existem, e podem ser diversas, mas o sucesso será melhor alcançado se a empresa tiver o melhor retorno sobre o investimento possível. Se um problema pode ser 100% resolvido com uma solução que custa 3 anos do time e 80% com uma solução que custa 1 mês, é provável que valha a pena buscar a solução mais barata primeiro e depois a mais cara, se for preciso.

Esse exemplo é bastante simplista, mas meu objetivo com ela é colocar a hipótese que existem várias soluções para um problema, e elas tem resultados e custos diversos. O resultado de um bom discovery é tentar encontrar e mapear os riscos e ganhos de algumas destas soluções.

Um ponto importante do discovery é que ele custa tanto tempo quanto se queira, pois a busca e o entendimento das diversas soluções pode durar para sempre, e isso provavelmente iria levar a empresa à falência. Por isso, é necessário estabelecer um limite de tempo para se dedicar à ele, ou, melhor ainda, dividir ele em etapas ao longo do desenvolvimento do produto.

Outro ponto importante é que se o discovery se trata da criação de um novo produto, é interessante fazer algum tipo de alinhamento entre os stakeholders para entender melhor o problema que se quer resolver. Minha sugestão é no início do projeto fazer uma matriz CSD, uma matriz É, Não é, Faz, não faz. Depois de ter esse conhecimento construído com o time, é necessário definir o Objetivo do time - que é uma frase para que todos entendem qual problema o time está se propondo a resolver, e de preferência algo que motive o time - e também as métricas, que irão indicar o quão perto o time está de atingir o sucesso. Exemplo de objetivo: Fazer o site Xyz ser reconhecido como o maior portal de conteúdo sobre vinhos do Brasil. Exemplo de métricas: posição no ranking de sites de vinho do Brasil (ser número 1 é a meta), taxa de retorno ao site e tempo de sessão.

Com os objetivos e métricas em mão, é hora de investigar. Um primeiro passo interessante é tentar transformar as dúvidas da matriz CSD em suposições e as suposições em certezas, pois já será possível entender mais sobre o problema. Paralelamente, pode-se levantar riscos associados em diversas áreas:

• Riscos do negócio

• Os clientes têm algum interesse que esse problema seja resolvido?

• Existe alguma regulamentação governamental envolvendo esse problema?

• O volume de pessoas ou do mercado impacto por este problema é relevante para o contexto da empresa?

• Alguma outra coisa impede que alguma solução para este problema possa ser lançada no mercado?

• Riscos de experiência

• Os usuários vão conseguir usar cada uma das soluções propostas para o problema?

• Como o usuário enxerga esse problema na vida dele?

• Riscos técnicos

• Existe algum impedimento ou problema técnico relacionado à este problema?

• Dadas as soluções que forem propostas, existe algum risco associado?

• Qual seria a estimativa de custo associado a cada solução?

Para os diversos riscos levantados deve-se investir mais sobre eles e tentar mitigá-los, para que eles não impactem o projeto, ou pelo menos o time consiga lidar com os impactos gerados e os administre.

Conforme o conhecimento sobre o problema vai se difundindo pela equipe é comum que as soluções vão surgindo, e é preciso discutir e fazer novas iterações sobre elas. Quanto à isso não há receita, é a discussão ativa do time e a paixão sobre o problema, com iterações de investigação e mitigação de riscos que irá fazer as soluções se concretizarem.

Após as discussões e lapidação das ideias é hora de definir um roadmap inicial, que deve ser feito de forma desapaixonada, pois novas iterações (como a própria construção de um MVP) poderá interferir no roadmap, isso é normal. Recomendo que se faça um roadmap para pelo menos 6 meses, mas não mais do que 1 ano.

Acredito que com as discussões feitas num processo de discovery como este que eu sugeri, o time já será capaz de entender melhor “o quê” deve ser feito, pelo menos inicialmente, para se começar a resolver o problema proposto. Conforme os primeiros resultados chegarem, a partir das métricas e do feedback do usuário, faça novas análises de risco e redefina as suas soluções e seu roadmap. Com esse ciclo iterativo você irá corrigir a rota e buscar soluções cada vez mais otimizadas para o problema que você está resolvendo

.