Ideen om at brukere «ansetter» et produkt, kan høres litt merkelig ut til å begynne med. Dette kan til og med ha fått deg til å tro at det såkalte rammeverket for jobber som skal gjøres er en slags intern spøk for produktledere.
I virkeligheten er imidlertid jobber som skal gjøres (også kjent som jobs-to-be-done, JTBD eller jobbs-teori) ikke bare noe som faktisk eksisterer, men også et av de mest effektive og virkningsfulle rammeverkene du kan bruke til å utvikle produktene dine.
Som senior produktleder med praktisk erfaring med å bruke JTBD-teorien i praksis, kan jeg si dette: Når du lærer å bruke denne fascinerende metodikken, vil det fullstendig endre hvordan du tenker på produktet ditt.
Prinsipper for jobbs-teori
Før vi ser på strukturen i dette rammeverket og forklarer deg hvordan du bruker det, vil jeg introdusere deg for kjerneideene og prinsippene bak det. Dette skal hjelpe deg med å forstå essensen i rammeverket, i stedet for bare å få deg til å memorere trinnene i implementeringen.
Veteraner innen produktutvikling og ledelse hevder at den første «måten å tenke på» bak JTBD kan spores tilbake til 1960-tallet, da den berømte Harvard Business School-professoren og markedsføringsforskeren Theodore Levitt lanserte konseptet «ønskede resultater» og sa denne berømte setningen:
Det geniale med denne måten å tenke på er hvordan du begynner å tilnærme deg produktutvikling.
Spotify ønsket å gå inn i musikkbransjen. I stedet for å opprette en markedsplass der de skulle selge sanger, slik iTunes gjorde på den tiden, innså de imidlertid at det folk ønsket, var å kunne lytte til musikk – ikke å kunne kjøpe den.
Dermed fikk de frihet til å bygge noe som var fundamentalt annerledes (og bedre) enn musikkbutikker – en strømmetjeneste som balanserte en bærekraftig forretningsmodell med brukernes ønskede resultat: å lytte til musikk.
Siden opprinnelsen på 60-tallet har tilnærmingen med å prioritere ønskede resultater blitt betydelig videreutviklet, og mange kjente ledelseseksperter og forskere har bygget sine egne rammeverk og «filosofier» på dette grunnlaget.
Noen av de viktigste milepælene var:
Clayton Christensens idé om disruptiv innovasjon, som han lanserte i boken sin «Innovatørens dilemma». Clayton påpekte at all innovasjon som endrer verden, begynner med å dekke behovene til en liten gruppe kunder (også kalt tidlige brukere), for deretter å forbedre løsningen slik at den kan dekke de ekstra behovene til større grupper av brukere som kommer senere.
Det sentrale poenget med denne strukturen, «begynn i en nisje og utvid deretter», var grunnleggernes og produktledernes evne til å identifisere behovene og de ønskede resultatene til nisjebrukerne på riktig måte, og deretter gjøre det samme for det bredere publikummet.
Bob Moestas «kamp-først»-tilnærming, som han beskrev i boken «Etterspørselsdrevet salg 101: Slutt å selge og hjelp kundene dine med å gjøre fremskritt». Bob hevder at kunder hele tiden forsøker å gjøre fremskritt i livet, enten det gjelder økonomi, forhold eller noe annet, og at de møter en rekke utfordringer på veien. Dyktige produktledere er i stand til å se disse utfordringene og tilby produkter som brukerne kan «ansette» for å håndtere dem.
Tony Ulwicks rammeverk for resultatdrevet innovasjon (ODI) (her er en god artikkel fra Harvard Business Review om dette). Ifølge Tony er den avgjørende faktoren som driver beslutningsprosessen hos kundene, de endelige resultatene de ønsker å oppnå ved å bruke produktet ditt.
Ideen er at når kundene kan velge mellom flere konkurrerende produkter, vil de ende opp med det som best kan hjelpe dem med å oppnå de ønskede resultatene.
Hvordan fungerer JTBD?
Med alle disse ideene og rammeverkene i tankene kommer vi endelig frem til JTBD. Det finnes flere tolkninger av JTBD-teorien, og alle er ganske gode, men personlig foretrekker jeg Tonys versjon, som han beskriver i boken «Jobber som skal gjøres: Fra teori til praksis».
Ifølge ham må kundene utføre en «jobb» som gjør det mulig for dem å oppnå det ønskede resultatet. De kan utføre denne jobben ved å bruke ulike fremgangsmåter og løsninger, inkludert å «ansette» produkter som kan håndtere jobben for dem.
Hvis vi visualiserer dette konseptet, ser det slik ut:
Utgangspunktet for kundene dine er den ikke-ideelle nåsituasjonen som ikke tilfredsstiller dem. For eksempel er denne nåsituasjonen for en kundestøtteagent som jobber hjemmefra, stuen hennes, der hun vanligvis utfører arbeidet sitt, ettersom leiligheten hennes ikke har et eget hjemmekontor.
Hvorfor er dette en ikke-ideell nåsituasjon? Jo, på grunn av all bakgrunnsstøyen fra hunden, barna og naboene er hun bekymret for at hun kan høres uprofesjonell ut under kundestøttesamtalene.
Hun har derfor det ønskede resultatet at kundestøttesamtalene skal være fri for støy.
For å oppnå dette må hun endre sin nåværende situasjon og gjøre fremskritt mot det ønskede resultatet ved å redusere bakgrunnsstøyen. Dette er en jobb hun må få utført.
En måte er å holde alle ute av stuen – men det er mye å forlange gjennom en hel arbeidsdag i en liten leilighet. En annen måte er å flytte ut av leiligheten og inn i en som har et lydisolert hjemmekontor – men det er arbeidskrevende, stressende og medfører mange langsiktige kostnader. Til slutt finnes muligheten for å leie støydempingsprogramvare for å fjerne all støy i sanntid.
Når hun tar kostnadene ved de alternative løsningene i betraktning, ville hun mer enn gjerne betale tolv dollar i måneden for en slik tjeneste!
Støydempingsprogramvaren har dermed fullført jobben hennes med å fjerne bakgrunnsstøy fra samtalene og hjulpet henne med å oppnå det ønskede resultatet: å ta samtaler uten forstyrrelser.
Have an account? Log In
Lovene i JTBD
I sin definisjon av JTBD-rammeverket på konsulentselskapet Strategyns nettsted trekker Tony frem et par interessante «fakta» om disse jobbene som kan hjelpe oss med å forstå essensen av JTBD ytterligere.
- En jobb forblir den samme over tid. Tidligere ansatte folk notatskrivere til å ta notater for seg under møter. Nå ansetter de i stedet verktøy for AI-oppsummering. Ulike løsninger, samme jobb.
- Jobber er «løsningsagnostiske». Det betyr at kundene kan leie inn ulike typer løsninger for å håndtere den samme jobben. Det betyr også at produktet ditt ikke trenger å ligne på det konkurrentene tilbyr for å kunne utføre jobben godt.
- Den beste løsningen får alltid jobben. Hvis det finnes konkurranse, er vinneren produktet som håndterer jobben bedre, raskere eller billigere (eller en kombinasjon av disse tre).
- Folk ønsker én enkelt løsning for én enkelt jobb. Kundene foretrekker produkter som kan dekke hele jobben fra start til slutt, og vil unngå tilfeller der det kreves flere produkter for å håndtere jobben.
For å oppsummere bygger rammeverket for jobber som skal utføres på ideen om at det folk egentlig ønsker, er de endelige resultatene, ikke verktøyene de bruker for å oppnå dem.
De bryr seg imidlertid om prosessen. For å hjelpe dem med å nå de endelige målene sine må de utføre bestemte oppgaver (eller jobber), og de er klare til å leie inn noen eller noe (en tjeneste eller programvare) til å håndtere disse jobbene for dem.
Ved å identifisere disse jobbene og tilpasse produktene dine slik at de håndterer dem sømløst, øker du sannsynligheten for at folk vil betale for produktet ditt og bruke det kontinuerlig.
Slik bruker du JTBD-rammeverket i den daglige produktutviklingen
Forhåpentligvis er det tydelig hvor viktig det er å forstå essensen av JTBD-rammeverket før du lærer hvordan du bruker det, ettersom de følgende trinnene gir langt mer mening i denne sammenhengen.
Det jeg skal dele med deg, er ikke den «klassiske» versjonen av JTBD (som du kan lese om i de mange bøkene som er nevnt ovenfor).
I stedet vil jeg dele varianten av JTBD som jeg med hell har brukt i praksis for noen av produktene mine.
Her er et eksempel på jobber som skal utføres fra min egen yrkeserfaring.
Lær om kundenes behov og ønskede resultater
Hjertet i ethvert vellykket produkt er godt gjennomført brukerundersøkelse. Når man tar i betraktning hvor avhengig JTBD er av ideen om at «folk ønsker resultater, ikke verktøy», bør du alltid begynne med å identifisere brukerne dine og lære om hva de ønsker.
Jeg har ingen spesifikk måte å gjennomføre denne undersøkelsen på som er «tilpasset JTBD». I stedet har produktteamet mitt og jeg basert oss på de tradisjonelle metodene våre og verktøyene våre for å lære om brukerne. Den eneste forskjellen var at vi fokuserte spørsmålene våre på å finne ut hvilket endelig resultat brukerne våre ønsket å oppnå.
La meg dele et eksempel fra tjenesten for nettbaserte push-varsler som vi jobbet med.
Merk: Dette verktøyet lar nettsteder sende push-varsler til de besøkende. Det var en ny og lønnsom markedskanal som nettsteder kunne bruke til å markedsføre produktene sine.
For å utvikle brukerpersonaene for denne tjenesten intervjuet vi personer som hadde brukt produktene til våre direkte og indirekte konkurrenter. Når du intervjuet en bruker av en konkurrent, ville du tradisjonelt stille spørsmål som dette:
Selv om vi også stilte disse spørsmålene under intervjuene våre, var hovedfokuset vårt å få svar på disse:
Og det var en god grunn til at vi intervjuet både direkte konkurrenter (f.eks. OneSignal og iZooto) og indirekte konkurrenter (f.eks. Mailchimp og Twilio). Vi nevnte tidligere at jobber og ønskede resultater er løsningsuavhengige. Det betydde at svarene vi ville få om resultatet, ville være de samme (eller i det minste lignende), uavhengig av hvilket verktøy intervjupersonene våre brukte.
Det var akkurat det vi fikk. Det viste seg at det vanligste ønskede resultatet for målmarkedet vårt (som på det tidspunktet var nettbutikker) var å redusere antallet såkalte «forlatte handlekurver» – når folk legger produkter i handlekurven og lar dem ligge der i dagevis eller ukevis.
Jobben som både e-posttjenester og tjenester for nett-pushvarsler gjorde for dem, var å minne brukerne på den forlatte handlekurven og tilby en rabatt hvis de kom tilbake og gjennomførte kjøpet.
Dette bestemte vi oss til slutt for å fokusere på, og vi utviklet et produkt som kunne gjøre det bedre enn alle andre.
Eksempelet jeg nevnte ovenfor, handlet om brukerintervjuer, men det er ikke den eneste måten du kan finne ut hva kundene dine ønsker. Du kan også vurdere å gjennomføre:
- Markedsundersøkelser sammen med kartlegging av ulike kundesegmenter og demografiske kjennetegn.
- Brukerundersøkelser som du kan gjennomføre ved hjelp av vår kuraterte liste med spørsmål til undersøkelser.
- Intervjuer i fokusgrupper, der du inviterer en utvalgt gruppe mennesker til å diskutere behovene og erfaringene sine med deg.
Men uansett hvilken type kundeinnsikt du arbeider med, må du alltid huske å prioritere spørsmålene som avdekker de endelige resultatene kundene dine ønsker å oppnå.
Formulere jobbutsagnet
Som et resultat av all innsikten du har samlet inn fra intervjuene og undersøkelsene våre, bør du ha en ganske god forståelse av både resultatene brukerne dine ønsker, og oppgavene de vanligvis utfører for å nå dem.
Nå er det på tide å konkretisere denne innsikten ved å formulere hovedleveransen i JTBD-metodikken – et jobbutsagn. Slik ser det ut:
Dette formatet for å beskrive resultater og jobber er svært nyttig, ettersom det inneholder viktig informasjon som:
- Situasjonen og omgivelsene der kunden opplever et problem. I vårt tilfelle var det personer som forlot handlekurvene sine.
- Jobben kunden vår må utføre for å oppnå det ønskede resultatet. For eiere av nettbutikker handlet det om å sende påminnelsesmeldinger til dem som hadde forlatt handlekurvene sine.
- Den emosjonelle og rasjonelle grunnen bak kundens ønske om å oppnå resultatet. Hvis folk legger produkter i handlekurvene sine og glemmer dem, er dette tapte potensielle inntekter for kundene våre, og de har en rasjonell grunn til å redusere antallet slike tilfeller.
- Til slutt har vi det ønskede resultatet. I dette eksempelet ønsket butikkeierne å bli kvitt disse forlatte handlekurvene.
Du har kanskje lagt merke til at vi brukte begrepet «påminnelsesmeldinger» i stedet for «påminnelses-e-poster» for pushvarsler. Grunnen er at kundene våre egentlig ikke brydde seg om den fysiske kanalen meldingen ble sendt gjennom, så lenge den faktisk reduserte andelen forlatte handlekurver.
Opprette et jobbkart
Dokumentasjon av mange av kundenes jobber som skal gjøres og resultatutsagn er en prestasjon i seg selv. Men det er bare halve jobben, ettersom du må omforme disse jobbene til et godt verdiforslag, nye produktkrav (inkludert et veikart) og en god brukeropplevelse.
Til dette kan vi dra nytte av en annen JTBD-leveranse – jobbkartet.
Jobbkartet er den visuelle fremstillingen av hele reisen kundene må gjennomføre for å fullføre jobben sin på en vellykket måte. Det fungerer som et mellomledd mellom jobbutsagnene dine og kundereisekartet eller produktkravene du skal overlevere til utviklingsteamet ditt.
Her er et eksempel på en mal for et jobbkart utviklet av GitLab.
Strukturen ovenfor er utviklet av Tony Ulwich, som foreslo å bruke den til å kartlegge jobber i rammeverket sitt for resultatdrevet innovasjon.
La meg nå fylle ut dette for deg med Spotify som eksempel, og jobben «Kunden lager en tilpasset spilleliste for sitt bestemte humør».
- Definer: Brukerne forstår at de trenger en personlig spilleliste basert på humøret sitt.
- Finn: De finner funksjonen for å opprette spillelister og navigerer dit.
- Forbered: Brukerne søker etter og velger sangene de ønsker å legge til i spillelisten.
- Bekreft: De går gjennom spillelisten for å forsikre seg om at alle sangene de ønsket for humøret sitt, er med.
- Utfør: Brukerne lagrer spillelisten og gir den et navn.
- Overvåk: De ser på måltall som antall avspillinger og likerklikk for å vurdere hvor populær spillelisten er.
- Endre: Brukerne innarbeider tilbakemeldinger fra andre i spillelistene sine ved å legge til eller fjerne sanger.
- Avslutt: Når de opplever humøret spillelisten ble laget for, slår brukerne den på og nyter musikken.
Avhengig av hvilken jobb du ønsker å kartlegge, kan du vurdere å utelate noen av trinnene her dersom du mener at brukerne ikke trenger å utføre noen bestemt handling i det aktuelle trinnet.
More Articles
Skap en løsning som folk vil «ansette» for den jobben
Endelig har vi kommet til punktet der du kan lage vanlige leveranser innen produktledelse, som PRDs, design, brukerhistorier og mer, ved å bruke din daglige programvare for produktledelse.
Du har allerede listen over trinnene brukerne dine tar for å dekke behovene de ikke får oppfylt, så alt du trenger å gjøre, er å lage funksjoner som dekker de nødvendige handlingene brukerne utfører i hvert trinn.
For «forbered»-trinnet i den spesifikke jobben ovenfor må du for eksempel utvikle en funksjon som lar brukerne søke etter sanger, filtrere andre brukeres spillelister og legge disse sangene inn i sin egen spilleliste.
I tillegg til å utvikle funksjoner som dekker jobbene dine, må du ikke glemme de mer «administrative» funksjonene heller, som prissetting og betalingslogikk, kundeopplevelsen knyttet til håndtering av data og konto, samt muligheten til å få tilgang til kundestøtte.
Det handler om å gjøre produktet ditt «ansettbart»
Jobber som skal gjøres (JTBD) er et fremragende rammeverk og en fremragende måte å tenke på, fordi det hjelper deg med å fokusere innsatsen på funksjoner som gjør produktet ditt mer attraktivt for brukere som ønsker å «ansette» deg til å håndtere jobbene sine.
Uansett om du er i en oppstartsbedrift eller i en teknologigigant (som Intercom eller Microsoft), kan jeg forsikre deg om at JTBD vil hjelpe deg med å øke effekten av arbeidet ditt innen produktledelse. Hvis du likte å lese tankene mine om JTBD, bør du abonnere på vårt nyhetsbrev for å få lignende innhold i innboksen din.
