hoe definieer je echt een MVP

Waarom kan MVP verwarrend zijn?

MVP is een van de termen die veel tractie lijkt te genereren tijdens een Agile transformatie. Het lijkt erop dat mensen blij zijn om te proberen ‘net genoeg’ te doen om een doel te bereiken. Maar voor bedrijven met een vaste mindset kan de term snel misbruikt worden. Voor die bedrijven ligt de focus meestal op het leveren van ‘wat was beloofd’ in plaats van het opbouwen van een dieper begrip van hoe te concurreren.

in deze omgevingen kunnen MVP ‘ s vaak worden gebruikt om een vermindering (en misschien zelfs een gebrek) in scope te rechtvaardigen. Ze zijn normaal gesproken alleen over het instellen van een taal van minimalisme, zodat ‘de Business’ krijgen iets wat ze wanhopig op zoek zijn naar, en ‘het’ hebben een beetje van scope controle. Met een enkele definitie van een MVP worden dingen te gefixeerd. Het resultaat is dat de klant wordt gereduceerd tot een after-thought met de focus op het leveren van wat vooraf ‘overeengekomen’ is in plaats van wat echt nodig is.

om de verwarring nog te vergroten, zijn er in de loop der jaren veel verschillende definities gehanteerd van minimale functionele/levensvatbare/verhandelbare/aanvaardbare kenmerken/producten/releases. Het ding dat lijkt aangenaam is om het minimum te doen. Het probleem is echter dat er binnen bedrijven geen echt beleid wordt vastgesteld om te bepalen hoe MVP ’s effectiever kunnen worden gebruikt in een kader dat helpt risico’ s te beheren en te beheersen.

om echt uit te zoeken wat het minimum is dat nodig is, moeten we een ontdekkingsreis maken en leren.

MVP ‘ s gaan over leren

de definitie van een MVP moet eigenlijk altijd gerelateerd zijn aan een resultaat – “deze MVP is ontworpen om x te bereiken”. Er is geen enkelvoudige definitie van een MVP. We kunnen bijvoorbeeld een MVP maken om te zien of ons product een specifiek probleem voor een specifieke klant oplost. Of we kunnen het kleinst mogelijke product creëren om een wereldwijd fenomeen te lanceren. Deze twee dingen zijn totaal verschillend en vereisen zeer verschillende strategieën om het doel te bereiken – en waarschijnlijk een andere management en governance aanpak.

wat we wel weten is dat er een aantal gemeenschappelijke dingen zijn die organisaties proberen te bereiken, dus we kunnen een structuur plaatsen rond de taal van leren en ontdekking.

Going on a Customer Discovery journey

Het Digital Services Team (GDS) van de Britse overheid schreef een uitstekend raamwerk voor hoe overheidsdiensten moeten worden ontworpen en gebouwd – U kunt het hier zien. Dit framework is speciaal ontworpen voor Britse overheidsdiensten en het creëren van oplossingen voor burgers die waren gebaseerd op het leren van de gebruikers echte behoeften en het implementeren van oplossingen die gebruikers beter gediend.

een vergelijkbaar raamwerk werkt even goed in een productmanagement-of Verandermanagementomgeving. We kunnen kijken naar het naast Steve Blank ‘ s Customer Discovery benadering van product en business development die uiteindelijk over het vinden van Product/markt passen en het bouwen van een schaalbaar bedrijfsmodel.

Dit model is ontworpen om nieuwe klanten te ontdekken, te valideren en aan te maken, en u vervolgens naar de Bedrijfsopbouw te leiden zodra u zeker weet dat uw productmarkt geschikt is.

Het doel van het framework is het ontwikkelen van begrip en leren door het ontwerpen van stappen die helpen bij het beantwoorden van specifieke vragen.

Discovery

Discovery gaat over het ontwikkelen van inzicht in uw klant en de tools, producten en diensten die zij vandaag gebruiken om hun doelen te bereiken. Als je denkt dat je iets hebt dat hun probleem beter oplost, moet je een paar dingen doen.:

1. Frame een probleemverklaring waarvoor u aan het oplossen bent, en krijg duidelijkheid over of dit een waardevol probleem is om
2. op te lossen Beschrijf opties over hoe u het probleem zou kunnen oplossen
3. verken de markt voor wat er vandaag bestaat om het doel te bereiken – erachter te komen wat uw concurrenten al doen.
4. zie stap 1. Het opstellen van een echt goed probleem statement is het meest kritische punt voordat u verder gaat.

mogelijk moet u hier iets bouwen om het probleem goed te kunnen framen. Wat je ook doet, Bouw niet te veel. Houd dingen heel licht, zeer snel en alleen bouwen dingen die zullen helpen bij het ontwikkelen van een gedeeld begrip tussen u en potentiële klanten over het probleem-ruimte.

Alpha

Alpha draait allemaal om het ontwerpen van iets dat past bij een probleemoplossing. Dus je hebt een duidelijk omschreven probleemstelling. En wat ideeën over hoe het op te lossen. Je begrijpt wat anderen doen in de markt. U vermoedt dat er waarde zit in het werken aan een oplossing en er is een markt van mensen die wat geld zullen uitgeven. Terwijl u uw oplossing bouwt (of oplossingen omdat het goed is om veel prototypes parallel of serieel te bouwen) moet u gefocust blijven op het beantwoorden van enkele belangrijke vragen:

1. gelooft u dat uw potentiële oplossing het probleem oplost dat u hebt gedefinieerd (en uw klant heeft beschreven als waardevol)?
2. heeft u een klantvalidatie – hebben klanten u verteld dat uw voorgestelde oplossing hen helpt het probleem dat ze hebben op te lossen?
3. zijn uw gebruikers tot op heden bereid om voor uw oplossing te betalen? Denk je dat het in dit stadium een levensvatbaar bedrijf kan worden?
4. is uw oplossing anders dan uw concurrenten? Is het voor anderen duidelijk dat het gedifferentieerd is?
5. en voordat u verder gaat, lost dit het probleem echt op? Het is echt nodig om voordat u geld uitgeven aan het verwerven van klanten en gebruikers.

Beta

in dit stadium hebt u uw oplossing gevalideerd met echte klanten. Het hadden mensen moeten zijn die de persona ‘ s vertegenwoordigen die je wilt dienen. Je weet dat je idee werkt – tenminste voor een kleine bevolking. Maar is het gemakkelijk om klanten op de markt te brengen, te vinden en te verwerven en een meer diverse groep te bedienen. Beta is alles over het vinden van Product-markt Fit. De vragen die nuttig zijn voor u om oplossingen op te bouwen in dit stadium zijn:

1. kan uw oplossing schalen om te voldoen aan de behoeften van de vele? Hoe kun je het probleem oplossen op een manier die economisch levensvatbaar is?
2. Hoe positioneert en verkoopt u uw levensvatbare waardepropositie?
3. welke kanalen zijn het beste voor het verwerven en bedienen van uw doelmarkt?
4. Hoe creëer je de beste ervaring (vanuit een verkoop-en leveringsperspectief)?
5. welke andere functies kunnen nodig zijn om mensen te laten evangeliseren over uw product?
6. Wat is de juiste mix van acquisitie -, referral-en retentiebeleggingen?
7. Hoe kan ik teams en operaties het beste structureren om een lancering te bedienen?
8. Wat zijn mijn belangrijkste groeiindicatoren? Hoe kan ik weten of het product niet zo goed doet als Ik wil? Of, hoe Weet ik dat er iets nieuws is dat concurreert met mijn Value Proposition?

Live

geweldig! Dus je hebt een aantal minimale levensvatbare producten gemaakt. Je hebt veel geleerd. Je hebt waarschijnlijk iterated je weg door Discovery, Alpha en Beta, en je bent klaar om uw product een wereldwijd fenomeen (of wat je doel is). U bent nu op zoek naar het levensvatbare businessmodel dat tot leven komt. In dit stadium gaat het om voortdurende verbetering van alles wat je doet. Nieuwe functies, verbeterde leveringsmodellen, groter klantenbestand. Het gaat over meer van hetzelfde – maar voortdurend verbeterd.

Retireer

nu, hopelijk heb je tijdens Beta en Live de belangrijkste metrics gevonden om je te helpen uit te zoeken of je verstoord wordt door iets anders op de markt. Deze moeten een aantal toonaangevende indicatoren die niet alleen over inkomsten en winst. Hopelijk geven ze je signalen dat het product nog steeds presteert of aandacht nodig heeft. Sommige van uw concurrentie in staat zal zijn om te worden behandeld door continue verbetering – dat is waarschijnlijk als je echt had Product/markt Fit. Maar soms komt er iets nieuws langs om je van je stoel te slaan. Op het punt dat je nu moet overwegen om met pensioen te gaan en het proces opnieuw te starten. Het is terug naar Discovery om uw klanten en gebruikers opnieuw te bedienen, en op met pensioen te gaan voor de oplossing die u zo liefdevol groeide.

het framen van goede MVPs

dus, om dit af te sluiten is het de moeite waard om een paar andere dingen te zeggen. U kunt (en misschien moet en zal) vele iteraties van MVP ‘ s in elke fase van het leerproces. Het belangrijkste is om te leren, krijg antwoorden op uw vragen en erachter te komen wanneer het beste om naar het volgende niveau van schaal. Op elk moment kunt u de vraag stellen of u moet volharden met uw idee, draaien om iets volledig nieuw of schroot het hele idee. Typisch, als het probleem statement was goed omlijst aan het begin zal er waarde te gaan na ongeacht hoe goed oplossingen werken, maar het is niet altijd het geval.

wees voorzichtig om direct naar een later stadium te springen zonder eerdere vragen te beantwoorden. Probeer altijd bewijs op te bouwen en validatie te krijgen. En, wees er rekening mee om niet over te gaan naar het standaard antwoord van ‘alleen een product met elke functie zal nodig zijn voor onze MVP, zodat we kunnen schalen naar onze bedrijven nodig hebben’. Het is waarschijnlijk de grootste fout met behulp van MVP ‘ s in grote bedrijven.

onthoud dat een MVP een leermiddel is. Het is onderdeel van een ontdekkingsproces en een manier om dieper inzicht te krijgen in het probleem waarvoor je het oplost. Het helpt u de meest wenselijke, haalbare en haalbare product mogelijk te bouwen. Denk erover in termen van manieren om een doel dat is een subset van het grootste doel frame. Zelfs als je in een grote onderneming bent, zijn er altijd manieren om dingen af te breken om te bouwen, te leren en te testen.