Descrição: Este material tem o objetivo de reunir algumas ideias sobre o assunto de Discovery de Produtos, boas práticas, práticas que não devem ser seguidas e outras adições pessoais discutidas durante os encontros de mentoria.

O que é?

Além de ser a “grande solução para todos os problemas de produtos”, Discovery é uma forma de denominar um grupo de atividades com a intenção de responder algumas perguntas que tenhamos e tentar diminuir riscos quando estivermos definindo hipóteses de solução. Martin Cagan cita esses 4 riscos:

• Risco de valor (monetário) → O cliente vai pagar por isso ou escolher o que estamos propondo?
• Risco de usabilidade → Vai ser fácil de utilizar? Fácil de entender?
• Risco de execução → Temos gente ou capacidade suficiente pra criar isso?
• Risco de viabilidade → A solução combina com nosso negócio?

O que come?

Diversas literaturas colocam o Discovery como parte do processo de construção de um produto. Por mais que esta visão esteja certa, para mim, isso torna o discovery uma muleta ou uma burocracia no processo de produtos.

Neste tempo todo, o que aprendi com discovery é que ele é essencialmente uma forma lógica de enxergar um problema.

Um exemplo próprio que uso para clarificar as ideias, quando o cliente (stakeholder) solicita algo que não está tão detalhado:

Usando o exemplo acima, a estrutura de blocos e as perguntas, são feitas de forma que o problema apresentado, seja explicitado e comece a ser dividido entre dúvidas e certezas.

Não é um formato próprio, utilizei como base um dos links que vou adicionar na bibliografia, mas os passos propostos pelo autor são:

1 – Aprofundamento do problema:

• Qual problema queremos resolver?
• Qual o público e qual tamanho?
• Porque para o produto/negócio, isso é importante?
• Como os concorrentes resolvem esse problema?

2 – Evidências – Chitãozinho & Xororó

• Tenho dados que quantificam o problema?
• Resolver isso vai de encontro com os objetivos do quarter/companhia?
• Clientes entram em contato/reclamam sobre isso?
• Foi feito análise da concorrência?

3 – Com qual solução vamos validar nossa hipótese?

• Qual ou quais soluções propostas para o problema?
  • Separado por curto prazo, médio prazo, longo prazo;
• A solução proposta traz diferencial para o produto?
• Como testar/medir se a solução vai resolver o problema?
  • Separado por curto prazo, médio prazo, longo prazo;
• Como vamos validar a hipótese?
  • Acreditamos que, a solução, para o, público, através do experimento, qual experimento será feito.
  • Sabemos que a hipótese foi validada quando, qual resultado esperado?

4 – Mitigar riscos

• Risco de valor (monetário);
• Risco de usabilidade;
• Risco de viabilidade técnica;
• Risco de viabilidade de negócio.

5 – Qual a estratégia de rollout?

• Como vamos entregar para aprender rápido?
• Qual será a segmentação?

6 – Quais métricas para sucesso da funcionalidade?

• Quais métricas indicam o caminho certo?
• Qual o alvo dessa solução?
• O que queremos impactar no negócio, cliente ou tecnologia?

Onde vive?

Usando o ponto anterior, já começamos a desmitificar o Discovery. Ele sai de uma “técnica divina que fornece todas as respostas”, para uma forma lógica de clarificar problemas e dúvidas.

Isto posto, um ponto importante, antes de falar de técnicas de Discovery, é quando ele é necessário ou não.

Quando não usar?

Lembre-se de que tudo aqui são recomendações, a ideia é não cair no erro de usar o processo de Discovery como parte de uma burocracia.

Todo processo que fornecer respostas às dúvidas que você possui, já serve como base para seguir com as hipóteses de solução. Refinamentos, plannings, teste de jornada, conversa em pé, discussão de roadmap, já são base para te entregar mais informações.

Todo contato que você tiver com seu cliente ou com o time do produto já são parte da descoberta de hipóteses de solução.

Algo que pode até mesmo te ajudar previamente, para decidir se vale a pena ou não seguir para um discovery, é o Hypothesis Canvas.

Hypothesis Prioritization Canvas v1.pdf

O Hypothesis Canvas ajuda principalmente a entender se, hipóteses que você já possui em relação a um problema apontado pelo cliente, valem a pena seguir em frente ou não. Até mesmo se alguma dessas hipóteses merece um Discovery.

