Escopo do MVP: o que NÃO construir importa mais

O termo MVP — Produto Mínimo Viável — surgiu com Frank Robinson e se popularizou com o livro "The Lean Startup" (2011), de Eric Ries. A palavra-chave é mínimo. É também a palavra que os iniciantes menos entendem: depois de "ninguém precisa disso", o maior assassino de lançamentos é "nunca foi lançado" — o produto inchou com recursos e nunca saiu do papel. Esta lição é sobre a faca que você usa para cortar o escopo.

O loop principal do usuário

Descreva o ÚNICO caminho pelo qual as pessoas pagam: chega → faz a coisa principal → obtém o valor → retorna. Exemplo (um serviço de resumo de chamadas): envia uma gravação → obtém notas com itens de ação → envia para a equipe. Qualquer coisa que não esteja nesse loop não é MVP.

O caso clássico: a primeira versão do Instagram chamava-se Burbn e fazia check-ins, planos de encontros, pontos e fotos. Os usuários só usavam as fotos. Kevin Systrom cortou todo o resto e manteve um único loop: tirar foto → aplicar filtro → postar. Dois anos depois, o Facebook o comprou por um bilhão de dólares. O loop sustenta o produto; os extras o afundam.

A faca do escopo: três listas

1. Agora (o loop + login + pagamento): sem isso, não há produto.
2. Depois (quando você tiver usuários reais): temas, integrações, equipes, configurações.
3. Não agora (as tentações): um aplicativo móvel, uma API, um marketplace. Anote, depois esqueça até ter cem clientes.

O teste para cada recurso: "Um usuário desistiria no primeiro mês se isso estivesse faltando?" Não — então vai para a lista dois. Essa única pergunta economiza semanas.

Uma pausa socrática

Você está prestes a adicionar "configurações de notificação" ao MVP. Pare e pergunte: uma única pessoa desistiria no primeiro mês se as notificações funcionassem com configurações padrão sensatas, sem opções de ajuste? A resposta é quase sempre não. O que significa: lista de "depois".

Mitos de iniciantes

• "Um MVP é um produto ruim." Não. É um produto restrito, mas bom: uma coisa bem feita, não dez mal feitas.
• "Não vai funcionar sem login social / modo escuro / um aplicativo móvel." As coisas funcionam com o loop essencial. O polimento é adicionado depois, com usuários reais.
• "Vou adicionar só por precaução." "Só por precaução" é a frase mais cara em software. Cada recurso é código, bugs e manutenção — para sempre.

O briefing de produto para IA

Pegamos o briefing do curso de vibe coding e o transformamos em um briefing de produto:

Product: [name] — [for whom] — [core value].
Loop: [the user's steps].
Pages: landing, sign-in, the app (one working screen!), minimal settings.
Data: [entities and fields — as taught in the database lesson].
Not in the MVP: [the "later" list — put it right in the brief so the AI doesn't build extras].
Style: [reference + palette].

Essa linha "não no MVP" é o ingrediente secreto. Um assistente de IA (um modelo que escreve código a partir da sua descrição) adora ser prestativo e preencher as lacunas: peça um formulário de login e você receberá recuperação de senha, autenticação de dois fatores e uma página de configurações de perfil de brinde. Uma proibição explícita mantém o escopo sob controle.

Ritmo e diagnóstico

Um MVP construído a partir deste briefing em Lovable/Replit leva de 2 a 4 semanas de noites. Se sua estimativa for mais longa, o escopo ainda está grande: reduza o loop para um único cenário. A regra é simples — a pergunta não é "o que mais eu poderia adicionar", é "o que mais eu posso descartar mantendo o loop intacto". Cada coisa descartada é um dia que você não desperdiçou.

Onde isso dá errado: "Não consigo cortar nada, é tudo importante"

A objeção mais comum nesta lição soa como: "mas tudo no meu produto está conectado, nada pode sair." Isso é quase sempre a ilusão de estar muito perto da sua própria ideia. Teste honestamente: pegue o recurso que você "não pode remover" e imagine um usuário que nunca o abre no primeiro mês. Ele ainda obtém valor? Se sim, esse recurso não está no loop — ele pode e deve esperar. Você corta o escopo não porque os recursos são ruins, mas porque agora eles estão impedindo o produto de ser lançado. Adiado não é descartado; está esperando sua vez na lista de "depois".

Como isso se conecta a outros cursos

Os dados e entidades para o briefing (o que armazenar e como) terão sua própria lição sobre contas e dados mais adiante neste curso, e a técnica básica de construir a partir de um briefing está no curso de vibe coding. Aqui, o briefing passa de técnico para um formato de produto — com aquela linha explícita de "não no MVP".

Faça isso agora (5 minutos)

Pegue sua ideia da última lição e escreva o loop como uma linha de setas. Em seguida, liste tudo o que você quer no produto e organize-o honestamente nas três listas. Se "Agora" tiver mais de 5 itens, continue cortando.