A Origem do Product Discovery

Marty Cagan - 01/06/2020 Traduzido por: Raphael Jubram

Há muitos anos que tenho a intenção de escrever este artigo, mas como ele é, sobretudo, de natureza histórica, sempre houve temas mais urgentes.

Mas, de vez em quando, alguém tenta descobrir a origem do termo. E, durante esta pandemia, por qualquer razão, tenho recebido esta pergunta com mais frequência.

Em primeiro lugar, deixe-me ser claro que o conceito de descoberta de produtos existe há muito tempo, como o software, e, certamente, há muito mais tempo do que eu. Sempre tivemos - e, provavelmente, sempre teremos - dois problemas essenciais no software: precisamos descobrir o produto certo e, depois, temos que construir o produto certo.

Sempre me interessei pelos dois problemas, mas penso que o primeiro é mais difícil. E é aí que acontece a maior parte da inovação e concentro a minha atenção.

A partir de 2005, comecei a experimentar o termo "descoberta" para perceber o que devemos construir e, em 2007, decidi entrar no conceito.

Desde então, tenho me referido ao primeiro problema como descoberta e, ao segundo, como entrega.

Em 2007, estava trabalhando na primeira edição do INSPIRED, e tinha um prazo de publicação próximo. Eu tinha que decidir qual termo utilizar, se é que tinha algum.

Nessa altura, praticamente, todos os gestores de produto falavam em "reunir e definir requisitos", mas eu considerava que essa era uma das razões fundamentais pelas quais havia tantos produtos falhos por aí.

Para mim, falar sobre a definição de requisitos era algo equivocado e arrogante.

Pude ver também que, em boas equipes, os produtos eram concebidos por verdadeiras colaborações entre engenheiros, designers e gestores de produto.

E não por algum gestor de produto que declarasse: "estes são os requisitos, agora vá, conceba e construa isto”.

Por isso, queria um termo que evocasse uma imagem muito diferente na mente dos gestores de produto e das equipes de produto.

Eu queria que eles tivessem uma mente aberta, que soubessem o que não podem saber e que admitissem o que não sabem.

Queria ressaltar que os grandes produtos são o resultado do trabalho em conjunto da equipe de produtos, do design e da engenharia.

Queria que pensassem em termos de "descobrir uma solução para um problema que nos foi pedido para resolver" em vez de "ditar os requisitos de uma funcionalidade que nos foi pedida para construir".

Descobri o termo "descoberta" pela indústria farmacêutica, que assim chamava o processo utilizado para criar um medicamento viável. Ao contrário da indústria de software, a indústria farmacêutica reconheceu o risco antecipadamente.

Esperava-se que muitos (senão a maioria) dos medicamentos acabassem por não serem suficientemente seguros e eficazes para fabricar, distribuir e vender.

Também gostei do termo "descoberta" porque era técnica agnóstica.

Existem várias técnicas utilizadas para ajudar na descoberta, e novas surgem o tempo todo.

Um MVP é uma técnica de descoberta, assim como o Design Thinking, o Customer Development e o "Jobs To Be Done".

Isso foi muito importante para mim porque vi várias técnicas e métodos irem e virem.

Por isso, não quis me associar explicitamente a nenhum deles.

Também gostei que o termo "descoberta" encoraja as equipes de produtos a pensarem nos riscos do valor, da usabilidade, da exequibilidade e da viabilidade.

Em geral, tenho relutância em tentar introduzir uma nova nomenclatura.

É uma coisa difícil de se fazer.

Mesmo que as pessoas respondam bem, é preciso tempo para se espalhar, e é preciso realmente escolher as batalhas em coisas como essa.

Mas hoje estou contente por ver que tantas equipes de produtos compreendem o conceito e têm, pelo menos, uma compreensão razoável de como e porquê fazemos a descoberta de produtos.

Agora, o meu foco está mais em garantir que as equipes de produtos estejam trabalhando em um ambiente em que tenham poderes para fazer a descoberta de produtos, em vez de se limitarem a dar roadmaps para a construção.

Texto Original: https://bit.ly/2EhOVs7