Løsriv dine fordomme og lær, hvorfor succesfulde virksomheder omfavner MVP’et som en nøgle til at gøre deres kunder glade.
Af Arbi Vartan og Jeff Brinkerhoff
Slalom elsker Agile. Vi er begejstrede for de reelle, målbare fordele, som vi har set virksomheder få ud af det, og vi taler om nogle af de største fordele i en række blogindlæg og et gratis Agile-webinar – se det on-demand.
MVP’en, eller Minimum Viable Product, er grundlæggende for Agile-praksis. Og det er også noget, der skaber modstand. Vi har hørt vores kunder sige ting som: “Vores chefer vil ikke have det mindste – de vil have den bedst mulige kvalitet.” Ja, hvorfor skulle man ikke ønske at gøre sit bedste? Det er et godt spørgsmål, men det er baseret på en misforståelse af MVP’en.
MVP’en, som Frank Robinson opfandt i 2001, og som Eric Ries populariserede i sin bog Lean Startup, er blevet en grundpille for højtydende produktteams over hele verden. Hvorfor har Google været så dominerende i så lang tid? Hvorfor laver Apple nogle af de mest populære produkter i verden? Hvorfor har Netflix ikke blot overlevet, men trives ud over deres oprindelige forretningsmodel? Mange faktorer har bidraget, men en fællesnævner er, at de alle bruger MVP’en.
Så hvad er MVP’en? Her er Eric Ries’ definition: Den version af et nyt produkt, som giver et team mulighed for at indsamle den maksimale mængde valideret viden om kunderne med den mindste indsats.
Som det fremgår af denne definition, er MVP’et ikke et produkt med den mindst mulige funktionalitet, der er nødvendig for en offentlig lancering. Det har intet at gøre med offentlig lancering af et produkt overhovedet. MVP’en er snarere nøglen til at anvende den videnskabelige metode til at opbygge produkter. Det er udelukkende en mekanisme til valideret læring, der bruges til at teste hypoteser og finde ud af, hvad der vil opfylde kundernes behov.
Dump begrebet, hvis du skal – men behold konceptet
I Slalom har vi integreret MVP-konceptet i både den måde, vi bygger produkter for virksomheder, og i den måde, vi samarbejder med dem om at høste fordelene ved at inkorporere agile principper og praksis i deres forretningsmodel. Men efter mere end tyve agile virksomhedstransformationer og hundredvis af partnerskaber på tværs af brancher har vi fundet ud af, at det nogle gange er enklere ikke at tvinge brugen af begreber som MVP frem. Nogle er gået over til udtrykket “Minimum Lovable Product”, og Henrik Kniberg (bedst kendt for sit arbejde med Spotifys ingeniørkultur) foreslår brugen af udtrykkene Earliest Testable, Earliest Usable og Earliest Lovable Products.
Alle disse udtryk er fine. Agile handler om gladere, mere produktive teams – ikke om terminologi. Vores tilgang til dette eller ethvert andet misfortolket, uklart Agile-begreb er at springe ordet over og stille følgende tre spørgsmål:
- Hvorfor gøre det? I tilfældet MVP handler det om hurtig læring samt de underliggende principper: kundetilfredshed, løbende forbedringer og enkelhed.
- Hvad ville det kræve at gøre det i min virksomhed? Åh, styrken af indramning! I stedet for at spørge, om du kan gøre det, fokuserer vi på blokeringer – organisatoriske eller andre blokeringer. Svaret på dette spørgsmål tager ofte form af buy-in fra enkeltpersoner, som man troede var ubevægelige.
- Hvad hvis vi ikke gjorde det? En anden rammestrategi: fokuser på omkostningerne ved at slæbe videre med status quo. Det kan skabe en følelse af, at det haster, og skabe enighed om en ny måde at arbejde på.
Her er en historie om farerne ved status quo: Et projekt for en virksomhed, som vi for nylig arbejdede med, involverede seks måneder på en større softwareudgivelse, der havde indflydelse på mere end 200 interne brugere. De låste sig selv inde i et rum og afsluttede opbygningen og al testning. Og det var først på dette tidspunkt, at de indhentede feedback fra en håndfuld forretningsanalytikere – ikke fra de faktiske brugere. Denne form for afkrydsningsaktivitet, der er for sen til at have nogen reel virkning, og som ikke har et ægte fokus på valideret læring, kan næppe engang betegnes som indhentning af feedback. Det er i virkeligheden et forsøg på at bekræfte det uundgåelige.
Resultatet var forudsigeligt. Da der allerede var brugt så meget tid og penge, følte de sig tvunget til at gå videre, og alle 200 brugere afviste den nye software på grund af dens langsomme ydeevne og manglende brugervenlighed. Seks måneder og over 12 millioner dollars blev brugt, og der blev kun peget fingre mellem forretnings- og teknologiteamene.
Forestil dig nu det samme scenarie med en MVP, der blev udleveret til en gruppe slutbrugere tidligt i projektet. Udviklerne kunne straks lære, hvad de gjorde forkert, og derefter udrulle yderligere MVP’er og forbedre dem iterativt hver gang, indtil der blev udrullet et endeligt produkt, der var udviklet sammen med og godkendt af rigtige brugere. En yderligere fordel: Brugerne i testgruppen ville være grundigt investeret i projektet og ville udbrede kendskabet til det blandt deres kolleger.
Vi har set præcis dette scenarie udspille sig, og det er derfor, vi tror så meget på MVP’en – uanset hvad man vælger at kalde den.