Da ideia aos primeiros utilizadores pagantes: como lançámos um SaaS B2B

Chegou com uma folha de cálculo, uma intuição e um prazo que o congresso do seu setor lhe tinha imposto sem lhe perguntar. Dentro de quatro meses estaria num pequeno palco perante cerca de duzentas pessoas que dirigiam exatamente o tipo de empresa a que a sua ideia se destinava. Queria poder mostrar-lhes algo real: nem diapositivos, nem um mockup, mas um produto em que um estranho pudesse entrar e pagar. É com essa conversa que começa este estudo de caso, e o mais útil nele é como o ponto de partida era comum.

Alterámos de propósito os detalhes que permitem identificá-la. A fundadora é real, o produto está no ar, e os números estão perto da verdade, mas arredondados e suavizados para que ninguém possa descobrir de quem se trata. O que importa não é o nicho específico, mas a forma do percurso, porque essa forma repete-se quase sempre que um fundador não técnico tenta transformar uma boa ideia em software que funcione. Se está mais ou menos no início desse caminho, é aproximadamente assim que podem ser os próximos meses quando corre bem.

A versão curta: um setor que conhecia a fundo, um processo manual penoso que todos nele toleravam, uma folha de cálculo com a qual o fazia discretamente melhor do que os seus pares, e zero formação técnica. Onze semanas de trabalho concentrado depois, chegaram os primeiros utilizadores pagantes. Eis como e, mais honestamente, eis onde tropeçámos.

A situação: uma folha de cálculo a fazer um trabalho real

A fundadora geria uma pequena consultora num domínio regulado e carregado de documentos. Os seus clientes eram outras pequenas empresas, e cada uma delas debatia-se com a mesma tarefa recorrente: reunir uma pilha de formulários, verificar se estavam completos, perseguir as partes em falta e produzir um resumo limpo antes de um prazo. A maioria dos concorrentes fazia isto com e-mails, telefonemas e uma pasta de modelos Word. Ela fazia-o com uma folha de cálculo que tinha construído e refinado ao longo de quatro anos, e os seus clientes adoravam-na em silêncio por isso.

Essa folha de cálculo era toda a perceção. Não era um plano de negócios nem uma análise de mercado: era uma prova. As pessoas já dependiam da sua ferramenta, pediam-lhe que a corresse para empresas que nem sequer assessorava, ofereciam-se para pagar só pelo acesso. Quando os clientes tentam comprar algo antes de o ter construído, pode deixar de adivinhar se existe procura. A pergunta nunca foi se valia a pena fazê-lo. A pergunta era se isto podia tornar-se software que outra pessoa pudesse usar sem ela estar sentada ao lado.

As suas restrições eram igualmente reais. Um orçamento fixo que saía das suas próprias poupanças, não de um fundo. O prazo do congresso. E uma regra firme com que concordámos cedo: isto não podia tornar-se um projeto que exigisse a sua atenção todos os dias, porque ainda tinha uma consultora para gerir. Fosse o que fosse que construíssemos, tinha de ser terminável, comportável e aborrecido de operar. Estas três palavras moldaram cada decisão que se seguiu.

O primeiro trabalho foi decidir o que NÃO construir

Quando os fundadores descrevem o produto dos seus sonhos, a lista de funcionalidades é sempre enorme, porque o imaginam há anos. A dela enchia duas páginas: painéis, permissões de equipa, um registo de auditoria, lembretes automáticos, um portal voltado para o cliente, faturação, análises, integrações com três ferramentas que os seus clientes usavam e — claro — «alguma IA algures lá dentro». Cada item era razoável. Construí-los todos antes do lançamento teria sido um desastre.

Por isso fizemos o exercício que fazemos com toda a gente: para cada funcionalidade, colocámos uma única pergunta direta. Se isto faltasse no dia do lançamento, um cliente recusaria pagar? Não «ficaria mais agradável com isto», mas se a venda morreria mesmo. A maioria das funcionalidades reprova nesse teste, e é precisamente esse o ponto. As que sobrevivem são o seu verdadeiro produto. Tudo o resto é um roteiro, algo encantador de ter, mas não o que se constrói primeiro.

