Bortse från dina förutfattade meningar och lär dig varför framgångsrika företag använder MVP som en nyckel till att göra sina kunder nöjda.
av Arbi Vartan och Jeff Brinkerhoff
Slalom älskar Agile. Vi är entusiastiska över de verkliga, mätbara fördelar som vi har sett företag få av det, och vi talar om några av dess största fördelar i en serie blogginlägg och ett kostnadsfritt Agile-webinar – se det på begäran.
MVP:n, eller Minimum Viable Product (minsta gångbara produkt), är en grundläggande del av Agiles praktik. Och det är också något som genererar motstånd. Vi har hört våra kunder säga saker som: ”Våra chefer vill inte ha ett minimum – de vill ha bästa möjliga kvalitet”. Varför skulle du inte vilja göra ditt bästa? Det är en bra fråga, men den bygger på ett missförstånd om MVP.
MVP, som introducerades av Frank Robinson 2001 och populariserades av Eric Ries i hans bok Lean Startup, har blivit en grundpelare för högpresterande produktteam över hela världen. Varför har Google varit så dominerande så länge? Varför tillverkar Apple några av de mest populära produkterna i världen? Varför har Netflix inte bara överlevt, utan även blomstrat bortom sin ursprungliga affärsmodell? Många faktorer bidrog, men en gemensam nämnare är att de alla använder MVP.
Så vad är MVP? Här är Eric Ries definition: Den version av en ny produkt som gör det möjligt för ett team att samla in maximal mängd validerad kunskap om kunderna med minsta möjliga ansträngning.
Som framgår av denna definition är MVP inte en produkt med minsta möjliga funktionalitet som är nödvändig för en offentlig lansering. Det har ingenting att göra med att släppa en produkt offentligt överhuvudtaget. MVP är snarare nyckeln till att använda den vetenskapliga metoden för att bygga produkter. Det är enbart en mekanism för validerat lärande som används för att testa hypoteser och upptäcka vad som kommer att uppfylla kundernas behov.
Släpp begreppet om du måste – men behåll konceptet
På Slalom har vi integrerat konceptet MVP både i hur vi bygger produkter för företag och i hur vi samarbetar med dem för att dra nytta av fördelarna med att införliva agila principer och metoder i deras affärsmodell. Efter mer än tjugo agila företagsomvandlingar och hundratals partnerskap inom olika branscher har vi dock kommit fram till att det ibland är enklare att inte tvinga fram användandet av termer som MVP. Vissa har övergått till termen ”Minimum Lovable Product”, och Henrik Kniberg (mest känd för sitt arbete med Spotifys ingenjörskultur) föreslår att man använder termerna Earliest Testable, Earliest Usable och Earliest Lovable Products.
Alla dessa termer är bra. Agilitet handlar om lyckligare, mer produktiva team – inte om terminologi. Vårt tillvägagångssätt när det gäller detta eller andra misstolkade, oklara agila begrepp är att hoppa över ordet och ställa följande tre frågor:
- Varför göra det? När det gäller MVP handlar det om att lära sig snabbt, liksom de underliggande principerna: kundtillfredsställelse, ständiga förbättringar och enkelhet.
- Vad skulle krävas för att göra det i mitt företag? Åh, kraften i inramningen! Istället för att fråga om du kan göra det, fokuserar vi på blockerare – organisatoriska eller andra. Svaret på den här frågan tar ofta formen av ett köp från personer som man trodde var orubbliga.
- Tänk om vi inte gör det? En annan inramningsstrategi: fokusera på kostnaderna för att hålla fast vid status quo. Detta kan skapa en känsla av att det är bråttom och skapa en anpassning till ett nytt arbetssätt.
Här är en berättelse om farorna med status quo: Ett projekt för ett företag som vi nyligen arbetade med innebar att vi ägnade sex månader åt en större programvaruversion som påverkade mer än 200 interna användare. De låste in sig i ett rum och slutförde byggandet och all testning. Och det var först nu som de bad om feedback från en handfull affärsanalytiker som ställföreträdare – inte verkliga användare. Den här typen av aktiviteter med kryssrutor, som sker för sent för att ha någon verklig inverkan och utan ett verkligt fokus på validerat lärande, kan knappast ens betecknas som att begära feedback. Det är egentligen ett försök att bekräfta det oundvikliga.
Resultatet var förutsägbart. Eftersom så mycket tid och pengar redan hade spenderats kände de sig tvungna att gå vidare, och alla 200 användare förkastade den nya programvaran på grund av dess långsamma prestanda och bristande användbarhet. Sex månader och över 12 miljoner dollar hade spenderats, med bara pekpinnar mellan affärs- och teknikgrupperna som resultat.
Föreställ dig nu samma scenario med en MVP som distribueras till en grupp slutanvändare i ett tidigt skede av projektet. Utvecklarna skulle omedelbart kunna lära sig vad de gjorde fel, och sedan sprida ytterligare MVP:er och förbättra varje MVP iterativt tills en slutprodukt tas i bruk – utvecklad tillsammans med och godkänd av riktiga användare. Ytterligare en fördel: Användarna i testgruppen skulle vara grundligt investerade i projektet och skulle sprida det bland sina kollegor.
Vi har sett exakt det scenariot utspela sig, och det är därför vi tror så starkt på MVP – vad man än väljer att kalla det.