Toda pessoa com a responsabilidade de gerenciar um produto depara-se frequentemente com muitas dúvidas e desejos bastante incômodos. Queremos ter certeza que estamos olhando para o lado certo, construindo e evoluindo o produto na direção que aumenta o valor entregue para os usuários. Queremos diminuir as chances de construir coisas inúteis ou não usáveis. Queremos diferenciar nosso produto dos demais concorrentes, criando vantagens únicas que os clientes desejam e pagam para ter. Queremos melhorar os resultados da empresa, atingindo as melhores oportunidades de negócio. Queremos muitas coisas.

Estamos tentando resolver problemas complexos, com muitas variáveis envolvidas que inviabiliza, encontrarmos respostas simples e definitivas. Para nos ajudar a navegar nesse mar de possibilidades e problemas, utilizamos o que chamamos de product discovery ou descoberta/discovery. Vamos compreender um pouco mais sobre o que é isso.

O que é Product Discovery?

O que entendemos por product discovery é um conjunto de atividades que executamos com a intenção de nos auxiliar a responder melhor aquelas e outras perguntas, e são necessárias para definir sobre onde, quando e se devemos evoluir nosso produto. São técnicas, frameworks e ferramentas que servem para descobrirmos sinais, indícios, evidências que nos auxiliem a tomar decisões, confrontar pressupostos e testar hipóteses.

Conforme apresentado pelo Marty Cagan no livro Inspired, o product discovery serve para reduzirmos quatro riscos:

• Risco de valor: o cliente irá comprar ou escolherá usar essa solução?
• Risco de usabilidade: o cliente entenderá como utilizar essa solução?
• Risco de execução: temos capacidade para construir essa solução?
• Risco de viabilidade: Essa solução funciona para nosso negócio?

Queremos coletar evidências, não opiniões, que nos ajudem a visualizar essas ameaças. Nosso objetivo final é lançar melhorias e produtos com confiança suficiente para não ser simples chutes, mas com velocidade suficiente para confrontarmos o que criamos com a realidade, o mais rápido possível.

Porém, infelizmente nem sempre nossa realidade é essa.

O que é costumeiro?

Há uma prática no mercado, e não quer dizer que está correta.

Em muitas empresas e cenários os gerentes de produto ficam responsáveis por definir o lançamento de produtos e melhorias (funcionalidades, novos módulos) baseados somente em pesquisas de mercado e nas visões de stakeholders de maior senioridade. É importante perceber que, mesmo com muito valor e importância nessas fontes de informação, elas respondem apenas parte das perguntas que assolam alguém que é responsável por definir a evolução de um produto.

Pesquisas de mercado são ótimas para guiar quanto a quais oportunidades de negócio parecem mais interessantes de serem exploradas, enquanto os insights e indicações de stakeholders com mais experiência são boas fontes para auxiliar no entendimento do mercado e possivelmente onde começar a olhar.

Mesmo endereçando bem os problemas de viabilidade, os demais questionamentos não são enfrentados (pelo menos não com muito afinco) nessas abordagens. Com isso ficamos perdidos, aceitando muitas suposições como verdade. Aceitamos muitos riscos para o negócio por simplesmente não pensar nas demais dimensões do problema e aceitar que a oportunidade de mercado é um indício suficiente para consumir recursos para colocar o produto ou funcionalidade em pé.

Mudar pode não ser simples, mas há alguns caminhos para iniciar.

Fundamentos para um bom Product Discovery

Para enfrentarmos essa situação e iniciar bem no product discovery, dois movimentos são importantes: conversar com os usuários e envolver mais pessoas.

Primeiro, converse com seus usuários. Fale com eles com frequência, com diferentes perfis deles; busque entender seus contextos, suas necessidades, dores e alegrias com o produto, entenda qual(is) necessidade(s) sua solução supre.

Mesmo que tenha recursos de analytics e dados de pesquisas fornecidos por outras áreas da sua empresa, não abra mão de contato direto e contínuo com seus clientes e usuários. É desse modo que geramos uma empatia mais profunda com as pessoas que usam e contratam nosso produto.

O segundo movimento é envolver mais pessoas na descoberta. Os primeiros candidatos são os product designers e os engenheiros. Além de ser de grande valor para esses eles entenderem mais sobre os usuários e suas motivações, esses profissionais são capacitados para responder com qualidade aos riscos de usabilidade e de execução.

Conte com eles para construir mockups e protótipos, para fazer testes com tecnologias, para delinear como podemos construir. E também tenha eles próximos para conversar com clientes e usuários e trazer mais insights para além dos seus.

Envolva os stakeholders apresentando as evidências encontradas e os resultados dos experimentos. Mostre que as ideias e sugestões que foram dadas estão servindo para apoiar o processo de descoberta. Faça com que eles se interessem sobre as ferramentas/técnicas ao ver valor no que você está puxando.

Um pequeno passo a passo para começar

Com os fundamentos em mente, trouxemos também um pequeno guia inicial para ficar mais fácil para você fazer seus primeiros product discoveries:

