Hoe te werken met MVP's (minimaal haalbare producten)

Laten we het hebben over MVP's (Minimum Viable Products) en hoe u als productmanager of gebruiker van gebruikerservaringen kunt werken met strakke deadlines en budgetten terwijl u toch een geweldig product levert.

Wat is een MVP?

Je bent waarschijnlijk eerder het acroniem MVP tegengekomen - bijna zeker als je in de technische industrie werkt - en ondanks dat het een controversieel drieletterwoord is, is een MVP waarschijnlijk een van de belangrijkste stappen op weg naar het bouwen van een geweldig product. Het belangrijkste doel van het verzenden van een minimaal haalbaar product moet altijd zijn: "het tegenover klanten plaatsen om uw aannames te valideren".

Als een team moet je je sterke punten verzamelen en je richten op het creëren van een gedeeld begrip van de bedrijfsvisie en -doelen. U moet het probleem dat u probeert op te lossen identificeren en uitzoeken hoe u zich wilt organiseren om zo snel mogelijk te leren wat klanten echt willen en hoe zij u kunnen helpen deze doelen te bereiken.

The Donut Analogy

Toen ik in klassen over MVP's begon te praten, zou ik de analogie gebruiken van een eenvoudige gewone donut (dat zou mijn MVP zijn) en een donut vol met chocolade, hagelslag en alle goedheid die mogelijk is (een latere versie van het product). 

MVP en latere iteratie? Donut pictogrammen van Diana Toma

Tegenwoordig, hoe meer ik werk met teams en het concept van MVP, vooral nu ik een Product-rol heb, merk ik dat ik deze analogie in vraag stel. Het bouwen van MVP's om aannames te valideren, kan in feite betekenen dat je verkeerd was om mee te beginnen, en de volgende iteratie is zelfs geen donut; misschien is het een eenvoudige wafel ?! Toegegeven, het zou nog steeds duidelijk zijn, en je zou opnieuw het validatieproces moeten doorlopen, maar het zou niet langer een donut zijn.

Dus ... Wat is geen MVP?

Hiervoor ga ik een illustratie lenen van Henrik Kniberg, waarin wordt uitgelegd wat een MVP is moet niet worden.

door Henrik Kniberg

Henrik beschrijft twee verschillende benaderingen die dezelfde visie delen: een auto. Als het probleem dat u nu probeert op te lossen transport is, zou u als klant dan ergens met een band willen gaan? Absoluut niet met een band, maar zeker met een skateboard.

Henrik verdedigt de agile, incrementele manier om producten af ​​te leveren, maar stelt dat elke iteratie een bruikbaar / testbaar product moet zijn. Het is duidelijk dat een skateboard nog lang geen auto is, maar je hebt je klanten in ieder geval veel eerder in het proces en feedback laten gebruiken, zodat je kunt beginnen met leren en nadenken over de volgende iteratie.

Je moet niet veel tijd besteden aan het kijken naar ontwerp of het technisch zo goed maken - je wilt het niet perfect maken om mee te beginnen, maar in plaats daarvan moet je net genoeg bouwen om je zakelijke hypothesen te valideren.. 

Kortom, een MVP is niet ...

  • Een product dat vanaf dag één niet door klanten of early adopters kan worden gebruikt en getest.
  • Een product dat u en uw team niet toestaat om aannames te leren en te valideren.
  • Een product dat geen problemen van klanten oplost (of probeert op te lossen).

In dit artikel

In dit artikel behandelen we de volgende onderwerpen: ze geven u enkele hulpmiddelen om te beginnen nadenken over wat uw MVP moet zijn:

  • Focussen op het oplossen van klantproblemen
  • Strategisch werken aan het bouwen van een MVP om mee te beginnen
  • Het belang van taggen
  • Leren met gegevens en inzichten
  • iteratie

Focussen op probleemoplossing

Uiteindelijk moet uw hoofddoel bij het bouwen van producten altijd het oplossen van de problemen van klanten zijn. Als u hun problemen niet oplost en u brengt niets nieuws dat past in hun dagelijkse routine, dan zullen ze uw product waarschijnlijk niet gebruiken. Met de golf van ontwerptechnieken verwerven UX-teams hulpmiddelen om klanten te leren kennen en tot op de bodem uit te vinden wat ze eerder in het proces willen.

