Product Discovery – Descoberta de Produto

Product Discovery (Descoberta de Produto) é um processo continuo de aprendizado, da qual é composto por um conjunto de atividades, técnicas e ações que tem o objetivo de descobrir aquilo que não se sabe sobre o produto.

A Descoberta do Produto já deixou de ser assunto somente de startups e produtos novos há muito tempo. Por conta disto, organizações em seus mais diversos estágios tem utilizado cada dia mais o conceito e boa parte de suas técnicas.

Pretendemos apresentar, de uma forma bem dinâmica e didática, a definição completa deste processo, bem como a sua utilização, fases, resultados e como Product Owner precisa conduzir e organizar as dinâmicas.

grupo de pessoas ao redor de uma mesa projetando ideias em um papel com canetinhas e desenhos

Product Discovery – Descoberta de Produto

 

O que é Product Discovery?

Como o próprio nome indica, o Product Discovery é um conjunto de atividades, técnicas e ações que tem o objetivo de descobrir aquilo que não se sabe sobre um eventual produto a ser criado ou melhorado.

São processos, ferramentas e uma coleção de ações colaborativas que nos ajuda a entender melhor os problemas, usuários/personas e contexto de negócio que não temos o total entendimento e precisamos descobrir para solucionar a dor/necessidade.

 

Assine nossa Newsletter e fique sempre atualizado com nossos artigos!

 

A descoberta de produto contribui para tomada de decisões mais assertivas antes de sair construindo produto, reduz risco de entrega sem valor de negócio e visa descobrir a melhor forma de atender às necessidades do negócio e usuários.

É importante reforçar que o PD não é apenas um processo e muito menos um conjunto de passos, mas sim uma mentalidade organizacional que visa conhecer e validar previamente novas funcionalidades do produto.

O Product Discovery é o Processo que nós, Donos do Produto, utilizamos para descobrir se o produto a ser criado está no caminho certo, descobrir os riscos, viabilidades, reduzir incertezas e refinamos ideias.

Porque fazer?

O Product Discovery é recomendado quando não temos conhecimento do problema/necessidade em que visualizamos a oportunidade e precisamos descobrir mais a respeito.

Também é recomendado para validar rapidamente uma eventual solução, projetar o MVP, mitigar risco de implementar algo que não entrega valor aos usuários ou à organização e redução de incertezas.

Quando fazer?

PD não é somente para produtos novos, mas também para produtos em funcionamento, independente da fase em que se encontra o ciclo de vida do produto.

A descoberta de produto não é recomendada a qualquer momento a toda hora e a qualquer custo, pois custa tempo e dinheiro da organização. O ideal é se fazer as seguintes perguntas antes de elaborar uma sessão de PD:

  • Eu tenho objetivos de negócio vinculado?
  • Eu não conheço o problema/oportunidade?
  • Se eu não realizar o PD, tem risco de perder espaço no mercado?
  • A descoberta de produto é a melhor forma de validar a ideia e solução?
  • O risco de não realizar o Product Discovery é alto?
  • Vai agregar valor no meu Produto?
  • Tenho disposição e tempo para executar um PD?

Se todas ou a maior parte das respostas para as perguntas forem “Sim”, é mais que recomendada a sua execução.

 

Os 4 riscos de Marty Cagan

Marty Cagan, Product Manager bastante conhecido no Vale do Silício e autor de INSPIRED, descreve quatro riscos que a Descoberta de Produto visa mitigar:

  • Risco de Valor: Sendo o risco mais importante a ser avaliado, este é o principal ponto de atuação do PO. É importante entender se a resolução do problema terá valor suficiente para os usuários para justificar o esforço de resolução.
  • Risco de Usabilidade: Esse risco visa entender se os usuários vão conseguir utilizar, entender e interagir com o produto. Aqui o conhecimento e habilidades sobre experiência do usuário são imprescindíveis.
  • Risco de Negócio: O valor do produto para o negócio também deve ser um fator importante a ser considerado. O Dono do Produto deve garantir que a entrega traga resultados que possam ser traduzidos em benefícios mensuráveis para a organização.
  • Risco de Viabilidade: Este é o ponto mais técnico desta lista e esse risco deve ser gerenciado e observado pela equipe técnica envolvida. Devem ser analisados fatores sobre infraestrutura, tecnologia atual, habilidades técnicas, tempo, escalabilidade e demais requisitos não funcionais.

Fases da Descoberta do Produto

Vamos abordar a seguir as fases da descoberta de produto, bem como cada uma das atividades e técnicas que compõem essas etapas.

2 círculos cíclicos de Exploração e Validação apresentando as etapas do Product Discovery

Fases da Descoberta do Produto

 

 

