Vad är en MVP (Minimum Viable Product)?

Innan vi dyker ner i vad en Minimum Viable Product är, låt mig fråga dig detta: Vad har de välkända apparna Instagram, Uber och Groupon gemensamt?

Deras tidigaste versioner var mycket enklare än de appar vi ser idag. De har mognat. De har dragit nytta av åratal av utveckling och stora mängder resurser som har lagts på dem. De kom inte bara till som de välutvecklade appar de är idag.

Det är en bra metafor för begreppet MVP (Minimum Viable Product). MVP-konceptet är stort inom startupvärlden och betyder: en version av produkten som endast innehåller de funktioner som gör att du kan släppa den på marknaden, som löser ett kärnproblem för en uppsättning användare. Målet är att leverera omedelbart värde och samtidigt minimera utvecklingskostnaderna.

I sin bästsäljande bok The Lean Startup sa Eric Ries:

"Den minsta livskraftiga produkten är den version av den nya produkten som gör det möjligt för ett team att samla in den maximala mängden validerad kunskap om kunden med minsta möjliga ansträngning"

Den vanligaste illustrationen av hur man bygger en MVP på rätt sätt är fordonsexemplet.

Men jag gillar exemplet som Ravi Vadrevu tar upp i den här artikeln. Han destillerar MVP-processen ner till tre steg:

1. Börja med en enda, enkel produkt som löser en liten del av ett stort problem;
2. Fortsätt att iterera, samtidigt som du hela tiden löser större, relaterade problem på vägen mot att lösa det stora problemet;
3. Kommunicera ständigt visionen om det stora problem som ska lösas.

Och sedan utvidgar han dessa steg till ett särskilt stort problem: Mänskligheten behöver billig och effektiv belysning under mörker.

1:a MVP: Eld. Människor såg blixtar sätta träd i brand och skapade själva eld med pinnar. Men eld är inte särskilt portabel, förrän...

2:a MVP: Oljelampor, stearinljus och gasljus. Nu kan människan bära med sig ljus. Men stearinljus och gaslampor lyser inte starkt och vinden blåser ut dem, tills...

3:e MVP: Glödlampor. De tidiga glödlamporna drevs av batterier och var mer pålitliga än ett stearinljus. Men befolkningarna växte och det fanns inget elnät, förrän...

4:e MVP: Allmänt tillgänglig elektricitet. Kraftverk och elnät ger en bred tillgång till belysning. Men världens efterfrågan på el växer för snabbt, tills...

5:e MVP: Solenergi. Glödlampor med låg watt spelar in och solenergi blir billigare att producera. Det är ungefär där vi är nu tills solenergi blir mer allmänt antagen.

Du förstår vad jag menar. MVP-konceptet är därför särskilt användbart för nystartade företag som arbetar i en mycket slimmad miljö. De kan rulla ut en MVP med en budget, testa den, få feedback och lägga till funktioner som kunderna efterfrågar.

Men en Minimum Viable Product-strategi kan också fungera för redan mogna produkter i samband med implementeringen av dessa produkter. Är det en hållbar strategi för lösningar för informationshantering? Vi tror att det är så. Här är skälet till varför.

Hur kan MVP-metoden tillämpas för att implementera tekniska lösningar (t.ex. informationshantering)?

När jag först hörde begreppet Minimum Viable Product var konnotationen lite märklig. Jag tänkte: "Minsta produkt? Varför skulle någon vilja ha minimiprodukten när de bara kan få hela grejen?" Det verkade som om slutkunden blev kort på något sätt. Men när jag dök djupare in i konceptet insåg jag att det är precis tvärtom. Kunden blir inte snuvad på något. De får exakt vad de behöver med utrymme för att växa till hela produktsviten - allt utan att behöva betala för den upphottade Lamborghinin redan från början.

Låt oss fundera på hur en MVP-strategi skulle kunna fungera för implementering av mångfacetterade tekniklösningar som en plattform för informationshantering eller dokumenthantering. Med det menar vi följande: en planerad, stegvis strategi där plattformen kan rullas ut till en viss grupp (t.ex. HR eller ekonomi) för att tillgodose deras behov och sedan utökas till andra avdelningar eller hela företaget senare. Ett annat sätt att fasa in det skulle vara att implementera plattformen i en mindre kapacitet som uppfyller kundernas behov och sedan lägga till andra funktioner efter behov.

Det finns ett rätt och ett fel sätt att göra detta på. I stället för att bara ge kunden grundläggande funktionalitet, på bekostnad av användbarhet, tillförlitlighet och design, är det i allmänhet bättre att ge kunden en del av allt detta och utöka efter behov.

Det finns faktiskt enorma fördelar för kunden med en stegvis utveckling. Läs vidare för några viktiga fördelar med en MVP-strategi för teknikimplementering.

Säkerställ att produkten uppfyller dina behov under verkliga förhållanden

I stället för att bara föreställa sig hur en plattform för informationshantering kan tillgodose dina behov efter att ha sett en demo, gör MVP att en organisation faktiskt kan använda plattformen i realtid och under verkliga förhållanden. De kan uppleva den och börja räkna ut om och hur det kan finnas mer värde att vinna med en mer expansiv utrullning.

Fokusera på de viktigaste funktionerna i produkten

Under implementeringen kan teamet fokusera på de funktioner och möjligheter som är viktigast. De kan börja bygga upp en lista över vad som måste finnas och vad som är bra att ha. Med ett stegvis tillvägagångssätt har kunden friheten att rangordna de funktioner de behöver och vill ha och ta den översta stapeln och lägga till efter behov. Så istället för att slösa resurser på funktioner som ingen skulle använda kan de koncentrera sig på viktiga funktioner som ger maximalt värde.

Minska produktens kostnad och tidsåtgång

Varför skulle du köpa en Boeing 747 när allt du egentligen behövde göra var att ta dig till mataffären? En cykel hade räckt alldeles utmärkt. På samma sätt kan en kund lösa vissa problem utan en enorm investering av tid och pengar. Om produkten gör det du vill att den ska göra kan du fasa in andra funktioner eller fasa in den i andra delar av organisationen. Kunderna kan i slutändan skapa affärsnytta inom en realistisk budget i början. De kan implementera plattformen utan att spendera tre månader på att skapa en omfattande plan som kanske inte är relevant när processen är över.

Iterativ process möjliggör fasindelning av produkten i den takt som passar kunden

Genom att implementera en MVP-produkt för informationshantering i en del av organisationen kan du börja ta reda på vad du gillar med den och var du kanske kan utöka användningen av den till andra delar av organisationen. Det är vanligt att våra kunder till exempel implementerar M-Files på sin juridiska avdelning, blir förälskade i den och innan man vet ordet av har andra avdelningar fasats in i produkten.

Eftersom en implementering av en Minimum Viable Product innebär att kunden kommer att börja med kärnfunktioner och funktionaliteter, gör det att de kan identifiera de bästa användarbaserna i sin organisation och finslipa de bästa användningsfallen för dem. MVP-strategin möjliggör iterationer av plattformen - iterationer som kommer från en mer välinformerad plats. Dessa framtida faser inkluderar saker som:

• vilka andra funktioner som ska läggas till
• vilka aspekter som bidrar till att öka ROI
• och exakt var budgeten kan fördelas för att få ut mesta möjliga värde av plattformen

Om en kund vill ha alla funktioner som ingår i M-Files kommer vi säkert att diskutera det med dem och hjälpa dem att avgöra, på ett konsultativt sätt, om det är vad de behöver. Men i slutändan, om du granskar informationshanteringsplattformar som M-Files - eller någon annan mångfacetterad teknik för den delen - som främjar en stegvis MVP-strategi, ska du veta att de har ditt bästa intresse för ögonen. Om en leverantör ville sälja mig den dyraste versionen av en produkt med varenda funktion (som jag kanske eller kanske inte behöver), skulle jag oroa mig för att de var ute efter den stora försäljningen istället för att se till mina behov.