O que o seu MVP de SaaS deve — e não deve — incluir no lançamento

A palavra «mínimo» em produto mínimo viável é a parte que toda a gente ignora. Os fundadores acenam à ideia de começar pequeno e depois entregam uma especificação com quarenta ecrãs, três perfis de utilizador, um motor de faturação, um painel de análise e um «ah, e deveria integrar-se com tudo». Isso não é um MVP. É um produto completo com o otimismo no máximo. E é, de longe, a razão mais comum para as primeiras versões chegarem atrasadas, acima do orçamento e, ainda assim, sem a única coisa que os clientes realmente queriam.

Ajudei um bom número de pequenas empresas e fundadores a solo a pôr cá fora o seu primeiro produto de software. A parte técnica raramente é o que os faz tropeçar. O difícil — sempre, sem exceção — é decidir o que não construir ainda. Um MVP não é uma versão reduzida do seu produto de sonho com funcionalidades limadas ao acaso. É uma aposta deliberada: a coisa mais pequena que consegue pôr à frente de utilizadores reais para provar que a ideia central merece mais do seu dinheiro e do seu tempo.

Por isso, este é o guia que gostaria que mais fundadores lessem antes de escrever a especificação. Sem jargão, sem o teatro do «avança depressa e parte coisas». Apenas uma forma prática de traçar a linha entre o que pertence à primeira versão e o que pode — e deve — esperar.

O que é realmente um MVP (e o que não é)

Acertemos a definição, porque é aqui que começa a maior parte da confusão. Um MVP é a versão mais pequena e simples do seu produto que permite a uma pessoa real fazer a única coisa valiosa que o produto promete — e que lhe permite descobrir se ela voltará para a fazer de novo. É só isto. É uma ferramenta de aprendizagem que por acaso é feita de software funcional, não um lançamento reduzido do produto acabado.

A palavra crucial é viável. Um erro comum é ler «mínimo» e lançar algo tão despido que envergonha o utilizador — um fluxo a meio que rebenta, um registo que leva a um ecrã vazio. Isso não é mínimo viável, é mínimo partido. A outra falha é o oposto: um produto tão «completo» que demorou um ano a construir, e a essa altura já gastou as suas reservas a provar uma suposição que poderia ter testado em oito semanas.

Eis o teste mental que uso. Para cada funcionalidade da lista, pergunte: se a removêssemos, conseguiria um utilizador ainda obter o único resultado central para o qual o produto existe? Se a resposta for sim, quase de certeza não é de MVP. Só essa pergunta corta a maioria das especificações ao meio — e a metade que corta é a que o ia atrasar.

Encontre a única tarefa que o seu produto faz

Antes de poder decidir o que construir, tem de ter uma clareza brutal sobre a única tarefa que o seu produto faz por alguém. Não a visão. Não o roteiro. A única ação repetível que, se funcionar, melhora o dia de uma pessoa e a deixa disposta a pagar. A maioria das especificações em apuros é vaga precisamente aqui: descrevem uma plataforma, não uma tarefa.

Tente terminar esta frase em voz alta: «Um utilizador vem ao meu produto para ______, e sai tendo ______.» Uma ferramenta de escalas: um responsável vem publicar a escala da próxima semana, e sai com cada turno preenchido e a equipa avisada. Uma aplicação de faturação: um trabalhador independente vem faturar a um cliente, e sai com uma fatura enviada e rastreável. Se não consegue preencher essa frase com limpidez, não está pronto para delimitar — ainda está pronto para pensar.

Aquilo de que todo o MVP de SaaS realmente precisa

Algumas coisas não são negociáveis, mesmo na primeira versão mais enxuta — não por serem entusiasmantes, mas porque sem elas o produto ou não pode ser usado ou não lhe ensina nada. Pense nelas como o chão, não o teto. Construa-as de forma simples, mas construa-as como deve ser.

• Uma forma de iniciar sessão. Até um único login com e-mail e palavra-passe serve — mas um a sério e seguro, porque tudo o resto depende de saber quem é o utilizador.
• O fluxo central, de ponta a ponta. A única tarefa, do primeiro clique do utilizador até ao momento em que obtém o resultado valioso — sem becos sem saída, sem botões «em breve» no caminho crítico.
• Um sítio onde os dados vivem de verdade. Armazenamento real, não um protótipo descartável, para que o trabalho de um utilizador sobreviva a uma atualização e ele possa voltar amanhã.
• Uma forma de ver o que se está a passar. Registo básico ou uma vista de administração simples, para que, quando algo se partir — e vai partir-se —, consiga descobrir porquê sem adivinhar.
• Uma forma de os utilizadores o contactarem. Nem que seja só uma ligação de e-mail. Os primeiros utilizadores vão bater em limites que não previu; quer que lho digam, não que saiam em silêncio.
• O mínimo indispensável de confiança: uma nota de privacidade, um tratamento sensato dos dados e nada de imprudente com a informação das pessoas.

Repare no que não está nessa lista: faturação, onboarding sofisticado, páginas de definições, aplicações móveis, integrações. Já lá vamos ao porquê. O propósito do chão é ser pequeno o suficiente para se terminar e sólido o suficiente para se aprender com ele. Um login que funciona, um fluxo que entrega, dados reais e uma forma de observar os utilizadores e falar com eles. Isso é um produto viável.