1. Tenha algum problema ou oportunidade em mãos: para começar, é importante você ter alguma dúvida/problema para iniciar suas primeiras descobertas. Pode ser uma ideia dada por um stakeholder, uma situação relatada por um cliente ou mesmo alguma impressão/sugestão do time.
2. Foque primeiro no valor: muitas vezes, quando estamos embrenhados no dia-a-dia do nosso produto, tomamos o valor como óbvio. Entretanto, precisamos questionar o valor de cada modificação que fazemos no nosso produto, do valor do nosso produto em relação ao mercado (que também está se modificando), aos concorrentes, às mudanças de comportamento dos nossos clientes e usuários. Tente começar suas primeiras descobertas tentando reduzir o risco de entregar alguma coisa que não seja valoroso para o seu público.
3. Tente mapear quais as suposições precisam ser testadas: converse com as pessoas envolvidas no problema/oportunidade e tente mapear quais as principais suposições que deveriam sustentar ou construir uma solução para isso. Busque entender quais os motivos e crenças que levam as pessoas a acreditarem no sucesso dessa solução ou ideia ou na importância desse problema ser resolvido.

De forma genérica, as mais frequentes que temos geralmente são:

• Esse problema existe para o usuário?
• Se sim, como ele soluciona hoje?
• As soluções atuais são satisfatórias?
• É um problema incômodo o suficiente para ele buscar uma solução para além das atuais?
• Estaria disposto a pagar (mais) por isso?
• Como ele sabe que o problema foi resolvido?
• Como ele avalia o resultado para dizer que está como deseja?
• Quem mais tem esse problema?

Tente entender quais perguntas cabem e deveriam ser utilizadas para deixar mais claro o cenário.

1. Monte um experimento! Parece algo difícil, mas o que precisamos é pensar em como testar uma suposição. Há uma série de recursos que você pode utilizar para isso, desde ferramentas de pesquisa, até a estruturação de MVPs. Lembrando que nosso intuito é gerar sinais que nos ajudem a chegar a conclusões melhores e com menos risco, não atingir a certeza absoluta. Comece pelas suposições mais críticas, que podem derrubar as demais ou torná-las irrelevantes. Utilize aqui o conhecimento de profissionais mais experientes para ajudar nessa escolha.
2. Valide com usuários (um é melhor que nenhum): Aplique seu experimento com usuários ou potenciais usuários, não com seus colegas de trabalho, amigos de área, chefes. Aplique seu experimento e confronte as ideias com quem realmente vai utilizar/comprar o que você está pensando em construir. Se não sabe como encontrar esses usuários, peça ajuda para áreas de suporte e atendimento para indicar clientes e usuários potenciais para conversar, peça para vendedores indicações de leads que possam ter entrado no fluxo de vendas com o problema que você está investigando.
3. Levante o que você aprendeu: Após aplicar seu experimento, compile e traga para a discussão as suas descobertas. Chame stakeholders e o time, explique o processo e os resultados. Fique aberto a novos questionamentos e sugestões. Muitas vezes haverá resistência de algumas pessoas, especialmente se as descobertas contradizem algumas ideias que elas trouxeram e tinham como certeza ou verdade.
4. Utilize esses resultados para tomar alguma ação: Com os resultados discutidos em mãos, defina qual o próximo passo. Se a resposta tiver sido positiva, os demais riscos (usabilidade, viabilidade e execução) foram mapeados? Podemos seguir em frente com o que temos? Conseguimos modificar nosso produto atual para resolver o que mais importa do problema, sem grandes modificações? Caso as respostas tenham sido contrárias ao imaginado, vamos validar por outra abordagem? Vamos comunicar os demais stakeholders da decisão?

O product discovery não vai te fornecer essas respostas, mas te estimular a ir buscá-las de modo ativo e disciplinado. Queremos evoluir nosso processo de descoberta para além da resolução de dúvidas e ideias dos stakeholders, buscando um fluxo contínuo de entendimento do nosso produto, do valor daquilo que estamos pensando em construir ou modificar e como tornar isso menos arriscado.

Para continuar

Algumas leituras são legais para ampliar os conhecimentos sobre product discovery. Selecionei um livro e três artigos para começar:

Livro
Validating Product Ideas, do Tomer Sharon: Um livro para não ser lido do início ao fim, mas com uma ótima estrutura, técnicas e dicas para você enfrentar as principais dúvidas para validar seu produto/funcionalidade.

Artigos
– 6 Guiding Principles for Effective Product Discovery, da Teresa Torres: selecionei este artigo da Teresa, pois é um bom guia para quem está iniciando, mas recomendo que acompanhe e leia TODO o blog dela.

– How to Stay on Course During Product Discovery, do Tim Herbig: através de uma ferramenta chamada Impact Mapping, Tim apresenta um modo de conseguir navegar pelo processo de descoberta sem se perder no mar de infinitas possibilidades.

– Common PM Problem Areas, do Marty Cagan: não fala somente sobre discovery, mas é um artigo no qual Cagan traz algumas discussões sobre o papel e responsabilidades dos gestores de produto e dos times de produto.

Este texto foi publicado originalmente no blog da Cursos PM3.