5 eksempler på rammeverket «oppgaver som skal utføres» (JTBD) i praksis

Hvis du er produktleder, er jeg ganske sikker på at du allerede har hørt om JTBD-rammeverket, enten fra kollegene dine eller ved å lese om det på nettet. Du har kanskje også hørt tilhengere av rammeverket lovprise hvor effektivt det er. Men hvordan kan du stole på denne rosen uten å lære om faktiske suksesshistorier? La meg dele et par eksempler på jobber som skal gjøres med deg og vise hvor kraftig et rammeverk det er.

Men først: Hva er jobber som skal gjøres?

Jobber som skal gjøres er et rammeverk for å formulere tydelig hva kundene ønsker, og prioritere løsningene som best kan dekke disse behovene.

Dette rammeverket er skapt av Tony Ulwick – en veteran innen innovasjonsledelse fra IBM. Tony var en av pionerene og tydelige forkjemperne for ideen om å utvikle nye produkter ved å prioritere resultatene kundene ønsker å oppnå med dem.

Som en del av denne filosofien formulerte han et rammeverk som skulle gjøre det enkelt for alle å tenke og handle resultatorientert, og kalte det jobber som skal gjøres. I boken sin om JTBD-teori hevder Tony at mennesker ikke bare kjøper og bruker produkter. I stedet leier de inn disse produktene til å utføre en jobb de egentlig skulle ha gjort selv.

Ifølge JTBD kjøper du ikke et Grammarly-abonnement. I stedet leier du inn Grammarly for å hjelpe deg med å skrive som en proff.

Det finnes også et kjent sitat som forklarer JTBD:

Ved å identifisere disse «jobbene» som kundene dine er villige til å betale for, kan du rette all oppmerksomheten og alle ressursene dine mot et produkt som kan utføre denne jobben på en vellykket måte for dem, og gjøre kundene ivrige etter å leie inn produktet ditt i stedet for å håndtere jobben ved hjelp av alternative løsninger.

Det kan være ulike grunner til at en person ønsker å leie inn produktet ditt. Du kan imidlertid nesten alltid organisere dem slik:

Hver jobb vil sannsynligvis bestå av en funksjonell og en emosjonell side. Den emosjonelle siden har i sin tur en personlig og en sosial dimensjon. La oss se på disse én etter én og forstå hva de handler om.

Funksjonelle aspekter: Dette gjelder når brukerne ønsker å velge et bestemt produkt basert på den praktiske fordelen de får fra det.

La oss for eksempel se på jobben som skal gjøres for en bærbar arbeidsdatamaskin.

Når jeg jobber eksternt, ønsker jeg en bærbar datamaskin som jeg kan ta med meg og jobbe fra hvor som helst, slik at jeg kan være produktiv og gjøre arbeidet mitt utenfor kontoret.

I dette tilfellet innebærer arbeidet ditt konstant reising, og du klarer sjelden å finne en stikkontakt for å lade arbeidsdatamaskinen. Et viktig funksjonelt aspekt ved jobben som skal gjøres, vil derfor være å ha en bærbar datamaskin som kan holde på batteriet hele arbeidsdagen.

Dette er altså hvordan JTBD-en vår vil se ut når det funksjonelle aspektet fremheves tydeligere.

Når jeg jobber mens jeg er på reise, ønsker jeg en bærbar datamaskin med et batteri som varer en hel arbeidsdag, slik at jeg kan ta den med meg og jobbe hvor som helst, slik at jeg kan være produktiv og gjøre arbeidet mitt utenfor kontoret.

Emosjonelle aspekter: Kundene dine baserer ikke alltid beslutningene sine på rasjonelle kriterier. Noen ganger er motivene bak kjøpene deres rent emosjonelle.

Hvis vi ser på eksempelet med arbeidsdatamaskinen ovenfor, kan du i tillegg til et stort batteri også bry deg om hvordan den ser ut, fordi en bærbar datamaskin med et pent utseende kan få deg til å føle deg kul og moteriktig.

Vi kan derfor ha en annen versjon av JTBD-en ovenfor som tar følelsene dine i betraktning og fremhever dem.

Når jeg jobber mens jeg er på reise, ønsker jeg en stilig bærbar datamaskin som jeg kan ta med meg og bruke til å jobbe hvor som helst, slik at jeg kan se moteriktig ut når jeg jobber blant andre.

