MVP de SaaS: o que cortar na primeira versão

Há uma conversa que se repete em quase todos os projetos de produto. O fundador tem a lista do que a versão 1 precisa de ter, e a lista tem trinta e quatro linhas. Todas defensáveis, todas com um cliente imaginário atrás.

O trabalho difícil de um MVP não é construir. É decidir o que não se constrói — e conseguir dizer isso sem perder a confiança de quem está a investir.

O que um MVP tem mesmo de fazer

A definição prática que usamos: um MVP é a versão mais curta do produto pela qual alguém está disposto a pagar. Não é uma demonstração, não é um protótipo bonito, não é um site com lista de espera. É software a ser usado por quem tem o problema.

Disso decorre uma consequência incómoda: se a primeira versão não consegue cobrar, não é um produto mínimo viável — é uma apresentação com base de dados.

A pergunta que corta âmbito: "se isto não existir na v1, alguém deixa de pagar?" Se a resposta for não, sai da lista.

O que entra quase sempre

• O fluxo principal, do início ao fim, sem atalhos — aquilo que o produto promete fazer
• Registo e autenticação, incluindo recuperação de password
• Separação de dados entre clientes, decidida à partida e não remendada depois
• Cobrança recorrente, com um plano só que seja
• Um painel de administração mínimo para poder ajudar clientes sem ir à base de dados
• Métricas de uso, para a v2 ser decidida com dados em vez de opiniões

Os dois últimos pontos são os mais esquecidos e os que mais custam depois. Sem painel de administração, cada pedido de apoio passa por alguém a escrever SQL em produção. Sem métricas, ao fim de três meses ninguém sabe que funcionalidades foram usadas e a discussão sobre o próximo passo faz-se por intuição.

O que sai — e costuma doer

• Vários planos e preços: comece com um. Definir a grelha de preços antes de existirem clientes é adivinhar.
• Permissões granulares por utilizador: dois perfis chegam. O terceiro aparece quando um cliente o pedir com dinheiro em cima da mesa.
• Personalização visual por cliente: quase nunca é o motivo de compra, e complica tudo o que vier a seguir.
• Aplicação móvel nativa: um site bem feito no telemóvel resolve a v1 inteira.
• Integrações antecipadas: construa a que o terceiro cliente pedir, não a que imaginou no plano de negócios.
• Relatórios avançados: exportar para CSV resolve os primeiros meses e mostra o que as pessoas realmente analisam.
• Tradução para várias línguas: duplica trabalho e adia a única coisa que interessa, que é falar com clientes.

Cada uma destas linhas foi, em algum projeto, defendida como indispensável. Nenhuma delas foi, na prática, o motivo por que o primeiro cliente pagou.

Decisões técnicas com consequências longas

Cortar âmbito não é cortar em qualidade nas duas ou três decisões que são difíceis de reverter.

Separação de dados entre clientes

A forma como os dados de cada cliente ficam isolados tem de estar decidida no primeiro dia. Acrescentar essa separação a um sistema que assumiu um único cliente é, quase sempre, uma reescrita.

Faturação

Use um serviço estabelecido para subscrições e faturas e resista à tentação de o construir. Cobrança recorrente parece simples até aparecerem cartões recusados, alterações de plano a meio do mês, reembolsos e IVA.

Registo do que acontece

Guardar quem fez o quê e quando custa pouco no início e é impossível de recuperar retroativamente. No dia em que um cliente disser "isto desapareceu", ou existe registo ou existe a sua palavra contra a dele.

Calendário realista

Com âmbito disciplinado, um MVP de SaaS leva tipicamente seis a doze semanas até estar no ar a cobrar. Distribuído por fases:

1. Semana 1 a 2 — âmbito fechado por escrito, ecrãs principais desenhados e validados
2. Semana 3 a 7 — fluxo principal, contas e separação de dados construídos e testados
3. Semana 8 a 10 — pagamentos, painel de administração e instrumentação
4. Semana 11 a 12 — utilizadores reais em ambiente controlado, correções e lançamento

Se o calendário que lhe apresentarem for de nove meses até ao primeiro cliente, o problema raramente é a velocidade da equipa. É a lista de trinta e quatro linhas.