De fleste betragter MVP og MMP som den samme idé i forskellig skala. Det er de ikke. Hvis du sidder med budgettet til en første udgivelse, vælger du mellem to udviklingsstrategier, der bruger dine penge på vidt forskellige ting: MVP (Minimum Viable Product) og MMP (Minimum Marketable Product). En MVP køber dig beviser. En MMP køber dig en lancering.
Betragt MVP og MMP som to sider af samme sag, for det er præcis, hvad de er. Samme budget, samme team, samme tidsplan. Du skal blot beslutte, hvilken side mønten lander på. En MVP fungerer som en prototype, der lader dig teste din produktidé på markedet med lige akkurat nok funktioner til at validere den. En MMP tilbyder et komplet sæt funktioner og et overbevisende design, der appellerer til kunderne.
Produktdesign, udviklingstid og budget trækker alle i den beslutning, og de trækker i hver sin retning. Begge strategier er dyre at tage fejl af, om end på hver sin måde. Derfor fortjener valget en times overvejelse, før udviklingen koster et kvartals budget.
Lad os sammenligne dem.
Et minimum viable product er en udviklingsstrategi, der fokuserer på at levere et produkt med det absolutte minimum af funktioner, der er nødvendige for at tilfredsstille de første brugere. Ideen er at få feedback fra kunderne så hurtigt som muligt og bruge denne feedback til at forbedre produktet. Det er et populært valg for startups og virksomheder, der ønsker at validere deres produktidé, før de investerer betydelige ressourcer i udvikling.
Begrebet har en mere interessant historie, end de fleste artikler giver udtryk for, og historien er vigtig, fordi den forklarer, hvorfor teams diskuterer, hvad en MVP egentlig er. Frank Robinson opfandt begrebet i 2001, og hans definition var kommerciel snarere end eksperimentel: det produkt, der "maksimerer afkastet af risiko for både leverandøren og kunden". Steve Blank bragte ideen ind i kundeudvikling i The Four Steps to the Epiphany (2005). Eric Ries gjorde det derefter berømt og flyttede dets tyngdepunkt: i The Lean Startup (2011) er en MVP den version af et produkt, der skaber mest valideret læring med mindst mulig indsats.
De to definitioner trækker i hver sin retning, hvilket er præcis grunden til, at møder om MVP-omfang ofte kører i ring. Robinsons MVP er dimensioneret til at tjene penge. Ries' MVP er dimensioneret til at besvare et spørgsmål. Hvis dit team ikke kan blive enige om, hvad der skal med i den første version, skyldes det normalt, at halvdelen af lokalet bruger den ene definition, mens den anden halvdel bruger den anden. Afklar det først, så løser diskussionen om funktionerne sig ofte af sig selv.
Alt nedenfor tager udgangspunkt i Ries' version, da det er den, de fleste virksomheder mener, når de taler om en MVP. En MVP er ikke et lille produkt. Det er et instrument til at købe evidens, og hver eneste egenskab ved det eksisterer for at holde prisen på denne evidens nede.
Aurora Analytica viser, hvordan det ser ud, når visionen er stor. Deres Aurora Suite er en big-data-platform til kliniske forsøg, og det fulde produkt omfatter elleve Decision Engines, der dækker mere end fjorten vurderingsområder: markedsadgang, forsøgsdesign, valg af land og lokation samt klinisk drift. Vi byggede en af dem. Geo Matrix Decision Engine kom først: et værktøj, der lader CRO-brugere køre scenarier baseret på deres egne data, med et verdenskort, der visualiserer resultaterne af matrix-beregningerne, samt CSV-import og -eksport, så teams kunne bruge deres eksisterende datasæt i stedet for at indtaste dem manuelt.
At vælge én motor ud af elleve er en beslutning om omfang, ikke en budgetbesparelse. Spørgsmålet var aldrig "hvor meget af suiten har vi råd til", men derimod "hvilken motor er værd at bruge alene, før de andre ti eksisterer". Hvis man tager fejl her, ender man med at lancere noget, der kun giver mening som en del af et produkt, som ingen endnu kan se. Det er den virkelige udfordring ved at definere omfanget af en MVP, og det er grunden til, at valget bør ligge hos folk, der forstår domænet, frem for hos den, der sidder med estimatet.
Tre ting følger af dette formål, og de er mindre flatterende, end de fleste artikler om MVP indrømmer.
Funktionaliteten stopper ved det minimum, der skal til for at tilfredsstille de tidlige brugere, for alt derudover er penge spildt på at besvare et spørgsmål, ingen har stillet. Designet er enkelt. Ikke grimt – bare enkelt. Det er til for at få produktet ud til brugerne, ikke for at vinde en designpris, og teams, der glemmer det, spilder ugevis på at finpudse en skærm, de alligevel ender med at kassere. Og lanceringen er afdæmpet. Ingen kampagne, intet pressemøde. Du ønsker den ærlige reaktion fra hundrede mennesker, der selv har valgt at være der, ikke en overfladisk dom fra ti tusinde, der er blevet afbrudt.
Hvad du får til gengæld: hastighed og en regning, du kan leve med. Et begrænset omfang betyder en udviklingsfase, der måles i uger frem for kvartaler, til en brøkdel af prisen for et fuldt produkt, og feedback, der kommer tidligt nok til, at du kan ændre kurs for det næste, du bygger. Det sidste er selve pointen. De to andre er blot måden, du har råd til det på.
Lær alt om minimum viable product i vores ultimative guide.
Hver af disse er prisen for at få beviser. Det er værd at betale, når du har brug for beviserne. Det er svært at retfærdiggøre, når du ikke har.
Invisible Homes er en britisk platform til køb af boliger uden for det åbne marked, og de kontaktede os, efter at deres egen MVP allerede var lanceret. Produktet virkede i den forstand, at det eksisterede. Det var dog fyldt med fejl, og adoptionen var lavere, end virksomheden havde planlagt. Vi blev hentet ind for at overtage projektet og lægge en køreplan for vejen frem.
Det interessante er, hvor fejlene kom fra. Platformen var bygget i Ruby on Rails, og vi beholdt den kodebase frem for at starte forfra, men testdækningen var mangelfuld, og det var årsagen til, at fejl blev ved med at slippe igennem til produktion. Vi øgede dækningen til 80 % og udskiftede de forældede biblioteker, som den oprindelige version havde akkumuleret.
Intet af dette er glamourøst arbejde, og intet af det var med i nogens oprindelige budget. Det er netop pointen. "Yderligere udvikling og investering" er et punkt, man let læser hen over i en artikel om MVP'er; i dette projekt betød det at afvikle den test- og afhængighedsgæld, som et produkt, der allerede var live foran brugerne, havde oparbejdet. Da gælden var betalt, rykkede tallene sig: adoptionen kom sig, fællesskabet rundede 35.000 registrerede brugere, og over hundrede bureauer tilmeldte sig.
Læren er ikke, at MVP'en var en fejl. Den fik et rigtigt produkt ud til et rigtigt marked, og efterspørgslen viste sig at være der. Læren er, at den anden regning altid kommer, og de teams, der planlægger efter det, klarer sig bedre end de teams, der bliver overraskede over den.
Et minimum marketable product er en udviklingsstrategi, der fokuserer på at levere et produkt med tilstrækkelige funktioner og egenskaber til at gøre det attraktivt for målmarkedet. Målet er et produkt, der er salgbart, hvilket betyder, at lanceringen skal kunne stå på egne ben over for kunder, der ikke har tilmeldt sig som early adopters. MMP er et populært valg for etablerede virksomheder og større projekter.
Der er et punkt, der ofte skaber forvirring, som er værd at få afklaret. MMP forveksles ofte med minimum marketable feature (MMF), men de to opererer på forskellige niveauer. En MMF er en enkelt funktion, der er lille nok til at blive lanceret alene, samtidig med at den stadig har værdi for brugeren. Et MMP er hele produktet i sin mindste salgbare form. MMF'en er en mursten. MMP'en er huset, du rent faktisk kan flytte ind i.
En MVP-tilgang er velegnet til virksomheder, der ønsker at teste en ny produktidé og løbende forfine den baseret på feedback. De tre situationer herunder er i bund og grund det samme: Du ved endnu ikke nok, og den billigste måde at finde ud af det på er ved at lancere.
Læs mere om hvordan du bygger din MVP effektivt med agile metoder.
En MMP-tilgang er velegnet til virksomheder, der ønsker at levere et komplet produkt til kunderne og konkurrere på et marked med mange aktører. Disse tre deler også en forudsætning, og den er den stik modsatte: Du ved allerede nok, så risikoen er skiftet fra at tage fejl til at komme for sent.
Det er kendetegnet ved et MMP. Når dine brugere ikke har noget valg i forhold til at tage dit produkt til sig, holder "lad os sende noget småt ud og se, hvad de siger" op med at være research. De vil fortælle dig, at det er ufuldstændigt, det vil du allerede have vidst, og du vil have brugt den goodwill, du skulle have gemt til den rigtige lancering.
Denne tabel giver et klart overblik over de vigtigste forskelle på MVP og MMP, så du kan vælge den strategi, der passer bedst til dine behov.
| MVP | MMP | |
|---|---|---|
| Mål | Validér produktidéen hos tidlige brugere | Etablere et salgbart produkt på markedet |
| Funktionalitet | Det absolutte minimum, der kræves for at tilfredsstille tidlige brugere | Komplet |
| Design | Enkelt og ligetil | Sofistikeret og attraktivt |
| Marketingindsats | Minimal | Betydelig |
| Time-to-market | Hurtig | Længere |
| Udviklingsomkostninger | Lav | Højere |
| Primær målgruppe | Tidlige brugere | Hele målgruppen |
| Omsætning ved lancering | Lidt eller ingen | Forventet fra lanceringen |
| Hovedrisici | Ufuldstændig oplevelse, begrænset skalerbarhed, yderligere investering påkrævet | Forældelse, hvis markedet ændrer sig |
| Bedst egnet til | Startups og virksomheder, der validerer en idé | Etablerede virksomheder og storskala-projekter |
Tabellen forklarer, hvad hver strategi indebærer. Den fortæller dig ikke, hvilken du skal vælge. Tre spørgsmål gør det meste af arbejdet, og de er værd at besvare, før der skrives en eneste linje kode.
Ved du, om efterspørgslen er der? Hvis svaret bygger på antagelser frem for beviser, er det en MVP, du har brug for. Hele formålet med et minimum viable product er at købe sig til den viden billigst muligt. Hvis efterspørgslen allerede er bevist af en eksisterende kundebase eller af konkurrenter på samme marked, har du allerede købt den viden. At bruge penge på det igen er blot at betale to gange.
Hvad forventer markedet allerede? I en etableret kategori har kunderne allerede en forventning om et vist niveau. Leverer du under dette niveau, vil den feedback, du får, måle dine mangler frem for din idé, hvilket er en dyr måde at lære ingenting på. Det er her, en MMP kommer ind i billedet. I en ny eller underbetjent kategori er der endnu ikke sat nogen standard, og her kan en MVP være med til at definere den.
Hvad koster det at tage fejl? Dette er spørgsmålet, som de fleste sammenligninger springer over, og det er det, der afgør budgettet. En MVP er billig at tage fejl med, men dyr at få succes med, fordi succes betyder, at produktet skal bygges ordentligt forfra. En MMP er det modsatte: Den er dyr at tage fejl med, da pengene er bundet, før markedet har bekræftet noget som helst, men billig at få succes med, da produktet allerede er salgsklart. Så hvilken fiasko er værst? Ingen af dem i teorien. Det eneste spørgsmål, der betyder noget, er, hvad din virksomhed kan holde til.
Kravhåndtering indebærer den samme spænding. At beslutte, hvad der skal vente, er det virkelige arbejde i begge strategier. Det er det altid.
Find de 10 bedste softwareudviklingsvirksomheder at samarbejde med.
MVP og MMP er to populære udviklingsstrategier, som virksomheder bruger til at lancere deres produkter. MVP er velegnet til virksomheder, der hurtigt og billigt vil validere deres produktidé. MMP er velegnet til virksomheder, der ønsker at bringe et salgbart produkt på markedet.
Træf dit valg ud fra, hvad du ved, ikke ud fra, hvad du har råd til. Hvis efterspørgslen stadig kun er en hypotese, så køb dig til beviser, før du køber selve produktet. Hvis den er bevist, og markedet allerede har et grundniveau, så lancér noget, der ligger over det. Mønten har to sider, og du kommer sandsynligvis til at se begge, da de fleste produkter gennemgår begge faser: En MVP beviser idéen, og en MMP sælger den.
Et minimum viable product (MVP) er en version af et produkt, der er bygget med det absolutte minimum af funktioner, som er nødvendige for at tilfredsstille de første brugere. Formålet er at teste en produktidé på markedet og indsamle kundefeedback så hurtigt som muligt, før der investeres betydelige ressourcer i udvikling.
Som regel ikke, og forsøget på det er ofte årsagen til, at produkter får et dårligt ry, før de overhovedet er færdigudviklede. En MVP er prissat, afgrænset og markedsført til folk, der på forhånd har accepteret mangler. I det øjeblik du tager penge fra det brede marked, ophører manglerne med at være en forskningsmetode og bliver i stedet til en kilde til utilfredshed. Den ærlige tilgang er at sælge MVP'en til en lille, informeret gruppe – designpartnere eller pilotkunder – som ved, hvad de køber, og som betaler for at få indflydelse på version 2.
Hurtig lancering, lave udviklingsomkostninger og tidlig kundefeedback – og det er den tredje fordel, der betaler for de to første.
En MVP har den absolutte minimumsfunktionalitet og et basalt design, lanceres med minimal markedsføring og eksisterer for at validere en idé hos de første brugere. En MMP har fuld funktionalitet og et attraktivt design, lanceres med omfattende markedsføring og eksisterer for at blive solgt til hele målgruppen. En MVP er hurtigere og billigere. En MMP er klar til at generere omsætning.
Nej. En prototype viser, hvordan noget fungerer; en MVP bliver brugt af rigtige kunder, og feedbacken fra denne brug er selve resultatet.
En MMF (minimum marketable feature) er en enkelt funktion, der er lille nok til at blive udgivet for sig selv, samtidig med at den har værdi for brugeren. En MMP (minimum marketable product) er hele produktet i sin mindste salgbare form. MMF'en er en enhed i udgivelsen. MMP'en er selve udgivelsen.
Når MVP'en har besvaret det spørgsmål, den blev bygget til at besvare. Når feedback fra de første brugere bekræfter, at efterspørgslen er reel, bliver begrænsningerne i MVP'en en hindring: en ufuldstændig brugeroplevelse, begrænset skalerbarhed og ingen umiddelbar omsætning. Det er det punkt, hvor den ekstra udvikling og investering, som en MMP kræver, begynder at betale sig selv hjem. På Invisible Homesindtraf det øjeblik, da antallet af fejl og en fladende adoptionskurve viste, at produktet havde bevist sit værd på markedet, men var stødt mod loftet for, hvordan det var bygget.
Nej. De besvarer forskellige spørgsmål. En MVP spørger, om nogen overhovedet ønsker dette; en MMP antager, at nogen gør, og spørger, om du kan vinde dem. Hvis du tilføjer funktioner til en MVP uden at skifte fokus i spørgsmålet, ender du med et oppustet eksperiment, ikke et produkt.
Hvis du overvejer en MVP kontra en MMP til dit næste produkt, kontakt os, vi tager meget gerne en snak om det.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
Inês Silva er projektleder med mere end fire års erfaring med at skrive om softwarelevering, agile metoder og tech-ledelse. Da hun startede sin karriere som udvikler, bidrager Inês med en ægte, dybdegående teknisk forståelse til ledelsessiden. Hun elsker at bygge bro mellem den overordnede forretningsstrategi og den daglige tekniske udførelse, og hun brænder for at dele praktiske tips, der hjælper teams med at samarbejde bedre og levere fremragende produkter.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
