Wat is een Minimum Viable Product (MVP)?

Wat is een Minimum Viable Product (MVP)?

Werken met het idee om eerst een ​​Minimum Viable Product (MVP) te creëren, wordt wereldwijd steeds populairder. Maar wat betekent het om een ​​MVP te maken? Wat is het Minimum? Wat is levensvatbaar (Viable) en voor wie? Wat is het verschil met het bouwen van een prototype, een Proof of Concept (PoC) of het leveren van een Minimum Marketable Feature Set (MMFS)? En hoe zit het met een mock-up of de Minimum Useable SubseT (MUST)?

Veel vragen over een paar nieuwe (verwarrende?) termen. Laat ik beginnen met de definitie van een MVP, dat is “een versie van het eindproduct die de maximale hoeveelheid gevalideerd leren mogelijk maakt met de minste inspanning“.

Het idee is om de eenvoudigste vorm van een product te maken en om feedback te verzamelen die kan worden gebruikt om het product met een aantal iteraties te verbeteren. Dit productontwikkelingsproces past perfect bij de Agile Way of Working, en het is dan ook geen wonder dat het gebruik van MVP’s tegenwoordig zo populair is.

In zijn boek “The Lean Startup” legt Eric Ries uit dat kleine verbeterstappen zullen leiden tot een perfect product door te leren van feedback. Dit gevalideerde leren kan ook resulteren in een overstap naar een compleet nieuw product. Wanneer dit gebeurt, wordt dit een kantelpunt (pivot) genoemd. Het gaat uiteindelijk om het leveren van producten die consumenten (klanten en / of gebruikers) écht willen en nodig hebben.

Het gebruik van een MVP vereist wederzijdse overeenstemming over wat haalbaar is en wat we bedoelen met minimum. Dit is heel erg belangrijk omdat dit het uitgangspunt is voor onze gezamenlijke inspanning. Het bepaalt de verwachtingen over ontwikkeltijd, budget, kwaliteit, scope, risico en baten (of waarde). Deze overeenstemming is afhankelijk van de context, het doel van het product en wie het zal gebruiken.

Gaan we iets ontwikkelen voor onze interne gebruikers, of willen we de wereldmarkt veroveren?

Om deze vragen te kunnen beantwoorden, hebben we om te beginnen een productvisie en een businesscase op hoofdlijnen nodig voor onze MVP. De visie helpt ons het eindresultaat in beeld te brengen en geeft een idee wie het product gaat gebruiken. De business case geeft een inschatting van het investeringsrendement (RoI).

Laten we aannemen dat we willen weten of ons nieuwe idee voor een product de investering en de ontwikkelingsinspanning waard is. Je kunt eenvoudig een landingspagina op de website van je bedrijf bouwen en kijken of jouw volgers zich aanmelden voor een eerste release. Of misschien gebruik je een van de crowdfundingwebsites om je idee te lanceren. Kunnen we deze “proefballon”, eenvoudig prototype of Mock-up een MVP noemen? Misschien niet volgens de definitie van een eenvoudige versie van het eindproduct. Maar we kunnen het nog steeds gebruiken om feedback te verzamelen en de volgende stappen te zetten om ons product te ontwikkelen. Dus als je wilt zeggen “dit is een MVP”, vind ik dat prima, als je het maar met elkaar eens bent!

Voor intern gebruik kun je producten ontwikkelen voor eigen users. Ook hier geldt dat je graag wilt leren van wat zij daadwerkelijk nodig hebben. Dus je start met een prototype of een Proof of Concept (PoC). Intern gebruik geeft je nog meer mogelijkheden om kortere en snellere ontwikkel iteraties uit te voeren, zodat je in staat bent snel een volgende versie op te leveren die prima past bij de eisen en wensen. “Fit for purpose” zoals dat vaak wordt genoemd. De start met een duidelijke product visie en business case is hét voorbeeld voor het definiëren van een MVP.

Een ander scenario is dat jouw organisatie een product of dienst moet bouwen om compliancy-redenen. In dit geval betekent het bouwen van het Minimum misschien dat je alleen de Must haves requirements creëert. De vereisten voor Should have worden tot een absoluut minimum of zelfs nul beperkt, en Could have items worden voorlopig automatisch Won’t have. Deze prioritering van vereisten door MoSCoW (Must, Should, Could, Won’t) te gebruiken en alleen de Must haves te bouwen, zal leiden tot een Minimum Useable SubseT (MUST). Kunnen we dit MUST-productscenario een MVP noemen? Als er maar één versie is en u uw product niet verbetert, dan misschien niet. Als je je verbetert en MUST was slechts de eerste stap, kunnen we het een MVP noemen. Zolang je het ermee eens bent!

Een vierde voorbeeld van MVP-productontwikkeling is waar je feedback wilt en nodig hebt van de daadwerkelijke klant die jouw product heeft gekocht. Deze klant was bereid om je te betalen, misschien als “early adopter” van jouw product. Dus het minste wat je kunt doen, is iets afleveren dat werkt en waardevol is, de Minimum Marketable Feature Set (MMFS). Blijf vervolgens in contact met deze klant voor feedback. Wanneer je op basis van de feedback updates kunt geven, is hij of zij de eerste die het te horen krijgt. Samen bouw je aan de volgende versie om de klant en de “early majority” van nieuwe klanten te voorzien van je product. Dit scenario is een geavanceerde manier om samen met uw klant uw MVP te bouwen. Voor mij is een MMFS een MVP, eens?

Dus wat is vervolgens de naam van het product als we feedback hebben gebruikt en iteratief een nieuwe versie hebben gemaakt? Ik hoor soms termen als “MVP2” of “The Next Viable Product” of gewoon het “nieuwe Minimum Viable Product”. Is het nog steeds een MVP? Zolang je het ermee eens bent en je product gebruikt om te leren en verbeteren.

De conclusie is dat we de gevalideerde leercyclus moeten gebruiken, de build-measure-learn lus. Op deze manier kunnen we in een redelijke tijd het perfecte product bouwen. Dat is efficiënt en effectief. Ik hoop dat je het hiermee eens bent!

Wil je meer weten over dit onderwerp, vul dan onderstaand formulier in: