Share
La oss snakke om MVPs (Minimum Viable Products) og hvordan du som produktleder eller brukeropplevelse profesjonell kan jobbe med stramme tidsfrister og budsjetter samtidig som du leverer et godt produkt.
Du har sikkert kommet over akronym MVP før - nesten sikkert hvis du jobber i teknologiindustrien - og til tross for å være et kontroversielt trebrevsord, er en MVP trolig en av de viktigste skrittene på vei til å bygge et godt produkt. Hovedmålet med å sende et minimalt levedyktig produkt bør alltid være å "sette det foran kundene for å begynne å validere dine forutsetninger".
Som et lag må du samle dine styrker og fokusere på å skape en felles forståelse av forretningssynet og målene. Du må identifisere problemet du prøver å løse og utarbeide hvordan du skal organisere, så raskt som mulig, begynne å lære om hva kundene virkelig vil ha, og hvordan de vil hjelpe deg med å drive disse målene.
Da jeg begynte å snakke om MVPs i klasser, ville jeg bruke analogien til en enkel vanlig doughnut (det ville være min MVP) og en dough full av sjokolade, sprinkles og all godhet mulig (en senere iterasjon av produktet).
MVP og senere iterasjon? Donut ikoner fra Diana TomaI dag, jo mer jobber jeg med lag og konseptet MVP, spesielt nå som jeg har en produktrolle, finner jeg meg selv å stille spørsmål til denne analogien. Å bygge MVPer for å validere antagelser kan faktisk bety at du hadde feil å begynne med, og den neste iterasjonen er ikke engang en doughnut; kanskje det er en vanlig vaffel ?! Gitt, det ville fortsatt være klart, og du ville igjen måtte gå gjennom prosessen med å validere den, men det ville ikke lenger være en doughnut.
For dette skal jeg låne en illustrasjon fra Henrik Kniberg, forklare hva en MVP bør ikke være.
av Henrik KnibergHenrik beskriver to forskjellige tilnærminger som deler samme visjon: en bil. Nå hvis problemet du prøver å løse er transport, vil du som kunde gå hvor som helst med et dekk? Definitivt ikke med et dekk, men sikkert med en skateboard.
Henrik forsvarer den fleksible, inkrementelle måten å levere produkter på, men sier at hver iterasjon bør være et brukbart / testbart produkt. Åpenbart er et skateboard langt fra å være bil, men i det minste har kundene dine prøvd produktet ditt mye tidligere i prosessen og fôr tilbake, slik at du kan begynne å lære og tenke på neste iterasjon.
Du bør ikke bruke mye tid på å se på design eller gjøre det teknisk bra - du vil ikke gjøre det perfekt til å begynne med, men i stedet bør du bygge akkurat nok til å validere forretningshypotesene dine.
For å oppsummere er en MVP ikke ...
I denne artikkelen vil vi dekke følgende emner-de gir deg noen verktøy for å begynne å tenke på hva MVP skal være:
Til slutt, når du bygger produkter, skal hovedmålet alltid være å løse kundenes problemer. Hvis du ikke løser sine problemer, og du ikke bringer noe nytt som passer inn i deres daglige rutine, vil de mest sannsynlig ikke bruke produktet ditt. Med flom av designteknikker får UX-lagene verktøy for å bli kjent med kunder og komme til bunnen av det de vil ha tidligere i prosessen.
Det finnes en rekke teknikker du og teamet ditt kan bruke for å bli kjent med kundene dine og forstå hvordan du kan løse problemer:
Fokus gruppe. Hvis du bygger et nytt produkt, kan du invitere en gruppe personer som bruker konkurrentens produkter og spørre dem om smertepunkter, pluss ting de virkelig liker, og prøv å få en god forståelse for hva de ville endre og hvorfor . Hvis du forbedrer et eksisterende produkt eller legger til en ny funksjon, hvorfor ikke invitere dine egne kunder og stille dem de samme spørsmålene? Fokusgrupper er en god start for å utvikle en god forståelse av hva kundene dine vil ha fra produktet ditt, men husk at fokusgrupper kan være litt partisk. Det er alltid noen med veldig sterke meninger som kan påvirke andre, så du bør prøve å lese mellom linjene.
Ideasjonsverksted. Samle laget ditt (interessenter inkludert) og avslør noen av smertepoengene som er funnet. Du bør også prøve å skrive ut så mye som du har lært så langt om den definerte visjonen og forretningsmålene og pin dem opp på veggene slik at alle kan tydeligvis se dem. I disse øktene, be alle om å skissere så mange løsninger som de kan tenke på for problemene du prøver å løse. Du leter etter kvantitet, ikke kvalitet.
Prototyping og brukertesting. Ideelt sett bør du prototypere minst en gang i uken. I dag er UX-lagene mer fleksible, og UX-designere har en tendens til å bruke mer tidskisse og brukertesting av papirprototyper eller lavfidelity wireframes enn å bruke lengre perioder etter en datamaskin som tar beslutninger alene. Få UX-teamet til å bruke prototyper så tidlig som mulig i prosessen for å få noen saftig tilbakemelding fra brukere. Guerilla-testing er en flott og effektiv måte å teste tidlig design på, og det tar nesten ingen innsats.
Så du gjorde mye testing mens du prøvde å designe den beste løsningen. Du løp ukentlig guerrilla-økter, du tok designene dine til laboratoriet, og du er sikker på at du er på rett spor.
Likevel, selv om du bare har testet med brukere av produktet, er de en liten prosentandel av publikum, og De var underlagt et testmiljø (neppe nøytralt). Testing med kunder tidligere i prosessen er uvurderlig, men du vil få produktet ditt der ute for et større publikum til å teste.
Strategi for å bygge og lansere et minimumsgjennomførbart produkt er det nest beste for å validere dine forutsetninger og fortsette å bygge videre på det du har lært så langt.
En god måte å begynne å tenke på MVP er å se på veikartet du har bygget i tidligere økter, og fokus på ting som løser kundeproblemer.
Når du har gjort dette, spør spørsmålet: Hva kan jeg bygge med minimale innsats som hjelper meg med å validere dette produktet?
Dette er hvor jeg fortsatt sliter: mitt UX-hjerte (kropp og sjel) forteller meg alltid å prøve å få så mye ut som mulig. Jeg vil bygge en sømløs opplevelse fra dag ett, for hver bruker.
Som produkteier, med en stram tidsfrist og et budsjett på mine hender, vil jeg bygge akkurat nok til å sikre at vi bygger den riktige tingen, og jeg tror virkelig dette er et godt produktsamtal.
Ingenting. Kan gå ut. Uten merking.
Vel, vi har sagt det før, ikke sant? Målet med å bygge en MVP er å lære og iterere. Det er ingen måte å lære (jeg mener å egentlig lære) med kundene dine med mindre du har et system på plass som lar deg spore hvilke kunder som gjør med produktet ditt. Du trenger de dyrebare dataene for å ta informerte beslutninger. Du kan gjøre kvalitativ forskning og spørre kundene hvordan de føler om produktet ditt, men vi vet at dette kanskje ikke er nok.
Du må sørge for at du bygger koder i MVP-en din, som vil hjelpe deg å forstå hvordan produktet ditt utfører KPI-er (Key Performance Indicators) og måle dine forutsetninger.
Analytiske (eller sporings) koder leveres ofte av tredjepartsleverandører som Google Analytics for å hjelpe oss med å integrere vårt produkt (nettsted, mobilapp) med sporingsverktøyene. Sporingskoder er ikke mer enn et stykke kode som du må legge inn i produktets kildekode for å sende hvilke kundehandlinger du vil spore, og gjøre det enklere for deg å visualisere data.
La oss si at du vil spore hvor mange ganger en bestemt knapp klikkes; Leverandøren vil be deg om å legge til en hendelse-kode i knappens kildekode for å sikre at en tag er sparket til verktøyet hver gang en kunde klikker den knappen. Deres verktøy vil da registrere denne handlingen sammen med andre handlinger du definerer for å gi deg en detaljert oversikt over hva kundene gjør med produktet ditt.
Det finnes en rekke verktøy du kan bruke til å spore dine kunder online. Begynn med å velge den rette for deg og dine forretningsbehov, og kontakt med kundeserviceteamet for å få hjelp til å bygge tagger i produktet ditt:
Når sporing er på plass og MVP-en er ute, kan du begynne å se på hva kundene dine gjør med produktet ditt.
Hvis du er ny til analytics, er det noen ting du kan gjøre for å få hodet rundt data og hva du bør se på. Google har noen innledende videoer for å komme i gang, og du kan også lese boken Lean Analytics. Disse vil hjelpe deg å forstå handlingsverdier og hva du skal gjøre med dataene du får.
Hvis du er heldig nok til å ha et team dedikert til innsikt i din bedrift, kan de hjelpe deg med å forstå dataene enda bedre! De vil mest sannsynlig kunne bygge rapporter med de viktigste beregningene du vil følge for å gjøre livet enklere.
Uansett hva som betyr for å få disse dataene til deg, burde hele laget ha tilgang til det. Du bør alle diskutere resultatene og hva som er neste for produktet ditt. Hvordan er kundetilfredshet? Kjører de målene du har satt?
Hvis svaret er ja, så gode nyheter! Dine tidligere forutsetninger var rett, og du gjorde en god jobb. Hvis din MVP derimot ikke kjører de beregningene du forventet, forstår hvorfor og avgjør hva du skal gjøre neste (også si nåde at du bestemte deg for å starte en MVP før du fordeler tonnevis av ressurser og penger til en produkt som ikke ville vært så vellykket som du opprinnelig trodde det ville).
Hvis kunden din er god nok, bør du oppmuntre A / B eller Multivariant testing. Dette vil tillate deg, gjennom hele livssyklusen til produktet ditt, å teste forskjellige variasjoner og sørge for at du fortsetter å kjøre disse beregningene.
Du kan gjøre endringer i grensesnittet ditt og se hva som fungerer best for kundene dine. Prøv små endringer som å endre kopien på en tittel eller en knappfarge, og har to versjoner av produktet som kjører side om side for å analysere resultater. Du kan også helt endre et grensesnitt; Optimizely er bare ett eksempel på et verktøy som kan hjelpe deg med å kjøre disse eksperimentene. Angi parametrene du vil teste, og prosentandelen av kunder du vil vise den nye versjonen av siden eller produktet, og spore resultater.
Det er på tide at du begynte å iterere og bygge på toppen av det du allerede har. Ideelt sett er køreplanen din prioritert nå, og på en måte som du kan løse produktintervaller kontinuerlig. Nå er det riktig tidspunkt å begynne å mobilisere teamet ditt for å tenke på neste dråpe.
Husk at hver iterasjon av produktet ditt skal kunne brukes (den "levedyktige" i MVP). Det bør søke å validere eller utfordre dine forutsetninger, og på en måte som gir deg målbare data. Lykke til med å bruke MVPer i produktutviklings arbeidsflyten!
Accentsconagua