Skip to main content

Idén om att användare ”anställer” en produkt kan låta lite märklig till en början. Det kan till och med ha fått dig att tro att det så kallade ramverket för jobb som ska utföras bara är ett internt skämt bland produktchefer.

I verkligheten är dock jobb som ska utföras (även kallat jobb som ska utföras, JTBD eller jobbteorin) inte bara något verkligt, utan också ett av de mest effektiva och betydelsefulla ramverk du kan använda för att utveckla dina produkter.

Som senior produktchef med praktisk erfarenhet av att tillämpa JTBD-teorin vill jag säga följande: att lära sig använda denna fascinerande metodik kommer helt att förändra hur du tänker kring din produkt.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

Principerna bakom teorin om jobb som ska utföras

Innan vi tittar på strukturen i detta ramverk och går igenom hur du använder det vill jag introducera dig till de grundläggande idéerna och principerna bakom det. Syftet är att hjälpa dig förstå ramverkets kärna, i stället för att bara få dig att memorera stegen i implementeringen.

Veteraner inom produktutveckling och företagsledning hävdar att det första ”sättet att tänka” bakom JTBD går tillbaka till 1960-talet, när den berömde professorn vid Harvard Business School och marknadsföringsforskaren Theodore Levitt lanserade konceptet ”önskade resultat” och yttrade denna berömda fras:

"Människor vill inte ha en borr med en diameter på 1/4 tum, de vill ha ett hål med en diameter på 1/4 tum."

Det geniala med detta sätt att tänka är hur du börjar närma dig produktutveckling.

Spotify ville ta sig in i musikbranschen. I stället för att skapa en marknadsplats där de skulle sälja låtar, precis som iTunes gjorde på den tiden, insåg de dock att det människor ville var att kunna lyssna på musik, inte att kunna köpa den.

Därför fick de friheten att bygga något som var fundamentalt annorlunda och bättre än musikbutiker – en strömningstjänst som balanserade en hållbar affärsmodell med användarnas önskade resultat: att lyssna på musik.

Sedan sitt ursprung på 1960-talet har angreppssättet att prioritera önskade resultat utvecklats avsevärt, samtidigt som många berömda experter och forskare inom företagsledning har byggt sina egna ramverk och ”filosofier” kring det.

Några av de mest framträdande milstolparna var:

Clayton Christensens idé om omvälvande innovation , som han lanserade i sin bok  ”Innovatörens dilemma”. Clayton noterade att all innovation som förändrar världen börjar med att tillgodose behoven hos en liten grupp kunder, så kallade tidiga användare, och därefter förbättra lösningen så att den kan tillgodose ytterligare behov hos större grupper av användare som kommer senare.

Den centrala punkten i denna struktur – ”börja i en nisch och expandera sedan” – var grundarnas och produktchefernas förmåga att korrekt identifiera behoven och de önskade resultaten hos användarna i nischen och sedan göra samma sak för den bredare målgruppen.

Bob Moestas ”kampen först”-angreppssätt, som han beskrev i sin bok ”Efterfrågebaserad försäljning 101: Sluta sälja och hjälp dina kunder att göra framsteg”. Bob hävdar att kunder ständigt försöker göra framsteg i sina liv, oavsett om det gäller ekonomi, relationer eller något annat, och att de möter många hinder på vägen. Framgångsrika produktledare kan se dessa hinder och erbjuda produkter som användarna kan ”anställa” för att hantera dem åt dem.

Tony Ulwicks ramverk för resultatdriven innovation (ODI) (här är en bra artikel i Harvard Business Review om det). Enligt Tony är den yttersta faktorn som driver beslutsprocessen hos kunderna de slutliga resultat som de vill uppnå genom att använda din produkt.

Idén är att kunder, när de kan välja mellan flera konkurrerande produkter, till slut väljer den som bäst kan hjälpa dem att nå sina önskade resultat.

Hur fungerar JTBD?

Med alla dessa idéer och ramverk i åtanke kommer vi slutligen fram till JTBD. Det finns flera tolkningar av JTBD-teorin, och alla är ganska bra, men personligen föredrar jag Tonys version, som han beskriver i sin bok ”Jobb som ska utföras: Från teori till praktik”.

Enligt honom behöver kunder utföra ett ”jobb” som gör det möjligt för dem att nå sitt önskade resultat. De kan utföra detta jobb genom att använda olika vägar och lösningar, inklusive att ”anställa” produkter som kan hantera jobbet åt dem.

