Product Discovery

Como embasar melhor suas decisões para construir um produto que os clientes amam

Matheus Tanaka
Apr 15, 2019 · 5 min read

Muito se fala de metodologias ágeis para garantir que o time de produto esteja entregando valor de maneira rápida e eficiente. De fato, é extremamente importante conseguir priorizar o backlog e executar sempre o que é mais importante para o negócio dentro dos menores prazos e custos possíveis.

Em um contexto em que as empresas precisam ser ágeis para se manterem competitivas é importante os times de produto buscarem manter seu produto sempre o mais atualizado possível, chegando muitas vezes à um processo de continuous delivery (realizando deploys muitas vezes ao dia).

Mas como saber o que deve ser construído?

Para entender o que deve ser entregue semanalmente ou quinzenalmente nas sprints e definir o que é mais importante é preciso entender sobre todo o contexto do negócio.

Esse conhecimento sobre o contexto do negócio vem da visão da empresa e da estratégia definida pela liderança. Essa estratégia pode ser representada de diversas formas, mas para facilitar o entendimento, focarei em OKRs (Objective and Key Results).

Os passos para entender sobre esse contexto de negócio são:

  1. Entender a visão da empresa;
  2. Entender todos os objetivos estratégicos do negócio e os principais resultados que medem o alcance desses objetivos (OKRs);
  3. Alinhar com as lideranças os resultados que serão de responsabilidade do time de produto.

É interessante entender que esse processo de entendimento do contexto de negócio leva em consideração que o time de produto não trabalha com um roadmap de features clássico e sim com um roadmap focado em resultados.

Dessa forma, o time de produto não é mais responsável somente por entregar features que estavam planejadas. Seu papel que acabava no momento da entrega da feature não acaba mais. Nesse modelo o time é responsável pelos resultados e deve buscar novas soluções caso a solução inicial não seja suficiente para bater a meta estipulada.

É importante destacar que apesar de que a maioria das empresas estejam abolindo o roadmap de features, trata-se de um tema muito recente, ou seja, não existem modelos substitutos consolidados.

Na GeekHunter, priorizamos os resultados que consideramos mais importantes para o negócio e focamos nosso processo de product discovery neles.

O que é Product Discovery?

É o processo de explorar e descobrir o que é mais importante que o time de produto construa no momento.

Uma vez que entendemos o contexto de negócio e temos a clareza de quais resultados queremos alcançar, podemos começar o processo de discovery que consiste em:

  1. Analisar as oportunidades que apresentam maior potencial de ajudar o time a alcançar os resultados esperados;
  2. Explorar as possíveis soluções para atacar as oportunidades escolhidas;
  3. Prototipar e experimentar para aprender rápido sobre as soluções escolhidas;
  4. Priorizar o backlog de soluções validadas.

Explorando as oportunidades

Após definir quais são os principais resultados que o time de produto irá buscar em determinado período de tempo (mês ou trimestre), o time pode começar a explorar oportunidades.

Existem diversas maneiras de identificar oportunidades que permitirão que o time alcance os resultados almejados. As formas mais comuns são através de entrevistas com usuários, pesquisas quantitativas (surveys) e análises de dados que indicam o comportamento dos usuários ou fornecem um panorama sobre o negócio.

É importante lembrar que clientes internos também são usuários e é valido entrevistá-los mesmo se eles não utilizarem diretamente o produto em questão, pois muitos deles estão em contato direto com os clientes externos e podem fornecer insights valiosos.

Podemos também extrair oportunidades de pesquisas sobre tendências do mercado, novas tecnologias e análise de concorrentes. O ideal é que o cliente esteja sempre no centro desse processo, mas muitas vezes para que a empresa consiga inovar, ela precisa antecipar soluções para dores que nem as pessoas sabem que têm.

Explorando soluções

O processo de ideação de soluções já é algo bem conhecido. Existem inúmeras metodologias para gerar possíveis soluções para resolver um problema. No momento de escolher as melhores soluções normalmente fazemos o seguinte questionamento:

Essa solução é boa ou é ruim?

É uma pergunta bem difícil de se responder, pois tratamos o “bom” como algo absoluto. A solução é boa em relação ao quê?

Ao invés disso, queremos fazer perguntas de “compare and contrast. Dessa forma, fica mais fácil saber o que é uma boa solução, pois tratamos o “bom” como algo relativo. Uma pergunta melhor seria:

Quais dessas soluções parecem ser as melhores?

Ao comparar as soluções, conseguimos ter uma noção muito melhor de quais soluções parecem resolver melhor o problema. Por isso é sempre importante manter a mente aberta quando as pessoas dão novas ideias. Essa é uma maneira de colaborar mais eficiente que evita o “apego” a uma solução e foca no que realmente importa: o problema.

Prototipando e experimentando

Todo mundo já deve ter ouvido falar do conceito de Mínimo Produto Viável (MVP), certo?

Fonte: exactsales.com.br

Apesar de ser um conceito muito difundido, muitos cometem o erro de enxergar o MVP como uma forma de validação de soluções. Pode ser que em alguns casos, o MVP realmente atue dessa maneira, mas considerando um contexto em que precisamos aprender cada vez mais rápido, imagine construir um MVP para cada solução idealizada. Seria loucura, não?

O MVP é uma forma custosa de validação, pois exige que a solução seja implementada para depois descobrir se ela funciona ou não. O ideal é que MVPs sejam trabalhados para a validação utilizando a seguinte abordagem:
MVP é o Mínimo Protótipo Viável.

Dessa maneira, não é necessário implementar a solução para validar se ela funciona. Podemos prototipá-la rapidamente e iterar várias vezes, sempre coletando feedbacks dos clientes. Dessa maneira, conseguimos aprender maneira muito mais acelerada e acertar em nossas escolhas muito mais vezes.

É óbvio que isso não nos impede de errar, mas é sempre melhor errar de maneira rápida e aprender com o erro.

Existem diversos tipos de protótipos, mas esse pode ser um tema para um outro artigo.

Priorizando o backlog de execução (Delivery)

Após definir quais soluções valem a pena ser implementadas, podemos passar para a etapa de priorização do backlog.

Essa etapa envolve mais o “jogo de cintura” que os responsáveis pela gestão de produto tem que ter naturalmente. É importante sempre estar alinhado com as lideranças do negócio e entender bem todo o contexto para conseguir tomar a decisão do que será priorizado.
Inevitavelmente surgem novas necessidades e prioridades, mas realizando um bom processo de discovery, é possível tomar decisões melhor embasadas em relação ao que será executado pelo time de produto.

Considerações finais

Para saber quais resultados buscar é necessário definir uma boa visão de produto que irá inspirar o time e será um lembrete de onde querem chegar. Essa visão deve derivar da visão do negócio, e dela deverá derivar a estratégia de produto.

Definindo essa estratégia, teremos um entendimento maior de quais resultados o time de produto deverá buscar e quando deve buscá-los.

Como estratégia de produto é um tema extenso, falarei um pouco disso em outro artigo.

Ficou com alguma dúvida ou gostaria de trocar conhecimentos sobre práticas de product discovery? Me chama no LinkedIn e vamos trocar uma ideia!

Matheus Tanaka

Written by

Product Manager passionate about how lots of bad ideas become great ideas as we decide to collaborate.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade