Vad din SaaS-MVP bör — och inte bör — innehålla vid lansering

Ordet ”minimal” i minsta livskraftiga produkt är den del alla ignorerar. Grundare nickar med på idén att börja smått, och lämnar sedan över en kravspec med fyrtio skärmar, tre användarroller, en faktureringsmotor, en analyspanel och ”åh, och den ska integrera med allt”. Det är ingen MVP. Det är en full produkt med optimismen vriden till max. Och det är den enskilt vanligaste anledningen till att första lanseringar kommer sent, över budget och ändå på något sätt saknar den enda sak kunderna faktiskt ville ha.

Jag har hjälpt en hel del småföretag och soloföretagare att få ut sin första mjukvaruprodukt. Den tekniska delen är sällan det som fäller folk. Det svåra — varenda gång — är att avgöra vad man inte ska bygga ännu. En MVP är inte en mindre version av din drömprodukt med funktioner slumpmässigt bortslipade. Det är ett medvetet vad: det minsta du kan sätta framför riktiga användare som bevisar att kärnidén är värd mer av dina pengar och din tid.

Så det här är guiden jag önskar att fler grundare läste innan de skrev sin kravspec. Ingen jargong, ingen ”rör dig snabbt och slå sönder saker”-teater. Bara ett praktiskt sätt att dra gränsen mellan vad som hör hemma i din första release och vad som kan — och bör — vänta.

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

Låt oss reda ut definitionen, för det är här mest av förvirringen börjar. En MVP är den minsta, enklaste versionen av din produkt som låter en riktig person göra den enda värdefulla sak din produkt lovar — och låter dig lära dig om de kommer tillbaka för att göra det igen. Det är allt. Det är ett läroverktyg som råkar vara gjort av fungerande mjukvara, inte en avskalad lansering av den färdiga saken.

Det avgörande ordet är livskraftig. Ett vanligt misstag är att läsa ”minimal” och lansera något så naket att det generar användaren — ett halvt flöde som kraschar, en registrering som leder till en tom skärm. Det är inte minimalt livskraftigt, det är minimalt trasigt. Det andra misslyckandet är det motsatta: en produkt så ”komplett” att den tog ett år att bygga, och då har du redan bränt ditt kapital på att bevisa en gissning du kunde ha testat på åtta veckor.

Här är tankeexperimentet jag använder. För varje funktion på listan, fråga: om vi tog bort den, kunde en användare ändå nå det enda kärnresultat produkten existerar för? Om svaret är ja är den nästan säkert inte MVP. Bara den frågan halverar de flesta kravspecar — och den halva den klipper bort är den som skulle ha gjort dig sen.

Hitta det enda jobb din produkt gör

Innan du kan avgöra vad du ska bygga måste du vara brutalt tydlig med det enda jobb din produkt gör för någon. Inte visionen. Inte färdplanen. Den enda upprepbara handling som, om den fungerar, gör någons dag bättre och får dem villiga att betala. De flesta kämpande kravspecar är vaga just här — de beskriver en plattform, inte ett jobb.

Försök avsluta den här meningen högt: ”En användare kommer till min produkt för att ______, och lämnar med att ha ______.” Ett schemaläggningsverktyg: en chef kommer för att publicera nästa veckas schema och lämnar med varje pass fyllt och teamet meddelat. En faktureringsapp: en frilansare kommer för att fakturera en kund och lämnar med en skickad, spårbar faktura. Om du inte kan fylla i den meningen rent är du inte redo att avgränsa — du är fortfarande redo att tänka.

Vad varje SaaS-MVP verkligen behöver

Vissa saker är icke förhandlingsbara, även i den slimmaste första versionen — inte för att de är spännande, utan för att utan dem kan produkten antingen inte användas eller inte lära dig något. Tänk på dessa som golvet, inte taket. Bygg dem enkelt, men bygg dem ordentligt.

• Ett sätt att logga in. Även en enda inloggning med e-post och lösenord duger — men en riktig, säker, för allt annat hänger på att veta vem användaren är.
• Kärnflödet, från början till slut. Det enda jobbet, från användarens första klick till stunden de får det värdefulla resultatet — inga återvändsgränder, inga ”kommer snart”-knappar i den kritiska vägen.
• Någonstans där datan faktiskt bor. Riktig lagring, inte en slit-och-släng-prototyp, så att en användares arbete överlever en omladdning och de kan komma tillbaka imorgon.
• Ett sätt för dig att se vad som händer. Grundläggande loggning eller en enkel adminvy, så att när något går sönder — och det kommer det att göra — kan du ta reda på varför utan att gissa.
• Ett sätt för användare att nå dig. Även bara en e-postlänk. Tidiga användare kommer att stöta på kanter du inte förutsåg; du vill att de berättar för dig, inte tyst lämnar.
• Det minsta av förtroende: en integritetsnotis, vettig datahantering och att inte göra något vårdslöst med folks information.

Lägg märke till vad som inte står på listan: fakturering, fin onboarding, inställningssidor, mobilappar, integrationer. Vi kommer till varför om en stund. Poängen med golvet är att det är litet nog att bli klart och stabilt nog att lära av. En inloggning som fungerar, ett flöde som levererar, riktig data och ett sätt att observera och prata med användare. Det är en livskraftig produkt.

Vad du medvetet ska lämna utanför v1

Det här är avsnittet grundare gör motstånd mot, så låt mig vara rakt på sak: de flesta saker som känns nödvändiga för din första lansering är det inte. De känns nödvändiga för att en ”riktig produkt” har dem — men du bygger ingen riktig produkt ännu, du bygger en fråga. Att lämna ut dessa är inte att fuska. Det är hela disciplinen i en MVP.

Automatisk fakturering och komplex prissättning

Du behöver nästan säkert ingen självbetjäningsfakturering, nivåindelade planer, proportionering och påminnelselogik i version ett. Om tidiga användare vill betala kan du ta deras pengar manuellt — en faktura, en betallänk, ett snabbt samtal. Manuell fakturering för dina första tio kunder berättar något automatisk inte kan: om någon överhuvudtaget vill betala. Bygg maskinen när du väl bevisat att det finns pengar att kräva in.

Komplicerade roller och behörigheter

Behörighetssystem med flera roller — administratörer, chefer, betraktare, finkorniga åtkomstregler — är ett äkta ingenjörsträsk, och de mångdubblar testytan enormt. För en första release räcker en sorts användare nästan alltid. Du lär dig de riktiga behörighetsbehoven genom att se faktiska team använda saken, och de behoven är sällan vad du hade gissat på pappret.

Integrationer, native mobilappar och panelen

”Den måste integrera med allt” är frasen som tyst dubblar tidsplaner. Välj högst en integration, och bara om den är del av kärnjobbet. Native iOS- och Android-appar kan nästan alltid vänta — en responsiv webbapp fungerar på en telefon redan idag. Och analyspanelen alla vill ha? Användare kan inte analysera data de inte skapat ännu. Lansera först det som skapar datan; visualisera den när det finns något att visa.

En enkel metod för att dra gränsen

Att känna principen är en sak; att tillämpa den på din egen kravspec, där varje funktion känns som ditt barn, är svårare. Här är en metod som fungerar för att den tvingar fram ett beslut för varje post i stället för att låta allt driva in i ”nödvändigt”.

1. 1
   Lista varje funktion du föreställt dig

   Häll ut allt — ingen filtrering än. Få hela önskelistan på bordet så att inget lurar outtalat och dyker upp mitt i bygget som en överraskning.
2. 2
   Markera var och en mot kärnjobbet

   För varje funktion, fråga: behöver en användare den för att fullborda det enda kärnjobbet, från början till slut? Märk den ”kärna”, ”hjälpsam” eller ”någon gång”. Var ärlig — de flesta landar i de två sista.
3. 3
   Behåll bara ”kärna” för v1

   Din MVP är ”kärna”-högen och inget annat. ”Hjälpsam”- och ”någon gång”-högarna är inte avvisade — de är din färdplan, parkerad där de hör hemma.
4. 4
   Förnuftskolla nedskärningen

   Titta på vad som är kvar och fråga: kan en riktig användare få verkligt värde av enbart detta? Om ja har du avgränsat en MVP. Om något genuint bryter kärnflödet, dra tillbaka bara den enda posten — och inget annat.

Disciplinen ligger i steg fyra. Det finns alltid en frestelse att ”dra tillbaka bara en sak till”, och sedan en till, tills du tyst byggt om hela produkten. Tillåt dig själv att rädda bara poster som genuint bryter kärnflödet — inte poster som bara skulle göra det trevligare. Trevligare är vad version två är till för.

Livskraftig betyder fortfarande att den måste kännas äkta

Det finns ett misslyckandeläge på andra sidan gränsen, och det är värt att namnge. I brådskan att lansera smått lanserar vissa grundare slarvigt — och kallar det MVP. Ett kärnflöde som tappar ditt arbete, en registrering som ger 404, text full av platshållartext. Det testar inte din idé rättvist; det testar om användare tolererar en trasig upplevelse, och svaret är alltid nej. Du kommer dra slutsatsen att idén misslyckades när det egentligen var genomförandet.

”Minimal” gäller omfattning, aldrig kvaliteten på den del du behåller. Färre funktioner, var och en stabil. Det enda flöde du lanserar bör kännas färdigt — snabbt, tydligt och pålitligt — även om det är det enda produkten gör. En smal produkt gjord väl slår en bred produkt gjord dåligt varje gång, särskilt när du ber främlingar att anförtro dig sitt arbete.

MVP:n är inte mållinjen — den är den första avläsningen

Här är delen som omformar allt: lanseringen är inte målet. Målet är vad du lär dig under veckorna efter den. En MVP som lanseras och berättar för dig ”användarna älskar kärnan men frågar hela tiden efter X” är en dånande framgång — även om X betyder en månad mer arbete. En MVP som lanseras in i tystnad, utan att någon kommer tillbaka, har också gjort sitt jobb: den räddade dig från att bygga de andra trettio funktionerna på en grund ingen ville ha.

Så planera de första veckorna lika medvetet som bygget. Observera vad folk faktiskt gör, inte vad de säger i enkäter. Prata med dem som kom tillbaka och dem som inte gjorde det. Låt den verkliga användningen — inte din ursprungliga kravspec — avgöra vad som går in i version två. Färdplanen du parkerade tidigare är inte ett löfte; den är en hypotes, och dina användare är på väg att betygsätta den.

Vanliga frågor