Om vi visualiserar detta koncept ser det ut så här:

infografik över jobbet som ska utföras

Utgångspunkten för dina kunder är det icke-ideala nuläget som inte tillfredsställer dem. För en kundsupportagent som arbetar hemifrån är detta nuläge till exempel hennes vardagsrum, där hon vanligtvis utför sitt arbete eftersom hennes lägenhet inte har ett särskilt hemmakontor.

Varför är det ett icke-idealt nuläge? Jo, på grund av allt bakgrundsljud från hunden, barnen och grannarna oroar hon sig för att låta oprofessionell under supportsamtalen med sina kunder.

Därför har hon det önskade resultatet att kunna ha supportsamtal utan störande ljud.

För att åstadkomma detta behöver hon förändra sin nuvarande situation och göra framsteg mot sitt önskade resultat genom att minska bakgrundsljudet. Detta är ett jobb som hon behöver utföra.

Ett sätt är att hålla alla borta från vardagsrummet – men det är svårt att genomföra under en hel arbetsdag i en liten lägenhet. Ett annat sätt är att flytta från sin lägenhet till en som har ett ljudisolerat hemmakontor – men det är arbetskrävande, stressigt och medför många långsiktiga kostnader. Slutligen finns möjligheten att anlita programvara för brusreducering som tar bort allt ljud i realtid.

Med tanke på kostnaden för de alternativa lösningarna skulle hon mer än gärna betala ett tiotal dollar i månaden för den här typen av tjänst!

På så sätt har programvaran för brusreducering framgångsrikt utfört hennes jobb genom att ta bort bakgrundsljud från hennes samtal och hjälpt henne att nå det önskade resultatet: att kunna ta samtal utan störande moment.

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

Lagarna för JTBD

I sin definition av JTBD-ramverket på konsultföretaget Strategyns webbplats tar Tony upp ett par intressanta ”fakta” om dessa jobb som kan hjälpa oss att ytterligare förstå kärnan i JTBD.

  1. Ett jobb förblir detsamma över tid. Förr anlitade människor protokollförare för att anteckna åt dem under möten. Nu anlitar de i stället verktyg för AI-sammanfattningar. Olika lösningar, samma jobb.
  2. Jobb är ”lösningsoberoende”. Det innebär att kunder kan anlita olika typer av lösningar för att hantera samma jobb. Det innebär också att din produkt inte behöver likna det dina konkurrenter erbjuder för att kunna utföra jobbet väl.
  3. Den bästa lösningen får alltid jobbet. Om det finns konkurrens är vinnaren den produkt som hanterar jobbet bättre, snabbare eller billigare (eller någon kombination av dessa tre).
  4. Människor vill ha en enda lösning för ett enda jobb. Kunder föredrar produkter som kan täcka hela jobbet från början till slut och undviker situationer där det krävs flera produkter för att hantera jobbet.

Sammanfattningsvis bygger ramverket Jobb som ska utföras på idén att det människor verkligen vill ha är de slutliga resultaten, snarare än verktygen de använder för att uppnå dem.

De bryr sig dock om processen. För att hjälpa dem att nå sina slutliga mål behöver de utföra vissa uppgifter (eller jobb), och de är redo att anlita någon eller något (en tjänst eller programvara) som hanterar dessa jobb åt dem.

Genom att identifiera dessa jobb och anpassa dina produkter så att de hanterar dem på ett smidigt sätt ökar du sannolikheten för att människor betalar för din produkt och använder den kontinuerligt.

Så använder du JTBD-ramverket i den dagliga produktutvecklingen

Förhoppningsvis är det tydligt hur viktigt det är att förstå kärnan i JTBD-ramverket innan du lär dig att använda det, eftersom följande steg blir mycket mer begripliga i sitt sammanhang.

Det jag nu ska dela med mig av är inte den ”klassiska” versionen av JTBD (som du kan läsa om i de många böcker som nämndes ovan).

I stället vill jag dela med mig av den variant av JTBD som jag framgångsrikt har använt i verkligheten för några av mina produkter.

Här är ett exempel på jobb som ska utföras från min egen yrkeserfarenhet.

Lär känna kundernas behov och önskade resultat

Kärnan i varje framgångsrik produkt är väl genomförd användarundersökning. Med tanke på hur beroende JTBD är av tanken att ”människor vill ha resultat, inte verktyg” bör du alltid börja med att identifiera dina användare och ta reda på vad de vill ha.