Ainda assim vai seguir com o Discovery?

Se você já tem hipóteses em mãos, fica mais simples de entender se vale seguir para um discovery.

Ainda assim repito alguns alertas que o Ivonika levanta sobre uma hipótese. Se alguns dos itens abaixo for verdadeiro, acenda o alerta:

• Acreditar que a ideia é a melhor do mundo;
• Não ouvir os clientes;
• Não mergulhar na dor;
• Não começar validando o mais difícil.

Nas referências, ao final desse material, vou colocar um artigo excelente do Product Oversee falando sobre Delivery e não Discovery. Que ajuda a entender os pontos anteriores, da importância de avaliar se é necessário mesmo o Discovery.

Qual a melhor receita para um Discovery?

Esse é o grande benefício do Discovery. Não existe uma bala de prata. Tudo vai depender do objetivo, onde você quer chegar. Existem diversas metodologias de Discovery que se aplicam a vários contextos. Abaixo abordaremos algumas.

Vou começar a lista com alguns que já utilizei, e darei mais detalhes dos métodos que surtiram mais resultados na minha experiência.

Desk Research

Neste link tem uma excelente explicação detalhada –

Desk research: o que é e como você pode elaborar o seu

Alguns pontos importantes que posso salientar:

• O objetivo da pesquisa não pode ser enviesado. Por exemplo perguntar ao cliente “o que ele gosta no aplicativo”. Isso limita a visão de quem vai responder, para falar bem do que está sendo pesquisado;
• Tenha mapeado as possíveis fontes de dados e com isso definir como a pesquisa será feita;
• Realize a pesquisa em si. Parece redundante este ponto, mas não deixe para realizar a pesquisa, só quando tudo estiver perfeito. É um processo de aprendizagem pro pesquisador também;
• Faça a análise dos dados. Por mais qualitativa que seja a pesquisa, transforme as entradas em dados quantitativos, ao máximo possível, para que seja fácil entender os padrões.

Cadeia de Valor

Neste link tem a explicação detalhada –

Cadeia de valor: o que é e por que montar uma para a sua empresa

Pode parecer estranho estar falando de um método mais voltado para gestão de processos, porém muitas vezes precisamos parar e fazer um discovery dos pontos onde nosso produto “toca”.

Alguns pontos que destaco sobre isso:

• Recomendo os livros do autor deste método que é o Michael Porter;
• Mapeie todas as áreas que geram valor para o seu produto, por exemplo, time de desenvolvimento, time de QA, etc;
• Geralmente a conta aqui é Valor Criado – Custo para chegar nesse valor = Margem de Lucro.

Benchmark

Neste link tem a explicação detalhada –

Benchmarking: por que a grama do vizinho parece sempre mais verde?

Como diria o Buiu da Praça é Nossa: “Traduzindo”, é a famosa Análise de Mercado. Por vezes é necessário comparar a solução que estamos propondo, com o mercado.

Muitas vezes, hipóteses que estamos levantando, já foram testadas no mercado e nos dá uma resposta aproximada da respostas do usuários. Por exemplo, vale a pena levar para um discovery, criar um aplicativo de aluguel de patinetes, para uma cidade com áreas comerciais pouco densas?

Se formos analisar mercados de cidades maiores, percebemos que talvez seja uma hipótese já validada, que não trará um bom resultado, já que diversos players saíram do país, por falta de retorno.

Tenha em mente dois pontos:

• Diversas features, serviços, produtos, etc, são commodities, ou seja, são itens obrigatórios para um produto. Exemplo disso, um aplicativo precisa ser feito para Android ou iOS, não adianta fazer um app para Windows Phone;
• Saiba quais empresas você deve usar como comparação. Imagine que seu produto é um produto agro. Não adianta fazer um benchmark com um produto espacial, por exemplo. Tenha foco no benchmark.

Segmentação de Mercado

Neste PDF, tem mais detalhes sobre segmentação e práticas –

https://www.sebrae.com.br/Sebrae/Portal Sebrae/UFs/MG/Sebrae de A a Z/Segmentação+de+mercado.pdf

Mais um item que parece não ter relação com Discoverys, mas é um ponto importante tanto para um produto, quanto para uma empresa. Relacionado até ao Benchmark, é necessário ter claro a definição do segmento de mercado.