Er zijn een aantal technieken die jij en je team kunnen gebruiken om je klanten te leren kennen en te begrijpen hoe je problemen kunt oplossen:

  • Focusgroepen. Als u een nieuw product bouwt, nodig dan een groep mensen uit die de producten van uw concurrenten gebruiken en vraag hen naar pijnpunten, plus dingen die ze echt leuk vinden, en probeer een goed inzicht te krijgen in wat ze zouden veranderen en waarom . Als u een bestaand product wilt verbeteren of een nieuwe functie wilt toevoegen, waarom dan niet uw eigen klanten uitnodigen en hen dezelfde vragen stellen? Focusgroepen zijn een goede start voor het ontwikkelen van een goed begrip van wat uw klanten van uw product willen, maar houd er rekening mee dat focusgroepen een beetje bevooroordeeld kunnen zijn; er is altijd iemand met heel sterke meningen die anderen kunnen beïnvloeden, dus je moet proberen te lezen tussen de regels door.

  • Ideeringsworkshop. Verzamel je team (inclusief belanghebbenden) en stel enkele van de gevonden pijnpunten bloot. Je moet ook zoveel proberen te printen als je tot nu toe hebt geleerd over de gedefinieerde visie en bedrijfsdoelen en deze op de muren vastzetten zodat iedereen ze duidelijk kan zien. Vraag in deze sessies iedereen om zoveel mogelijk oplossingen te schetsen voor de problemen die je probeert op te lossen. U bent op zoek naar kwantiteit, niet naar kwaliteit.

  • Prototyping en gebruikerstesten. Idealiter moet je minstens een keer per week een prototype maken. Tegenwoordig zijn UX-teams wendbaarder en hebben UX-ontwerpers de neiging om meer tijd te besteden aan het schetsen en testen van papieren prototypes of low-fidelity-wireframes dan langere tijd achter een computer te zitten die alleen beslissingen neemt. Laat je UX-team zo vroeg mogelijk in het proces prototypes gebruiken om sappige feedback van gebruikers te krijgen. Guerrilla-testen is een geweldige en effectieve manier om vroege ontwerpen te testen en het kost bijna geen inspanning.

Strategisch werken aan het bouwen van een MVP om mee te beginnen

Dus je hebt veel getest terwijl je probeerde de beste oplossing te ontwerpen. Je hebt wekelijkse guerrilla-sessies gehouden, je hebt je ontwerpen naar het lab gebracht en je bent ervan overtuigd dat je op de goede weg bent.

Toch, zelfs als je alleen hebt getest met gebruikers van je product, is dit een klein percentage van je publiek, en ze waren onderworpen aan een testomgeving (nauwelijks neutraal). Testen met klanten eerder in het proces is van onschatbare waarde, maar u zult uw product daar voor een groter publiek willen testen.

Strategisch werken aan het bouwen en lanceren van een minimaal levensvatbaar product is de beste manier om uw aannames te valideren en verder te bouwen op wat u tot nu toe hebt geleerd.

Een goede manier om na te denken over uw MVP is om te kijken naar de roadmap die u in vorige sessies hebt opgebouwd en aandacht te besteden aan dingen die klantproblemen oplossen.

Zodra u dit hebt gedaan, stelt u de vraag: wat kan ik bouwen met de minimale inspanning die me helpt dit product te valideren?

Dit is waar ik nog steeds moeite mee heb: mijn UX-hart (lichaam en ziel) zegt me altijd om te proberen er zoveel mogelijk uit te halen. Ik wil een naadloze ervaring opbouwen vanaf dag één, voor elke gebruiker.

Als eigenaar van een product, met een strakke deadline en een budget voor mijn handen, wil ik net genoeg bouwen om te zorgen dat we het goede opbouwen, en ik geloof echt dat dit een goed product is.

Het belang van tagging

Niets. Kan uitgaan. Zonder te taggen. 

Nou, we hebben het al eerder gezegd, toch? Het doel van het bouwen van een MVP is leren en herhalen. Er is geen manier om te leren (ik bedoel werkelijk leren) met uw klanten, tenzij u een systeem hebt waarmee u kunt volgen wat klanten doen met uw product. U hebt die kostbare gegevens nodig om weloverwogen beslissingen te nemen. Je kunt kwalitatief onderzoek doen en je klanten vragen wat ze van je product vinden, maar we weten dat dit misschien niet genoeg is.

U moet ervoor zorgen dat u tags aan uw MVP toevoegt, zodat u beter begrijpt hoe uw product presteert ten opzichte van uw KPI's (Key Performance Indicators) en meet uw aannames.

