In een trial-and-error wereld, is degene die het snelst fouten kan vinden degene die wint. Sommige mensen noemen deze aanpak “fail fast”. Eric Ries noemde het Lean, terwijl Kent Beck en andere software-ontwikkelaars het Agile noemden.
Hoe je het ook noemt, het gaat erom uit te vinden welke aannames over het product fout zijn door zo snel mogelijk feedback van echte gebruikers te krijgen.
De agile methodologie veronderstelt het opdelen van de productontwikkeling in sprints, waardoor risico’s kunnen worden beperkt en snel kan worden gereageerd op vereiste veranderingen.
Omdat de agile methodologie is opgebouwd rond het idee van een iteratief proces op basis van feedback van de klant, speelt de MVP een centrale rol in agile ontwikkeling.
Het bouwen van een Minimum Viable Product (MVP) helpt bij het leveren van een nieuw product met voldoende functies om early adopters tevreden te stellen, waardoor waardevolle feedback kan worden verkregen, en het bouwen van een complete set van functies later.
Het MVP-concept wordt meestal beoefend in de software-industrie om de levensvatbaarheid van het product te controleren. Als u op zoek bent naar een bedrijf om de MVP te bouwen voor u, check out deze software development company.
De meerderheid van de software vandaag de dag wordt ontwikkeld met behulp van Agile methodologie. In de Agile-omgeving, hoor je vaak de uitdrukking minimum viable product (MVP).
Deze term betekent eenvoudigweg: het meest minimaal uitgeruste ding dat je kunt bouwen dat de gelegenheid goed genoeg zal aanpakken voor de meeste van je doelklanten en je markt en product zal valideren.
Met andere woorden, als u nadenkt over de kernfunctie die u uw klanten wilt laten vervullen, wat is dan het eenvoudigste product dat u kunt bouwen waarmee ze dat doel kunnen bereiken?
Stel dat u teruggaat in de tijd en werkt aan de eerste versie van een app voor een krant. De kernfunctie van een app zou het informeren van het lezerspubliek zijn. Daarom zou het eenvoudigste product dat je zou kunnen bouwen een lijst met nieuwskoppen zijn en een knop om te verversen.
Opnieuw, de sleutel tot een succesvolle MVP is zich te concentreren op de kernwaarde die de app biedt, namelijk vers nieuws, in plaats van uw tijd te besteden aan het bouwen van extra functies van de app.
Merk op dat MVP niet betekent dat het product slecht moet zijn. De waarheid is dat het heel goed moet zijn in wat het doet, maar het moet zich richten op het doen van slechts een paar kernfuncties.
In een notendop, de belangrijkste kenmerken van MVP zijn:
- Het heeft genoeg waarde dat mensen bereid zijn om het in eerste instantie te gebruiken of te kopen
- Het toont genoeg toekomstige voordelen om early adopters te behouden
- Het biedt een feedback loop om toekomstige ontwikkeling te sturen
Waarom zou je een Agile methodologie moeten gebruiken om de MVP te ontwikkelen?
Een belangrijk verschil tussen Agile en andere methodologieën is dat Agile gebruikmaakt van MVP’s. Met een Agile-aanpak bouwt u het eenvoudigste ding dat u kunt, verzamelt u gegevens over hoe klanten het gebruiken, en verfijnt u vervolgens het product indien nodig.
Hierdoor kun je heel effectief werken, waarbij je alleen de functies bouwt die klanten willen en zullen gebruiken, in plaats van tijd te verspillen aan het bouwen van dingen waar klanten niet om geven.
Zet dit af tegen niet-MVP-gebaseerde benaderingen van productontwikkeling. Bij andere benaderingen besteed je misschien veel tijd aan het bouwen van het “perfecte” product met alle functies die je je maar kunt voorstellen, maar als het eenmaal in de echte wereld staat, ontdek je dat klanten de helft van de functies die je dacht dat ze zouden gebruiken, niet gebruiken.
Hier volgt een voorbeeld van een agile minimum viable product (MVP):
Bron: Dropbox
Drew Houston – de CEO van Dropbox, besloot een MVP te maken voor de cloud-storage startup in de vorm van video.
Ze maakten een explainer-video en deelden die met hun netwerk om de reacties van mensen te peilen. De 3 minuten durende video legde uit wat Dropbox is en liet zien hoe het mensen zou helpen.
Na het vrijgeven van de video, verhoogde het bedrijf het aantal inschrijvingen van 5.000 mensen naar 75.000 in een nacht voor de “vroege toegang” – dit alles zonder een daadwerkelijk product te hebben.
De belangrijkste voordelen van het bouwen van een MVP (agile) zijn dus:
- Initieel consumentenonderzoek
Hoe sneller het product de beoogde gebruiker bereikt, hoe sneller u feedback krijgt en de uitdagingen of voorkeuren van de klant analyseert. Als de gebruikers uw MVP niet waardevol vinden, hebt u ruimte om te pivotten en de andere waardeproposities te testen.
Of, als het tegenovergestelde waar is, weet je zeker dat ontwikkelde functies nuttig zijn voor doelklanten, zodat je verder kunt gaan. In het slechtste geval kunt u het project bevriezen om uw verliezen te beperken.
- Testfase
Het grootste voordeel van het ontwikkelen van een MVP is dat hiermee verschillende bedrijfsmodellen en concepten kunnen worden getest.
Door een kernset functies aan te bieden in plaats van een product met veel functies, kunt u verifiëren of hun productconcept resoneert met uw bedrijfsmodel, waardoor u de mogelijkheid hebt om de richting van een product te wijzigen op basis van de bevindingen.
In tegenstelling tot feature-heavy producten, wanneer de MVP is gelanceerd, zult u de mogelijkheid hebben om te identificeren welke soorten sociale groepen de meest actieve gebruikers zijn, hoe ze omgaan met het product, en hoe u het te gelde kunt maken.
- Kostefficiëntie
De kwaliteitsproducten zijn het resultaat van jarenlange ontwikkeling, met een passend prijskaartje. Maar omdat deze producten iteratief over een langere periode tot stand zijn gekomen, zijn de kosten over de tijd uitgesmeerd.
De MVP-aanpak helpt ook om te besparen door te voorkomen dat het product te ingewikkeld wordt. Naarmate het product meer tractie krijgt en meer informatie verzamelt over de richting waarin het product zich beweegt, kunt u uw investeringen verhogen of verlagen.
Als u geïnteresseerd bent om meer te leren over Agile en SCRUM-methodologieën, raden we u aan dit artikel van het SCRUM Institute te bekijken over hoe u een SCRUM-master wordt in een gedetailleerd stapsgewijs proces. Zij bieden ook de meest populaire, en de meest economische Scrum Certificeringsprogramma’s wereldwijd.
Het proces van het bouwen van de MVP (Agile)
Nu, als je eenmaal weet wat een MVP is, waarom het wordt gebruikt in Agile, en wat de voordelen ervan zijn, laten we eens kijken naar de 6 stappen die nodig zijn voor het bouwen van een MVP.
Stap # 1: Identificeer Welk Probleem Je Oplost en Voor Wie
Bij het ontwikkelen van een versie van nieuwe producten zijn de meeste mensen niet voldoende rigoureus in het definiëren van de problemen die ze proberen op te lossen en het verwoorden waarom die problemen belangrijk zijn. Zonder dit proces kan het product kansen missen en middelen verspillen. Daarom moet je beter worden in het stellen van de juiste vragen, zodat ze de juiste problemen aanpakken.
Bekijk uw productidee en vraag uzelf het volgende af:
- Wie is uw doelgroep?
Als u in dit stadium vastloopt, probeer dan uw persoonlijke uitdagingen te identificeren. Is er iets dat u beter zou kunnen doen als u het juiste gereedschap had?
- Waarom heeft uw doelgroep dit product nodig?
Dit zal u helpen het hoofddoel van uw product en de oplossing voor de behoeften van uw potentiële klanten te identificeren.
- In welke situatie zouden ze het gebruiken?
Bron: Metabeta
Notitie: Bij het vaststellen van de antwoorden op bovenstaande vragen is het belangrijk om alles reëel te houden en daarnaast tijd- en kostenramingen te maken.
Stap #2: Analyseer uw concurrenten
Zodra u weet welk probleem u oplost, is het tijd om te kijken hoe andere bedrijven dit probleem oplossen – of in ieder geval proberen op te lossen. Op dit punt is het duidelijk dat je een concurrentie-analyse uit te voeren als er soortgelijke producten op de markt.
U moet ook in gedachten houden dat zelfs als je niet denkt dat je hebt geen directe concurrenten, uw geloof in de uniciteit van uw product zal grond voor vol vertrouwen uw product op de markt te brengen.
Stap #3: Definieer de gebruikersstroom, Wireframe & Ontwerp
Het definiëren van de gebruikersstroom voor uw toekomstige product houdt in dat u zich direct richt op uw primaire doel. Om de belangrijkste gebruikersstroom te definiëren, moeten we eerst de processtappen definiëren, wat eigenlijk eenvoudig is omdat u alleen maar de stappen hoeft uit te leggen die nodig zijn om het primaire doel van uw product te bereiken.
Op dit punt moet u niet denken aan functies – maar moet u zich richten op basistaken, zoals de soorten doelen die uw eindgebruikers hebben wanneer ze uw product gebruiken, hun verwachtingen, enz.
Als u klaar bent met het definiëren van de gebruikersstroom, kunt u overgaan tot wireframing, wat simpelweg een illustratie is van een webpagina of een app. Een wireframe is een lay-out waarin wordt beschreven welke interface-elementen een plaats krijgen op belangrijke pagina’s.
Wireframing Voorbeeld:
Het ontwerpen van de gebruikersinterface (UI) brengt concepten van interactieontwerp, visueel ontwerp en informatiearchitectuur samen. Hier moet u profiteren van wat u in de vorige fasen hebt geleerd om een ervaring te produceren die de eindgebruiker zal verrassen en verrukken.
Wanneer we bij Cleevio het eerste prototype klaar hebben (meestal een aanklikbare mock-up), voeren we gebruikerstests uit. Het testen van gebruikers is essentieel voor het succes van de nieuwe app. Als we de resultaten van de gebruikers testen klaar hebben, itereren we de wireframes en testen we ze opnieuw op de gebruikers.
Nadat de wireframes zijn getest, ga je naar de ontwerpfase die voor elk platform (iOS, Android, Web,…) anders moet zijn.
Stap #4: Analyseer je functies
Wist je dat meer dan 45% van de functies die in softwareproducten zijn ingebouwd, zelden of nooit worden gebruikt?
Nu u uw gebruikersstroom hebt gemaakt, kunt u beginnen met het maken van een meer gedetailleerde lijst van functies voor elke specifieke fase, maar met de statistieken in gedachten.
Als je eenmaal hebt gelegd uw functies voor elke fase, moet je om ze te prioriteren. Wat is de belangrijkste actie die u wilt dat uw gebruikers te voltooien? Dit wordt je belangrijkste functie.
Een van de functie prioritering methoden is MoSCoW die wordt gebruikt om te beslissen welke functies eerst te voltooien, die moeten later komen en welke uit te sluiten. Een andere techniek die wordt gebruikt om de noodzaak van de functies te meten is gebaseerd op de bedrijfswaarde (tijd om te ontwikkelen vs. nice to have vs. kosten)
Bron: ProductPlan
Stap #5: Ontwikkeling & Testen
Nu u de functies van uw minimum viable product (MVP) kent, is het tijd om ze in de praktijk te brengen. Verhuizen naar de ontwikkelingsfase, moet u uw product te testen en te werken aan de verbetering van de kwaliteit.
Na goedkeuring van de Wireframes, moet u beginnen te werken aan de setup-architectuur, database en beginnen met het ontwikkelen van API, Administratie, en alle back-end.
Alpha en beta testen kan hier helpen als een van de meest populaire manieren om de prestaties van een product te testen in verschillende scenario’s. Zorg ervoor dat u het testen op elkaar afstemt en alleen de wijzigingen aanbrengt die van invloed zijn op de gehele gebruikerservaring.
Als standaard moet u de volgende tests uitvoeren in een gecontroleerde omgeving voordat de app wordt gelanceerd:
- Functionaliteitstests
- Gebruikbaarheidstests
- Compatibiliteitstests
- Interfacetests
- Prestatietests
- Veiligheidstests
Tijdens het ontwikkelproces moet u alle geïmplementeerde functies voortdurend testen.
Bij Cleevio bouwen we bijvoorbeeld mobiele apps, en releases van beta builds worden geüpload naar Google alpha/beta testing en naar Apple’s TestFlight. Interne test builds zijn in Appcenter (een officiële tool van Microsoft).
Wanneer de “release candidate” (een product dat klaar is voor de markt) klaar is, doen we open of gesloten betatests, waarbij we zoveel mogelijk relevante gebruikers uitnodigen in het betatestprogramma en we feedback verzamelen over functionaliteit en bugs.
Stap #6: Iteratief naar product-markt fit of fail
Als je de MVP valideert, kun je beginnen te kijken naar de reikwijdte van je product en uitbreiden. Op dit punt moet u ofwel startkapitaal aantrekken om u te helpen sneller op de markt te komen, of falen.
Voor een mobiele app doen we meestal een “soft launch” wanneer we de MVP vrijgeven aan AppStore en Google Play, maar moedigen we op dit moment geen marketing van de app aan.
Als de app meer gebruikers krijgt, kunnen er bugs opduiken en we zijn er zeker van om alles ASAP te repareren. Normaal gesproken brengen we om de dag nieuwe builds uit. Zodra de app stabiel is en we hebben een crash-vrij gebruikerspercentage meer dan 99,9%, raden we aan om te beginnen met marketing en meer gebruikers te werven.
Data is echt belangrijk en dat is waarom we raden het monitoren van het gedrag van gebruikers met Mixpanel of Google Firebase analytics, zodat we kunnen begrijpen hoe gebruikers zijn echt het gebruik van de app.
De ontwikkeling van het product is nooit af. Heel belangrijk is om de feedback van de gebruiker te vragen en het product te itereren. Als we meer gebruikers hebben, voeren we A/B-tests uit om verschillende oplossingen te kunnen testen en de betrokkenheid van gebruikers te vergroten.
Bron: ProductPlan
Conclusie
Bij Cleevio hebben we in de afgelopen 10 jaar meer dan 120 MVP’s ontwikkeld, dus we hebben genoeg ervaring om te weten welke MVP’s schalen en welke verbranden en sterven.
We weten dat het een beetje overweldigend is om een roadmap, documentatie, of wireframes voor je MVP idee voor te bereiden, dus voel je vrij om contact met ons op te nemen en we geven je graag gratis advies.
Voor een adviesgesprek over je MVP email ons op [email protected] .