Slik validerer du en SaaS-idé før du skriver en eneste kodelinje

Den dyreste måten å finne ut om folk vil ha programvaren din på er å bygge den. Likevel er det nettopp det de fleste førstegangsgründere gjør — de bruker seks måneder og hele sparekontoen på å gjøre en idé om til kode, lanserer den til total stillhet, og begynner først da å spørre om noen i det hele tatt trengte den. Validering er den billige versjonen av den lærepengen. Det er måten du kjøper svaret på med noen ukers samtaler i stedet for et år av livet ditt.

Jeg har sett mange smarte mennesker gå i den samme fellen. De har en virkelig god observasjon — en reell irritasjon i en bransje de kjenner — og de antar at gapet mellom observasjon og produkt bare er ingeniørarbeid. Det er det ikke. Gapet er fullt av ubesvarte spørsmål: kjenner noen andre på denne smerten nok til å betale? Vil de bytte fra det de gjør i dag? Kan du nå dem uten å brenne av penger? De spørsmålene blir ikke besvart ved å skrive kode. De blir besvart ved å snakke med folk og se hva de faktisk gjør.

Så dette er guiden jeg gir gründere før de leier inn noen til å bygge noe som helst. Den handler ikke om lean-startup-teater eller å fylle ut et canvas. Den handler om en håndfull ærlige, billige eksperimenter som forteller deg om idéen din har en puls — og disiplinen til å tro på resultatene, selv når de svir.

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

Å bygge er forførende fordi det føles som fremgang du kan se. På slutten av en kodeøkt finnes det en skjerm som virker, en knapp som gjør noe, en ting du kan vise partneren din. Å snakke med fremmede om et problem gir ingen artefakt. Det er ubehagelig, det er tregt, og til slutt sitter du igjen med ingenting annet enn notater. Så gründere griper etter tastaturet, fordi tastaturet belønner dem raskere.

Problemet er at en fungerende skjerm forteller deg nesten ingenting om idéen er riktig. Du kan bygge et vakkert, feilfritt produkt for et problem ingen har, og det vil være like dødt som et stygt et. Kode er svaret på «hvordan leverer vi dette?» — ikke «vil noen ha dette?» Å bruke måneder på det første spørsmålet før du har besvart det andre er måten dyktige utviklere bygger elegante løsninger på innbilte problemer.

Validering snur rekkefølgen. Du bruker noen uker og svært lite penger på å bevise — eller motbevise — den mest risikable antakelsen i idéen din før du forplikter deg til å bygge. Er idéen sterk, går du inn i utviklingen med bevis, en tydeligere spesifikasjon og de første brukerne dine allerede ventende. Er den svak, finner du det ut for prisen av noen kaffekopper og en landingsside, ikke prisen av et produkt.

Finn den ene antakelsen som kan velte hele greia

Hver SaaS-idé hviler på en stabel av antakelser, og de er ikke like farlige. Noen er trygge — «folk bruker e-post», «småbedrifter misliker papirarbeid». Andre er veddemål hele foretaket ditt avhenger av, og tar de feil, spiller ingenting annet noen rolle. Jobben med validering er ikke å teste alt. Den er å finne den mest risikable antakelsen og angripe den først.

For å finne den, skriv idéen din som én eneste setning: «[disse menneskene] har [dette problemet] ille nok til å betale for [denne løsningen] i stedet for [det de gjør i dag].» Spør deg så selv, brutalt ærlig: hvilket ord i den setningen ville senke idéen om det viste seg å være usant? Som regel er det ikke løsningen. Det er om problemet er smertefullt nok til å betale for, eller om du faktisk kan nå disse menneskene til en overkommelig pris.

Denne rekkefølgen er viktig fordi kostnaden ved testing stiger for hvert steg. Et problemintervju er gratis. En test av betalingsvilje koster en landingsside. En løsningstest trenger kanskje en klikkbar prototype. Å bygge er den dyreste testen av alle. Du vil feile billig og tidlig, ikke dyrt og sent — så du plasserer de billigste, mest dødelige testene helt fremst.

Snakk med folk — men gjør det riktig

Det aller mest nyttige du kan gjøre er å snakke med menneskene du tror har problemet. Ikke vennene dine, ikke andre gründere — de faktiske menneskene som ville brukt dette. Og her er hakene som ødelegger de fleste forsøk: folk er høflige. Spør «ville du brukt et verktøy som gjør X?», og nesten alle sier ja, fordi det er gratis og hyggelig å si ja. Det jaet er verdiløst. Det har senket flere oppstartsbedrifter enn noen teknisk svikt.

Løsningen er å slutte å spørre om fremtiden og begynne å spørre om fortiden. Fremtiden er der folk lyver for å være snille; fortiden er der sannheten bor. I stedet for «ville du brukt dette?», spør «fortell meg om sist gang du måtte håndtere dette problemet». Hva gjorde de? Hvor lang tid tok det? Hva kostet det dem? Lette de etter en løsning? Betalte de for en? Reell atferd slår hypotetisk entusiasme hver eneste gang.

Spørsmål som gir ærlige svar

• «Ta meg gjennom sist gang dette skjedde.» — får frem den reelle arbeidsflyten, ikke en idealisert.
• «Hva gjorde du med det?» — avslører om de faktisk bryr seg eller bare trekker på skuldrene.
• «Hvor mye tid eller penger kostet det deg?» — gjør vag smerte om til et tall.
• «Har du prøvd å fikse dette før? Hva skjedde?» — forteller deg om det finnes budsjett og intensjon.
• «Hva annet er mer irriterende enn dette akkurat nå?» — sjekker om problemet ditt i det hele tatt kommer på topp fem hos dem.

