Bom Discovery, Melhor Discovery.

Quanto mais o tempo passa e conheço times de produtos, mais eu vejo Product Managers e Designers frustrados com a velha queixa de não terem tempo suficiente para Discovery.

“Eu queria ter mais tempo pra fazer Discovery” – Qualquer pessoa de produto, em qualquer empresa.

Quem me conhece sabe que tenho uma opinião um pouco polemica sobre como ter uma prática saudável de Discovery.

Vou tentar abstrair ao máximo os conceitos para que esse texto se aplique a qualquer pessoa que trabalhe em um time multidisciplinar de produto.

Discovery vs Research

O primeiro ponto de muita confusão é a falta de um entendimento claro do que as palavras Discovery e Research significam para você, seu time e sua empresa.

A definição que eu mais gosto de utilizar para tirar a ambiguidade desses termos são essas:

Discovery/descoberta é o processo contínuo de descoberta de oportunidades e riscos para apoiar sua priorização. O objetivo é definir qual a melhor oportunidade para perseguir em determinado momento e porque.

Research/pesquisa é o processo de investigação qualitativa e quantitativa para gerar insights e chegar a conclusões sobre determinado tema.

Ou seja, muitas vezes você precisa de algum método de pesquisa para chegar em melhores conclusões sobre um tema e fazer uma priorização mais assertiva.

Ocupado demais para fazer Discovery

Se você trabalha em um time de produto (ou próximo a algum time de produto) você já deve ter ouvido algumas queixas como: "não temos tempo suficiente para discovery" ou "a empresa onde eu trabalho não me dá espaço pra fazer discovery".

Sem tempo, irmão

Se você tem um papel de produto (Product Manager ou Product Designer) e "não tem tempo para fazer Discovery", você inevitavelmente vai iniciar um ciclo vicioso de nunca ter tempo.

Se você nunca tem tempo para Discovery, você está negligenciando grande parte do seu papel, que é garantir que seu time esteja perseguindo as oportunidades certas e que todos tenham contexto sobre os maiores riscos envolvidos no processo. Sejam eles riscos de negócio, de valor, de tecnologia ou de experiência.

Primeiro consistência, depois profundidade

Outro problema/questao/pratica que dificulta muito sair desse ciclo vicioso é a de sair de um extremo para outro, ou seja, de não ter nenhum hábito de Discovery para de repente precisar de um mês para aprofundar algum tema.

Foque inicialmente em ter algumas horas de Discovery por semana. Lembre que seus dias e semanas são os átomos da sua rotina, organizar bem sua semana tem um impacto gigante no seu mês, quarter e ano.

Você só vai conquistar mais tempo e espaço para processos de descoberta maiores quando tiver bons argumentos do porque determinado tema merece mais aprofundamento, tanto pelo potencial ou pelo risco que o tema representa para a empresa. Portanto, comece criando uma rotina saudável para tirar a cabeça de dentro d’água e ter o mínimo de tempo e espaço para criar bons racionais.

Discovery pé no chão

Outro ponto problema frequente é a busca incansável do processo de discovery que leve a melhor resposta possível para um determinado problema.

Na grande maioria das vezes você não precisa ter a melhor resposta para uma tomada de decisão, mas sim otimizar para tomar boas decisões constantemente.

Ter a expectativa de tomar sempre as melhores decisões demanda muito mais tempo e pode gerar um ambiente onde as pessoas tenham medo de errar, o que é extremamente prejudicial para times que precisam estar constantemente experimentando coisas novas.

A maior parte das decisões do dia a dia não são críticas e podem ser revisitadas em ciclos futuros. Então pense bem quais temas realmente precisam de mais aprofundamento para justificar um investimento de tempo maior.

Você não precisa de Discovery para tudo

Aqui o assunto fica mais polêmico. Eu vejo muitos times que se cobram para ter etapas de discovery mais robustas em todo novo ciclo de desenvolvimento, como se fosse uma etapa fixa e inegociável.

Como disse anteriormente, Discovery é um processo contínuo de entendimento sobre qual é a próxima grande oportunidade a ser perseguida e os riscos que ela representa, de ir gradualmente transformando grandes incertezas em pequenas hipóteses acionáveis.

Existem diferentes níveis de granularidade dessa descoberta. De entender o roadmap do próximo quarter até identificar desafios de uma feature específica que será entregue nas próximas sprints.

Você precisa usar o seu julgamento para saber a hora de aprofundar em algum tema ou de tomar uma boa decisão rapidamente e “aprender em produção”.

Aprendendo em produção

Eu compartilho muito da visão do Jason Fried sobre validação e user testing. Ao invés de tornar o ciclo de desenvolvimento de produto super burocrático e cheio de validações a fim de garantir que as melhores decisões estejam sendo tomadas, eu prefiro otimizar para ciclos mais rápidos de iteração, com o mínimo de validação possível e aprender em produção.

A melhor maneira de validar se seu time está no caminho certo é com o produto funcional na mão dos usuários.

Você pode tentar validar uma funcionalidade antecipadamente de diversas maneiras, mas só vai ter certeza do seu resultado quando ela estiver no seu contexto natural de uso.

É claro que testes de usabilidade e outros tipos de validação são bons meios de evitar erros grosseiros e garantir que a solução proposta está minimamente dentro do esperado, mas lembre-se sempre que a validação de fato só acontece em produção.

Você precisa ter consciência de quando é necessário investir mais tempo em validação e quando otimizar para aprendizado contínuo em produção.

Uma das principais características de um time de produto de alta performance é o quão rápido é seu ciclo de iteração da solução baseando-se em aprendizados de ciclos anteriores, e não quantas horas de discovery foram investidas durante o processo.

Quer fazer parte de um dos melhores times de Produto e Design do Brasil? Estamos com diversas vagas abertas no olist 💙