Minimal Viable Discovery

É muito comum escutarmos sobre produto mínimo viável (MVP) quando estamos falando sobre desenvolvimento de produtos ou criação de uma empresa. Um ponto muito importante que muitas vezes é deixado de lado é que não podemos esquecer que não se trata apenas de uma entrega (delivery) rápida, mas também de um processo de descoberta enxuto com apenas o necessário.

Aqui entra a mentalidade da descoberta mínima viável (Minimal Viable Discovery, MVD). Qual a quantidade mínima de informações que preciso coletar sobre um problema, a descoberta mínima referente a dor do cliente, para formular e testar hipóteses para entregas/soluções mínimas para descobrir o produto que realmente resolve o problema.

O discovery lento é um dos grandes pontos que levam stakeholders a temerem as discoveries e sempre pedirem para apressar o processo.

O processo de descoberta

Como já falei em outro texto sobre Product Dscovery, o processo de descoberta tem duas fases principais que representam a primeira etapa do método do diamante duplo (Double Diamond), a descoberta do problema e a descoberta da solução.

O mais importante é entender que não precisamos saber os mínimos detalhes sobre um problema para testar hipóteses de solução. Em muitos casos podemos aprender mais e mais rápido sobre o problema com a descoberta da solução e testes de hipóteses.

Gosto bastante do conceito de agilizar a tomada de decisão apresentada pro Jeff Bezos. Ele fala que temos dois tipos de decisões:

• Decisões de Tipo 1 são as mais importantes, que implicam graves consequências e não permitem que se volte atrás.
• Decisões de Tipo 2 são aquelas que podem ser dadas ou revertidas sem que isso seja considerado o fim do mundo. 

Esse conceito também pode ser aplicado na descoberta de soluções, avaliando o grau de complexidade e testes necessários, mas buscando sempre reduzir a menor parte para realizar testes. 

Algo que Bezos fala em suas cartas aos acionistas, que gerou um impacto enorme na minha tomada de decisão, é da necessidade de agir sem ter todas as informações. Se tentarmos descobrir tudo sobre um determinado problema, vamos acabar com tantos subproblemas que tornarão o processo de descoberta muito grande e consequentemente demorando pra lançar uma solução no mercado.

Para Bezos, a maioria das decisões precisam ser tomadas com algo entorno de 70% das informações que você gostaria de ter. Se esperar para ter 90%, o mais provável é que você seja lento demais.  

O melhor discovery é encontrado no delivery

Isso já é batido para pessoas da área de produto, mas sempre é bom reforçar, você só consegue a validação da solução com ele rodando com os seus clientes no meio em que ele deve ser utilizado. Você pode fazer uma infinidade de pesquisas, testes de protótipos com possíveis usuários, mas para descobrir se a solução realmente atendo ao problema de um grupo de pessoas é necessário vender e observar a utilização do produto no contexto em que os clientes precisam da sua solução.

Assim, o ideal para testar uma hipótese de solução levantada é implementá-la e entregar aos usuários que podem apresentar o problema que você identificou na descoberta do problema.

E não se engane achando que é necessários um time de devs e semanas para criar o teste. Para muitas hipóteses, podemos utilizar ferramentas low-code ou no-code que permitem gerar valor ao usuários com soluções simples. Um caso muito conhecido é do MVP da Easy Taxi, que apenas criou um formulário na landing page do site solicitando alguns dados.

O MVD nada mais é do que entender qual a quantidade mínima/ideal de dados que devamos analisar para ter de base para testar as hipóteses com delivery.

Tem uma frase que me marcou muito em uma palestra do Chris Chan que representa esse mentalidade de Minimal Viable Discovery:

"Move forward with IMPERFECT information".

Isso não significa que você deve seguir com informações erradas ou incompletas, mas que você não precisa ter todas as informações para seguir para o próximo passo.