Scora hypoteser — så prioriterar du rätt

Daniel Hansson
Jan 16, 2019 · 10 min read

Genom att analysera och poängsätta dina hypoteser kan du öka teamets pricksäkerhet avsevärt. På samma gång minskar du svinnet och blir mer effektiv. Och användarna blir glada.

Vill du hoppa över tillvägagångssätt kan du gå direkt till min mall för hypotesscoring (gör en kopia).

Förutsättningar

Det här sättet att arbeta fungerar bäst på en redan skeppad produkt där en jobbar med ständig förbättring. Du behöver också analysverktyg, A/B-testverktyg samt ett team med kompetens som täcker flera discipliner; tänk teknik, ux-design och affär. I praktiken är det också en stor fördel om du jobbar i en organisation som har en datadriven kultur.

Hur tar en fram hypoteser?

Hypoteser finns överallt. Hos Hippon, i teamet och hos era konkurrenter. Alla feature requests är egentligen hypoteser. Alla dina konkurrenters features är potentiella hypoteser. Fast i din produkts kontext. Idéer i teamet är hypoteser. Resultatet din research och dina förstudier, som epics och user stories, är nästan alltid ovaliderade hypoteser. Alltså, hela din backlogg är full av hypoteser. Det vi förut kallade för krav.

Lite, grovt finns det två sätt att ta fram hypoteser.

  1. Samla ihop alla krav och idéer som finns kring produkten, eller
  2. Brainstorma fram idéer som ska lösa ett specifikt problem.

Exempel:

Varför scora hypoteser?

Anledningen till att vi poängsätter hypoteser är att förbättra pricksäkerheten. Vi har ofta många idéer, feature requests och hypoteser men begränsat med resurser. Vi vill inte spendera dyrbar tid på att bygga saker som få använder. Eller bygga saker som många använder, men som inte skapar hållbart värde. Vi vill minimera waste.

Tillvägagångssätt

  1. Dokumentera hypoteser.
  2. Beskriv detaljerat vilken nivå MMF:n behöver hålla för att hypotesen ska kunna valideras.
  3. Precisera vilka mätpunker som behövs för att kunna validera hypotesen.
  4. Diskutera med teamet vilka utvärderingskriterier hypoteserna ska poängsättas mot.
  5. Kalla till scoringworkshop.
  6. Sammanställ och diskutera rangordningsresultat.

1. Dokumentera hypoteser

Formulera hypoteser på ett sätt som du tycker är tillräckligt tydligt. De flesta sätt är bra. Förklara hypotesen och vilken effekt du hoppas den kan få.

Exempel:

2. Hitta rätt nivå på MMF (Minimum Marketable Feature)

En Minimum Marketable Feature är den minsta uppsättningen funktionalitet som måste realiseras för att kunden ska kunna uppleva värde. Tre saker är viktigt:

  1. Bygg så lite du kan,
  2. Tänk på att du måste kunna skeppa funktionen till en riktig marknad, och
  3. Funktionen ska skapa användarvärde.

Det här är kanske det svåraste och viktigaste. Speciellt om du jobbar med större hypoteser som är dyra att validera.

Du måste se till att bygga tillräckligt mycket för att testa hypotesens fulla potential. Samtidigt vill du inte bygga för mycket för att riskera waste.

Det är en stor fördel att samla alla kompetenser i teamet för att diskutera lämplig nivå på MMF. Fundera också på vilken exponering och marknadsföring en feature behöver för att den fulla potentialen ska kunna testas. Det kan vara så att en feature måste få en tillfälligt överexponerad plats för att potentialen av den ska kunna utvärderas ordentligt. Samtidigt vill du inte ha irrelevant trafik till din feature, som kan påverka experimentets utvärderingsmetrics felaktigt. Som avhoppningsgrad och featurelojalitet. Det är en lurig balansgång.

Är det något du ska lägga extra tid på under hela den här processen så är det att hitta fram till rätt nivå på MMF:erna. Detta kan inte nog understrykas.

Exempel:

3. Definiera mätpunkter

För att kunna etablera ett kausalt samband mellan din MMF och hållbart värde behöver du kvantitativa mätpunkter. Dessa mätpunkter följer du upp i A/B-test där du jämför originalversion mot MMF:n.

Oftast behöver du mätpunkter kopplade till MMF:n, mätpunkter kopplade till kannibalism, samt övergripande produktmetrics.

Exempel:

Exemplet ovan exkluderar metrics för att mäta kannibalism. På t.ex. en produktvy där du gör större förändringar behöver du ha mätpunkter för alla viktiga vyelement. Ett nytt element kan ta klick från andra element och leda till suboptimering, därför behöver du ofta följa upp beteendet för alla element.

Har du svårt att hitta bra, tydliga mätpunkter som dessutom är lätta att tolka bör du fundera en extra gång på om det ens är värt att försöka validera hypotesen. Och om du inte kan veta om hypotesen skapar hållbart värde, ska du då gå vidare med den?

4. Utvärderingskriterier

Vad du vill analysera och scora dina hypoteser efter bör bestämmas helt av produktens och teamets kontext. Men det är vanligt att några kategorier återkommer gång på gång:

  • Värde (0–5 p): Hur stort uppskattar teamet hypotesens värde om den valideras? Vanligtvis räckvidd, lojalitet, måluppfyllnad eller någon kombination av dem.
  • Resurs (0–5 p): Hur många sprintar tar det att utveckla MMF:n till den överenskomna nivån? Här är det mycket viktigt att teamet har hittat rätt nivå på MMF:n.
  • Lärande (0–5 p): Hur mycket lär vi oss på experimentet? Är det här ett outforskat område eller ej? Hur viktigt är det för teamet att lära sig om experimentet. Tror vi att lärandet kommer påverka produktens måluppfyllnad mycket eller lite?
  • Räckvidd (0–5 p): Hur stor andel av våra besökare kommer ha nytta av vår MMF? Ta hjälp av en digital analytiker så att uppskattningen blir hyfsat korrekt. Det är inte ovanligt med överdrivna glädjekalkyler här.
  • Risk (0–3 p): Finns det en betydande risk eller osäkerhet med MMF:n? Kan den riskera att användare slutar att använda vår produkt? Finns det så mycket osäkerhet om MMF:n att den riskerar att gå i stöpet?

Exempel på enkelt scorecard:

Exempel på fler kriterier som kan vara användbara:

  • Nödvändighet (0–3 p): Har alla dina konkurrenter funktionaliteten? Använd bara detta kriterium om du verkar på en marknad där konkurrensen är hård och du är hyfsat säker på att dina konkurrenter är datadrivna i sina beslutsprocesser. Då är sannolikheten hög att hypotesen är validerad och skapar värde.
  • Unikt (0–3 p): Har dina konkurrenter funktionaliteten eller är du ensam om den? Om positionering är viktigt på din marknad kan det här kriteriet vara relevant att ha med.
  • Word of mouth (0–2 p): Tror du att dina användare skulle tipsa sina kompisar om funktionaliteten? Ett enkelt sätt för teamet att uppskatta om funktionaliteten verkligen löser viktiga problem.
  • Synlighet (0–2 p): Är experimentet ovanför folden? Detta kriterium kan vara relevant för att vikta upp hypoteser som är lättare att upptäcka än andra. Tänk på att folden kan vara olika för olika enheter och skärmstorlekar.
  • Välbesökt (0–5 p): En feature på en populär vy har oftast större sannolikhet att skapa större impact än en feature på en mindre populär vy. Använder du redan ett kriterium för räckvidd kan du bortse från den här.
  • UX-problem (0–2 p): Om funktionaliteten löser ett tidigare känt problem bör hypotesen viktas upp något. Tänk på att problem identifierade med hjälp av kvalitativa metoder som användningstest inte behöver vara generella för alla eller många användare. Helst ska du alltså ha noterat problemet många gånger innan du scorar upp det här värdet.
  • Analytics-problem (0–3 p): Löser vi ett problem vi upptäckt med kvantitativ analys/klickbeteende? Samma som ovan med skillnaden att vi upptäckt beteendet med hjälp av kvantitativ data. Då kan vi också se ungefär hur stort problemet är och hur det påverkar måluppfyllnad.
  • Feedback (0–2 p): Löser vi ett problem som ofta kommer in som feedback? Kolla med kundtjänst och ev. app-recensioner för att se om hypotesen adresserar problem som kommit in som användarfeedback. Tänk på användare kan önska features samtidigt som de kan ha svårt med att analysera sitt framtida beteende. Alltså, de kan önska features som de inte kommer använda.
  • Förändring (0–2 p): Lägger vi till eller tar bort ett element? Experiment där vi tar bort eller lägger till element har vanligtvis större impact jämfört med experiment där vi bara gör förändringar på befintliga element. Inte alltid, men oftast. Därför kan en scora upp hypoteser som innebär större förändringar i gränssnittet.
  • Upptäckbarhet (0–2 p): Skulle en användare upptäcka förändringen på fem sekunder? Alltså, om en användare får se en vy med alternativ A (original) under fem sekunder, och sedan alternativ B under fem sekunder, tror vi då att hen skulle upptäcka skillnaden? Detta test går att göra på riktiga användare om en exempelvis har prototyper eller skisser över de hypoteser en vill scora.
  • Nöjdhet (0–5p): Tror vi att användarna blir mer nöjda med vår produkt när den inkluderar features i vårt experiment? Då menar jag hållbar nöjdhet över tid, inte nöjdhet i form av upptäcka-och-testa-ny-feature-ett-par-gånger-för-att-sedan-överge-den.
  • Interna effekter (0–5 p): Ger experimentet positiva effekter internt inom vår organisation? Innebär hypotesen att teamet får jobba med stakeholders som det är viktigt att ha en bra relation med? Ofta ett bra kriterium att ha med i organisationer där internpolitik kan vara en utmaning.
  • Hållbarhet (0–5 p): Skapar vi bättre hållbarhet eller andra positiva CSR-effekter med featuren? Alla organisationer har ett ansvar för generellt hållbarhetsarbete. Inte minst för att locka kunder och medarbetare. Innebär hypotesen förbättrad hållbarhet ska den scoras upp.
  • Teknik (0–3 p): Hur intressant är tekniken att jobba med? Hypoteser som innebär att teamet får jobba med ny och relevant teknik bör scoras upp något. Dels för teamets lärandeprocess, men också för att vara ett attraktivt team att jobba i. Detta gäller inte såklart inte alla team.
  • Strategisk inriktning (0–10 p): Följer hypotesen den utstakade vägen för produktutvecklingen? De hypoteser som följer strategin bäst bör scoras upp.

Det var ett axplock av kriterier att scora dina hypoteser efter. Du kan säkert komma på fler som är relevanta för just ditt team och din kontext.

Ett råd är att inte börja med för många kriterier, lägg hellre till fler efter hand när nikört några varv.

5. Workshop

1. Inledning

Det finns olika sätt att hålla i den här typen av workshops. Oavsett behöver du börja med en genomgång av alla kriterier, hypoteser, samt beskrivningar av dess MMF-nivåer.

Har teamet tidigare erfarenhet i form av experiment och A/B-test eller redan gjort gedigen digital analys om räckviddspotential kan det vara bra att också gå igenom den tillsammans med gruppen innan start.

T.ex. kanske teamet redan vet att 2–3% använder internsök och att det är svårt att ändra på det beteendet. Generell CTR på pushytor på förstasidan kanske ligger runt 15–17% p.g.a. stor andel användare som vet vad de vill, och är immuna mot push innan de nått sina mål. Ja, ni förstår.

Gå också igenom alla utvärderingskriterier så att alla i workshoppen förstår dess innebörd fullt ut. Det är inte ovanligt med diskussioner kring vad menas med “lärande” eller “risk”. Gå också igenom om poängskalan känns relevant, och om decimaler är ok att använda eller ej under poängsättningen.

Nu är ni redo att börja.

2. Scora i par

Dela in workshopdeltagarna i par. Försök mixa paren så att de blir dynamiska och har lite bredd inom design och teknik. Poängsättning av hypoteserna gör paren med fördel i ett kalkylark med olika flikar. På så sätt går det supersnabbt att sammanställa resultatet efter workshopen.

Använd gärna mallen jag har tagit fram.

Paren måste vara överens om ett värde innan det läggs in i kalkylarket. Ibland leder detta till långa diskussioner inom paren. Då kan en snabb gruppdiskussion behövas för att reda ut frågetecken. Kommer inte ett par vidare inom rimlig tid lämnar de cellen tom så länge.

Hur lång tid poängsättningen tar beror såklart på antalet hypoteser och utvärderingskriterier. Men räkna med två timmar om du har upp mot 20 hypoteser och, säg, 15 utvärderingskriterier. Då är det ändå 300 värden som ska fyllas i.

3. Genomgång i grupp

När alla är färdiga med sina spreadsheets träffas hela gruppen igen och går igenom cell efter cell. Precis som vid planning poker behöver de par som har värden långt utanför resten av gruppen motivera sitt värde och eventuellt justera det.

4. Avsluta workshop

Vid det här laget brukar energinivån vara låg. Så vänta med att visa resultatet. Ta ett längre break, eller kalla till ett nytt möte en tid senare.

6. Sammanställning resultat

Räkna ut medelvärde för varje kriterium/hypotes-cell och summera ihop till en hypotesscore. Rangordna efter högsta score först. Använd gärna mallen jag tagit fram.

Kalla till nytt möte och gå igenom rangordningen. Känns den rimlig? Är det någon som vill ändra på sin score? Passar rangordningen in i produktplaneringen? Är någon hypotes beroende av någon annan? Påverkar det vilken ordning hypoteserna ska testas?

Peppa teamet och börja validera era fina idéer.

Feedback på dina uppskattningar

Spara gärna poängsättningsdokumentet som ett tidsdokument. Spara ner ändringar du gör i ett nytt dokument. På så sätt kan teamet tillsammans gå tillbaka och utvärdera sitt scoringsarbete och bli vassare för varje gång. Min erfarenhet är att värde, räckvidd och risk tenderar att överscoras och att interna effekter och resurser underscoras.

En utveckling av poängsättningsmodellen kan vara att de personer i teamet som har bäst track record i sitt scorande också får ökad påverkan i själva poängsättningen.

Praktiskt kan det gå till att de personer som förutspår resultat av A/B-test bäst (rullande senaste fem experiment, eller liknande) får större inflytande genom att deras poängsättning viktas upp något. På så sätt kan vi optimera pricksäkerheten ännu mer.

När ska du inte scora hypoteser?

Självklart behöver inte alla hypoteser analyseras och poängsättas. Är risken låg, komplexiteten låg och resursåtgången begränsad går det såklart att bara köra på och utveckla.

Det en bör tänka på i dessa fall är att A/B-test krävs för att på ett validerat sätt lära sig om just denna hypotes eventuella effekter på produkten. Men ibland är lärandet på en sån begränsad nivå att A/B-test och etableringen av kausala samband inte är värt det.

En lär sig balansgången över tid.


Daniel Hansson är frilanskonsult inom Lean UX och Analytics, med bas i Stockholm.

Validerat lärande

Artiklar om Lean UX, Analytics och förändringsledning. Av Daniel Hansson — frilanskonsult

Daniel Hansson

Written by

Frilanskonsult inom Growth Analytics och Lean UX / Stockholm / danielhansson.info

Validerat lärande

Artiklar om Lean UX, Analytics och förändringsledning. Av Daniel Hansson — frilanskonsult

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade