MVP, MMF, PSI, WTF? Deel één: De MVP begrijpen
Wanneer ik met nieuwe Product Owners werk, merk ik vaak dat we verstrikt raken in een zee van TLA’s (drieletterige acroniemen) wanneer het tijd wordt om hun backlog van ideeën om te zetten in vrij te geven incrementen van waarde.
Het idee van het afbreken van werk – het afbreken van onze grote, geplande product releases in kleinere incrementen van waarde is waar veel nieuwe Product Owners mee worstelen. Hoe nemen we deze Product Roadmap en zet het in iets mijn Scrum teams daadwerkelijk kunnen leveren op een korte, regelmatige cadence? Hoe kan ik deze enorme lijst van Very Important Features (VIF’s) omzetten in een iteratieve set van mogelijkheden om te leren, om waarde te leveren, en om daadwerkelijk iets in de handen van onze klanten te leggen? Met andere woorden….
“Wat is onze MVP?”
“Is dat onze MMF?”
“Kunnen we deze PSI als MVP uitbrengen, of moeten er meer stories gedaan worden voordat we een MMF hebben?”
Ook…. wat??
Wat betekenen deze TLA’s? Hoe verschillen ze van elkaar? Hoe zijn ze aan elkaar gerelateerd? Waarom zou ik me er druk om maken?
Beginnend met MVP (Minimum Viable Product), zal deze driedelige serie beginnende agilists helpen te begrijpen wat deze TLA’s betekenen. Hoe verschillen ze van elkaar? Hoe zijn ze verwant? Waarom zou ik er iets om geven? Het zal ook degenen helpen herinneren die al een tijdje Agile werken waarom deze concepten de hoekstenen van wendbaarheid zijn.
Voor mensen die net beginnen te leren over Scrum, kunnen ze zich wenden tot de Scrum Guide… en snel leren dat de Scrum Guide zwijgt over het hoe van het veranderen van een product in een verzameling van kleine, releasable incrementen van waarde.
Het gebrek aan informatie over dit belangrijke onderwerp kan echt frustrerend zijn voor nieuwe Product Owners. Hopelijk zal de rest van dit artikel MVP’s verduidelijken, en er zijn altijd Certified Scrum Product Owner-klassen om te bekijken voor meer informatie. Laten we ons nu eens verdiepen in het Minimum Viable Product.
The MVP
Je hebt onderzoek gedaan, met focusgroepen een paar rondes van Buy a Feature gelopen, en je hebt een aantal beslissingen genomen over hoe je volgende release eruit zou kunnen zien. U hebt zelfs uw marketingteam ingeschakeld en u bent ideeën aan het doornemen over hoe u een grote indruk kunt maken – advertenties in vakbladen, gepromote Tweets, Facebook-posts…
Maar er zijn nog steeds een paar knagende vragen die u hebt over een aantal van de functies waar u aan werkt. Je hebt erover nagedacht, je hebt ze geanalyseerd, maar er is een stemmetje in je hoofd dat blijft vragen: “Maar hoe weet je dat?”
Dat is waar de MVP in het spel komt – niet Steph Curry, maar de (misschien ten onrechte genoemde) Minimum Viable Product.
The Lean Startup Conundrum
In zijn boek “The Lean Startup” geeft Eric Reis een verwarrende nieuwe definitie van de term “Minimum Viable Product”, die hij uitlegt in een interview in 2015. In het kort:
“Some caveats right off the bat. MVP, ondanks de naam, gaat niet over het creëren van minimale producten. Ten tweede, het gebruik van de definitie van de woorden maximum en minimum betekent dat het beslist niet formulegebonden is.”
Dus, als de wereld van Product Ownership en de Agile-gemeenschap Minimum Viable Product heeft geherdefinieerd om noch over het creëren van het minimum of producten te gaan, wat is het dan?
All About the Learning
Dat knagende stemmetje in je achterhoofd, dat zich afvraagt of er een manier is om uit de Analyse Verlamming val te komen waar je in zit, een manier proberen te vinden om daadwerkelijk de antwoorden te weten op een aantal van je vragen, in plaats van jezelf te analyseren tot een dieper gevoel van valse zekerheid? Dat is waar de Minimum Viable Product in het spel komt.
Waar een PSI (Potentially Shippable Increment) gaat over het creëren van de mogelijkheid om potentieel iets van waarde te verschepen, en de MMF (Minimum Marketable Feature) gaat over het combineren van die stukjes waarde in een verzameling van functies die klantproblemen oplossen, de MVP gaat over het doen van de minimale hoeveelheid werk die je team kan doen om een gevalideerde leerlus te sluiten.
In de Lean Startup-methodologie van productontdekking is een van de belangrijkste gewoonten om in te komen de gewoonte om hypotheses te valideren en experimenten te creëren. In meer traditionele risicomijdende organisaties leidt de overtuiging dat risico’s uit je product moeten worden geanalyseerd voordat het wordt gelanceerd, tot lange doorlooptijden en, frustrerend genoeg, op gegevens gebaseerde veronderstellingen over de wensen en verlangens van de klant. Als we echt goed zijn in statistische analyse, en als we echt goede gegevens hebben over een statistisch significant deel van onze klanten, kunnen we een vrij goede baan hebben bij het formuleren van een onderbouwde gok over wat onze klanten willen.
Maar, aan het eind van de dag, is dat nog steeds een gok.
Wanneer we MVP’s maken, bouwen we met opzet net genoeg functionaliteit om de juiste vragen aan onze klanten te stellen – zou je dit product kopen? Zijn deze pictogrammen zinvol? Frustreert deze workflow je, of helpt het je om je volgende favoriete restaurant te vinden?
Op dit punt kijken we naar papieren prototypes, website wireframes, UI mock-ups; we lopen naar de overkant van de straat naar het winkelcentrum om onze ontwerpen te laten zien aan de dichtstbijzijnde mensen die we kunnen, gewoon om snel te valideren dat we op het juiste spoor zitten.
De magie van het maken van een goede MVP zit hem echter niet in de tools of technieken; het zit hem in de discipline om, wanneer je gegevens van een website heat-map wilt analyseren om uit te zoeken welk kleurenschema het beste werkt, in plaats daarvan wat stiften en papier te pakken, een paar low-fidelity oplossingen te schetsen, en iemand te vragen: “Welke van deze vind je mooier?”