Wil jij een minimal viable product maken of laten maken? Of je nu op zoek bent naar een mvp prototype, een mvp app of een mvp product we gaan graag met je in gesprek. We hebben dit artikel alvast voor je geschreven om je op weg te helpen als je je nog aan het verdiepen bent. Wil je al aan de slag, dan maken we graag contact.
Minimum Viable Product (MVP): Wat is het en hoe gebruik je het bij de ontwikkeling van een app?
Goede software ontwikkelen is doorgaans en relatief lang process en brengt daardoor een hoge investering met zich mee. Als we het hebben over investeren in een app als startup dan is dit een risicovolle investering. Je hebt immers veel tijd en geld gestoken in een applicatie die tot op dat moment nog niet beschikbaar was voor je beoogde gebruikers. Hoogstwaarschijnlijk heb je flink wat onderzoek gedaan naar de wensen van de klant en de product market fit, echter weet je op dat moment nog niet of je idee ook echt aanslaat in de markt.
Zou het niet mooi zijn als je het idee dat je hebt alvast te kunnen valideren bij je beoogde gebruikers? En zodoende, waar mogelijk, vroegtijdig bij te kunnen sturen? Daarbij ook nog eens de initiële investering een stuk lager houden?
Hier komt de MVP om de hoek kijken.
Wat betekent MVP ontwikkeling precies?
Een Minimum Viable Product (MVP) is een versie van een product met net genoeg functionaliteiten om bruikbaar te zijn voor de eerste klanten. Deze eerste groep aan gebruikers kan bijvoorbeeld een beperkte set aan (potentiële) klanten zijn of early adopters in het geval je een compleet nieuwe technologie ontwikkeld.
Hoe bepaal je wat in de MVP moet zitten?
Een van de moeilijkste aspecten tijdens de ontwikkeling van een MVP is bepalen wanneer “genoeg, genoeg is”. De volgende stelregels kan je gebruiken voor het bepalen van de benodigde development werkzaamheden:
Het MVP moet de “core features” bevatten en niets meer. Dit betekend dat je alle randzaken en niet essentiële buiten beschouwing laat. Om tot deze lijst aan features te komen zou je de MOSCOW methode kunnen gebruiken.
Het ontwerp en user experience (UX) moet aan de laatste standaarden voldoen. Een MVP zonder fatsoenlijk ontwerp/UX zal weinig kans van slagen hebben. Een ondermaats ontwerp zal afleiden van de core functionaliteit.
De app dient bugvrij te zijn In lijn van het punt hierboven: Bugs en offline servers leiden gebruikers af in het gebruik/testen van de applicatie.
Welk doel dient een MVP?
Een MVP heeft meerdere doelen. In de basis gaat het om 2 aspecten: product validatie en kosten reductie. Doordat je een product zo snel mogelijk op de markt brengt kan je direct starten met het verzamelen van feedback en zodoende een beter beeld vormen of de applicatie potentieel winstgevend kan worden. Doordat het product eerder op de markt verschijnt is er een kleinere investering nodig.
Voor de product validatie (ook wel Product Market Fit genoemd) is het van belang om als bedenker/ontwikkelaar in goed contact met de eerste groep gebruikers te blijven. Deze groep kan de ontwikkelaars voorzien van feedback voor verdere doorontwikkeling. Vaak zien we dat er tijdens het gebruik van een MVP applicatie veel ideeën voor nieuwe features ontstaan. Deze features hebben mogelijk wel of juist geen plek in verdere doorontwikkelen, of vragen juist om een andere doelgroep of marketing aanpak.
Ook helpt het in goed contact blijven met de eerste gebruikers om bij een succesvolle product validatie te begrijpen wat er verbeterd kan worden aan de app, of welke nieuwe features het belangrijkste zijn om als eerste op te pakken. Hierdoor worden niet onnodig development resources gestoken in features welke later niet of weinig gebruikt gaan worden. Hierdoor is het dus mogelijk om naast op een kosteneffectieve manier een app te lanceren ook de doorontwikkeling direct efficiënter in te richten.
MVP en SCRUM / Agile?
Een applicatie ontwikkelen door middel van een MVP past zeer goed binnen een werkmethode als SCRUM/Agile software development. Immers binnen de SCRUM methodiek (Bij Cell[0] ontwikkelen wij onze software projecten dmv van SCRUM sprints) werk je in sprints aan de belangrijkste features en lever je aan het einde van de sprint werkende software op. In meer traditionele development trajecten wordt na elke sprint een oplevering gedaan op interne omgevingen zodat de klant (een gedeelte) van de software kan testen. Herhaal dit proces vaak genoeg en uiteindelijk kan het volledige product opgeleverd worden. Echter kan de product development roadmap zo ingericht worden dat er in een vroeger stadium al een MVP opgeleverd kan worden. Na deze oplevering kan dan feedback van daadwerkelijke gebruikers als input dienen voor de volgende sprints.
Zitten er ook nadelen aan een MVP?
Vanuit het perspectief van ons als developers niet. Echter zien we mogelijk enkele bezwaren vanuit de business kant:
Bij een te vroege release van je MVP met relatief weinig investeringen bestaat er de mogelijkheid dat concurrenten aan de haal gaan met je idee.
Ook in het geval van een te vroege release kan negatieve feedback op een MVP je reputatie als bedrijf schaden.
Naar ons idee zijn er voor beide issues oplossingen en komt het vooral neer op: wanneer en aan wie laat je de MVP zien? De kritiek op de MVP methode heeft ervoor gezorgd voor verschillende nieuwe methodes, zoals bijvoorbeeld de MVE (Minimum Viable Experiment) en MAP (Minimum Awesome Product). Met deze methodieken hebben wij echter (nog) geen ervaring.
Wij horen graag van je!
Heb jij een fantastisch idee voor een applicatie, zoek je advies of heb je een opmerking? Diede en Bertus gaan graag met je in gesprek!
