O que é um Produto Mínimo Viável?

Ao ir de 0 a > 1, a sabedoria da engenharia nos diz que é importante começar com um MVP. Afinal, construir um MVP permite que você obtenha feedback antecipado, alcance os clientes mais cedo e descubra incógnitas desconhecidas. Eu compro esse argumento - na minha experiência, é muito fácil gastar muito tempo trabalhando em coisas que acabam não importando e os MVPs atenuam essa preocupação. Mas o que é um MVP? Você conhece um quando vê um? Um gosto desenvolvido com a experiência? Vamos decompô-lo.

Por que construir um MVP?

Primeiro vamos recapitular porque queremos construir MVPs.

A engenharia é fundamentalmente sobre a construção de sistemas sob restrições. O objetivo número um de um MVP é entregar uma fração significativa de valor agregado com uma pequena fração do esforço. Isso permite que você obtenha feedback antecipado para ajudá-lo a priorizar o restante do trabalho. Muitas vezes, permite que você descarte grandes partes do trabalho e se concentre no que importa.

Em minha experiência, também descobri que essa mentalidade traz um enorme benefício cultural e experimental para a equipe de engenheiros que trabalha no projeto. As restrições o forçam a trabalhar no que importa. Conseguir mostrar o progresso é satisfatório. Além disso, você evita construir peças que não são tão úteis. É uma boa prática não se apegar emocionalmente ao seu código, porque você pode precisar jogá-lo fora. Apesar disso, ainda é muito bom ver que a maior parte do seu trabalho é bem aproveitada e é triste ter que abrir mão de algo que você projetou demais.

O que é um MVP?

Sem surpresa, definir um MVP é mais difícil do que descrever por que você deseja um. Vejamos a expansão do acrônimo. Um MVP é um produto de complexidade mínima, viável em utilidade e um produto que deve ser usado por alguém representativo do seu público.

Esses objetivos às vezes são conflitantes, então como realmente navegamos nisso?

Um MVP NÃO significa uma experiência quebrada. Embora deva ser mínimo em complexidade, deve ser completo no que está tentando fazer. Não precisa tentar fazer tudo (não deveria), mas deve ser completo naquilo que tenta fazer. Toda a arte de um MVP é encontrar atalhos para reduzir a complexidade e, ao mesmo tempo, manter a viabilidade.

O escopo de corte é uma parte fundamental disso. Por exemplo, um MVP de S3 para uso em um site básico pode querer get, pute delete. Provavelmente não precisa de URLs pré-assinados, uploads em várias partes e é melhor não ter ACLs complexas.

Dito isto, cabe a você, como engenheiro e designer de produto, escolher quais peças são as peças fundamentais que você está tentando entregar. Se o seu produto não for viável sem ACLs, escolha um conjunto mínimo de ACLs e entregue-os completamente sem complexidade e reduza o escopo do restante.

Finalmente, um MVP tem que sair para alguém. Talvez vá para alguns adotantes iniciais. Talvez vá para seus amigos ou seu chefe. Talvez você o lance para todos com um aviso “beta”. Tudo isso é ótimo, mas ALGUÉM deveria usá-lo antes de você continuar trabalhando nele.

Como é um MVP de sucesso?

Existem alguns cenários pós-MVP bem-sucedidos.

• As pessoas adoram e desejam mais. Crie mais recursos!
• As pessoas adoram como é. Deixe como está. Mantenha suas ideias de recursos arquivadas para o futuro, quando elas serão úteis. No mínimo, será um artefato divertido de se olhar em um ou dois anos com nostalgia. Na melhor das hipóteses, é o seu roteiro.
• As pessoas não estão animadas. Repita (ou jogue fora)!

Continue lançando código!