Hvad din SaaS-MVP bør — og ikke bør — indeholde ved lancering

Ordet ”minimum” i mindste levedygtige produkt er den del, alle ignorerer. Stiftere nikker med til idéen om at starte småt og afleverer så en kravspecifikation med fyrre skærme, tre brugerroller, en faktureringsmotor, et analysedashboard og ”nå ja, og den skal integrere med alt”. Det er ikke en MVP. Det er et fuldt produkt med optimismen skruet helt op. Og det er den enkeltstående mest almindelige grund til, at første lanceringer kommer for sent, over budget og alligevel på en eller anden måde mangler den ene ting, kunderne faktisk ville have.

Jeg har hjulpet en del små virksomheder og solo-stiftere med at få deres første softwareprodukt ud over rampen. Den tekniske del er sjældent det, der vælter folk. Det svære — hver eneste gang — er at afgøre, hvad man ikke skal bygge endnu. En MVP er ikke en mindre version af dit drømmeprodukt med funktioner slebet tilfældigt af. Det er et bevidst væddemål: det mindste, du kan sætte foran rigtige brugere, der beviser, at kerneidéen er flere af dine penge og din tid værd.

Så dette er den guide, jeg ville ønske flere stiftere læste, før de skrev deres kravspecifikation. Ingen jargon, ingen ”bevæg dig hurtigt og slå ting i stykker”-teater. Bare en praktisk måde at trække grænsen mellem, hvad der hører hjemme i din første udgivelse, og hvad der kan — og bør — vente.

Hvad en MVP faktisk er (og hvad den ikke er)

Lad os få definitionen på plads, for det er her, det meste forvirring starter. En MVP er den mindste, enkleste version af dit produkt, der lader en rigtig person gøre den ene værdifulde ting, dit produkt lover — og lader dig lære, om de kommer tilbage for at gøre det igen. Det er det. Det er et læringsværktøj, der tilfældigvis er lavet af fungerende software, ikke en afskrabet lancering af det færdige produkt.

Det afgørende ord er levedygtig. En almindelig fejl er at læse ”minimum” og lancere noget så bart, at det gør brugeren forlegen — et halvt flow, der går ned, en tilmelding, der fører til en tom skærm. Det er ikke minimum-levedygtigt, det er minimum-i-stykker. Den anden fiasko er det modsatte: et produkt så ”komplet”, at det tog et år at bygge, og da har du allerede brændt din kapital på at bevise et gæt, du kunne have testet på otte uger.

Her er den tankeprøve, jeg bruger. For hver funktion på listen, spørg: hvis vi fjernede den, kunne en bruger så stadig opnå det ene kerneresultat, produktet eksisterer for? Hvis svaret er ja, er den næsten med sikkerhed ikke MVP. Alene det spørgsmål halverer de fleste kravspecifikationer — og den halvdel, det skærer væk, er den, der ville have gjort dig forsinket.

Find det ene job, dit produkt udfører

Før du kan afgøre, hvad du skal bygge, skal du være brutalt klar over det ene job, dit produkt udfører for nogen. Ikke visionen. Ikke roadmappet. Den ene gentagelige handling, der, hvis den virker, gør en persons dag bedre og gør dem villige til at betale. De fleste kæmpende kravspecifikationer er vage præcis her — de beskriver en platform, ikke et job.

Prøv at afslutte denne sætning højt: ”En bruger kommer til mit produkt for at ______ og går igen efter at have ______.” Et vagtplanlægningsværktøj: en leder kommer for at offentliggøre næste uges vagtplan og går igen med hver vagt dækket og teamet underrettet. En faktureringsapp: en freelancer kommer for at fakturere en kunde og går igen med en sendt, sporbar faktura. Hvis du ikke kan udfylde den sætning rent, er du ikke klar til at afgrænse — du er stadig klar til at tænke.

Hvad enhver SaaS-MVP reelt har brug for

Nogle ting er ikke til forhandling, selv i den slankeste første version — ikke fordi de er spændende, men fordi produktet uden dem enten ikke kan bruges eller ikke kan lære dig noget. Tænk på disse som gulvet, ikke loftet. Byg dem enkelt, men byg dem ordentligt.

• En måde at logge ind på. Selv et enkelt login med e-mail og adgangskode er fint — men et ægte, sikkert et, for alt andet hænger på at vide, hvem brugeren er.
• Kerneflowet, fra ende til anden. Det ene job, fra brugerens første klik til det øjeblik, de får det værdifulde resultat — ingen blindgyder, ingen ”kommer snart”-knapper på den kritiske vej.
• Et sted, hvor data faktisk bor. Rigtig lagring, ikke en smid-væk-prototype, så en brugers arbejde overlever en genindlæsning, og de kan komme tilbage i morgen.
• En måde, hvorpå du kan se, hvad der sker. Grundlæggende logning eller en simpel admin-visning, så når noget går i stykker — og det gør det — kan du finde ud af hvorfor uden at gætte.
• En måde for brugere at nå dig på. Selv bare et e-maillink. Tidlige brugere rammer kanter, du ikke forudså; du vil have, at de fortæller dig det, ikke forlader stille.
• Det absolutte minimum af tillid: en privatlivsnote, fornuftig datahåndtering og ikke at gøre noget hovedløst med folks oplysninger.

Læg mærke til, hvad der ikke er på listen: fakturering, fancy onboarding, indstillingssider, mobilapps, integrationer. Vi kommer til hvorfor om et øjeblik. Pointen med gulvet er, at det er lille nok til at blive færdigt og solidt nok til at lære af. Et login, der virker, ét flow, der leverer, rigtige data og en måde at observere og tale med brugere på. Det er et levedygtigt produkt.

