Da ideia ao MVP de SaaS: o guia passo a passo do fundador

Quase todos os artigos sobre construir um SaaS são, na verdade, escritos para alguém que já levantou capital. Pressupõem uma equipa, uma reserva de tesouraria, um roteiro e a calma de saber que se pode dar ao luxo de errar durante um ano. Se é um fundador com uma ideia real, um emprego e poupanças de que precisa mesmo, esse conselho é silenciosamente perigoso. Diz-lhe para construir em grande e depressa, que é exatamente como morre a maioria dos primeiros produtos antes de alguém pagar um único cêntimo.

Há mais de uma década que ajudo pessoas a transformar ideias em software que funciona, e os fundadores de que mais me lembro não são os dos planos mais audaciosos. São os que começaram pequeno e se mantiveram honestos. Uma fisioterapeuta que criou uma ferramenta de marcações para a sua própria clínica e acabou por vendê-la a outras quarenta. Um despachante de logística que automatizou a sua própria papelada e percebeu que metade do setor tinha o mesmo problema. Nenhum deles começou com uma grande plataforma. Começaram com uma tarefa penosa e a disposição de cobrar por resolvê-la.

Este é, portanto, o guia que gostaria que alguém tivesse entregado a essas pessoas no primeiro dia. Sem teatro de angariação de fundos, sem arquitetura da moda, sem fingir que a primeira versão tem de impressionar. Apenas um caminho sereno, de um palpite na sua cabeça até ao primeiro cliente pagante, e o discernimento para saber o que dispensar pelo caminho.

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

O termo produto mínimo viável foi esticado de tal forma que já quase nada significa. Alguns fundadores ouvem «mínimo» e lançam algo embaraçoso que ninguém consegue usar. Outros ouvem «produto» e passam oito meses a construir uma plataforma polida com escalões de preços, um painel de administração e um modo escuro, antes de um único ser humano confirmar que pagaria por ela. Ambos são erros, e são o mesmo erro com roupa diferente: construir antes de ter aprendido seja o que for.

Um MVP útil é a coisa mais pequena que pode colocar à frente de um utilizador real e que prova que a sua ideia central merece que se pague por ela. Não a coisa mais pequena que consegue construir, mas a mais pequena que lhe ensina algo verdadeiro. Se a sua ideia é «uma ferramenta que permite aos dentistas enviar lembretes de revisão automaticamente», o MVP é o motor de lembretes e mais nada. Sem portal do paciente, sem painel de análise, sem contas de equipa. Essas são respostas a perguntas que ainda não conquistou.

A razão por que isto importa tanto é o custo. Cada funcionalidade que constrói antes da validação é uma aposta feita às cegas. Reduza o MVP ao seu núcleo e terá feito uma aposta pequena e recuperável. Construa a visão inteira e terá apostado as poupanças, numa suposição. A disciplina do «mínimo» não tem a ver com ser barato. Tem a ver com manter-se vivo tempo suficiente para ter razão.

Valide a ideia antes de escrever uma linha de código

Eis a verdade incómoda que ninguém que lhe vende desenvolvimento quer dizer: a maioria das ideias de SaaS está errada nalgum aspeto importante, e pode descobri-lo por quase nada. O instinto é construir primeiro e perguntar depois. Inverta-o. A versão mais barata do seu produto é uma conversa, e a segunda mais barata é uma página de destino.

Antes de construir o que quer que seja, vai querer provas de duas coisas. Primeiro, que o problema é real e suficientemente penoso para que as pessoas já gastem tempo ou dinheiro nele, de forma desajeitada, com folhas de cálculo, notas autocolantes e uma ferramenta que detestam. Segundo, que pagariam mesmo para o fazer desaparecer. «É uma ideia gira» não é prova. «Eu usaria isso» não é prova. «Quanto custa, e posso começar segunda-feira?» isso é prova.

Uma página de destino com uma promessa clara e um botão de «entrar na lista de espera» ou «marcar uma demonstração» é o passo seguinte. Se não consegue que um punhado de desconhecidos deixe um e-mail por aquilo que descreve, isso não é um problema de marketing para resolver mais tarde: é um sinal agora, enquanto ainda é barato ouvi-lo. A validação não é uma fase pela qual se passa a correr para chegar à parte divertida. Para um fundador que gasta o seu próprio dinheiro, é a parte divertida: é onde evita o erro caro.

