Implementar um processo de Product Discovery em uma empresa pode apresentar vários desafios, principalmente pela gama de possibilidades que podem ser exploradas. Neste momento, é muito comum surgir a dúvida: por onde começar?

Neste artigo trago a minha resposta a esta pergunta. Explico os caminhos que acredito que são mais eficientes e trazem mais resultados de acordo com a minha experiência dentro da área de Produto e liderança de projetos.

Product Discovery

Por que fazer Product Discovery?

O principal objetivo do Product Discovery é reduzir riscos. No livro “Inspired” de Marty Cagan, uma referência na área de Produto, são citados 4 principais tipos de riscos que precisam ser mitigados na etapa de Discovery. São eles:

• Risco de valor, que avalia se a solução tem valor e será comprada pelo usuário final;

• Risco de usabilidade, referente ao quanto a solução é fácil de ser usada;

• Risco de Execução, que avalia a capacidade técnica da equipe implementar a solução;

• Risco de Viabilidade, que avalia se a solução está alinhada com o momento do negócio.

Qualquer negócio que tenha parte de sua operação funcionando de maneira digital precisa estar atento a mitigação destes riscos para que a implementação final não custe mais caro do que o esperado.

Sabe-se que a maior parte dos problemas encontrados em softwares existem por falhas nas etapas de Especificação e Design (ou seja, durante o Discovery).

Apesar de parecer que “pular” fases do Discovery pode trazer eficiência e agilidade na implementação, com o passar do tempo os custos para correção de bugs se tornam muito maiores.

Por isso, a etapa de Discovery é o momento para estressar ao máximo o problema e a solução final, para que sejam evitadas alterações futuras.

O que é Product Discovery

Basicamente é o criar soluções a partir de problemas e necessidades dos usuários. Na prática, o processo de Discovery trabalha em dois “espaços” diferentes: o do Problema e o da Solução.

Tudo se inicia entendendo qual o seu problema, por meio de muita pesquisa e investigação. Este é o momento de empatizar com o usuário, fazer entrevistas e mapear qual são as dores e necessidades do seu público alvo.

Vale ressaltar que o ideal para conduzir um Discovery efetivo é dedicar de 50% a 60% do tempo no “Problem Space” - realizando pesquisas e alinhamentos. Isso por que é deste modo que conseguimos entender a fundo qual os reais problemas e oportunidades do negócio para criar as soluções corretas.

Construir produtos digitais de sucesso requer duas coisas: construir o produto certo e construir o produto da maneira correta. O Discovery existe para resolvermos a primeira delas.

3 conceitos chave para implementação do Discovery

1. Entregue um Design acima da média

Design é sobre resolver problemas, não sobre implementar soluções. Como já dito acima, um dos principais pontos para a boa condução do Processo de Discovery é empatizar com usuário e entender com clareza quais são os reais problemas dele (não os seus ou de outras pessoas do negócio).

Ressaltando a importância do design, um estudo sobre a interação de usuários com sites e apps mostrou que o usuário leva frações de segundos para definir se vai ou não se engajar com o site ou app que está acessando, e que mais de 50% das pessoas deixam o site em menos de 3 segundos. Além disso:

• 94% das impressões que temos de sites são relacionadas a design;

• 75% das pessoas julgam a credibilidade de sites baseados na sua estética;

• 88% dos usuários são menos prováveis de retornar ao site após ter uma pior experiência.

Construa sua Toolbox de Design

Como já falado, existem 2 estágios no Product Discovery:

1. Identificar o problema ou oportunidade (também conhecido como o output do trabalho no ”problem space”);

2. Identificar a solução mais promissora (também conhecido como o output do trabalho no ”solution space”).

Para entregar um design acima da média é essencial garantir a qualidade do processo, garantindo que para cada estágio seja aplicado os frameworks, ferramentas e conceitos ideais.

Existem frameworks que auxiliam tanto na identificação do problema quanto da solução, como é o caso do Design Thinking, Design Sprint e Lean Inception. Eles geralmente são conduzidas no modelo de workshop e precisam de um tempo maior de dedicação.

