🛹 MVP: O Minimo que Entrega Valor
MVP nao e "a versao quebrada do produto". Nao e a versao sem CSS. Nao e a versao com bugs que voce promete arrumar "depois". MVP e a versao mais enxuta que resolve o problema principal do usuario de forma funcional e testavel. A palavra-chave e "viable", nao "minimum".
A analogia classica do skateboard ilustra o ponto. Voce nao constroi um carro tirando as rodas. Voce constroi um skateboard, que ja resolve o problema de ir do ponto A ao ponto B. Depois evolui para bicicleta, moto e carro. Cada versao e completa e funcional por si so.
Conceito Principal: Skateboard > Bicicleta > Carro
Henrik Kniberg popularizou a analogia de transporte para explicar MVP. O erro classico e construir a roda do carro na v1, a porta na v2, o motor na v3. Nenhuma dessas versoes funciona sozinha. A abordagem correta e entregar algo que funciona em cada iteracao.
Skateboard
Resolve o problema de forma minima. Login + 1 tela principal + 1 acao core. Feio, simples, funcional.
Bicicleta
Mais eficiente. Dashboard com metricas, fluxo refinado, UX melhorada. Feedback dos primeiros usuarios incorporado.
Carro
Produto maduro. Integrancoes, automacoes, analytics, multi-usuario. So chega aqui com validacao real.
Por que MVP e Mais Importante com IA
IA tornou construir software absurdamente mais rapido. Isso e uma faca de dois gumes. Quando voce pode gerar 10 features em um dia, a tentacao de enfiar tudo na v1 e enorme. Mas velocidade de construcao nao muda a velocidade de validacao. Seu usuario ainda precisa de tempo para testar, entender e dar feedback.
Dados do Y Combinator mostram que startups que lancam com menos de 5 features tem 3x mais chance de encontrar product-market fit do que startups que lancam com 15+. A razao e simples: com menos features, o feedback e mais claro e voce sabe o que esta funcionando.
Dica Pratica: Exemplos Reais de MVPs com IA
Muitos produtos de sucesso lancaram como MVPs absurdamente simples. O segredo e identificar a unica coisa que gera valor e entregar isso perfeitamente:
Stripe: Lancou so com 7 linhas de integracao. Sem dashboard, sem analytics. So pagamento.
Dropbox: MVP foi um video de 3 minutos mostrando o conceito. Nem tinha produto funcional.
Buffer: Landing page com precos. Se alguem clicava "comprar", aparecia "ainda nao esta pronto". Validou demanda antes de construir.
Fazer
- ✓Definir a unica acao core do produto
- ✓Entregar algo funcional em cada versao
- ✓Lancar rapido e coletar feedback real
- ✓Testar com 5-10 usuarios antes de expandir
Evitar
- ✗Tratar MVP como "versao ruim" do produto final
- ✗Adicionar features porque a IA gera rapido
- ✗Esperar o produto ficar "perfeito" para lancar
- ✗Construir o carro antes de validar o skateboard
🔀 User Flows e Wireframes Mentais
Antes de pensar em telas, pense em fluxos. Um user flow e o caminho que o usuario percorre para completar uma tarefa no seu produto. Se voce nao mapear esse caminho antes de construir, vai acabar com telas bonitas que nao se conectam de forma logica.
Wireframes mentais sao uma tecnica onde voce descreve cada tela em uma unica frase, sem desenhar nada. Isso forca clareza: se voce nao consegue descrever uma tela em uma frase, ela provavelmente esta fazendo coisas demais.
Conceito Principal: Pensar em Fluxos, Nao em Telas
Um user flow tem tres elementos: entry points (de onde o usuario vem), decision trees (decisoes que ele toma no caminho) e error states (o que acontece quando algo da errado). A maioria dos builders esquece os error states, e e la que a experiencia do usuario quebra.
Exemplo: User Flow de um SaaS de Gestao
1.Entry: Usuario acessa o site pela primeira vez (landing page)
2.Decision: Cria conta ou faz login?
3.Action: Ve o dashboard com seus projetos
4.Core: Cria novo projeto ou acessa existente
5.Output: Executa a acao principal (ex: gera relatorio)
E.Error: O que acontece se o login falhar? Se nao tem projetos? Se a acao da erro?
Wireframes Mentais: Descricao em 1 Frase
A tecnica de wireframe mental e simples: para cada tela do seu produto, escreva uma unica frase descrevendo o que o usuario ve e o que ele pode fazer. Essa frase vai ser a base dos seus prompts para a IA gerar as telas.
Landing: "Pagina com headline, 3 beneficios, CTA de cadastro e social proof."
Login: "Form com email e senha, botao de entrar, link para cadastro e recuperar senha."
Dashboard: "Cards com metricas principais, lista de projetos recentes, botao de novo projeto."
Core Feature: "Area de trabalho com sidebar de opcoes, area central para a acao principal, botao de salvar/exportar."
Settings: "Tabs de perfil, plano e notificacoes. Forms simples com botao salvar."
Dica Pratica: IA Gera Wireframes a Partir de Descricoes
Ferramentas como v0 da Vercel, Claude e Cursor conseguem gerar componentes visuais diretamente das suas descricoes de wireframe mental. O prompt ideal combina o wireframe mental com restricoes de stack:
// Prompt para gerar wireframe:
"[Contexto] Projeto Next.js + Tailwind. Tela de dashboard.
[Descricao] Cards com metricas (3 cards: total usuarios, receita mensal, tarefas ativas), lista dos 5 projetos mais recentes com status, botao 'Novo Projeto' no topo direito.
[Restricao] Mobile-first, sem lib de UI, dados mockados.
[Formato] Um arquivo page.tsx."
Fazer
- ✓Mapear o fluxo completo antes de desenhar telas
- ✓Incluir error states em todo fluxo
- ✓Descrever cada tela em 1 frase
- ✓Usar wireframes mentais como base dos prompts
Evitar
- ✗Comecar pelo design visual antes do fluxo
- ✗Ignorar o que acontece quando da erro
- ✗Criar telas que nao se conectam logicamente
- ✗Gastar horas no Figma antes de validar o fluxo
📱 Lista de Telas da v1
Se a v1 do seu produto tem mais de 7 telas, seu escopo esta grande demais. Ponto final. Cada tela adicional e mais codigo para escrever, mais bugs para resolver, mais edge cases para tratar, mais tempo ate o lancamento. A regra de ouro e: 5 telas ideais, 7 no maximo absoluto.
A lista de telas nao e uma lista de desejos. E uma lista de necessidades. Cada tela precisa justificar sua existencia respondendo: "sem essa tela, o usuario consegue completar o fluxo principal?" Se a resposta for sim, a tela nao e essencial para a v1.
Conceito Principal: As 5 Telas Essenciais
Quase todo SaaS pode ser reduzido a 5 telas essenciais. Nao significa que seu produto so vai ter 5 telas para sempre. Significa que a v1 funciona com 5. O resto vem depois, com dados reais guiando as decisoes.
Landing Page
Primeiro contato. Headline, beneficios, CTA. Convence o visitante a criar conta. Sem landing page, ninguem sabe que seu produto existe.
Login / Signup
Autenticacao. Pode ser uma unica tela com toggle entre login e cadastro. OAuth (Google, GitHub) simplifica muito.
Dashboard
Visao geral. O usuario logou e precisa ver o estado atual: metricas, itens recentes, acoes rapidas. Centro de comando.
Core Feature
A razao de existir do seu produto. A tela onde o usuario faz A COISA. Se e um chat, e aqui. Se e um editor, e aqui. Se e um gerador de relatorios, e aqui.
Settings
Configuracoes basicas: perfil, senha, preferencias. Na v1, mantenha simples. Nada de tabs infinitas.
Mais Telas = Mais Problemas
= +2-3 horas de dev, +1 rota de API, +N edge cases, +1 lugar para bugs
= ~20 rotas de API, ~30 componentes, ~50 testes. Gerenciavel para 1 pessoa.
= ~60 rotas, ~100 componentes, ~150 testes. Precisa de time. Nao e MVP.
Dica Pratica: O Teste da Necessidade
Para cada tela que voce quer incluir na v1, faca o teste: "Se eu remover essa tela, o usuario ainda consegue usar o produto?" Se sim, tire da v1. Exemplos praticos:
Pagina "Sobre"? Nao essencial. Coloque no rodape da landing.
Pagina de precos? Na v1, pode ser uma secao da landing. Tela separada so quando tiver multiplos planos.
Perfil publico? A menos que seja core do produto (como Twitter), nao e v1.
Admin panel? Na v1, use o Supabase/Firebase dashboard direto. Zero telas extras.
Fazer
- ✓Limitar a 5-7 telas na v1
- ✓Justificar cada tela com o teste da necessidade
- ✓Combinar funcionalidades em telas existentes
- ✓Documentar telas removidas como "v2"
Evitar
- ✗Criar tela separada para cada funcionalidade
- ✗Incluir admin panel na v1
- ✗Copiar a quantidade de telas de apps maduros
- ✗Adicionar "so mais uma tela" depois de definido
📊 Prioridade MoSCoW
MoSCoW e um framework de priorizacao criado por Dai Clegg na Oracle nos anos 90 e usado ate hoje por times ageis do mundo inteiro. O nome vem das iniciais: Must Have, Should Have, Could Have, Won't Have. Os "o"s sao so para formar a palavra.
A forca do MoSCoW esta na clareza que ele traz. Em vez de uma lista infinita de features com prioridades vagas ("alta", "media", "baixa"), voce classifica cada feature em uma de quatro categorias com definicoes rigidas. Nao tem espaco para ambiguidade.
Framework MoSCoW: As 4 Categorias
M - Must Have (Obrigatorio)
Sem isso, o produto nao funciona. E o bloqueador de lancamento. Se uma feature Must nao esta pronta, voce nao lanca.
Exemplo: Autenticacao, tela principal, fluxo core, persistencia de dados.
S - Should Have (Importante)
Importante, mas o produto funciona sem. Entra na semana 2 ou sprint 2. Se faltar tempo, pode esperar.
Exemplo: Recuperacao de senha, filtros avancados, notificacoes por email, export CSV.
C - Could Have (Desejavel)
Seria bom ter. Melhora a experiencia, mas nao e critico. Entra no mes 2 se tiver tempo e se os dados mostrarem demanda.
Exemplo: Dark mode, atalhos de teclado, integracao com Slack, avatar customizado.
W - Won't Have (Descartado)
Nao vai entrar. Nem agora, nem no curto prazo. Pode ser revisitado na v3 ou nunca. Essa categoria e a mais importante do framework.
Exemplo: App mobile, multi-idioma, marketplace de plugins, AI voice, chat em tempo real.
Matriz de Decisao: Exemplo Real
Veja como classificar features de um SaaS de gestao de projetos com IA:
| Feature | MoSCoW | Quando |
|---|---|---|
| Login com email/senha | Must | Sprint 1 |
| Dashboard com projetos | Must | Sprint 1 |
| Criar/editar tarefas | Must | Sprint 2 |
| Recuperar senha | Should | Semana 2 |
| Filtros por status | Should | Semana 3 |
| Dark mode | Could | Mes 2 |
| App mobile | Won't | Nunca (v1) |
| Multi-idioma | Won't | Nunca (v1) |
Dica Pratica: A Regra 60-20-20
Uma distribuicao saudavel de MoSCoW para um MVP:
~60% Must Have: As features essenciais que fazem o produto funcionar. Se voce tem 10 features, 6 sao Must.
~20% Should Have: 2 features importantes para a segunda semana.
~20% Could + Won't: 2 features que voce reconhece como desejaveis mas corta conscientemente.
Se mais de 80% das suas features sao "Must", voce esta classificando errado. Seja honesto: e realmente bloqueador de lancamento?
Fazer
- ✓Classificar TODA feature antes de comecar a construir
- ✓Ser brutal: Must so se for bloqueador de lancamento
- ✓Ter pelo menos 2-3 itens no Won't Have
- ✓Revisar a classificacao apos feedback de usuarios
Evitar
- ✗Colocar tudo como Must Have
- ✗Ignorar a categoria Won't Have
- ✗Mudar classificacoes no meio do sprint
- ✗Classificar sem envolver stakeholders
🚫 Lista de Exclusao: O que NAO Fazer
A lista de exclusao e o documento mais importante do seu projeto. Mais importante que o roadmap, mais importante que o backlog, mais importante que o design system. Parece contraditorio, mas a lista do que voce NAO vai fazer salva mais tempo do que a lista do que voce vai fazer.
O conceito vem de Warren Buffett, que diz que pessoas bem-sucedidas dizem "nao" para quase tudo. No contexto de produto, isso significa criar um contrato explicito consigo mesmo (e com seu time, se tiver) sobre limites inegociaveis. Quando a tentacao de adicionar "so mais uma feature" aparecer, voce abre a lista de exclusao e lembra: "ja decidimos que isso nao entra".
Conceito Principal: O Anti-Roadmap
Um roadmap diz "vamos construir X, Y e Z". Um anti-roadmap diz "nao vamos construir A, B, C, D, E, F, G". A segunda lista e maior, e e isso que a torna poderosa. Ela define os limites do projeto e protege o foco.
Cada item na lista de exclusao deve incluir tres coisas: o que (a feature), por que nao (a justificativa) e quando talvez (em que condicao pode ser reconsiderada).
Exemplo: Lista de Exclusao de um SaaS de Chat com IA
App mobile nativo
Por que: PWA resolve 90% dos casos. Custo de manter 2 plataformas e proibitivo. Quando: se passar de 10k usuarios ativos mensais.
Admin panel customizado
Por que: Supabase dashboard resolve. Quando: se precisar de operacoes que o Supabase nao suporta.
Multi-idioma (i18n)
Por que: foco no mercado BR primeiro. Quando: se validar demanda internacional significativa.
Integracao WhatsApp
Por que: API cara ($), complexa, e nao e core do produto. Quando: se for a feature mais pedida por pagantes.
Marketplace de plugins
Por que: complexidade absurda para v1. Quando: talvez v3, se o ecossistema justificar.
O Custo Invisivel de Cada Feature
Toda feature tem um custo visivel (tempo de dev) e custos invisiveis que se acumulam ao longo do tempo. Pesquisas de engenharia de software estimam que para cada hora gasta construindo uma feature, voce vai gastar 4-6 horas mantendo ela ao longo da vida do produto.
custo de manutencao vs custo de construcao para cada feature
das features em produtos SaaS nunca sao usadas pelos usuarios (Pendo, 2024)
Dica Pratica: Kill Your Darlings
A expressao "kill your darlings" vem da literatura: corte as partes que voce mais ama no texto se elas nao servem a historia. No produto, e igual: corte as features que voce mais quer construir se elas nao servem ao usuario na v1.
Crie a lista de exclusao antes de comecar a construir e trate como contrato. Cole em algum lugar visivel. Quando a tentacao aparecer ("sera que devo adicionar um chatbot?"), abra a lista e diga "nao, ja decidimos".
Uma boa lista de exclusao tem pelo menos o dobro de itens da sua lista de features. Se voce tem 6 features na v1, tenha pelo menos 12 itens na lista de exclusao.
Fazer
- ✓Criar a lista de exclusao ANTES de comecar
- ✓Incluir "por que nao" e "quando talvez" em cada item
- ✓Ter pelo menos 2x mais exclusoes que features
- ✓Tratar como contrato, nao como sugestao
Evitar
- ✗Nao ter lista de exclusao
- ✗Adicionar excecos "so dessa vez"
- ✗Incluir features na v1 porque a IA gera rapido
- ✗Mudar a lista toda semana
📝 Exercicio: Documento de Escopo do seu SaaS
Este exercicio junta tudo que voce aprendeu nos topicos 1-5 em um unico documento de escopo de uma pagina. Esse documento vai ser a bussola do seu projeto. Toda decisao de "incluo ou nao?" passa por ele. Todo prompt para a IA referencia ele. Toda conversa sobre o produto comeca nele.
O documento de escopo nao e um business plan de 30 paginas. E um documento vivo, curto e afiado, que cabe em uma pagina A4. Se precisa de mais de uma pagina, o escopo esta grande demais.
Template: Documento de Escopo (1 pagina)
1. Product Sentence
Uma unica frase que define o produto:
Exemplo: "Um dashboard web que ajuda freelancers a organizar clientes e projetos atraves de automacao com IA."
2. Lista de 5 Telas
As telas da v1 com wireframe mental (1 frase cada):
1. Landing: [descricao em 1 frase]
2. Auth: [descricao em 1 frase]
3. Dashboard: [descricao em 1 frase]
4. Core Feature: [descricao em 1 frase]
5. Settings: [descricao em 1 frase]
3. Tabela MoSCoW
Classifique suas features:
Must: [3-5 features essenciais]
Should: [2-3 features importantes]
Could: [1-2 features desejaveis]
Won't: [3-5 features descartadas]
4. Lista de Exclusao
Pelo menos 8 itens que voce NAO vai construir:
Para cada item: O que | Por que nao | Quando talvez
5. Timeline
Cronograma de 2 semanas:
Semana 1: Setup + Auth + Dashboard + Core Feature (Must Haves)
Semana 2: Polish + Should Haves + Deploy + Landing Page
Por que 1 Pagina e Suficiente
Jeff Bezos e famoso por proibir PowerPoints na Amazon e exigir "narrativas de 6 paginas". Para startups e projetos solo, ate 6 paginas e demais. Uma pagina forca voce a ser conciso e priorizar o que realmente importa.
Estudos da Harvard Business Review mostram que documentos de planejamento mais curtos sao mais consultados e mais seguidos. Um doc de 30 paginas ninguem abre depois da primeira semana. Um doc de 1 pagina voce cola na parede e consulta todo dia.
Dica Pratica: Use a IA para Revisar seu Escopo
Depois de preencher o template, use este prompt para a IA fazer uma revisao critica:
// Prompt de revisao de escopo:
"Analise este documento de escopo de um MVP SaaS:
[Cole seu documento aqui]
Avalie: 1) O escopo e realista para 2 semanas com Vibe Coding? 2) Alguma tela pode ser combinada ou eliminada? 3) Algum Must Have e na verdade Should Have? 4) A lista de exclusao esta completa? 5) O user flow faz sentido? Seja direto e critico."
A IA vai apontar furos que voce nao viu. E mais facil cortar escopo no papel do que depois de construido.
Fazer
- ✓Preencher TODOS os 5 campos do template
- ✓Caber em 1 pagina (se nao cabe, corte)
- ✓Pedir revisao da IA antes de comecar a construir
- ✓Salvar e consultar durante todo o projeto
Evitar
- ✗Escrever um doc de 10 paginas
- ✗Pular a lista de exclusao ("ja sei o que nao fazer")
- ✗Fazer sozinho sem feedback externo
- ✗Engavetar o documento e nunca mais abrir
Resumo do Modulo 1.4
Voce agora tem as ferramentas para definir escopo de forma disciplinada. O segredo nao e o que voce constroi, e o que voce escolhe nao construir.