🏗️ Framework Problema > Usuario > Solucao > MVP
A maioria dos projetos de software falha nao por falta de habilidade tecnica, mas por comecar pelo lugar errado. Devs apaixonados por tecnologia comecem pela solucao: "quero construir um app com IA que faz X". O framework correto inverte essa ordem. Voce comeca pelo problema, nao pela solucao.
Esse pipeline de quatro etapas e a espinha dorsal de todo produto de sucesso. Nao importa se voce esta construindo um SaaS de $10/mes ou uma plataforma enterprise. As perguntas sao as mesmas: qual e o problema? Quem tem esse problema? Qual e a solucao minima? E o que eu posso construir em semanas, nao meses, para provar que funciona?
O Pipeline de 4 Etapas
Problema
Tudo comeca com uma dor real. Nao "seria legal ter um app que...", mas "pessoas gastam 3 horas por semana fazendo X manualmente e detestam isso". O problema precisa ser especifico, mensuravel e frequente. Se a pessoa so sente a dor uma vez por ano, nao vale construir um produto para resolver.
Pergunte: "Se eu nao construir isso, como a pessoa resolve hoje?" Se a resposta for "com uma planilha", "manualmente", ou "nao resolve", voce tem um problema real. Se a resposta for "com 5 outras ferramentas que ja existem", pense duas vezes.
Usuario
Quem sofre com esse problema? Nao diga "todo mundo". Quanto mais especifico, melhor. "Freelancers de design que gerenciam mais de 5 clientes simultaneamente" e infinitamente melhor que "designers". A especificidade te ajuda a entender onde encontrar essas pessoas, como falar com elas, e o que elas valorizam.
Bonus: se voce E o usuario, melhor ainda. Voce sente a dor, entende o contexto, e pode ser o primeiro testador. Muitos dos melhores SaaS nasceram porque o fundador construiu a ferramenta que ele mesmo precisava.
Solucao
Agora sim, a solucao. Mas nao a solucao dos sonhos. A solucao minima que resolve o problema principal. "O usuario cola o briefing do cliente, a IA organiza em tarefas com prazos, e o usuario exporta como PDF". Uma acao, um resultado, um valor claro.
A armadilha classica e a "feature creep" na fase de ideacao. Voce pensa "e se tambem fizesse Y? E Z?" Pare. Cada feature adicionada na fase de planejamento e semanas a mais de desenvolvimento. Resolva uma coisa bem.
MVP
O Minimum Viable Product e a versao mais enxuta da solucao que ainda entrega valor. Nao e um prototipo descartavel. E um produto real, simples, que resolve o problema e pode ser usado por pessoas reais. A pergunta-chave: "qual e o menor conjunto de funcionalidades que faz alguem pagar (ou voltar a usar)?"
Com Vibe Coding, o MVP pode ser construido em dias. Isso muda tudo. Antes, o MVP era caro e demorado, entao tinha que ser perfeito no planejamento. Agora, voce pode construir, testar, jogar fora e reconstruir em uma fracao do tempo.
Exemplos de Pivots bem Sucedidos
Empresas que hoje valem bilhoes comecaram resolvendo um problema completamente diferente do produto final. O que as salvou foi o framework de pensar pelo problema, nao pela solucao:
Slack: Comecou como uma empresa de jogos (Tiny Speck). O chat interno que eles construiram para a equipe era mais valioso que o jogo. Pivotaram. Hoje vale $27B.
Instagram: Comecou como Burbn, um app de check-in. Ninguem usava o check-in, mas todo mundo usava o filtro de fotos. Pivotaram para fotos. Vendido por $1B.
Notion: A primeira versao era tao complexa que ninguem entendia. Simplificaram para resolver um problema: "quero uma ferramenta que substitua Google Docs + Trello + Evernote". Hoje: $10B.
Dica Pratica: O Teste do Elevador
Se voce nao consegue explicar seu produto em 30 segundos (o tempo de uma viagem de elevador), o escopo esta grande demais ou o problema nao esta claro. Pratique a frase:
Exemplo: "Freelancers perdem horas organizando briefings de clientes. BriefBot organiza automaticamente com IA em 30 segundos." Se a frase nao soa convincente, volte a etapa P (Problema) e refine.
Fazer
- ✓Comecar sempre pelo problema, nunca pela tecnologia
- ✓Definir o usuario com o maximo de especificidade
- ✓Limitar o MVP a uma unica acao principal
- ✓Estar disposto a pivotar baseado em feedback
Evitar
- ✗Comecar pela solucao ("quero fazer um app de...")
- ✗Definir usuario como "todo mundo"
- ✗Planejar 20 features para o MVP
- ✗Se apaixonar pela primeira ideia e se recusar a mudar
✅ Validacao de Ideia Antes de Construir
Com Vibe Coding, construir e rapido. E por isso que a tentacao de "so comecar a codar" e ainda mais forte. Mas velocidade de construcao nao substitui validacao. Construir rapido a coisa errada e pior que construir devagar a coisa certa. Voce gasta tempo, energia e motivacao em algo que ninguem quer.
A abordagem Lean Startup, criada por Eric Ries, e ainda mais relevante na era do Vibe Coding. A diferenca e que agora o ciclo Build-Measure-Learn pode acontecer em dias, nao meses. Mas o "Measure" e o "Learn" continuam sendo as partes mais importantes, e sao as que devs tendem a pular.
Metodos de Validacao (do Mais Barato ao Mais Caro)
Conversa com 5 Usuarios (Custo: $0, Tempo: 1-2 dias)
A validacao mais poderosa e a mais barata. Encontre 5 pessoas que tem o problema que voce quer resolver. Nao pergunte "voce usaria meu app?", pergunte "como voce resolve [problema] hoje?" e "quanto tempo/dinheiro voce gasta com isso?". As respostas dizem tudo.
Landing Page + Waitlist (Custo: $0-20, Tempo: 2-4 horas)
Crie uma landing page que descreve o produto como se ele ja existisse. Adicione um formulario de waitlist. Compartilhe em comunidades relevantes (Reddit, IndieHackers, Twitter, grupos de WhatsApp). Se ninguem se inscreve, ninguem quer. Se 100 pessoas se inscrevem em uma semana, voce tem sinal forte.
Smoke Test / "Wizard of Oz" (Custo: $0, Tempo: 1 semana)
Oferte o servico manualmente antes de automatizar. Se seu SaaS vai usar IA para gerar relatorios, gere os relatorios voce mesmo (com ajuda de IA) para os primeiros clientes. Se eles pagam e voltam, a demanda e real. Ai voce automatiza. O nome "Wizard of Oz" vem da ideia de que "atras da cortina" nao existe magia, so uma pessoa fazendo o trabalho.
Pre-venda (Custo: $0, Tempo: 1-2 semanas)
A validacao definitiva: alguem paga antes do produto existir. Crie uma oferta de lancamento com desconto. Se 10 pessoas pagam $20 antecipado, voce tem $200 e a certeza absoluta de que a demanda existe. Plataformas como Gumroad ou Lemon Squeezy facilitam isso.
O "Mom Test": Perguntas que Revelam a Verdade
Rob Fitzpatrick escreveu o livro "The Mom Test" para resolver um problema universal: quando voce conta sua ideia para alguem, a pessoa mente para nao te magoar. Ate sua mae diria "que otima ideia!" mesmo se for terrivel. O Mom Test ensina a fazer perguntas que geram respostas honestas:
Pergunta ruim: "Voce usaria um app que organiza seus projetos com IA?"
Pergunta boa: "Como voce organiza seus projetos hoje? Quanto tempo gasta nisso por semana?"
Pergunta ruim: "Voce pagaria $20/mes por isso?"
Pergunta boa: "Quanto voce ja gastou tentando resolver esse problema? Ja pagou por alguma ferramenta?"
Dica Pratica: A Regra das 48 Horas
Quando tiver uma ideia, nao comece a construir imediatamente. Espere 48 horas. Nesse tempo, faca tres coisas: converse com 3 pessoas que tem o problema, pesquise concorrentes (pode haver 5 solucoes que voce nao conhece), e escreva a "frase do produto" do Modulo 1.1.
Se depois de 48 horas a ideia ainda parece boa E voce confirmou que o problema e real, ai sim comece. Essa pausa de 48 horas salva semanas de trabalho em projetos que nao teriam futuro.
Fazer
- ✓Falar com usuarios reais antes de codar
- ✓Usar perguntas do Mom Test (sobre comportamento passado, nao futuro)
- ✓Criar landing page de teste antes do produto
- ✓Considerar pre-venda como validacao maxima
Evitar
- ✗Construir 3 meses e so depois mostrar para alguem
- ✗Perguntar "voce usaria?" (a resposta e sempre sim)
- ✗Validar so com amigos e familia (viés positivo)
- ✗Confundir "curtidas no post" com demanda real
👤 Definicao de Persona e Dor Principal
Uma persona nao e um exercicio academico de marketing. E uma ferramenta pratica que guia cada decisao do seu produto: que features construir, que linguagem usar na interface, quanto cobrar, e ate onde anunciar. Sem persona, voce toma decisoes baseadas em achismo. Com persona, cada decisao tem fundamento.
Para projetos de SaaS com IA, a persona e ainda mais critica. Porque o usuario pode nao saber que precisa de IA. Ele sabe que tem um problema. Ele nao sabe (e nem precisa saber) que a solucao envolve machine learning ou large language models. A persona te ajuda a falar a lingua do usuario, nao a lingua da tecnologia.
Anatomia de uma Persona para SaaS
Dados Demograficos
Nome ficticio, idade, profissao, tamanho da empresa, faixa de renda. Nao precisa ser exacto, mas precisa ser especifico o suficiente para visualizar uma pessoa real. "Carlos, 34 anos, designer freelancer, 8 clientes ativos, fatura R$12K/mes" e muito mais util que "designers".
Dor Principal (Primary Pain Point)
A unica coisa que mais atrapalha essa pessoa. Nao liste 10 problemas. Identifique O problema. O que faz essa pessoa abrir o Google a meia-noite procurando solucao? O que ela reclama para os colegas? O que ela daria dinheiro para resolver?
Exemplo: "Carlos perde 5 horas por semana organizando feedback de clientes que chega por email, WhatsApp, e comentarios em PDFs. Ele ja perdeu prazos por causa de feedback que ficou perdido."
Jobs-to-be-Done (JTBD)
O framework JTBD, criado por Clayton Christensen (professor de Harvard e autor de "The Innovator's Dilemma"), olha para o "trabalho" que o usuario precisa realizar, nao para features do produto. O formato e:
Exemplo: "Quando recebo feedback de um cliente por multiplos canais, eu quero centralizar tudo num lugar so, para que eu possa responder rapido e nao perder nenhum item."
Disposicao para Pagar
Quanto essa persona gasta hoje para resolver o problema (mesmo que de forma ruim)? Se a resposta e "zero", o problema pode nao ser forte o suficiente para sustentar um SaaS pago. Se a resposta e "ja pago $50/mes em 3 ferramentas que nao resolvem direito", voce tem ouro.
A Diferenca em Projetos com IA
Projetos que usam IA tem uma particularidade na definicao de persona: o usuario frequentemente nao sabe que IA e a solucao. Ele sabe que tem um problema. Ele procura "ferramenta para organizar feedback de clientes", nao "IA para processar linguagem natural de feedback".
Isso significa que sua comunicacao deve ser sobre o resultado, nao sobre a tecnologia. "Organize todo feedback em um clique" vende mais que "IA com GPT-4 analisa sentimento de feedback". O usuario quer o resultado. A IA e o mecanismo por tras, nao o argumento de venda.
Excecao: se sua persona e tecnologica (devs, data scientists), ai sim a IA pode ser argumento de venda. Contexto importa.
Dica Pratica: Template de Persona em 5 Minutos
Use este template rapido. Nao precisa ser um documento de 10 paginas. Uma persona util cabe em um bloco de texto:
Nome: [Nome ficticio, idade, profissao]
Contexto: [O que faz, tamanho do negocio, ferramentas que usa]
Dor principal: [O maior problema em uma frase]
Quanto custa a dor: [Horas/semana perdidas ou dinheiro gasto]
JTBD: "Quando [X], eu quero [Y], para que [Z]"
Onde encontrar: [Comunidades, redes sociais, eventos]
Disposicao para pagar: [$X/mes e o maximo realista]
Fazer
- ✓Basear a persona em conversas reais (nao imaginacao)
- ✓Focar em UMA dor principal, nao 10
- ✓Usar JTBD para entender motivacao
- ✓Quantificar a dor (horas, dinheiro, frustacao)
Evitar
- ✗Criar personas fictícias sem dados reais
- ✗Listar 5 personas diferentes (foque em 1 no inicio)
- ✗Vender "IA" quando o usuario quer "resultado"
- ✗Ignorar a disposicao para pagar
🎯 Product-Market Fit para Projetos com IA
Product-Market Fit (PMF) e o momento em que seu produto encontra um mercado que realmente o quer. Nao e "algumas pessoas usam". E "as pessoas ficariam genuinamente chateadas se voce tirasse o produto do ar". Antes do PMF, voce esta experimentando. Depois do PMF, voce esta escalando.
Para produtos com IA, o caminho para o PMF tem armadilhas unicas. A maior delas e o "wow factor": as pessoas ficam impressionadas com a tecnologia ("uau, a IA gera isso!") mas nao voltam a usar. Impressionar nao e o mesmo que resolver. Voce precisa ir alem do "uau" e chegar no "nao consigo mais viver sem".
Conceito Principal: O Teste de Sean Ellis
Sean Ellis, que cunhou o termo "growth hacking", criou o teste mais simples e eficaz para medir PMF. A pergunta e:
"Como voce se sentiria se nao pudesse mais usar [produto]?"
Opcoes: Muito desapontado / Um pouco desapontado / Nao desapontado / Nao uso mais
O benchmark: se 40% ou mais dos seus usuarios respondem "Muito desapontado", voce tem PMF. Abaixo de 40%, voce precisa iterar. Esse numero vem de analise de centenas de startups e e o limiar estatisticamente associado a crescimento sustentavel.
O teste e poderoso porque mede dependencia real, nao satisfacao generica. Uma pessoa pode "gostar" do seu produto e nunca mais usar. Mas se ela ficaria "muito desapontada" sem ele, ela depende dele. Dependencia e PMF.
O Desafio Unico de PMF em Produtos com IA
O Problema do "Wow Factor"
IA impressiona na primeira experiencia. O usuario ve algo magico, compartilha no Twitter, e nunca mais volta. A taxa de retencao D7 (usuarios que voltam 7 dias depois) em apps de IA e em media 14%, comparado com 25% em apps tradicionais. O "wow" se dissipa rapido.
Retencao > Aquisicao
Para produtos com IA, retencao e a metrica que importa, nao aquisicao. E facil conseguir usuarios (o "wow factor" traz). Manter os usuarios e o desafio. Se seu D30 (retencao de 30 dias) esta abaixo de 10%, o produto nao esta resolvendo um problema recorrente.
Utilidade vs Novidade
A pergunta que separa PMF de hype: "O usuario voltaria mesmo se a IA nao fosse novidade?" Se a resposta e sim, voce tem utilidade real. Se a resposta e "ele so volta porque a IA e legal", voce tem um brinquedo, nao um produto.
Dica Pratica: Medindo PMF Cedo
Voce nao precisa de milhares de usuarios para medir PMF. Com 20-30 usuarios ativos, ja e possivel rodar o teste de Sean Ellis e ter um sinal direcional. Envie uma pesquisa simples (TypeForm ou Google Forms) com a pergunta do teste + duas abertas:
1. Como voce se sentiria se nao pudesse mais usar [produto]? (Muito/Pouco/Nada desapontado)
2. Qual e o principal beneficio que voce recebe do [produto]?
3. O que voce melhoraria?
A pergunta 2 revela o que manter e dobrar. A pergunta 3 revela o que esta faltando. Juntas, elas dao o roadmap do proximo sprint.
Fazer
- ✓Rodar o teste de Sean Ellis com os primeiros 20-30 usuarios
- ✓Medir retencao D7 e D30 como metricas primarias
- ✓Focar em resolver problema recorrente (nao novidade pontual)
- ✓Iterar baseado em dados de uso, nao em opiniao
Evitar
- ✗Confundir viralidade com PMF (compartilhamentos nao sao retencao)
- ✗Escalar marketing antes de ter PMF confirmado
- ✗Depender do "wow factor" da IA como proposta de valor
- ✗Ignorar churn (usuarios que saem) por focar em novos usuarios
🗺️ Mapa de Fluxo do Usuario
O mapa de fluxo do usuario (User Flow Map) e o blueprint do seu produto. Antes de pedir para a IA gerar codigo, voce precisa saber exatamente o que o usuario faz, em que ordem, e o que acontece em cada etapa. Sem esse mapa, voce vai construir telas soltas que nao se conectam logicamente.
Em produtos com IA, o fluxo do usuario tem uma particularidade importante: frequentemente ha um "fluxo de conversa" alem do fluxo de navegacao tradicional. O usuario nao apenas clica em botoes, ele interage com um chat, envia inputs, recebe respostas geradas. Mapear esse fluxo dual e essencial.
O Fluxo Universal de SaaS
Todo SaaS segue um fluxo fundamental, nao importa o nicho. As telas e features mudam, mas a estrutura e a mesma:
Entrada (Entry Point)
Como o usuario chega: landing page, link compartilhado, busca, anuncio. O primeiro contato com o produto. A primeira impressao decide se ele continua ou sai. Tempo medio de decisao: 8 segundos.
Onboarding
Sign up + primeiros passos. O objetivo e levar o usuario ao "Value Moment" o mais rapido possivel. Se o signup tem 8 campos, voce perde 60% dos usuarios. Peca so email e senha (ou social login). O resto vem depois.
Core Action (Acao Principal)
A UNICA coisa mais importante que o usuario faz no seu produto. Para Slack, e enviar mensagem. Para Notion, e criar uma pagina. Para o seu SaaS, e [o que voce definiu no pipeline P-U-S-M]. Tudo no produto existe para levar o usuario a essa acao.
Value Moment
O momento em que o usuario sente o valor do produto. No Spotify, e quando a musica comeca a tocar. No ChatGPT, e quando a resposta aparece. No seu SaaS, e quando o usuario ve o resultado da Core Action. O tempo ate o Value Moment deve ser o menor possivel.
Retention Loop (Ciclo de Retencao)
O que traz o usuario de volta. Pode ser: novo conteudo gerado, notificacao de tarefa, email resumo semanal, dados atualizados. Sem retention loop, o usuario usa uma vez e esquece. O loop transforma uso pontual em habito.
Fluxo de Conversa vs Fluxo Tradicional
Em apps tradicionais, o fluxo e linear: clique > tela > clique > resultado. Em apps com IA, frequentemente ha um fluxo de conversa dentro do fluxo de navegacao. O usuario navega ate um chat, inicia uma conversa, itera com a IA, e recebe um resultado.
Isso cria um desafio de UX: como voce mapeia um fluxo que nao e completamente previsivel? A resposta e mapear os cenarios tipicos, nao todas as possibilidades. Para cada interacao com IA, defina:
Input esperado: O que o usuario tipicamente envia (texto, arquivo, dados)
Output esperado: O que a IA retorna (texto, tabela, arquivo, acao)
Fluxo de erro: O que acontece quando a IA nao entende ou gera algo errado
Iteracao: Como o usuario refina o resultado (pedir novamente, editar, aceitar)
Dica Pratica: Mapeie em 15 Minutos
Nao precisa de ferramenta cara. Abra um documento e escreva o fluxo como uma lista numerada. Cada item e uma acao ou tela. Use setas para indicar direcao. Exemplo:
1. Landing Page > [CTA] > Sign Up
2. Sign Up (email + senha) > Onboarding (3 perguntas)
3. Dashboard (cards de resumo + botao "Novo Projeto")
4. [Novo Projeto] > Chat com IA (input: briefing)
5. IA gera plano de projeto > Usuario revisa > Aceita ou edita
6. Projeto salvo > Dashboard atualizado
7. [Retention] Email semanal com resumo de projetos ativos
Esse mapa simples ja e suficiente para comecar a construir com IA. Cada linha vira um prompt, cada tela vira um componente. O mapa E o briefing.
Fazer
- ✓Mapear o fluxo ANTES de construir qualquer tela
- ✓Identificar o Value Moment e minimizar o tempo ate ele
- ✓Incluir fluxo de conversa/IA no mapa
- ✓Definir o retention loop desde o inicio
Evitar
- ✗Construir telas isoladas sem fluxo definido
- ✗Colocar 10 passos entre signup e Value Moment
- ✗Ignorar fluxos de erro (IA vai errar, planeje para isso)
- ✗Fazer fluxos complexos com diagramas UML (keep it simple)
📋 Exercicio: Pipeline Completo da sua Ideia
Este e o exercicio mais importante da Trilha 1. Voce vai aplicar tudo que aprendeu nos modulos 1.1, 1.2 e 1.3 para criar o plano completo do seu SaaS. Ao final, voce tera um documento que guiara toda a construcao nas proximas trilhas.
Nao pule etapas. Nao escreva meia pagina e siga em frente. Cada secao deste exercicio economiza horas de retrabalho nas trilhas de construcao. Um plano bem feito aqui e a diferenca entre construir com direcao e construir no escuro.
As 5 Entregas do Exercicio
Problem Statement (Declaracao do Problema)
Escreva em 2-3 frases o problema que seu SaaS resolve. Inclua: quem sofre, o que sofre, com que frequencia, e quanto custa (tempo ou dinheiro).
Exemplo:
"Freelancers de design que gerenciam mais de 5 clientes perdem em media 5 horas por semana organizando feedback que chega por email, WhatsApp e PDFs. Feedback perdido causa atrasos e retrabalho, custando em media R$2.000/mes em produtividade."
Documento de Persona
Use o template do Topico 3 para criar sua persona principal. Preencha todos os campos: nome, contexto, dor, custo da dor, JTBD, onde encontrar, disposicao para pagar.
Bonus: Se voce ja conversou com usuarios reais (Topico 2), inclua 2-3 citacoes diretas dessas conversas. Citacoes reais sao ouro para guiar decisoes de produto.
Plano de Validacao
Defina como voce vai validar a ideia antes de construir o produto completo. Escolha pelo menos 2 metodos do Topico 2:
- • Quem voce vai entrevistar (5 nomes ou onde encontrar)
- • Landing page: onde publicar, meta de inscritos em 1 semana
- • Smoke test: como oferecer o servico manualmente
- • Pre-venda: preco, plataforma, meta de conversao
User Flow Diagram
Mapeie o fluxo completo do usuario usando o formato do Topico 5. Inclua:
- • Entry point > Onboarding (max 3 passos)
- • Core Action (a acao principal do produto)
- • Value Moment (onde o usuario sente o valor)
- • Retention Loop (o que traz de volta)
- • Fluxo de conversa/IA (se aplicavel)
- • Fluxo de erro (quando algo da errado)
Metricas de PMF
Defina antecipadamente como voce vai medir Product-Market Fit:
- • Meta de usuarios para rodar o teste de Sean Ellis (sugestao: 20-30)
- • Meta de retencao D7 (sugestao: acima de 20%)
- • Meta de retencao D30 (sugestao: acima de 10%)
- • Meta do teste Ellis (sugestao: 40% "muito desapontado")
- • Timeline: quando voce espera atingir essas metas
Checklist de Entregaveis
Dica Pratica: Use IA para Refinar seu Pipeline
Depois de preencher todos os entregaveis, use o seguinte prompt para a IA fazer uma revisao critica do seu plano:
Prompt de revisao completa:
"Analise este plano de SaaS e responda: 1) O problema e especifico o suficiente? 2) A persona esta baseada em dados reais ou e imaginacao? 3) O plano de validacao vai gerar dados uteis? 4) O user flow tem passos demais entre signup e Value Moment? 5) As metricas de PMF sao realistas para o primeiro mes? Seja direto e aponte falhas."
A IA nao vai ser gentil se voce pedir para ser direta. E exatamente isso que voce precisa. Feedback honesto agora salva semanas de trabalho perdido depois.
Fazer
- ✓Completar todos os 5 entregaveis antes de seguir
- ✓Usar IA para revisar criticamente o plano
- ✓Salvar o documento: ele e o briefing para as Trilhas 2-6
- ✓Compartilhar com a comunidade para feedback externo
Evitar
- ✗Pular etapas ("ja sei o que quero construir")
- ✗Escrever respostas vagas ("meu usuario e todo mundo")
- ✗Nao definir metricas (sem metricas, voce nunca sabe se acertou)
- ✗Seguir para Trilha 2 sem esse documento pronto
Resumo do Modulo 1.3
Voce agora tem o framework completo para ir da ideia ao software. Nao e sobre ter a melhor ideia. E sobre validar rapido, construir certo, e medir o que importa.