J OliveiraComo 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
.