Zo ontwikkel je een MVP

Een Minimum Viable Product (MVP) laat zich het best omschrijven als een minimaal, werkbaar product: de meest basic, standaard en uitgeklede versie van jouw product of oplossing. De term is afkomstig uit The Lean Startup methode en draait erom dat je een antwoord krijgt op de enige vraag die er als founder, ondernemer of corporate toe doet: is er (voldoende) behoefte aan mijn oplossing, product, app of dienst?

Valideren klinkt lastiger dan het is. Om een idee te valideren, is een MVP – de minimale, werkbare versie van jouw idee – nodig. Vervolgens moet je in gesprek met jouw doelgroep. Vraag hen wat hun behoefte is en of ze aan jouw idee behoeften zouden hebben. Merk op dat het belangrijk is om niet al te sturende vragen te stellen, maar zoveel mogelijk vanuit open vragen te blijven werken. Vraag je doelgroep dan ook: ‘Overweeg je oplossing X?’ Deze vraag is niet heilzaam: ‘Aangezien je inziet dat je dit probleem niet zelf kunt oplossen, vroeg ik me af: wat zou je voor oplossing X willen betalen?’

# MVP

We ontwikkelen een MVP in samenwerking met de klant. Hiervoor is het nodig dat er voldoende informatie beschikbaar is, zodat er voor een lage prijs een product ontwikkeld kan worden dat voldoet aan de eisen om te valideren. Tegelijkertijd is er ruimte voor flexibiliteit: bepaalde specificaties, zoals hoe het design eruitziet, hoeven niet in beton gegoten te zijn. Het is niet voor niets een MVP: functionaliteiten moeten helder voor de gebruiker zijn, werkbaar zijn en ervoor zorgen dat er gevalideerd kan worden.

Dankzij snelle iteraties (herhaalde experimenten) valt er na het opleveren van een MVP te ontdekken welke zaken er geoptimaliseerd moeten of kunnen worden. Zodra deze kennis er is, stellen we ons flexibel op en optimaliseren we hetgeen er beter kan. Hierbij houden we uiteraard rekening met de roadmap. Dat is het strategische plan achter het idee, dat dikwijls gevangen is in een software-systeem (zoals Jira, de meest gebruikte variant, of Teamweek en Trello).

# PoC en MVP

Merk op dat we in dit artikel de term MVP gebruiken, maar dat deze informatie ook opgaat voor een Proof of Concept (PoC) – een andere vorm van de MVP. De PoC is de eerste versie van de beoogde technologie, dat fungeert als bewijs (proof) dat de oplossing daadwerkelijk functioneert. Een PoC wordt vaak gebruikt om een technologische oplossing te valideren en maakt vaak gebruik van derde partijen (zoals Firebase, Google Maps en andere sdk’s (software development kits) en apis) om snel tot een werkbare oplossing te komen. Hoewel de PoC ook aan de doelgroep gepresenteerd kan worden, wordt deze vaker gebruikt als showcase, een toonbaar voorbeeld voor eerste investeerders en klanten.

Een PoC verschilt met een MVP, doordat de MVP een verkoopbaar product is, waar je graag marketing- en sales-inspanningen op loslaat. Bij een MVP wordt er vaker rekening gehouden met de veiligheid, usercases en de roadmap van de technologie. Ook wordt een MVP in de regel vaker doorontwikkeld dan een PoC.

Het ontwikkelen van een MVP (of PoC) gebeurt in de volgende fases:

# 1: De intake

Tijdens een intake bespreken we hetgeen er ontwikkeld moet worden. Of het een app, website of andere (technische) oplossing betreft: we willen weten welk probleem er opgelost wordt met deze innovatie, welk doel het dient en welke afwegingen er gemaakt zijn. Misschien is er al een (verkennend) onderzoek onder (mogelijke) gebruikers geweest. Ook dit is input die van waarde kan zijn tijdens het ontwikkelen van een app, platform of site.

De intake draait om het delen van de juiste informatie, zodat het development-team aan de slag kan met de wensen die op tafel liggen. Daarnaast delen we feedback, aangezien we al jarenlang technische producten ontwikkelen. Dit betekent dat we je bevragen of deze oplossing echt aansluit op het probleem dat je tracht op te lossen. Dit is voor beide partijen een leerzaam proces; hiermee versterken we elkaar.

# 2: De definitie

Vanuit de intake, is het mogelijk om een definitie op te stellen. Hierin worden de Epics en Stories opgesteld. Dit betekent dat het proces concreet gemaakt wordt in kleinere definities: wat moet deze app bijvoorbeeld kunnen? En welke zaken zijn nodig om te zorgen dat dit werkt?

De definitie is daarin een essentieel onderdeel van het proces. Vanuit het ontwerp is het mogelijk om een overzicht te hebben van hetgeen ontworpen gaat worden. Alleen door afspraken te maken, kunnen deze nagekomen worden. Story Mapping is hierbij een uiterst geschikt middel.

# 3: Het development

Het ontwikkelen van een app of site kan op verschillende manieren georganiseerd worden. Enerzijds is het mogelijk om een dedicated team van ons af te nemen, dat op afstand werkt. Door hier bijvoorbeeld een Product Manager of -Owner op aan te laten sluiten, verlopen werkzaamheden soms vlotter. Anderzijds is het mogelijk om IT-talent naar Nederland te brengen en aan te laten sluiten in een team.

In dit eerdere bericht lees je meer over de manieren waarop je een development team kunt nearshoren. Als een paal boven water staat in elk geval dat het outsourcen van development loont. Ook het zelf samenstellen van een development-team is uitdagend en valt beter over te laten aan experts, zo blijkt uit ervaring.

# 4: De launch

De lancering van een MVP is een mooie milestone: je bent van concept naar de eerste versie van een oplossing gegaan. Daarmee heb je iets in handen om het gesprek met gebruikers aan te gaan. Hoewel de launch van een MVP enigszins ‘basic’ kan aanvoelen, is dat ook het uitgangspunt: het is een oplossing die voldoende inzicht biedt in de wensen en verwachtingen van potentiële klanten of gebruikers.

Het opleveren van de MVP, de zogeheten launch, gebeurt volgens Sprint Demo’s, waarbij het gedane werk gedemonstreerd wordt en de voortgang gemeten. Dit geldt natuurlijk ook voor de stappen die hierop volgen.

# Verschillende ontwikkelingsmogelijkheden van een MVP:

Er zijn verschillende manieren om een MVP te ontwikkelen. Uiteraard wordt er zo agile mogelijk gewerkt. Maar, afhankelijk van de use-case kunnen er eenvoudig bepaalde ‘shortcuts’ genomen worden zoals:

–    Een moderne agile techniek: back-endless. Dit is een methode die draait om het gebruik de cloud. Er is geen fysieke back-end, waarin de applicatie, platform of site gebouwd wordt, maar deze is online en continu beschikbaar – en daardoor wendbaarder. Bijvoorbeeld het gebruik van online realtime databases van Amazon, Azure of Google.

–   Serverless is een andere moderne Agile techniek. Hierbij betaal je als gebruiker niet voor ongebruikte serverruimte, aangezien er geen deployment, lifecycle management of andere DevOps taken nodig zijn. Voorbeelden zijn bijvoorbeeld gebruik makend van Amazon Lambda.

–   We maken gebruik van veel libraries en frameworks. Er zijn veel zaken beschikbaar die ontwikkeling eenvoudiger maken. Een app van een MVP zouden we bijvoorbeeld sneller kunnen maken met een hybrid framework.

–   Er wordt gekeken naar welke open-source zaken al beschikbaar zijn op het internet.  Er zijn veel kleine deeloplossingen beschikbaar op het internet. Waarom het wiel opnieuw uitvinden?

–   Tot slot bestaat er een hybride vorm. Dit is uiteindelijk ook een schaalbare oplossing, maar het is een iets robuustere en veilige methode. Dit maakt het erg geschikt voor enterprise en fintech-oplossingen (die met strengere bankwetgeving te maken krijgen).

# Kosten ontwikkeling mvp

Uiteraard brengen de verschillende technische producten ook verschillende kostenplaatjes met zich mee. Een MVP valt al te ontwikkelen vanaf 5000 Euro – wat de ontwikkeling van een idee tot een startup een stuk toegankelijker maakt. Bij de ontwikkeling van een app moet gedacht worden aan een bedrag vanaf 10.000 Euro. Bij een platform of interactieve web-app is een som van 15.000 – 25.000 Euro een goede inschatting. Moqod kan ook helpen met het bekostigen van de MVP.