Tenho certeza que se você está na fase de transição de carreira ou iniciou agora pouco na área de produto, já ouviu falar muito em Discovery. Há quem diga, inclusive, que você ganha muitos pontos ao falar sobre Discovery em entrevistas haha.
Mas na prática, essa palavrinha pode te dar muita dor de cabeça, principalmente se estiver iniciando.
Então vou simplificar ao máximo, certo?
Bem, a tradução literal de Discovery é Descoberta. E como isso se encaixa no cenário de produto? Então, quando falamos de Discovery nesse contexto, nos referimos ao processo de descoberta para mitigar riscos de viabilidade, valor, usabilidade e negócio.
Em outras palavras, é um processo para verificar se o produto é viável tecnicamente, se entrega valor ao usuário a ponto dele pagar por isso, se ele vai saber como utilizar e ainda, se vai gerar valor ao negócio.
Afinal, imagine só, seu time pensar em uma solução incrível, gastar tempo e recursos, para no final, nenhum usuário pagar por isso ou qualquer outro cenário descrito acima.
Entendido isso, surgem outros questionamentos, como por exemplo: Qual framework utilizar para o discovery? É preciso fazer discovery para tudo, produtos e funcionalidades? Como saber que o discovery é suficiente para partir para o delivery?
Sinto dizer que, as respostas exatas para essas perguntas você não irá encontrar em nenhum livro ou muito menos em algum curso. Algumas respostas você só terá com o skin the game, ou seja, com experiência mesmo, através dos erros e acertos cometidos durante sua jornada. Acredito que seja por isso, que uma das respostas preferidas dos Product Managers é “Depende”.
Mas calma, para esse primeiro momento, vou responder essas perguntas com base no que vivi até agora, para ajudar na sua trajetória e espero que em breve, você encontre suas próprias respostas.
Qual framework utilizar para o discovery?
Se você está estudando ou já atua na área, sabe que existem milhares de frameworks, e isso não é um facilitador, na verdade, pode te atrapalhar. Confesso que já teve um momento em que travei, porque não sabia qual framework utilizar, fiquei me perguntando qual seria o melhor para aquele cenário e acabei adiando o início do discovery.
Hoje, posso dizer que não existe um melhor, na verdade, existem vários e dependendo do cenário, um pode se encaixar perfeitamente e o outro não.
A mensagem que quero passar aqui é que, os frameworks foram feitos para ajudar e não para serem algum tipo de obstáculo. Pode ser que no seu contexto, no processo de discovery, você não utilize nenhum e “tá tudo bem” (alerta meme) .
É preciso fazer discovery para tudo, produtos e funcionalidades?
Essa é polêmica hein, inclusive, tem vários memes produteiros sobre esse assunto. Mas vamos lá! Para essa pergunta, gostaria que você retornasse ao início do texto e lesse novamente onde abordo a aplicação de discovery em produto.
E por que? Quando você entende que o objetivo do discovery é para mitigar os riscos, fica um pouco mais fácil lidar com isso no dia a dia.
Vou te dar um exemplo prático, identificamos que os usuários estavam com dúvidas para realizar um fluxo na plataforma, porém, tínhamos outras prioridades e para revê-lo, precisaríamos de um esforço alto. Decidimos fazer ajustes apenas no conteúdo do fluxo, o esforço era baixo, não precisaríamos de um discovery enorme, afinal, o risco também era baixo e ainda sim, estaríamos entregando valor, sem deixar de lado esse problema.
Então veja, não realizamos um discovery estruturado e demorado para isso, mas o fato de identificar essa dor dos usuários, faz parte do processo de descoberta. Calma, vou explicar melhor! Faz parte do nosso trabalho como Product Managers resolver problemas, mas para isso, é preciso focar muito mais no problema, na sua raiz, do que na solução (eu sei, ninguém aguenta mais essa frase clichê), por isso o continuos discovery é tão estimado.
Mas também faz parte do nosso trabalho priorizar e entregar resultados, isso significa que, se você tem um problema que não é tão crítico, não precisa investir um alto esforço ou utilizar mil frameworks com ele. Isso não é deixá-lo de lado, ok? É só lembrar do exemplo prático acima.
Resumindo, você não precisa de um super discovery para tudo, o delivery precisa rodar e com o tempo ficará um pouco mais confortável com essa situação, mas acredito que nunca 100%, incertezas também fazem parte do nosso trabalho.
Como saber se o discovery é suficiente para partir para o delivery?
Outra pergunta de ouro, e reforço que não existe resposta exata para essa e nem para as outras questões acima. Dito isso, me sinto muito confortável para dizer que dificilmente você fará esse handoff inteiramente convicto. E se tem alguém que faz isso tranquilamente, por favor, me apresenta, quero dicas (não contém ironia, quero conhecer mesmo essa pessoa).
Eu vi em um curso que a passagem entre essas etapas deve acontecer quando você não tiver mais o que aprender com o discovery. Claramente, eu discordo, afinal, se você continuar pesquisando e pesquisando, aprenderá sim coisas novas sobre aquele assunto.
Quem nunca identificou uma ponta solta quando já estava no delivery, que atire a primeira pedra.
Então, o que posso dizer sobre isso é que, com o tempo ficará mais confiante com esse processo, mas principalmente depois de ter errado e aprendido com isso. Não se cobre tanto, não tem receita de bolo, o importante é fazer funcionar.
Concluindo
Tem um milhão de temas e conteúdos sobre discovery, vale super a pena estudar e conhecer diversos pontos de vista. Mas tenha em mente que esses recursos devem lhe ajudar e não atrapalhar. Não tente forçar o encaixe do framework X da empresa Y no seu cenário, encaixe o que funciona para você, esse sim é o melhor framework. E o mais importante, discovery não é bala de prata!
