o MVP fez o trabalho dele: provou que tem gente disposta a usar e a pagar. O erro vem depois — tratar o que provou a hipótese como se fosse o produto que vai escalar. São coisas diferentes, com objetivos opostos, e confundir as duas custa caro exatamente no momento em que o negócio começa a dar certo.

MVP é argumento. Produto é compromisso. A transição de um pro outro é engenharia deliberada, não consequência automática do sucesso.

§ 01 / TeseMVP otimiza aprendizado. Produto otimiza confiança.

Todo atalho que faz sentido no MVP — código colado, processo manual por trás da cortina, zero observabilidade — existe pra aprender rápido e barato. Os mesmos atalhos viram dívida perigosa no instante em que usuário real depende do sistema. O MVP é otimizado pra velocidade de aprendizado; o produto, pra confiabilidade. Não dá pra servir os dois com a mesma arquitetura.

§ 02 / Os sinaisQuando o MVP começa a cobrar.

A hora da transição se anuncia. Os sinais mais comuns:

  • O manual por trás vira gargalo. Aquilo que “a gente faz na mão por enquanto” agora consome o time inteiro.
  • Todo bug é surpresa. Sem monitoramento e teste, você descobre os problemas pelo cliente, não pelo sistema.
  • Cada feature nova quebra duas antigas. A base feita pra provar a hipótese não foi feita pra crescer.
  • Ninguém quer tocar em certo trecho do código. Medo de código é dívida técnica falando alto.
O MVP não falha por ser ruim. Falha por ter sido bem-sucedido demais pra estrutura que o sustenta.

§ 03 / A transiçãoReescrever o que aguenta, manter o que ensina.

Transição não é jogar tudo fora e recomeçar — “rewrite from scratch” é a forma mais cara de perder o aprendizado embutido. Também não é remendar pra sempre. O caminho é cirúrgico: identificar o que vira coração do produto e reescrever com fundação séria; manter o que ainda é descoberta como descoberta. Fundação séria quer dizer integração de verdade, observabilidade, teste, governo de custo e dono operável — tudo o que o MVP pôde ignorar e o produto não pode.

Padrão Noûs
Quando entra na transição de MVP pra produto, nosso primeiro entregável costuma ser um não fundamentado pra metade do escopo. Nem tudo que está no MVP merece virar produto. Decidir o que escala — e o que volta a ser experimento — é a parte da cabeça de negócio, e vem antes de qualquer linha de código.

§ 04 / EncerrandoO sucesso do MVP é o começo do trabalho sério.

Comemore a validação — e entenda que ela é a largada, não a chegada. O produto que escala é construído com decisões que o MVP teve o luxo de adiar. Adiar de novo, agora, é trocar velocidade de aprendizado por fragilidade em produção, no pior momento possível.

MVP prova que vale a pena. Produto é o que você constrói porque valeu. Tratar os dois como a mesma coisa é o erro mais caro de quem acabou de acertar.

fim  ·  nota de campo nº 54  ·  noûs / mar 26