Usando exemplo clichês, a Amazon não chegou onde está, atacando todos os segmentos ao mesmo tempo. Um dos produtos, que é a AWS, tem seus segmentos também. Atendendo, desde pequenas empresas, até empresas gigantes como o PicPay, Netflix e afins.

Associado ao segmento, defina também o tamanho do mercado que você quer trabalhar. Pode ser que uma hipótese levantada, vá atender uma parte do mercado que o seu produto realmente alcança.

Entra aqui também a Identificação de concorrentes e possíveis substitutos para o produto ou serviço que você oferece.

Personas

Neste link, tem uma boa explicação e bons exemplos de Personas –

Persona: o que é, como fazer e por que criar uma para sua empresa [+ferramenta]

Este é um item que ajuda demais no levantamento de hipóteses e nos refinamentos das soluções. Este é um trabalho mais específico do time de Design ou de UX, mas caso você não tenha esse trabalho já feito, é possível criar Proto Personas, que também ajudam a guiar os Discoverys.

Proto Personas, é resumidamente o trabalho inicial de uma Persona. Mais detalhes no link abaixo.

Guia prático de proto-personas e personas | Alura

Pesquisa com usuários e leads

Dependendo do tipo de produto que você desenvolve, é uma forma válida de fazer um Discovery. A percepção entre as respostas de um cliente e as respostas de um lead, podem te dar hipóteses diferentes e focos diferentes.

Não vou abranger aqui técnicas para essa pesquisa. Pode ficar para outra mentoria, mais voltada para Marketing. Todavia, fica um link aqui que vale a consulta.

Pesquisa com usuários: como escolher a técnica certa?

Entrevista com clientes internos

Em muitos casos, atendemos com produtos internos, ou então, existem clientes internos que utilizam o produto que fornecemos. Então é uma excelente fonte de hipóteses e soluções. Principalmente para chegarmos no próximo método.

Quais técnicas eu recomendo?

Relembrando que o processo de Discovery, nada mais é, do que aplicar um raciocínio lógico a resolução de problemas. É basicamente fazer igual a Xuxa, pegando somente uma cartinha pra ler, das centenas que foram jogadas pra cima.

Isto posto, as técnicas abaixo ajudam nisso, e por ordem, das mais rápidas, às mais elaboradas.

Matriz CSD

Neste link tem uma excelente explicação da técnica –

Matriz CSD: template e passo a passo para usar no projeto

Usando um exemplo recente, pelo menos para os Paulistas, uma matriz rápida de CSD seria:

• Certeza: O buraco desmoronou;
• Suposições: Talvez um super cano da Sabesp tenha sido a causa;
• Dúvidas: Tem jacaré na água? Vai dar para usar o Tatuzão depois, pra terminar o tunel?

Não é necessário usar um canvas, ter um material bonitinho pra escrever. Basta ter o pensamento lógico de separar as certezas, suposições e dúvidas.

Lightning Decision Jam

Neste dois links, tem mais detalhes sobre esta técnica –

Welcome to Lightning Decision Jam resource page!

Lightning Decision Jam: O que é, Como Fazer e Exemplos – ONOVOLAB

O LDJ é uma evolução da técnica Dot Voting. Ele possibilita sair de uma sessão, já com hipóteses e soluções priorizadas e principalmente, já validadas com o cliente.

O importante nessas sessões é realmente respeitar os tempos para cada etapa, pois isso colabora com que os participantes pensem somente nos problemas e possíveis soluções, para o que realmente incomoda no dia a dia.

Um exemplo rápido de um LDJ:

Phoebe’s Game.mp4

Design Sprint e Design Thinking

Neste momento, os influenciadores de produtos, caem pra trás por eu estar colocando as duas técnicas juntas, porém os “outcomes”, as saídas, são muito parecidas. Ambas tem como foco Imersão, Ideação, Prototipação e Realização.

Minha maior experiência se concentra na Design Sprint, então colocá-las no mesmo balaio, pode ser desconhecimento. Porém vamos aos links com mais detalhes.

Design Sprint: saiba o que é e como aplicar em produtos digitais

Modelo oficial para Sprint de Design de 5 dias para times | Miro

Esse modelo do Miro é excelente.

Entenda o conceito de design thinking e como aplicá-lo aos negócios – Sebrae

Design Thinking: o que é, como aplicar e as principais etapas

Então resumindo os pontos aqui da Design Sprint:

• 1º dia – Entender o problema e mostrar tudo que se tem de informações daquele problema;
• 2º dia – Rascunhar o que puder sobre o problema, levantar hipóteses e trocar ideias;
• 3º dia – Filtrar as ideias e decidir qual das hipóteses será levada pra frente;
• 4º dia – Prototipar. Seja desenhando em papel, seja fazendo telas, o importante é tangibilizar as ideias;
• 5º dia – Testar. É o dia de mostrar o protótipo para os clientes, seja interno ou externos e validar as ideias.

Hora de apresentar

Em todas as técnicas, e em qualquer ação de entendimento de problemas e hipóteses, é extremamente importante quantificar os resultados e apresentar esses resultados para quem consome isso, seja o cliente interno, sejam clientes externos.

Por vezes, o processo de Discovery é ignorado ou mal visto, pois os resultados não são apresentados. Então tenha ciência de uma das etapas é apresentar.

• Simplifique a apresentação. Não precisa criar apresentações super elaboradas, com pirofagia e efeitos especiais. Foque no resultado;
• Crie uma ligação com o seu time e com seus clientes. Inclua-os nos processos e testes sempre que possível;
• Conte sobre o processo que você utilizou e como tudo foi feito. Caso seja necessário, mostre o processo psicológico associado aquele método;
• Apresente as evidências que foram levantadas;
• Tenha uma análise pronta, em cima das evidências apresentadas. Lembre do que comentei ali em cima. O Discovery só tem sentido, quando há alguma evolução no assunto, seja diminuir as dúvidas, seja surgir novas dúvidas para serem sanadas;
• Tome uma decisão em conjunto com seu cliente, com seu time. Saia dessa apresentação com próximas etapas definidas. Isso ajuda demais a adicionar valo ao nosso trabalho.

É hora da revisão

Tratamos aqui de assuntos como, quando não fazer um discovery e quando fazê-lo. Vimos que existem técnicas e métodos que ajudam a diminuir as incertezas, sem a necessidade de um discovery.

Vimos também como fugir da armadilha de tornar o discovery um processo burocrático no nosso dia a dia.

Mostrei algumas técnicas usadas para Discovery, muito baseado na minha experiência e literatura.

Vimos também que é importante mostrar os resultados.

Por fim dois pontos importantes que levo pro meu dia a dia:

Cultura é muito importante. É necessário que a empresa que você trabalha tenha e permita ter uma cultura de descoberta das coisas. Não dá pra viver somente de Job to be done.

PO ou PM não decidem negócios. Polêmica essa frase, mas nosso trabalho é com o produto, não os rumos do negócio. Estamos intrinsecamente ligados, mas nós não decidimos o negócio.

Bibliografia

Este material de mentoria não estaria organizado desta forma, se não fosse o artigo do Ivonika. A linha de pensamento montada por ele no link abaixo, me ajudou a organizar as milhões de ideias sobre o assunto e principalmente a entender que não era só eu que achava que Discovery não era bala de prata do PM.

Product Discovery: O Que É, Quando não fazer e Como Fazer

Abaixo, vários outros links usados na mentoria que aplico. Vocês vão perceber que existem links de diversas escolas. No momento, tenho recomendado bastante a Tera, pois eles tem se preocupado em mostrar a realidade de produtos e não o mundo utópico. E olha que não tem nenhum patrocínio pra isso aqui.

discovery| gere insights de mercado e descubra novas oportunidades

Discovery

Product Discovery: o que é, importância e como fazer

O que é Product Discovery e quais são as principais etapas | UDS

Product Discovery: o Guia Completo para criação de produtos digitais

Hypothesis Template – The Hypothesis Prioritization Canvas

O que é Product Discovery e qual a sua importância para os negócios?

Matriz CSD: o que é e como usar (mais template!)

Entenda, de fato, o que é o design thinking? | Alura

Double Diamond: o que é e como usar essa metodologia do Design Thinking

Dot Voting: A Simple Decision-Making and Prioritizing Technique in UX

Literatura que indico

Abaixo coloco duas outras páginas com literatura que venho consumindo. A curadoria desse material tem os créditos do Thiago Aragão em uma das páginas e do curso da BBI Chicago, onde tenho feito a Pós.