Descoberta de Produto

Você conhece essa situação? Na sua empresa, todos estão super empolgados com uma determinada ideia de produto e você, como gerente de produto, deve definir esse produto. Dizem que os desenvolvedores vão terminar o projeto atual em quatro semanas. Isso significa que você pode levar o tempo que precisar, desde que esteja pronto em quatro semanas…

Você diz que não tem problema (afinal, às vezes você tem apenas alguns dias, então quatro semanas parecem um sonho). Você vai até usar todos aqueles métodos incríveis sobre os quais eu sempre falo tanto. Vai começar com a avaliação de oportunidades para entender o problema a ser resolvido. Depois, vai realizar entrevistas com usuários reais e criar uma lista preliminar de requisitos. No início da segunda semana, você já deve estar trabalhando com um Interaction Designer em um protótipo. Na terceira semana, vai poder fazer testes com esse protótipo e na quarta semana vai elaborar os detalhes dos casos de uso e revisar o protótipo e as especificações junto com os desenvolvedores.

A realidade na Product Discovery

Isso parece muito bom – mas o que realmente acontece geralmente não é tão bom assim: Durante as conversas iniciais com os clientes, descobre-se que eles não estão tão entusiasmados com o produto quanto a gestão estava, e/ou você tem dificuldades em criar um protótipo com o qual os clientes consigam lidar, e/ou os clientes não acham as ideias implementadas no protótipo realmente boas. Mas agora o tempo acabou e os desenvolvedores estão prontos. Então, nos próximos três a seis meses, será desenvolvido o mesmo produto inútil e entediante que já foi visto como protótipo. Quando o produto é finalmente entregue, a gestão fica justificadamente decepcionada com o resultado.

Qual é o problema?

O problema não está na confiabilidade do software. Os desenvolvedores não têm culpa – afinal, eles apenas construíram o que você pediu. Todos sabem, portanto, que a responsabilidade é sua como gerente de produto.

Não adianta nada conversar com os usuários, desenvolver protótipos e testá-los junto com os usuários, se você não coloca em prática o que aprende com isso.

A ideia de ver requisitos e design como uma fase sequencial, previsível e planejada no processo de desenvolvimento de produtos está tão enraizada na nossa indústria que muitas vezes é muito difícil para as organizações de produto abandonar esse hábito.

Mas você precisa fazer isso. Em organizações de produto é preciso entender que inventar novos produtos é fundamentalmente um processo criativo. É mais arte do que ciência. Por isso, prefiro chamar essa fase de "Product Discovery" em vez de "requisitos e design".

O termo "Product Discovery" destaca dois pontos particularmente importantes:

• Primeiro, você precisa descobrir se realmente existem clientes lá fora que querem esse produto. Isso significa que você precisa definir o mercado e ter a oportunidade do produto validada pelos seus clientes.

• Segundo, você precisa encontrar uma solução para esse problema que seja utilizável, útil e viável. E isso significa que você precisa projetar o produto e depois validá-lo junto com os clientes e a equipe de desenvolvimento.

Product Discovery na Indústria Farmacêutica

A indústria farmacêutica é um exemplo extremo. Encontrar um mercado não é tão difícil – sempre há problemas suficientes que vale a pena resolver (por exemplo, salvar vidas, prolongar vidas ou melhorar a qualidade de vida). Encontrar a solução para isso é a parte difícil. Quando as empresas farmacêuticas iniciam a "fase de descoberta", elas têm plena consciência de que não há garantia de que encontrarão uma solução ou de quanto tempo o processo vai demorar. Nesse setor, portanto, é preciso lidar com essa incerteza (e o risco se reflete nos preços dos produtos).

Razões para dificuldades com a Product Discovery

E embora todos saibamos que é difícil e que a maioria dos lançamentos de software são fracassos porque não atingem os objetivos desejados, ainda insistimos em planejar a fase de Discovery no desenvolvimento de software da mesma forma que planejamos a construção de um edifício.

Especialmente a gestão tem dificuldades com o conceito de Product Discovery. E acredito que há duas razões para isso:

• Primeiro, o processo de Discovery não é previsível. A gestão tem medo de trabalhar meses em algo e não obter nenhum resultado. Se simplesmente começarmos e desenvolvermos qualquer coisa, pelo menos podemos afirmar que entregamos algo. Provavelmente é a mesma razão pela qual tantos gestores não se dão bem com Scrum, pois querem saber exatamente quantos Sprints de 30 dias serão necessários até estar pronto.

• Segundo, numa organização de produto de software, os desenvolvedores são sempre vistos como um recurso escasso. A ideia de que uma equipe de desenvolvedores fica sentada sem fazer nada, a não ser jogar pebolim, deixa a gestão maluca.

Ironicamente, é exatamente essa argumentação que leva a desperdiçar os desenvolvedores como recurso.

Quase toda empresa usa o processo de Discovery que acabamos de descrever. Em vez de dedicar algumas semanas a um protótipo, fazem toda a equipe de desenvolvimento passar por ciclos completos de release para desenvolver o software, que então passa pela garantia de qualidade e é implantado em sistemas de produção. É por isso que tantas empresas precisam de três ou até mais releases e de um a dois anos antes de conseguirem algo útil e utilizável. Elas usam a organização de desenvolvimento para construir um protótipo extremamente caro e transformam seus clientes em cobaias involuntárias.

Essa também é a razão pela qual tantas startups não têm sucesso. Elas simplesmente não têm o capital necessário para esperar dois anos antes de poderem decolar. Então, pegue os desenvolvedores delas, deixe-os dar o melhor de si e veja o que acontece.

Conclusão

Por isso, aconselho tanto start-ups quanto grandes empresas a concentrarem suas forças nesse processo de Discovery muito mais rápido. Assim que encontrarem uma solução que funcione (que seja utilizável, útil e viável), tudo passa a girar em torno do trabalho de desenvolvimento. Até esse ponto, não precisam ter tantos desenvolvedores. Os desenvolvedores que têm podem e devem participar ativamente do processo de Discovery. Até certo ponto, os desenvolvedores também podem preparar a infraestrutura durante o processo de Discovery.

Você pode ajudar sua gestão a entender o processo de Product Discovery. Se você apontar consistentemente que é sua responsabilidade garantir que os desenvolvedores também criem algo útil e utilizável, e participar dos esforços para encontrar uma solução promissora, conseguirá direcionar o foco da gestão para essa fase extremamente importante do processo de desenvolvimento de produto.

Este texto é do blog de Marty Cagan e foi traduzido por nós para o português. 

Criar produtos incríveis

=> Discovery vs Delivery em produtos.

Desenvolver uma estratégia de produto

Descubra como a tua estratégia empresarial vs. estratégia de produto se diferencia.