I alle projekter arbejder vi agilt og lean med en udviklingsproces, hvor vi udgiver tidligt og ofte og maksimerer brugerfeedback, mens vi fokuserer på at etablere markedspasform. Konceptet er at komme ind i en Learn⇢Build⇢Measure-rotation bestående af mange små MVP’er, indtil vi når MMP-niveauet.

Vi bruger mange begreber til at definere vores proces: MVP, MMF, MMP, MMR, MVBP, SRP, MAP. De fleste mennesker bruger udtrykket MVP, men deres definition af udtrykket varierer meget, hvilket gør fejlkommunikation om målet alt for almindelig.

For at undgå at udvikle på den forkerte måde, er vi meget præcise i vores brug af begreber. Dette er de definitioner, vi bruger:

• PoC: Proof of Concept – alt, hvad der giver dig mulighed for at validere brugernes interesse.

• Pro: Prototype – en klikbar mockup, der tillader brugerinteraktion i en PoC.

• MVP: Minimum Viable Product – et testprodukt, der demonstrerer en eller flere funktioner.

• MMF: Minimal Marketable Feature – en af dine kernefunktioner.

• MMP: Minimal Marketable Product – din første markedsudgivelse.

• MMR: Minimal Marketable Release – den næste opgradering af dit produkt.

• MVBP: Minimum Viable Business Product – dit produkt med en levedygtig indtægtsmodel.

• SRP: Sales Ready Product, et produkt, der gør det muligt for kunden at finde værdi i produktet før betaling, og derfor “sælger sig selv”.

• MAP: Minimum Awesome Product. Det perfekte produkt, som folk vil elske! Medmindre du er uden konkurrence, er du nødt til at opnå dette niveau for at kunne konkurrere i 2020’erne.

Grundlæggerne vil se noget, der virker NU!

Vi bruger vores MVP → MMP → MVBP → MAP-model. Det er en almindelig måde, da den viser fremskridt for alle, mens vi bygger, og sikrer, at vi får vigtige input undervejs.

Overvej billedet nedenfor – en gammeldags vandfaldsproces, der bygger systemet, hvor modtageren er bekymret og ikke tilfreds undervejs, men i sidste ende får det produkt, de ønskede. Men de får kun det produkt, de sagde, de ville have, da der ikke var mulighed for at lære undervejs.

Men hvis man i stedet udvikler agilt ved hjælp af MVP ⇢ MAP-modellen, hvor man forfiner, mens man bygger, ender man ofte med et produkt, der er mere, end kunden bad om, på grund af udviklingen i små trin. I illustrationen nedenfor bad kunden om en bil – men ved hjælp af den agile proces endte vi med en flot cabriolet, som kunden ikke engang vidste, at han virkelig ønskede sig.

Validering af dine MVP’er

Før du bygger dit MMP, skal du validere dine MVP’er for at se, om de passer til specifikke nøgleområder. Det kan gøres via mail, telefon eller ved at tilføje en landingsside med en tilmeldingsknap til mailinglisten, som du kan dele på sociale medier. Brug alle mulige kanaler til at hjælpe dig med at indsamle input.

Mens du validerer, skal du huske dette:

• Forskning!
  Er idéen original? Er der konkurrenter på markedet? Har du en niche?

• Løsning!
  Hvordan hjælper det folk? Hvad er kundens fordel?

• Hvorfor? Hvad er pointen?
  Hvad er pointen? Hvorfor gør du det her? Hvorfor skal kunderne stole på dig på lang sigt?

• Planlæg!
  Er din forretningsplan solid? Har du overvejet alle udfald som f.eks. ikke at sælge, nye konkurrenter, trendændringer etc.?

• Ressourcer?
  Har du alle de ressourcer, du har brug for? Især nok penge til at køre i et par år? At opbygge en SaaS tager længere tid at generere indkomst, end du tror!

Hvis du, mens du validerer din idé, formår at få en kunde til at betale dig for at levere en løsning om X måneder, har du valideret din idé med succes.

Roadmap og kortlægning af brugerhistorier

For at bygge den eller de rigtige MVP’er er det afgørende, at du først storymapper din brugers flow.

Vi er nødt til at vide, hvad brugerens problem er, hvad brugeren får ud af en funktion, og hvordan kundens flow skal være for at løse kundens problem. Det er vi nødt til:

• Identificere dine brugere, i segmenter og roller.

• Specificere slutmålet for brugeren.

• Identificere de handlinger, der kræves af brugeren for at nå målet.

Nu skal vi storymappe brugerne for at finde ud af, hvilke funktioner der er MMF’er, og hvilke funktioner der er til backloggen og roadmappen “fremtidige versioner”.

For at lave story mapping skal du:

• Sætte dig i brugerens sted – og notere brugerens handlinger.

• Noter smertepunkterne, og hvorfor disse steder i flowet var ubelejlige.

• Sammenlign de gevinster, du fik, og smerterne undervejs i pain-gain maps.

Du kan nu prioritere dine story maps i en køreplan.

• Brug pain-gain maps til at prioritere muligheder.

• Beslut, hvilke 5 vigtigste muligheder der skal valideres i en MVP.

MVP – Minimum Levedygtigt Produkt

Vores MVP er en version af produktet med en enkelt funktion eller et minimumssæt af funktioner, der er nødvendige for at få tidlige brugere til at begynde at bruge det, give dig feedback og give dig mulighed for at sikre, at din model har markedets interesse.

Vores MVP har til formål at sikre, at der er markedsinteresse for produktet. Det er ikke det samme som, at potentielle kunder er villige til at betale, og derfor er betalingsmodellen måske ikke defineret endnu.

Fokus i MVP’en er derfor at få brugerne til at begynde at bruge produktet, så vi kan få input, vi kan reagere på og bygge videre på. Din MVP bør:

• Effektivt løse et nøgleproblem.

• Betjene mindst én specifik kundegruppe/segment.

• Have en veldesignet UX.

En MVP kan bygges på mange måder, men det vigtigste er at udforske og få brugerinput om, hvorvidt funktionen er salgbar eller ej, og om funktionen skal blive en MMF. MVP’en kan bygges ind i enhver form for løsning, så længe den giver os mulighed for at teste, om brugeren ønsker funktionen. Eksempler:

• En landingsside, der beskriver en funktion og giver folk mulighed for at tilmelde sig et nyhedsbrev.

• En klikbar mockup (interaktioner til at bevæge sig mellem sider).

• Et klikbart design (interaktioner til at bevæge sig mellem sider).

• Skitser på papir.

• Et system bygget med en no-code builder (f.eks. Makerpad).

• En WordPress-side med plugins, der bygger funktionen.

• En specialbygget side/app.

• Et menneske, der leverer tjenesten, som SaaS senere kan automatisere.

• Mennesker, der i al hemmelighed efterligner tjenesten.

• Direkte personlige e-mails eller telefonopkald, hvor man tester en salgstale af funktionen.

Få altid brugerens telefonnummer til alle dine MVP’er, så du senere kan interviewe brugeren og få mere input til funktionerne.

Husk også, at hvis en MVP ikke valideres, betyder det ikke, at funktionen er forkert. Det fortæller dig kun, at den måde, du byggede funktionen på, ikke var levedygtig for det specifikke segment, du forsøgte at validere den på. Måske var segmentet forkert?

MMF – Minimal markedsførbar funktion

Ved hjælp af vores MVP eller en række forskellige MVP’er finder vi nu vores MMF, som vi skal bruge til at bygge vores MMR’er og MMP.

• En MMF er en minimal version af en funktion, som er testet og markedsgodkendt ved hjælp af en MVP.

• Som en tommelfingerregel skal du prøve at bygge din MMP med 5 MMF’er.

• Et MMP er et minimalt markedsklart produkt, der består af et minimum af MMF’er. MMP’en er den første udgivelse til markedet.

MMP – minimalt salgbart produkt

MMP er din første markedsudgivelse. Det er det, du sikkert har hørt mange omtale som MVP.

Når du har nok MMF’er til at frigive dit produkt, frigiver du MMP’et.

• For hver iteration af undersekvensen af MMP’et hedder det en MMR (f.eks. release, 1.1, 1.2 osv.).

MVBP – Minimum levedygtigt forretningsprodukt

Når vi går videre fra MVP, bruger vi det indsamlede input til at beslutte indtægtsmodellen, salgsmodellen og betalingsmodellen.

Vi kan A/B-splitteste forskellige betalingsmodeller, der kører på samme tid for forskellige segmenter eller i round robin (tilfældigt), eller vi kan starte med en enkelt model i henhold til det input, vi får fra potentielle kunder.

Vægten i MVBP ligger på at være helt sikker på, at det endelige produkt er noget, som kunderne vil betale for.

Derfor betyder MVBP, at man undgår tidskrævende Pivots (tilbagevendende betalingsmodel).

SRP – Salgsklart produkt

Nu hvor vores produkt har en betalingsmodel, kan vi levere det med en stærk salgsafdeling eller fokusere på et Sales Ready Product. SRP er defineret som et produkt, der sælger sig selv ved at give kunden mulighed for at finde værdi i produktet, før betaling.

Det vigtigste ved SRP er at holde fokus på at levere reel værdi til din kunde, det skal være indlysende, at produktet er værdifuldt for kunden. Hvis du holder fokus på dit produkt og forbliver salgsklar, vil du begrænse dine funktionskampe og priskrige med konkurrenterne.

Et godt produkt kan blive et SRP ved at vise dets funktioner på en webside, selvom brugen af en freemium-model eller et affiliate-system ofte gør det lettere.

MAP – Minimum Awesome Product

I den nuværende verden er designet altafgørende – både UI og UX skal være fantastiske, de tusindårige kunder forventer, at enhver SaaS-tjeneste skal se fantastisk ud. Minimum viable betyder minimumsfunktioner – ikke et grimt og svært anvendeligt UI/IX.

Bemærk, at i nogle tilfælde kan din MVP give så meget kundeværdi, at kunden kan betragte den som en MAP. I 2000’erne var dette almindeligt for SaaS-tjenester, men i dag, hvor vi har en SaaS til det meste, skal du som regel op på MAP-niveau for at skille dig ud.

• Har dit produkt ingen konkurrence? Så opfatter kunderne måske din MVP = MAP!

• Hvis der er stor konkurrence inden for dit produktdomæne, er du nødt til at blive MAP.

• Selvom det kan tage dig et år at komme fra en kodningsstart til et salgsklart produkt – så forvent endnu et år med ubarmhjertig nitpicking for at komme til det fantastiske niveau. Først da er du klar til at tilføje flere kernefunktioner. Nu begynder den virkelige kamp, og det er her, enhjørninger bliver født.

Byggeprocessen

Langsigtet drift

Så du har bygget dit produkt, det sælger, og du har fået fodfæste – hvad nu?

• Du vil blive truet oppefra, af større konkurrenter med flere penge og flere ressourcer.

• Og du vil blive truet nedefra af hurtige, slanke og smidige nytilkomne.

Nøglen er nu at blive ved med at gøre det samme, som fik dig hertil. Forbliv hurtig og tro mod dine værdier. Konkurrenterne kan kopiere dine funktioner, men de kan ikke kopiere den viden, der fik dig hertil og fik dig til at bygge funktionerne, som du har implementeret dem i dit system.

Med en MAP er du nu klar til at levere den bedst mulige CX – kundeoplevelsen af alle de måder, kunden interagerer med din virksomhed på. Mål din CX, hold den høj, og du vil beholde dine kunder.

Fremtiden for SaaS

En undersøgelse fra 2017 af BetterCloud, hvor 1827 amerikanske virksomhedsledere blev interviewet, viser denne historiske og anslåede udvikling i flere virksomheder, der bruger SaaS til 80% eller mere af deres forretningssoftware. Fremskrivningen viser, at alle amerikanske virksomheder vil bruge SaaS til næsten alt i 2025!

OFTE STILLEDE SPØRGSMÅL

• Hvad er et MLP? Minimum Loveable Product – betyder det samme som MAP.

• Hvad er MAP også et akronym for? Nogle bruger MAP som et Minimum Acceptable Product, hvilket betyder et MMP med nogle flere funktioner. Det korrekte agile udtryk er MMR.

• Er M en forkortelse for “Minimum” eller “Minimal”? Det afhænger af udtrykket. Minimal betyder “knap nok tilstrækkelig”, mens Minimum betyder “laveste mængde”. Funktionerne skal bygges minimalt – mens produktet skal indeholde et minimum af minimale funktioner.

• Hvad er forskellen mellem UI, UX og CX?
  UI er designet, den måde tingene ser ud på – brugergrænsefladen.
  UX er brugervenlighed, hvor nemme tingene er at bruge – brugeroplevelsen.
  CX er kundens følelser over for produktet – kundeoplevelsen.
  En god brugergrænseflade får dit produkt til at se godt ud. En god UX gør dit produkt nemt at bruge. Hvis UI og UX er gode, er du tæt på en god CX. Men CX involverer også de følelser, som kunderne har i forbindelse med din support, fakturering osv.