Exploração

A fase de exploração recebe como insumo oportunidade/ideia ou problema percebido e o seu objetivo é entender e se aprofundar nas principais dores existentes.

A ideia aqui é explorar a fundo aquilo que não se sabe, tais como: dores e necessidades, usuários/personas, contexto de negócio e demais assuntos que podem impactar indiretamente o produto como questões legais, não funcionais e viabilidade.

A seguir as atividades que envolvem a etapa de exploração:

Ideia / Oportunidade

Tudo começa a partir de uma oportunidade de negócio percebida pelo Dono do Produto. É essa informação que alimenta nosso processo de descoberta e é justamente este ponto que precisamos entender e compreender.

Ideias, problemas e oportunidades podem surgir de diversas fontes diferentes:

  • Necessidade dos Usuários: Observando o mercado e comportamento dos usuários, é possível encontrar dores e necessidades existentes no dia a dia. Isso vale tanto para os produtos existentes através dos feedbacks quanto para novas soluções de mercado.
  • Objetivo Estratégico: Também conhecido como OKRs, é bastante comum que as oportunidades são iniciativas sejam geradas para atender os Resultados Chaves esperados.
  • Problema de Negócio: Problemas em processos de negócio para otimizar fluxos, reduzir custos, esforço operacional, atendimento regulatório/legal, entre outros pontos de trabalho da organização. Demandas deste tipo são normalmente originadas pelos clientes internos ou partes interessadas.
  • Problemas de Produto: Inconsistências no Produto atual – normalmente por falha operacional ou não atendimento dos requisitos funcionais e não funcionais, além de limitações técnicas ou qualquer outro tipo de erro não funcional.
  • Análise de Dados: A análise dos dados obtida através do uso e alimentação de dados do Produto permite obter informações valiosíssimas quanto ao perfil dos usuários, mercado, negócio e vários outros pontos não percebidos. Aqui vale uma análise analítica e sintética para buscar melhores insights.
  • Análise do Mercado e Concorrência: A Análise do Mercado é também uma excelente fonte de ideias, pois é possível observar o comportamento do mercado que envolve o Produto e possíveis novos usuários. Observar a concorrência traz possibilidades e ponto de vista que podemos ter esquecido ou deixado escapar.

Apesar deste ponto ainda não ser o Backlog do Produto, o Proprietário do Produto precisará estruturar e organizar bem seu “Backlog de Ideias” para entender quando realizar o processo de descoberta.

A descrição, origem e objetivo de cada oportunidade deve ser bem descrita pelo PO.

Pesquisa

Após a apresentação e organização da ideia/oportunidade, a atividade de pesquisa é o primeiro passo para início da descoberta da necessidade a ser solucionada. Este é o momento em que saímos do nosso mundo e vamos até o universo dos nossos usuários.

Bastante conhecido na disciplina de UX Research ou na Engenharia de Requisitos, é um conjunto de técnicas que busca investigar com profundidade um assunto, problema, resposta e/ou situação ainda não conhecido.

Tendo como premissa o desconhecimento total do contexto, o objetivo aqui é descobrir os seguintes pontos imprescindíveis para o Produto:

  • Dores e necessidades
  • Usuários e Personas
  • Contexto de Negócio
  • Mercado e Concorrentes

O Product Owner precisa ter a capacidade de moderar as pesquisas, bem como conduzir a dinâmica e registrar todas as informações possíveis. Aqui é necessário que seja usada a sua habilidade de comunicação e empatia.

Avaliação e agrupamento

Uma vez que os problemas e necessidades estão mapeados, é hora de agrupá-los por semelhanças e pontuar cada um dos itens levantados através da percepção resgatada pela pesquisa realizada.

Também chamada de convergência no Design Thinking, neste momento os envolvidos realizam as seguintes atividades para fechar o entendimento da fase de exploração:

  1. Agrupar por semelhança
  2. Definir o problema a ser resolvido
  3. Priorizar os problemas

Neste momento, o Product Owner precisa utilizar das suas habilidades de priorização e percepção de valor de negócio. É também muito importante já termos conhecido nosso usuário, mercado e concorrência, organização e contexto.

 

Validação

Partindo do problema mapeado e conhecido, a fase de validação é o momento em que os problemas e hipóteses mapeados são validados a partir de projeções, mapeamento da jornada e protótipos.

Essa fase também elimina o desperdício de tempo com desenvolvimento indevido e permite que possamos aprender rápido e experimentar mais rapidamente.

A seguir as atividades que envolvem essa etapa:

Protótipo

Com as ideias, problemas ou necessidades mapeadas, chegou o momento de gerar ideias de soluções para cada item priorizado.

