hur man verkligen definierar en MVP
Varför kan MVP vara förvirrande?
MVP är en av termerna som verkar generera mycket dragkraft under en smidig omvandling. Det verkar människor är glada över att försöka göra ’precis tillräckligt’ för att uppnå ett mål. Men, för företag med en fast tänkesätt termen kan få snabbt missbrukas. För dessa företag, fokus ligger vanligtvis på att leverera ’vad utlovades’ snarare än att bygga upp en djupare förståelse för hur man konkurrerar.
i dessa miljöer kan MVP: er ofta användas för att motivera en minskning (och kanske till och med brist) i omfattning. De är normalt bara om att sätta ett språk av minimalism så’ verksamheten ’få något de är desperat letar efter, och’ det ’ har några minimum av omfattning kontroll. Med en enda definition av en MVP saker blir alltför fast. Resultatet är att kunden reduceras till att vara en eftertanke med fokus på att leverera vad som är ’överenskommet’ på förhand snarare än vad som verkligen krävs.
för att lägga till förvirringen har det genom åren funnits många olika definitioner av minsta funktionella/livskraftiga/marknadsförbara/acceptabla funktioner/produkter/utgåvor. Det som verkar vara trevligt är att göra det minsta. Problemet är dock att det inte finns några verkliga policyer inom företag för att definiera hur MVP: er Kan användas till större effekt i ett ramverk som hjälper till att hantera och styra risker.
för att verkligen räkna ut vad det minsta som krävs är, måste vi gå på en upptäcktsresa och lärande.
MVP: er handlar om att lära sig
definitionen av en MVP bör verkligen alltid relateras till ett resultat – ”denna MVP är utformad för att uppnå x”. Det finns ingen enskild definition av en MVP. Vi kan till exempel skapa en MVP för att se om vår produkt löser ett specifikt problem för en specifik kund. Eller vi kan skapa den minsta möjliga produkten för att starta ett globalt fenomen. Dessa två saker är helt olika och kräver mycket olika strategier för att uppnå målet – och förmodligen en annan förvaltnings-och styrningsstrategi.
vad vi vet är att det finns några vanliga saker som organisationer försöker uppnå, så att vi kan lägga lite struktur kring språket för lärande och upptäckt.
att gå på en kund upptäckt resa
den brittiska regeringens Digital Services Team (GDS) skrev en utmärkt ram för hur statliga tjänster bör utformas och byggas – du kan se det här. Detta ramverk har utformats särskilt för brittiska statliga tjänster och skapa lösningar för medborgarna som baserades på att lära användarna verkliga behov och distribuera lösningar som bättre betjänas användare.
ett liknande ramverk fungerar lika bra i en Produkthanterings-eller Förändringshanteringsmiljö. Vi kan titta på det tillsammans med Steve Blanks customer Discovery-strategi för produkt-och affärsutveckling som i slutändan handlar om att hitta produkt/Marknadspassning och bygga en skalbar affärsmodell.
denna modell är utformad för att upptäcka, validera och skapa nya kunder och sedan leda dig till företagsbyggnad när du är säker på att du har produktmarknaden passform.målet med ramverket är att utveckla förståelse och lära genom att utforma steg som hjälper till att svara på specifika frågor.
Discovery
Discovery handlar om att utveckla en förståelse för din kund och de verktyg, produkter och tjänster de använder idag för att uppnå sina mål. Om du tror att du har något som bättre löser deras problem måste du göra ett par saker:
- rama in ett problem som du löser för, och få klarhet om huruvida detta är ett värdefullt problem att lösa
- beskriv alternativ för hur du kan lösa problemet
- utforska marknaden för vad som finns idag för att uppnå målet – ta reda på vad dina konkurrenter redan gör.
- se Steg 1. Att utforma ett riktigt bra problemförklaring är det mest kritiska objektet innan du går vidare.
Du kan behöva bygga något här för att hjälpa till att rama problemet väl. Vad du än gör, bygg inte för mycket. Håll saker väldigt lätta, väldigt snabba och bygg bara saker som hjälper till att utveckla en gemensam förståelse mellan dig och potentiella kunder om problemutrymmet.
Alpha
Alpha handlar om att designa något som uppnår problemlösning. Så du har ett väldefinierat problem uttalande. Och några ideer om hur man löser det. Du förstår vad andra gör på marknaden. Du misstänker att det finns värde i att arbeta med en lösning och det finns en marknad för människor som kommer att spendera lite pengar. När du bygger din lösning (eller lösningar eftersom det är okej att bygga många prototyper parallellt eller seriellt) måste du hålla fokus på att svara på några viktiga frågor:
- tror du att din potentiella lösning faktiskt löser problemet du har definierat (och din kund har beskrivit som värdefull)?
- har du någon kundvalidering – har några kunder sagt att din föreslagna lösning hjälper dem att lösa problemet de har?
- är dina användare beredda att betala för din lösning? I detta skede, tror du att det kan bli en livskraftig verksamhet?
- är din lösning annorlunda än dina konkurrenter? Är det tydligt för andra att det är differentierat?
- och innan du går vidare, löser det verkligen problemet? Det behöver verkligen innan du spenderar pengar på att förvärva kunder och användare.
Beta
i detta skede har du validerat din lösning med riktiga kunder. De borde ha varit människor som verkligen representerar de personer du vill tjäna. Du vet att din ide fungerar-åtminstone för en liten befolkning. Men är det lätt att marknadsföra, hitta och förvärva kunder och tjäna en mer varierad grupp. Beta handlar om att hitta produktmarknaden passform. De frågor som är till hjälp för dig att bygga lösningar på i detta skede är:
- gör din lösning skala för att möta behoven hos de många? Hur kan du lösa problemet på ett sätt som är ekonomiskt lönsamt?
- hur positionerar och marknadsför du ditt lönsamma värdeförslag?
- vilka kanaler kan vara bäst för att förvärva och betjäna din målmarknad?
- Hur skapar du den bästa upplevelsen (ur ett försäljnings-och leveransperspektiv)?
- vilka andra funktioner kan behövas för att få människor att evangelisera om din produkt?
- Vad är rätt blandning av förvärv, remiss och retention investering?
- hur strukturerar jag bäst team och operationer för att tjäna en lansering?
- vilka är mina nyckelindikatorer för tillväxt? Hur vet jag om produkten inte fungerar så bra som jag vill? Eller, hur vet jag att det finns något nytt som konkurrerar med mitt värdeförslag?
Live
bra! Så du har skapat ett antal minsta livskraftiga produkter. Du har lärt dig mycket. Du har förmodligen itererat dig igenom Discovery, Alpha och Beta, och du är redo att göra din produkt till ett globalt fenomen (eller vad ditt mål är). Du letar nu efter den livskraftiga affärsmodellen som kommer till liv. I detta skede handlar det om kontinuerlig förbättring av allt du gör. Nya funktioner, förbättrade leveransmodeller, ökad kundbas. Det handlar om mer av samma – men ständigt förbättras.
gå i pension
nu, förhoppningsvis under Beta och Live har du räknat ut de viktigaste mätvärdena för att hjälpa dig att träna om du störs av något annat på marknaden. Dessa bör innehålla några ledande indikatorer som inte bara handlar om intäkter och vinst. Förhoppningsvis kommer de att ge dig signaler om att produkten fortfarande utför eller behöver uppmärksamhet. En del av din tävling kommer att kunna hanteras genom kontinuerlig förbättring – det är troligt om du verkligen hade produkt/marknad passform. Men ibland kommer en ny sak att slå dig av din abborre. Vid den punkten måste du nu överväga att gå i pension och starta processen igen. Det är tillbaka till Discovery att åter betjäna dina kunder och användare, och på att gå i pension för den lösning som du så kärleksfullt växte.
inramning bra MVP: er
så, för att begränsa detta är det värt att säga ett par andra saker. Du kan (och kanske säkert borde och kommer) ha många iterationer av MVP i varje steg i inlärningsprocessen. Det viktiga är att lära sig, få svar på dina frågor och ta reda på när det är bäst att flytta till nästa skala. När som helst kan du ställa frågan om du ska fortsätta med din ide, svänga till något helt nytt eller skrota hela ideen. Vanligtvis, om problemförklaringen var väl inramad i början kommer det att finnas värde att gå efter oavsett hur bra lösningar fungerar, men det är inte alltid fallet.
var försiktig med att hoppa direkt till ett senare skede utan att svara på tidigare frågor. Sträva alltid efter att bygga bevis och få validering. Och, vara uppmärksam att inte hoppa till standard svaret på ’endast en produkt med varje funktion kommer att behövas för vår MVP så att vi kan skala till våra företag behöver’. Det är förmodligen det största misstaget att använda MVP i stora företag.
Kom ihåg att en MVP är ett fordon för lärande. Det är en del av en upptäcktsprocess och ett sätt för dig att utveckla djupare insikter i det problem du löser för. Det hjälper dig att bygga den mest önskvärda, livskraftiga och genomförbara produkten som möjligt. Tänk på det när det gäller sätt att rama in ett mål som är en delmängd av det största målet. Även när du är i ett stort företag finns det alltid sätt att bryta ner saker för att bygga, lära och testa.