De emosjonelle fordelene du ønsker å få fra produktene du kjøper, vil også variere basert på den sosiale faktoren. Derfor kan du ha to dimensjoner for de emosjonelle aspektene ved JTBD-en din.

Personlig dimensjon: Dette er de emosjonelle fordelene du opplever personlig, og ikke som medlem av en sosial gruppe.

Du kan for eksempel foretrekke å kjøpe en kraftig bærbar datamaskin som kan kjøre de nyeste spillene fordi du er en ivrig spiller, og fordi du i tillegg til å jobbe også liker å spille på datamaskinen.

Sosial dimensjon: I dette tilfellet handler den emosjonelle fordelen du får ved å velge produktet ditt, om at du er medlem av samfunnet generelt eller av en bestemt sosial gruppe.

Du foretrekker kanskje å kjøpe en MacBook fordi den høye prisen og utseendet signaliserer høy sosial status hos eieren.

Nå som vi kjenner filosofien bak JTBD og kundenes motivasjon, kan vi se på hvordan du kan formulere en jobb ved å følge dette rammeverket.

Slik utformer du en jobbformulering

Innen jobber-teori er formatet for å skrive en jobbformulering ikke fastsatt, og ulike selskaper og produktteam bruker forskjellige varianter. I mitt tilfelle foretrekker jeg å bruke følgende mal:

Når {kontekst}, vil jeg {jobb} fordi jeg er {motivasjon}, slik at jeg kan {resultat}.

Her er betydningen av hver del av dette formatet:

Kontekst: Her gir vi litt bakgrunnsinformasjon, slik at de som skal lese denne jobbformuleringen, vet hvor og når denne jobben finner sted.

Hvis vi går tilbake til vår JTBD for en bærbar arbeidsdatamaskin, vil konteksten være begynnelsen, der vi fastslår at brukeren arbeider mens han eller hun er på reise. Denne konteksten hjelper oss med å forstå hvorfor brukeren foretrekker en bærbar datamaskin fremfor en stasjonær PC, og hvorfor det er viktig med god batteritid.

Jobb: Dette er den faktiske oppgaven brukeren ønsker å fullføre. Vi må passe på at vi ikke skriver noe her som representerer brukerreisen i stedet for jobben de ønsker å utføre. Disse to ser like ut ved første øyekast, og det er ganske lett å velge feil.

Se for deg at du skriver en JTBD for en app for hotellbestilling. Det ville høres naturlig ut å ha en jobb som sier «Jeg vil kunne registrere meg» eller «Jeg vil kunne søke etter hoteller». Dette er imidlertid ikke jobber (de er bare trinn i brukerreisen), og de representerer ikke på riktig måte den endelige oppgaven og fordelen brukerne ønsker å få fra appen din.

Den virkelige oppgaven ville i dette tilfellet være noe i retning av: «Jeg vil finne hoteller som passer budsjettet mitt og datoene for ferien min». Det er jo dette du til slutt ønsker å oppnå i en bestillingsapp, ikke sant? Å bestille riktig hotell.

Motivasjon: Dette er den grunnleggende årsaken til at brukerne dine trenger å fullføre denne jobben. Når du kjenner brukernes motivasjon, blir det lettere å forstå hvor frustrerte de føler seg når jobben ikke er fullført, og hvor glade eller tilfredse de blir når produktet ditt utfører jobben for dem.

Resultat: Til slutt har vi det endelige resultatet når brukeren har fullført jobben. Med et godt formulert resultat kan du visualisere hvordan suksess ser ut for kundene dine og sørge for at produktet ditt kan oppnå det brukerne forventet av det.

Nå som alle komponentene er tydelige, kan vi lage et eksempel på en JTBD ved å følge dette formatet.

Når jeg arbeider hjemmefra, vil jeg bruke en app som demper bakgrunnsstøy, fordi jeg føler meg utilpass når hunden min bjeffer i bakgrunnen under arbeidssamtaler, slik at jeg kan fremstå mer profesjonell overfor kollegene mine.

Jeg liker virkelig hvordan dette ser ut. Alt er tydelig, og du kan enkelt forstå hva kundene dine ønsker, og hvorfor de ønsker det.

