Fra idé til SaaS-MVP: en grunders guide steg for steg

Nesten hver artikkel om å bygge en SaaS er i det skjulte skrevet for noen som allerede har hentet inn penger. Den forutsetter et team, en likviditetsbuffer, et veikart og roen i å vite at du har råd til å ta feil i et år. Hvis du er grunder med en ekte idé, en dagjobb og sparepenger du faktisk trenger, er det rådet stille farlig. Det sier at du skal bygge stort og bygge raskt — som er nøyaktig slik de fleste første produkter dør før noen betaler en krone.

Jeg har brukt mer enn et tiår på å hjelpe folk med å gjøre idéer om til fungerende programvare, og grunderne jeg husker best er ikke de med de modigste planene. Det er de som startet smått og forble ærlige. En fysioterapeut som bygde et bookingverktøy for sin egen klinikk og endte med å selge det til førti andre. En logistikkdisponent som automatiserte sitt eget papirarbeid og innså at halve bransjen hadde samme problem. Ingen av dem begynte med en storslått plattform. De begynte med én smertefull oppgave og en vilje til å ta betalt for å løse den.

Så dette er guiden jeg skulle ønske noen hadde rakt de menneskene på dag én. Ingen kapitalinnhentingsteater, ingen moteriktig arkitektur, ingen lek med at den første versjonen må være imponerende. Bare en rolig vei fra en anelse i hodet ditt til en første betalende kunde — og dømmekraften til å vite hva du skal hoppe over underveis.

Hva en MVP egentlig er (og hva den ikke er)

Begrepet minimum viable product er strukket så langt at det knapt betyr noe. Noen grundere hører "minimum" og slipper noe pinlig som ingen kan bruke. Andre hører "produkt" og bruker åtte måneder på å bygge en polert plattform med prisnivåer, et adminpanel og en mørk modus, før et eneste menneske har bekreftet at de ville betalt for den. Begge er feil, og det er den samme feilen i ulike klær: å bygge før du har lært noe.

En nyttig MVP er det minste du kan sette foran en ekte bruker som beviser at kjerneidéen din er verdt å betale for. Ikke det minste du kan bygge — det minste som lærer deg noe sant. Hvis idéen din er "et verktøy som lar tannleger sende påminnelser automatisk", er MVP-en påminnelsesmotoren og ingenting annet. Ingen pasientportal, intet analysedashbord, ingen teamkontoer. Det er svar på spørsmål du ennå ikke har gjort deg fortjent til.

Grunnen til at dette betyr så mye er kostnaden. Hver funksjon du bygger før validering er et veddemål plassert i blinde. Skjær MVP-en ned til kjernen, og du har plassert ett lite, gjenvinnbart veddemål. Bygg hele visjonen, og du har satset sparepengene — på en gjetning. Disiplinen i "minimum" handler ikke om å være billig. Den handler om å holde seg i live lenge nok til å få rett.

Valider idéen før du skriver en linje kode

Her er den ubehagelige sannheten som ingen som selger deg utvikling vil si: de fleste SaaS-idéer er feil på en viktig måte, og du kan finne det ut for nesten ingenting. Instinktet er å bygge først og spørre etterpå. Snu det. Den billigste versjonen av produktet ditt er en samtale, og den nest billigste er en landingsside.

Før noe blir bygget, vil du ha bevis for to ting. For det første at problemet er ekte og smertefullt nok til at folk allerede bruker tid eller penger på det — klønete, med regneark og post-it-lapper og et verktøy de hater. For det andre at de oppriktig ville betalt for å få det til å forsvinne. "Det er en fin idé" er ikke bevis. "Det ville jeg brukt" er ikke bevis. "Hva koster det, og kan jeg starte mandag?" er bevis.

En landingsside med et tydelig løfte og en knapp for "bli med på ventelisten" eller "book en demo" er neste steg. Hvis du ikke får en håndfull fremmede til å legge igjen en e-post for det du beskriver, er det ikke et markedsføringsproblem å fikse senere — det er et signal nå, mens det fortsatt er billig å høre det. Validering er ikke en fase du haster gjennom for å komme til den morsomme delen. For en grunder som bruker sine egne penger er den den morsomme delen: det er der du unngår den dyre feilen.

Finn den ene funksjonen produktet ditt ikke kan leve uten