Jag har inget särskilt sätt att genomföra denna undersökning som är ”anpassat för JTBD”. I stället har mitt produktteam och jag förlitat oss på våra traditionella metoder och verktyg för att lära känna användare. Den enda skillnaden var att vi fokuserade våra frågor på att upptäcka det slutliga resultat som våra användare ville uppnå.

Låt mig dela med mig av ett exempel från den tjänst för webbpushnotiser som vi arbetade med.

Obs! Med det här verktyget kan webbplatser skicka pushnotiser till sina besökare. Det var en ny lönsam marknadsföringskanal som webbplatser kunde använda för att marknadsföra sina produkter.

För att utveckla användarpersonerna för den här tjänsten intervjuade vi personer som hade använt våra direkta och indirekta konkurrenters produkter. När du intervjuar en konkurrentproduktens användare brukar du traditionellt ställa frågor som dessa:

Vilka är de tre sakerna du hatar med {competitor}?Vilka är de tre sakerna du älskar?Vilka faktorer eller förbättringar skulle få dig att överväga att byta från {competitor} till en annan lösning?

Även om vi ställde de här frågorna under våra intervjuer också, låg vårt huvudsakliga fokus på att få svar på följande:

Varför använder du {competitor}? Vilket slutresultat och vilken nytta får du av det?Hur ofta behöver du uppnå detta resultat?Hur mäter du framgång eller avgör om {competitor} uppfyller dina behov?

Och det fanns en god anledning till att vi intervjuade både direkta (t.ex. OneSignal och iZooto) och indirekta (t.ex. Mailchimp och Twilio) konkurrenter. Vi nämnde tidigare att jobb och önskade resultat är lösningsoberoende. Det innebar att svaren vi fick om resultatet skulle vara desamma (eller åtminstone likna varandra), oavsett vilket verktyg våra intervjupersoner använde.

Det var precis vad vi fick. Det visade sig att det vanligaste önskade resultatet för vår målmarknad (som vid den tidpunkten bestod av e-handelsbutiker) var att minska antalet så kallade ”övergivna kundvagnar” – när människor lägger produkter i sin kundvagn och lämnar dem där i dagar eller veckor.

Det jobb som både e-post- och web push-notistjänster utförde åt dem var att påminna användarna om den övergivna kundvagnen och erbjuda en rabatt om de kom tillbaka och genomförde köpet.

Det här var vad vi till slut bestämde oss för att fokusera på, och vi byggde en produkt som kunde göra det bättre än någon annan.

Infografik om att lära sig kundernas behov och önskade resultat

Exemplet jag tog upp ovan handlade om användarintervjuer, men det är inte det enda sättet att ta reda på vad dina kunder vill ha. Du kan också överväga att genomföra:

  • Marknadsundersökningar tillsammans med kartläggning av olika kundsegment och demografiska grupper.
  • Användarundersökningar som du kan genomföra med hjälp av vår sammanställda lista med enkätfrågor.
  • Intervjuer i fokusgrupper, där du bjuder in en utvald grupp människor för att diskutera sina behov och erfarenheter med dig.

Men oavsett vilken typ av kundundersökning du genomför ska du alltid komma ihåg att prioritera de frågor som avslöjar vilka slutresultat dina kunder vill uppnå.

Formulera jobbformuleringen

Som ett resultat av alla insikter du har samlat in från våra intervjuer och undersökningar bör du ha en ganska god förståelse för både de resultat dina användare vill uppnå och de uppgifter de vanligtvis utför för att nå dem.

Nu är det dags att konkretisera dessa insikter genom att formulera det huvudsakliga resultatet av JTBD-metoden – en jobbformulering. Så här ser den ut:

Infografik om att formulera jobbformuleringen

Det här formatet för att beskriva resultaten och jobben är mycket användbart eftersom det innehåller viktig information som:

  • Situationen och miljön där kunden upplever ett problem. I vårt fall handlade det om människor som övergav sina kundvagnar.
  • Det jobb som kunden behöver utföra för att nå det önskade resultatet. För e-handelsägare handlade det om att skicka påminnelsemeddelanden till dem som hade övergett sina kundvagnar.
  • Den känslomässiga och rationella anledningen bakom kundens önskan att nå resultatet. Om människor lägger produkter i sina kundvagnar och glömmer bort dem innebär det förlorade potentiella intäkter för våra kunder, och de har en rationell anledning att minska antalet sådana fall.
  • Slutligen har vi det önskade resultatet. I det här exemplet ville butiksägarna bli av med dessa övergivna kundvagnar.

