Programa de Continuous Discovery Poderoso: 6 Insights de Product Managers da Docusign, Linkedin e Zapier

Na nossa segunda roundtable de especialistas, tivemos o prazer de contar com três especialistas em product management com vasta experiência em gestão de produto e product discovery discutindo os segredos de construir um programa de continuous discovery.

Aqui estão os principais aprendizados desta discussão de alto nível sobre ouvir continuamente os clientes para tomar decisões de produto corretamente. 

1. Um programa de continuous discovery requer resultados claros, dados e colaboração coletiva

Ao pensar nos elementos-chave que tornam um programa de continuous discovery bem-sucedido, a primeira coisa a ter em mente é que, enquanto o product discovery é sobre usar dados para validar suposições de soluções para problemas, o continuous discovery é fazer isso constantemente para medir se você está no caminho certo ou não.

Segundo Lisa Orr, cuja formação é em data science, o continuous product discovery nada mais é do que "reunir evidências e fazer perguntas profundas sobre se você está no caminho certo ou não". Para que isso aconteça, é obrigatório que você tenha uma definição clara de sucesso e que empodere os seus times de produto com acesso a dados que vão te ajudar a medir os critérios.

Depois de reforçar a importância dos dados para o discovery, Naren Raghavan acrescentou que é crítico reconhecer que o discovery vai além do produto: você precisa envolver design, engenharia, marketing, vendas e todos na organização em algum nível. Segundo ele, "se você juntar essas duas peças, é aí que você pode realmente começar a pensar em um programa de Discovery e construir em cima disso".

Shyvee acrescentou dizendo que, para ela, o aspecto de continuous discovery é na verdade sobre continuar a construir aquela convicção de "ok, estamos seguindo pelo caminho certo e resolvendo o problema certo. É um exercício de construção de convicção e confiança no qual você fica checando continuamente".

2. Continuous discovery é como se exercitar: precisa virar parte da sua rotina

Um dos aspectos centrais de um programa de continuous discovery é garantir que você realmente o torne iterativo. A premissa é que as necessidades dos seus usuários estão sempre evoluindo e o seu produto também deveria evoluir, e isso requer uma revisão constante dos seus objetivos, dos seus resultados, do que os usuários esperam e de como eles se sentem a respeito. 

O erro mais comum que as empresas cometem é não transformar o continuous discovery em uma rotina dentro da organização — torná-lo realmente parte do processo. O que acontece é que, quando elas ficam ocupadas com outra coisa, param o processo de discovery e só voltam a ele quando têm uma nova ideia para validar. 

A chave aqui é, segundo Shyvee Shi, fazer do discovery um verdadeiro hábito — quase como se exercitar: "Conseguir, de forma contínua, entender o que está acontecendo é um novo músculo que você precisa exercitar, e isso exige muita energia de ativação. É definitivamente mais fácil falar do que fazer". Isso é especialmente verdade em um contexto como o de hoje, em que tudo muda tão rápido e em que as empresas têm recursos e tempo limitados.

3. Ter um repositório de feedback do usuário é indispensável em um programa de continuous discovery

Para construir hábitos de continuous discovery, um time de produto precisa definir alguns hábitos fundamentais que vão além da sugestão de "entrevistar usuários toda semana" de Teresa Torres. Uma coisa é documentar pesquisas de UX e entrevistas para construir uma biblioteca de conhecimento que possa ser usada depois por times atuais e futuros. "Toda vez que você faz o onboarding de alguém, ainda há algum nível de curva de aprendizado, mas acho que a documentação é o hábito número um do ponto de vista de processo", disse Shi. 

Mas vai além disso: existe uma diferença entre os dados e os insights que você obtém dos dados, e você deveria ter acesso a ambos. Todos os palestrantes concordaram que documentar e centralizar os insights de uma conversa é importante, mas pessoas diferentes podem chegar a conclusões diferentes ao olhar para os mesmos dados de formas ou momentos diferentes; elas podem usá-los para novas análises, para validar rapidamente novas ideias, para fazer alguma exploração adicional ou até para obter a evidência de que precisam para justificar uma descoberta ou decisão. 

Naren recomenda que os times tenham um feedback river centralizado onde você pode fazer anotações e compartilhar insights, mas também ter acesso aos dados brutos de forma organizada: "ter todos os dados em um só lugar onde as pessoas podem vir acessar torna a curva de aprendizado muito mais fácil, mas a parte bonita disso é que pessoas diferentes podem chegar a conclusões diferentes usando os mesmos dados". 

A necessidade de dados e documentação de feedback do usuário é ainda maior em culturas de discovery mais maduras, pois ter evidências será exigido pela liderança em algum momento e será naturalmente usado pelos times de produto quando quiserem defender algo que colocaram no roadmap.

4. Programas de continuous discovery bem-sucedidos usam dados para reduzir a incerteza sem perder velocidade

Segundo Tim Herbig, Product Discovery é sobre ter dados para reduzir a incerteza ao tomar decisões. Embora não seja um processo linear, também não é algo que te dá o direito de gastar todo o tempo que quiser nele, já que é provável que seja impossível eliminar a incerteza. 

