Hoe u een SaaS-idee valideert voordat u één regel code schrijft

De duurste manier om erachter te komen of mensen uw software willen, is hem bouwen. Toch is dat precies wat de meeste beginnende oprichters doen — ze besteden zes maanden en hun spaargeld aan het omzetten van een idee in code, lanceren het in stilte, en pas dan beginnen ze zich af te vragen of iemand het nodig had. Validatie is de goedkope versie van die les. Zo koopt u het antwoord voor een paar weken gesprekken in plaats van een jaar van uw leven.

Ik heb veel slimme mensen in dezelfde val zien lopen. Ze hebben een werkelijk goede observatie — een echte ergernis in een branche die ze kennen — en ze gaan ervan uit dat de kloof tussen observatie en product slechts een kwestie van techniek is. Dat is het niet. De kloof zit vol onbeantwoorde vragen: voelt iemand anders deze pijn genoeg om te betalen? Stappen ze over van wat ze nu doen? Kunt u hen bereiken zonder geld te verbranden? Die vragen worden niet beantwoord door code te schrijven. Ze worden beantwoord door met mensen te praten en te kijken naar wat ze werkelijk doen.

Dit is dus de gids die ik oprichters geef voordat ze iemand inhuren om iets te bouwen. Het gaat niet om lean-startup-theater of het invullen van een canvas. Het gaat om een handvol eerlijke, goedkope experimenten die u vertellen of uw idee een hartslag heeft — en de discipline om de resultaten te geloven, zelfs als ze pijn doen.

Waarom eerst bouwen productief voelt — en dat meestal niet is

Bouwen is verleidelijk omdat het voelt als zichtbare vooruitgang. Aan het einde van een codeersessie is er een scherm dat werkt, een knop die iets doet, iets dat u aan uw partner kunt laten zien. Met vreemden praten over een probleem levert geen tastbaar resultaat op. Het is ongemakkelijk, het is traag, en aan het einde heeft u niets anders dan aantekeningen. Dus grijpen oprichters naar het toetsenbord, omdat het toetsenbord hen sneller beloont.

Het probleem is dat een werkend scherm u bijna niets vertelt over de vraag of het idee klopt. U kunt een prachtig, foutloos product bouwen voor een probleem dat niemand heeft, en het zal net zo dood zijn als een lelijk product. Code is het antwoord op “hoe leveren we dit?” — niet op “wil iemand dit?” Maandenlang aan de eerste vraag werken voordat u de tweede hebt beantwoord, is hoe goede ingenieurs elegante oplossingen bouwen voor denkbeeldige problemen.

Validatie keert de volgorde om. U besteedt een paar weken en heel weinig geld aan het bewijzen — of weerleggen — van de meest risicovolle aanname in uw idee voordat u zich vastlegt op bouwen. Als het idee sterk is, stapt u de ontwikkeling in met bewijs, een helderdere specificatie en uw eerste gebruikers die al klaarstaan. Als het zwak is, komt u daar achter voor de prijs van wat koffie en een landingspagina, niet voor de prijs van een product.

Vind de ene aanname die het hele plan kan doen kelderen

Elk SaaS-idee rust op een stapel overtuigingen, en die zijn niet even gevaarlijk. Sommige zijn veilig — “mensen gebruiken e-mail,” “kleine bedrijven hebben een hekel aan papierwerk.” Andere zijn weddenschappen waar uw hele onderneming van afhangt, en als die fout zijn, doet niets anders er meer toe. De taak van validatie is niet om alles te testen. Het is om de meest risicovolle aanname te vinden en die als eerste aan te pakken.

Om die te vinden, schrijft u uw idee op als één zin: “[deze mensen] hebben [dit probleem] erg genoeg om te betalen voor [deze oplossing] in plaats van [wat ze nu doen].” Vraag uzelf dan, genadeloos: welk woord in die zin zou, als het onwaar bleek, het idee laten zinken? Meestal is het niet de oplossing. Het is de vraag of het probleem pijnlijk genoeg is om voor te betalen, of dat u die mensen daadwerkelijk betaalbaar kunt bereiken.

