Meus primeiros 30 dias de Continuous Discovery

Desde o lançamento do livro da Teresa Torres, o método vêm sendo muito discutido na área de Produto. Conto como foram os primeiros 30 dias usando no meu time.

Para 2022, o objetivo da minha squad passou a ser a expansão de ofertas de produtos, e por ser um desafio com inúmeras possibilidades, comecei a perceber que precisaríamos de um método de discovery que estivesse mais próximo do cliente e trouxesse respostas rápidas.

Com isso em mente, gastei meu fim de dezembro buscando um modelo que poderia nos ajudar, e quando li o Continuous Discovery Habits (resenha aqui), enxerguei como uma boa possibilidade para experimentarmos.

Mas, eu tinha alguns receios.

O principal foi que achei poucas referências parecidas com o meu desafio que tivessem usado o Continuous Discovery. Essa inclusive foi minha motivação para escrever esse artigo: trazer algum case de startups brasileiras pra mesa. Fiquei um pouco perdida de como seria a rotina, porque o livro entra muito no detalhe do que fazer, mas o como fica na mão do leitor.

Também tinha receio sobre o impacto das reuniões nas nossas agendas. Não tínhamos noção de qual seria a duração ideal para as entrevistas, e nem se haveria alguma queda no ritmo do delivery, considerando que nosso Tech Lead teria um papel bem mais ativo no discovery agora.

Minha última dúvida era sobre o “pós-conversa”. Beleza, falamos com os clientes, precisamos trabalhar enquanto product trio para mapear as necessidades dos usuários e gerar valor a partir dos insights. Mas como fazemos isso? Coloco alguma reunião recorrente? Aplico alguma dinâmica?

Felizmente, consegui as respostas para essas dúvidas nos primeiros 30 dias e vou compartilhar com vocês.

Preparação

Esses foram os passos que segui antes de começar com as entrevistas.

1. Criação da árvore de oportunidades
   Comecei definindo o resultado esperado e escrevendo as oportunidades que já tínhamos mapeado, seguindo o padrão que o livro apresenta (esse artigo explica). Como seguíamos um método que também usava o conceito de oportunidade, ficou mais fácil.
2. Definição dos gatilhos de recrutamento
   Uma dica valiosa do livro é contar com as outras áreas da empresa para o recrutamento dos entrevistados. Defini gatilhos objetivos para passar ao time de CS, CX e Vendas, para que eles pudessem agendar os papos toda vez que uma situação específica acontecesse. No nosso caso, um dos gatilhos era quando um cliente pedia uma funcionalidade nova.
3. Alinhamento com o product trio
   Achei melhor alinhar com o Designer e Tech Lead só depois de ter feito a árvore de oportunidades e os gatilhos de recrutamento, porque eles ainda não tinham tido contato com o Continuous Discovery, e achei que ter alguma coisa pronta facilitaria o entendimento. Também fiz um resumo do método e deixei no nosso Notion.
   Compartilhamos nossas visões e todos estavam dispostos a testar, e acho muito importante que o trio inteiro esteja, principalmente porque exige dedicação de tempo. Se alguém não estiver motivado, pode impactar o resultado.
4. Alinhamento com o time de produto
   No meu time, cada Product Manager tem bastante autonomia sobre a forma de trabalhar. Nós temos uma cultura bem estruturada e deixamos na mão das pessoas definirem um método que melhor atende seu desafio. Por isso, não tive o trabalho de convencer a área, apenas trouxe o racional por trás da decisão.
5. Alinhamento com as outras áreas
   Aqui, dividi em dois formatos de conversa. Para os líderes de Vendas e Marketing, que são mais interessados nos novos produtos que surgiriam a partir do processo de discovery, foquei em explicar os benefícios do método e principalmente alguns conceitos importantes (priorização por oportunidade, validação em entrevistas quali com pequena base de clientes). Já com CS, CX e a equipe de Vendas, expliquei a rotina de entrevistas e os gatilhos de recrutamento.

Agora, vamos falar dos 30 dias.

Recrutamento

Nas primeiras duas semanas, não tivemos dificuldades em conseguir clientes para as entrevistas. Criei um calendly em grupo que unia a minha agenda, do designer e Tech Lead, e as áreas marcavam por lá ou compartilhavam o link com o cliente. Depois das duas semanas, o assunto ficou mais esquecido e precisei entrar em uma daily dos times e reforçar o recrutamento. Meu aprendizado é que precisa ter um reforço constante pros outros times permanecerem engajados no processo.

Entrevistas

Como o gatilho do recrutamento era uma ação do cliente, levamos poucos bolos, porque as pessoas estavam interessadas em falar do pedido ou reclamação recente. Fizemos de 1 a 3 entrevistas por semana, e começamos com 20 minutos de duração. Achamos que 20 minutos realmente é o suficiente, e ainda nos dá 10 minutos para um debriefing sem impactar a agenda. Quanto à quantidade, funcionou bem pro que estávamos estudando no momento, mas entendemos que daria para fazer mais conversas sem impactar o resto do trabalho (chegar a 5, por exemplo).

