Como validar uma ideia de SaaS antes de escrever uma única linha de código

A forma mais cara de descobrir se as pessoas querem o seu software é construí-lo. E, no entanto, é exatamente isso que a maioria dos fundadores em início de carreira faz: passam seis meses e as suas poupanças a transformar uma ideia em código, lançam-na para o silêncio e só então começam a perguntar se alguém precisava dela. A validação é a versão barata dessa lição. É a forma de comprar a resposta com algumas semanas de conversas em vez de um ano da sua vida.

Já vi muitas pessoas inteligentes cair na mesma armadilha. Têm uma observação genuinamente boa — um incómodo real num setor que conhecem — e assumem que a distância entre a observação e o produto é apenas uma questão de engenharia. Não é. Essa distância está cheia de perguntas sem resposta: haverá mais alguém que sinta esta dor o suficiente para pagar? Vão abandonar aquilo que fazem hoje? Consegue chegar até eles sem queimar dinheiro? Estas perguntas não se respondem escrevendo código. Respondem-se falando com as pessoas e observando o que elas realmente fazem.

Por isso, este é o guia que dou aos fundadores antes de contratarem alguém para construir o que quer que seja. Não se trata de teatro lean-startup nem de preencher um canvas. Trata-se de um punhado de experiências honestas e baratas que lhe dizem se a sua ideia tem pulsação — e da disciplina de acreditar nos resultados, mesmo quando doem.

Porque construir primeiro parece produtivo — e quase nunca é

Construir é sedutor porque parece um progresso que se vê. No fim de uma sessão de código há um ecrã que funciona, um botão que faz algo, uma coisa que pode mostrar ao seu parceiro. Falar com desconhecidos sobre um problema não produz qualquer objeto. É desconfortável, é lento e, no fim, não tem nada além de notas. Por isso os fundadores agarram no teclado, porque o teclado recompensa-os mais depressa.

O problema é que um ecrã que funciona não lhe diz quase nada sobre se a ideia é acertada. Pode construir um produto lindíssimo e sem erros para um problema que ninguém tem, e ele estará tão morto como um feio. O código é a resposta a «como entregamos isto?» — não a «alguém quer isto?». Passar meses na primeira pergunta antes de ter respondido à segunda é como bons engenheiros acabam por construir soluções elegantes para problemas imaginários.

A validação inverte a ordem. Passa algumas semanas e muito pouco dinheiro a provar — ou a refutar — o pressuposto mais arriscado da sua ideia antes de se comprometer a construir. Se a ideia for forte, entra no desenvolvimento com provas, uma especificação mais clara e os seus primeiros utilizadores já à espera. Se for fraca, descobre-o pelo preço de uns cafés e de uma página de destino, não pelo de um produto.

Encontre o único pressuposto que poderia deitar tudo a perder

Toda a ideia de SaaS assenta numa pilha de crenças, e elas não são igualmente perigosas. Algumas são seguras: «as pessoas usam o e-mail», «as pequenas empresas não gostam de papelada». Outras são apostas das quais depende todo o seu projeto e, se estiverem erradas, mais nada importa. A tarefa da validação não é testar tudo. É encontrar o pressuposto mais arriscado e atacar esse primeiro.

Para o encontrar, escreva a sua ideia numa única frase: «[estas pessoas] têm [este problema] de forma suficientemente forte para pagar por [esta solução] em vez de [aquilo que fazem agora].» Depois pergunte a si próprio, sem dó: que palavra dessa frase, se se revelasse falsa, afundaria a ideia? Normalmente não é a solução. É se o problema dói o suficiente para se pagar por ele, ou se consegue de facto chegar a essas pessoas a um custo comportável.

Esta sequência importa porque o custo de testar sobe a cada passo. Uma entrevista sobre o problema é gratuita. Um teste de disposição para pagar custa uma página de destino. Um teste da solução pode precisar de um protótipo clicável. Construir é o teste mais caro de todos. Quer falhar barato e cedo, não caro e tarde — por isso coloca à frente os testes mais baratos e mais letais.

Fale com as pessoas — mas faça-o bem

A coisa mais útil que pode fazer é falar com as pessoas que acredita terem o problema. Não os seus amigos, não outros fundadores — os seres humanos reais que o usariam. E eis a armadilha que arruína a maioria das tentativas: as pessoas são educadas. Pergunte «usaria uma ferramenta que faz X?» e quase toda a gente diz que sim, porque dizer que sim é gratuito e simpático. Esse sim não vale nada. Afundou mais startups do que qualquer falha técnica.

A solução é deixar de perguntar sobre o futuro e começar a perguntar sobre o passado. O futuro é onde as pessoas mentem para serem simpáticas; o passado é onde vive a verdade. Em vez de «usaria isto?», pergunte «conte-me a última vez que lidou com este problema». O que fizeram? Quanto tempo demorou? Quanto lhes custou? Procuraram uma solução? Pagaram por alguma? O comportamento real ganha ao entusiasmo hipotético todas as vezes.

Perguntas que obtêm respostas honestas

• «Leve-me pela última vez que isto aconteceu.» — faz emergir o fluxo de trabalho real, não uma versão idealizada.
• «O que fez em relação a isso?» — revela se lhes importa de facto ou se apenas encolhem os ombros.
• «Quanto tempo ou dinheiro é que isso lhe custou?» — transforma uma dor vaga num número.
• «Já tentou resolver isto antes? O que aconteceu?» — diz-lhe se há orçamento e intenção.
• «O que é que neste momento o incomoda mais do que isto?» — verifica se o seu problema entra sequer no top cinco deles.

