Definir e construir um bom produto viável mínimo é muito mais difícil do que parece. Encontrar aquela “coisa” que você pode fazer, que as pessoas querem, é muito mais do que escolher uma coisa. É uma combinação de resolver o problema do produto viável  mínimo e todas as outras coisas que o acompanham. Resolver para ambas as necessidades de fora para dentro e as metas de dentro para fora é crítico.

Começando com icebergs

O excelente artigo do Rich Mironov, DIY Illusion, fala sobre a importância de focar sua equipe em construir o que é importante construir (e não a construção de algo que pode ser facilmente adquirido de outras maneiras). Imagine que sua equipe está construindo um aplicativo móvel. Agora imagine que ela está construindo – a partir do zero – um sistema de CRM para que você possa monitorar todos os usuários que instalarem o aplicativo. Ou imagine que ela está construindo um sistema de emissão de bilhetagem – a partir do zero – para que você possa acompanhar o progresso da equipe de desenvolvimento em pedidos de funcionalidades e correções de bugs.

Eu apresentei o conceito de design do Andy Polaine em diferentes contextos no artigo sobre roteiros e listas de atributos no ano passado. O mesmo padrão/conceito se aplica aqui.

O artigo do Rich descreve uma microversão da clássica decisão de comprar, construir e fazer parceria. Quando for a sua equipe tomando decisões sobre dev-ops ou outras infraestruturas de que necessita, é assim que as coisas são.

Surgiu para o contexto mais amplo no nível da organização, e agora, é a versão clássica do MBA – vamos construir um novo produto para completar nosso portfólio? Ou nós achamos um parceiro para incluir o produto dele? Ou talvez adquirir esse parceiro (ou apenas o produto) faz mais sentido.

Ambas as decisões estão firmadas no pensamento de dentro para fora, em relação ao produto. E sobre o enquadramento de fora para dentro?  Seus clientes estão tomando a decisão de comprar, construir e fazer parceria sobre o seu produto. Como você pode ter certeza de que a resposta certa para eles é “comprar”?

Um ponto importante no artigo do Rich é que o trabalho que você precisa fazer (para rolar seus próprios <insira o sistema aqui>) é muito maior do que uma análise superficial levaria a crer. O mesmo vale para a definição de um produto viável mínimo. Seus clientes terão que resolver mais do que o único problema no qual você começará a focar.

Problema viável mínimo

Agora vou falar sobre problemas viáveis mínimos, e não produtos viáveis mínimos, como uma experiência para verificar se eles aceleram a mudança de pensamento na minha equipe. [Falei o termo pela primeira vez recentemente, em uma reunião com executivos explicando que nosso produto tem como foco atender completamente ao problema viável mínimo, e obtive alguns acenos negativos de cabeça, mas nenhum comentário direto.]  Se você quiser saber os resultados, pergunte nos comentários deste artigo.

Na minha mente, eu lembro de ter lido Steve Johnson citando Saeed Khan, dizendo que um produto viável mínimo é, literalmente, “o mínimo que você poderia fazer”. Espero que seja verdade, eu amo essa citação. Eu não sei se é realmente onde ouvi isso, mas vamos fazer a citação e ver se alguns tweets fazem com que o autor original apareça magicamente. Um MVP é, literalmente, o mínimo que você poderia fazer com o seu #produto.

Por que fazer a distinção entre o produto e o problema? Duas razões – uma filosófica e uma prática.

Filosofia Soapbox

Uma coisa que meus clientes valorizam regularmente em mim é que costumo me unir à equipe deles com um “novo conjunto de olhos”, e trago uma perspectiva externa sobre o que eles estão fazendo e planejam fazer. Isso me dá a oportunidade de ajudar a mudar a perspectiva da equipe de dentro para fora e de fora para dentro. Em outras palavras, serem orientados pelas necessidades do mercado. No nível de produto do contexto, isso geralmente significa ser impulsionado pelos problemas que um determinado conjunto de usuários estão tentando resolver. Apresentar o “problema” como um totem em muitas conversas ajuda a reforçar e sutilmente mudar conversas ao longo do tempo.  Quanto mais tempo eu trabalho com uma equipe em particular, mais eu vejo os resultados disso.

Quando as pessoas falam sobre o produto, estão geralmente falando sobre “essa coisa que nós (iremos) construir”.  Não é tão valioso para mim assegurar um produto apto ao mercado, quanto saber que as pessoas estão falando sobre o problema que estamos resolvendo com o produto. Eu estou em uma equipe nas primeiras fases de descoberta e definição.

Nós obtemos mais valor em conversas sobre por que alguém vai usar o produto do que em discussões em torno de como o produto vai funcionar. Nós obtemos mais valor de conversas em torno de como o produto será usado do que a partir de discussões em torno de quanto custa para fazê-lo.