Analytische (of tracking) tags worden vaak geleverd door externe leveranciers zoals Google Analytics om ons product (website, mobiele app) te helpen integreren met hun trackingtools. Tracking-tags zijn niet meer dan een stukje code dat u moet insluiten in de broncode van uw product om alle acties van klanten die u wilt volgen, te verzenden en het u gemakkelijker maken om gegevens te visualiseren.

Laten we zeggen dat u wilt bijhouden hoe vaak op een bepaalde knop wordt geklikt; de provider vraagt ​​u om een ​​gebeurtenistag aan de broncode van de knop toe te voegen om ervoor te zorgen dat een tag naar zijn tool wordt gestuurd telkens wanneer een klant op die knop klikt. Hun tool registreert deze actie vervolgens samen met andere acties die u definieert om u een gedetailleerd beeld te geven van wat klanten doen met uw product.

Er is een reeks hulpmiddelen die u kunt gebruiken om uw klanten online te volgen. Begin met het kiezen van de juiste keuze voor u en uw zakelijke behoeften en neem contact op met hun klantenservice om hulp te krijgen bij het bouwen van tags in uw product:

  • Adobe Omniture (Adobe Marketing)
  • Mouseflow (opnamen, heatmaps, trechters)
  • Google Analytics
  • Optimizely (u kunt dit gebruiken voor experimenten met A / B of Multivariant testen, die ik verderop in dit artikel zal bespreken)

Leren met gegevens en inzichten

Zodra tracking is ingevoerd en uw MVP is uit, kunt u beginnen te kijken naar wat uw klanten doen met uw product.

Als u nieuw bent bij Analytics, zijn er een paar dingen die u kunt doen om uw hoofd rond gegevens te krijgen en waar u naar moet kijken. Google heeft een paar introductievideo's om je op weg te helpen en je kunt ook het boek Lean Analytics lezen. Deze zullen u helpen bruikbare statistieken te begrijpen en wat te doen met de gegevens die u krijgt.

Als u bij toeval het geluk heeft een team te hebben dat is toegewijd aan inzichten in uw bedrijf, kunnen zij u helpen de gegevens nog beter te begrijpen! Ze zullen waarschijnlijk in staat zijn rapporten te maken met de belangrijkste statistieken die u wilt volgen om uw leven gemakkelijker te maken.

Wat ook de middelen zijn om deze gegevens bij u te krijgen, het hele team moet er toegang toe hebben. U moet het allemaal hebben over de uitkomsten en wat de toekomst biedt voor uw product. Hoe is de klanttevredenheid? Stuurt het de doelen die je hebt gesteld?

Als het antwoord ja is, dan is geweldig nieuws! Je eerdere aannames hadden gelijk en je hebt geweldig werk geleverd. Als uw MVP daarentegen niet de meetwaarden drijft die u verwachtte, begrijp dan waarom en ben het eens over wat u vervolgens zou moeten doen (zeg ook genade dat u hebt besloten om een ​​MVP te starten voordat u tonnen aan middelen en geld toewijst aan een product dat niet zo succesvol zou zijn geweest als u aanvankelijk dacht dat het zou zijn).

Multivariant testen

Als uw klantenbestand goed genoeg is, moet u A / B- of Multivariant-testen stimuleren. Hiermee kunt u gedurende de hele levenscyclus van uw product verschillende varianten testen en ervoor zorgen dat u deze statistieken blijft gebruiken.

U kunt uw interface aanpassen en zien wat het beste werkt voor uw klanten. Probeer kleine wijzigingen, zoals het wijzigen van de kopie van een titel of een knopkleur, en laat twee versies van uw product naast elkaar lopen om de resultaten te analyseren. Je zou ook een interface volledig kunnen veranderen; Optimizely is slechts één voorbeeld van een tool waarmee u deze experimenten kunt uitvoeren. Stel de parameters in die u wilt testen en het percentage klanten dat u de nieuwe versie van uw pagina of product wilt laten zien en volg de resultaten.

Ga vooruit en herhaal!

Het wordt tijd dat je begint te itereren en bouwen op wat je al hebt. Idealiter wordt uw routekaart nu geprioriteerd, en op een manier die u voortdurend productstappen kunt vrijgeven. Dit is het juiste moment om je team te mobiliseren om na te denken over de volgende druppel.

Onthoud dat elke iteratie van uw product bruikbaar moet zijn (de "levensvatbare" in MVP). Het moet trachten uw aannames te valideren of aan te vechten, en op een manier die u meetbare gegevens oplevert. Veel succes met het gebruik van MVP's in uw workflow voor productontwikkeling!