Sådan scoper du en SaaS-MVP: hvad skal med, og hvad kan vente

Du scoper en MVP ved at tage udgangspunkt i det ene problem som dine første kunder vil betale for at få løst, og derefter skære alt fra som ikke er nødvendigt for at løse det fra start til slut. Jeg sorterer hver eneste funktion i tre bunker: skal med, bør med og senere. Kun den første bunke er din MVP.

Jeg er freelanceudvikler og bygger SaaS-produkter for andre, så jeg har en interesse i at du ender med at bygge noget. En stram første version er alligevel også i din interesse: den er billigere, den kommer hurtigere ud, og du lærer mere af den.

Den korte version: tre bunker og ét spørgsmål

Beslutningsreglen er enkel: kan en betalende kunde løse den opgave produktet findes for uden funktionen, hører den ikke til i skal med. Det lyder banalt, men det er her de fleste ønskelister falder fra hinanden.

Metoden er en forenklet udgave af MoSCoW-prioritering, hvor jeg har slået "could" og "won't" sammen til én bunke. Forskellen betyder sjældent noget i en første version. Er du tidligere i forløbet, så start med min guide til at bygge en SaaS fra idé til betalende kunder. Og er du i tvivl om begrebet, har jeg skrevet om hvad en MVP er, og hvad den ikke er.

Sådan scoper du en MVP i syv trin

Rækkefølgen betyder noget. Mange starter med at skrive funktioner op, men så har de ikke noget at sortere dem efter. Begynd med problemet, og lad listen komme bagefter.

1. Skriv kerneopgaven i én sætning

Formulér hvem produktet er til, hvilket problem det løser, og hvad kunden har opnået når det virker. Fx: "Ejere af små rengøringsfirmaer kan planlægge ugens opgaver og se hvad der er udført, uden at ringe rundt til medarbejderne."

Kræver sætningen et "og" mere, har du sandsynligvis to produkter. Vælg det ene. Sætningen bliver din målestok resten af vejen, og hver funktion skal kunne forsvares ud fra den.

2. Beskriv det vigtigste forløb fra start til slut

Skriv det forløb en ny kunde går igennem: tilmelding, første opsætning, den handling der løser problemet, og det øjeblik kunden ser resultatet. Det er typisk 5-10 skridt.

Alt hvad der skal til for at komme igennem forløbet, er en kandidat til skal med. Det der ligger uden for, er det som udgangspunkt ikke. Her opdager du også de kedelige dele som ingen nævner i en præsentation: nulstilling af adgangskode, invitation af en kollega, en kvittering på mail.

3. Skriv alle ønsker ned uden filter

Tøm hovedet. Skriv alt ned som du, dine medstiftere og dine første interesserede kunder har nævnt, også det du godt ved er urealistisk. Det er lettere at sortere en lang liste end at diskutere en vag fornemmelse af hvad produktet skal kunne.

Formulér hver funktion som noget en bruger gør, ikke som en teknisk komponent. "Medarbejderen markerer en opgave som udført" er lettere at vurdere end "mobilmodul".

4. Sortér listen i tre bunker

Tag én funktion ad gangen, og stil tre spørgsmål:

1. Kan kunden løse kerneopgaven uden den? Hvis nej, skal den med.
2. Vil kunden savne den inden for den første måned? Hvis ja, bør den med.
3. Er der en kunde der har bedt om den, eller forestiller du dig at nogen vil? Er det det sidste, hører den til senere.

Vær hård ved den første bunke. Min tommelfingerregel er at hvis mere end halvdelen af listen ender i skal med, har du ikke sorteret listen, kun omdøbt den.

5. Find de manuelle genveje

Mange funktioner kan erstattes af manuelt arbejde så længe du har få kunder. Du kan oprette nye kunder selv i stedet for at bygge selvbetjent tilmelding. Du kan tage betaling med et betalingslink fra Stripe, som også kan bruges til abonnementer, i stedet for en fuld abonnementsløsning. Og du kan sende en månedlig rapport fra et regneark i stedet for at bygge et dashboard.

Det skalerer ikke, og det er netop pointen. Du automatiserer først når det manuelle arbejde gør ondt, og så ved du præcis hvad der skal bygges.

6. Sæt tid og budget, og skær igen

Bestem hvor lang tid og hvor mange penge første version må koste før du ser et estimat. Lad rammen ligge fast, og lad indholdet være det der tilpasses.

Fylder skal med-bunken mere end ca. 60 % af budgettet, så skær igen. Grænsen kommer fra MoSCoW-metoden, og den giver en fornuftig buffer: resten går til det uforudsete og til de vigtigste ting fra bør med. Vil du kende niveauet, har jeg skrevet om hvad det koster at få udviklet en MVP.

7. Skriv senere-listen ned, og del den

Alt i senere-bunken skal skrives ned og deles med alle i projektet, også dine første kunder hvis det er relevant. En synlig liste gør det lettere at sige nej fordi nej betyder "ikke nu" og ikke "aldrig".

Gennemgå listen når du har haft rigtige brugere i nogle uger. Ofte viser det sig at en del af punkterne ikke savnes af nogen mens brugerne beder om noget helt tredje.

Et eksempel: sådan bliver en ønskeliste skåret ned

Eksemplet er konstrueret for at vise metoden, men punkterne er af den slags der ofte står på en ønskeliste til et B2B-værktøj. Forestil dig en iværksætter der vil bygge et planlægningsværktøj til små rengøringsfirmaer. Den første ønskeliste har 13 punkter. Efter sorteringen ser den sådan ud:

Fem punkter er tilbage i skal med, og alle fem handler om kerneopgaven fra trin 1: planlæg opgaverne, og se hvad der er udført. De tre punkter i bør med er gode idéer, men de kan løses manuelt eller med standardværktøjer de første måneder. Et betalingslink kan sættes op uden kode mens en fuld abonnementsløsning med prøveperioder, opgraderinger og fejlede betalinger er et projekt i sig selv.

Det svære punkt er appen. Den føles som et krav fordi medarbejderne arbejder ude hos kunderne. Men det de skal, er at åbne en liste og trykke "udført". Det kan en mobilvenlig webapp klare, og så skal der udvikles og vedligeholdes én udgave af produktet i stedet for tre.

Læg også mærke til rollerne. Ejer og medarbejder er nok til at komme i gang. Teamledere, afdelinger og rettigheder pr. kunde kan komme senere når du ved hvordan kunderne faktisk organiserer sig.

Det du ikke kan skære fra

En stram MVP er ikke det samme som en sjusket MVP. Nogle ting ligner funktioner på en liste, men er i virkeligheden forudsætninger for at du overhovedet kan have kunder i systemet:

• Adskillelse af kundernes data. I en SaaS deler mange kunder det samme system, og én kunde må aldrig kunne se en andens data. Det skal være på plads fra første kunde, og jeg har skrevet mere om hvordan du adskiller kunderne i en multi-tenant-arkitektur.
• Sikkert login og adgangskontrol. Adgangskoder gemmes korrekt, sessioner udløber, og rettigheder tjekkes på serveren, ikke kun i brugerfladen.
• Backup som du har prøvet at gendanne. Ellers ved du ikke om den virker.
• Fejllogning, så du opdager at noget går galt før kunden ringer.
• Det grundlæggende i GDPR: en privatlivspolitik, databehandleraftaler med kunder og underleverandører og en måde at slette en kundes data på.
• En måde at hjælpe kunderne på. Du skal kunne slå data op og rette fejl uden at gå direkte i databasen hver gang. Det behøver ikke være et pænt administrationspanel.

Datamodellen hører også til her. Kunden ser den ikke, men den er dyr at lave om når der først ligger rigtige data i den. Brug hellere en dag ekstra på at tænke kunder, brugere og roller igennem end at skulle flytte alle data om et halvt år.

Sådan holder du afgrænsningen under udviklingen

Afgrænsningen skrider sjældent i ét stort spring. Den skrider i små skridt som hver for sig lyder fornuftige:

• "Mens du alligevel er i gang, kan den så ikke også ..."
• En enkelt interesseret kunde vil have en bestemt funktion før kunden skriver under.
• En konkurrent lancerer noget, og pludselig føles det som et krav.
• Særtilfælde: hvad nu hvis en opgave går over midnat, eller en medarbejder har to roller?

Min regel er at bytte i stedet for at lægge til. Kommer der en ny funktion ind i skal med-bunken, skal noget af samme størrelse ud. Det flytter samtalen hen på det rigtige spørgsmål: er det her vigtigere end det du allerede har besluttet?

Særtilfælde håndterer du bedst manuelt i starten. Lad systemet afvise det usædvanlige med en tydelig besked, og løs det selv når det sker. Vil du se konkrete eksempler på hvad der roligt kan vente, har jeg samlet 12 funktioner din SaaS ikke har brug for ved lancering.

Hvornår du ikke skal bygge en MVP endnu

En god afgrænsning hjælper ikke hvis ingen vil betale for produktet. Har du endnu ikke talt med potentielle kunder om problemet, så start der. Min guide til at validere en SaaS-idé viser hvordan du tester efterspørgslen før der skrives kode.

Der er også situationer hvor du ikke har brug for en udvikler som mig endnu:

• Når problemet kan testes med et regneark, en formular og et betalingslink. Får du ti kunder til at betale for en manuel udgave, har du lært mere end en MVP kan lære dig.
• Når skal med-bunken stadig ikke passer i budgettet efter to runder sortering. Så ligger problemet i afgrænsningen af produktet, ikke i udviklingen, og det skal løses først.
• Når ingen hos dig har tid til at træffe beslutninger løbende. En MVP kræver mange små valg hver uge, og uden en fast person til at træffe dem går projektet i stå.

Næste skridt

Har du været igennem de syv trin, har du et godt grundlag for et tilbud: en kerneopgave, et forløb og en sorteret liste. Brug tjeklisten før du sender noget til en udvikler.

På siden om udvikling af SaaS-produkter kan du se hvordan jeg arbejder med SaaS-projekter, herunder det betalte forprojekt til fast pris som går forud for større udviklingsopgaver.

Ofte stillede spørgsmål

Hvor lang tid tager det at bygge en SaaS-MVP?+

Det afhænger af hvad der ligger i skal med, men en fokuseret MVP med én udvikler tager ofte et par måneder. Peger estimatet mod et halvt år eller mere, er det et tegn på at listen skal sorteres igen. Tidsrammen er i sig selv et godt styringsværktøj: bestem den først, og lad indholdet tilpasse sig.

Skal betaling være med i første version?+

Ja, i en eller anden form. Kunderne bør betale fra start, ellers lærer du ikke om produktet er noget værd for dem. Betalingen behøver bare ikke være automatiseret. En faktura eller et betalingslink kan klare de første kunder, mens selvbetjent abonnement med prøveperioder og opgraderinger kan vente til du kender din prismodel bedre.

Kan jeg ændre afgrænsningen undervejs?+

Ja, og det skal du forvente. Du lærer noget nyt hver uge, især når de første brugere kommer til. Det afgørende er at en ændring bytter plads med noget andet i stedet for at blive lagt oven i. Arbejder du med en fast pris, skal ændringer aftales og prissættes, så tag dem op tidligt og samlet frem for én ad gangen.

Skal en MVP kunne skalere til mange brugere fra start?+

Nej, men den skal bygges så den kan videreudvikles. Det betyder et udbredt og veldokumenteret framework, en gennemtænkt datamodel og adskilte kundedata fra dag ét. Optimering til tusindvis af samtidige brugere kan vente til du har dem. En MVP får sjældent problemer med belastningen i starten, men den kan sagtens få problemer med en datamodel der blev lavet for hurtigt.