Product Discovery.

A essência do trabalho de uma PM.

***

TL;DR

Processo que eu busco seguir para product discovery, com sugestão de stakeholders a envolver:

1- Objetivo da empresa/área: C-level, diretoria, empresa toda…

2- Problemas e potenciais soluções para eles: cliente, customer success e suporte, o squad (design e engenharia) e outros PMs da empresa.

3- Priorização de um problema e de uma potencial solução: squad (design e engenharia).

4- Processo de mitigar riscos: cliente, product marketing, vendas, jurídico, financeiro e parcerias.

5- Desenhar solução/protótipo: designers.

6- Validar hipótese com usuário: cliente e designers.

7- Construir e entregar pro mundão: squad (design e engenharia) e praticamente todo mundo da etapa de mitigar riscos.

***

Desde quando comecei a estudar e trabalhar com produto, sempre me chamou a atenção como, ao mesmo tempo que o product discovery é o centro das atribuições de alguém de produto, também há tanta discussão, dúvidas, incertezas e variações sobre o tema. Me lembro de várias vezes, no início, tentar achar um material robusto (e direto) que me falasse o que é e me desse um passo a passo para o discovery, mas tive dificuldade com isso. Não devo estar sozinha, pois o tema é assunto para dezenas de eventos, podcasts, meetups e por aí vai.

Para mim, o que é parece bem simples (apesar dos diferentes "autores" trazerem vieses levemente diferentes), ainda mais após alguns anos trabalhando com produto. Minha definição preferida é a forma como a Teresa Torres coloca o tema:

It’s all the decisions around what should we build next.

O que talvez gere uma maior incerteza na galera é o como fazer: passos, processos, práticas, atividades, frameworks, ferramentas, etc. Isso porque, de fato, existem muitas formas diferentes de estruturar esse processo. Muitos frameworks que podemos aplicar. Dessa forma, imagino que cada um deva ir testando e encontrando como prefere estruturar esse seu processo. Inclusive cada contexto de cada empresa vai pedir um exercício adaptado.

Particularmente, eu tenho a necessidade de estruturar um processo que possa me guiar em meu trabalho. E por isso, ao longo do tempo, fui documentando a forma de trabalhar que melhor funciona para mim em termos de product discovery. Longe de mim propor aqui algo que seria o "ideal para todo mundo", mas penso que talvez compartilhar essa minha documentação possa ajudar alguém que, assim como eu lá no início, se sente um pouco perdido.

Também lembro que nada disso é "de minha autoria". É só um compilado de práticas e frameworks já existentes em uma estrutura/ordem que funciona e é clara para mim.

Dito isso, vamos ao processo de discovery!

O meu, pelo menos. Até que mude, hehehe. Seguindo a linha deste post, vou usar a estrutura de uma talk que dei sobre o tema para guiar o texto a seguir.

A palestra era bem focada em stakeholders a envolver em um processo de discovery, então vamos falar disso também por tabela.

Comecei falando um pouco do discovery em si, ressaltando que é a atividade central da atribuição do produteiro, ou deveria ser. Nesse post falo um pouco sobre a distribuição que eu imagino ser a ideal para o nosso tempo, e lá também ressalto essa como a primeira tarefa da lista. Caso você não esteja conseguindo dedicar a maior parte do seu tempo para o discovery, minha sugestão é repensar se não há uma forma de reorganizar as suas atribuições ou agenda.

OK, mas o que é, de fato? Aqui, uso a mesma ideia da Teresa que citei lá em cima para explicar.

De forma bem resumida, estamos lá para identificar a melhor direção (viável) na qual o produto deve evoluir para seguir mantendo e conquistando mercado e representando um modelo de negócio sustentável. Também de forma resumida, isso é feito por meio de discovery e de delivery em produto: a todo tempo, precisamos descobrir/definir/refinar/validar boas apostas para que sejam construídas, e dar o apoio à construção para que saiam da forma mais adequada ao propósito ali em negrito. Ou seja, vamos focar no primeiro desses dois pontos. E eu gosto de uma organização de processos:

Esse é um passo a passo que organizei para o meu processo particular de discovery. Como falei mais para cima, você encontra isso na fala de vários autores/fontes/frameworks, mas organizei em itens para facilitar pra mim. Rapidamente sobre cada passo:

1- Todo processo de discovery deve iniciar com o foco em um problema maior que queremos resolver. Geralmente, isso é o objetivo atual da empresa em que trabalhamos. Vai ter empresa que está com o foco em redução de churn, outra que está em momento de aumento da base de clientes, receita, expansão internacional, etc. Não faz sentido nenhum que as decisões em produto naveguem numa direção diferente dessa, então esse deve ser o norteador aqui também. Como isso muda (ou deveria!) com uma frequência mais baixa, não é algo que precise ser revisado a todo momento, mas sim mantido em mente.

2- Bom, a partir desse problema macro, conseguimos quebrar em problemas micro. Aqui tem gente que gosta da palavra oportunidade, mas eu gosto de problema, mesmo. Então, pegando um exemplo da lista acima e jogando possibilidades para um cenário hipotético de um produto: digamos que o objetivo maior do momento seja a redução de churn. Precisamos identificar o que o está causando. Esses são os problemas micro. Pode ser que o produto (ou parte dele) é muito difícil de usar e as pessoas eventualmente desistem dele. Pode ser que a pessoa ache muito fácil de usar, mas tem alguma coisa que a atrapalha bem no momento em que ela obteria o ganho que busca com aquele produto. Etc.

E então, pegamos cada problema micro e quebramos em várias potenciais soluções. No exemplo da dificuldade de usar, poderíamos ter uma hipótese de redução de passos para uma determinada tarefa, por exemplo. Ou a visualização diferente de uma informação X. Por aí vai.

Mas nada disso sai da cartola do PM. Esse mapeamento deve estar pautado primordialmente em insumos que você vai captar dos usuários/clientes. Por isso defendo tanto mantermos papos abertos com clientes o tempo todo, em vez de apenas papos voltados já à mitigação de risco de uma hipótese Y. Mas falo sobre isso mais pra frente.

Uma ótima estrutura para organizar esses pontos é a árvore de oportunidades.

3- Agora que temos essa estrutura pronta, precisamos priorizar qual "micro-problema" vamos começar olhando, e qual potencial solução para ele.

De novo, a PM que fala constantemente com seu cliente já tem bons insumos para isso, e técnicas de priorização também podem ajudar aqui. Mas mais pra frente falo como também envolver o time nessa etapa é importante.

4- Beleza, agora é pegar a hipótese selecionada e mitigar seus riscos.

5- Para boa parte dos riscos envolvidos, protótipos de soluções podem ajudar nessa avaliação.

6- Ao validarmos esses desenhos de solução com os usuários, fechamos esse ciclo e podemos priorizar para desenvolvimento com mais segurança.

7- Agora, o squad "só" precisa construir e entregar para o mundão.

Não vou me alongar aqui, porque fiz outro post sobre isso. Mas basicamente, o recado é que muitas pessoas fazem esse processo completo inicialmente, e depois ficam eternamente presas do 3 ao 7. Não revisitam muito o 1 e o 2. Claro que o 1, como falei, muda menos, mas o 2, minha gente, muda o tempo todo. O ideal é, em paralelo a selecionar hipóteses e mitigar seus riscos, estar sempre revendo se não há problemas diferentes/maiores que podem ser resolvidos na busca do grande objetivo do passo 1.

Mas calma, você não está sozinha!

Agora vamos passar cada passo para falar um pouco sobre quem podemos envolver para um discovery mais certeiro.

No primeiro passo, não há muito mistério. As definições mais amplas da empresa geralmente partem de diretoria, executivos, C-level, etc. Por ser uma posição que está constantemente olhando para mercado e para cliente, produto pode colaborar muito nessa definição, se houver espaço para isso. No entanto, são diretrizes que permeiam a empresa inteira, e não serão estabelecidas pelo PM sozinho.

Para o passo 2, conforme spoiler lá de cima, o cliente é quem pode trazer mais insumos. Não devemos esperar que essa pessoa traga uma listinha de como atingir o objetivo macro da empresa, mas sim, devemos conversar com ela para, a partir das percepções dela com o produto, identificarmos principais gargalos que nos impedem de estarmos em dia com o norteador do ponto 1.

Sempre brinco que falar com um customer success/gerente de conta/atendimento/suporte equivale a falar com vários clientes de uma vez só. São pessoas que estão em contato com dezenas de clientes o tempo todo, podendo acrescentar muito ao nosso mapa de principais dores e potenciais soluções.

São duas as formas de envolver o time aqui. Primeiro no próprio mapeamento dos problemas e hipóteses de solução, porque todos estão dentro do mesmo contexto, e podem colaborar. E segundo, nos papos com os clientes, porque faz toda a diferença escutar sobre uma dor direto da boca do usuário.

Nem sempre esse segundo ponto é possível, porque cada um está focado na sua própria parte da equação do produto, então o que faço muitas vezes é trazer prints de conversas ou recortes de partes chave de um vídeo de entrevista para compartilhar com o squad.

