Meu principal aprendizado na área de produto: Esquece os modelos

Mapa de empatia, persona, jornada do usuário, mapa de impacto, business model canvas. São só alguns exemplos de modelos, templates e frameworks que você encontra quando começa a estudar product discovery. Muitos cursos e artigos falam sobre esses modelos, como preencher e porque são importantes. Estou escrevendo o artigo que eu queria ter lido quando eu comecei na área de produto. Esquece esses modelos, o coração de um bom gerenciamento de produtos não está neles.

O que é product discovery?

Para começar, preciso primeiro explicar o que é product discovery. O grande objetivo de discovery é aprender o mais rápido possível para reduzir riscos. Copiando Marty Cagan, os principais riscos são:

• Risco de valor/ desejabilidade: o cliente irá comprar ou escolherá usar essa solução?
• Risco de usabilidade: o cliente entenderá como utilizar essa solução?
• Risco de execução: temos capacidade para construir essa solução?
• Risco de viabilidade: Essa solução funciona para o nosso negócio?

Tem muitos exemplos de que esse risco é alto. Em uma pesquisa interna do Jim Jhonson ele mostrou que na empresa dele, 64% das funcionalidades que desenvolveram nunca ou quase nunca foram usadas pelos usuários. Então o que precisa ser feito para não gastar tanto tempo em coisa inútil?

Porque não começar com o modelo

Preencher o mapa da empatia, por exemplo, tem como objetivo você entender seu cliente. Mas exatamente nisso está minha frustração com o foco nos modelos: Isso realmente te ajuda a entender o cliente? Não estou falando que preencher um desses modelos não tem benefício nenhum. Eles ajudam com a organização dos seus pensamentos e conhecimentos, mas o perigo é preencher um modelo desse e achar que você está pronto. Ao contrário, provavelmente ele te dará uma sensação falsa de segurança.

Esquece os modelos por um tempo

(Minhas) regras de ouro

Então tá bom, os modelos não são por onde você deve começar, o que você deve fazer então? Vou listar para vocês algumas coisas que eu aprendi na prática durante os últimos anos. Basicamente todos têm a ver em conseguir responder uma única pergunta: “porque?”.

1. Entenda seu cliente

Não tem muito mistério em como fazer isso: você tem que falar com eles. Você não é seu cliente. Seu colega não é seu cliente. Fulano que por acaso passa na rua não é necessariamente seu cliente. A gente assume que a gente conhece o nosso cliente, mas a gente conhece mesmo? Se imaginar no lugar do outro não é suficiente e só confirma os seus próprios preconceitos enraizados. Você precisa falar com frequência com quem realmente é seu cliente (semanal é ideal de acordo com a Teresa Torres). Mesmo que pareça simples, na prática é muito trabalhoso. Dependendo do seu negócio (Edify por exemplo é B2B2C) custa bastante energia e planejamento para conseguir falar com seu cliente com uma frequência alta. Já te preparando, você vai tomar muito bolo. Além de você falar diretamente com seu cliente, falar com as pessoas que atendem os clientes diretamente e ler os registros de atendimento também podem gerar insights.

O que não fazer

2. Pergunte as coisas certas

Só falando com seu cliente você não está lá. Você precisa ativamente tentar achar evidências que vão contra o que você pensa. Senão você está com um risco grande de se enganar cheio de confiança comprovando suas próprias ideias porque você só perguntou o que quis ouvir. Definir as perguntas certas vale muito a pena e pode te ajudar a descartar ideias antes de escrever qualquer linha de código. Para conseguir fazer as perguntas certas, tenho 4 dicas:

• Seu objetivo é entender os problemas do seu cliente e não perguntar a ele a solução. Na minha experiência as respostas da pergunta ´o que você gostaria de usar?´ raramente geram bons inputs ou coisas que o próprio cliente realmente usaria.
• Peça aos clientes para detalhar situações reais recentes para aprender a realidade. ́Quantas vezes você vai à academia?´ gera uma resposta bem diferente do que a pergunta ́ Quantas vezes você foi à academia na semana passada?´. Isso não é por maldade, mas porque somos muito bons em enganar a nós mesmos. Na vida real agimos diferente do que a versão ideal que somos na nossa cabeça. Teresa Torres escreveu um artigo bem interessante sobre isso.
• As pessoas são bem educadas e não gostam de falar que não gostaram da sua ideia. Se você quer validar se a sua solução realmente atende, faça as perguntas da forma que sua própria mãe daria as respostas que precisa. Um dos meus artigos favoritos para elaborar roteiros de entrevista é esse, que tem no final o vídeo brilhante chamado ´the mom test´.

• Fique calado e escute. Já participei de muitas entrevistas que a pessoa que estava fazendo a entrevista falava mais do que a pessoa que estava sendo entrevistada. Faça seu roteiro com as perguntas mais importantes e deixe a pessoa falar. Escute atentamente as respostas e permita que o silêncio dê espaço para a pessoa refletir mais. Às vezes a melhor forma de aprofundar é o método de papagaio. Você simplesmente repete as últimas palavras que a pessoa falou, tornando em uma pergunta.

Cliente “Ah eu não uso aquelas ferramentas porque eu acho muito difícil”

Você: “Muito difícil?”

3. Use múltiplas fontes de dados

Discovery de produto é uma ciência e os melhores cientistas usam triangulação de pontos de dados diferentes para confirmar suas hipóteses. As entrevistas com clientes são a fonte de dados qualitativos essenciais que se tornam mais poderosos ainda combinados com dados quantitativos de uso da sua solução atual. Dados como quais features do seu produto são usadas, por quantos clientes e com que frequência podem mostrar o que está ou não funcionando. Com poucos indicadores chaves você já consegue ter muita informação importante. O que os seus clientes que voltam sempre fazem? A pessoa que entrou uma vez e nunca mais voltou olhou quais páginas? Como as pessoas navegam pela solução? (assistir gravação de hotjar é viciante). Os dados quantitativos falam o que, enquanto as entrevistas te explicam porque. Um case muito interessante que ilustra o poder dessa combinação é esse case do Spotify.

“What-Why Framework,” versão do Spotify adaptado do Nielsen Norman Group -Christian Rohrer.

4. Fazer benchmark é importante, mas escutar o cliente é mais importante ainda

Eu já me perdi muitas vezes fazendo benchmark, descobrindo tanta solução no mercado que até me pergunto se tudo já não foi inventado. Esses benchmarks podem te gerar muitos aprendizados, mas realmente recomendo só fazer depois que você entende bem o seu cliente. Como seus pais já te falaram: “só porque os outros fazem não quer dizer que você deva fazer!”. Você não sabe se a feature que o concorrente fez está sendo super utilizada ou não. Quando você conversa com seu cliente e tem uma boa noção da dor que eles têm, aí vale olhar como outras soluções existentes resolvem essa dor. Até é bem possível que uma solução totalmente fora do seu mercado já tenha pensado em algo elegante e poderia ser um ótimo contraste para apresentar ao lado de um protótipo seu.

Eu depois de fazer benchmark

No final das contas, discovery é difícil porque precisa de esforço e muitas vezes você vai aprender que sua ideia maravilhosa não era tão maravilhosa assim. Seria incrível se só aprendendo um dos muitos modelos te tornasse um PM top, mas não existe esse atalho. No mesmo tempo, isso também quer dizer que não vale estressar sobre quais dos modelos é o certo. Um bom teste se está no caminho certo? Se pergunta “porque isso é o mais importante?” umas cinco vezes. Se tiver uma resposta boa e que não é baseada no seu próprio achismo, você está fazendo discovery direito.