Eksempler på produktsuksess ved bruk av JTBD

Takket være sin resultatorienterte tilnærming har JTBD blitt et populært verktøy både blant digitale produkter (som Apple og den ledende meldingsplattformen for kunder, Intercom) og fysiske produkter (som BOSCH), og har hjulpet mange av dem med å nå store høyder. La meg fortelle deg om suksesshistoriene til et par av dem.

Eksempel 1: Hvordan LeanStack brukte JTBD-rammeverket til å finne ut at de allerede hadde dekket kundenes jobber

Jeg hørte først om Ash Maurya gjennom et interessant rammeverk og verktøy som du kan bruke til å utforme forretningsplanen din – Lean Canvas.

Ved siden av å lage selve Lean Canvas begynte Ash snart å arbeide med en digital plattform, LeanStack, som skulle hjelpe gründere med å fylle ut en lean canvas på nettet og administrere informasjonen i den ved kontinuerlig å validere eller avkrefte hypotesene sine og oppdatere canvaset basert på denne læringen.

Denne programvaren for produktstyring hadde en god brukeropplevelse og et solid verdiforslag som traff kundenes smertepunkter. Derfor var den ganske populær, og gründere likte å bruke den til å finne den ideelle forretningsplanen for oppstartsbedriftene sine. Én måling var imidlertid ikke særlig god hos LeanStack – brukerbevaringen.

Ash la merke til at flertallet av brukerne snart forlot produktet og aldri kom tilbake. For å finne ut hvorfor begynte Ash å snakke med brukerne som hadde forlatt LeanStack, for å finne ut hvorfor de hadde brukt verktøyet, og hvorfor de sluttet å komme tilbake.

For å fastslå disse behovene brukte Ash JTBD-rammeverket og utarbeidet snart kjernejobbene som LeanStack-brukerne hadde i tankene da de abonnerte på produktet. Selv om de faktiske jobbutsagnene ikke er offentlige, kan jeg gjøre et kvalifisert gjetning på at de så omtrent slik ut:

Når jeg er i ferd med å utvikle en ny forretningsmodell, ønsker jeg å lage et Lean Canvas fordi jeg ser etter en strukturert måte å skissere antakelsene mine og teste ideene mine på, slik at jeg kan identifisere potensielle risikoer og muligheter, prioritere ressursene mine og bygge en skalerbar og bærekraftig virksomhet.

Så snart kjernejobbutsagnet for LeanStack var tydelig, forsto Ash årsaken til den lave brukerbevaringen – brukerne hadde ganske enkelt fullført jobbene sine og forlatt produktet.

Denne innsikten oppmuntret Ash til å begynne å utvikle supplerende produkter som kunne dekke jobbene som oppsto så snart gründerne hadde fullført jobben med å lage en forretningsmodell.

Én av disse jobbene handlet om oppstartsbedriftens vekstfase og så slik ut:

Når jeg starter en ny virksomhet, ønsker jeg å identifisere de mest effektive kanalene for å skape fremdrift for produktet eller tjenesten min, fordi jeg ønsker å oppnå fremdrift og utvide kundebasen min, slik at jeg kan oppnå bærekraftig og skalerbar vekst.

For å dekke denne jobben utviklet Ash veikartet for fremdrift, som var basert på rammeverket med samme navn.

Veikartet for fremdrift hjelper gründere med å beregne hvor mye fremdrift oppstartsbedriften trenger for å opprettholde eksponentiell vekst, noe både oppstartsbedrifter og investorer drømmer om.

Verktøyet kunne også vise hvilke måltall oppstartsbedriften måtte nå hvert kvartal for å nå målet sitt. Disse måltallene omfatter følgende:

• Antall henviste besøk, salgsbesøk og vanlige besøk samt konverteringsraten for disse
• Aktiveringsrate
• Konverteringsrate for inntekter
• Frafallsrate
• Brukerbevaring og mer

Det betyr at gründerne som brukte dette verktøyet, kunne omgjøre disse kvartalsvise målene for måltall til OKR-er for oppstartsbedriftene sine og fokusere innsatsen på å nå dem.

Jobbens natur og måten veikartet for fremdrift dekket den på, bidro til å øke brukerbevaringen i LeanStack betydelig, ettersom gründerne stadig kom tilbake til verktøyet for å gjennomgå den nåværende fremdriften og hente ut mål for det kommende kvartalet.