Porém, além dos já citados, temos também outras ferramentas, métodos e conceitos que permitem que podem ser aplicadas de maneira separada e mais rapidamente. Segue uma breve lista:

2. A solução deve ser construída a várias mãos

Product Discovery requer participação ativa de todo o time. Requer alinhamento, boa tomada de decisão e a mentalidade de Problem-Solving.

É claro que existem pessoas e funções que ficam responsáveis pela condução do processo, como a de PMs e Designers. O ponto é que eles não devem ser os únicos!

É bem comum que os times de engenharia e negócio se envolvam apenas em partes bem específicas do processo, não entendendo o todo do que está sendo construído. Esse é um erro cometido por muitas equipes.

Devemos lembra que o produto final é a intersecção do direcionamentos negócio, possibilidades da tecnologia e necessidades dos usuários.

Para garantir isso, é importante que PMs e Designers conduzam o processo de modo iterativo. Mas como fazer isso?

1. Dar updates de Discovery nas Dailys Isso dá ao discovery a atenção que ele merece, e não leva mais de 5 minutos por dia. Deste modo, toda a equipe fica por dentro do andamento e ainda permite que todos contribuam com a solução final.

2. Conduzir reuniões semanais de Discovery Essas reuniões devem conter pelo menos um representante do time de Tech e um representante do time de Negócios. O principal objetivos são colocar todos na mesma página, tirar dúvidas e tomar decisões em conjunto!

3. Teste a solução com seus usuários

Mais uma vez, é hora de envolver os usuários no processo. Não basta entender quais os seus problemas: é essencial também testar o sucesso da solução e mitigar o risco de usabilidade.

Daniel Kahneman, autor do Livro “Rápido e Devagar - Duas Formas de Pensar”, é muito conhecido por seu trabalho sobre finanças comportamentais e vieses cognitivos. Segundo ele, os vieses são formas e caminhos que nosso cérebro cria para aperfeiçoar a tomada de decisão, visando economia de esforço e agilidade de resposta.

O que podemos aprender com isso? Que muitas vezes o que pode parecer óbvio para quem esteve envolvido em todo o processo de Discovery não é tão óbvio para quem não esteve (os usuários!). É bem comum conduzir um teste de usabilidade e descobrir que no geral as pessoas tem uma percepção bem diferente da sua sobre a ação por trás de um botão, por exemplo.

A condução constante de testes garante que estaremos focando o processo de Discovery em User Researchs, e não em opiniões pessoais. Como já vimos, isso reduz riscos ao:

• Remover vieses pessoais das soluções criadas;

• Encontrar problemas antes da implementação, momentos em que eles são menos custosos.

 

Existem diversos tipos de testes e pesquisas que podem ser aplicados para validar a solução que foi criada. É possível conduzir pesquisas quantitativas e qualitativas, teste A/B, Focus Group, entre outros.

Porém a ideia aqui é entrar no detalhe dos testes que fornecem um feedback direto sobre a qualidade da interface e solução que estamos criando, como os testes de usabilidade (moderados ou não moderados).

Estes testes são feitos com protótipos que representam a interface de maneira real, e nos permitem entender como o usuário se comportam perante nosso produto. Eles nos trazem insights muito relevantes sobre a usabilidade e sobre como podemos melhorar a arquitetura da informação, os textos, mensagens de erro e fluxos de navegação.

Jacob Nielsen, em um dos seus estudos, criou a regra dos 5. Essa regra diz que realizar o teste com 5 usuários garante que serão encontrados 80% dos problemas.

A tabela abaixo mostra a porcentagem de erros encontrados de acordo com o número de participantes em testes de usabilidade.

Concluindo

É claro que o universo de Product Discovery tem inúmeras outras áreas e técnicas para serem exploradas, como por exemplo a utilização de dados para pautar a tomada de decisão.

Porém, enxergo que a implementação deste processo vai envolver muita tentativa e erro para gerar aprendizado real. Por isso, vejo que deve-se começar pelo básico, que é a espinha dorsal do Discovery: o foco em resolver problemas dos usuários de maneira alinhada ao negócio.

Após isso, as possibilidades de evolução são muitas (e muito valiosas!) para trazer mais qualidade e profissionalismo ao processo de Discovery.