Product Discovery: Mitigando os riscos de produto

Por Felipe Soares|
Atualizado: Jul 2023 |
Publicado: Jul 2021

Iniciar um novo negócio, seja a construção de um novo produto ou a implementação de uma nova funcionalidade para um produto já existente no mercado, demanda muita análise, preparação e estudo, que envolve desde a ideia de projeto até o entendimento do que construir, que é o conceito de product discovery. Porém esse processo não deve se basear apenas nas percepções dos stakeholders ou em pesquisas de mercado.

Não estou dizendo que isso não seja importante, pelo contrário, isso ajuda sim a nortear se o caminho a ser seguido pode ser interessante. Além da expertise dos stakeholders trazem um direcionamento estratégico para o negócio. Porém, é necessário muito mais que apenas essas informações para ter segurança de um lançamento.   

Quando falamos em cultura de produto partimos inicialmente de um processo de descoberta, que chamamos de product discovery. Nele, buscamos entender as dores dos nossos possíveis usuários e as formas que podemos ajudá-los, traçando assim uma solução viável a ser construída e entregue.

Em suma, o discovery consiste basicamente em: experimentação, validação, aprendizados e decisão. 

O processo de Product Discovery 

Primeiramente, esse processo tem uma abordagem centrada no usuário com foco em gerar soluções criativas para todos os tipos de problemas. Isso ocorre através da co-criação do time de produto, evitando, desta forma, desperdícios de tempo, esforço e dinheiro. Caracterizado como uma jornada de aprendizado constante,  buscando entender o que faz sentido para o usuário, ajudando a responder às principais perguntas que geram incertezas para construção do produto ideal. Assim, como conceitua Marty Cagan, product discovery é um processo para definir um produto valioso, útil e viável. 

Neste processo, é preciso ouvir seus possíveis usuários e envolver pessoas que se correlacionam com o problema a ser resolvido. Ouvir clientes e usuários traz percepções incríveis de experiência, do que estão realmente usando do produto, se a solução os atendem da melhor forma, se sentem falta de algo e como podemos melhorar o produto baseado em necessidade específica deles.  

A chave está na empatia pelas pessoas que irão interagir ou utilizar nossas soluções, aqui deixando os ‘achismos’ de lado e tendo curiosidade sobre nossos usuários. O feedback antecipado sobre o que iremos construir é o melhor caminho. Então não devemos ter medo de procurar nossos usuários e perguntar a eles sobre nossa solução, mesmo que ainda não esteja finalizada! 

O pensamento deve ser: construir pequeno, testar rápido e melhorar continuamente.  

Algumas perguntas podem e devem ser feitas para nos ajudar nesse processo de enxergar e entender nosso cenário sob as percepções de mercado e do usuário: 

  1. Esse problema realmente existe para o usuário? Se sim, como ele o soluciona hoje? 
  2. As soluções atuais estão atendendo as suas necessidades? 
  3. É um problema que gera insatisfação o suficiente para ele buscar uma outra solução? 
  4. Ele estaria disposto a pagar por este serviço? 
  5. Esse problema envolve mais pessoas? 
Quer ver mais conteúdos como esse?

Construção e validação de hipóteses de produtos

A partir desses questionamentos começamos a levantar pontos relevantes que nos guiaram em nossas ideias de solução, começando a construir e validar hipóteses. E claro que esse processo deve ser contínuo, para entendimento do nosso produto, pensando sempre na agregação de valor ao que temos e ao que estamos pensando em construir; o que chamamos de dual track agile, onde trabalhamos paralelamente com o processo de discovery e delivery, entregando novas funcionalidades para os usuários, ao mesmo tempo que testando e validando hipóteses antes da construção. 

 Alinhado a esse processo devemos também identificar os riscos do desenvolvimento desta solução. Isto é, avaliar se resolveria de fato o problema do usuário, se conseguimos construir, se teríamos retorno do investimento, entre outros pontos.

São questionamentos que procuramos responder definindo e sabatinando sobre os quatro riscos de produto que Marty Cagan apresenta para nós em seu livro Inspired. São eles os riscos de: 

  1. Valor
  2. Usabilidade
  3. Execução 
  4. Viabilidade de negócio. 

Riscos de produto: o que você precisa saber sobre?  

Durante um processo de descoberta é importante direcionarmos nossa atenção também aos riscos do produto, pois eles podem inviabilizar a construção do mesmo. Para mapear cada risco podemos levantar alguns questionamentos: 

  • Será que estamos resolvendo um problema real? esta forma de resolver o problema agregaria valor para meu cliente? as pessoas vão comprar ou escolher usar esta solução? (Risco de valor) 
  • Será que meu cliente consegue entender como usar meu produto? (Risco de usabilidade) 
  • É possível construir este produto? Temos conhecimento e capacidade para construir esta solução? (Risco de execução (viabilidade técnica)) 
  • Será que conseguimos assumir os riscos deste produto? Essa solução funciona para o nosso modelo de negócio? (Risco de viabilidade de negócio) 

Tipos de risco no Product Discovery

Riscos de valor no Product Discovery