O que deixar de fora da v1 de propósito

Esta é a secção a que os fundadores resistem, por isso serei franco: a maioria das coisas que parecem essenciais para o primeiro lançamento não o são. Parecem essenciais porque um «produto a sério» tem-nas — mas ainda não está a construir um produto a sério, está a construir uma pergunta. Deixá-las de fora não é cortar caminho. É toda a disciplina de um MVP.

Faturação automática e preçários complexos

Quase de certeza não precisa de um motor de faturação self-service, planos escalonados, rateio e lógica de cobrança na versão um. Se os primeiros utilizadores quiserem pagar, pode receber o dinheiro manualmente — uma fatura, uma ligação de pagamento, um telefonema rápido. A faturação manual para os seus primeiros dez clientes diz-lhe uma coisa que a automática não pode: se alguém vai sequer pagar. Construa a máquina depois de provar que há dinheiro a cobrar.

Perfis e permissões elaborados

Os sistemas de permissões multiperfil — administradores, gestores, observadores, regras de acesso granulares — são um verdadeiro pântano de engenharia e multiplicam enormemente a superfície de testes. Para uma primeira versão, um único tipo de utilizador quase sempre chega. Vai aprender as verdadeiras necessidades de permissões ao ver equipas reais a usar a coisa, e essas necessidades raramente são o que teria suposto no papel.

Integrações, aplicações móveis nativas e o painel

«Tem de se integrar com tudo» é a frase que duplica calmamente os prazos. Escolha no máximo uma integração, e só se fizer parte da tarefa central. As aplicações nativas iOS e Android quase sempre podem esperar — uma aplicação web responsiva funciona hoje num telemóvel. E o painel de análise que toda a gente quer? Os utilizadores não conseguem analisar dados que ainda não criaram. Lance primeiro o que cria os dados; visualize-os quando houver algo para mostrar.

Um método simples para traçar a linha

Conhecer o princípio é uma coisa; aplicá-lo à própria especificação, onde cada funcionalidade parece um filho seu, é mais difícil. Eis um método que resulta porque força uma decisão sobre cada item em vez de deixar tudo derivar para «essencial».

1. 1
   Liste todas as funcionalidades que imaginou

   Despeje tudo — sem filtrar por agora. Ponha a lista de desejos completa na mesa para que nada fique à espreita por dizer e reapareça a meio da construção como surpresa.
2. 2
   Marque cada uma face à tarefa central

   Para cada funcionalidade, pergunte: um utilizador precisa disto para completar a única tarefa central, de ponta a ponta? Marque-a como «central», «útil» ou «um dia». Seja honesto — a maioria cai nas duas últimas.
3. 3
   Guarde apenas o «central» para a v1

   O seu MVP é o monte «central» e nada mais. Os montes «útil» e «um dia» não estão rejeitados — são o seu roteiro, estacionados onde pertencem.
4. 4
   Verifique o corte com bom senso

   Olhe para o que sobra e pergunte: consegue um utilizador real tirar valor real só disto? Se sim, delimitou um MVP. Se algo quebra mesmo o fluxo central, traga de volta apenas esse item — e nada mais.

A disciplina está no passo quatro. Há sempre a tentação de «trazer de volta só mais uma coisa», e depois outra, até ter reconstruído em silêncio o produto completo. Permita-se resgatar apenas itens que quebram mesmo o fluxo central — não itens que apenas o tornariam mais agradável. O mais agradável é para o que serve a versão dois.

Viável continua a significar que tem de parecer a sério

Há um modo de falha do outro lado da linha, e vale a pena nomeá-lo. Na pressa de lançar pequeno, alguns fundadores lançam algo desleixado — e chamam-lhe MVP. Um fluxo central que perde o seu trabalho, um registo que dá um 404, textos cheios de marcadores de posição. Isso não testa a sua ideia com justiça; testa se os utilizadores vão tolerar uma experiência partida, e a resposta é sempre não. Vai concluir que a ideia falhou quando, na verdade, foi a execução.

«Mínimo» aplica-se ao âmbito, nunca à qualidade da parte que mantém. Menos funcionalidades, cada uma sólida. O único fluxo que lança deve parecer acabado — rápido, claro e de confiança — mesmo que seja a única coisa que o produto faz. Um produto estreito bem feito ganha a um produto largo mal feito todas as vezes, sobretudo quando pede a estranhos para lhe confiarem o trabalho deles.

O MVP não é a meta — é a primeira leitura

Eis a parte que reenquadra tudo: o lançamento não é o objetivo. O objetivo é o que aprende nas semanas seguintes. Um MVP que é lançado e lhe diz «os utilizadores adoram o núcleo mas continuam a pedir X» é um êxito retumbante — mesmo que X signifique mais um mês de trabalho. Um MVP que é lançado no silêncio, sem ninguém voltar, também cumpriu o seu papel: poupou-o de construir as outras trinta funcionalidades sobre alicerces que ninguém queria.

Por isso, planeie as primeiras semanas com tanta intenção como a construção. Observe o que as pessoas realmente fazem, não o que dizem nos inquéritos. Fale com quem voltou e com quem não voltou. Deixe o uso real — não a sua especificação original — decidir o que entra na versão dois. O roteiro que estacionou antes não é uma promessa; é uma hipótese, e os seus utilizadores estão prestes a classificá-la.

Perguntas frequentes