Por fim, a dica é envolver outras pessoas de produto da empresa. Elas também trazem um olhar de produto sobre a questão, porém estão livres de vieses que muitas vezes temos por estarmos muito imersos na nossa feature, o que ajuda a enxergar com maior clareza a fotografia mais atualizada sobre oportunidades e soluções em potencial.

Como já citei, aqui podemos contar com todos os insumos que já temos como PM, e também com técnicas de priorização consolidadas no mercado. No entanto, há duas principais razões para também envolver o time nessa etapa. A primeira é porque o balanço entre esforço para construir algo e valor entregue ao cliente com esse algo ajuda bastante na decisão de priorização, e essa visão de esforço precisa vir do time todo. E a segunda é bem simples: quando todos estão bem envolvidos nesse processo, há mais engajamento para os passos seguintes de mitigação de risco e, potencialmente, construção da solução.

Creio que não preciso me estender aqui, mas depois que temos um objeto de estudo estipulado, papos direcionados sobre o tema com os usuários nos ajudam a entender se realmente aquela hipótese ajuda a solucionar o problema micro escolhido (que, por sua vez, ajuda a resolver o problema macro). O grande foco aqui é identificar se o cliente vê valor no que está sendo estudado. Além disso, aproveitamos para pegar insights para o desenho da solução que vem a seguir.

Mas não é só o cliente quem pode ajudar a mitigar riscos. Product marketing, se a sua empresa tem a sorte de contar com essa área, pode te ajudar a entender se aquilo que está sendo pensado está de acordo com o posicionamento da empresa perante o mercado, e se não teremos surpresas desagradáveis mais para frente ao tentar levar a mercado um produto/feature com algum tipo de particularidade negativa para o contexto da empresa.

Seja lá o que você estiver pensando em lançar, alguém terá que vender. E não será você. Então tenha certeza de que a empresa conta com um time de vendas compatível e que suporta a venda da soluções pensada por produto.

Talvez a recente discussão da LGPD (e a não tão recente, de GDPR) tenha aberto mais os olhos de produteiros quanto a isso, mas é sempre importante já pensar sobre potenciais fragilidades que uma solução possa ter perante legislações/regulações nessa hora. Antes de parar o time para construir algo, entenda se esse algo não fere nenhuma lei, ou se alguns detalhes da solução não precisam ser previstos de acordo com uma política Z.

Em alguns casos, consultar o financeiro pode ser indicado nessa etapa do processo. Para features que demandam, por exemplo, a contratação de um fornecedor para viabilizá-la, e/ou um pagamento adicional para que o usuário possa usufruir dela, precisamos entender, basicamente, como fazer a conta fechar (e, se ela não fechar, você quer descobrir isso agora).

Por fim, temos sempre que lembrar de sair da bolha da "PM+seus usuários", e pensar na empresa/negócio como um todo. Por vezes, principalmente em empresas maiores, a companhia conta com parcerias com as quais podemos conflitar com determinadas proposições em produto, e é isso que queremos evitar aqui.

Ufa! Uma vez que tiramos boa parte dos riscos da nossa frente, um protótipo ajuda a finalizar essa etapa, principalmente quando falamos de risco de usabilidade. Alguns PMs possuem skills para isso, mas costumo contar com a pessoa de design do meu time nesse ponto.

O cliente já trouxe insumos, lá no início, para que você identificasse principais caminhos para resolver seu problema macro. Depois, ele ajudou a mitigar os riscos de seguir por um determinado caminho. Agora, ele irá olhar para a solução proposta e ver se, na vida real, essa linha de raciocínio se sustenta. Em outras palavras, se a pessoa consegue usar o que está sendo proposto, e se ela acredita que, por usar isso, estará mais próxima daquele cenário que almejamos no ponto 1 do processo.

Da mesma forma como a designer pode ajudar muito no processo de construção do protótipo, essa profissional é expert em testá-lo com o usuário. Mas não terceirize nada integralmente no seu discovery: esteja junto nos testes e pegue todos as percepções junto ao cliente.

Se chegarmos até aqui com tudo validado, bora construir e entregar para o mercado! Aqui o time de engenharia é o principal envolvido, mas PM e designer também dão suporte ao delivery. Depois, é hora de vendas vender, marketing divulgar, e assim por diante, sempre contando com o apoio do gerente de produto para esse go-to-market.

***

Sem mais delongas, lembro que nem todo o discovery será assim. Às vezes não teremos tempo para tudo isso. Às vezes as pessoas com as quais será necessário mitigarmos riscos vão variar. Às vezes nem todas essas etapas são necessárias ou ocorrerão exatamente assim. Esse guia serve como um apoio geral para mim, para organizar meu raciocínio na busca de um produto cada vez melhor, mas é levemente adaptado dependendo do momento em que estou. Espero que possa te ajudar também!

Happy discovery!