Låt oss prata om MVP (Minimum Viable Products) och hur du som produktchef eller användarupplevelse professionell kan arbeta med snäva tidsfrister och budgetar samtidigt som du levererar en bra produkt.
Du har förmodligen kommit över akronymet MVP före - nästan säkert om du arbetar inom teknikindustrin - och trots att du är ett kontroversiellt tre bokstavsord, är en MVP förmodligen en av de viktigaste stegen på väg att bygga en bra produkt. Huvudsyftet med att skicka en minsta livskraftig produkt ska alltid vara att "lägga det framför kunderna för att börja validera dina antaganden".
Som ett lag måste du samla dina styrkor och fokusera på att skapa en gemensam förståelse för affärsvisionen och målen. Du måste identifiera problemet du försöker lösa och utreda hur du ska organisera så fort som möjligt, börja lära dig om vad kunderna verkligen vill ha och hur de hjälper dig att driva dessa mål.
När jag började prata om MVP i klasser skulle jag använda analogi av en enkel vanlig munk (det var min MVP) och en munk full av choklad, strö och all godhet möjligt (en senare iteration av produkten).
MVP och senare iteration? Donut ikoner från Diana TomaNuförtiden, ju mer jag jobbar med lag och konceptet MVP, särskilt nu när jag har en produktroll, befinner jag mig att ifrågasätta denna analogi. Att bygga MVP för att validera antaganden kan faktiskt innebära att du hade fel att börja med, och nästa iteration är inte ens en munk; kanske är det en vanlig våffla ?! Beviljas, det skulle fortfarande vara klart, och du skulle återigen behöva gå igenom processen för att validera den, men det skulle inte längre vara en munk.
Därför ska jag låna en illustration från Henrik Kniberg och förklara vad en MVP borde inte vara.
av Henrik KnibergHenrik beskriver två olika tillvägagångssätt som delar samma vision: en bil. Nu om problemet du försöker lösa är transport, skulle du som kund gå någonstans med ett däck? Definitivt inte med ett däck, men säkert med en skateboard.
Henrik försvarar det smidiga, inkrementella sättet att leverera produkter men säger att varje iteration bör vara en användbar / testbar produkt. Självklart är en skateboard långt från att vara en bil, men åtminstone har du kunderna försöker din produkt mycket tidigare i processen och matar tillbaka så att du kan börja lära dig och tänka på nästa iteration.
Du borde inte ägna mycket tid på att titta på design eller göra det tekniskt bra - du vill inte göra det perfekt till att börja med, men istället borde du bygga bara nog för att validera dina affärshypoteser.
Sammanfattningsvis är en MVP inte ...
I den här artikeln kommer vi att täcka följande ämnen-de ger dig några verktyg för att börja tänka på vad din MVP ska vara:
När du slutligen byggar produkter ska ditt huvudmål alltid lösa kundernas problem. Om du inte löser sina problem, och du inte tar med något nytt som passar in i deras dagliga rutin, kommer de troligtvis inte att använda din produkt. Med överflöd av designtekniker får UX-team verktyg för att lära känna kunder och komma till botten med vad de vill ha tidigare i processen.
Det finns ett antal tekniker som du och ditt team kan använda för att lära känna dina kunder och förstå hur du kan lösa problem:
Fokusgrupper. Om du bygger en ny produkt, bjud in en grupp människor som använder dina konkurrenters produkter och fråga dem om smärtpunkter, plus saker som de verkligen gillar, och försök att få en bra förståelse för vad de skulle förändras och varför . Om du förbättrar en befintlig produkt eller lägger till en ny funktion, varför inte bjuda in dina egna kunder och fråga dem samma frågor? Fokusgrupper är en bra start för att utveckla en god förståelse för vad dina kunder kanske vill ha från din produkt, men tänk på att fokusgrupper kan vara lite förspända. det finns alltid någon med riktigt starka åsikter som kan påverka andra, så du borde försöka läsa mellan linjerna.
Ideation workshop. Samla ditt lag (inklusive berörda parter) och avslöja några av de smärtpunkter som hittats. Du bör också försöka skriva ut så mycket som du hittills har lärt dig om de definierade visionerna och affärsmålen och stift dessa upp på väggarna så att alla tydligt kan se dem. I dessa sessioner, fråga alla att skissera så många lösningar som de kan tänka sig för problemen du försöker lösa. Du letar efter kvantitet, inte kvalitet.
Prototyper och användartestning. Helst bör du prototypera minst en gång i veckan. Numera är UX-team mer smidiga och UX-designers tenderar att spendera mer tidsschetching och användarprövning av pappersprototyper eller lågfidelity wireframes än att spendera längre perioder bakom en dator som tar beslut på egen hand. Få ditt UX-team att använda prototyper så tidigt som möjligt i processen för att få lite saftig återkoppling från användarna. Guerilla-testning är ett utmärkt och effektivt sätt att testa tidiga mönster, och det tar nästan ingen ansträngning.
Så du gjorde mycket testning när du försökte utforma den bästa lösningen. Du sprang varje vecka guerrilla sessioner, du tog dina mönster till labbet och du är säker på att du är på rätt spår.
Ändå, även om du bara testat med användare av din produkt, är de en liten andel av din publik, och De var föremål för en testmiljö (knappast neutral). Att testa med kunder tidigare i processen är ovärderlig, men du vill få din produkt där ute för en större publik att testa.
Att strategisera om att bygga och starta en minsta levande produkt är det näst bästa för att validera dina antaganden och fortsätta bygga vidare på vad du har lärt dig hittills.
Ett bra sätt att börja tänka på din MVP är att titta på färdplanen som du har byggt i tidigare sessioner och fokusera på saker som löser kundproblem.
När du har gjort det här, fråga frågan: Vad kan jag bygga med minsta ansträngning som hjälper mig att validera denna produkt?
Det är här jag fortfarande kämpar: mitt UX-hjärta (kropp och själ) säger alltid att jag ska försöka få så mycket ut som möjligt. Jag vill bygga en sömlös upplevelse från dag ett, för varje användare.
Som produktägare, med en kort tidsfrist och en budget på mina händer, vill jag bygga tillräckligt för att vi ska bygga rätt sak, och jag tror verkligen att det här är ett bra produktsamtal.
Ingenting. Kan gå ut. Utan taggning.
Tja, vi har sagt det innan, eller hur? Målet att bygga en MVP är att lära och iterera. Det finns inget sätt att lära (jag menar att verkligen lära) med dina kunder om du inte har ett system som gör att du kan spåra vilka kunder som gör med din produkt. Du behöver de värdefulla uppgifterna för att fatta välgrundade beslut. Du kan göra kvalitativ forskning och fråga dina kunder hur de tycker om din produkt, men vi vet att det kanske inte räcker med.
Du måste se till att du skapar taggar i din MVP som hjälper dig att förstå hur din produkt fungerar mot dina KPI (Key Performance Indicators) och mäta dina antaganden.
Analytiska (eller spårning) taggar tillhandahålls ofta av leverantörer från tredje part som Google Analytics för att hjälpa oss att integrera vår produkt (webbplats, mobilapp) med deras spårningsverktyg. Spårningstaggar är inte mer än ett kodnummer som du måste bädda in i produktens källkod för att skicka vilka kundhandlingar du vill spåra och göra det enklare för dig att visualisera data.
Låt oss säga att du vill spåra hur många gånger en viss knapp klickas. leverantören kommer att be dig lägga till en händelsetagg till knappens källkod för att se till att en tagg är avfyrade till deras verktyg varje gång en kund klickar på den knappen. Deras verktyg registrerar sedan denna åtgärd tillsammans med andra åtgärder du definierar för att ge dig en detaljerad bild av vad kunderna gör med din produkt.
Det finns en rad verktyg du kan använda för att spåra dina kunder online. Börja med att välja den rätta för dig och dina företagsbehov och kontakt med deras kundtjänst för att få några hjälpbyggande taggar till din produkt:
När spårningen är på plats och din MVP är ute kan du börja titta på vad dina kunder gör med din produkt.
Om du är ny för att analysera, finns det några saker du kan göra för att få huvudet kring data och vad du ska titta på. Google har några introduktionsvideor för att komma igång, och du kan också läsa boken Lean Analytics. Dessa hjälper dig att förstå handlingsbara mätvärden och vad man ska göra med de data du får.
Om du har chans att ha ett team dedikerat till insikter i ditt företag, kan de hjälpa dig att förstå data ännu bättre! De kommer sannolikt att kunna bygga rapporter med de viktigaste mätvärdena du vill följa för att göra ditt liv enklare.
Oavsett vad som helst för att få den här informationen till dig, ska hela laget ha tillgång till det. Du borde alla diskutera resultaten och vad som är nästa för din produkt. Hur är kundnöjdhet? Drivs de mål du har ställt?
Om svaret är ja, då bra nyheter! Dina tidigare antaganden var rätt, och du gjorde ett bra jobb. Om din MVP däremot inte kör de mätvärden du förväntade dig, förstår varför och överens om vad du ska göra nästa (säg också nåd att du bestämde dig för att starta en MVP innan du fördelar massor av resurser och pengar till en produkt som inte skulle ha varit så framgångsrik som du ursprungligen trodde det skulle).
Om din kundbas är tillräckligt bra bör du uppmuntra A / B eller Multivariant testning. På så sätt kan du under hela livscykeln för din produkt testa olika variationer och se till att du fortsätter att köra dessa mätvärden.
Du kan göra ändringar i ditt gränssnitt och se vad som fungerar bäst för dina kunder. Prova små förändringar som att byta kopia på en titel eller en knappfärg och ha två versioner av din produkt som kör sida vid sida för att analysera resultat. Du kan också helt ändra ett gränssnitt; Optimizely är bara ett exempel på ett verktyg som kan hjälpa dig att köra dessa experiment. Ange de parametrar du vill testa och procentandelen kunder som du vill visa den nya versionen av din sida eller produkt och spåra resultaten.
Det är dags att du började iterera och bygga på det du redan har. Idealiskt är din färdplan prioriterade nu och på ett sätt som du kan lösgöra produktintervaller kontinuerligt. Nu är det dags att börja mobilisera ditt lag för att tänka på nästa droppe.
Kom ihåg att varje iteration av din produkt ska vara användbar (den "livskraftiga" i MVP). Det bör sträva efter att validera eller utmana dina antaganden och på ett sätt som ger dig mätbara data. Lycka till med MVP i ditt produktutvecklings arbetsflöde!