Eksempel nr. 2: Hvordan Kroll Ontrack brukte JTBD som en personamall for å finne ut hva som er viktig

Kroll Ontrack er en tjeneste som gjør det mulig for juridiske fagfolk å gå automatisk gjennom en enorm mengde juridiske dokumenter på nettet og oppdage lover, rettsavgjørelser, saker og annen viktig informasjon som de kan bruke i det daglige arbeidet sitt.

Tilbake i 2001, da produktet fortsatt var helt nytt, slet Kroll med å entre markedet for søk etter juridiske dokumenter, til tross for det store potensialet for vekst og inntekter der.

Men heldigvis forsto Kroll Ontrack raskt, etter å ha engasjert Strategyn Consulting til å analysere produktutviklingsprosessene og -praksisene deres grundig ved hjelp av rammeverket for resultatorientert innovasjon, at årsaken til utfordringene var at de ikke forsto kundenes behov godt nok.

Ledelsen startet derfor en intensiv prosess for kundeinnsikt, med mål om å definere brukerpersonaen til den juridiske eksperten som skulle kjøpe og bruke produktet deres. For å gjøre personadefinisjonen mer effektiv bestemte Kroll Ontrack seg for, i tillegg til å samle inn tradisjonelle data som kundedemografi, også å bruke Jobs To Be Done-rammeverket og malen for jobbutsagn.

Igjen finnes det ikke noe offentlig jobbutsagn for produktet, men basert på markedet de siktet seg inn mot og brukstilfellet ville det sett omtrent slik ut:

Når jeg arbeider med en juridisk sak, ønsker jeg en løsning for elektronisk dokumentgjennomgang som kan hjelpe meg med enkelt å finne relevant informasjon og bevis i digitale dokumenter, fordi jeg må bygge en sterk sak og kunne få tilgang til viktig informasjon raskt og effektivt.

Kroll Ontrack brukte imidlertid ikke bare ett jobbutsagn. Med tanke på hvor komplekst produktet de utviklet var, hadde de flere jobber de kunne dekke for både juridiske eksperter og andre spesialister som var involvert i dokumentgjennomgangsprosessen.

Resultatet av å bruke JTBD-rammeverket var at Kroll Ontrack kunne fokusere ressursene sine på å dekke disse jobbene og bli en ledende aktør i markedet.

Eksempel nr. 3: Hvordan BOSCH brukte JTBD til å rette seg mot riktig marked med sirkelsagen sin

Du leste riktig! Ja, folk bruker ikke bare JTBD for digitale produkter, og dette eksempelet handler om den tyske giganten innen elektroverktøy, BOSCH, og en usedvanlig populær sirkelsag de utviklet – CS20. Slik ser den ut.

Denne historien kan virke litt uvanlig for deg som er produktleder for digitale produkter. Prosessen med produktoppdagelse, utvikling og å oppnå produkt–markedstilpasning er imidlertid svært lik den som også brukes av digitale oppstartsbedrifter.

Historien begynner da BOSCH bestemmer seg for å gå inn i det amerikanske markedet med elektroverktøyene sine. De var spesielt interessert i det lukrative markedet for sirkelsager. Dette markedet var relativt mettet av lokale og internasjonale merkevarer.

For å kunne konkurrere med disse etablerte aktørene og sikre seg sin egen del av markedet bestemte BOSCH seg for å gjennomføre markedsundersøkelser og analysere behovene til kundegruppen som til slutt skulle kjøpe produktet – tømrere.

De brukte rammeverket for oppgaver som skal utføres til å identifisere de ulike jobbene tømrerne skulle utføre ved hjelp av sirkelsager. Det de fant, var et bredt spekter av oppgaver, fra den vanlige produksjonen av planker fra oppsagde tømmerstokker til det delikate trearbeidet utført av møbelmestere.

De kunne ikke dekke alle disse jobbene. Derfor analyserte de også hvordan de eksisterende alternativene kunne dekke hver jobb, og bestemte seg for å fokusere på jobben som var dårligst dekket:

Skjæring av treverk med finishkvalitet i en rett linje og i vinkel.

