Sådan validerer du en SaaS-idé, før du skriver en eneste linje kode

Den dyreste måde at finde ud af, om folk vil have din software, er at bygge den. Alligevel er det præcis, hvad de fleste førstegangsstiftere gør — de bruger seks måneder og deres opsparing på at omdanne en idé til kode, lancerer den til stilhed og begynder først da at spørge, om nogen overhovedet havde brug for den. Validering er den billige version af den lektie. Det er måden, du køber svaret for nogle få ugers samtaler i stedet for et år af dit liv.

Jeg har set mange kloge mennesker falde i den samme fælde. De har en oprigtigt god observation — en reel irritation i en branche, de kender — og de antager, at kløften mellem observation og produkt blot er ingeniørarbejde. Det er den ikke. Kløften er fuld af ubesvarede spørgsmål: føler nogen anden denne smerte nok til at betale? Vil de skifte fra det, de gør nu? Kan du nå dem uden at brænde penge af? De spørgsmål besvares ikke ved at skrive kode. De besvares ved at tale med folk og se, hvad de rent faktisk gør.

Så dette er guiden, jeg giver stiftere, før de hyrer nogen til at bygge noget. Det handler ikke om lean startup-teater eller om at udfylde et canvas. Det handler om en håndfuld ærlige, billige eksperimenter, der fortæller dig, om din idé har en puls — og om disciplinen til at tro på resultaterne, selv når de svier.

Hvorfor det føles produktivt at bygge først — og som regel ikke er det

At bygge er forførende, fordi det føles som synlige fremskridt. Ved slutningen af en kodningssession er der en skærm, der virker, en knap, der gør noget, en ting, du kan vise din partner. At tale med fremmede om et problem giver ingen artefakt. Det er ubehageligt, det er langsomt, og til sidst har du intet andet end noter. Så stiftere griber tastaturet, fordi tastaturet belønner dem hurtigere.

Problemet er, at en fungerende skærm fortæller dig næsten intet om, hvorvidt idéen er rigtig. Du kan bygge et smukt, fejlfrit produkt til et problem, ingen har, og det vil være lige så dødt som et grimt. Kode er svaret på “hvordan leverer vi dette?” — ikke “vil nogen have dette?” At bruge måneder på det første spørgsmål, før du har besvaret det andet, er måden, dygtige ingeniører bygger elegante løsninger på indbildte problemer.

Validering vender rækkefølgen om. Du bruger nogle få uger og meget få penge på at bevise — eller modbevise — den mest risikable antagelse i din idé før du forpligter dig til at bygge. Hvis idéen er stærk, går du ind i udviklingen med beviser, en klarere kravspecifikation og dine første brugere allerede ventende. Hvis den er svag, finder du ud af det for prisen af nogle kopper kaffe og en landingsside, ikke for prisen af et produkt.

Find den ene antagelse, der kan vælte hele projektet

Enhver SaaS-idé hviler på en stak af overbevisninger, og de er ikke lige farlige. Nogle er sikre — “folk bruger e-mail”, “små virksomheder kan ikke lide papirarbejde”. Andre er væddemål, som hele dit projekt afhænger af, og hvis de er forkerte, betyder intet andet noget. Valideringens opgave er ikke at teste alt. Det er at finde den mest risikable antagelse og angribe netop den først.

For at finde den, skriv din idé som en enkelt sætning: “[disse mennesker] har [dette problem] slemt nok til at betale for [denne løsning] i stedet for [det, de gør nu].” Spørg så dig selv brutalt: hvilket ord i den sætning ville, hvis det viste sig falsk, sænke idéen? Som regel er det ikke løsningen. Det er, om problemet er smertefuldt nok til at betale for, eller om du faktisk kan nå de mennesker til en overkommelig pris.

Denne rækkefølge er vigtig, fordi omkostningen ved at teste stiger ved hvert trin. Et probleminterview er gratis. En betalingsviljetest koster en landingsside. En løsningstest kan kræve en klikbar prototype. At bygge er den dyreste test af alle. Du vil fejle billigt og tidligt, ikke dyrt og sent — så du sætter de billigste, mest dødelige tests forrest.

Tal med folk — men gør det rigtigt

Det enkeltvis mest nyttige, du kan gøre, er at tale med de mennesker, du tror har problemet. Ikke dine venner, ikke andre stiftere — de faktiske mennesker, der ville bruge dette. Og her er hagen, der ødelægger de fleste forsøg: folk er høflige. Spørg “ville du bruge et værktøj, der gør X?”, og næsten alle siger ja, fordi det at sige ja er gratis og venligt. Det ja er værdiløst. Det har sænket flere startups end nogen teknisk fiasko.

Løsningen er at holde op med at spørge om fremtiden og begynde at spørge om fortiden. Fremtiden er, hvor folk lyver for at være søde; fortiden er, hvor sandheden bor. I stedet for “ville du bruge dette?”, spørg “fortæl mig om sidste gang, du håndterede dette problem.” Hvad gjorde de? Hvor lang tid tog det? Hvad kostede det dem? Ledte de efter en løsning? Betalte de for en? Reel adfærd slår hypotetisk begejstring hver eneste gang.

Spørgsmål, der giver ærlige svar

• “Tag mig igennem sidste gang, dette skete.” — afdækker det reelle arbejdsflow, ikke et idealiseret.
• “Hvad gjorde du ved det?” — afslører, om de rent faktisk bekymrer sig eller bare trækker på skuldrene.
• “Hvor meget tid eller penge kostede det dig?” — forvandler vag smerte til et tal.
• “Har du prøvet at løse dette før? Hvad skete der?” — fortæller dig, om der er budget og hensigt.
• “Hvad andet er mere irriterende end dette lige nu?” — tjekker, om dit problem overhovedet kommer på deres top fem.

Hvor mange samtaler? Færre, end du skulle tro. Når du har haft ti ærlige, velgennemførte interviews med de rigtige mennesker, er mønstret som regel åbenlyst. Enten lyser tre eller fire af dem op og begynder at beskrive smerten i levende detaljer — eller de er alle høfligt lunkne, og ingen smart bygning kan rette op på det. Tolv til femten er rigeligt til at træffe en beslutning, du kan stole på.

Billige måder at teste reel efterspørgsel på

Samtaler fortæller dig, om problemet er reelt. Det næste spørgsmål er, om folk vil handle — og den eneste måde at vide det på er at bede om en lille forpligtelse, før produktet eksisterer. Det er her, validering bliver lidt ubehagelig, og også hvor den bliver ærlig. Snak er billig; et klik, en e-mailadresse eller et depositum er det ikke.

Du behøver ikke bygge noget for at køre disse tests. Du har brug for en enkelt side, der klart beskriver løftet og beder om én bestemt handling. Handlingen er dataene. Hvis folk læser dit pitch og ikke gør noget, er det dit svar, og det er et langt billigere svar end at lancere til tavshed om seks måneder.

1. 1
   Sæt et énsides-pitch op

   Beskriv problemet og din løsning i et klart sprog, med én tydelig opfordring til handling. En simpel landingsside er nok — endnu intet produkt bag den.
2. 2
   Bed om et reelt signal

   Ikke et “like”. Bed folk om at tilmelde sig en venteliste med deres e-mail, forudbestille eller booke et opkald. Jo mere det koster dem at sige ja, desto mere betyder ja’et.
3. 3
   Skab lidt ærlig trafik

   Del det, hvor dit reelle publikum allerede er — et relevant fællesskab, en lille annonce, nogle få direkte beskeder. Du vil have fremmede, ikke dit støttende netværk.
4. 4
   Læs konverteringen, ikke komplimenterne

   Ud af alle, der oprigtigt forstod tilbuddet, hvor mange tog handlingen? En håndfuld reelle tilmeldinger fra de rigtige mennesker slår tusind vage lykønskninger.

