Product Discovery
Share on facebook
Share on twitter
Share on linkedin

Product Discovery: Mitigando os riscos de produto

Felipe Soares

Felipe Soares

Product Owner

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, e muito a nortear se o caminho a ser seguido pode ser interessante, além de que a 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, onde 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. O processo de discovery consiste basicamente em: experimentação, validação, aprendizados e decisão. 

Sumário

 O processo de Product Discovery 

 O processo de product discovery tem uma abordagem totalmente centrada no usuário com foco em gerar soluções criativas para todos os tipos de problemas, 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, que busca 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 mais pessoas que se correlacionam com o problema a ser resolvido. Ouvir nossos clientes e usuários nos traz percepções incríveis de experiência, do que eles 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 alguma necessidade específica deles.  

 A chave está na empatia pelas pessoas que irão de alguma forma 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 ela 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 às 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? 

 

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: o que implicaria, 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:

  1. risco de valor

  2. risco de usabilidade

  3. risco de execução 

  4. risco de 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? Será que esta forma de resolver o problema agregaria valor para meu cliente? Será que 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) 

  

 1 – 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

  2 – 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). 

 3 – 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. 

 É 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. 

 4 – 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. 

Sintetizando e 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; cabendo 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; que como disse, deve trabalhar junto para uma melhor avaliação e percepção do cenário e tudo que ele implica. É 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 resumo: 

  • 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. 

E 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!

Preencha seus dados para receber nossa newsletter!

Tá na dúvida?

contato@dtidigital.com.br

R. Antônio de Albuquerque, 330 – 14° andar
Savassi, Belo Horizonte – MG, 30112-010

Cuidado

Nós utilizamos cookies e outras tecnologias semelhantes para analisar sua experiência no site e personalizar conteúdos e anúncios durante sua navegação. Ao navegar pelo site, você autoriza a DTI Digital a realizar tal monitoramento. Conheça nossa Política de Privacidade.

You will be redirected to spotify