MVP: a primeira versão é uma pergunta, não um produto pela metade

MVP, em desenvolvimento de software, é a menor versão de um produto capaz de responder, com uso real, a pergunta que decide se vale construir o resto. Não é a versão pobre do produto final: é um experimento com pergunta escrita, critério de sucesso definido antes e usuário de verdade do outro lado.

A sigla vem de produto mínimo viável, e as duas palavras costumam ser lidas ao contrário. "Mínimo" vira desculpa para cortar o que não devia, e "viável" vira sinônimo de "funciona na demonstração". O resultado é uma primeira versão que não responde nada, porque ninguém disse qual era a pergunta.

A pergunta vem antes do escopo

Todo MVP útil começa por uma frase que pode dar errado. Alguns exemplos:

• Os técnicos vão registrar a visita no app em vez do papel, sem ninguém cobrando?
• As empresas do nicho pagam a mensalidade que imaginamos, ou só usam de graça?
• O cliente consegue começar a usar sozinho, sem uma reunião de implantação?
• O vendedor vai lançar o pedido na hora da visita, ou continua anotando para digitar à noite?

Cada pergunta dessas pede um MVP diferente. A primeira pede um app que funcione sem sinal no dia a dia de um grupo pequeno. A segunda pede cobrança de verdade. A terceira pede um caminho de ativação e quase nada de funcionalidade. Escopo definido sem pergunta vira lista de desejos cortada pela metade, e metade de uma lista de desejos não testa hipótese nenhuma.

Junto com a pergunta vão duas coisas: o critério (o que conta como sim, o que conta como não) e a data em que a resposta vai ser lida. MVP sem data não termina: vira produto sem ninguém ter decidido que ele deveria existir.

Uma fatia inteira, não uma camada

O glossário do site define MVP como fatia estreita e completa de um processo, e a palavra que importa é completa. Primeira versão que faz metade do processo e deixa o resto na planilha cria dois lugares para conferir, e a equipe volta para o papel porque ele pelo menos está num lugar só.

Estreita quer dizer poucos usuários, um tipo de tarefa, uma filial, um segmento de cliente. Completa quer dizer que essa tarefa, para esses usuários, vai do começo ao fim dentro do sistema novo.

O que dá para cortar

Quase tudo que não serve à pergunta:

• Perfis secundários. O relatório do diretor, a aprovação em três níveis, o acesso do contador. Entram quando a resposta vier.
• Automação do que acontece pouco. Cadastro de plano, estorno, ajuste de conta: nos primeiros meses, alguém do time faz pelo painel ou direto no banco, com registro.
• Integração que pode ser arquivo. Por um tempo, uma exportação diária resolve o que depois vai ser uma integração em tempo real. A integração por arquivo é antiga e continua funcionando.
• Configuração e personalização. Tela de preferência, tema, campo customizável, vários idiomas.
• A segunda plataforma. Se o MVP é app para uma equipe, uma plataforma basta para o piloto.
• Relatório elaborado. Uma exportação em planilha responde a maior parte das perguntas do começo.

O que não pode cortar

Aqui mora o erro caro. Algumas coisas parecem acabamento e são fundação, e fundação não se acrescenta depois sem reconstruir.

Segurança. Autenticação, controle de acesso por papel, criptografia e backup com restauração testada. O MVP roda com dado real de gente real, e um vazamento na primeira versão encerra o produto antes de a pergunta ser respondida. Os compromissos mínimos são os mesmos de qualquer sistema em produção, e estão descritos em segurança e LGPD.

Dado isolado por cliente, se o produto é SaaS. Com três clientes, parece exagero separar no banco o dado de cada um. Com trinta, separar depois é mexer na base de todos ao mesmo tempo, com o produto no ar. É a decisão mais cara de adiar, e ela entra na conta de quanto custa criar um SaaS.

Cobrança, se a hipótese é preço. "Vão pagar?" não se responde com uso gratuito. Cliente que testa de graça dá retorno sobre a tela; cliente que paga dá retorno sobre o valor. É por isso que o nosso método de SaaS exige de 3 a 5 clientes pagando no beta antes de abrir a venda. A cobrança do MVP pode ser simples, até manual, mas tem que ser real.

Registro do que acontece. Sem medir quem usou, quantas vezes e onde desistiu, a data da resposta chega e a resposta é uma impressão. O registro de uso é o instrumento do experimento, não um luxo para depois.

O dado do usuário de volta. Quem entrou no piloto precisa conseguir sair dele com o que registrou. Isso protege a relação e é o que torna aceitável pedir a alguém que teste uma versão inicial.

Os erros que fazem o MVP não responder nada

• Testar preço de graça. A pergunta era se pagam, e ninguém pagou.
• Usuário amigo. Quem conhece o fundador elogia. A pergunta precisa de quem não deve nada a ninguém.
• Protótipo no lugar de MVP. Protótipo de telas clicáveis responde "as pessoas entendem a tela?". MVP responde "as pessoas usam, e continuam usando?". As duas perguntas valem, e não são a mesma.
• Código feito para jogar fora. A versão descartável raramente é descartada. Se der certo, ela vira produção, com toda a pressa que tinha. Por isso o corte é no escopo, não na fundação.

Quanto tempo leva

Depende da pergunta, não da sigla. O que dá para dizer é o ritmo: no nosso método, a entrega vai para produção a cada duas semanas, e um aplicativo de campo chega à primeira versão em uso real entre 6 e 10 semanas. Se o MVP proposto passa muito disso, ou ele está respondendo perguntas demais, ou está tentando ser o produto inteiro.

O documento de uma página

Antes de qualquer linha de código, vale escrever uma página com seis itens:

1. A pergunta, numa frase que pode dar errado.
2. O critério: o que conta como sim e o que conta como não.
3. Quem são os usuários do piloto, e por que eles.
4. A data em que a resposta vai ser lida.
5. O que foi cortado, com o motivo.
6. O que não foi cortado, com o motivo.

Às vezes esse documento mostra que a pergunta se responde sem software: uma planilha, um formulário e uma pessoa fazendo à mão por um mês. Quando é assim, faça isso primeiro, e economize o projeto. Quando a resposta precisa de sistema em produção, o jeito como trabalhamos e o serviço de desenvolvimento de SaaS partem exatamente desse documento.