Neste risco devemos avaliar se o que estamos pensando em construir irá realmente gerar valor para o cliente, e se irá impactar positivamente a sua vida e resolver satisfatoriamente a sua principal dor. Uma forma de mitigação deste risco é através de entrevistas com o usuário. Podendo ser acompanhado de um teste de usabilidade em protótipo, por exemplo, ou utilizando de outras abordagens como o teste A/B e programas de teste acompanhado. 

 Temos que pensar que mesmo que tenhamos a melhor ideia de solução, ela pode não fazer sentido para o nosso público alvo, sendo desnecessária para eles, desta forma não trazendo o retorno esperado. Não devemos nos apaixonar pela solução, mas sim pelo problema a ser resolvido! 

Os agilistas times de produto - Product Discovery
Os agilistas times de produto.png

Riscos de Usabilidade

Neste risco devemos levar em consideração se o que estamos pensando em construir irá trazer uma experiência satisfatória para o nosso usuário, e se eles vão realmente conseguir usar a nossa solução. Neste ponto, uma forma de mitigação é avaliar pelo uso da nossa solução (a partir de MVP, protótipos, por exemplo) se os usuários estão sabendo usar, se estão reclamando de algo, ou se tem alguma dificuldade ou problema no uso. 

 É importante que neste passo estejam envolvidos as pessoas de design e experiência de usuário (UI/UX). 

Riscos de Execução (viabilidade técnica)

Neste risco avaliamos se a solução proposta é factível de ser construída, trazendo um ponto de vista bem técnico sobre a solução, sendo imprescindível que a equipe de engenheiros, arquitetos e dados participem (de acordo com a necessidade do projeto). Uma forma de mitigação desse risco é a construção de PoC’s (Proof of Concept ou prova de conceito), para identificação de capacidade técnica do time. 

Por fim, é sempre importante alocar tempo da equipe para esta avaliação, onde possam pesquisar e estudar sobre a construção da solução proposta e em que isso implicaria. 

Riscos de Viabilidade de Negócio

Neste risco entramos em uma análise onde devemos verificar se a solução está alinhada ao modelo de negócio do cliente e o retorno que a construção e entrega dessa solução irá trazer para empresa. Para mitigação deste risco podemos nos questionar: estamos preparados para lançar este produto, qual a possibilidade de aquisição do nosso produto pelo nosso usuário, a qual preço conseguimos vender este produto e se esse retorno será satisfatório para empresa em questão de investimento inicial. 

A avaliação deste risco é importante pois vai em contato direto com várias áreas da empresa como financeiro, jurídico, vendas e marketing; onde vários pontos devem ser pensados em cima do que está sendo proposto: avaliando se é necessário treinamento para a equipe de vendas, o nível de auxílio que será necessário para o nosso usuário (se pode ou não gerar uma sobrecarga no suporte, por exemplo), questões voltadas a LGPD e compliance, e divulgação do produto para mercado. 

Concluindo temas para Product Discovery   

O papel do Product Manager é definir o quê, quando e porquê um produto e/ou funcionalidade deve ser criado, já a parte do como fazer  fica a encargo de todo o time, designer e desenvolvedores. Cabe ao PM alinhar o time e direcioná-los na construção do melhor produto possível. Mas para que seja possível o product manager definir o quê construir é necessário o processo de descoberta do produto! 

O processo de discovery e mitigação dos riscos deve ser o ponto inicial na construção de um produto, onde a descoberta do problema deve ser bem estruturada e desenvolvida entre todo o time. Para isso, deve-se trabalhar junto para uma melhor avaliação e percepção do cenário e tudo que ele implica. Contudo, é importante que aquietamos nossos egos para ouvir e observar.  

princípios do agilismo

A avaliação dos riscos devem ser realizadas se esperamos ter sucesso com o nosso produto. Confiar e se basear apenas nas ideias e percepções do time de desenvolvimento e dos stakeholders é totalmente um equívoco e pode causar o insucesso do seu produto. 

É importante que avaliemos as percepções dos nossos possíveis usuários e validemos nossa proposta ainda em protótipo ou em MVP, antes mesmo de implementá-las para que tenhamos maior garantia de que realmente estamos seguindo no melhor caminho. O não atendimento e atenção a esses riscos pode implicar em problemas tanto de não aceitação do produto em mercado, não permitindo que ele atinja sua maturidade (market fit), como também,  problemas voltados a área jurídica e financeira da empresa. 

 Em síntese 

  • Seja específico com seu recorte de mercado (público alvo); 
  • Aloque tempo para que sua equipe técnica avalie as possibilidades de construção; 
  • Converse com todas as áreas impactadas pelo seu produto na empresa; 
  • Crie protótipos; 
  • Defina um MVP (mínimo produto viável); 
  • Execute testes consecutivos para avaliar e validar seus conceitos e soluções antes de implementá-las; 
  • Verifique a usabilidade e experiência do seu usuário; 
  • Aprenda com seus usuários; 
  • Faça iterações e evolua o seu produto a cada hipótese validada ou invalidada. 

Além disso tudo, lembre-se que o processo de discovery e mitigação de riscos deve fazer parte de todo o ciclo de vida do seu produto!

Se você tem interesse em mais insights sobre tecnologia na prática, validação de hipóteses em produtos e metodologia ágil, o podcast Os Agilistas pode te ajudar nessa jornada.

Gestão empresarial ágil
Saiba mais sobre True Agile

Lá você tem acesso aos assuntos mais variados dentro do contexto de mercado de trabalho e tecnologia. Vale a pena!

Quer saber mais?