Het vet eruit snijden/de essentie verwijderen?

Fouten die je moet vermijden bij het bouwen van je MVP

Het doel van MVP (Minimum Viable Product) is vooral klantgestuurd in plaats van productgestuurd. Het begint met het opstellen van een bedrijfshypothese en deze vervolgens te valideren door van klanten te leren en uit te zoeken wat klanten wel of niet willen. Het MVP-idee ontstond jaren geleden bij Frank Robinson en werd later gepopulariseerd door Eric Ries in zijn Lean Startup beweging in de jaren 2000. Volgens Ries is een MVP: “De versie van een nieuw product waarmee een team de maximale hoeveelheid gevalideerde kennis over klanten kan verzamelen met de minste inspanning.”

Uitbestede productontwikkeling

Dit idee werd vrijwel meteen favoriet bij ontwikkelaars toen de tech-industrie een hoge vlucht nam en de drempels voor productontwikkeling lager werden. Productontwikkelaars en ontwerpers hadden nu een raamwerk om nieuwe producten snel op de markt te brengen. Bedrijven vonden het prettig om een gestript product te kunnen laten zien, het te testen met echte klanten en het succes op de markt te meten zonder een volledig ontwikkelde oplossing te bouwen. En hier begint misschien het probleem. MVP had in plaats van een minimaal “levensvatbaar” product een minimaal “waardevol” product moeten worden genoemd, omdat een MVP verkeerd werd geïnterpreteerd als iets met de minste functies die nodig zijn om alleen het bovenste probleem van klanten op te lossen. Ontwikkelaars genoten van de voordelen van het besparen van tijd en geld en van het vrijwel onmiddellijk krijgen van feedback. Ontwikkelaars en ontwerpers gebruiken MVP als excuus om te bezuinigen, functies te verwijderen en UI/UX op te offeren in de naam van “slank blijven”. Uiteindelijk maken ze een product dat niet concurrerend is en veranderen ze het kernidee door een functie te vervangen door iets dat eenvoudiger te implementeren is. Welke fouten moet je vermijden als je deze duurzame aanpak gebruikt, die bedrijven verleidt met zijn onbetwistbare voordelen?

Streven naar perfectie

Het idee van MVP is om klanten een voorproefje te geven van het toekomstige product, zonder alle functies, standaard en geavanceerd, te implementeren. Je zult begrijpen dat je de goede kant op gaat, zelfs als de MVP wordt gelanceerd met slechts een paar functies. Door een “cool ontwerp” en mooie functies toe te voegen aan de MVP, kun je de focus verliezen op de prestaties en de daadwerkelijke levensvatbaarheid van het product. Toen Uber begon, verbond het simpelweg iPhone-eigenaars met chauffeurs en werd het alleen gebruikt door de oprichters en hun vrienden. Vandaag de dag laat Uber een hele evolutie zien van het primaire idee, waarbij het voor gebruikers eenvoudig is om een taxi te reserveren en te betalen via de app. Ze haastten zich nooit om de apps vol te proppen met knoppen en animaties en bleven gefocust op het ontwikkelen van de kernfuncties die ze in de loop der tijd opbouwden.

Feedback en statistieken negeren

Een belangrijk doel van een MVP is het genereren van feedback om het uiteindelijke product beter te maken. Toch hebben ontwikkelaars de neiging om feedback van gebruikers en testers te negeren. Vergeet niet dat je je product uiteindelijk maakt voor gebruikers en dat hun feedback cruciaal is. Feedback zal je helpen om de gebruiker beter te begrijpen, om je product aan te passen aan de behoeften van de klant en om de perceptie van je product door het publiek te meten. Zorg er ook voor dat je analytics zoals dagelijkse actieve gebruikers, retentiegraad en gemiddelde gebruikstijd van het product implementeert in het platform waar je product op staat om een idee te krijgen van het succes van je MPV.

Een MVP bouwen als het niet nodig is

Dit is een fout die verrassend veel startups vaak maken. Ze beginnen hun MVP te bouwen zonder enig onderzoek en maken uiteindelijk een product dat al bestaat voor een markt die meestal al overvol is. Niet elk bedrijfsidee is puur innovatief en ontwrichtend. Het gevolg is dat ze uiteindelijk tijd, geld en moeite verspillen aan iets dat misschien niet de verwachte resultaten oplevert of de beoogde klanten versteld doet staan. In plaats van overhaast een MVP te ontwikkelen die de functies van je concurrenten kopieert, moet je eerst je bedrijfsidee valideren en een product maken dat nog niet bestaat of op zijn minst extra functies heeft die uniek zijn en de gebruikerservaring kunnen verbeteren.

Snelkoppelingen gebruiken om er snel te komen