Quando perguntada sobre qual é o momento certo de avançar para o estágio de priorização, Lisa respondeu que é quando você tem a confiança de que cobriu o risco que identificou — esse é um fator realmente importante. Ela mencionou um exemplo de passaportes de COVID, dizendo que "é tudo sobre se você atingiu a massa crítica em cobrir as suposições arriscadas importantes e, sabe, especialmente com um produto novo em que o time-to-market é tão crítico, você não pode gastar tempo demais em Discovery antes de fazer a sua primeira aposta".

Naren acrescentou que há muito julgamento e intuição de produto envolvidos também para definir quão grande um discovery deve ser, pois nem sempre você tem tempo de rodar um processo completo. Para ele, quando uma hipótese é uma decisão reversível, então você pode se mover mais rápido e fazer isso um pouco mais rapidamente. É aí que ter dados disponíveis para te apoiar pode ser útil: "pense nisso como um intervalo de confiança — você precisa ser capaz de tomar uma decisão confiante e, se você tem dados e feedback de usuário suficientes para tomar essa decisão e justificá-la e comunicá-la a todos os seus stakeholders, você deveria conseguir fazê-lo".

Para Shyvee, olhar para padrões e tendências nos dados é crítico. Na maioria das vezes, os insights não serão completamente novos e provavelmente reforçarão algo que você descobriu antes, o que é ótimo e mostra que você fez um bom trabalho, e talvez 20% serão algo novo que você pode explorar. Mas ainda precisa ser contínuo para que você consiga identificar quando isso acontece: "fazemos calls mensais revisando os tickets de suporte para que possamos sempre sobrepor, tipo, o que está mudando do período passado para este período, para entender constantemente o que está acontecendo".

5. Não fique preso na armadilha da complexidade

Um dos riscos significativos com esse processo é tentar colocar um processo perfeito em prática desde o primeiro dia. A melhor forma de começar é voltar aos primeiros princípios e mostrar às pessoas a importância dos dados e como uma decisão orientada por dados pode te trazer os resultados que você quer. 

A sugestão de Naren é escolher um projeto pequeno para começar de forma enxuta e mostrar algumas vitórias rapidamente: "você não quer dizer que algo só é valioso se você tiver cada pedaço de informação para juntar tudo e contar uma história, porque aí você vai entrar em paralisia por análise". Ele recomenda que os times implementem algo e obtenham alguns dados para construir a partir daí, para então mostrar como esses dados permitiram tomar uma decisão melhor, e assim começar a encontrar as novas fontes de dados de que precisam e construir incrementalmente a partir disso.

Somando a isso, Shyvee reforçou que continuous discovery é uma forma de validar e aprender o máximo e o mais rápido possível, o que pode ser diferente em estágios iniciais versus produtos mais maduros. Ela retomou a importância de construir a disciplina de agregar todas as diferentes coisas que você ouve do campo para apoiar as suas decisões, exemplificando que "conseguir quantificar coisas como 100 casos de suporte relacionados à funcionalidade A versus 75 relacionados à funcionalidade A, para que você não se enviese pela recenticidade. Ou se um grande cliente diz algo, mas, se você olha os dados históricos, apenas cinco clientes mencionaram aquilo".

Lisa complementou dizendo: "eu sempre vou mirar na ação em vez de esperar um pouco mais para validar mais". Para ela, combinar dados de comportamento do usuário com feedback qualitativo é uma peça importante no processo de olhar para a sua métrica North Star e criar a sua própria árvore de métricas para te ajudar a provar o valor do que você está fazendo. Para isso, ela sugere o que chama de um exercício divertido, que é concordar sobre quais métricas de produto vão impactar uma métrica da empresa, como a receita: "quando você consegue concordar que, se mexermos nesta alavanca, ela vai gerar potencialmente esta quantidade de receita, então você consegue muito entusiasmo da liderança e dos colegas product managers a seu favor". Ela também acrescenta que ter a evidência de que "não só estou deixando um cliente feliz, estou deixando-o feliz e gerando receita para a empresa inteira" é um resultado ideal de um ótimo programa de continuous discovery. 

6. UX Researchers devem apoiar o seu programa de product discovery

Nem toda organização tem o privilégio de ter um time de UX Research para ajudá-la a fazer product discovery, mas elas deveriam estar atentas ao risco de sobreposição de funções quando isso acontece. Um risco ainda pior é ter UX como o único time falando com os clientes e alimentando Produto com a sua interpretação ou insights da conversa. 

Uma sugestão para evitar o problema de ter dois times fazendo coisas semelhantes, que veio de Lisa, foi dividir as coisas. No caso dela, eles tinham o trio de produto focado no curto prazo enquanto a pesquisa de UX foca nas grandes questões: "temos essa visão de para onde estamos indo e ela está atacando as grandes questões arriscadas sobre isso. Ela até recorre a ir ao mercado tentando falar com pessoas que experimentaram soluções na direção que estamos buscando". 

Para Shyvee, a pesquisa de usuário vem em duas formas principais: pesquisa fundacional, explorando a jornada do usuário, os jobs to be done e o mercado, e estudos de usabilidade, em que ter as habilidades para fazer as perguntas certas é essencial.

Se você quiser se aprofundar, pode ver a gravação completa. E se você está pronto para construir um programa de discovery baseado em evidências de todas as fontes de feedback do usuário, visite a nossa página de produto.