Ontwikkeling van Minimuum Viable Product: laat het onderweg niet zakken

Tech startups komen bij ons met het idee op basis van wat ze al weten. Maar de feedback van de klant dwingt hen om te draaien en zich constant aan nieuwe gegevens aan te passen.

Elke tech startup heeft een idee dat kan uitgroeien tot een product waar velen van houden. Veel startups komen naar Moqod met een duidelijk idee van wat ze willen en wat voor soort probleem ze oplossen. Zodra de kern is gevormd, kan men doorgaan met het aanbieden van het concept op de markt door een MVP omheen te bouwen.

Er zijn enkele manieren waarop we je kunnen helpen je zakelijk idee tot leven te wekken. In dit artikel bied ik de optimale aanpak vanuit onze ervaring en een pragmatisch perspectief (meest prijs-kwaliteitsverhouding).

# MVP is gelijk aan iteratief

Een MVP is een van de meest gebruikte woorden in de startup wereld. Volgens Wiki “Het is een kern artefact in een iteratief proces van het bedenken van ideeën, prototypen, presentatie, het verzamelen van gegevens, analyse en leren.” Ik benadruk het woord “iteratief”, omdat de kernwaarde van MVP onder deze definitie ligt.

In een ideale wereld wil je zo meteen een MVP krijgen zoals je het had bedacht. En wat nog belangrijker is, de overtuiging dat de manier waarop je je het voorstelde, is precies wat je startende bedrijf nodig heeft. In werkelijkheid wordt het proces herhaald totdat een gewenst product-market fit is verkregen of totdat het product als niet-levensvatbaar wordt beschouwd. Soms kan het zelfs op een plek terechtkomen die niemand zou kunnen verwachten (denk aan de bekende YouTube pivot case?).

Met een MVP sla je hypothetisch twee vliegen in één klap. Ten eerste kun je zien hoe goed je idee in de praktijk is. Ten tweede bespaar je nogal wat tijd en geld op ontwikkeling in plaats van te investeren in een volwaardig product.

Er zijn een paar manieren waarop je aan de slag kunt met een MVP. Laten we verder eens kijken hoe ze voldoen aan ons verzoek om iteratief.

# Doe het zelf

Afhankelijk van de complexiteit van het idee en je zaakkennis, kun je overwegen om zelf een MVP te bouwen. Als je op deze manier snel market fit kunt bewijzen, ga ervoor! We hebben deze aanpak al nader beschreven in het artikel, waar we een aantal tools in  hebben aanbevolen voor het bouwen van je MVP zonder codering.

# Huur je eigen ontwikkelaars in

Het inhuren van een team (maakt niet uit of er één of meerdere ontwikkelaars zijn) begint bij het juiste wervingsproces. Daarnaast gaat het gepaard met het stellen van duidelijke verwachtingen, het opzetten van business en communicatieprocessen, het zorgen voor hetzelfde niveau van motivatie, het hooghouden van de geest, het behouden van teamleden, enz. Het proces is zo ingewikkeld dat het vereist dat het grondig wordt behandeld in afzonderlijke artikelen (zonder de kostenkwesties te vermelden, die we hier gedetailleerd hebben beschreven).

Nadat je mensen hebt aangenomen, ben je voortaan verantwoordelijk voor de werknemers en niet meer vrij in je beslissingen. Je moet ermee rekening houden als je verder wilt gaan met je startup of wilt terugkeren naar je vorige leven. Denk eraan dat je nu beperkt bent in de technische vaardigheden van je nieuwe team. Dus als marktfeedback meldt dat je je op de andere sets met tools moet richten, zou je dan ook een ander team moeten inhuren?

# Laat het aan een leverancier

Je kunt er ook voor kiezen om het hele MVP-ontwikkelingsproject aan een leverancier toe te vertrouwen. Startups komen vaak naar leveranciers zoals Moqod en willen meteen een MVP lanceren.

In de wereld van softwareontwikkeling noemen we dit type aanpak “projectmatig”, omdat het start- en einddatums heeft, duidelijke scope, kenmerken, functies en de vooraf overeengekomen prijs. Je houdt toezicht op het project, terwijl het wordt geïmplementeerd, maar je hoeft niet na te denken over ontwikkelingsprocedures, je hebt het allemaal meteen voor elkaar. Wat kan er met dit bijna ideale overzicht misgaan?

# Waarom projectmatige opdrachten mislukken voor MVP’s

