Veja quais os principais erros cometidos por equipes de product discovery e como evitá-los

Segundo Marty Cagan, quando se trata de desenvolvimento de softwares, temos dois problemas essenciais: (1) como imaginar o produto certo (to figure out the right product) e (2) como construir o produto da maneira certa (to build the product right). O primeiro problema Cagan definiu como product discovery, o mais complicado dos dois porém o mais inovador, e o segundo como product delivery.

O objetivo principal de Cagan para usar o termo discovery foi estimular uma abertura da mente à criação e à colaboração entre equipes de produto, design e engenharia. Bem diferente do tradicional processo vertical de desenvolvimento de produtos, que trata levantamento de requisitos, design e produção como fases, o que, para ele, é causa do fracasso de vários projetos de software.

Descobrir é imaginar uma solução a um problema proposto, não ditar os requisitos ou o roadmap de uma funcionalidade que precisa ser construída.

Só que como você não sabe a resposta certa para o problema, toda discovery de produto envolve riscos e incertezas.

Com “descoberta” Cagan também buscou um termo tecnicamente agnóstico, isto é, que não tivesse nenhuma referência imediata a técnicas usadas no processo de descoberta, como prototipação, MVP e PoC.

Apesar de toda a dificuldade de cunhar um conceito, o de product discovery pegou. No entanto, isso não significa que as organizações estejam aplicando a técnica. Falta de compreensão sobre os motivos da prática, assim como o mal uso das técnicas de discovery, aliados a resquícios do processo tradicional de levantamento de requisitos, dão origem a erros no processo. 

Que outros obstáculos estão escondidos ou mais evidentes no processo de discovery? Neste artigo, você vê quais são os principais, assim como remediá-los.

10 erros em produc discovery e como evitá-los

Marty Cagan não apenas cunhou o termo, mas tem, desde então, recomendado como fazer a product discovery, seja por meio de que mindset gestores e equipes precisam adotar, seja por meio de técnicas que auxiliam nesse processo. Junto com os demais parceiros da SVPG, Cagan tem identificado inúmeros problemas que na aplicação das práticas. Nós reunimos as principais abaixo: 

1. Problemas mal definidos

O primeiro erro muito comum em discovery está na proposição do problema. Definições muito amplas e vagas, que não atingem a causa-raiz em jogo; falta de definição de critérios de sucesso; falta de detalhes sobre como o problema será resolvido são alguns deles. 

Outra forma desse problema se apresentar é pela simples proposição de uma solução, sem uma ampla compreensão do problema, para depois encontrar pessoas dispostas a concordar com ela.

A melhor maneira de começar a chegar a uma solução é saber colocar o problema. Do contrário, é provavel que o produto não resolva problema algum. 

A partir daí, é preciso definir o seu escopo: quem tem esse problema, quais são as alternativas para resolvê-lo, quais as abordagens propostas, quais os critérios de sucesso para tais abordagens e, por fim, qual o valor de negócio delas.

2. Achar que é a discovery é totalmente previsível

Uma das pressões da equipe de gestão é a previsibilidade. Há um temor muito grande quanto ao tempo do processo de descoberta, de que ele se arraste e não dê em nada. Então, ir em frente com um projeto pouco claro em termos de valor, usabilidade, viabilidade e factibilidade significa, ao menos, entregar algo.

Disso surge uma insistência para a criação de uma agenda de descoberta. Saber quantos protótipos serão necessários para validar uma ideia, quantas sprints serão necessárias para fazer o MVP etc. se tornam questões recorrentes.

O remédio para essa armadilha é compreender o processo. Nem sempre a descoberta é um caminho simples. O problema e a oportunidade de mercado geralmente até podem ser fáceis de validar, mas a solução geralmente é bem mais difícil. 

A indústria farmacêutica é um dos exemplos citado por Cagan: as pesquisas em torno de medicamentos são feitas com plena consciência de que não há garantias de que chegarão a um resultado nem em quanto tempo chegarão. O nível de risco e de incerteza em relação a produtos é similar.

Leia também: Do MVP ao MLP: o que está em jogo?

3. Separar definição do problema da solução

Cagan aponta este como um dos principais problemas: a visão de que a descoberta está apenas relacionada com a definição do problema, questão ligada à gestão do produto, e de que a equipe de engenharia trabalha sobre a solução. Essa visão é simplista e inibe a inovação. Na prática, as coisas são mais imbricadas e por isso mesmo possivelmente mais inovadoras. 

O processo de descoberta do produto não se restringe à validação do problema. Ela envolve encontrar qual a melhor solução para ele em termos de negócio e para os usuários.

Para Marty Cagan isso significa um produto factível, viável, usável e que gera valor.  É nessa descoberta que a maior parte do tempo da equipe deve ser investido. E esse processo envolve três dimensões: produto, design e engenharia.

Saiba mais: O que é lean inception?

4. Deixar vieses cognitivos se sobreporem à neutralidade

Muitas equipes têm a tendência de buscar apenas reforçar suas ideias iniciais ou as decisões que já foram tomadas em relação ao produto, minimizando visões divergentes.

Vieses de confirmação transformam testes em ferramentas de validação das suposições e escolhas dos criadores, não uma oportunidade de colocá-las à prova e de melhorá-las. 