Deze volgorde is belangrijk omdat de kosten van testen bij elke stap stijgen. Een probleeminterview is gratis. Een test op betalingsbereidheid kost een landingspagina. Een oplossingstest heeft misschien een klikbaar prototype nodig. Bouwen is de duurste test van allemaal. U wilt goedkoop en vroeg falen, niet duur en laat — dus zet u de goedkoopste, dodelijkste tests vooraan.

Praat met mensen — maar doe het goed

Het allernuttigste wat u kunt doen, is praten met de mensen van wie u denkt dat ze het probleem hebben. Niet uw vrienden, niet andere oprichters — de echte mensen die dit zouden gebruiken. En hier zit de valkuil die de meeste pogingen verpest: mensen zijn beleefd. Vraag “zou u een tool gebruiken die X doet?” en bijna iedereen zegt ja, omdat ja zeggen gratis en vriendelijk is. Dat ja is waardeloos. Het heeft meer startups de das om gedaan dan welk technisch falen ook.

De oplossing is om te stoppen met vragen naar de toekomst en te beginnen met vragen naar het verleden. De toekomst is waar mensen liegen om aardig te zijn; het verleden is waar de waarheid woont. In plaats van “zou u dit gebruiken?”, vraagt u “vertel me over de laatste keer dat u met dit probleem te maken had.” Wat deden ze? Hoe lang duurde het? Wat kostte het hen? Zochten ze naar een oplossing? Betaalden ze ervoor? Echt gedrag verslaat hypothetisch enthousiasme elke keer weer.

Vragen die eerlijke antwoorden opleveren

• “Neem me mee terug naar de laatste keer dat dit gebeurde.” — legt de echte werkwijze bloot, niet een geïdealiseerde.
• “Wat heeft u eraan gedaan?” — onthult of het hen echt iets kan schelen of dat ze het van zich afschudden.
• “Hoeveel tijd of geld kostte dat u?” — verandert vage pijn in een getal.
• “Heeft u dit eerder proberen op te lossen? Wat gebeurde er?” — vertelt u of er budget en intentie is.
• “Wat is op dit moment nog vervelender dan dit?” — controleert of uw probleem überhaupt in hun top vijf staat.

Hoeveel gesprekken? Minder dan u zou denken. Tegen de tijd dat u tien eerlijke, goed gevoerde interviews met de juiste mensen heeft gehad, is het patroon meestal duidelijk. Of drie of vier van hen lichten op en beginnen de pijn levendig te beschrijven — of ze zijn allemaal beleefd lauw, en geen enkele slimme build gaat dat oplossen. Twaalf tot vijftien is ruim voldoende om een beslissing te nemen die u kunt vertrouwen.

Goedkope manieren om echte vraag te testen

Gesprekken vertellen u of het probleem echt is. De volgende vraag is of mensen ook werkelijk handelen — en de enige manier om dat te weten is door een kleine toezegging te vragen voordat het product bestaat. Hier wordt validatie een tikje ongemakkelijk, en ook hier wordt het eerlijk. Praten is goedkoop; een klik, een e-mailadres of een aanbetaling niet.

U hoeft niets te bouwen om deze tests uit te voeren. U heeft één pagina nodig die de belofte helder beschrijft en om één specifieke actie vraagt. De actie is de data. Als mensen uw pitch lezen en niets doen, dan is dat uw antwoord, en het is een veel goedkoper antwoord dan over zes maanden lanceren naar krekelgetjirp.

1. 1
   Zet een pitch van één pagina online

   Beschrijf het probleem en uw oplossing in gewone taal, met één duidelijke oproep tot actie. Een eenvoudige landingspagina is genoeg — nog geen product erachter.
2. 2
   Vraag om een echt signaal

   Geen 'like'. Vraag mensen om zich met hun e-mailadres aan te melden voor een wachtlijst, vooruit te bestellen of een gesprek te boeken. Hoe meer het hen kost om ja te zeggen, hoe meer dat ja betekent.
3. 3
   Stuur wat eerlijk verkeer

   Deel het waar uw echte doelgroep al is — een relevante community, een kleine advertentie, een paar directe berichten. U wilt vreemden, niet uw steunende netwerk.
