MVP seria um paliativo para uma restrição que já não existe, defende texto

O texto publicado no research.oguzbilgic.com defende que o MVP foi uma otimização para uma estrutura de custos específica, em que tempo de engenharia era o insumo mais escasso. O autor relata que uma equipe pequena construiu um produto do zero em cerca de uma semana, e que ele foi lançado e vendeu cinco dígitos. Para ele, se a versão completa custa o que a versão mínima custava, lançar o mínimo não é economia, é só entregar menos. A proposta é o maximum viable product: a versão mais completa da solução para o problema inteiro do cliente. Um detalhe de nomenclatura: o contexto técnico da pauta aponta 'capacity' como entidade principal, mas o texto trata de uma tese sobre estratégia de produto, não descreve um software com repositório próprio. A autoria também não está identificada no material.

O artigo não vende a ideia sem ressalvas. Ele lista o que não ficou mais barato: errar (o papel real do MVP era aprender, então o ajuste seria 'tempo mínimo até o aprendizado, escopo máximo por iteração'), manter superfície de produto (suporte, QA, segurança, integrações, documentação), a compreensão do cliente, que não absorve produtos infinitos, e domínios regulados, onde 'máximo' significa correto e profundo, não amplo. Também aponta que o gargalo se desloca para a adoção, com vendas virando ativação e receita migrando da aquisição para a expansão, com add-ons e compras dentro do app.

A tese conversa com a cobertura anterior do CEVIU, mas vai além dela. Em 2 de março de 2026, o CEVIU publicou 'A Era do Produto Mínimo Amável', sobre o MLP como versão inicial digna de amor, e em 3 de março de 2026 veio 'A Era do Produto Mínimo Amável: Por Que MLPs Superam MVPs', com o argumento de que a funcionalidade básica ficou barata e fácil de copiar. Ali a resposta ao MVP era elevar a qualidade percebida do mínimo. Agora o argumento é ampliar o escopo da primeira entrega. Em 18 de março de 2026, 'A Contratação Mais Subestimada Agora é um Grande Profissional de Produto' já apontava que o gargalo saiu da engenharia, ideia que o texto atual reforça ao falar de adoção. E em 2 de outubro de 2026, 'Lean LaunchPad Repensa Estratégia' sustentava que a validação com o cliente continua central mesmo com a IA acelerando a construção, o que casa com a ressalva do autor sobre o custo de estar errado.

Para quem toca produto, a leitura útil é revisar a conta, não abandonar a validação. Se construir ficou barato, o escopo do primeiro lançamento deixa de ser decisão de capacidade e vira decisão de problema. Isso empurra o trabalho do PM para descoberta, priorização e métricas de ativação, não de entrega. Vale desconfiar do exagero: o relato é de uma única equipe, e o próprio texto admite que suporte, manutenção e coerência da plataforma custam caro.