Takket være riktig identifisering av et spesifikt kundebehov og utviklingen av en sag som kunne utføre jobben perfekt, ble BOSCHs CS20 snart et av de mest populære verktøyene blant tømrere.

Eksempel nr. 4: Hvordan Microsoft revitaliserte Assurance-virksomheten sin med JTBD

Den neste historien handler om giganten Microsoft og Software Assurance-virksomheten deres, som nylig opplevde en betydelig nedgangsperiode.

For å redde virksomheten begynte Microsoft å undersøke de grunnleggende årsakene til nedgangen ved å intervjue både eksisterende brukere og brukere som hadde sluttet. Det de fant, var høy grad av misnøye med måten Microsoft håndterte lisensiering av tjenesten på, samt et bredt spekter av dårlig dekkede jobber.

Ved hjelp av JTBD-rammeverket definerte de raskt jobbene kundene hadde, og prioriterte dem ut fra hvor utilfredsstilte de var. Deretter begynte de å løse disse udekkede behovene med nye produktfunksjoner, forbedret introduksjon for eksisterende funksjoner og generelt god brukeropplevelse.

Her er to av de mange ulike jobbene de fant.

Innkjøpsansvarlige trenger å administrere virksomhetens programvarelisenser effektivt, samtidig som de minimerer kostnadene og holder seg innenfor budsjettet.

IT-ansvarlige trenger å sørge for at utrulling og oppdateringer av programvare skjer smidig og uten feil, samtidig som de minimerer påvirkningen på sluttbrukerne.

For å dekke disse jobbene la de til muligheten for å administrere nåværende og tidligere lisenser, samt se og håndtere eventuelle programvarekonflikter ved bruk av disse lisensene.

Resultatet av denne innsatsen var en vellykket revitalisering av Software Assurance-virksomheten, som begynte å vokse og utvikle en sunn bunnlinje.

Eksempel nr. 5: Hvordan Clarity brukte JTBD til å forbedre effektiviteten i kundeoppdagelsen

Clarity er en nettbasert markedsplass for gründere og oppstartsgründere. Markedsplassen kobler brukere med eksperter innen spesifikke fagområder, slik at de kan komme i kontakt, få råd og søke veiledning gjennom samtaler arrangert av Clarity.

Grunnleggeren, Dan Martell, er en forkjemper for JTBD-rammeverket og brukte det aktivt under kundeoppdagelsesøktene for produktet (før han solgte Clarity til Fundable i 2015).

Ifølge Dan har JTBD gjort det mulig for Clarity-teamet å fokusere tankegangen sin og måten de intervjuer brukere på, på de faktiske behovene og jobbene disse brukerne trenger å få dekket ved å ta i bruk Clarity.

Dan oppdaget snart at brukerne før de ble med i Clarity, benyttet alternative løsninger som å delta i faglige fellesskap på LinkedIn og på bransjemesser og fagkonferanser.

Dette var en gullgruve for Clarity-teamet, ettersom de kunne spørre brukerne sine om disse alternative løsningene faktisk dekket oppgavene deres på en god måte, og undersøke hvilke aspekter som ikke ble godt nok ivaretatt – slik at de kunne konsentrere seg om å utvikle løsninger som håndterte disse områdene.

JTBD hjelper deg med å bli bedre kjent med brukerne dine

Som vi kan se av de fem eksemplene ovenfor, har JTBD-rammeverket vist seg å være et svært effektivt verktøy for interessenter, gründere og produktledere. Å bruke dette rammeverket er en enkel og effektiv måte å identifisere kundenes grunnleggende behov og ønsker på, og sørge for at produktet du utvikler, er noe brukerne med glede vil «ansette» til å håndtere oppgavene de har.

JTBD er blant de mange verdifulle rammeverkene for produktledelse som du kan vurdere å bruke i det daglige arbeidet ditt.

For videre lesning om JTBD anbefaler jeg å se nærmere på følgende forfattere:

• Markedsføringsnærsynthet av Theodore Levitt
• Disruptiv innovasjon fra Harvard Business School av Clayton Christensen
• Jobber som skal gjøres-metodikken av Bob Moesta

Hvis du ikke har tid til å lese disse bøkene, kan du i stedet dra nytte av vår korte produktoppsummering ved å abonnere på nyhetsbrevet vårt.