Hvad du bevidst skal lade ude af v1

Dette er afsnittet, stiftere gør modstand mod, så lad mig være direkte: de fleste af de ting, der føles uundværlige for din første lancering, er det ikke. De føles uundværlige, fordi et ”rigtigt produkt” har dem — men du bygger ikke et rigtigt produkt endnu, du bygger et spørgsmål. At lade disse ude er ikke at skære hjørner. Det er hele disciplinen i en MVP.

Automatisk fakturering og kompleks prissætning

Du har næsten med sikkerhed ikke brug for en selvbetjent faktureringsmotor, niveaudelte planer, proratering og rykkerlogik i version ét. Hvis tidlige brugere vil betale, kan du tage deres penge manuelt — en faktura, et betalingslink, et hurtigt opkald. Manuel fakturering for dine første ti kunder fortæller dig noget, automatisk ikke kan: om nogen overhovedet vil betale. Byg maskinen, når du har bevist, at der er penge at opkræve.

Indviklede roller og tilladelser

Tilladelsessystemer med flere roller — administratorer, ledere, seere, finkornede adgangsregler — er en ægte teknisk sump, og de mangedobler testfladen enormt. Til en første udgivelse er én slags bruger næsten altid nok. Du lærer de reelle tilladelsesbehov ved at se faktiske teams bruge tingen, og de behov er sjældent, hvad du ville have gættet på papiret.

Integrationer, native mobilapps og dashboardet

”Den skal integrere med alt” er sætningen, der stille fordobler tidsplaner. Vælg højst én integration, og kun hvis den er en del af kernejobbet. Native iOS- og Android-apps kan næsten altid vente — en responsiv webapp virker på en telefon allerede i dag. Og analysedashboardet, alle vil have? Brugere kan ikke analysere data, de ikke har skabt endnu. Lancer først det, der skaber dataene; visualiser dem, når der er noget at vise.

En enkel metode til at trække grænsen

At kende princippet er én ting; at anvende det på din egen kravspecifikation, hvor hver funktion føles som dit barn, er sværere. Her er en metode, der virker, fordi den tvinger en beslutning frem på hvert punkt i stedet for at lade alt drive over i ”uundværligt”.

1. 1
   List enhver funktion, du har forestillet dig

   Hæld det hele ud — ingen filtrering endnu. Få hele ønskelisten på bordet, så intet lurer uudtalt og dukker op midt i byggeriet som en overraskelse.
2. 2
   Marker hver enkelt op mod kernejobbet

   For hver funktion, spørg: har en bruger brug for den for at fuldføre det ene kernejob fra ende til anden? Marker den ”kerne”, ”hjælpsom” eller ”engang”. Vær ærlig — de fleste lander i de to sidste.
3. 3
   Behold kun ”kerne” til v1

   Din MVP er ”kerne”-bunken og intet andet. ”Hjælpsom”- og ”engang”-bunkerne er ikke afvist — de er dit roadmap, parkeret hvor de hører hjemme.
4. 4
   Fornuftstjek nedskæringen

   Se på, hvad der er tilbage, og spørg: kan en rigtig bruger få reel værdi af kun dette? Hvis ja, har du afgrænset en MVP. Hvis noget reelt bryder kerneflowet, så træk kun det ene punkt tilbage — og intet andet.

Disciplinen ligger i trin fire. Der er altid en fristelse til at ”trække bare én ting mere tilbage”, og så endnu en, indtil du stille har genopbygget hele produktet. Tillad kun dig selv at redde punkter, der reelt bryder kerneflowet — ikke punkter, der blot ville gøre det rarere. Rarere er, hvad version to er til for.

Levedygtig betyder stadig, at den skal føles ægte

Der er en fejltilstand på den anden side af grænsen, og den er værd at navngive. I hastværket med at lancere småt lancerer nogle stiftere sjusket — og kalder det MVP. Et kerneflow, der mister dit arbejde, en tilmelding, der giver 404, tekst fyldt med pladsholdertekst. Det tester ikke din idé fair; det tester, om brugere vil tolerere en ødelagt oplevelse, og svaret er altid nej. Du vil konkludere, at idéen fejlede, når det i virkeligheden var udførelsen.

”Minimum” gælder omfang, aldrig kvaliteten af den del, du beholder. Færre funktioner, hver enkelt solid. Det ene flow, du lancerer, bør føles færdigt — hurtigt, klart og troværdigt — selv hvis det er det eneste, produktet gør. Et smalt produkt gjort godt slår et bredt produkt gjort dårligt hver gang, især når du beder fremmede om at betro dig deres arbejde.

MVP'en er ikke målstregen — den er den første aflæsning

Her er den del, der omformulerer alt: lanceringen er ikke målet. Målet er, hvad du lærer i ugerne efter den. En MVP, der lanceres og fortæller dig ”brugerne elsker kernen, men bliver ved med at bede om X”, er en brølende succes — selv hvis X betyder en måneds mere arbejde. En MVP, der lanceres ind i stilhed, hvor ingen kommer tilbage, har også gjort sit job: den reddede dig fra at bygge de andre tredive funktioner oven på et fundament, ingen ville have.

Så planlæg de første uger lige så bevidst som byggeriet. Observer, hvad folk faktisk gør, ikke hvad de siger i undersøgelser. Tal med dem, der kom tilbage, og dem, der ikke gjorde. Lad den reelle brug — ikke din oprindelige kravspecifikation — afgøre, hvad der ryger med i version to. Det roadmap, du parkerede tidligere, er ikke et løfte; det er en hypotese, og dine brugere er ved at give den karakter.

Almindelige spørgsmål