Hvor mange samtaler? Færre enn du skulle tro. Når du har hatt ti ærlige, godt gjennomførte intervjuer med de rette menneskene, er mønsteret som regel åpenbart. Enten lyser tre eller fire av dem opp og begynner å beskrive smerten i levende detalj — eller så er de alle høflig lunkne, og ingen mengde smart bygging kan fikse det. Tolv til femten er mer enn nok til å ta en avgjørelse du kan stole på.

Billige måter å teste reell etterspørsel på

Samtaler forteller deg om problemet er ekte. Det neste spørsmålet er om folk vil handle — og den eneste måten å vite det på er å be om en liten forpliktelse før produktet finnes. Det er her validering blir litt ubehagelig, og også her den blir ærlig. Snakk er billig; et klikk, en e-postadresse eller et depositum er det ikke.

Du trenger ikke bygge noe for å kjøre disse testene. Du trenger én eneste side som beskriver løftet tydelig og ber om én bestemt handling. Handlingen er dataen. Leser folk pitchen din og gjør ingenting, er det svaret ditt, og det er et langt billigere svar enn å lansere til syrissang om seks måneder.

1. 1
   Sett opp en enkeltsides pitch

   Beskriv problemet og løsningen din på et klart språk, med én tydelig oppfordring til handling. En enkel landingsside holder — ennå uten noe produkt bak.
2. 2
   Be om et reelt signal

   Ikke en «liker». Be folk om å melde seg på en venteliste med e-posten sin, forhåndsbestille eller booke en samtale. Jo mer det koster dem å si ja, jo mer betyr jaet.
3. 3
   Driv litt ærlig trafikk

   Del den der det ekte publikummet ditt allerede er — et relevant fellesskap, en liten annonse, noen direktemeldinger. Du vil ha fremmede, ikke det støttende nettverket ditt.
4. 4
   Les konverteringen, ikke komplimentene

   Av alle som faktisk forsto tilbudet, hvor mange tok handlingen? En håndfull ekte påmeldinger fra de rette menneskene slår tusen vage lykkeønsker.

Den sterkeste etterspørselstesten av alle er å be om penger på forskudd. Et forhåndssalg, en betalt pilot, et depositum mot tidlig tilgang — hva som helst der en lommebok åpner seg. Det føles aggressivt, og det er det mest ærlige du kan gjøre for deg selv. Noen som rekker over selv en liten sum til et produkt som ennå ikke finnes, forteller deg noe ingen spørreundersøkelse noensinne kunne. Klarer du å finne tre eller fire slike mennesker, har du ikke lenger en idé. Du har en bedrift som venter på å bli bygd.

Selg det før du bygger det

Det finnes et steg mellom «folk er interesserte» og «folk vil betale hver måned» som fortjener sin egen oppmerksomhet: å levere verdien manuelt før du automatiserer den. Er idéen din et verktøy som for eksempel gjør rotete leverandør-e-poster om til en ryddig ukerapport, gjør det for hånd for tre eller fire kunder først. Du blir programvaren. Det er tregt og det skalerer ikke, og det er hele poenget — det lar deg lære hva produktet faktisk må gjøre før du har bundet det opp i kode.

Dette gjør to ting på én gang. Det beviser at folk vil betale for resultatet, ikke bare idéen om det. Og det lærer deg den reelle arbeidsflyten — kanttilfellene, unntakene, bitene kundene bryr seg om som du aldri ville gjettet fra et intervju. Når du så bygger, gjetter du ikke på spesifikasjonen. Du koder inn en prosess du allerede har kjørt for hånd og blitt betalt for.

Å lese signalene ærlig

Alt dette fungerer bare hvis du er villig til å tro på resultatene — og det er vanskeligere enn det høres ut, for nå er du knyttet til idéen. Faren er ikke dårlige data; det er en gründer som tolker hvert signal som oppmuntring. Lunken interesse blir husket som entusiasme. En høflig påmelding til ventelisten blir til «sterk etterspørsel». Du må kjempe mot din egen optimisme her.

Det hjelper å bestemme, på forhånd, hvordan en bestått test ser ut. Før du kjører en test, skriv ned resultatet som ville fått deg til å gå videre og resultatet som ville fått deg til å stoppe. «Hvis færre enn X av intervjuene mine beskriver dette som et ekte, tilbakevendende problem, dropper jeg det.» Å avgjøre lista før du ser dataene er det eneste pålitelige forsvaret mot å snakke deg selv inn i en bygging du ikke burde gjøre.

Og noen ganger er det ærlige svaret nei. Det er ikke en fiasko — det er systemet som virker. En valideringsprosess som aldri kan returnere «ikke bygg dette» er ikke validering, den er jakt på tillatelse. Gründerne som vinner over en karriere er ikke de som aldri har dårlige idéer. Det er de som dreper dårlige idéer på tre uker for noen hundrelapper i stedet for å pleie dem i et år.

Når du virkelig er klar til å bygge

La oss si at signalene er gode. Problemet er ekte, folk beskrev det med følelse, noen få av dem la penger på bordet. Nå — og bare nå — gir det mening å bygge. Men selv her lønner tilbakeholdenhet seg. Målet for den første versjonen din er ikke å være produktet du ser for deg. Det er å levere det ene kjerneresultatet de validerte kundene dine betaler for, og ingenting mer ennå.

Det er her validering stille rekker deg en gave: en skarp, bevisbasert spesifikasjon. Du vet hvem det er for, hva kjernejobben er, hva folk vil betale, og hvilke funksjoner som dukket opp igjen og igjen kontra de bare du brydde deg om. Den klarheten er verdt mer enn all verdens forhåndsdesign. Det er forskjellen på å bygge den rette lille tingen og å bygge et dyrt alt.

Vanlige spørsmål