Weet je nog, we zijn dol op iteratie?

Startups komen naar ontwikkelaars met het idee dat gebaseerd is op de kennis. Dit is volkomen natuurlijk: we nemen allemaal altijd onze beslissingen op basis van de gegevens die we op dit moment hebben, zowel in ons werk als privéleven.

Hoewel een bedrijfseigenaar zeker is van de behoeften van zijn klant, blijken we heel vaak (eerlijk gezegd, bijna altijd) NIET onze ideale klant te zijn. Dan gaat het project verder, komt er meer informatie binnen en wijkt van het oorspronkelijke idee af. Met een vast aantal uren, prijs en deadline kan dit werkproces voor iedereen hevige hoofdpijn worden.

Zelfs als je begint met het heronderhandelen over de uren en verdere verfijningen, doe je dat nog steeds gesteund door de kennis die je op dit moment beheerst. Hoewel het misschien gemakkelijk lijkt om de ontwikkelaar te vragen ‘X te verwijderen en Y toe te voegen’, maar toch is het proces achter het scherm niet zo eenvoudig.

Je kunt het achterwiel van je auto vervangen zonder de werking van het voorwiel te verstoren. Je kunt de ene functie echter niet door een andere vervangen zonder de ontwikkeling in de weg te staan. Bijna alle taken zijn verweven met technologieën, kaders, deadlines en andere nuances. Een simpele wijziging kan langer duren dan het lijkt. Als je direct een wijziging wilt aanbrengen, is het moeilijk te voorspellen hoe het eruit zal zien met betrekking tot uren en geld, omdat de ontwikkelaars het moeten aanpassen aan het bestaande project.

Zelfs als je die wijzigingen aanbrengt (en betaalt voor extra uren), kun je bij het lanceren van de gereed-MVP nog steeds een weigering van de markt krijgen en moet je je snel aanpassen aan nieuw verworven kennis.

In onze praktijk komt dit, omdat dit model mogelijk flexibiliteit mist (nogmaals, iteratie is een koning.) Nieuwe projecten en startende bedrijven vereisen altijd de betrokkenheid van de eigenaar. Jouw MVP is geen uitzondering – hoe minder je betrokken bent, hoe meer je MVP van de behoeften van de markt afwijkt. Het idee zelf is niet de sleutel tot succes, maar de implementatiemethode wel. En jij bent de enige die de kijk hebt hoe dat moet.

In de realiteit is er geen enkele MVP perfect vanaf het begin  – niets is perfect. Op je MVP kun je de wet van Pareto toepassen, waar 20% van het werk 80% van de resultaten oplevert. Beter kant-en-klaar dan perfect!

Wat als we een meer flexibele aanpak zouden voorstellen?

# Laat een bekwaam team het bouwen

Laten we meteen aannemen dat het uiteindelijke product niet uitkomt zoals je het in je hoofd zag. Je krijgt een toegewijd team met de nodige samenstelling van technische vaardigheden om onder je toezicht aan je MVP te werken, waarbij jij de eigenaar en de manager (ontwerper, marketeer, bedrijfsontwikkelaar, tester – noem maar op) van het product bent. Hoe is het eenvoudiger dan de vorige oplossingen?

Volgens onze ervaring is het vaak de beste manier om zaken te doen, omdat hij zo agile mogelijk is. Op zo’n manier neem je minder risico bij het testen van je idee op de markt, omdat het werk in sprints van twee weken (soms zelfs een week) wordt gedaan. Aan het begin van de sprint legt het team de scope van de taken vast en beoordeelt uiteindelijk het resultaat met de klant. Voor een nieuwe business is het veel effectiever dan de resultaten binnen 3-5 maanden proberen te evalueren. Kortere sprints laten ruimte voor effectievere en nauwkeurigere aanpassingen.

We zouden je MVP in kleinere taken verdelen met behulp van de MoSCoW-methode. We beginnen met de belangrijkste taken en passen de backlog stapsgewijs samen met de klant aan op de nieuwe data. Op deze manier schat je de resultaten degelijk in, in plaats van voortijdig in te schatten. Je  kunt de hypothese testen en valideren met behulp van productstatistieken. Als je project wordt gelanceerd, is het ook een geweldige opstap om naar financiering te zoeken in plaats van te wachten tot het perfect is.

Deze aanpak laat beide partijen zich te concentreren op productontwikkeling in plaats van extra uren en veranderingen te bespreken.