Quantas conversas? Menos do que pensa. Quando tiver realizado dez entrevistas honestas e bem conduzidas com as pessoas certas, o padrão costuma ser óbvio. Ou três ou quatro delas se iluminam e descrevem a dor com vivos pormenores — ou estão todas educadamente mornas, e nenhum desenvolvimento, por mais engenhoso que seja, irá corrigir isso. Doze a quinze chegam e sobram para tomar uma decisão em que possa confiar.

Formas baratas de testar a procura real

As conversas dizem-lhe se o problema é real. A pergunta seguinte é se as pessoas vão agir — e a única forma de saber é pedir um pequeno compromisso antes de o produto existir. É aqui que a validação se torna um pouco desconfortável, e também é aqui que se torna honesta. Falar é barato; um clique, um endereço de e-mail ou um sinal não o são.

Não precisa de construir nada para realizar estes testes. Precisa de uma única página que descreva claramente a promessa e peça uma ação específica. A ação é o dado. Se as pessoas lerem a sua proposta e não fizerem nada, essa é a sua resposta, e é uma resposta muito mais barata do que lançar para o vazio daqui a seis meses.

1. 1
   Publique uma proposta de uma página

   Descreva o problema e a sua solução em linguagem simples, com uma chamada à ação clara. Uma página de destino simples basta — ainda sem qualquer produto por trás.
2. 2
   Peça um sinal real

   Não um «gosto». Peça às pessoas que se inscrevam numa lista de espera com o seu e-mail, que reservem antecipadamente ou que marquem uma chamada. Quanto mais lhes custar dizer que sim, mais esse sim significa.
3. 3
   Leve um pouco de tráfego honesto

   Partilhe-o onde o seu público real já está — uma comunidade relevante, um pequeno anúncio, algumas mensagens diretas. Quer desconhecidos, não a sua rede de apoio.
4. 4
   Leia a conversão, não os elogios

   De todos os que perceberam mesmo a oferta, quantos realizaram a ação? Um punhado de inscrições reais das pessoas certas vale mais do que mil votos de boa sorte vagos.

O teste de procura mais poderoso de todos é pedir dinheiro à cabeça. Uma pré-venda, um piloto pago, um sinal por acesso antecipado — qualquer coisa em que uma carteira se abra. Parece agressivo, e é a coisa mais honesta que pode fazer por si próprio. Quem entrega ainda que uma pequena quantia por um produto que ainda não existe está a dizer-lhe algo que nenhum inquérito conseguiria. Se encontrar três ou quatro dessas pessoas, já não tem uma ideia. Tem um negócio à espera de ser construído.

Venda-o antes de o construir

Há um passo entre «as pessoas estão interessadas» e «as pessoas vão pagar todos os meses» que merece a sua própria atenção: entregar o valor manualmente antes de o automatizar. Se a sua ideia for, digamos, uma ferramenta que transforma e-mails desorganizados de fornecedores num relatório semanal arrumado, faça-o primeiro à mão para três ou quatro clientes. Você torna-se o software. É lento e não escala, e esse é precisamente o ponto — permite-lhe aprender o que o produto tem realmente de fazer antes de o ter fixado em código.

Isto consegue duas coisas ao mesmo tempo. Prova que as pessoas vão pagar pelo resultado, não apenas pela ideia dele. E ensina-lhe o fluxo de trabalho real — os casos-limite, as exceções, os pormenores que importam aos clientes e que nunca teria adivinhado numa entrevista. Quando finalmente construir, não estará a adivinhar a especificação. Estará a codificar um processo que já executou à mão e pelo qual já foi pago.

Ler os sinais com honestidade

Tudo isto só funciona se estiver disposto a acreditar nos resultados — e isso é mais difícil do que parece, porque a esta altura já está apegado à ideia. O perigo não são os dados maus; é um fundador que interpreta cada sinal como um incentivo. Um interesse morno é recordado como entusiasmo. Uma inscrição educada na lista de espera torna-se «procura forte». Aqui tem de lutar contra o seu próprio otimismo.

Ajuda decidir, de antemão, o que é uma aprovação. Antes de realizar um teste, escreva o resultado que o faria prosseguir e o que o faria parar. «Se menos de X das minhas entrevistas descreverem isto como um problema real e recorrente, desisto.» Fixar a fasquia antes de ver os dados é a única defesa fiável contra convencer-se a si próprio de um desenvolvimento que não deveria fazer.

E, por vezes, a resposta honesta é não. Isso não é um fracasso — é o sistema a funcionar. Um processo de validação que nunca pode devolver «não construas isto» não é validação, é procura de permissão. Os fundadores que vencem ao longo de uma carreira não são os que nunca têm más ideias. São os que matam as más ideias em três semanas por umas centenas de euros, em vez de as acalentarem durante um ano.

Quando está genuinamente pronto para construir

Digamos que os sinais são bons. O problema é real, as pessoas descreveram-no com sentimento, algumas puseram dinheiro. Agora — e só agora — construir faz sentido. Mas, mesmo aqui, a contenção compensa. O objetivo da sua primeira versão não é ser o produto que imagina. É entregar o único resultado central pelo qual os seus clientes validados pagam, e mais nada por agora.

É aqui que a validação lhe entrega em silêncio uma prenda: uma especificação nítida e sustentada por provas. Sabe para quem é, qual é a tarefa central, por que é que as pessoas vão pagar e que funcionalidades surgiram vezes sem conta face àquelas que só a si importavam. Essa clareza vale mais do que qualquer quantidade de desenho prévio. É a diferença entre construir a coisa pequena certa e construir um tudo caríssimo.

Perguntas frequentes