O que sobreviveu era quase embaraçosamente pequeno. Um utilizador podia criar uma conta, configurar um processo, convidar o seu cliente a carregar os documentos exigidos e receber de volta o mesmo resumo limpo e verificado que a sua folha de cálculo produzia — só que automaticamente, e sem ela no meio. Era tudo. Sem painéis. Sem papéis de equipa. Sem IA, ainda não. Quatro funcionalidades, um trabalho claro, feito como deve ser.

O que realmente construímos em onze semanas

Trabalhamos em ciclos curtos e visíveis, em vez de desaparecer durante três meses e regressar com uma surpresa. Mais ou menos a cada semana, a fundadora recebia um link para algo em que podia clicar, mesmo quando era feio e estava meio ligado. Esse ritmo importa mais do que parece: mantinha as suas decisões pequenas e frequentes, em vez de as deixar acumular numa única revisão aterradora no fim.

Semanas 1–3: a espinha dorsal

Primeiro construímos o núcleo pouco glamoroso: as contas, uma forma segura de armazenar documentos e o modelo de dados sob o fluxo dos processos. Nada disto é visível para um cliente, e tudo isto é a parte cara de corrigir mais tarde se for feita à pressa. Como o produto lidava com documentação sensível de outras empresas, tratámos o controlo de acessos e a separação de dados como um requisito de lançamento, não como uma melhoria posterior. É um dos poucos pontos em que recusámos cortar.

Semanas 4–7: o trabalho a sério

Depois a parte que tornava o produto digno de ser pago: transformar a lógica da sua folha de cálculo no motor que verifica se os documentos estão completos e produz o resumo. Era o coração do produto e demos-lhe o máximo de tempo. Sentámo-nos com ela e desmontámos porquê cada regra da sua folha de cálculo existia — e várias revelaram-se hábitos em vez de requisitos, o que nos permitiu simplificar. Ao fim da sétima semana, era possível correr um processo real de início a fim.

Semanas 8–11: torná-lo seguro para cobrar

A última etapa foi a diferença entre uma demonstração e um produto. O pagamento, para que as pessoas pudessem de facto subscrever. Um registo limpo que não precisava de manual. A dúzia de pequenos estados de erro que decidem se um estranho confia no seu software ou se vai embora. E os testes — aborrecidos, repetitivos — com a fundadora e dois clientes amistosos que aceitaram parti-lo de propósito antes de os estranhos o fazerem. Esse último grupo mereceu o seu desconto de acesso antecipado muitas vezes.

A pergunta «mete lá alguma IA», respondida com honestidade

A sua lista de desejos tinha IA, como têm agora quase todas. Contrapusemos, e vale a pena explicar porquê, porque é o mesmo conselho que damos a quase toda a gente. O trabalho que a versão um precisava de fazer — verificar um conjunto conhecido de documentos face a um conjunto conhecido de regras — é um trabalho que as regras fazem melhor do que a IA. É previsível, é auditável, e quando um cliente regulado pergunta «porque é que o sistema assinalou isto», quer uma resposta clara, não um encolher de ombros.

Isso não significa que a IA não tivesse lugar. Havia um problema genuinamente confuso, de natureza linguística, escondido no fluxo: os clientes carregavam muitas vezes documentos quase certos mas mal rotulados, ou colavam informação como texto livre em vez de preencher o formulário. Ler essa confusão e organizá-la é exatamente aquilo em que a IA moderna é boa. Por isso anotámo-lo com cuidado — e depois deixámo-lo para a versão dois. Acrescentá-lo antes do lançamento teria atrasado o prazo para polir uma funcionalidade que ninguém tinha ainda pedido para pagar.

Conseguir os primeiros utilizadores pagantes

Eis a parte que mais preocupa os fundadores e para a qual menos se preparam. Um produto que ninguém consegue encontrar não é um negócio, é um passatempo. Mas esta fundadora tinha uma vantagem que valia mais do que qualquer orçamento de marketing: já tinha um público que confiava nela, e alguns deles tinham pedido para pagar antes de o software existir. O plano de lançamento apoiou-se inteiramente nisso, e o seu também deveria se o tiver.

