Um MVP É Um Experimento Científico Projetado Para Reduzir Incerteza

No primeiro ano da minha carreira, trabalhei em quatro projetos de software. Cada um levou três meses. Cada um tinha uma equipe entre três e quatro pessoas. Apenas um dos projetos foi realmente utilizado pelos clientes para os quais foi construído.

Os outros três foram desperdício. Desperdício evitável e caro.

Não posso compartilhar detalhes, mas também não preciso. Os números falam por si: nove meses de esforço coletivo de engenharia, perdidos. Não porque alguém trabalhou mal. Não porque o código era ruim. E sim porque ninguém perguntou, antes de escrever uma única linha de código, se aquele sistema precisava existir.

Esse é o erro mais comum e mais custoso no desenvolvimento de software de produtos. Equipes tratam um MVP como um produto pequeno, quando deveria ser um experimento científico projetado para reduzir incerteza.

Três conceitos

Um experimento científico é um método estruturado para testar uma hipótese e coletar dados que informam uma decisão. A propriedade crítica é que ele deve ser refutável: você define o que é sucesso e fracasso antes de executar o teste. Um experimento que só pode ter sucesso não é um experimento. É uma encenação.

Incerteza é a distância entre o que você acredita sobre seu mercado e o que é realmente verdade. Startups não falham principalmente por causa de concorrentes ou falta de financiamento. Elas falham porque construíram algo que ninguém precisava, e construíram por meses antes de descobrir.

Um MVP é o artefato mínimo necessário para responder uma questão específica sobre seu negócio. Não a primeira versão de um produto. Não um protótipo. O instrumento que você constrói para rodar um teste.

O experimento

A ciência tem uma estrutura limpa: hipótese, desenho do experimento, coleta de dados, conclusão.

O que torna algo científico não é o equipamento ou a área de estudo e sim o compromisso de estar disposto a estar errado. Um experimento é projetado para produzir um resultado que pode mudar sua mente, se você já sabe a resposta que quer e está apenas gerando evidências para ela, não está rodando um experimento.

Toda suposição que você faz sobre o que os usuários querem, quanto pagarão, e qual problema realmente têm é uma hipótese. Não um fato. Uma hipótese. Quanto mais cedo você tratar dessa forma, mais honestamente abordará a questão de como testá-la.

Um experimento sem uma hipótese pré-definida é apenas ruído. Você interpretará todos os dados que conseguir da forma mais conveniente. Toda equipe que vejo fazer isso racionaliza da mesma forma depois: “Aprendemos muito.” Talvez. Mas não aprenderam o que se propuseram a aprender, porque nunca decidiram o que era.

O inimigo

Incerteza não é um problema que você resolve uma vez. É a condição permanente de qualquer negócio fazendo algo novo.

The Lean Startup de Eric Ries extrai muito da filosofia de manufatura da Toyota, que trata o desperdício como o inimigo operacional principal. No desenvolvimento de software de produtos, a forma mais cara de desperdício é construir algo que ninguém precisa. Não construir mal, mas simplesmente construir.

Li The Lean Startup duas vezes. A primeira vez, a maior parte passou batido. Entendia as palavras, mas tudo era muito “estrangeiro” para mim. A segunda vez, depois de tentar criar uma startup eu mesmo e cair de cara no chão, não conseguia passar três páginas sem ficar sem papel para anotações. O que mudou não foi o livro e sim o meu contexto de vida. O livro parecia diferente uma vez que vivenciei o que os clientes daqueles três projetos anteriores sentiram, ou pelo menos, o que imagino que sentiram.

O objetivo de uma startup em seu estágio inicial não é crescer. É reduzir incerteza de forma rápida e barata. O crescimento segue de saber o que é verdade, mas tudo antes disso são só apostas.

Dois tipos de incerteza importam mais no início. A primeira é desejabilidade: as pessoas realmente querem isso? A segunda é viabilidade: você consegue construir e sustentar a um preço que pagarão? Ambas precisam ser testadas, mas a maioria das equipes só se preocupa com a segunda.

O MVP como instrumento

Um MVP é o aparato experimental. O artefato mínimo necessário para testar uma suposição específica.

O que separa um MVP de um protótipo é a intenção. Um protótipo testa se algo pode ser construído. Um MVP testa se deveria. Podem parecer idênticos por fora. A diferença está na pergunta que foram projetados para responder.

A forma certa de desenhar um MVP é de trás para frente. Não “qual é a menor versão do nosso produto?” mas “qual é a suposição única que, se errada, mata esse negócio?” e então “qual é a forma mais barata de testar essa suposição?”

Às vezes a resposta é um produto. Mais frequentemente é uma landing page, um processo manual, uma planilha, ou dez conversas com clientes em potencial. O ponto não é lançar algo pequeno. O ponto é descobrir o que é verdade da forma mais barata possível.

Há uma racionalização que já ouvi mais de uma vez, geralmente de desenvolvedores que construíram algo que sabiam de antemão que não tinha validação real: “O cliente queria, eu construí, foi uma situação de ganho mútuo.” Não foi. O cliente gastou dinheiro e tempo em algo que não funcionou. O desenvolvedor produziu desperdício, cobrou pelo trabalho, e todos seguiram sem aprender o que realmente precisavam aprender. O mundo tem um produto fracassado a mais e todos envolvidos contam a si mesmos uma história confortável sobre por que está tudo bem.

Saber que um projeto provavelmente falhará e fazer de qualquer forma pelo dinheiro é uma escolha, não algo circunstancial e as consequências impactam pessoas reais.

Conclusão

Uma vez que você vê um MVP como um experimento, toda decisão sobre escopo fica respondível com uma pergunta: isso nos ajuda a testar a hipótese mais rápido?

Não “essa é uma boa feature?” Não “o cliente quer isso?”.

Você para de construir o que não precisa aprender para saber o que deve conhecer. Esse é o ganho. Não apenas eficiência. Honestidade sobre o que está fazendo e por quê.

Um MVP não é a primeira versão do seu produto. É um experimento científico projetado para reduzir incerteza, e quanto mais cedo você tratar dessa forma, menos desperdiçará construindo a coisa errada.