De flesta betraktar MVP och MMP som samma koncept i olika skala. Det är de inte. Om du ansvarar för budgeten för en första lansering väljer du mellan två utvecklingsstrategier som lägger pengarna på helt olika saker: MVP (Minimum Viable Product) och MMP (Minimum Marketable Product). En MVP ger dig bevis. En MMP ger dig en lansering.
Se MVP och MMP som två sidor av samma mynt, för det är precis vad de är. Samma budget, samma team, samma tidsplan. Du bestämmer bara vilken sida det landar på. En MVP fungerar som en prototyp som låter dig testa din produktidé på marknaden med precis tillräckligt många funktioner för att validera den. En MMP erbjuder en komplett uppsättning funktioner och en tilltalande design som lockar kunder.
Produktdesign, utvecklingstid och budget påverkar alla beslutet, och de drar åt olika håll. Båda strategierna är kostsamma att göra fel, om än i olika valutor. Det är därför valet förtjänar en timmes eftertanke innan utvecklingen tar ett kvartal.
Låt oss jämföra dem.
En minimum viable product är en utvecklingsstrategi som fokuserar på att leverera en produkt med absolut minsta antal funktioner som krävs för att tillfredsställa tidiga användare. Tanken är att få kundfeedback så snabbt som möjligt och använda den för att förbättra produkten. Det är ett populärt val för nystartade företag och verksamheter som vill validera sin produktidé innan de investerar betydande resurser i utveckling.
Begreppet har en mer intressant historia än vad de flesta artiklar medger, och historien är viktig eftersom den förklarar varför team bråkar om vad en MVP faktiskt är. Frank Robinson myntade termen 2001, och hans definition var kommersiell snarare än experimentell: den produkt som "maximerar avkastningen på risken för både leverantören och kunden". Steve Blank förde in idén i kundutveckling i The Four Steps to the Epiphany (2005). Eric Ries gjorde den sedan känd och försköt dess tyngdpunkt: i The Lean Startup (2011) är en MVP den version av en produkt som ger mest validerad kunskap med minsta möjliga ansträngning.
Dessa två definitioner drar åt olika håll, vilket är precis anledningen till att möten om MVP-omfattning ofta går i cirklar. Robinsons MVP är dimensionerad för att tjäna pengar. Ries MVP är dimensionerad för att besvara en fråga. Om ditt team inte kan enas om vad som ska ingå i den första versionen beror det oftast på att hälften i rummet använder den ena definitionen och hälften den andra. Red ut det först, så brukar diskussionen om funktioner lösa sig själv.
Allt nedan utgår från Ries version, eftersom det är den de flesta företag menar när de säger MVP. En MVP är inte en liten produkt. Det är ett instrument för att köpa bevis, och varje egenskap den har finns där för att hålla priset för dessa bevis nere.
Aurora Analytica visar hur det ser ut när visionen är stor. Deras Aurora Suite är en plattform för stordata inom kliniska prövningar, och den fullständiga produkten omfattar elva beslutsmoduler som täcker mer än fjorton bedömningsområden: marknadstillträde, studiedesign, val av land och plats samt klinisk verksamhet. Vi byggde en av dem. Geo Matrix-modulen var först ut: ett verktyg som låter användare hos CRO-företag köra scenarier mot sin egen data, med en världskarta som visualiserar resultaten av matrisberäkningarna samt import och export av CSV-filer så att teamen kunde använda sina befintliga dataset istället för att skriva in dem på nytt.
Att välja en modul av elva är ett beslut om omfattning, inte en budgetnedskärning. Frågan var aldrig "hur stor del av sviten har vi råd med", utan "vilken modul är värd att använda på egen hand innan de andra tio existerar". Gör du fel där lanserar du något som bara är begripligt som en del av en produkt ingen ännu kan se. Det är den verkliga svårigheten med att definiera en MVP, och det är därför valet bör ligga hos personer som förstår domänen snarare än hos den som håller i kostnadskalkylen.
Tre saker följer av detta syfte, och de är mindre smickrande än vad de flesta artiklar om MVP medger.
Funktionaliteten stannar vid det minimum som krävs för att tillfredsställa tidiga användare, eftersom allt utöver det är pengar som lagts på att besvara en fråga ingen ställt. Designen är enkel. Inte ful – enkel. Den finns till för att få produkten framför användarna, inte för att vinna ett designpris, och team som glömmer det förlorar veckor på att putsa på en skärm de ändå kommer att kasta bort. Och lanseringen är lågmäld. Ingen kampanj, ingen press. Du vill ha ärliga reaktioner från hundra personer som valt att vara där, inte ett distanserat omdöme från tiotusen som blivit avbrutna.
Vad du får i utbyte: snabbhet och en kostnad du kan leva med. Begränsad omfattning innebär en utvecklingstid som mäts i veckor snarare än kvartal, till en bråkdel av kostnaden för en fullskalig produkt, och feedback som kommer tillräckligt tidigt för att påverka vad du bygger härnäst. Det sistnämnda är själva poängen. De två andra är bara hur du har råd med det.
Upptäck allt om minimum viable product i vår ultimata guide.
Var och en av dessa är priset för bevisen. Värt att betala när du behöver bevisen. Svårt att motivera när du inte gör det.
Invisible Homes är en brittisk plattform för köp av fastigheter utanför den öppna marknaden, och de kontaktade oss efter att deras egen MVP redan hade lanserats. Produkten fungerade, i den bemärkelsen att den existerade. Den var dock buggig och användningen var lägre än vad företaget hade planerat för. Vi togs in för att ta över projektet och bygga en färdplan för att komma vidare.
Det intressanta är var buggarna kom ifrån. Plattformen var byggd i Ruby on Rails, och vi behöll den kodbasen istället för att börja om, men testtäckningen var tunn, och tunn täckning är anledningen till att defekter fortsatte att nå produktion. Vi höjde täckningen till 80 % och bytte ut de föråldrade bibliotek som den ursprungliga versionen hade samlat på sig.
Inget av detta är glamoröst arbete, och inget av det fanns med i någons ursprungliga budget. Det är det som är poängen. "Ytterligare utveckling och investering" är en enkel punkt att skumma förbi i en artikel om MVP; i det här projektet innebar det att betala av test- och beroendeskulder för en produkt som redan var live inför användare. När den väl var betald vände siffrorna: användningen återhämtade sig, communityn passerade 35 000 registrerade användare och över hundra mäklarfirmor anslöt sig.
Lärdomen är inte att MVP:n var ett misstag. Den fick ut en verklig produkt på en verklig marknad, och efterfrågan visade sig finnas där. Lärdomen är att den andra notan alltid kommer, och de team som planerar för den klarar sig bättre än de team som blir överraskade av den.
En minimum marketable product är en utvecklingsstrategi som fokuserar på att leverera en produkt med tillräckligt många funktioner för att den ska vara attraktiv för målmarknaden. Målet är en produkt som är säljbar, vilket innebär att lanseringen måste kunna stå på egna ben inför kunder som inte har valt att vara tidiga användare. MMP är ett populärt val för etablerade företag och storskaliga projekt.
En punkt som ofta skapar förvirring är skillnaden mellan MMP och minimum marketable feature (MMF), då de verkar på olika nivåer. En MMF är en enskild funktion som är tillräckligt liten för att kunna lanseras separat, men som ändå har ett värde för användaren. En MMP är hela produkten i sin minsta säljbara form. MMF är tegelstenen. MMP är huset du faktiskt kan flytta in i.
En MVP-strategi passar företag som vill testa en ny produktidé och förfina den över tid baserat på feedback. De tre situationerna nedan är i grunden samma sak i olika förpackningar: du vet inte tillräckligt än, och det billigaste sättet att ta reda på det är att lansera.
Läs mer om hur du bygger din MVP effektivt med agila metoder.
En MMP-strategi passar företag som vill leverera en komplett produkt till kunderna och konkurrera på en mättad marknad. Dessa tre delar också en förutsättning, och den är den motsatta: du vet redan tillräckligt, så risken har skiftat från att ha fel till att vara för sent ute.
Det är kännetecknet för en MMP. När dina användare inte har något val när det gäller att börja använda din produkt, upphör "låt oss lansera något litet och se vad de säger" att vara forskning. De kommer att berätta för dig att den är ofullständig, det kommer du redan att ha vetat, och du kommer att ha förbrukat det förtroendekapital du behövde för den riktiga lanseringen.
Den här tabellen ger en tydlig jämförelse av de viktigaste skillnaderna mellan MVP och MMP, så att du kan välja den strategi som passar dina behov bäst.
Tabellen förklarar vad varje strategi innebär, men den talar inte om vilken du bör välja. Tre frågor gör det mesta av det arbetet, och de är värda att besvara innan en enda rad kod skrivs.
Vet du att efterfrågan finns? Om svaret bygger på antaganden snarare än bevis, beskriver du en MVP. Hela poängen med en minimum viable product är att köpa sig till dessa bevis till lägsta möjliga pris. Om efterfrågan redan är bevisad, genom en befintlig kundbas eller konkurrenter som säljer på samma marknad, har du redan köpt den. Att spendera pengar igen är bara att betala dubbelt.
Vad förväntar sig marknaden redan? I en etablerad kategori har kunderna redan en grundläggande förväntan. Om du lanserar något som ligger under den nivån kommer feedbacken du får att mäta dina brister snarare än din idé, vilket är ett dyrt sätt att inte lära sig någonting. Det är fallet för en MMP. I en ny eller underbetjänad kategori har ingen satt ribban än, och en MVP får chansen att göra det.
Vad kostar det att ha fel? Det här är frågan som de flesta jämförelser hoppar över, och det är den som avgör budgeten. En MVP är billig att ha fel med men dyr att ha rätt med, eftersom framgång innebär att produkten måste byggas om ordentligt en andra gång. En MMP är motsatsen: dyr att ha fel med, eftersom pengarna är låsta innan marknaden har bekräftat något, och billig att ha rätt med, eftersom produkten redan är säljbar. Så vilket misslyckande är värst? Ingetdera, rent teoretiskt. Den enda frågan som spelar roll är vilket din verksamhet har råd att hantera.
Arbetet med kravställning innebär samma spänning. Att besluta vad som kan vänta är det verkliga arbetet i båda strategierna. Det är det alltid.
Upptäck de 10 bästa mjukvaruutvecklingsföretagen att samarbeta med.
MVP och MMP är två populära utvecklingsstrategier som företag använder för att lansera sina produkter. MVP passar företag som snabbt och till låg kostnad vill validera sin produktidé. MMP passar företag som vill lansera en säljbar produkt på marknaden.
Basera ditt val på vad du vet, inte på vad du har råd med. Om efterfrågan fortfarande bara är en hypotes, köp bevisen innan du köper produkten. Om den är bevisad och marknaden redan har en basnivå, leverera något som överträffar den. Myntet har två sidor och du kommer troligen att få se båda, eftersom de flesta produkter går igenom båda stadierna: en MVP bevisar idén, och en MMP säljer den.
En minimum viable product (MVP) är en version av en produkt som byggts med absolut minsta möjliga funktionalitet för att tillfredsställa tidiga användare. Syftet är att testa en produktidé på marknaden och samla in kundfeedback så snabbt som möjligt, innan stora resurser läggs på utveckling.
I regel inte, och att försöka är ett säkert sätt att få ett dåligt rykte innan produkten ens är färdig. En MVP prissätts, avgränsas och marknadsförs mot personer som valt att ha överseende med brister. I samma ögonblick som du tar betalt av den breda marknaden upphör bristerna att vara en forskningsmetod och blir istället en källa till klagomål. Det är mer ärligt att sälja en MVP till en liten, informerad grupp – designpartners eller pilotkunder – som vet vad de köper och betalar för att kunna påverka version 2.
Snabbare tid till marknaden, lägre utvecklingskostnader och tidig kundfeedback – och det är den tredje punkten som finansierar de två första.
En MVP har minimal funktionalitet och en enkel design, lanseras med begränsad marknadsföring och finns till för att validera en idé hos tidiga användare. En MMP har fullständig funktionalitet och en attraktiv design, lanseras med omfattande marknadsföring och finns till för att säljas till hela målmarknaden. En MVP är snabbare och billigare. En MMP är redo för intäkter.
Nej. En prototyp visar hur något skulle kunna fungera; en MVP används av riktiga kunder, och feedbacken från den användningen är själva resultatet.
En MMF, eller minimum marketable feature, är en enskild funktion som är tillräckligt liten för att kunna lanseras separat, men som ändå har ett värde för användaren. En MMP, eller minimum marketable product, är hela produkten i sin minsta säljbara form. MMF är en enhet i en release. MMP är själva releasen.
När MVP:n har besvarat frågan den byggdes för att besvara. När feedback från tidiga användare bekräftar att efterfrågan är verklig, blir MVP:ns begränsningar ett hinder: en ofullständig användarupplevelse, begränsad skalbarhet och inga omedelbara intäkter. Det är i det läget som den extra utveckling och investering som en MMP kräver börjar betala sig. På Invisible Homeskom det ögonblicket när antalet buggar och en avplanande adoptionskurva visade att produkten hade bevisat sin marknad men nått taket för hur den var byggd.
Nej. De är svar på olika frågor. En MVP frågar om någon vill ha detta; en MMP utgår från att någon vill ha det och frågar om du kan vinna över dem. Att lägga till funktioner i en MVP utan att skifta fokus i frågeställningen resulterar bara i ett svullet experiment, inte en produkt.
Om du väger en MVP mot en MMP för din nästa produkt, kontakta oss, vi diskuterar gärna saken.
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
Inês Silva är projektledare med över fyra års erfarenhet av att skriva om mjukvaruleverans, agila metoder och tekniskt ledarskap. Eftersom hon började sin karriär som utvecklare, bidrar Inês med en verklig, djupt teknisk förståelse till ledningssidan. Hon älskar att överbrygga klyftan mellan övergripande affärsstrategi och det dagliga ingenjörsarbetet, och hon brinner för att dela med sig av praktiska tips som hjälper team att samarbeta bättre och leverera fantastiska produkter.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