Du kanske lade märke till att vi använde termen ”påminnelsemeddelanden” i stället för ”påminnelsemeddelanden via e-post” för pushnotiser. Anledningen är att våra kunder egentligen inte brydde sig om den fysiska kanalen som användes för att skicka meddelandet, så länge den effektivt minskade andelen övergivna kundvagnar.

Skapa en jobbkarta

Att dokumentera många av dina kunders jobb som ska utföras och resultatbeskrivningar är en bedrift i sig. Men det är bara halva kampen, eftersom du behöver omvandla dessa jobb till ett bra värdeerbjudande, nya produktkrav (inklusive en färdplan) och en användarupplevelse.

För detta kan vi dra nytta av ytterligare ett resultat från JTBD – jobbkartan.

Jobbkartan är den visuella representationen av hela den resa som dina kunder behöver genomföra för att framgångsrikt slutföra sitt jobb. Den fungerar som ett mellanliggande steg mellan dina jobbformuleringar och kundresan eller produktkraven som du överlämnar till ditt utvecklingsteam.

Här är ett exempel på en mall för en jobbkarta utvecklad av GitLab.

Skärmbild av jobbkarta utvecklad av GitLab
Källa: GitLab

Strukturen ovan är skapad av Tony Ulwick, som föreslog att den skulle användas för att kartlägga jobb i sitt resultatdrivna innovationsramverk.

Låt mig nu fylla i den åt dig med Spotify som exempel och jobbet ”Kund skapar en anpassad spellista för sitt specifika humör”.

  • Definiera: Användarna förstår att de behöver ha en personlig spellista baserad på sitt humör.
  • Lokalisera: De hittar funktionen för att skapa spellistor och navigerar dit.
  • Förbereda: Användarna söker efter och väljer de låtar som de vill lägga till i spellistan.
  • Bekräfta: De granskar spellistan för att säkerställa att den innehåller alla låtar de ville ha för sitt humör.
  • Genomföra: Användarna sparar spellistan och ger den ett namn.
  • Övervaka: De tittar på mätvärden som antalet uppspelningar och gilla-markeringar för att utvärdera spellistans popularitet.
  • Ändra: Användarna införlivar andras feedback i sina spellistor genom att lägga till eller ta bort låtar.
  • Avsluta: När de upplever det humör som spellistan skapades för sätter användarna på den och njuter av musiken.

Beroende på vilket jobb du vill kartlägga kan du överväga att utelämna några av stegen här om du upplever att det inte finns någon faktisk åtgärd som användarna behöver utföra i det steget.

Skapa en lösning som människor kommer att anlita för det jobbet

Slutligen har vi nått den punkt där du kan skapa dina vanliga leverabler inom produktledning, såsom PRD:er, designer, användarberättelser och mycket mer, genom att använda din dagliga programvara för produktledning.

Du har redan listan över de steg som dina användare tar för att tillgodose sina ouppfyllda behov, så allt du behöver göra är att skapa funktioner som täcker de nödvändiga åtgärderna som användarna utför i varje steg.

För ”förbereda”-steget i jobbet ovan behöver du till exempel utveckla en funktion som låter användarna söka efter låtar, filtrera andra användares spellistor och lägga till dessa låtar i sin egen spellista.

Utöver att utveckla funktioner som täcker dina jobb får du inte heller glömma de mer ”administrativa” delarna, som din prissättning och betalningslogik, kundupplevelsen när det gäller att hantera kundernas data och konton samt deras möjlighet att få tillgång till support.

Allt handlar om att göra din produkt ”anlitningsbar”

Jobb som ska utföras (JTBD) är ett exceptionellt ramverk och tankesätt eftersom det hjälper dig att fokusera dina insatser på funktioner som gör din produkt mer attraktiv för användare som vill anlita dig för att hantera deras jobb åt dem.

Oavsett om du arbetar på ett nystartat företag eller hos en teknikjätte (som Intercom eller Microsoft) kan jag försäkra dig om att JTBD hjälper dig att öka effekten av ditt arbete inom produktledning. Om du uppskattade att läsa mina tankar om JTBD kan du prenumerera på vårt nyhetsbrev för att få liknande innehåll direkt i din inkorg.