Verwijder het vet/elimineer de essentie?

Te vermijden fouten bij het bouwen van uw MVP

Het doel van de MVP (Minimum Viable Product) is primair klantgedreven in plaats van productgedreven. 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 met 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 met de minste inspanning de maximale hoeveelheid gevalideerde informatie over klanten kan verzamelen.”

Uitbestede productontwikkeling

Dit idee werd bijna onmiddellijk favoriet bij ontwikkelaars toen de technische industrie een hoge vlucht nam en de barrières voor productontwikkeling werden verlaagd. Productontwikkelaars en ontwerpers hadden nu een raamwerk om nieuwe producten snel op de markt te krijgen. Bedrijven hielden van de mogelijkheid om een uitgekleed product te presenteren, het te testen met echte klanten en het succes ervan 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 probleem van het hoogste niveau van klanten op te lossen. Ontwikkelaars profiteerden van de voordelen om tijd en geld te besparen en vrijwel onmiddellijk feedback te krijgen.

Ontwikkelaars en ontwerpers gebruiken MVP als een excuus om te bezuinigen, functies te verwijderen en UI/UX op te offeren in de naam van “slank blijven”. Ze creëren uiteindelijk een product dat niet concurrerend is en veranderen het kernidee door een functie te vervangen door iets dat gemakkelijker te implementeren is.

Dus wat zijn de fouten die moeten worden vermeden bij het gebruik van deze duurzame aanpak 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 standaard en geavanceerde functies te implementeren. Je zult begrijpen dat je in de goede richting 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, kunt u de focus verliezen op de prestaties en de werkelijke levensvatbaarheid van het product. Toen het begon, verbond Uber iPhone-bezitters eenvoudig met automobilisten en werd het alleen gebruikt door de oprichters en hun vrienden. Vandaag laat Uber een hele evolutie zien van het primaire idee, waardoor gebruikers gemakkelijk de taxi kunnen boeken en 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 van de tijd hadden gebouwd.

Feedback en statistieken negeren

Een belangrijk doel van een MVP is het genereren van feedback om het eindproduct beter te maken. Toch hebben ontwikkelaars de neiging om feedback die u van gebruikers en testers hebt ontvangen, te negeren. Vergeet niet dat u uiteindelijk uw product voor gebruikers maakt en dat hun feedback van cruciaal belang is. Feedback helpt u de gebruiker beter te begrijpen, uw product aan te passen aan de behoeften van de klant en de perceptie van uw product door het publiek te meten. Zorg er ook voor dat u analyses zoals dagelijks actieve gebruikers, retentiepercentage en gemiddelde tijd besteed aan het gebruik van het product, implementeert in het platform waarop uw product is ondergebracht om een idee te krijgen van uw MPV-succes.

Een MVP bouwen als dat niet nodig is

Dit is een fout die verrassend veel startups vaak maken. Ze beginnen hun MVP te bouwen zonder enig onderzoek en creëren uiteindelijk een product dat al bestaat voor een markt die meestal al overvol is. Niet elk zakelijk idee is puur innovatief en disruptief. Als gevolg hiervan verspillen ze uiteindelijk tijd, geld en moeite aan iets dat misschien niet de verwachte resultaten oplevert of gerichte klanten verleidt. In plaats van haast te maken met het ontwikkelen van een MVP die de functies van uw concurrenten repliceert, moet u eerst uw bedrijfsidee valideren en een product maken dat 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 wel het meest opwindende waargenomen voordeel van het ontwikkelen van een MVP is 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 eenvoudig kunnen navolgen. Sparkly-functies en andere franje en toeters en bellen zullen uw product niet succesvol maken. Het vereist een geweldige zakelijke propositie en veel iteratieve inspanning.

Om Eric Ries zelf te citeren: Ondanks de naam gaat MVP niet over het maken van minimale producten. Als het je doel is om gewoon een duidelijke jeuk te krabben of iets te bouwen voor een snelle flip, dan heb je de MVP echt niet nodig. In feite is MVP behoorlijk vervelend, omdat het extra overhead met zich meebrengt. We moeten erin slagen iets te leren van onze eerste productiteratie. In veel gevallen kost dit veel energie die wordt geïnvesteerd in het praten met klanten of metrics en analytics.”

Marketingstrategie negeren