Enhver SaaS-idé kommer, når du først beskriver den, pakket inn i et dusin funksjoner. Det er det den gjør, og så er det konstellasjonen av kjekt-å-ha som hjernen din allerede har festet på: rapporter, integrasjoner, mobilapper, roller og rettigheter, et offentlig API. Den enkeltvis mest verdifulle ferdigheten i å komme fra idé til MVP er å lære seg å skrelle bort alt det og finne den ene funksjonen som, hvis den forsvant, ville gjort hele saken meningsløs.

Den kjernefunksjonen er MVP-en din. Alt annet er en hypotese du tester senere, når folk bruker kjernen og forteller deg hva de faktisk savner. Grundere får konsekvent dette baklengs — de bygger birollene først fordi det føles tryggere, og går tom for tid og penger før den ene tingen som betyr noe i det hele tatt blir sluppet.

Én-setnings-testen

Prøv å beskrive hva produktet ditt gjør i én setning uten "og". "Det lar klinikker sende automatiske timepåminnelser." "Det gjør et bilde av en kvittering om til en regnskapspostering." "Det sporer hvilke tilbud en håndverker har sendt og minner vedkommende om å følge opp." Hvis du trenger et "og" for å beskrive verdien, har du sannsynligvis to produkter som slåss inne i én MVP — og du bør slippe den mer smertefulle halvdelen først.

• Skriv ned alt du ser for deg at produktet gjør — få alt ut, ikke filtrer.
• Spør for hvert punkt: hvis dette ikke fantes, ville noen fortsatt betalt? Stryk ut hvert "ja".
• Det som er igjen etter overstrykingen er kjernen din. Det er MVP-en.
• Ta de sterkeste overstrøkne punktene og legg dem på en "senere"-liste — ikke borte, bare ikke nå.
• Motstå å legge dem til igjen. "Senere"-listen er der gode idéer venter på å bli fortjent, ikke der MVP-er går for å dø.

Bygg den, kjøp den eller fake den: slik lager du MVP-en

Når du først kjenner din ene kjernefunksjon, har du et valg som grundere sjelden tar bevisst: hvor mye av dette trenger du faktisk å bygge fra bunnen? Det ærlige svaret, for en første versjon, er som regel "mindre enn du tror". Det finnes tre brede veier, og det smarte trekket er ofte en blanding.

No-code- / limveien

For noen MVP-er kan du koble sammen eksisterende verktøy — et skjema, en database, et automatiseringslag, en e-posttjeneste — og validere idéen uten å skrive noen egen kode i det hele tatt. Dette er glimrende for å teste om folk vil bruke og betale for arbeidsflyten. Det er raskt og billig. Grensene viser seg senere: når du trenger en ekte produktopplevelse, din egen datamodell eller noe genuint unikt, begynner limet å stramme. Det er et godt problem — det betyr at det er på tide å bygge ordentlig, med betalende brukere allerede i hånden.

Den skreddersydde byggeveien

Når kjernefunksjonen din er det som skiller deg ut — selve grunnen til at kunder velger deg — fortjener den delen ekte, skreddersydd programvare. Feilen er å skreddersy alt rundt den. Du trenger ikke å skrive din egen autentisering, betalingshåndtering eller e-postinfrastruktur; det er løste problemer som du bør leie. Bygg delen som er unikt din, lei resten, og du holder både kostnaden og tidsplanen ærlig.

De fleste vellykkede MVP-ene jeg har sett er en bevisst blanding: leide byggeklosser for det kjedelige-men-nødvendige rørarbeidet, og fokusert skreddersydd utvikling for den ene tingen som gjør produktet verdt å betale for. Å vite hva som er hva — hva du skal bygge kontra hva du skal kjøpe — er nøyaktig den typen beslutning det er verdt å få en ny vurdering på før du bruker noe.

Hva du trygt kan hoppe over i versjon én

Å vite hva du skal utelate er like viktig som å vite hva du skal bygge, og det er der grundere trenger mest tillatelse. Så her er den: du har tillatelse til å hoppe over nesten alt. Den første versjonen finnes for å lære, ikke for å imponere, og nesten ingenting av det som får et produkt til å føles "ferdig" hjelper deg faktisk med å lære.

• Flere prisnivåer — velg én pris, eller fakturer til og med manuelt i begynnelsen.
• En selvbetjent registreringsflyt — å onboarde dine første ti kunder for hånd lærer deg mer enn noen automatisert trakt.
• Et admindashbord med diagrammer — du kan lese databasen direkte mens det er ti brukere.
• Mobilapper, hvis weben fungerer fint på en telefon foreløpig.
• Roller, rettigheter og teamkontoer — helt til en ekte kunde blir blokkert uten dem.
• Polerte innstillinger, temaer og hvert eneste grensetilfelle — håndter den vanlige veien først, resten når noen treffer på den.

En realistisk vei fra idé til første kunde

Her er rekkefølgen jeg ville tatt nesten hvilken som helst grunder gjennom. Den er bevisst langsom i begynnelsen og rask når du først bygger, fordi de dyre feilene alle bor i de tidlige stegene — de grundere er mest fristet til å hoppe over.

1. 1
   Skriv problemet i én setning

   Ikke løsningen — problemet. "Klinikker taper penger på ikke-oppmøter fordi påminnelser er manuelle." Hvis du ikke kan formulere problemet rent, er du ikke klar til å løse det.
2. 2
   Ha ti ekte samtaler

   Snakk med folk som har problemet. Lytt etter smerte og etter penger som allerede brukes. Juster eller forkast idéen ut fra hva du hører, ikke hva du håpet.
3. 3
   Sett opp en landingsside og en pris

   Beskriv løftet rett frem, navngi en pris, og be om en e-post eller en demobooking. Se om fremmede lener seg fram. Dette er validering du kan stole på.
4. 4
   Definer den ene kjernefunksjonen

   Skrell idéen ned til den ene tingen som, hvis den mangler, gjør den meningsløs. Skriv én-setnings-beskrivelsen uten "og". Det er byggeomfanget ditt.
5. 5
   Bestem bygge eller kjøpe for hver del

   Skreddersy kun det som skiller deg ut. Lei innlogging, betalinger, e-post og hosting. Få dette kartet riktig før noen skriver kode — det setter hele budsjettet ditt.
6. 6
   Bygg den minste fungerende versjonen

   Sikt mot uker, ikke måneder. Hvis kjernefunksjonen alene tar lengre tid enn et par måneder, er omfanget fortsatt for stort — skjær igjen.
7. 7
   Onboard dine første kunder for hånd

   Gå gjennom den med dem personlig. Følg med på hvor de snubler. De første ti brukerne er ditt beste produktteam — og din første omsetning.
8. 8
   Forbedre ut fra bruk, ikke mening

   Endre det som ekte bruk forteller deg å endre. Først nå begynner du å trekke punkter fra "senere"-listen — fortjent av etterspørsel, ikke lagt til ved gjetning.

Hva det faktisk koster — i penger og i tid

Grundere stiller alltid kostnadsspørsmålet først, og det ærlige svaret er "det kommer an på, og du styrer det meste av det". Den enkeltvis største driveren av kostnad er omfanget — hvor mye du bestemte deg for å bygge før du bestemte deg for å lære. En stram MVP med én kjernefunksjon, der du leier rørarbeidet, er et beskjedent, definert prosjekt. Den samme idéen bygget som en full plattform med alt påslått er et annet kostnadsunivers og en langt høyere risiko for å feile før lansering.

Kostnaden de fleste glemmer er tid — din. Hver måned du bruker på å bygge noe ingen har bekreftet at de vil kjøpe, er en måned av livet ditt og sparepengene dine brukt på en gjetning. Det er det egentlige argumentet for å starte smått: ikke at smått er billig, men at smått er raskt, og raskt betyr at du lærer om du har rett mens veddemålet fortsatt er gjenvinnbart. En grunder som når en betalende kunde på tre måneder med et smalt verktøy er i en langt sterkere posisjon enn en som fortsatt polerer en storslått plattform et år ut.

Det finnes en mer stillferdig kostnad også: hver funksjon du slipper er noe du nå må vedlikeholde, supportere og forklare. Et lite produkt som gjør én ting pålitelig er billigere å drifte, lettere å selge og enklere å forbedre enn et omfangsrikt som gjør ti ting halvgodt. Tilbakeholdenhet er ikke bare hvordan du overlever byggingen — det er hvordan du holder forretningen levelig etterpå.

Vanlige spørsmål