Product Discovery

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

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.

Apaixone-se pelo problema e não pela solução.

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!