Pensamento prático

Um enorme desafio em comunicação é melhor descrito por Jeff Patton em seu livro User Story Mapping.

Quando as pessoas falam sobre “o produto”, na minha experiência, todos na sala terão todo o prazer levar a conversa adiante, cada um se referindo ao “produto” sem ninguém esclarecer exatamente o que ele significa.

Quando as pessoas falam sobre “o problema” que pretendemos que o produto seja usado para ajudar a resolver, é comum que a conversa seja para reiterar, refinar, ou pelo menos de referenciar o problema sobre o qual estamos falando.

Eu não sei por que isso se resolve de formas diferentes, mas é o que parece acontecer. Talvez nós tenhamos um psicólogo cognitivo na audiência que possa lançar alguma luz?

Independentemente disso, o problema viável mínimo parece ser algo que as pessoas estão confortáveis em esclarecer na conversa.

Resolvendo o problema

Eu começo a me apoiar sobre outro gigante, Gojko Adzic e seu livro Impact Mapping, como o meu jiu jitsu pessoal de gerenciamento de produtos. A abordagem de Gojko me ajuda a definir muito rapidamente o que significa para meu ou minha usuário/a resolver o seu problema.

Ao focar nos resultados (há, de fato, muitas maneiras de chegar a isso – eu só achei o Gojko mais atraente), você descobre que a solução do problema que você originalmente tinha a intenção de resolver pode não ser suficiente.

Seu produto viável mínimo pode resolver metade do problema. A solução de metade de um problema é a criação de metade de um produto. Pode haver casos em que isso faz sentido – histórias divididas, entrega incremental etc.  Mas não faz sentido por muito tempo.

Quantas vezes você fica interessado em comprar metade de uma solução para um problema que você está enfrentando? Quando as luzes de freio do seu carro queimam, você pediria ao eletricista para apenas corrigir uma delas agora, e agendar uma visita de acompanhamento no próximo mês para consertar a outra?

Definir o problema viável mínimo é definir o produto viável mínimo.

O problema viável mínimo é aquele que você resolve completamente. Você só pode resolvê-lo em um contexto ou escopo muito estreito. Você só pode resolvê-lo para um pequeno grupo de usuários ou um subconjunto do seu mercado final. Você só pode resolvê-lo de forma adequada, sem criar uma solução verdadeiramente competitiva.  Mas, para aquele cliente, naquela única situação, você o resolve completamente.

Lembre-se – você aumenta a receita um cliente de cada vez. Isso soa como superficial, mas inverta a perspectiva. Aquele cliente está considerando vários fornecedores para essa venda. Será que o cliente escolhe o fornecedor que é medíocre (e também medíocre para outros clientes), ou será que o cliente escolhe o fornecedor que é perfeito para ele (mesmo que imperfeito para outros clientes)?

Os problemas por trás do problema

Imagem maior

O diagrama acima é uma visão real das dependências de um ecossistema para um produto. Ele está desfocado, porque é real. O que ele mostra, no canto superior esquerdo, é o “problema alvo” a ser resolvido. Essa meta é um candidato para o problema viável mínimo.

Cada conexão em vermelho diz “require”, porque para um determinado usuário resolver o problema em sua caixa desfocada requer a assistência de outro usuário. Esse outro usuário, em seguida, tem que resolver o problema de “ajudar o primeiro usuário”. Ou pode ser que haja um contexto operacional, como “monitorar o desempenho [do grupo do primeiro usuário] resolvendo seu problema, para que possamos afinar a solução”. Quando você está fazendo o trabalho ou projetando produtos inteiros, você vê (ou deveria ver) isso em cada compromisso.

No ecossistema de um problema-espaço complexo, descobrimos que existem várias partes associadas para resolver adequadamente o problema do usuário.  Cada cor diferente de usuário reflete um usuário diferente envolvido na solução do problema foco para o usuário foco. Essa teia de problemas interdependentes é o resto do iceberg.

Um diagrama de cebola para esse mesmo problema-espaço nos permite também ver muito rapidamente (mesmo com essa versão editada) que existem três sistemas (ou interfaces do sistema) através dos quais diferentes usuários utilizam direta ou indiretamente o nosso produto para resolver os seus problemas.

Construindo uma ponte na lacuna entre os processos

Estes pontos de vista do problema-espaço ajudam a garantir que estamos resolvendo um problema importante – que é a minha definição preferida de um produto viável. Como um bônus, eles ajudam a preencher a lacuna entre o pensamento abstrato de uma equipe de gerenciamento de produto do pensamento concreto da equipe de engenharia que irá criar a solução e a equipe executiva que quer “saber o que é isso”.

***

Scott Sehlhorst faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://tynerblain.com/blog/2016/07/22/minimum-valuable-problem/#more-1956