Em vez de um lançamento público espalhafatoso, fizemos o contrário: um silencioso e deliberado. Duas semanas antes do congresso, escreveu ao punhado de clientes que já tinham perguntado, ofereceu-lhes preço de membro fundador e integrou-os à mão, observando por videochamada como o usavam. Cada confusão tornava-se uma correção. Quando subiu àquele palco, não estava a vender uma ideia; estava a descrever software que os seus pares já pagavam, e podia dizê-lo honestamente.

1. 1
   Comece pelas pessoas que já estão a pedir

   O seu primeiro contacto foi apenas para clientes que antes se tinham oferecido para pagar. A procura quente converte antes de a procura fria sequer responder.
2. 2
   Integre os primeiros à mão

   Sem heroísmos de autosserviço no início. Acompanhou ao vivo cada utilizador inicial, transformando cada ponto de confusão numa correção concreta.
3. 3
   Preço para fundadores, não para sempre

   Os primeiros utilizadores tiveram uma tarifa de fundador claramente limitada no tempo. Recompensava o seu risco e dava aos clientes seguintes uma razão para os preços estarem a subir.
4. 4
   Use o prazo como lançamento

   O congresso não foi um truque de marketing aparafusado depois — foi a função forçadora que manteve o âmbito honesto durante todo o percurso.

O resultado — e o que ele significa de facto

No fim do mês de lançamento, o produto tinha os seus primeiros subscritores pagantes — um número pequeno, do género que ainda se conta pelos dedos de duas mãos, cada um uma empresa real a pagar uma verdadeira mensalidade. Parece modesto, e é. É também o marco mais difícil de toda a vida de um produto de software. Passar de zero clientes pagantes a alguns é muito mais difícil do que passar de alguns a muitos, porque é o momento em que a ideia deixa de ser sua e passa a ser do mercado.

Os números abaixo são ilustrativos e arredondados, mas são fiéis à forma do que aconteceu. O que queremos que retire deles não são os valores — são as proporções. Uma primeira versão estreitamente delimitada, um orçamento pequeno e focado, um prazo curto e um lançamento apontado à procura quente em vez de a toda a internet.

Onde nos enganámos

Um estudo de caso que só enumera vitórias é um anúncio, por isso eis a parte honesta. Cometemos dois erros que vale a pena nomear, porque será tentado pelos mesmos.

Primeiro, subestimámos o acolhimento. Tínhamos delimitado o produto com cuidado, mas tratámos os primeiros cinco minutos da experiência de um novo utilizador como algo secundário, algo a arrumar no fim. Revelou-se o momento decisivo, e passámos uma semana não planeada a reconstruir o registo e o primeiro ecrã vazio para que um estranho pudesse perceber o que fazer sem que lho dissessem. Da próxima vez, a experiência de primeira utilização é uma funcionalidade desde o primeiro dia, não desde a décima semana.

Segundo, deixámos uma regra «pequena» do motor de verificação inchar. A fundadora mencionou um caso-limite quase de passagem, concordámos que era fácil, e consumiu em silêncio três dias porque os dados do mundo real eram mais confusos do que a sua folha de cálculo impecável alguma vez revelou. A lição não foi «evite os casos-limite» — foi que a sua folha de cálculo andava a fazer em silêncio uma limpeza manual que ela tinha esquecido que fazia. O software tem de tornar visível esse trabalho invisível, e isso custa sempre mais do que qualquer um espera.

Se está onde ela estava

O que fez isto funcionar não foi uma arquitetura engenhosa nem uma ferramenta da moda. Foi disciplina quanto ao âmbito e honestidade quanto à procura. Ela tinha a prova de que as pessoas o queriam antes de escrevermos uma linha de código, e fomos implacáveis a construir a versão mais pequena pela qual alguém ainda pagaria. Nenhuma dessas coisas exige formação técnica. Ambas são coisas que pode começar esta semana, por si mesmo.

Se tem uma folha de cálculo que as pessoas lhe pedem sempre para correr, ou um processo manual pelo qual os seus clientes lhe agradecem, talvez esteja mais perto de um produto do que pensa. A jogada perigosa é imaginar a versão acabada, completa em funcionalidades, e paralisar perante o quão grande parece. Não o faça. Encontre o único trabalho que ele tem de fazer obrigatoriamente, construa só isso e coloque-o diante de quem já está a pedir. O roteiro pode esperar. O primeiro utilizador pagante não pode.

Perguntas frequentes