Den allerstærkeste efterspørgselstest er at bede om penge på forhånd. Et forsalg, en betalt pilot, et depositum mod tidlig adgang — alt, hvor en pengepung åbnes. Det føles aggressivt, og det er det ærligste, du kan gøre for din egen skyld. En person, der overdrager selv et lille beløb til et produkt, der endnu ikke eksisterer, fortæller dig noget, som ingen undersøgelse nogensinde kunne. Hvis du kan finde tre eller fire af den slags mennesker, har du ikke længere en idé. Du har en virksomhed, der venter på at blive bygget.

Sælg det, før du bygger det

Der er et trin mellem “folk er interesserede” og “folk vil betale hver måned”, som fortjener sin egen opmærksomhed: at levere værdien manuelt, før du automatiserer den. Hvis din idé er et værktøj, der f.eks. omdanner rodede leverandørmails til en pæn ugentlig rapport, så gør det i hånden for tre eller fire kunder først. Du bliver softwaren. Det er langsomt, og det skalerer ikke, og det er netop pointen — det lader dig lære, hvad produktet rent faktisk skal gøre, før du har låst det fast i kode.

Dette gør to ting på én gang. Det beviser, at folk vil betale for resultatet, ikke kun idéen om det. Og det lærer dig det reelle arbejdsflow — grænsetilfældene, undtagelserne, de dele, kunderne bekymrer sig om, som du aldrig ville have gættet fra et interview. Når du endelig bygger, gætter du ikke på kravspecifikationen. Du koder en proces, du allerede har kørt i hånden og fået betaling for.

At læse signalerne ærligt

Alt dette virker kun, hvis du er villig til at tro på resultaterne — og det er sværere, end det lyder, fordi du på dette tidspunkt er knyttet til idéen. Faren er ikke dårlige data; det er en stifter, der fortolker hvert signal som opmuntring. Lunken interesse huskes som begejstring. En høflig ventelistetilmelding bliver til “stærk efterspørgsel”. Du er nødt til at bekæmpe din egen optimisme her.

Det hjælper at beslutte på forhånd, hvordan en bestået test ser ud. Før du kører en test, skriv resultatet ned, der ville få dig til at fortsætte, og resultatet, der ville få dig til at stoppe. “Hvis færre end X af mine interviews beskriver dette som et reelt, tilbagevendende problem, dropper jeg det.” At fastsætte barren, før du ser dataene, er det eneste pålidelige forsvar mod at tale dig selv ind i en bygning, du ikke burde lave.

Og nogle gange er det ærlige svar nej. Det er ikke en fiasko — det er systemet, der virker. En valideringsproces, der aldrig kan returnere “byg ikke dette”, er ikke validering, det er at bede om tilladelse. De stiftere, der vinder over en karriere, er ikke dem, der aldrig har dårlige idéer. Det er dem, der dræber dårlige idéer på tre uger for et par hundrede euro i stedet for at pleje dem i et år.

Når du oprigtigt er klar til at bygge

Lad os sige, at signalerne er gode. Problemet er reelt, folk beskrev det med følelse, et par stykker lagde penge på bordet. Nu — og først nu — giver det mening at bygge. Men selv her betaler tilbageholdenhed sig. Målet med din første version er ikke at være det produkt, du forestiller dig. Det er at levere det ene kerneresultat, dine validerede kunder betaler for, og intet andet endnu.

Det er her, validering stille rækker dig en gave: en skarp, evidensbaseret kravspecifikation. Du ved, hvem den er til, hvad kerneopgaven er, hvad folk vil betale, og hvilke funktioner der dukkede op igen og igen sammenlignet med dem, kun du gik op i. Den klarhed er mere værd end nogen mængde forhåndsdesign. Det er forskellen mellem at bygge den rigtige lille ting og at bygge et dyrt alt-muligt.

Almindelige spørgsmål