4. 4
   Lees de conversie, niet de complimenten

   Van iedereen die het aanbod werkelijk begreep, hoeveel ondernamen de actie? Een handvol echte aanmeldingen van de juiste mensen verslaat duizend vage goede wensen.

De sterkste vraagtest van allemaal is om vooraf om geld te vragen. Een voorverkoop, een betaalde pilot, een aanbetaling voor vroege toegang — alles waarbij een portemonnee opengaat. Het voelt agressief, en het is het eerlijkste wat u voor uzelf kunt doen. Iemand die zelfs maar een klein bedrag overmaakt voor een product dat nog niet bestaat, vertelt u iets dat geen enkele enquête ooit kan. Als u drie of vier van die mensen kunt vinden, heeft u geen idee meer. U heeft een bedrijf dat erop wacht gebouwd te worden.

Verkoop het voordat u het bouwt

Er is een stap tussen “mensen zijn geïnteresseerd” en “mensen betalen elke maand” die zijn eigen aandacht waard is: de waarde handmatig leveren voordat u hem automatiseert. Als uw idee een tool is die, zeg, rommelige leveranciersmails omzet in een net wekelijks rapport, doe dat dan eerst met de hand voor drie of vier klanten. U wordt de software. Het is traag en het schaalt niet, en dat is precies de bedoeling — het laat u leren wat het product werkelijk moet doen voordat u het in code hebt vastgelegd.

Dit doet twee dingen tegelijk. Het bewijst dat mensen voor het resultaat betalen, niet alleen voor het idee ervan. En het leert u de echte werkwijze — de uitzonderingen, de randgevallen, de dingen waar klanten om geven en die u nooit uit een interview had geraden. Tegen de tijd dat u gaat bouwen, gokt u niet naar de specificatie. U codeert een proces dat u al met de hand hebt uitgevoerd en waarvoor u betaald bent.

De signalen eerlijk lezen

Dit alles werkt alleen als u bereid bent de resultaten te geloven — en dat is moeilijker dan het klinkt, want inmiddels bent u gehecht aan het idee. Het gevaar is niet slechte data; het is een oprichter die elk signaal als aanmoediging interpreteert. Lauwe belangstelling wordt onthouden als enthousiasme. Een beleefde aanmelding voor een wachtlijst wordt “sterke vraag.” U moet hier tegen uw eigen optimisme vechten.

Het helpt om vooraf te bepalen hoe een geslaagde uitkomst eruitziet. Voordat u een test uitvoert, schrijft u op welk resultaat u zou laten doorgaan en welk resultaat u zou laten stoppen. “Als minder dan X van mijn interviews dit beschrijft als een echt, terugkerend probleem, laat ik het vallen.” De lat bepalen voordat u de data ziet, is de enige betrouwbare verdediging tegen het uzelf aanpraten van een build die u niet zou moeten doen.

En soms is het eerlijke antwoord nee. Dat is geen mislukking — dat is het systeem dat werkt. Een validatieproces dat nooit “bouw dit niet” kan opleveren, is geen validatie, het is toestemming zoeken. De oprichters die over een carrière winnen, zijn niet degenen die nooit slechte ideeën hebben. Het zijn degenen die slechte ideeën in drie weken voor een paar honderd euro doden in plaats van ze een jaar lang te koesteren.

Wanneer u werkelijk klaar bent om te bouwen

Stel dat de signalen goed zijn. Het probleem is echt, mensen beschreven het met gevoel, een paar van hen legden geld neer. Nu — en pas nu — is bouwen zinvol. Maar zelfs hier loont terughoudendheid. Het doel van uw eerste versie is niet om het product te zijn dat u zich voorstelt. Het is om het ene kernresultaat te leveren waarvoor uw gevalideerde klanten betalen, en voorlopig niets anders.

Dit is waar validatie u stilletjes een geschenk overhandigt: een scherpe, met bewijs onderbouwde specificatie. U weet voor wie het is, wat de kerntaak is, wat mensen zullen betalen, en welke functies keer op keer naar voren kwamen versus de functies waar alleen u om gaf. Die helderheid is meer waard dan wat voor vooraf-ontwerp dan ook. Het is het verschil tussen het juiste kleine ding bouwen en een duur allesomvattend geheel bouwen.

Veelgestelde vragen