Quando fazemos as entrevistas lá na etapa do problema, muita coisa não dá pra ser validada, porque ainda temos as regras do produto. Ao fazer as entrevistas regularmente, conseguimos separar o que realmente era uma grande dor ou necessidade do que o cliente só achava legal. Isso num nível muito mais micro das regras de negócio, como os status, por exemplo.

Dinâmica de trabalho

Pra mim, a parte mais importante para as entrevistas serem eficazes é ter um objetivo muito bem definido. É preciso que esteja claro o que queremos entender naquele momento.

Pra isso, tivemos a seguinte dinâmica na primeira semana:

Terça, 14h às 15h — Reunimos o product trio para conversar sobre o que gostaríamos de entender melhor e mapear as hipóteses.

Terça, 15h às 16h30 — Demos um tempo pra cada um pensar sozinho depois do papo.

Terça, 16h30 às 17h — Conversamos novamente e definimos o objetivo.

Quarta, 11h às 12h — Estruturamos melhor e nos preparamos pra primeira entrevista.

Quarta, 14h às 14h20 — Primeira entrevista.

Quinta, 11h às 11h30 — Conversamos sobre experimentos para testar as hipóteses.

Depois disso, não sentimos necessidade de ter novos papos, um debriefing de 10 minutos após as entrevistas já nos permitia compartilhar os insights e alinhar o que alteraríamos no desenho do produto. Também usamos bastante um canal só do product trio no slack para discutir as mudanças que cada um ia fazendo.

Experimentos

Teresa reforça também a cultura dos experimentos para complementar os insights das entrevistas, e pra gente funcionou bem essa dinâmica. Tínhamos um desafio de não ter ferramentas técnicas feitas para experimentos, então tivemos que improvisar com Amplitude e teste A/B do Firebase.

Depois das entrevistas, desenvolvíamos algumas hipóteses, que poderiam estar certas ou não. Vou contar um exemplo.

Mapeamos um caso que compras recorrentes impactariam uma regra de negócio importante na entrega de valor do produto, e a hipótese era que apesar da situação existir, poucas vezes aconteceria.

Decidimos fazer um experimento para metrificar o quanto as pessoas já usavam o produto para compras recorrentes. Se o número fosse baixo, o problema seria raro, então não precisaríamos priorizar uma solução naquele momento.

Colocamos um modal no app perguntando se as pessoas usavam o produto para assinaturas de serviços como Spotify e Netflix e usamos as tags do Amplitude nas opções de resposta. Fomos acompanhando os resultados e tiramos do ar depois de 5 horas, usando o recurso de teste A/B do Firebase. Descobrimos que 18% usavam, e com esse número, entendemos que o risco era aceitável e decidimos não priorizar o caso mapeado na primeira versão do produto.

Delivery

Na squad, não somos muito presos em processos pro delivery.

Encaixamos o início do Continuous Discovery com o período que o time estava terminando de desenvolver algumas demandas, e quando eles finalizaram, já tínhamos duas semanas de discovery rodando e contávamos com uma boa noção de qual seria a primeira versão do produto.

Conduzimos a planning passando por todas as histórias que eram prioritárias (gosto de deixar tudo bem dividido pra conseguir ter visibilidade) e fomos decidindo o que estava pronto para desenvolvimento — ou seja, as histórias que continham todas as informações necessárias pros devs.

O time conduziu outras conversas paralelas e criaram as tarefas. Nós não usamos estimativas, então não fizemos outra planning em conjunto, fomos acompanhando pelas dailys e pelo board.

O que entendemos que ainda precisava de mais informação ficou como objetivo para as próximas entrevistas, e fomos atualizando a squad dos resultados e mudanças pelas dailys. Quando já tínhamos evoluído bem com o desenvolvimento, definimos o cronograma de lançamento da versão beta e comecei o recrutamento de clientes.

Resultados

O maior diferencial que sentimos ao usar o Continuous Discovery foi ter mais confiança em despriorizar cenários que poderiam ser grandes problemas, mas que não tínhamos noção do quanto aconteceriam. É sempre aquela dúvida de: corner case ou uma ação que não mapeamos?

Ele também nos ajudou a enxugar o produto e deixá-lo mais simples, porque conseguíamos filtrar os recursos que achávamos que os clientes precisavam do que eles realmente precisavam.

E por último, um feedback do Tech Lead trouxe o insight mais importante pra gente. Quando apresentei o conceito de product trio, ele não estava vendo tanto valor em participar das entrevistas. Mas, quando começamos, ele percebeu que poderia aproveitar o discovery para ir pensando na solução técnica com mais tranquilidade, contexto e foco no real problema do cliente.

Com o Continuos Discovery, nossa planning foi bem mais profunda, mesmo durando só duas horas, porque ele já tinha passado semanas tendo ideias de como desenvolver.

Decidimos seguir com a dinâmica, e agora testando como ela vai funcionar num pós-implantação, mas animados com o processo.

Gostou, ficou com dúvidas ou quer só bater papo sobre o assunto? Estou disponível no Linkedin.