Existem basicamente três razões, duas delas tem a ver com a mentalidade e a outra tem a ver com o processo de discovery.

A que tem a ver com mentalidade fica clara quando ouvimos frases como “Por que você quer fazer uma descoberta? Eu sou a pessoa de negócios, então sou a pessoa que mais entende sobre nossos problemas/necessidades de negócios e como resolvê-los. Você apenas tem que implementar o que eu digo”.

Outras vezes, essa aversão está enraizada na mentalidade de “exigências de negócios => implementos de tecnologia” que mencionei anteriormente. Era assim que as coisas eram feitas no passado, sem necessidade de descoberta, pois “são as pessoas de negócios que interagem com o cliente então elas sabem o que é melhor para os clientes”.

Contudo, na maioria das vezes, essa aversão pelo processo de discovery é motivada pelas experiências passadas das pessoas de negócio em que o processo de discovery foi muito longo. A pessoa de negócio precisa que a solução de seus problemas seja implementada o mais rápido possível, para que possa se beneficiar dos resultados que essa demanda pode gerar. A pessoa de negócios não pode arcar com longos processos de discovery.

É muito difícil, mas não impossível, mudar essa mentalidade. Requer paciência e repetição:

• Pergunte por quê: perguntando por que a pessoa de negócios está exigindo a implementação de uma determinada funcionalidade, temos a oportunidade de mostrar a essa pessoa uma tática de descoberta muito simples que ajuda tanto o gerente de produto quanto a pessoa de negócios a encontrar outras hipóteses de soluções para o problema. Mudamos para um modo de discovery sem usar a palavra discovery. Depois de algumas vezes aplicando essa tática, podemos dizer à pessoa que entender o porquê de uma demanda, gerar hipóteses de solução e testar essas hipóteses de solução é o processo de discovery e é baseado na necessidade do gerente de produto e da equipe de desenvolvimento de produto encontrarem a solução mais fácil e rápida de implementar.

• Aprenda sobre o negócio: às vezes a pessoa de negócio acredita que sabe mais sobre o negócio do que o gerente de produto. Isso normalmente acontece quando um novo gerente de produto ingressa em uma empresa e ainda não sabe muito sobre o negócios. Para resolver essa percepção da pessoa de negócio, o gerente de produto precisa encontrar maneiras de conhecer o negócio o mais rápido possível. Converse com pessoas de negócio, converse com clientes, leia sobre o negócio, participe de cursos de curta duração sobre o negócio, vá a conferências sobre o tema de negócios. Os gerentes de produto precisam entender sobre o negócio para discutir questões de negócios com a pessoa de negócios.

• Encurte o processo de discovery: às vezes os discoveries demoram bastante. Algumas semanas, um mês, mais de um mês. Enquanto isso, a pessoa de negócio tem um problema que precisa de solução o mais rápido possível para que possa se beneficiar do resultado esperado que a solução do problema pode gerar. Isso acontece principalmente quando o processo de descoberta é focado apenas na descoberta do problema. Se o gestor de produto for capaz de alternar rapidamente entre a descoberta do problema e a descoberta da solução, a pessoa de negócios poderá ver a equipe de desenvolvimento de produto trabalhando mais cedo nas hipóteses de solução para o problema e pode ter suas expectativas por uma solução acalmadas.

MVD – Descoberta Mínima Viável

Infelizmente, esse terceiro motivo, o processo de descoberta lento, acontece com bastante frequência e a culpa é nossa como gestores de produto, principalmente quando buscamos entender tudo sobre um problema antes de testar as soluções.

Como mencionei anteriormente, o processo de descoberta tem dois lados, a descoberta do problema e a descoberta da solução. Não precisamos saber tudo sobre um problema antes de testar hipóteses de solução, ou seja, descobrir soluções. A descoberta de solução é uma ferramenta poderosa para entendermos mais sobre o problema. Por esse motivo, precisamos alternar o mais rápido possível entre a descoberta do problema e a descoberta da solução. Quanto mais rápido fizermos isso, mais rápido entenderemos o problema e mais rápido descobriremos uma solução para o problema.

Além disso, se fizermos uma descoberta completa do problema para entender tudo sobre esse problema, podemos acabar com tantos subproblemas que tornarão o processo de descoberta da solução também muito demorado e o delivery levará muito tempo para ser concluído.

A comunidade de desenvolvimento de produtos fala muito sobre MVP, o produto mínimo viável, mas não podemos esquecer que não se trata apenas de um delivery rápido de um produto mínimo, mas também de um processo de discovery enxuto. É hora de adotar uma mentalidade MVD – Minimal Viable Discovery ou Descoberta Mínima Viável, ou seja, qual é a descoberta mínima sobre o problema que preciso fazer para testar hipóteses de solução mínimas e entregar aquela que funciona e realmente resolve o problema?

Um bom exemplo para ilustrar isso é o app para corretores Lopes. A Lopes é a maior imobiliária do Brasil, onde lidero os esforços de transformação digital. Quando entrei na empresa, a equipe estava trabalhando em um “MVP” deste aplicativo. Coloquei aspas porque estava em desenvolvimento há 5 meses e ainda faltavam 2 ou 3 meses. Quando me aprofundei um pouco mais sobre o processo e porque estava demorando tanto, aprendi algumas coisas:

• O processo de descoberta durou de 7 a 10 meses!
• O processo de descoberta foi focado apenas na descoberta do problema.
• O processo de descoberta foi interno, ou seja, levantamento de demanda das áreas de negócios e benchmarking com outros aplicativos para corretores disponíveis no mercado.
• O “MVP” foi definido com 58 requisitos/funcionalidades e já havia mais 90 requisitos/funcionalidades com escopo definido para lançamentos futuros.
• O principal problema a ser resolvido foi baseado na hipótese de que, se a corretora recebeu um lead, ou seja, um potencial cliente interessado em um imóvel, quanto mais rápido ela receber esse lead e interagir com o cliente, maiores serão as chances de fechar um negócio.
• Em seguida, a equipe analisou a jornada da corretora e percebeu que, quando um lead chega, a corretora precisa pesquisar o banco de dados de potenciais clientes da Lopes para verificar se o potencial cliente do lead já está em nosso banco de dados e, caso não esteja, cadastrar seus dados nosso sistema.
• E então, a partir dessa análise da jornada da corretora, o time percebeu que, se a corretora pudesse enviar algumas outras opções de imóveis para o cliente em potencial, isso aumentaria as chances de fechar um negócio.
• Esse processo criou o escopo a ser implementado que levou de 7 a 10 meses de discovery mais 7 a 8 meses de entrega para construir o aplicativo “MVP”.

Há alguns pontos a destacar do processo acima:

• O processo de descoberta foi muito longo, o que gerou uma enorme lista de problemas da corretora a serem resolvidos.
• A fase de descoberta da solução não foi executada. A equipe passou da descoberta do problema diretamente para a entrega, sem qualquer oportunidade de testar hipóteses de solução.
• A enorme lista de problemas a serem resolvidos impactava diretamente no processo de entrega tornando-o muito longo também.
• Se a descoberta da solução fosse utilizada assim que o problema principal fosse descoberto, ou seja, a hipótese de que quanto mais rápido ela recebesse esse lead e interagisse com o cliente, maiores as chances de fechar um negócio, provavelmente a equipe conseguiria conceber uma solução mais simples, que levaria dias e não meses para ser implementada.

Em relação a este último ponto, após algumas discussões, pensamos em um aplicativo com apenas uma notificação push para cada lead recebido e a corretora poderia continuar as outras tarefas como já fazia. E para ser ainda mais simples de testar a hipótese da solução pensamos em nem construir um aplicativo, mas enviar um SMS ou uma mensagem de WhatsApp para a corretora. Um teste A/B pode ser feito para comparar as taxas de fechamento de negócios dos corretores que receberam notificação por SMS versus as taxas de fechamento dos corretores que não receberam.

Na verdade, acabamos implementando a notificação por SMS. Demoramos 10 dias para implementar e logo em seguida conseguimos testar a hipótese de que quanto mais rápido um corretor receber um lead e interagir com o cliente, maiores as chances de fechar um negócio.

O melhor método de discovery chama-se delivery

Já mencionei que uma das razões para entregar cedo e frequentemente é que o momento da verdade para o seu produto acontece quando um produto está na frente de seus usuários, sendo usado no contexto em que deve ser usado. Não importa quantas pesquisas, entrevistas e protótipos você faça, o momento da verdade, ou seja, o momento em que você saberá se o seu produto é, de fato, a solução para um problema de um grupo de pessoas, é quando o produto está nas mãos de seus clientes, no contexto em que eles precisam do produto.

Portanto, a melhor maneira de descobrir se uma hipótese de solução funciona é realmente implementá-la e apresentá-la a usuários em potencial que podem ter o problema que você descobriu durante a descoberta do problema.

Para muitas hipóteses de solução, não precisamos construir um produto completo para testar. Hoje existem muitas ferramentas low-code e no-code que nos permitem construir soluções simples. E algumas dessas ferramentas existem há bastante tempo, como apresentações e formulários. No Gympass testamos algumas hipóteses de solução que tínhamos para resolver o problema que descobrimos de trazer novas opções para pessoas que não queriam ir à academia, mas queriam seguir um estilo de vida mais saudável.

A hipótese de solução foi fazer parceria com aplicativos de bem-estar e fornecer esses aplicativos aos nossos usuários por uma taxa de assinatura mensal. Essa nova ideia tinha duas hipóteses principais que precisávamos testar:

• Disposição dos provedores de aplicativos para fazer parceria. Provedores de aplicativos, assim como academias, estão acostumados com o modelo de receita mensal recorrente. Eles aceitariam ser pagos por dia de uso?
• Nossa disposição de base de usuários para pagar. Nossa base de usuários está interessada em pagar uma taxa mensal para acessar os aplicativos?

Para testar nossa primeira hipótese, construímos um deck com a proposta de valor que planejamos entregar aos parceiros e conversamos com alguns potenciais parceiros. Apresentamos a oportunidade a 8 potenciais parceiros, dos quais 6 demonstraram interesse e 4 decidiram aderir à nossa prova de conceito. NEOU, um aplicativo de atividade física, 8fit, um aplicativo de atividade física e nutrição, Tecnonutri, um aplicativo de nutrição e ZenApp, um aplicativo de meditação.

Ok, nossa primeira hipótese foi validada apenas com um deck de slides. Nenhum produto foi criado. Agora precisávamos validar a segunda hipótese, a vontade de assinar. Nosso usuário está disposto a pagar para acessar esses aplicativos através do Gympass?

Para testar nossa segunda hipótese, construímos um formulário simples, onde descrevíamos o produto e pedíamos nome, e-mail e empresa. Após o usuário fornecer essas informações, ele era direcionado para uma página de assinatura do Paypal, onde precisava fornecer os dados do cartão de crédito para assinar o serviço. O usuário receberia um e-mail com o link de ativação para cada aplicativo. Não havia produto real, nenhuma área logada, apenas um formulário para testar o interesse e um e-mail com links para os aplicativos.

Ou seja, devemos utilizar as opções de ferramentas no-code ou low-code disponíveis para criar sua hipótese de solução para facilitar e agilizar a descoberta da solução. Como efeito colateral, as pessoas de negócios começarão a entender, apreciar e até querer participar de seus próximos discoveries.

Resumindo

• Pessoas de negócios não gostam de discoveries por causa de 3 razões principais. (1) Acreditam saber mais sobre o negócio, os clientes e o que esse clientes precisam. (2) Eles podem ter tido experiências passadas em que a descoberta levou muito tempo. (3) Eles estão acostumados a um modelo de “negócios demanda => tecnologia implementa”.
• Mudar essa mentalidade requer paciência e repetição. Três coisas que uma gerente de produto deve fazer continuamente para ajudar a mudar essa mentalidade. (1) Pergunte por que a pessoa está pedindo para implementar a funcionalidade pedida. (2) Procure conhecer mais sobre o negócio. (3) Encurte o processo de discovery.
• Para encurtar o processo de discovery, devemos pensar em termos de uma mentalidade MVD, ou seja, Minimal Viable Discovery ou Descoberta Mínima Viável, onde descobrimos o suficiente sobre o problema para gerar e testar hipóteses de solução o mais rápido possível.
• O melhor método de discovery chama-se delivery. O momento da verdade de qualquer hipótese de solução é quando somos capazes de apresentá-la ao potencial usuário em seu próprio contexto onde ele enfrenta o problema que queremos resolver. Hoje temos muitas soluções low-code e no-code que nos ajudam a construir nossa hipótese de solução para tornar mais fácil e rápido trabalhar na descoberta da solução.
• Como efeito colateral, as pessoa de negócio começarão a entender, apreciar e até querer participar de suas próximas descobertas.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.