Bandon your preconceptions and learn why successful companies embrace the MVP as a key to making their customers happy.
Door Arbi Vartan en Jeff Brinkerhoff
Slalom loves Agile. We zijn enthousiast over de echte, meetbare voordelen die we bedrijven hebben zien behalen, en we praten over een aantal van de grootste voordelen in een reeks blogposts en een gratis Agile webinar – bekijk on-demand.
De MVP, of Minimum Viable Product, is fundamenteel voor de praktijk van Agile. En het is ook iets dat weerstand oproept. We hebben onze klanten dingen horen zeggen als: “Onze leidinggevenden willen niet het minimum – ze willen de best mogelijke kwaliteit.” Inderdaad, waarom zou je niet je best willen doen? Het is een geweldige vraag, maar een die is gebaseerd op een verkeerd begrip van de MVP.
Gedacht door Frank Robinson in 2001, en gepopulariseerd door Eric Ries via zijn boek Lean Startup, is de MVP uitgegroeid tot een pijler van goed presterende productteams over de hele wereld. Waarom is Google al zo lang zo dominant? Waarom maakt Apple enkele van de meest populaire producten ter wereld? Waarom heeft Netflix niet alleen overleefd, maar is het zelfs verder gegroeid dan hun oorspronkelijke business model? Veel factoren hebben bijgedragen, maar één rode draad is dat ze allemaal de MVP gebruiken.
Dus wat is de MVP? Hier is de definitie van Eric Ries: Die versie van een nieuw product die een team in staat stelt om de maximale hoeveelheid gevalideerd leren over klanten te verzamelen met de minste inspanning.
Zoals deze definitie duidelijk maakt, is de MVP geen product met de minst mogelijke functionaliteit die nodig is voor een openbare lancering. Het heeft helemaal niets te maken met het publiekelijk uitbrengen van een product. Integendeel, het MVP is de sleutel tot het gebruik van de wetenschappelijke methode voor het bouwen van producten. Het is puur een mechanisme voor gevalideerd leren, gebruikt om hypotheses te testen en te ontdekken wat in de behoeften van klanten voorziet.
Dump de term als je moet, maar behoud het concept
Bij Slalom hebben we het concept van de MVP geïntegreerd in zowel de manier waarop we producten voor bedrijven bouwen als in de manier waarop we met hen samenwerken om de vruchten te plukken van de integratie van Agile principes en praktijken in hun bedrijfsmodel. Maar – na meer dan twintig Agile-transformaties in bedrijven en honderden partnerschappen in verschillende sectoren – hebben we gemerkt dat het soms eenvoudiger is om het gebruik van termen als MVP niet af te dwingen. Sommigen zijn overgestapt op de term “Minimum Lovable Product”, en Henrik Kniberg (vooral bekend van zijn werk met de Spotify engineering cultuur) stelt het gebruik voor van de termen Earliest Testable, Earliest Usable, en Earliest Lovable Products.
Elke van deze termen is prima. Agile gaat over gelukkigere, meer productieve teams – niet over terminologie. Onze benadering van dit of elk ander verkeerd geïnterpreteerd, onduidelijk Agile concept is om het woord over te slaan en de volgende drie vragen te stellen:
- Waarom zou je het doen? In het geval van de MVP gaat het om snel leren, en om de onderliggende principes: klanttevredenheid, voortdurende verbetering en eenvoud.
- Wat zou er nodig zijn om het in mijn bedrijf te doen? O, de kracht van framing! In plaats van te vragen of u het kunt, concentreren we ons op blokkerende factoren, organisatorisch of anderszins. Het antwoord op deze vraag neemt vaak de vorm aan van een buy-in van individuen waarvan werd gedacht dat ze onwrikbaar waren.
- Wat als we het niet zouden doen? Een andere strategie om de zaak in een kader te plaatsen: focus op de kosten van het voortzetten van de status quo. Dit kan een gevoel van urgentie creëren en zorgen voor afstemming rond een nieuwe manier van werken.
Hier volgt een verhaal over de gevaren van de status quo: Een project voor een bedrijf waarmee we onlangs hebben samengewerkt, omvatte zes maanden besteden aan een grote software-release met gevolgen voor meer dan 200 interne gebruikers. Ze sloten zichzelf op in een kamer en voltooiden de build en alle tests. En het was pas op dat moment dat ze feedback vroegen van een handvol business analist proxies – niet van echte gebruikers. Dit soort checkbox activiteit, te laat om een echte impact te hebben, en zonder een echte focus op gevalideerd leren, kwalificeert zelfs nauwelijks als het vragen naar feedback. Het is eigenlijk een poging om het onvermijdelijke te valideren.
Het resultaat was voorspelbaar. Omdat er al zoveel tijd en geld in was gestoken, voelde men zich gedwongen verder te gaan, en alle 200 gebruikers wezen de nieuwe software af vanwege de trage prestaties en het gebrek aan bruikbaarheid. Zes maanden en meer dan $12 miljoen uitgegeven, met alleen maar vingerwijzen tussen business en technologie teams als resultaat.
Stel je nu ditzelfde scenario voor met een MVP die vroeg in het project aan een groep eindgebruikers werd ingezet. Ontwikkelaars zouden onmiddellijk kunnen leren wat ze verkeerd deden, en dan verdere MVP’s uitrollen door iteratief te verbeteren met elke MVP tot de uitrol van een eindproduct-ontwikkeld met en goedgekeurd door echte gebruikers. Een bijkomend voordeel: de gebruikers in de testgroep zouden grondig in het project worden geïnvesteerd en het onder hun gelijken evangeliseren.
We hebben precies dat scenario zien spelen, en dat is waarom we zo’n fervente voorstanders zijn van de MVP – hoe je het ook wilt noemen.