Introductie

De meesten van ons kennen de term “Minimum Viable Product”. Een Minimum Viable Product of kortweg MVP is een product dat genoeg waarde toevoegt om ‘viable’, levensvatbaar, te zijn. De term wordt gebruikt om een optimum te vinden tussen de moeite die je in een product stopt enerzijds, en de aanvaardbaarheid voor de klant anderzijds. Het risico is namelijk dat je op basis van verkeerde aannames te veel moeite stopt in functionaliteiten die niet gebruikt worden. Viable is echter een woord dat door mensen in verschillende rollen, verschillend zal worden uitgelegd. Is Viable het absolute minimum aan gebruiksvriendelijkheid maar het maximum aan functionaliteit? Of is het de versie die het meeste aantal klanten aan zal spreken met minimale hoeveelheid functionaliteit? De versie waarmee gebruikers de meeste mond-op-mond reclame zullen maken? Minste aantal klachten?

Viable vs Lovable

De term Viable moet dus strak gedefinieerd worden wil het hele team van marketing tot app ontwikkelaar hetzelfde idee hebben van wat een minimale versie inhoudt. En voor een iOS app waar de app zelf het verdienmodel is, en je zoveel mogelijk aantallen wil verkopen, zal dat anders zijn dan een gratis B2B app die onderdeel is van het totaalpakket aan diensten. Voor die laatste echter is de term Viable het gevaarlijkst. Want het kan zijn dat je als ‘brein’(-team) achter de app niet bewust meegeeft aan app ontwikkelaars wat je verstaat onder Viable. In dat geval delegeer je onbewust het bepalen van de definitie ervan aan het ontwikkelteam.

Kan dat kwaad dan? Want je geeft toch gewoon door wat er gebouwd moet worden, en zolang de specificaties goed zijn krijg je wat je vraagt.

Ja en nee. Specificaties zijn ten eerste nooit perfect. Ten tweede geven specificaties soms weinig mee van de ‘geest’ achter, de gedachte achter de te bouwen functionaliteit. En ten derde geven specificaties van deelproducten nog minder mee van wat we voor het gehele product als Viable zien.

De gevolgen hiervan zijn niet positief. Een app ontwikkelaar mag nu zelf bepalen wanneer de functionaliteit ‘netjes’ af is. De ene app ontwikkelaar zal het absolute minimum opleveren en (denkend aan de eigen definitie van Viable) er zeer tevreden op terugkijken. De andere ontwikkelaar zal (ook denkend aan de eigen definitie van Viable) denken “dit kan ik zo echt niet opleveren”. Uiteraard zijn er testers, UI/UX designers en andere rollen die hierin mee kunnen kijken en als die er voldoende zijn en het een op elkaar ingespeeld team is voorkomt dat sommige excessen, maar deze rollen zijn niet altijd in voldoende mate aanwezig in een team. Daarnaast zorgt tijdsdruk en met sprints werken ervoor dat de volgende functionaliteiten alweer op de planning staan, met als gevolg dat er iets opgeleverd wordt dat Viable is volgens de persoon die het gemaakt heeft.

Een app ontwikkelaar hoeft bij een MVP minder na te denken over de gedachte achter het product.

Dat samen met alle andere ‘Viable’ onderdelen van de applicatie maakt dat het wellicht totaal niet voldoet aan het doel van de applicatie. Er zijn nog allerlei andere momenten te bedenken wanneer ‘Viable’ gebruiken een slecht idee is, bijvoorbeeld bij het binnenhalen van investeringen en bepalen hoeveel tijd mag worden besteed aan het MVP.

Daarom kunnen we beter op zoek naar een term die beter duidelijk maakt waar het minimale product aan moet voldoen om succesvol te zijn.

Een voorbeeld hiervan is de term “Minimum Lovable Product” (MLP). Deze term werd geintroduceerd in 2013 door Henrik Kniberg van Spotify. Hij omschrijft het ‘waarom’ van deze term als volgt:

«…Perhaps a better term is Minimum Lovable Product. A bicycle is a lovable and useful product for somebody with no better means of transport, but is still very far from the motorcycle that it will evolve into».

En dat klopt. Een MVP streeft er naar een product op te leveren dat levensvatbaar en net genoeg is, en nooit een prachtig en geliefd product. Zoals ik eerder beschreef is de definitie van een MVP ook te veel voor interpretatie vatbaar. Want wat is net genoeg? Volgens welke standaarden?

Wat is net genoeg?

Een MLP echter streeft er naar geliefd te zijn, wat natuurlijk een hele andere lading heeft als levensvatbaar. Een MLP is een product waarvan je wilt en verwacht dat het enthousiasme opwekt en een warm, goed gevoel geeft bij het gebruik ervan.

“Would I love this functionality” zou een app ontwikkelaar, een tester, het hele team zich afvragen bij ieder deelproduct. Elk mens kan hier iets mee en MLP staat hiermee nogmaals in schril contrast met MVP.

“Would I love this functionality?”

Dit betekent echter ongetwijfeld dat je moet snijden in hoeveel functionaliteiten je bouwt. Want de hoeveelheid aandacht en tijd per functionaliteit zal moeten stijgen. Maar wat je ervoor terugkrijgt is zeer waarschijnlijk stukken doeltreffender dan wat je had gekregen bij het maken van een MVP.

Is de term MLP dan overal inzetbaar? Zeker niet! Een ‘lovable’ product bouwen is voor bepaalde doeleinden de beste insteek, maar wat de goede invalshoek voor jullie product is, hangt af van allerlei factoren. Wat is je budget, wie is je klant, hoeveel tijd heb je en hoe compleet is je team? Kost de app geld of is het gratis, is het de enige app of onderdeel van een set aan diensten. Is het duidelijk voor de klant dat het een probeersel is of moet deze er meteen goed mee kunnen werken of van houden?

Overal de term MLP gebruiken is net zo’n slecht idee als overal de term MVP gebruiken.

Maar wat nou als ik vooral geld wil verdienen met het product en de geliefdheid me niet zo veel uitmaakt? Ook dan is Viable net zo’n slechte term. Want je wilt vooral dat mensen bereid zijn te betalen voor het product. Dus, gebruik in zo’n situatie bijvoorbeeld de term Minimum Payable Product. Het is dan meteen duidelijk aan iedereen wat de geest achter de ontwikkeling ervan moet zijn: een product maken waar jij zelf bereid voor zou zijn te betalen.

Het hoeft hier niet te stoppen. Maximum Payable Product voor een app waarvoor het volume minder belangrijk is maar waar je vooral een kleine groep veel-betalende klanten wilt hebben. Minimum Stable Product als het één enkele functionaliteit betreft en stabiliteit de enige vereiste is. Minimum Innovative Product als innovatie ademen het belangrijkste is. Wat maakt het uit als het grammaticaal niet precies meer klopt? Het gaat erom dat iedere specificatie, iedere presentatie doordrenkt is van de gedachte achter de applicatie en ieder persoon een eenvoudige, drie-woordige term in gedachte heeft bij het uitwerken, specificeren, ontwikkelen, marketen en onderhouden van het product.

Vragen? Neem direct contact op!