Encontre a única funcionalidade sem a qual o seu produto não pode viver

Toda a ideia de SaaS, quando a descreve pela primeira vez, vem embrulhada numa dúzia de funcionalidades. Há aquilo que faz, e depois a constelação de extras agradáveis que o seu cérebro já lhe acrescentou: relatórios, integrações, aplicações móveis, papéis e permissões, uma API pública. A competência mais valiosa para ir da ideia ao MVP é aprender a retirar tudo isso e encontrar a única funcionalidade que, se desaparecesse, tornaria tudo inútil.

Essa funcionalidade central é o seu MVP. Tudo o resto é uma hipótese que testará mais tarde, assim que as pessoas usarem o núcleo e lhe disserem o que realmente lhes falta. Os fundadores fazem isto sistematicamente ao contrário: constroem primeiro os secundários porque dá mais segurança, e ficam sem tempo nem dinheiro antes de a única coisa que importa chegar sequer a ser lançada.

O teste da frase única

Tente descrever o que o seu produto faz numa única frase sem qualquer «e». «Permite às clínicas enviar lembretes de marcação automáticos.» «Transforma a foto de um recibo num lançamento contabilístico.» «Regista que orçamentos um profissional enviou e lembra-o de fazer o seguimento.» Se precisa de um «e» para descrever o valor, provavelmente tem dois produtos a lutar dentro de um MVP, e deveria lançar primeiro a metade mais penosa.

• Anote tudo o que imagina que o produto faz: ponha tudo cá para fora, não filtre.
• Para cada item, pergunte: se isto não existisse, alguém pagaria à mesma? Risque cada «sim».
• O que sobrar depois dos riscos é o seu núcleo. Esse é o MVP.
• Pegue nos itens riscados mais fortes e ponha-os numa lista de «mais tarde»: não eliminados, apenas não agora.
• Resista a voltar a acrescentá-los. A lista de «mais tarde» é onde as boas ideias esperam para conquistar o seu lugar, não onde os MVP vão morrer.

Construir, comprar ou simular: como fazer o MVP

Assim que conhece a sua única funcionalidade central, tem uma escolha que os fundadores raramente fazem de forma consciente: quanto disto precisa de facto de construir de raiz? A resposta honesta, para uma primeira versão, é normalmente «menos do que pensa». Há três grandes caminhos, e a jogada inteligente é muitas vezes uma mistura.

O caminho no-code / de ligação

Para alguns MVP pode ligar ferramentas existentes — um formulário, uma base de dados, uma camada de automatização, um serviço de e-mail — e validar a ideia sem escrever qualquer código à medida. Isto é brilhante para testar se as pessoas vão usar o fluxo de trabalho e pagar por ele. É rápido e barato. Os seus limites surgem mais tarde: quando precisa de uma verdadeira experiência de produto, do seu próprio modelo de dados ou de algo genuinamente único, a cola começa a esticar. É um bom problema: significa que é hora de construir a sério, com utilizadores pagantes já na mão.

O caminho do desenvolvimento à medida

Quando a sua funcionalidade central é o fator diferenciador — a verdadeira razão pela qual os clientes o escolhem —, essa parte merece software real, feito à medida. O erro é construir à medida tudo o que está à volta dela. Não precisa de escrever a sua própria autenticação, gestão de pagamentos ou infraestrutura de e-mail; esses são problemas resolvidos que deveria alugar. Construa a parte que é unicamente sua, alugue o resto, e mantém honestos tanto o custo como o prazo.

A maioria dos MVP bem-sucedidos que vi são uma mistura deliberada: blocos alugados para a canalização aborrecida mas necessária, e desenvolvimento à medida focado na única coisa que torna o produto digno de ser pago. Saber qual é qual — o que construir face ao que comprar — é precisamente o tipo de decisão que vale a pena ter uma segunda opinião antes de gastar seja o que for.

O que pode dispensar com segurança na versão um

Saber o que deixar de fora é tão importante como saber o que construir, e é onde os fundadores mais precisam de permissão. Então aqui está ela: tem permissão para dispensar quase tudo. A primeira versão existe para aprender, não para impressionar, e quase nada do que faz um produto parecer «acabado» o ajuda de facto a aprender.

• Vários escalões de preços: escolha um único preço, ou até cobre manualmente por fatura ao início.
• Um fluxo de registo em autosserviço: integrar os seus primeiros dez clientes à mão ensina-lhe mais do que qualquer funil automatizado.
• Um painel de administração com gráficos: enquanto houver dez utilizadores, pode ler a base de dados diretamente.
• Aplicações móveis, se a web funcionar bem num telemóvel por agora.
• Papéis, permissões e contas de equipa, até que um cliente real fique bloqueado sem eles.
• Definições polidas, personalização de temas e cada caso-limite: trate primeiro do caminho comum, o resto quando alguém esbarrar nele.

Um caminho realista da ideia ao primeiro cliente

Eis a sequência por que faria passar quase qualquer fundador. É deliberadamente lenta ao início e rápida assim que se constrói, porque os erros caros vivem todos nos primeiros passos, aqueles que os fundadores são mais tentados a saltar.

1. 1
   Escreva o problema numa frase

   Não a solução: o problema. «As clínicas perdem dinheiro com faltas porque os lembretes são manuais.» Se não consegue enunciar o problema com clareza, não está pronto para o resolver.
2. 2
   Tenha dez conversas reais

   Fale com pessoas que têm o problema. Escute a dor e o dinheiro já gasto. Ajuste ou abandone a ideia com base no que ouve, não no que esperava.
3. 3
   Publique uma página de destino e um preço

   Descreva a promessa com simplicidade, indique um preço e peça um e-mail ou a marcação de uma demonstração. Veja se os desconhecidos se interessam. Esta é uma validação em que pode confiar.
4. 4
   Defina a única funcionalidade central

   Reduza a ideia à única coisa cuja ausência a torna inútil. Escreva a descrição de uma frase sem «e». Esse é o seu âmbito de construção.
5. 5
   Decida construir ou comprar para cada peça

   Construa à medida apenas o fator diferenciador. Alugue início de sessão, pagamentos, e-mail e alojamento. Acerte neste mapa antes de alguém escrever código: fixa todo o seu orçamento.
6. 6
   Construa a versão funcional mais pequena

   Aponte a semanas, não a meses. Se só a funcionalidade central demorar mais de um par de meses, o âmbito ainda é demasiado grande: corte de novo.
7. 7
   Integre os seus primeiros clientes à mão

   Guie-os pessoalmente. Observe onde tropeçam. Os primeiros dez utilizadores são a sua melhor equipa de produto, e a sua primeira receita.
8. 8
   Melhore com base no uso, não na opinião

   Mude o que o uso real lhe disser para mudar. Só agora começa a retirar itens da lista de «mais tarde», conquistados pela procura, não acrescentados por suposição.

Quanto custa de facto: em dinheiro e em tempo

Os fundadores fazem sempre primeiro a pergunta do custo, e a resposta honesta é «depende, e a maior parte é controlada por si». O maior fator de custo, de longe, é o âmbito: quanto decidiu construir antes de decidir aprender. Um MVP apertado com uma funcionalidade central e a canalização alugada é um projeto modesto e bem definido. A mesma ideia construída como uma plataforma completa com tudo ligado é um universo de custo diferente e tem uma probabilidade muito maior de falhar antes do lançamento.

O custo que a maioria das pessoas esquece é o tempo: o seu. Cada mês que passa a construir algo que ninguém confirmou que iria comprar é um mês da sua vida e das suas poupanças gasto numa suposição. É este o verdadeiro argumento para começar pequeno: não que pequeno seja barato, mas que pequeno é rápido, e rápido significa que aprende se tem razão enquanto a aposta ainda é recuperável. Um fundador que chega a um cliente pagante em três meses com uma ferramenta restrita está numa posição muitíssimo mais forte do que um que ainda está a polir uma grande plataforma um ano depois.

Há também um custo mais discreto: cada funcionalidade que lança é algo que tem agora de manter, apoiar e explicar. Um produto pequeno que faz uma coisa de forma fiável é mais barato de operar, mais fácil de vender e mais simples de melhorar do que um produto desmesurado que faz dez coisas pela metade. A contenção não é só como sobrevive à construção: é como mantém o negócio vivível depois.

Perguntas frequentes