Du har 47 features i backloggen. Produktsjefen vil ha den ene. Salgsteamet skriker etter en annen. Kundeservice har sine favoritter. Og utviklingsteamet lurer på hvorfor dere ikke bare fikser den tekniske gjelden først.
Velkommen til hverdagen for de fleste produktteam. Problemet er sjelden mangel på ideer – det er å velge hvilke ideer som faktisk fortjener tid og ressurser.
ICE-scoring er et prioriteringsrammeverk som hjelper deg ta disse valgene basert på data og logikk, ikke bare hvem som roper høyest. La oss se på hvordan det fungerer i praksis.
Hva er ICE-scoring og hvorfor fungerer det?
ICE-scoring er en metode for å rangere features og initiativer basert på tre faktorer:
Impact (Effekt) – Hvor stor effekt vil dette ha på målene våre?
Confidence (Sikkerhet) – Hvor sikre er vi på at dette vil fungere?
Ease (Enkelhet) – Hvor enkelt er dette å gjennomføre?
Hver faktor scores på en skala, typisk 1-10. Multipliser de tre tallene, og du får en ICE-score som gjør det enkelt å sammenligne helt ulike features.
En feature med Impact 8, Confidence 7 og Ease 5 får scoren 280. En annen med Impact 9, Confidence 3 og Ease 8 får 216. Den første vinner.
Hvorfor tradisjonelle metoder ofte feiler
De fleste team prioriterer på en av disse måtene:
HiPPO-metoden (Highest Paid Person's Opinion) – Sjefen bestemmer. Raskt, men ofte basert på magefølelse fremfor data.
Demokratisk avstemning – Alle stemmer. Høres rettferdig ut, men features som gleder flest internt er sjelden det som gir mest verdi til kundene.
Først til mølla – Det som kommer først inn i backloggen blir gjort først. Ingen strategi, bare reaksjon.
Kundeønsker direkte – Gjøre alt kundene ber om. Høres kundesentrisk ut, men ender ofte med et produkt som prøver å være alt for alle.
ICE-scoring tvinger teamet til å vurdere hver feature langs tre dimensjoner samtidig. En feature kan ha høy impact, men hvis confidence er lav og ease er lav, vil den tape mot en feature med middels impact men høy confidence og ease.
Når ICE-scoring er riktig verktøy
ICE fungerer best når:
- •Du har mange features å velge mellom (minst 10-15)
- •Teamet trenger et felles språk for prioritering
- •Dere vil ta raskere beslutninger uten endeløse møter
- •Det er uenighet om hva som bør prioriteres
- •Du trenger å forsvare prioriteringer overfor ledelsen
ICE er ikke alltid riktig verktøy. Hvis du bygger noe helt nytt uten data, eller hvis du har regulatoriske krav som må implementeres uansett, trenger du ikke ICE for å ta beslutningen.
Fordeler du får med ICE-scoring
Et produktteam i fintech-bransjen hadde 63 features i backloggen. Etter første ICE-scoring workshop fant de ut at 18 av disse hadde så lav score at de ble fjernet helt. 12 features med høy Impact men lav Ease ble splittet i mindre deler. De 15 med høyest score ble roadmapen for neste kvartal.
Resultatet: Teamet leverte 12 av disse 15 featurene i løpet av tre måneder. Før ICE hadde de levert 6-7 features per kvartal, ofte de som var enklest å bygge, ikke de som ga mest verdi.
De tre komponentene i ICE-scoring
Impact (Effekt)
Impact handler om én ting: Hvor mye vil denne featuren flytte nåla på målene våre?
Nøkkelen er å koble impact direkte til målbare KPIer. Ikke "dette vil gjøre kundene lykkeligere" – det er for vagt. I stedet: "dette vil øke konverteringsraten fra trial til betalt abonnement med 15%".
Slik scorer du impact 1-10:
1-3 (Lav impact): Påvirker en liten brukergruppe eller har minimal effekt på KPIer. Eksempel: En kosmetisk endring i admin-panelet som brukes av 3 personer.
4-6 (Middels impact): Påvirker en betydelig brukergruppe eller har moderat effekt på KPIer. Eksempel: En forbedring av søkefunksjonen som 40% av brukerne bruker ukentlig.
7-9 (Høy impact): Påvirker de fleste brukere eller har stor effekt på primære KPIer. Eksempel: En onboarding-flow som reduserer time-to-value fra 7 dager til 2 dager.
10 (Kritisk impact): Game-changer som fundamentalt endrer produktets verdi. Eksempel: En integrasjon som åpner et helt nytt markedssegment.
Vanlige feil ved impact-vurdering:
Den største feilen er å gi alt høy impact-score. Hvis 30 av 40 features får score 8-10, har du ikke prioritert – du har bare gitt alle en gullstjerne.
En annen feil er å blande impact med personlige preferanser. "Jeg synes denne featuren er kul" er ikke det samme som "denne featuren vil øke retention med 20%".
Koble impact til forretningsmål:
Før du scorer, må du vite hva dere faktisk prøver å oppnå. Er målet å øke antall betalende kunder? Redusere churn? Øke average revenue per user?
Et B2B SaaS-selskap hadde tre hovedmål: Øke trial-to-paid konvertering, redusere time-to-value, og øke feature adoption blant eksisterende kunder. Hver feature ble scoret basert på hvilken av disse den påvirket mest. Features som ikke påvirket noen av dem fikk automatisk lav impact-score.
Confidence (Sikkerhet)
Confidence handler om hvor sikre dere er på impact-estimatet. Har dere data som støtter antagelsen, eller er det ren gjetning?
Slik scorer du confidence 1-10:
1-3 (Lav confidence): Ren antagelse uten data. "Vi tror kanskje dette kan hjelpe."
4-6 (Middels confidence): Noe data eller indirekte bevis. Kanskje konkurrenter har gjort noe lignende, eller dere har kvalitativ feedback fra noen kunder.
7-9 (Høy confidence): Solid data fra brukerundersøkelser, analytics, A/B-tester eller lignende features dere har bygget før.
10 (Svært høy confidence): Validert gjennom prototyper, beta-testing eller faktiske tall fra en pilot.
Datakilder som øker confidence:
- •Brukerundersøkelser med konkrete spørsmål
- •Analytics som viser faktisk brukeratferd
- •Kundesamtaler med spesifikke use cases
- •A/B-tester av prototyper eller mockups
- •Data fra konkurrenter eller lignende produkter
- •Tidligere features med sammenlignbar impact
Et produktteam ville bygge en avansert rapporteringsfunksjon. Impact-scoren var 8 – hvis kundene faktisk ville bruke den. Men de hadde kun snakket med 3 kunder som hadde bedt om den. Confidence ble satt til 4. Før de bygget featuren, sendte de en enkel mockup til 50 kunder og spurte: "Ville du brukt dette ukentlig?" 12 sa ja. Det var nok til å øke confidence til 6 og gå videre med utviklingen.
Når lav confidence faktisk er OK:
Noen ganger må du satse på features med lav confidence fordi potensialet er så stort. En feature med Impact 10, Confidence 3, Ease 7 får score 210. Det kan fortsatt være verdt å teste, spesielt hvis Ease er høy nok til at du kan bygge en enkel versjon raskt.
Nøkkelen er å være bevisst på usikkerheten. Hvis du bygger noe med lav confidence, planlegg for å måle effekten tidlig og være klar til å pivotere.
Ease (Enkelhet)
Ease handler om hvor enkelt det er å bygge og lansere featuren. Dette inkluderer både teknisk kompleksitet og organisatorisk kompleksitet.
Slik scorer du ease 1-10:
1-3 (Svært vanskelig): Krever måneder med utvikling, nye teknologier, eller store endringer i eksisterende systemer. Eksempel: Bygge en helt ny betalingsplattform fra bunnen.
4-6 (Middels vanskelig): Krever noen uker med utvikling og involverer flere team. Eksempel: Integrere med et tredjeparty-API som krever autentisering og feilhåndtering.
7-9 (Relativt enkelt): Kan gjøres i løpet av en sprint eller to med eksisterende teknologi. Eksempel: Legge til et nytt felt i et skjema og lagre det i databasen.
10 (Svært enkelt): Kan gjøres på timer eller dager. Eksempel: Endre tekst på en knapp eller justere en fargeverdi.
Teknisk vs organisatorisk kompleksitet:
En feature kan være teknisk enkel, men organisatorisk kompleks. Å endre standard-innstillingene i produktet kan ta 30 minutter å kode, men hvis det krever godkjenning fra legal, compliance og fire produktsjefer, er Ease-scoren lav.
Motsatt kan noe være teknisk komplekst men organisatorisk enkelt. En avansert algoritme kan ta tre uker å bygge, men hvis ett team kan gjøre alt selv uten avhengigheter, kan Ease-scoren være høyere enn du tror.
Hvordan involvere utviklingsteamet:
Ikke la produktsjefen gjette på Ease-score. Involver minst én utvikler i scoringen, helst tech lead eller noen med oversikt over hele systemet.
Et team gjorde den feilen å score Ease uten utviklerne. Produktsjefen ga en feature Ease 8 fordi "det er bare å legge til en knapp". Utvikleren forklarte at knappen måtte trigge en kompleks bakgrunnsprosess som krevde omskriving av tre microservices. Faktisk Ease: 3.
Quick wins vs strategiske investeringer:
Features med høy Ease og middels Impact er quick wins – ting du kan levere raskt for å vise fremgang. Features med lav Ease men høy Impact er strategiske investeringer som tar tid men gir stor verdi.
En sunn backlog har begge deler. Hvis alt du bygger er quick wins, beveger du deg ikke mot de store målene. Hvis alt er strategiske investeringer, går det måneder uten at noen ser resultater.
Steg-for-steg implementering av ICE-scoring
Steg 1: Forberedelse
Definere scoringkriterier for teamet
Før første scoring-workshop, må dere bli enige om hva tallene betyr. Hva er forskjellen på Impact 6 og Impact 8? Hva kvalifiserer som Confidence 7?
Lag et enkelt dokument med kriterier tilpasset deres produkt og mål. Et team som jobbet med et internt HR-system definerte Impact basert på antall ansatte påvirket og timer spart per uke. Et team som jobbet med en consumer app definerte Impact basert på påvirkning på retention og engagement.
Velge verktøy
Start enkelt. De fleste team begynner med et Google Sheet eller Excel-ark. Det holder lenge.
Når dere har scoret 50+ features og vil ha bedre integrasjon med utviklingsprosessen, kan dere vurdere å legge ICE-scoring inn i Jira, Azure DevOps eller et dedikert produktverktøy som Productboard.
Involvere stakeholders
Hvem skal være med på scoringen? Minimumsbesetningen er:
- •Produktsjef eller produkteier
- •Tech lead eller senior utvikler
- •Designer (hvis featuren påvirker UX)
- •Én representant fra business-siden (salg, kundeservice eller lignende)
Ikke inviter for mange. 4-6 personer er ideelt. Mer enn det, og workshopen blir treg.
Sette opp første scoring-workshop
Blokker 2-3 timer. Ja, det høres lenge ut, men første gang tar tid. Senere scorer dere nye features på 15-30 minutter.
Send ut listen over features som skal scores minst to dager før, slik at folk kan tenke gjennom dem på forhånd.
Steg 2: Scoring-prosessen
Workshop-format som fungerer
Start med å gå gjennom scoringkriteriene sammen. Alle må forstå hva tallene betyr.
Gå gjennom én feature om gangen. Produktsjefen forklarer featuren og hvorfor den er på listen. Deretter scorer hver person individuelt – skriv ned tallene uten å diskutere først. Dette forhindrer at den mest høylytte personen påvirker alle andre.
Når alle har scoret, del tallene. Hvis alle er enige innen 1-2 poeng, bruk gjennomsnittet. Hvis det er stor uenighet (noen sier Impact 3, andre sier 9), diskuter hvorfor.