.wpb_animate_when_almost_visible { opacity:1; }
 In Strategie

Wij leveren graag MVP’s af: een ‘Minimal Viable Product’, het minimaal werkbare product. Met andere woorden een hele vroege versie van het eindproduct met minimale functionaliteiten, of eigenlijk het fundament van je product. Het is een belangrijk onderdeel van het agile werken met sprints zoals we hier graag doen.

Wat is een MVP precies?

Een MVP van Uber was bijvoorbeeld dat klanten taxi chauffeurs konden oproepen en de betaling konden doen. Andere minder belangrijke functionaliteiten komen pas later. Pas nadat Uber genoeg feedback had verzameld van gebruikers zijn er veel meer functies bij gekomen zoals het live volgen van chauffeurs, het delen van taxi rekeningen en inschattingen van kosten van taxi ritten.

Op die manier heb je al een al tastbaar product die je zelf kunt testen maar ook zeker al aan de gebruikers kunt geven om te gebruiken. Laat de gebruikers feedback geven en gebruik die feedback ook! Wij zorgen er vervolgens voor dat we regelmatig (na een nieuwe ‘sprint’) nieuwe updates toevoegen, zodat er meer functionaliteiten beschikbaar worden.

Waarom is het super nuttig?

In de agile projectaanpak ben je erg flexibel in het ontwikkelen van een project. Je werkt daarbij met diverse ‘sprints’. Dit is een korte vooraf gedefinieerde periode (gangbaar is zo’n 2 weken) waarin we aan de slag gaat om iets te ontwikkelen. Na een aantal sprints zal er een MVP staan: een Minimal Viable Product. Een werkbaar basisproduct met beperkte functionaliteiten.

Zo’n MVP kun je zelf gaan testen en al direct lanceren naar (een beperkte groep) gebruikers. Meestal wanneer je zo’n eerste versie ziet van zo’n product krijg je bepaalde ideeën over welke kant bepaalde features op moeten gaan, welke features als eerste belangrijk zijn. Door zo’n MVP krijg je veel meer gevoel met het product wat ontwikkeld wordt. En belangrijker nog je krijgt feedback waarmee je beter kunt sturen.

Bij niet agile manieren van projecten aanpakken is het gebruikelijk dat je vooraf helemaal bepaald wat het eindproduct moet worden. Dan kun je het pas gebruiken en testen wanneer het zo goed als af is. Dan merk je vaak dat bepaalde dingen waar je vooraf over nagedacht had misschien niet zo handig werken. En dan moet er misschien van alles omgebouwd worden.

Wanneer je bepaald hebt wat de volgende stappen zijn in de volgende sprints kunnen de ontwikkelaars weer verder. Na weer zo’n een of meerdere sprints heb je weer nieuwe features die toegevoegd zijn aan het product. En ondertussen verzamel je de feedback en bepaal je de verdere tijdlijn en functionaliteiten.

De voordelen van een MVP op een rij:

  • Sneller lanceren van je product.
  • Je krijgt waardevolle feedback van de gebruikers.
  • Er is ruimte voor evolutie: je ontdekt zo welke functionaliteiten voor gebruikers belangrijk zijn.
  • Het is kostenefficiënt: Je ontwikkelt alleen de features die echt nodig zijn.
  • Je kunt zo ook makkelijker investeerders vinden: die investeren niet graag in een idee of een powerpoint. Maar wel als er al een tastbaar product staat.
  • Het ontwikkelen van een MVP is simpeler dan een uitgebreider product.
  • Het is makkelijker nieuwe features toe te voegen. 
  • Je kunt aannames snel testen bij de gebruikersgroep en dan bevestigen ofwel onderuit halen.

Hoe bepaal je wat er in een MVP moet zitten?

Wanneer je een idee hebt ben je vaak heel erg enthousiast over van allerlei dingen die er echt in moeten komen. Het doel van een MVP is om te kijken naar welke dingen echt essentieel zijn. Het scheiden van de must-haves en de nice-to-haves. 

Om er achter te komen wat er in een MVP moet zitten is het verstandig om in gesprek te gaan met de gebruikers: welke dingen hebben zij minimaal nodig om het product te kunnen en willen gebruiken.

Wat belangrijk is om te achterhalen is welk probleem jouw product oplost voor de gebruiker. Dan kun je ook makkelijker tot de kern wat er minimaal in een MVP moet zitten. Verdeel de gewenste features in diverse groepen: dingen die echt absoluut nodig zijn, dingen die wel fijn zouden zijn maar het gebruik niet blokkeert, en dingen die leuk zijn maar ook later kunnen of misschien wel geschrapt kunnen worden. Zorg dat vooral de eerste lijst erg kort is, zo kom je het snelste tot de kern.

Probeer vervolgens een beperkte groep mensen aan de slag te laten gaan met het product. Je kunt ze kiezen bijvoorbeeld op locatie (Uber begon eerst alleen in San Francisco bijvoorbeeld) of misschien heb je wel al een trouw groep fans die je nu ook al van feedback voorziet die je graag willen helpen. Verzamel de feedback en vooral: verwerk het ook!

Recente berichten