Discovery do discovery.
Ou, se isso for muito Inception para você, o pré-discovery.
TL;DR: product discovery não é só mitigar riscos de ideias, mas saber de quais ideias precisamos mitigar riscos (seja incluindo essa etapa sempre no início do discovery, seja fazendo isso em paralelo e constantemente).
Dia desses estava em um meetup organizado pela PM3, cujo tema era product discovery. Como já venho há algum tempo me questionando sobre um ponto específico acerca do tema, resolvi mandar a pergunta lá na plataforma de Q&A deles para ver a opinião dos participantes do painel. Era algo como:
Você acredita em discovery do discovery (ou pré-discovery)? O que alimenta a sua lista de candidatos a tema para o próximo product discovery?
Gostei bastante da resposta de uma das participantes (e concordo), que levantou que boa parte do que alimenta o “backlog do discovery” são as metas, objetivos, OKRs da empresa, árvore de oportunidades e por aí vai.
No entanto, apesar de serem, sim, aspectos que pautam bastante do que vamos descobrir e priorizar, humildemente acho que não basta. É que, geralmente, esses acabam sendo pontos meio estáticos e amplos demais. Mas vamos por partes e sigamos o raciocínio abaixo.
Mas primeiro, o Product Discovery em si
Talvez "o que é Product Discovery" soe um pouco básico para quem já trabalha com produto, mas dada a quantidade de eventos, palestras e cursos que continuam a surgir sobre o tema, talvez valha aqui um rápido recap.
O que a Teresa Torres acha (se você não viu esse vídeo do link, é imperdível — um resumo da evolução de product discovery + uma aulinha de árvore de oportunidades em 35 minutos):
Encompasses all the activities that we do to decide what to build. It's all the decisions around what should we build next. Is to learn earlier in the process. For product discovery, our goal is to learn fast. We wanna learn as quickly as possible if what we think we should build is the right thing to build.
O que o Marty Cagan acha (uma colagem, aqui, de várias frases do capítulo de discovery do livro "Inspired"):
We need to be able to test out many ideas, and we need to to this quickly and inexpensively. The purpose of product discovery is to make sure we have some evidence that when we ask the engineers to build a production-quality product, it won't be a wasted effort. If you want to discover great products, it really is essential that you get your ideas in front or real users and customers early and often. Product discovery is mostly about quickly trying out an ideia.
O que o Tim Herbig acha:
O que o Mixpanel acha:
Product discovery is a method of deeply understanding your customers to develop products that perfectly suit their needs. It’s a critical stage in the product design process because if companies do not accurately prove or disprove their assumptions about their customers, they may waste time building products that nobody needs.
E o que eu (com toda a humildade) acho:
Que tudo isso é inquestionavelmente importante, válido, enfim, é boa parte do que compõe o trabalho de uma PM. No entanto, tem um tempo que comecei a me questionar também sobre o que viria "antes" (ou, no início) do processo de discovery. Isso aconteceu principalmente quando mudei de empresa. Quando cheguei na Resultados Digitais, em setembro do ano passado, eu ainda tinha zero de contexto do produto, mercado, usuário, etc. Claro que herdei um backlog, uma árvore de oportunidades e muito material sobre o cenário do produto/feature/empresa do PM anterior e do restante do time. Mas pra mim não era suficiente. Eu queria ver com os meus próprios olhos o big picture, para me sentir confortável na escolha de qual seria meu primeiro discovery.
Não me entenda mal: há muitos processos de product discovery que compreendem etapas de definição de objetivos e descobertas de problemas/oportunidades/potenciais soluções antes de partir pro discovery de uma ideia. (A própria famosa árvore de oportunidades da Teresa Torres faz isso).
Mas vamos dar uma focada em detalhes das definições do povo ali de cima:
- Teresa: …is the right thing to build.
- Cagan: …quickly trying out an idea.
- Tim Herbig: …uncertainty around a problem or idea.
- Mixpanel: …prove or disprove their assumptions.
Podemos ver que as definições de product discovery acima, e também é o que eu escuto de muitos profissionais sobre o que é e como eles fazem esse processo, sempre partem do pressuposto que você já tem ideias/hipóteses/assumptions para validar — ou não — em um discovery. Que você já tem uma lista de coisas lá, e discovery é só priorizar e fazer entrevistas e levantar dados e fazer desk research e protótipos e testes sobre cada uma delas e é isso aí. Mas de onde vêm essas coisas, em primeiro lugar? Essa lista precisa ser alimentada. Revisitada.
Descobrir o que precisa ser descoberto é tão importante quanto descobrir. (Deu pra entender, né?) :)
Vejo muitas pessoas que entendem o processo de discovery acontecendo “da ideia adiante”. Definindo-o como algo que está entre a ideia e a solução/produto. Ou, mesmo que não seja o caso (tem muitas pessoas/metodologias que entendem, sim, “ definição de objetivos” + “mapeamentos de oportunidades/problemas/soluções” como parte do processo de discovery), na prática muitas vezes essas pessoas acabam fazendo muito esporadicamente a parte inicial, e concentrando seu trabalho de discovery nas etapas que se seguem à lista de potenciais soluções.
Temo que, se ficarmos presos em listas que já tínhamos de problemas a serem resolvidos e potenciais soluções, ou ainda a metas e OKRs estabelecidos, estaremos desatualizados sobre nosso próprio produto. A velocidade com que o mercado muda e com que o nosso usuário se frustra ou se limita com o nosso produto pode ser maior do que a nossa agilidade em revisitar nossa lista de hipóteses ou OKRs. Podemos estar lá desesperadamente testando coisa após coisa, mas coisas essas que podem já nem serem mais relevantes. Por isso, creio que precisamos ter um processo organizado que nos estimule, como PMs, a sempre estarmos atualizados nesse passo anterior e mais macro ao discovery (ou, o que seria talvez mais correto de pensar, nesse passo inicial das metodologias de discovery). A sempre revisarmos "a lista".
Em resumo, eu acredito que não basta rodarmos product discoveries específicos em cima de uma ideia. Em paralelo a eles (ou, pelo menos, frequentemente), precisamos rodar discoveries macro, focados unicamente em descobrirmos novos candidatos aos próximos discoveries micro (ou, até, em descobrirmos quais itens da lista já não fazem mais sentido e não precisam nem mais serem trabalhados).
Claro que todo PM eventualmente revisita essa "lista" de alguma forma, mas não tenho escutado falar sobre isso como um processo contínuo. E eu acho que deve ser. Eu, ao menos, preciso dele.
Para finalizar esse ponto sobre discovery, de forma bem direta, abaixo coloco os "passos" que eu acredito compreender um processo de product discovery:
1- Entender o objetivo macro que a empresa/área quer alcançar
2- Achar problemas que possam alavancar o ponto 1 ao serem resolvidos, e levantar/idear potenciais soluções para eles
3- Priorizar um problema e uma potencial solução
4- Mitigar risco dessa ideia (falar com cliente, levantar dados, etc.)
5- Desenhar a solução/protótipo
6- Testar e validar hipótese com usuário
7- Construir e entregar pro mundão
Aqui fica mais claro ainda de entender o ponto. Escuto muito do mercado falando em discovery como sendo algo "do ponto 3 para baixo". Para não esquecermos do 1 e do 2, poderíamos fazê-los a cada início de "novo discovery", ou com frequência determinada. Mas tenho pensado e tentado manter um processo paralelo, para manter o dinamismo da coisa.
Buenas, e como eu sugiro fazer isso? Algumas práticas que tenho procurado seguir abaixo. Estou apenas começando, mas está sendo muito legal!
Discovery do discovery
Poderíamos, toda vez que vamos começar um novo discovery, começar “do zero”, revisitando nosso objetivo macro e identificando potenciais problemas e soluções pra ele. Como já comentei, muitas vezes não é o que acontece, mas poderíamos. Essa seria uma das forma de fazer um “discovery do discovery”: simplesmente respeitando sempre as fases iniciais dele. Ou então, podemos tentar ficar sempre atualizados em nossa listinha de problemas e soluções em potencial, inserindo em nossa rotina práticas para tanto.
1- Manter papos com clientes/usuários apenas com esse propósito
(Um coisa que me incomoda um pouco quando fala-se sobre product discovery é que muitas pessoas acabam se limitando a, ou até usando como sinônimo de entrevista com usuários. Apesar disso ser, sim, o centro de um discovery — afinal, qual melhor forma de validar se alguém quer algo ou "que algo" ela pode querer do que conversando com esse alguém? — , há mais que isso, mas isso é assunto pra outro post).
Bom, feito o parênteses, ainda é uma das principais atividades do processo. Para garantir a cadência, sugiro manter agendas frequentes com clientes apenas para essa exploração inicial. Tenha um roteiro bem amplo, que inclua perguntas objetivando descobrir coisas como (1) pontos de dor com o produto atual, (2) como ela resolve esses problemas hoje, (3) o que faria a pessoa trocar pelo concorrente, (4) o que a faz não trocar pelo concorrente, (5) quais são os obstáculos que a impedem de obter o resultado esperado com o produto, etc.
Sim, isso geralmente significa uma agenda bem colorida e um PM bem organizado, porque em boa parte do tempo você terá rolando em paralelo esses papos mais amplos com alguns clientes, enquanto terá outros sobre o tema X do seu discovery atual específico.
2- Olho nos dados
Todos sabemos que uma outra forma de sabermos o que nossos usuários pensam e fazem é olhando os números. Eles transparecem comportamentos, e são um gatilho para criarmos hipóteses, identificarmos problemas, termos novas ideias de como melhorar a vida das pessoas com o nosso produto. E o que queremos com esse papo todo de "discovery do discovery" é justamente isso. Junte essa fagulha trazida pelos dados a papos com os clientes para entender melhor a situação, e temos uma grande fonte de atualização para nossa lista de candidatos à discovery micro.
Além disso, uma grande vantagem dos dados é o fator quantitativo. Os papos do ponto 1 são ótimos, mas corremos o risco de enviesarmos decisões por um recorte muito pequeno de usuários. O volume dos dados nos ajuda aqui.
3- Revise sua árvore de oportunidades com frequência
A árvore de oportunidades é uma representação mental criada pela Teresa Torres, que basicamente ilustra/esquematiza o processo de product discovery que ela sugere. O que é muito legal desse processo é que ele prevê etapas de descoberta de oportunidades para chegar no resultado (o que é justamente alimentar/atualizar "a lista" da qual tanto falo aqui).
Como já coloquei, o que vejo muito é isso sendo construído muito pontualmente, e depois o processo de product discovery se limitar, por um bom tempo, a mitigação de riscos das ideias de solução. Então a proposta aqui é simples: revisar com mais frequência a estrutura completa da árvore.
4- Fique de olho na concorrência
Todos sabemos: obcecar com a concorrência e sair fazendo tudo o que ela faz não é um bom jeito de gerenciar produto. No entanto, deve haver equilíbrio aqui. O que os competidores estão fazendo pode ser um bom cheiro de potenciais problemas que você também tem para resolver. Principalmente se você começar a ver um movimento de migração da sua base de clientes para "lá".
Manter o hábito de "dar uma fuçada" no produto do vizinho pode não tomar muito tempo, e trazer bastantes insights do que pode estar faltando na sua lista de problemas e potenciais soluções.
5- Converse com outras áreas da empresa
Pode ser um papo descontraído no almoço (projeto "uma reunião a menos" :P), uma agenda mais fixa, um e-mail, uma chamada no Slack, o que funcionar melhor. Conversar com product marketing, customer success/gerente de conta, suporte, jurídico, financeiro, etc. ajuda muito aqui.
Sonde sobre pontos substanciais de insatisfação do cliente, motivos mais frequentes para abertura de chamado/ticket, movimentações no mercado, mudanças de leis, e por aí vai. Muitas vezes só isso já ajuda a refrescar a mente sobre os pontos 1 de 2 (principalmente 2) que sugiro do processo de discovery.
***
Se pararmos para analisar, o que proponho se parece bastante com o que faríamos no que eu sugiro como passo 2 do discovery (levantamento de problemas e potenciais soluções). É isso mesmo. Só que em vez de ser feito toda santa vez que começo um discovery, ou de quase nunca ser feito (que é o que tenho percebido muito quando as pessoas falam de discovery), ele é um processo mais perene. Tá sempre aí.
Acalma o coração
Claro que, em geral, somos um único PM por squad. Como se já não bastasse discovery contínuo e apoio constante ao delivery, ainda vem alguém com essa ideia de "discovery do discovery" contínuo: entendo que você não esteja me amando nesse momento (vai que a moda pega). Calma. Cada PM precisa dosar as coisas à sua realidade. Até porque, a própria velocidade com que cada mercado de cada diferente produto muda difere muito — e isso é um dos fatores que ajuda a determinar a frequência com que você faz uma descoberta mais macro.
Além disso, o processo de "discovery do discovery" pode ser muito simplificado, para não atrapalhar o próprio discovery, mas ainda assim deixar o PM por dentro do cenário amplo. Eu mesma falei tudo isso e estou apenas começando. Mas acho que vale a pena! Seja fazendo sempre o discovery desde o início, ou inserindo práticas de atualização constante, o importante é não pirar em uma lista de soluções centenária, dizer que está fazendo discovery, e esquecer que o mundo muda.
