Quem já teve contato com times de desenvolvimento de produto já deve ter se deparado com o termo discovery. É bastante comum as pessoas que são novas no desenvolvimento de produtos pensarem que discovery de produto é um processo para entender as necessidades dos clientes, mas esse entendimento está incorreto. A definição correta é:

DISCOVERY DE PRODUTOS é um conjunto de ferramentas para nos ajudar a mitigar os riscos do desenvolvimento de produtos.

Primeiro, precisamos entender que o discovery de produtos tem um objetivo muito claro, a mitigação de riscos do desenvolvimento de produto. Por quê? Porque o desenvolvimento de produtos requer um investimento muito alto. Normalmente, o time de desenvolvimento de produto é uma parte considerável dos custos totais da empresa, então precisamos ter a certeza de que estamos investindo o tempo desse time no desenvolvimento de coisas que ajudarão a empresa a atingir seus objetivos ao mesmo tempo em que resolverão um problema ou atenderão a uma necessidade dos clientes.

De que tipos de riscos estamos falando? Se pesquisarmos tipos de riscos em negócios no Google, encontraremos muitos tipos de riscos. Alguns chegam a falar sobre 10 tipos de riscos. Marty Cagan (2017), reconhecida referência em gestão de produtos, fala sobre quatro tipos de riscos:

1. Risco de valor: se os clientes vão comprá-lo ou se os usuários optarão por usá-lo;
2. Risco de usabilidade: se os usuários podem descobrir como usá-lo;
3. Risco de viabilidade: se nossos engenheiros podem construir o que precisamos com o tempo, habilidades e tecnologia que temos;
4. Risco de viabilidade do negócio: se esta solução também funciona para os vários aspectos do nosso negócio.

Embora eu entenda essa necessidade de categorizar os tipos de riscos do desenvolvimento de um produto, o tipo de risco não é tão crucial quanto a prioridade do risco, que significa saber qual risco tem maior potencial de ser um obstáculo significativo para o sucesso do produto. Lembre-se: queremos desenvolver um produto que ajude a empresa proprietária a atingir seus objetivos enquanto resolve um problema ou atende a uma necessidade de seus clientes. É isso que significa ter sucesso com o produto.

Por isso, precisamos identificar e priorizar os riscos. Após priorizar os riscos, utilizamos o discovery de produto como o conjunto de ferramentas que nos ajudam a mitigar esses riscos.

Discovery de problema e discovery de solução

Outro aspecto importante que costuma não estar claro é o fato de que o discovery de produto tem dois lados: o discovery do problema e a descoberta da solução.

Discovery do problema é quando buscamos entender o problema (ou necessidade) da nossa cliente, como esse problema está conectado aos objetivos estratégicos de negócios da nossa empresa, a motivação que a cliente tem para querer que esse problema seja resolvido, quando, onde, como e por que esse problema ocorre, se existem soluções para esse problema e o que nossa cliente pensa sobre essas soluções. O problema é o foco, e essa tarefa é liderada principalmente pela gestora de produto e pela designer de produto.

Em 2011, tive a ideia de criar um aplicativo contador de calorias que me informasse não apenas o número de calorias de cada alimento, mas também a qualidade da caloria com um sistema simples de cores vermelho, amarelo e verde, em que as calorias vermelhas, como doces e bolos, devem ser evitadas, calorias amarelas, como arroz e carne, podem ser consumidas moderadamente e calorias verdes, como alface e espinafre, podem ser consumidas sem restrições.

A primeira coisa que decidi testar foi se havia demanda para tal aplicativo. Portanto, antes de criar o aplicativo, decidi criar uma landing page para o aplicativo e, em seguida, criar uma campanha do Google Adwords para enviar algum tráfego para esta página. A página explicava o produto que eu planejava construir e quanto custaria. Conto a história completa desse aplicativo em meu livro Guia para startups: como startups e empresas estabelecidas podem criar produtos digitais lucrativos. Esta é uma mitigação de risco típica de descoberta de problemas: eu estava tentando mitigar o risco de saber se era um problema que valia a pena perseguir.

Descoberta da solução:

Quando começamos a entender o problema a ser resolvido, precisamos descobrir possíveis soluções para esse problema. É quando geramos e testamos ideias e hipóteses de solução da maneira mais simples possível com protótipos, provas de conceito e outras técnicas semelhantes de low-code ou no-code, ferramentas que, com pouca ou nenhuma programação, permite implementar alguma funcionalidade, como um formulário, por exemplo. Isso ajuda todos na equipe de desenvolvimento de produtos a entenderem melhor como maximizar o valor a ser entregue durante o desenvolvimento do produto, minimizando o risco e o tempo desse desenvolvimento. Por esse motivo, durante a descoberta da solução, toda a equipe de desenvolvimento de produto (gestora de produto, designer de produto e engenheiras) deve se envolver igualmente.

Um exemplo muito interessante de descoberta de solução vem da história do restaurante McDonald’s. Richard e Maurice McDonald, conhecidos como McDonald Brothers, eram empresários americanos que fundaram a empresa de fast-food McDonald’s. A história deles foi contada no filme Fome de Poder (2016), e há uma cena muito interessante em que os irmãos McDonald explicam como descobriram o melhor layout de cozinha para agilizar o processamento dos pedidos. Eles foram até uma quadra de tênis e desenharam com giz, no chão, o layout que haviam pensado e testaram operar nesse layout. Viram que havia pontos de melhoria, fizeram ajustes no layout e testaram até chegar ao layout de cozinha que foi implementado no primeiro restaurante McDonald’s. Veja uma imagem que mostra esse discovery de solução:

Você pode ver essa cena do filme Fome de Poder em: https://www.youtube.com/watch?v=jTageuhPfAM.

O motivo mais comum para a falha de um produto

Por trás de muitas das falhas de produto, podemos encontrar um comportamento comum: ir direto da descoberta do problema para o desenvolvimento da solução com pouca ou nenhuma descoberta de solução. Ao conversar com meus clientes sobre o discovery de produto, eles normalmente descrevem situações como estas:

“Fizemos uma pesquisa profunda com o usuário e encontramos o problema X, que os usuários desejam resolver a ponto de pagarem por uma boa solução. Então decidimos criar a solução Y, mas agora que entregamos a solução Y, estamos vendo muito baixa adoção…”

Isso aconteceu porque eles pularam o discovery de solução, passando da descoberta do problema direto para a entrega da solução. Deixe-me repetir isso porque isso é muito, muito importante:

O discovery é um conjunto de ferramentas para nos ajudar a mitigar os riscos do desenvolvimento de produtos. Descobrir um problema é fácil. Encontrar uma solução é difícil e exige que gestoras de produto, designers e engenheiras pensem em possíveis soluções. Em seguida, é preciso avaliar as soluções para determinar se pelo menos uma funciona e, se sim, e se mais de uma delas funcionar, qual delas tem a maior chance de sucesso.

Às vezes, a descoberta da solução confirma qual produto ou funcionalidade precisamos entregar, e isso é um sucesso. No entanto, há momentos em que a descoberta da solução nos mostra que não seremos capazes de encontrar uma solução com chance de sucesso, e isso é bom. É bom porque nos poupará muito tempo e energia trabalhando na entrega de uma solução que falhará. Precisamos investir em discovery de soluções para evitar falhas de produto.

A descoberta de solução pode ser um protótipo, mas também pode ser outras coisas, como uma landing page, onde atraímos tráfego para entender se há demanda, como mostrei no exemplo do app contador de calorias. Também pode ser uma planilha, com a qual avaliamos a viabilidade financeira de determinada solução. Como já foi dito, discovery de produto é um conjunto de ferramentas para nos ajudar a mitigar os riscos de desenvolvimento de produtos, e existem muitos tipos diferentes de ferramentas para os diversos tipos de riscos no processo de desenvolvimento de produtos.

Certa vez uma cliente teve uma ideia de solução muito interessante para determinado problema que ela descobriu que a maioria de seus clientes tinha, mas quando resolveu rodar alguns números, entendeu que a solução não era viável financeiramente, pois a quantidade de dinheiro que ela receberia dos clientes não seria suficiente para pagar todos os custos de servir o produto. E isso foi bom porque ela conseguiu poupar todo o tempo e dinheiro que investiria na construção de uma solução que se tornaria uma falha.