Een andere veelgemaakte fout die de meeste ondernemers in de val laat lopen en struikelt die denken dat alles wat ze nodig hebben om een product succesvol te laten zijn, een uniek en fantastisch idee is dat vanzelf zal adverteren en populair zal worden. Maar zonder een goede marketingstrategie is elke MVP gedoemd te mislukken, tenzij deze op de juiste manier op de markt wordt gebracht en gepromoot.

Verkeerde of ondergeschoolde ontwikkelaars krijgen

Zou je een beul inhuren om het werk van een kapper te doen? Of een geschiedenisprofessor vragen om kwantumfysica te doceren? Beiden hebben hetzelfde beroep en beschikken over vaardigheden, maar zijn ze het juiste talent? Aan de andere kant, terwijl u extra voorzichtig bent bij het aannemen van goed gekwalificeerde nieuwe werknemers, waarom zou u iemand vragen die niet gekwalificeerd genoeg is om uw MVP op te bouwen? In het beste geval zullen ze erg creatief blijken te zijn en er op de een of andere manier in slagen 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 terug te brengen naar het begin. Het bouwen van een MVP vereist een professioneel team van ontwerpers, ontwikkelaars, QA-ingenieurs en projectmanagers met bekwame vaardigheden en in staat om binnen een strikte tijdlijn een goed product te leveren.

De verkeerde projectmanagementstijl kiezen

Waterfall en Agile zijn de twee meest populaire projectmanagementmethoden. Als het gaat om MVP-ontwikkeling, is het belangrijkste verschil hoe vaak u uw product aan gebruikers gaat leveren. In tegenstelling tot Agile is het Waterfall-model een strikte opeenvolging van ontwikkelingsfasen en is het alleen mogelijk om naar de volgende fase te gaan als de vorige volledig is voltooid. Deze aanpak is misschien niet de beste optie, omdat je competitief moet blijven en de lanceringstijd in gedachten moet houden bij het bouwen van een MVP. Daarnaast zorgt Agile voor meer transparantie. U kunt zien hoeveel tijd er aan de verschillende fasen is besteed en wat de resultaten zijn. Het is een meer flexibele aanpak waardoor u de richting van uw project kunt wijzigen wanneer u maar wilt. Het belangrijkste is dat in de Agile-aanpak de MVP wordt gedeeld met alle belanghebbenden en dat hun feedback wordt verwerkt in toekomstige iteraties.

De verkeerde tech-stack kiezen

Voordat je een MVP maakt, is het erg 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 cake zal zijn. U bespaart ook tijd en geld, omdat de juiste tech-stack u helpt om fouten te minimaliseren. Uw MVP en later uw product zijn gemakkelijker te onderhouden en te schalen als het oorspronkelijk op de juiste technische stapel is gebouwd.

Conclusie – Is uw product levensvatbaar of waardevol?

Vraag uzelf af, voordat u overgaat tot de productie van uw MVP: wat maakt uw product uniek? Welke problemen lost het op? Wie zijn de beoogde klanten en waarom? Dit is belangrijk omdat een MVP niet alleen een verkleind product is waarbij enkele functies zijn weggelaten, of een manier om het product iets eerder de deur uit te krijgen. De MVP hoeft helemaal geen product te zijn, vooral als je maar één keer gaat bouwen en dan de klus overweegt.

Denk aan MVP is een proces dat je herhaalt. Wanneer u een product ontwikkelt, maakt u veel aannames, zoals waar gebruikers naar op zoek zijn, hoe het ontwerp zou moeten werken, welke marketingstrategie u moet gebruiken, welke architectuur u moet gebruiken, strategie om inkomsten te genereren, enz. Ken uw 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 Odeo-podcastplatform. Maar toen Apple iTunes lanceerde, realiseerden de oprichters zich dat ze van strategie moesten veranderen omdat ze nooit zouden kunnen concurreren met de gigant. Een van hun ideeën was om een platform te creëren dat de mogelijkheid bood om updates te delen met een groep mensen met behulp van eenvoudige sms-berichten met de codenaam ’twttr’. En zo werd Twitter geboren.

Hoe goed uw team ook is, sommige van uw aannames kunnen onjuist zijn. Het probleem is dat je niet weet welke en dat is het doel van een MVP.