Misschien is het meest opwindende voordeel van het ontwikkelen van een MVP wel het “snel rijk worden” dat eraan verbonden is, hoe onnauwkeurig ook. Succesverhalen van startups als Airbnb en Dropbox geven ondernemers het idee dat ze hun succes gemakkelijk kunnen kopiëren. Sprankelende functies en andere frutsels en toeters en bellen zullen je product niet succesvol maken. Het vereist een geweldig zakelijk voorstel en veel iteratieve inspanning. Om Eric Ries zelf te citeren: MVP, ondanks de naam, gaat niet over het maken van minimale producten. Als je gewoon een duidelijke jeuk wilt wegkrabben of iets wilt bouwen voor een snelle flip, dan heb je de MVP echt niet nodig. In feite is MVP heel vervelend, omdat het extra overhead met zich meebrengt. Het moet ons lukken om iets te leren van onze eerste product iteratie. In veel gevallen vereist dit dat er veel energie wordt gestoken in gesprekken met klanten of in statistieken en analyses.”

Marketingstrategie negeren

Een andere veelgemaakte fout is dat de meeste ondernemers denken dat alles wat ze nodig hebben om een product succesvol te maken, een uniek en fantastisch idee is dat vanzelf reclame maakt en populair wordt. Maar zonder een goede marketingstrategie is elke MVP gedoemd te mislukken als hij niet op de juiste manier op de markt wordt gebracht en gepromoot.

Verkeerde of ondergeschoolde ontwikkelaars

Zou jij een beul inhuren om het werk van een kapper te doen? Of een geschiedenisprofessor vragen om les te geven in kwantumfysica? Beiden hebben hetzelfde beroep en beschikken over vaardigheden, maar zijn het wel de juiste talenten? Aan de andere kant, terwijl je extra zorg besteedt aan het aannemen van goed gekwalificeerde nieuwe werknemers, waarom zou je iemand vragen die niet gekwalificeerd genoeg is om je MVP te bouwen? In het beste geval blijken ze heel creatief te zijn en slagen ze er op de een of andere manier in om het grootste deel van de taak te voltooien, waarbij de kwaliteit natuurlijk in het gedrang komt. In het ergste geval verspillen ze je tijd en moeite om je weer terug bij af te brengen. Het bouwen van een MVP vereist een professioneel team van ontwerpers, ontwikkelaars, QA-engineers en projectmanagers met bekwame vaardigheden die in staat zijn een goed product af te leveren binnen een strikte tijdlijn.

De verkeerde projectmanagementstijl kiezen

Waterval en Agile zijn de twee populairste projectmanagementmethoden. Bij MVP ontwikkeling is het belangrijkste verschil hoe vaak je je product gaat leveren aan gebruikers. In tegenstelling tot Agile, is het Watervalmodel een strikte opeenvolging van ontwikkelingsfasen en is het alleen mogelijk om naar de volgende fase te gaan als de vorige volledig is afgerond. Deze aanpak is misschien niet de beste optie, omdat je concurrerend moet blijven en de lanceringstijd in gedachten moet houden bij het bouwen van een MVP. Bovendien zorgt Agile voor meer transparantie. Je kunt zien hoeveel tijd er in de verschillende fasen is gestoken en wat de resultaten zijn. Het is een flexibelere aanpak waardoor je de richting van je project kunt veranderen wanneer je maar wilt. Het belangrijkste in de Agile aanpak is dat de MVP wordt gedeeld met alle belanghebbenden en dat hun feedback wordt verwerkt in toekomstige iteraties.

De verkeerde technologie kiezen

Voordat je een MVP maakt, is het heel belangrijk om vanaf het begin de juiste tech stack te kiezen, omdat dit een solide basis vormt voor toekomstige verbeteringen. Simpel gezegd: hoe beter de ingrediënten die je gebruikt, hoe lekkerder je taart zal zijn. Je zult ook tijd en geld besparen, omdat de juiste technologie je helpt om fouten tot een minimum te beperken. Je MVP en later je product zullen gemakkelijker te onderhouden en op te schalen zijn als ze oorspronkelijk gebouwd zijn op de juiste tech stack.

Conclusie – Is je product levensvatbaar of waardevol?

Vraag jezelf af – Wat maakt jouw product uniek voordat je je MVP in productie neemt? Welke problemen lost het op? Wie zijn de beoogde klanten en waarom? Dit is belangrijk omdat een MVP niet zomaar een verkleind product is met wat functies eruit geknipt, of een manier om het product iets eerder de deur uit te krijgen. De MVP hoeft helemaal geen product te zijn, vooral als je het maar één keer gaat bouwen en de klus dan als geklaard beschouwt. Beschouw MVP als een proces dat je herhaalt. Wanneer je een product ontwikkelt, doe je veel aannames zoals wat gebruikers zoeken, hoe het ontwerp moet werken, welke marketingstrategie je moet gebruiken, welke architectuur je moet gebruiken, monetisatiestrategie enz. Ken je meest riskante aanname, zoek het kleinst mogelijke experiment om die aanname te testen en gebruik de resultaten van het experiment om de koers te corrigeren. Twitter was bedoeld als het podcastplatform van Odeo. Maar toen Apple iTunes lanceerde, realiseerden de oprichters zich dat ze van strategie moesten veranderen omdat ze nooit met de gigant zouden kunnen concurreren. Een van hun ideeën was om een platform te creëren dat de mogelijkheid bood om updates te delen met een groep mensen door middel van eenvoudige tekstberichten met de codenaam “twttr”. En zo werd Twitter geboren. Hoe goed je team ook is, sommige aannames kunnen verkeerd zijn. Het probleem is dat je niet weet welke en dat is het doel van een MVP.