Um exemplo da vida real – um produto da Locaweb que nunca ganhou vida

Quando eu estava na Locaweb, por volta de 2010, descobrimos que alguns clientes em potencial não queriam usar os construtores de sites existentes e procuravam profissionais de web design, mas sem conhecimento suficiente sobre como gerenciar o trabalho com esse tipo de profissional. Como tínhamos experiência na construção de sites, pensamos que poderíamos administrar esse relacionamento com profissionais de web design para o cliente.

Ficamos muito entusiasmados com a oportunidade e desenhamos uma solução. Já estávamos tendo algumas discussões sobre como desenvolver essa solução; no entanto, antes de pensarmos em construir a solução, decidimos construir um protótipo para apresentar a alguns clientes em potencial e aprender com suas reações e feedback.

Quando apresentamos o protótipo da solução a clientes em potencial, recebemos um balde de água fria. Queríamos ser o intermediário, deixando claro que faríamos o possível para ajudar o cliente a ter um bom site, mas não queríamos ser responsáveis por qualquer má conduta dos profissionais de web design. Queríamos que o sistema se autorregulasse através daquele tipo de classificação de 1 a 5 estrelas. Quando construímos nosso protótipo – um esforço de uma semana – e o apresentamos a clientes em potencial, quase todos queriam que pagássemos alguma multa por não entrega ou atrasos caso as coisas não saíssem como o esperado.

Fizemos alterações no protótipo para apresentar o produto de formas alternativas para deixar os papéis e responsabilidades da Locaweb e dos web designers mais claros, mas sem sucesso. Foi quando decidimos cancelar o desenvolvimento do produto. Ficamos muito felizes por termos feito isso e aprendemos como é importante fazer a descoberta de soluções antes de colocar energia e recursos na entrega de um produto completo.

A descoberta de soluções é uma maneira muito poderosa, porém simples e barata de aumentar a taxa de sucesso de nossos esforços de desenvolvimento de produtos. No entanto, muitas equipes a ignoram e partem da descoberta do problema direto para a entrega da solução. Se tivéssemos feito isso neste exemplo da Locaweb que acabei de descrever, certamente seria um grande fracasso. Isso geraria muita dor de cabeça para a Locaweb, para a nossa equipe de desenvolvimento de produtos e para nossos clientes.

Por que as pessoas de negócios odeiam discovery?

É comum as pessoas de negócios das empresas que começam sua jornada de transformação digital ficarem bastante frustradas com o discovery de produto. Essa frustração costuma ser externada em 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 e necessidades de negócios e como resolvê-los. Você apenas tem que implementar o que eu digo”. Essa forma de pensar deriva de um modelo antigo de gestão de tecnologia no qual as pessoas de negócio demandam e as pessoas de tecnologia implementam. Era assim que as coisas eram feitas no passado, sem necessidade de discovery, pois “as pessoas de negócios interagem com o cliente, então elas sabem o que é melhor para resolver os problemas e atender às necessidades deles”.

Além dessa motivação, a aversão pelo discovery também pode ser motivada pela experiência de longos períodos de discovery passados pelas pessoas de negócio. 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 discoveries.

Já ouvi casos em que o discovery demorou 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.

Transformação digital e cultura de produto

Esse artigo é mais um trecho do meu mais novo livro “Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia da sua empresa“, que vou também disponibilizar aqui no blog. Até o momento, já publiquei aqui:

• Sobre o livro
• Parte 1: Conceitos
  • Capítulo 1: A tal da transformação digital – Projeto e Produto
  • Capítulo 2: Incerteza e transformação digital
  • Capítulo 3: Tipo de empresa
  • Capítulo 4: Tipo de empresa x maturidade digital
  • Capítulo 5: Modelos de negócio
  • Capítulo 6: Cultura ágil, digital e de produto
• Parte 2: Princípios
  • Capítulo 7: Entregas rápidas e frequentes – Medindo e gerenciando a produtividade – Estudo de caso: Grupo Dasa – Estudo de caso: Itaú Unibanco
  • Capítulo 8: Foco no problema – O Famoso Discovery de Produto