Nesse sentido, o grupo deve começar a desenhar, com as ferramentas disponíveis, diversas propostas de soluções. Aqui a ideia é livre e o objetivo é que sejam mapeadas a maior quantidade possível de propostas.

Para desenho ou redesenho de interfaces ou objetos, existem alguns tipos de protótipos largamente utilizados:

  • Protótipo de baixa fidelidade: Rascunhos em baixo nível de detalhes e mais rápido de desenhar. O objetivo aqui é não se aprofundar, mas entender a disposição de cada uma das partes e gerar um número maior de ideias.
  • Protótipo de alta fidelidade: Desenho da solução mais próxima do resultado real e esperado. Normalmente necessita de profissionais mais capacitados e busca mais profundidade nos detalhes.

Existe uma infinidade de técnicas de prototipagem e tipos de protótipos. O Dono do Produto e o time pode selecionar aquele que melhor faz sentido para a dinâmica. A capacidade de aprendizado e criatividade neste ponto é imprescindível.

Teste

Com os protótipos realizados, mapeados e selecionados, é o momento de testar se a hipótese levantada para o problema/necessidade encontrado é verdadeira.

Os artefatos de entrada para os testes serão as personas mapeadas, o contexto de negócio percebido e principalmente os protótipos desenhados.

Os protótipos mapeados precisam ser apresentados e validados próximos ao usuário, do qual deve interagir, de alguma forma, com os desenhos realizados.

O objetivo aqui é colher feedbacks dos usuários e procurar entender se as propostas de solução realmente sanam em parte ou total suas dores. O PO precisará escutar muito mais do que falar, ter boa comunicação, saber escutar e observador.

Aprendizado, invalidação e conclusão

Por fim, chegou o momento de validar ou invalidar as ideias geradas, entender se o as dores e necessidades, bem como as hipóteses e propostas de soluções obtiveram o sucesso esperado.

A fase de validação só pode gerar duas saídas possíveis:

  • Problema, hipótese e protótipos validados: Esse é certamente o caminho mais esperado pelo Dono do Produto. Nesse caso, o resultado obtido vai para o Backlog do Produto para ser devidamente priorizado, planejado e construído pelo time de desenvolvimento.
  • Problema, hipótese ou protótipos não validados: O Product Discovery tem tudo a ver com velocidade. É nesse ponto que entra o termo “Errar rápido para acertar rápido”. Isso significa que invalidar ideia é também um bom resultado, pois mostra que economizamos muito tempo e dinheiro em uma solução definitiva com muito menos horas de validação.

Vale lembrar que não existe certo ou errado. Alguns parâmetros previamente definidos (não escritos aqui) devem servir de “régua” para o grupo definir se obteve o sucesso ou não em cada resultado.

O Proprietário do Produto precisará, novamente, utilizar sua percepção de valor de negócio e habilidade de tomada de ação, liderança sobre o Produto e análise de dados para tomar decisão com maestria sobre a validação ou invalidação.

 

Conclusão

A Descoberta de Produto é cíclica e pode ser realizada até que existam oportunidade/problemas a serem mapeados, até que exista hipóteses a serem validadas ou invalidadas e até que exista possibilidades de propostas.

Somado a este ponto, entendemos que o produto precisa ser constantemente adaptado para que se perpetue o seu Ciclo de Vida no máximo possível e mantenha o seu crescimento constantemente.

Por conta disto, é esperado que uma organização com cultura de produto seja orientada à descoberta e evolução deste produto – não baseada em Projetos, mas com foco na solução e resolução de problemas.

Gostou? Então compartilhe!

Você pode gostar...

5 Resultados

  1. 27 de junho de 2021

    […] Se você não sabe muito sobre descoberta de produto ou pra que serve, recomendo que você dê uma lida rápida em outro artigo do nosso site que fala sobre o objetivo, quando executar e as definições de cada etapa do p…. […]

  2. 15 de novembro de 2021

    […] informações do gráfico comprovam que na etapa de análise, seja através do Product Discovery, Inception ou qualquer outro método de pesquisa e descoberta, é extremamente importante para a […]

  3. 6 de janeiro de 2022

    […] fim – e não menos importante – é importante citar que conhecimentos de UX/UI, MVP, Product Discovery, Maximização do valor do Produto, História de usuário e outros assuntos já comentados aqui tem […]

  4. 19 de janeiro de 2022

    […] durante a execução da sprint, o PO deve atuar com os usuários, mercado de atuação, pesquisa, Discovery e outras atividades que contribuam para enriquecimento do backlog do […]

  5. 2 de março de 2022

    […] de bons Product Discovery buscando o MVP do Produto como um todo e também de novas implementações de Épicos, reduzindo […]

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *