Wat is een Minimum Viable Product?
Een Minimum Viable Product (MVP) is een eerste versie van een product of dienst met voldoende functionaliteiten om het product of de dienst in de markt uit te testen. Een Minimum Viable Product wordt niet alleen gebruikt om de haalbaarheid van het product te onderzoeken maar ook de (grote van de) markt te testen en te verkennen. Met behulp van een Minimum Viable Product probeert men de zogenoemde “Early Adaptors” te bereiken zodat hun feedback kan gebruiken voor het door ontwikkelen en verbeteren van de Minimum Viable Product tot een volwassen product of dienst.
Een Minimum Viable Product bestaat in veel gevallen, maar niet altijd, uit Minimum Marketable Features.
Wat is het doel van een Minimum Viable Product?
Een Minimum Viable Product dient dus meerdere doelen:
- het valideren van het product idee met real-life data
- het verkrijgen van feedback en data voordat het product 100% af is
- Het vroeg leveren van waarde
- Het minimaliseren van risico en verspilling
1. Valideren van het product idee
Een Minimum Viable Product neemt een belangrijke plaats in, in het innovatie proces. In traditionele innovatie of ontwikkelprocessen wordt een product volledig ontwikkeld voordat het op de markt wordt gebracht. In een Agile proces werkt ment echter met een Minimum Viable Product. Dit houdt in dat een eerste versie van het nieuwe product wordt ontwikkeld dat beschikt over een aantal functionaliteiten die al voldoende waarde cremeren voor de klant. Deze functionaliteiten zijn niet nog volledig doorontwikkeld en zullen in de toekomst nog verder verbeterd moeten worden. Ook zullen er nog bepaalde functionaliteiten ontbreken. Dit weerhoudt de product ontwikkelaars er echter niet van om de innovatie alvast in de markt te plaatsen en te onderzoeken of er voldoende vraag is naar het product. Hiermee valideren zij de Epic Hypothesis Statement voor het product. Ze valideren de hypothese dat dit product gewenst is door klanten of gebruikers en dat zij bereid zijn ervoor te betalen.
Een Minimum Viable Product is dus niet een demo, maar een echt werkend product waar klanten bereid zijn om voor te betalen en die klanten dus ook daadwerkelijk kunnen gebruiken (wat bij een demo vaak niet, of slechts deels het geval is). Op basis van de verkopen of het gebruik van het product wordt data verzameld die de interesse uit de markt bevestigd of verwerpt. Ook kan de data worden gebruikt voor het bepalen van het toekomstige prijsniveau en verdienmodellen of het inschatten van de Product Life Cycle.
Bovenstaande is met name van toepassing op Agile werken. Hanteert men meer een Design Thinking approach dan is een Minimum Viable Products soms niets meer dan een pagina, of een “koop nu” knop, op een website. Het gedrag van de bezoekers op die pagina, of die van bezoekers die daadwerkelijk op de ” koop nu” knop klikken wordt dan gebruikt om het potentieel voor een bepaald product te onderzoeken.
2. Het verkrijgen van feedback en data voordat het product 100% af is
Met het lanceren van een Minimum Viable Product dat ook daadwerkelijk door echte klanten (early adaptors) gekocht wordt, wordt een mogelijkheid gecreëerd om feedback te verzamelen. Dit kan door, in het geval van digitale producten, data te verzamelen over het gebruik en dit te analyseren. Ook kan direct contact gezocht worden met de gebruikers met het verzoek om feedback achter te laten. Het opzetten van een community voor de “early adaptors” is een derde manier waarop een producent in contact kan komen met de klant en actief feedback kan verzamelen. Vaak wordt dit gedaan in de vorm van beperkte toegang voor geselecteerde klanten tot bèta releases. Een bèta release is de eerste keer dat een versie van een product beschikbaar wordt gesteld aan personen die niet werkzaam zijn voor de organisatie.
De feedback verkregen van de early adaptors helpt bij het verder ontwikkelen van het product, het wegnemen eventuele kinderziektes en het verkrijgen van een marktpositie. Vaak wordt een Minimum Viable Product gelanceerd in een niche en/of een beperkte geografisch regio. De feedback die binnen die niche of regio wordt verzameld wordt vervolgens gebruikt om het product verder te ontwikkelen, eventuele kwaliteitsissues weg te nemen en de ideale uitrolstrategie te bepalen. Op deze manier wordt iedere keer dat een nieuwe versie wordt uitgebracht, of een nieuwe markt wordt betreden, een verbeterde versie van het product gelanceerd.
3. Het vroeg leveren van waarde
Met het lanceren van een een Minimum Value Product wordt direct waarde gecreëerd voor de klant. Ook al is het product nog niet volledig, het heeft werkende functionaliteiten en is op dat moment al van toegevoegde waarde voor de klant. De klant is bereid het te gebruiken en ervoor te betalen. In plaats van dat een klant langdurig moet wachten totdat het een compleet product krijgt (Waterfall aanpak) kan de klant direct al beginnen het product te gebruiken met beperkte functionaliteiten.
Dit is het verschil tussen een jaar wachten en dan een product krijgen met 12 functionaliteiten of een Minimum Viable Product krijgen met 1 functionaliteit die vervolgens elke maand er een functionaliteit bij krijgt. De waarde voor de klant wordt eerder geleverd én de klant krijgt het gevoel dat het product continue verder wordt verbeterd waardoor de klantbeleving stijgt.
4. Minimaliseren van Risico en Verspilling
Als Epic Owner wil je natuurlijk de visie, vastgelegd in de Epic Hypothesis Statement, valideren. Is de klant geïnteresseerd in dit product en is men bereid er voor te betalen. Maar, als Epic Owner dien je niet alleen naar de omzet kant, maar ook naar de kosten kant te kijken. Kunnen we dit product rendabel in de markt plaatsen. Een Minimum Viable Product helpt ook daarbij. een MVP levert eerder waarde en eerder feedback dan een product dat wordt ontwikkeld volgens een traditionele waterfall methode. Deze feedback is vaak gericht op het product en helpt daarmee bijvoorbeeld om “bugs”en issues te identificeren die een verdere ontwikkeling of uitrol in de weg staan. Deze feedback wordt dus gebruikt om het product te verbeteren. Maar dit is niet de enige feedback die je als Epic Owner zou moeten willen verzamelen. Het lanceren van een MVP in een niche of beperkte geografische regio biedt ook de optie om feedback te verzamelen over de risico’s (bijvoorbeeld gelinkt aan een uitrol strategie) en de achterliggende processen (Operational Value Streams).
Als we als voorbeeld nemen het lanceren van een app waarin evenemententickets kunnen worden geboekt. Op het moment dat de app in gebruik genomen wordt door klanten zal niet alleen de app over basisfunctionaliteiten moeten beschikken maar ook de gehele organisatie daarop ingericht moeten zijn. Indien betalingen via de app plaats gaan vinden moeten bijvoorbeeld de interne financiële processen correct zijn ingericht. Indien er customer support functie in de app aanwezig is zal er een Helpdesk klaar moeten staan om vragen te registreren en af te handelen. Al deze Operational Value Streams moeten worden ingericht en vertegenwoordigen kosten en risico’s die het succes van de App teniet kunnen doen. Een Minimum Viable Product helpt in een vroeg stadium om de impact op de organisatie te analyseren en te bepalen welke organisatie onderdelen ingericht moeten worden en welke risico’s en kosten daarbij ontstaan. Risico’s kunnen dan in een vroeg stadium worden gemitigeerd en kosten kunnen worden beheerst. Het werken met een Minimum Viable Product helpt dus het uitfilteren van goede maar niet rendabele ideeën.
Als in een latere sprint een nieuwe functionaliteit wordt toegevoegd kan dezelfde impact analyse worden uitgevoerd. Eventuele functionaliteiten die onvoorziene kosten of risico’s met zich mee blijken te brengen kunnen vervolgens worden aangepast of worden verwijderd. Indien het product met een traditionele “waterfall” aanpak wordt ontwikkeld dan kom je pas in een laat stadium achter deze onvoorziene kosten en risico’s en vaak is het tegen die tijd, door de complexiteit van het product, niet meer mogelijk om een specifieke functionaliteit te herkennen als de bron van de risico’s en kosten. Ook het verwijderen van een functionaliteit is dan, door de complexiteit en verwevenheid met andere functionaliteiten, vaak niet meer mogelijk.
De uitdagingen bij het ontwikkelen van een Minimum Viable Product
Het eindproduct ontwikkelen in plaats van een Minimum Viable Product
Een van de valkuilen die we vaak zien langs komen is dat de Development Value Stream probeert het eind product te ontwikkelen in plaats van een Minimum Viable Product. Men is bang dat een Minimum Viable Product niet goed genoeg is om feedback mee te verzamelen of dat men wordt “afgerekend” op een product dat niet af is. Als gevolg daarvan zal het team proberen zoveel mogelijk features in de Minimum Viable Product aan te brengen (waarmee het dus eigenlijk het eind product wordt). Omdat er vaak maar enkele sprints worden uitgetrokken voor het ontwikkelen van een Minimum Viable Product zal het toevoegen van teveel features al snel tot vertraging, of tot een lagere kwaliteit leiden. Er moet immers werk worden uitgevoerd in dezelfde beperkte tijd. Hierdoor zal men sneller of harder proberen te werken wat altijd zijn invloed gaat hebben op de geleverde kwaliteit.
Het nadeel van het werken aan een eind product in plaats van een Minimum Viable Product is dat het te lang duurt voordat er iets aan de klant kan worden getoond. Hiermee duurt het te lang voordat er feedback wordt verzameld. Deze feedback is echter enorm belangrijk voor het door-ontwikkelen van het Minimum Viable Product tot een eindproduct. De feedback vertelt de Development Value Stream namelijk welke features er verbetert of ontwikkeld moeten worden. Ontwikkelt men dus een eind product in plaats van een Minimum Viable Product dan is de kans zeer groot dat het eindproduct, door het gebrek aan feedback, niet over de juiste features beschikt. Daarnaast duurt de ontwikkeling veel langer en wordt de mogelijkheid weggenomen om de ontwikkeling van het product vroegtijdig aan te passen of zelfs te stoppen. Dit laatste kan bijvoorbeeld gebeuren wanneer uit de feedback blijkt dat er geen klantbehoefte is voor het product.
Negeren van klantfeedback
Een van de doelen van een Minimum Viable Product is het verkrijgen van klantfeedback. Deze klantfeedback zal je moeten vertellen of er daadwerkelijk interesse is voor het product maar ook hoe de huidige features worden ontvangen en welke features er in de toekomst nog zouden moeten worden toegevoegd.
Met name de klantfeedback op de huidige en toekomstige features komt vaak in een negatieve vorm. Klanten klagen bijvoorbeeld over een slechte gebruiksvriendelijkheid of het gebrek aan bepaalde, voor hun, essentiële functionaliteiten. Als Epic of Product Owner moet je in staat zijn door de negatieve feedback heen te kijken en vooral te kijken naar wat jij kan aanpassen om deze klanten tevreden te krijgen. Dit zullen namelijk de features worden waar in de toekomst aan gewerkt kunnen worden.
Ook het uitblijven van feedback is feedback. Dit kan namelijk betekenen dat er maar beperkte interesse is in het product. Klanten die klagen over ontbrekende features betekent namelijk dat deze klanten daadwerkelijk je product hebben gebruikt. Als feedback uitblijft dan is de kans groot dat klanten je product, in de huidige vorm, niet willen gebruiken.
Werken met een onervaren team
Bovenstaande twee valkuilen zijn vaak het gevolg van werken met onervaren Agile Teams. Teams (of hun Product Owner) laten zich meeslepen in de visie voor het product zonder af te toetsen of die visie werkelijk gerealiseerd kan worden. Indien de Agile teams volgens de Scrum methode werken dan is het de rol van de Scrum Master om dit te bewaken en waar nodig de Product Owner en/of Developers hierin bij te sturen en te onderwijzen.
