Från idé till SaaS-MVP: en grundares guide steg för steg

Nästan varje artikel om att bygga en SaaS är i smyg skriven för någon som redan tagit in pengar. Den förutsätter ett team, en kassakudde, en färdplan och lugnet i att veta att du har råd att ha fel i ett år. Om du är grundare med en verklig idé, ett dagjobb och sparpengar du faktiskt behöver, är det rådet tyst farligt. Det säger åt dig att bygga stort och bygga snabbt — vilket är precis så de flesta första produkter dör innan någon betalar ett öre.

Jag har ägnat mer än ett decennium åt att hjälpa människor förvandla idéer till fungerande mjukvara, och de grundare jag minns bäst är inte de med de djärvaste planerna. Det är de som började smått och förblev ärliga. En fysioterapeut som byggde ett bokningsverktyg för sin egen klinik och slutade med att sälja det till fyrtio andra. En logistikdispatcher som automatiserade sitt eget pappersarbete och insåg att halva branschen hade samma problem. Ingen av dem började med en storslagen plattform. De började med en smärtsam uppgift och en vilja att ta betalt för att lösa den.

Så det här är guiden jag önskar att någon hade räckt de människorna på dag ett. Ingen kapitalanskaffningsteater, ingen trendig arkitektur, inget låtsande att den första versionen behöver vara imponerande. Bara en lugn väg från en aning i ditt huvud till en första betalande kund — och omdömet att veta vad du ska hoppa över på vägen.

Vad en MVP faktiskt är (och vad den inte är)

Termen minimum viable product har tänjts så långt att den knappt betyder något. Vissa grundare hör "minimum" och släpper något pinsamt som ingen kan använda. Andra hör "produkt" och ägnar åtta månader åt att bygga en polerad plattform med prisnivåer, en adminpanel och ett mörkt läge, innan en enda människa har bekräftat att de skulle betala för den. Båda är misstag, och det är samma misstag i olika kläder: att bygga innan du lärt dig något.

En användbar MVP är det minsta du kan ställa framför en verklig användare som bevisar att din kärnidé är värd att betala för. Inte det minsta du kan bygga — det minsta som lär dig något sant. Om din idé är "ett verktyg som låter tandläkare skicka påminnelser automatiskt" är MVP:n påminnelsemotorn och inget annat. Ingen patientportal, ingen analyspanel, inga teamkonton. De är svar på frågor du ännu inte förtjänat.

Anledningen till att detta spelar så stor roll är kostnaden. Varje funktion du bygger före validering är ett vad som lagts blint. Skär ner MVP:n till kärnan och du har lagt ett litet, återhämtningsbart vad. Bygg hela visionen och du har satsat sparpengarna — på en gissning. Disciplinen i "minimum" handlar inte om att vara billig. Den handlar om att hålla sig vid liv tillräckligt länge för att ha rätt.

Validera idén innan du skriver en rad kod

Här är den obekväma sanningen som ingen som säljer dig utveckling vill säga: de flesta SaaS-idéer har fel på något viktigt sätt, och du kan ta reda på det för nästan ingenting. Instinkten är att bygga först och fråga sedan. Vänd på det. Den billigaste versionen av din produkt är ett samtal, och den näst billigaste är en landningssida.

Innan något byggs vill du ha bevis för två saker. Först, att problemet är verkligt och smärtsamt nog att folk redan lägger tid eller pengar på det — klumpigt, med kalkylblad och post-it-lappar och ett verktyg de hatar. Sedan, att de genuint skulle betala för att få det att försvinna. "Det är en fin idé" är inte bevis. "Jag skulle använda det" är inte bevis. "Vad kostar det, och kan jag börja på måndag?" är bevis.

En landningssida med ett tydligt löfte och en knapp för "gå med i väntelistan" eller "boka en demo" är nästa steg. Om du inte kan få en handfull främlingar att lämna en e-postadress för det du beskriver är det inte ett marknadsföringsproblem att fixa senare — det är en signal nu, medan det fortfarande är billigt att höra den. Validering är inte en fas du rusar igenom för att komma till den roliga delen. För en grundare som spenderar sina egna pengar är den den roliga delen: det är där du undviker det dyra misstaget.

Hitta den enda funktion din produkt inte kan leva utan

Varje SaaS-idé kommer, när du först beskriver den, inlindad i ett dussin funktioner. Det finns det den gör, och sedan finns konstellationen av trevliga-att-ha som din hjärna redan kopplat på: rapporter, integrationer, mobilappar, roller och behörigheter, ett publikt API. Den enskilt mest värdefulla färdigheten i att ta sig från idé till MVP är att lära sig skala bort allt det och hitta den enda funktion som, om den försvann, skulle göra hela saken meningslös.

Den kärnfunktionen är din MVP. Allt annat är en hypotes du testar senare, när folk använder kärnan och berättar för dig vad de faktiskt saknar. Grundare gör konsekvent detta baklänges — de bygger biroller först eftersom det känns tryggare, och får slut på tid och pengar innan den enda sak som spelar roll någonsin släpps.

En-mening-testet

Försök beskriva vad din produkt gör i en enda mening utan "och". "Den låter kliniker skicka automatiska tidpåminnelser." "Den förvandlar ett foto av ett kvitto till en bokföringspost." "Den spårar vilka offerter en hantverkare skickat och påminner hen om att följa upp." Om du behöver ett "och" för att beskriva värdet har du förmodligen två produkter som slåss inuti en MVP — och du bör släppa den mer smärtsamma halvan först.

• Skriv ner allt du föreställer dig att produkten gör — få ut allt, filtrera inte.
• Fråga om varje punkt: om detta inte fanns, skulle någon ändå betala? Stryk varje "ja".
• Det som återstår efter strykningen är din kärna. Det är MVP:n.
• Ta de starkaste strukna punkterna och lägg dem på en "senare"-lista — inte borta, bara inte nu.
• Motstå att lägga till dem igen. "Senare"-listan är där goda idéer väntar på att förtjänas, inte där MVP:er går för att dö.

Bygg den, köp den eller fejka den: hur du gör MVP:n

När du väl känner din enda kärnfunktion har du ett val som grundare sällan gör medvetet: hur mycket av detta behöver du faktiskt bygga från grunden? Det ärliga svaret, för en första version, är oftast "mindre än du tror". Det finns tre breda vägar, och det smarta draget är ofta en blandning.

No-code- / limvägen

För vissa MVP:er kan du koppla ihop befintliga verktyg — ett formulär, en databas, ett automationslager, en e-posttjänst — och validera idén utan att skriva någon egen kod alls. Det här är lysande för att testa om folk kommer använda och betala för arbetsflödet. Det är snabbt och billigt. Dess gränser visar sig senare: när du behöver en verklig produktupplevelse, din egen datamodell eller något genuint unikt börjar limmet spänna. Det är ett bra problem — det betyder att det är dags att bygga ordentligt, med betalande användare redan i handen.

Den skräddarsydda byggvägen

När din kärnfunktion är det som skiljer dig från mängden — det faktiska skälet till att kunder väljer dig — förtjänar den delen verklig, skräddarsydd mjukvara. Misstaget är att skräddarbygga allt runt den. Du behöver inte skriva din egen autentisering, betalningshantering eller e-postinfrastruktur; det är lösta problem som du bör hyra. Bygg den del som är unikt din, hyr resten, och du håller både kostnaden och tidsplanen ärlig.

De flesta framgångsrika MVP:er jag sett är en medveten blandning: hyrda byggstenar för det tråkiga-men-nödvändiga röret, och fokuserad skräddarsydd utveckling för den enda sak som gör produkten värd att betala för. Att veta vilket som är vilket — vad du ska bygga kontra vad du ska köpa — är precis den sortens beslut som är värt att få en andra åsikt om innan du spenderar något.

Vad du tryggt kan hoppa över i version ett

Att veta vad du ska lämna ute är lika viktigt som att veta vad du ska bygga, och det är där grundare behöver mest tillåtelse. Så här är den: du har tillåtelse att hoppa över nästan allt. Den första versionen finns för att lära, inte för att imponera, och nästan inget av det som får en produkt att kännas "färdig" hjälper dig faktiskt att lära.

• Flera prisnivåer — välj ett pris, eller fakturera till och med manuellt i början.
• Ett självbetjäningsflöde för registrering — att introducera dina första tio kunder för hand lär dig mer än någon automatiserad tratt.
• En adminpanel med diagram — du kan läsa databasen direkt så länge det finns tio användare.
• Mobilappar, om webben fungerar fint på en telefon för tillfället.
• Roller, behörigheter och teamkonton — tills en verklig kund blockeras utan dem.
• Polerade inställningar, teman och varje gränsfall — hantera den vanliga vägen först, resten när någon stöter på det.

En realistisk väg från idé till första kund

Här är sekvensen jag skulle ta nästan vilken grundare som helst igenom. Den är medvetet långsam i början och snabb när du väl bygger, eftersom de dyra misstagen alla bor i de tidiga stegen — de som grundare frestas mest att hoppa över.

1. 1
   Skriv problemet i en mening

   Inte lösningen — problemet. "Kliniker förlorar pengar på uteblivna besök eftersom påminnelser är manuella." Om du inte kan formulera problemet rent är du inte redo att lösa det.
2. 2
   Ha tio verkliga samtal

   Prata med människor som har problemet. Lyssna efter smärta och efter pengar som redan läggs. Justera eller överge idén utifrån vad du hör, inte vad du hoppades.
3. 3
   Sätt upp en landningssida och ett pris

   Beskriv löftet rakt, namnge ett pris och be om en e-postadress eller en demobokning. Se om främlingar lutar sig framåt. Det här är validering du kan lita på.
4. 4
   Definiera den enda kärnfunktionen

   Skala idén till den enda sak som, om den saknas, gör den meningslös. Skriv en-meningen-beskrivningen utan "och". Det är din byggomfattning.
5. 5
   Bestäm bygga eller köpa för varje del

   Skräddarbygg bara det som skiljer dig åt. Hyr inloggning, betalningar, e-post och hosting. Få den här kartan rätt innan någon skriver kod — den sätter hela din budget.
6. 6
   Bygg den minsta fungerande versionen

   Sikta på veckor, inte månader. Om enbart kärnfunktionen tar längre tid än ett par månader är omfattningen fortfarande för stor — skär igen.
7. 7
   Introducera dina första kunder för hand

   Gå igenom den med dem personligen. Iaktta var de snubblar. De första tio användarna är ditt bästa produktteam — och din första intäkt.
8. 8
   Förbättra utifrån användning, inte åsikt

   Ändra det som verklig användning säger åt dig att ändra. Först nu börjar du plocka punkter från "senare"-listan — förtjänade av efterfrågan, inte tillagda genom gissning.

Vad det faktiskt kostar — i pengar och i tid

Grundare ställer alltid kostnadsfrågan först, och det ärliga svaret är "det beror på, och du styr det mesta av det". Den enskilt största kostnadsdrivaren är omfattningen — hur mycket du bestämde dig för att bygga innan du bestämde dig för att lära. En tajt MVP med en kärnfunktion, där du hyr röret, är ett blygsamt, definierat projekt. Samma idé byggd som en full plattform med allt påslaget är ett annat kostnadsuniversum och en långt högre risk att misslyckas före lansering.

Kostnaden de flesta glömmer är tid — din. Varje månad du lägger på att bygga något som ingen bekräftat att de kommer köpa är en månad av ditt liv och dina sparpengar lagd på en gissning. Det är det verkliga argumentet för att börja smått: inte att smått är billigt, utan att smått är snabbt, och snabbt betyder att du lär dig om du har rätt medan vadet fortfarande är återhämtningsbart. En grundare som når en betalande kund på tre månader med ett smalt verktyg är i ett oerhört mycket starkare läge än en som fortfarande polerar en storslagen plattform ett år in.

Det finns en tystare kostnad också: varje funktion du släpper är något du nu måste underhålla, stödja och förklara. En liten produkt som gör en sak tillförlitligt är billigare att driva, lättare att sälja och enklare att förbättra än en vidlyftig som gör tio saker halvbra. Återhållsamhet är inte bara hur du överlever byggandet — det är hur du håller verksamheten levbar efteråt.

Vanliga frågor