Quando a equipe cai no viés de confirmação, já não é a melhor solução para o problema que importa, e sim a confirmação da solução já proposta. Com isso, a discovery não produz aprendizado nem avalia corretamente a proposta.

Evitar o viés de confirmação é difícil, afinal quem não defende suas ideias? Considerá-las hipóteses que precisam ser validadas, mantendo uma atitude cética, ajuda a focar na busca pela melhor solução. Não importa o que a equipe pense, o mercado e os clientes, por exemplo, podem não estar preparados.

Ao explorar soluções potenciais, a compreensão da equipe sobre o problema se desenvolve e se aprofunda, geralmente de maneira inesperada e poderosa.

5. Confundir produto com protótipo

Um protótipo não é nem um MVP, nem um teste beta do produto. Embora todo mundo saiba disso, muitos fazem protótipos pensando em aproveitá-los no produto. Esse é outro erro comum em discovery. 

Leia mais: Design sprint ou lean inception?

Não porque seja errado aproveitar, mas porque ir por esse caminho pode aumentar consideravelmente o tempo e o custo do processo de descoberta. Depois, porque quanto maior o comprometimento do time de engenharia, mais difícil será abandonar ou modificá-lo.

A solução é dar a César o que é de César. Manter a atitude experimentadora, voltada ao aprendizado e refinamento da solução, é o principal objetivo durante a discovery.

6. Não considerar funcionalidade, design e engenharia

Cagan é claro: o conceito de discovery implica a colaboração de produto, design e engenharia.  

Porém, uma prática muito comum é ter apenas um ou dois desses papéis à frente dessa fase, geralmente, product manager e designers, deixando ao time de engenharia apenas a viabilidade técnica.

O problema fica pior quando apenas a parte de design é considerada. Pode acontecer de a descoberta ficar desconectada dos objetivos de negócio e do go-to-market, por exemplo.

Não são práticas recomendadas. Primeiro, porque o desenvolvimento de softwares é essencialmente multidisciplinar e todas as três frentes têm contribuições importantes para o sucesso do projeto. Depois porque facilita a comunicação entre discovery e delivery.

Veja também: UI e UX: tem que separar?

7. Envolver muitas pessoas

Se, no ponto anterior, vimos que a configuração mínima da equipe de discovery envolve um product manager, um designer e um engenheiro, agora veremos que também não dá para exagerar. A outra face do erro anterior é envolver muitas pessoas. 

Se, por um lado, quanto mais perspectivas o time tem, mais vai aprender; por outro, muito cacique para poucos índios afetará a capacidade de tomar decisões.

É possível ouvir muita gente, mas encontrar o equilíbrio para continuar a se mover rapidamente. Aos representantes básicos do time, escolha a dedo quem deve estar junto. Pode haver profissionais ligados a pesquisas com usuários, product marketing e até vendas.

8. Adotar apenas um técnica de discovery

É comum que o time use uma técnica de descoberta, mas exclua outras. O resultado pode ser uma análise limitada em termos de riscos. Por isso, esse é outro erro.

O processo de descoberta usa muitas ferramentas, com diferentes tipos de resultados. Obter evidências quantitativas, por meio de testes A/B, e qualitativas, por meio de testes como os de usabilidade e de pesquisas, dará uma visão suficientemente abarcante para a equipe refinar o projeto.

9. Pensar que a descoberta é uma fase

Muitas equipes trabalham a descoberta como uma fase limitada ou então simplesmente interrompem hábitos de descoberta. Esse é outro erro. Geralmente, a solução precisa ser muito simples para a equipe cair nisso.

Produtos relevantes exigem que a descoberta seja contínua, tal como o são as mudanças no comportamento dos usuários e nas tendências em tecnologia. Claro que existirão momentos com menor produtividade ou até de completa dificuldade de exercitar a descoberta.

Mesmo assim, boas equipes se mantêm em aprendizado constante, com cadências e engajamento constantes com clientes e usuários. 

 10. Não compreender bem o valor comercial da solução

Um produto bem-sucedido precisa, além de ser usável, geral valor para os usuários. Por outro lado, além de ser factível, ele precisa ser viável para a organização. Esses dois últimos pontos não podem ser descurados, sob pena de não gerar valor para a organização. 

Entender o valor de negócio e a dimensão da oportunidade, assim como estimar custos do problema e tempo de desenvolvimento, são requisitos fundamentais em uma discovery.

Product discovery: saiba qual a melhor forma de resolver seus problemas

Como todas as técnicas em desenvolvimento de softwares, a product discovery nasce com o objetivo de determinar melhor do que o simples modelo sequencial e vertical de definição de requisitos qual a melhor solução para os problemas subjacentes. Cagan a torna multidisciplinar, contínua e essencialmente experimental.

Como vimos, isso não significa que em sua aplicação o processo não possa ser desvirtuado, causando problemas como os que vimos. 

A boa notícia é que mudanças no mindset e nas abordagens adotadas podem corrigir o curso, tornando a discovery um processo enriquecedor.

Se você quer evitar esses erros, conte com profissionais experientes para auxiliar a sua equipe. A Supero ajudará você a se conectar com eles. Fale com um de nossos consultores.