MVP: seis meses construindo não valem uma semana com usuário
O erro caro raramente é construir a coisa errada. É construir meio ano antes de mostrar para alguém. Um MVP não é um produto menor: é a menor coisa capaz de arrancar uma resposta de quem tem o problema.
Sem cartão. Dá para pôr a v1 de pé e mandar o link no mesmo dia.
A ideia não fica melhor guardada
Enquanto o produto está só na sua cabeça, cada decisão é um palpite empilhado em cima do palpite anterior. A diferença entre os dois caminhos abaixo não é qualidade de código: é quantas semanas você passa sem nenhuma informação nova.
- Você escreve um documento de escopo com trinta funcionalidades.
- Desenha telas para coisas que ninguém pediu ainda.
- Constrói o painel de administrador antes do primeiro cadastro.
- Lança no sexto mês e descobre que o problema principal era outro.
Ao final: um produto grande e nenhuma resposta.
- Dia 1: as primeiras telas existem e você já vê onde o fluxo trava, antes de qualquer estranho abrir.
- Dia 3: dez pessoas receberam o link e três travaram na mesma tela.
- Dia 5: você mexeu naquela tela por causa delas, não por palpite.
- Dia 12: duas voltaram sozinhas. É a primeira informação da lista que vale dinheiro.
Ao final: um produto pequeno e uma lista de coisas que você não sabia.
O que é um MVP, e o que insistem em chamar de MVP
A palavra virou guarda-chuva para qualquer coisa inacabada. Vale separar, porque cada uma dessas coisas responde a uma pergunta diferente.
É
- Software que funciona de ponta a ponta em um fluxo só.
- Alguém entra, faz a coisa principal e sai com o resultado na mão.
- Está publicado, tem endereço e abre no celular de um estranho.
- Guarda dado de verdade: quem voltar amanhã encontra o que salvou.
Resumo brutal: feio é aceitável, incompleto é aceitável, quebrado não é.
Não é uma demo
Na demo você segura o mouse e desvia dos buracos. No MVP a pessoa usa sozinha, no horário dela, sem você na chamada para explicar.
Não é protótipo de Figma
Tela clicável não salva nada. Ela testa se o desenho é compreensível, não se alguém volta na terça-feira para usar de novo.
Não é versão quebrada
Cortar escopo é decidir o que não existe ainda. Entregar bug é outra coisa: o que está na v1 precisa funcionar inteiro.
Não é lista de espera
Formulário de e-mail mede curiosidade, não uso. Isso tem lugar próprio, no trabalho de uma página de conversão. O MVP mede comportamento.
Construir, mostrar, aprender, ajustar
Esse ciclo é velho e não tem nada de novidade. O que trava a maioria dos projetos é o tamanho da volta: quando cada ajuste custa uma sprint e um deploy, você dá duas voltas por trimestre. O Zheus encurta a volta: o ajuste é pedido na mesma conversa e aparece na prévia, sem sprint nem fila de deploy no meio do caminho.
Construir
Você conta o que o produto faz e para quem. As primeiras telas nascem na própria conversa; o fluxo completo costuma levar algumas rodadas de ajuste, e cada rodada consome créditos. Aqui ainda é tudo palpite seu. É a etapa mais confortável e a menos informativa das quatro.
Mostrar
Publicar é um botão, e o que sai é um link. A parte difícil não é técnica: é mandar antes de estar bom, para dez pessoas do seu nicho que não te devem favor nenhum. A lista de melhorias que você faria sozinho quase nunca é a lista que elas pedem.
Aprender
Você vê quem criou conta e o que ficou salvo; quem desistiu no meio deixa o cadastro vazio como pista. O porquê ainda é você que pergunta. O Zheus não inclui painel de analytics, e uma ligação de cinco minutos com quem parou rende mais que o gráfico que você não tem.
Ajustar
A correção volta para a mesma conversa: muda o passo confuso, tira o campo que ninguém preencheu, publica de novo. A volta inteira cabe entre duas reuniões, e é isso que separa quem dá quatro voltas no mês de quem dá uma por trimestre.
E aí volta para o 01. Nenhuma das quatro etapas passa por configurar servidor, comprar certificado ou esperar alguém subir a versão. Tirar essas paradas do caminho é o que faz o ajuste caber na mesma conversa, em vez de esperar a próxima janela. Quantas voltas você dá depende do tamanho do projeto e dos créditos disponíveis.
Sem sprint, sem filaO que entra na primeira versão e o que fica para depois
Esta parte é opinativa de propósito. Você vai querer discordar de algum item. Ótimo: discorde por escrito e siga cortando. O que não pode é a lista de “depois” ficar vazia.
O que precisa existir para alguém usar sozinho e voltar depois.
- Cadastro e loginSem conta, a pessoa não tem como voltar e achar o que era dela. É o mínimo para existir segunda visita.
- O fluxo principal inteiroDo primeiro clique até o resultado, sem beco sem saída. Se o produto promete gerar uma proposta, a proposta precisa sair.
- Dados salvos de verdadeNo banco do projeto, não no navegador do usuário. Aprendizado exige que o que foi feito ontem ainda esteja lá hoje, inclusive quando a pessoa abre do celular na semana seguinte.
- Uma lista do que foi criadoA tela chata que mostra os itens do usuário. É ela que faz o produto parecer útil na terceira visita.
- Um canal para responderUm e-mail visível, um campo de contato. Quem se irrita e não tem onde reclamar simplesmente some, e o motivo some junto.
Nada disso é ruim. É só caro cedo demais, e você constrói tudo isso na hora certa, pedindo na mesma conversa.
- Painel de administrador completoEnquanto houver doze registros, o administrador é você olhando o banco do projeto.
- Relatórios e gráficosCom trinta linhas não existe gráfico, existe uma tabela. Dashboard antes de dado é decoração.
- Permissão granular por papelDono e convidado resolvem. Matriz de papéis é problema de quem já tem time usando.
- Tema escuro e preferênciasNinguém abandona um produto porque ele só tem um tema. Abandona porque não entendeu para que serve.
- Onboarding animado e tour guiadoTour existe para explicar interface confusa. Na v1, é mais barato deixar a interface menos confusa.
- Integrações com tudoEscolha uma, e só se o fluxo principal morrer sem ela. As outras entram quando alguém pedir pelo nome.
Regra prática para cortar sem sofrer: se a funcionalidade só faz sentido com quinhentos usuários, ela não pertence à versão que existe para descobrir se você terá dez.
Você descreve o fluxo principal, corta o resto na conversa e muda de ideia quantas vezes quiser.
O corte aplicado numa ideia real de nicho
Imagine uma ferramenta para nutricionistas montarem e enviarem plano alimentar, hoje feito em documento do Word e mandado em PDF. A pergunta que a v1 precisa responder é uma só: o nutricionista larga o Word para usar isto? Tudo que não ajuda a responder essa pergunta sai da primeira versão.
Exemplo criado para ilustrar o raciocínio de corte. Não é um cliente nem um caso medido.
Na v1
- Login do profissional.
- Cadastro do paciente com objetivo e restrições alimentares.
- Montagem do plano por refeição, em texto livre.
- Link do plano para o paciente abrir no celular.
- Lista dos planos enviados, por paciente.
Fora por enquanto
- Base completa de alimentos com cálculo automático de macros.
- Chat com o paciente dentro da ferramenta.
- Relatório de adesão ao plano.
- Vários nutricionistas na mesma conta.
Como saber que o MVP funcionou
Não é sensação, e não é elogio. São quatro comportamentos que você observa no próprio projeto, e nenhum deles alguém faz por educação. Vale ler cada um pensando na nutricionista do exemplo acima.
Volta sem você pedir
A nutricionista abriu de novo numa terça à noite, montou o segundo plano e você não mandou lembrete nenhum.
O que provaQue o problema dói toda semana, não só no dia em que você perguntou se ela tinha testado.
Pede funcionalidade
“Dá para duplicar o plano da semana passada?” vale mais que dez elogios: é um pedido com verbo e objeto.
O que provaQue a pessoa já colocou o produto na rotina dela e sabe exatamente qual pedaço falta.
Pergunta o preço
“Quanto vai custar quando sair do beta?” aparece na boca de quem já contou com a ferramenta para a agenda da semana seguinte.
O que provaQue o valor já é maior que a fricção de largar o Word, e essa comparação ela fez sozinha.
Usa de um jeito que você não previu
Ela começou a mandar o mesmo link para o paciente usar como lista de compras, coisa que você nunca desenhou.
O que provaQue existe um segundo produto escondido dentro do seu, às vezes maior que o primeiro.
Sinais que enganam
Todos parecem tração e nenhum diz que alguém usaria de novo na semana seguinte.
- Amigo dizendo que ficou muito bom.
- Cadastro sem nenhum segundo acesso.
- Elogio ao visual sem uma linha sobre o problema.
- Compartilhamento nas redes sem ninguém entrando.
Funcionou? Então evolua o mesmo projeto
A tentação de recomeçar do zero (“agora que eu sei, faço direito”) é o segundo erro mais caro dessa história. O projeto validado já tem o esqueleto que os usuários aprovaram; jogar fora é voltar ao ponto de partida com mais confiança e nenhuma vantagem.
- Os cadastros de teste são a sua primeira lista: quem voltou três vezes de graça é quem você chama primeiro no dia de cobrar.
- A conversa segue de onde parou. Você pede a evolução em vez de reexplicar o produto, e as decisões de corte da v1 continuam registradas ali.
- A lista de “fica para depois” vira a fila da v2, só que agora com nome: cada item entra porque alguém pediu, não porque parecia importante em janeiro.
- Trocar o endereço de teste pelo definitivo não reconstrói nada: é o mesmo projeto, com os mesmos dados, atendendo em outro domínio.
Daí em diante o caminho se abre: quem descobriu que o problema é grande segue para construir o SaaS completo, com contas de usuário e área logada. É lá também que está o detalhe de quem é o código e de como ele sai para o GitHub quando o produto pedir um desenvolvedor. Quem descobriu que o problema é pequeno, específico e do tamanho de um dono sozinho pode parar por aqui e tocar como um microSaaS de recorte estreito.
A conta cai no meio do ciclo
As etapas 01 e 02 desta página cabem no grátis: as telas sobem, o link sai e você já consegue ver alguém travar na terceira tela. É a parte da validação que não exige assinatura; o que ela consome são os 60 créditos que a conta grátis recebe uma vez.
Construir e mostrar é grátis; deixar dez pessoas voltarem amanhã e acharem o que salvaram exige banco, e banco é plano pago. Ou seja: enquanto a pergunta for “abriu e entendeu?”, você não gasta. No dia em que ela virar “voltou na semana seguinte?”, entra mensalidade: essa é a etapa 03, a única que responde se a ideia se sustenta.
O que trava a decisão de publicar
As cinco perguntas que aparecem sempre na véspera de mandar o link para o primeiro estranho.
Feio não espanta; confuso espanta. O que faz a pessoa fechar a aba é não entender o que fazer na primeira tela, clicar em algo que não responde ou perder o que digitou. O Zheus parte de um layout com hierarquia, tipografia legível e espaçamento decente, e o que sair torto você corrige pedindo o ajuste na mesma conversa. A exceção é quando a estética é o produto: portfólio, moda, casamento, gastronomia. Aí a aparência faz parte do que está sendo testado e merece uma rodada a mais de ajuste na conversa.
Mudar é o resultado esperado, não o acidente. Por isso a v1 fica pequena: o custo de mudar é proporcional ao tamanho do que já existe. Na prática você volta para a mesma conversa e pede a alteração: trocar o fluxo de cadastro, remover uma etapa, renomear a entidade principal. A mudança que piorou volta atrás na hora pelo histórico de versões, e é isso que permite arriscar um corte grande na v1: você tira a etapa que acha dispensável e, se dois usuários reclamarem dela na mesma semana, ela volta. Reescrever do zero só faz sentido quando o produto virou outra coisa; ajuste de rumo é rotina.
Dá: quando o produto pedir um dev, o código vai para o GitHub e ele continua daí. O detalhe de quem é o código e como ele sai está na página do SaaS builder. O que muda de verdade é o momento da entrega. Contratar alguém antes da validação é pagar para construir uma aposta; contratar depois é entregar uma estrutura que dez pessoas já usaram, com a lista do que elas pediram por escrito. O segundo briefing é muito mais barato de executar, e o dev discute prioridade em cima de uso real em vez de opinião.
Menos gente do que você imagina, e mais repetição do que você gostaria. Cinco a dez pessoas que não te devem nada (nem amigo, nem sócio, nem seguidor) já revelam se o fluxo principal se sustenta. O número que interessa não é quantos entraram, é quantos voltaram uma segunda e uma terceira vez. Volume grande serve para medir taxa de conversão e afinar preço; para descobrir se o problema existe, conversa individual com dez usuários rende mais que mil cadastros silenciosos.
Então você descobriu em uma semana o que descobriria no sexto mês, e o que ficou pelo caminho foi crédito de construção, não meio ano da sua vida. O projeto continua na sua conta e o esqueleto se aproveita: as telas, a estrutura de dados e a publicação costumam servir para a segunda ideia com a entidade principal trocada. O que não volta é o crédito já gasto: ele se consome construindo, e a segunda rodada precisa de saldo. Antes de começar de novo, aplique o mesmo teste desta página na ideia nova: qual é a menor coisa capaz de arrancar uma resposta de quem tem o problema?
Sua v1 pode sair da sua cabeça e ir para a mão de alguém
Descreva o produto na conversa, veja a primeira versão nascer na prévia e publique com HTTPS. O aprendizado começa no dia em que o link sai da sua máquina.
Publicação com HTTPS incluída · Exportação do código a qualquer momento