Ajatus siitä, että käyttäjät ”palkkaavat” tuotteen, saattaa aluksi kuulostaa hieman oudolta. Tämä on saattanut jopa saada sinut ajattelemaan, että niin kutsuttu tehtävät, jotka on tehtävä -viitekehys on jonkinlainen tuotepäälliköiden sisäpiirivitsi.
Todellisuudessa kuitenkin tehtävät, jotka on tehtävä (tunnetaan myös nimillä tehtävät, jotka on tehtävä, JTBD tai tehtävien teoria), eivät ole ainoastaan todellinen asia, vaan kyseessä on myös yksi tehokkaimmista ja vaikuttavimmista viitekehyksistä, joita voit käyttää tuotteidesi kehittämiseen.
Vanhempana tuotepäällikkönä, jolla on käytännön kokemusta JTBD-teorian soveltamisesta, voin vakuuttaa sinulle tämän: tämän kiehtovan menetelmän käytön oppiminen muuttaa täysin tapasi ajatella tuotteestasi.
Tehtävien teorian periaatteet
Ennen kuin tarkastelemme tämän viitekehyksen rakennetta ja selitän, miten sitä käytetään, haluan esitellä sen taustalla olevat keskeiset ajatukset ja periaatteet, jotta ymmärtäisit tämän viitekehyksen ytimen (sen sijaan, että vain opettelisit toteutuksen vaiheet ulkoa).
Tuote- ja johtamisalan konkarit väittävät, että ensimmäinen JTBD:n taustalla oleva ”ajattelutapa” juontaa juurensa 1960-luvulle, jolloin kuuluisa Harvard Business Schoolin professori ja markkinoinnin tutkija Theodore Levitt toi esiin ”haluttujen lopputulosten” käsitteen ja esitti tämän kuuluisan lauseen:
Tämän ajattelutavan nerokkuus piilee siinä, miten alat lähestyä tuotekehitystä.
Spotify halusi päästä musiikkialalle. Sen sijaan, että se olisi luonut markkinapaikan, jossa se myisi kappaleita (aivan kuten iTunes tuolloin), se ymmärsi, että ihmiset halusivat pystyä kuuntelemaan musiikkia eivätkä ostamaan sitä.
Siksi sillä oli vapaus rakentaa jotain musiikkikaupoista perustavanlaatuisesti erilaista (ja parempaa) – suoratoistopalvelu, joka yhdisti kestävän liiketoimintamallin käyttäjien haluttuun lopputulokseen eli musiikin kuuntelemiseen.
Sen jälkeen kun lähestymistapa haluttujen lopputulosten priorisointiin syntyi 60-luvulla, se on kehittynyt merkittävästi, kun monet tunnetut johtamisen asiantuntijat ja tutkijat ovat rakentaneet sen pohjalta omia viitekehyksiään ja ”filosofioitaan”.
Merkittävimpiä virstanpylväitä olivat:
Clayton Christensenin ajatus disruptiivisesta innovaatiosta , jonka hän esitteli kirjassaan ”Innovaattorin dilemma”. Clayton huomautti, että mikä tahansa maailmaa muuttava innovaatio alkaa vastaamalla pienen asiakasryhmän (eli varhaisten omaksujien) tarpeisiin ja parantamalla sen jälkeen ratkaisua niin, että se pystyy vastaamaan suurempien myöhäisten käyttäjämassojen lisätarpeisiin.
Tämän ”aloita markkinaraosta ja laajenna sitten” -rakenteen keskeinen ajatus oli perustajien ja tuotepäälliköiden kyky tunnistaa markkinaraon käyttäjien tarpeet ja halutut lopputulokset asianmukaisesti ja tehdä sitten sama laajemmalle yleisölle.
Bob Moestan ”haasteet ensin” -lähestymistapa, jonka hän kuvasi kirjassaan ”Kysyntälähtöinen myynti 101: Lopeta myyminen ja auta asiakkaitasi edistymään”. Bobin mukaan asiakkaat yrittävät jatkuvasti edistyä elämässään (oli kyse sitten taloudesta, ihmissuhteista tai jostain muusta), ja he kohtaavat tällä matkalla lukuisia haasteita. Erinomaiset tuotejohtajat pystyvät näkemään nämä haasteet ja tarjoamaan tuotteita, jotka käyttäjät voivat ”palkata” käsittelemään nämä haasteet heidän puolestaan.
Tony Ulwickin lopputuloslähtöisen innovaation (ODI) viitekehys (tästä on hyvä Harvard Business Review -artikkeli). Tonyn mukaan asiakkaiden päätöksentekoa ohjaava perimmäinen tekijä ovat lopulliset lopputulokset, jotka he haluavat saavuttaa käyttämällä tuotettasi.
Ajatuksena on, että kun asiakkaat voivat valita useiden kilpailevien tuotteiden välillä, he päätyvät tuotteeseen, joka auttaa heitä parhaiten saavuttamaan halutut lopputulokset.
Miten JTBD toimii?
Kun kaikki nämä ajatukset ja viitekehykset ovat mielessämme, saavumme viimein JTBD:hen. JTBD-teoriasta on useita tulkintoja (ja ne kaikki ovat varsin hyviä), mutta itse pidän eniten Tonyn versiosta, jonka hän kuvaa kirjassaan ”Tehtävät, jotka on tehtävä: teoriasta käytäntöön”.
Hänen mukaansa asiakkaiden on suoritettava ”tehtävä”, jonka avulla he voivat saavuttaa halutun lopputuloksen. He voivat tehdä tämän tehtävän käyttämällä erilaisia polkuja ja ratkaisuja, mukaan lukien tuotteet, jotka voidaan ”palkata” hoitamaan tehtävä heidän puolestaan.
Jos havainnollistamme tätä käsitettä, se näyttää tältä:
Asiakkaidesi lähtökohtana on epäihanteellinen nykytila, joka ei tyydytä heitä. Esimerkiksi kotoa käsin työskentelevälle asiakastukihenkilölle tämä nykytila on hänen olohuoneensa, jossa hän yleensä työskentelee, koska hänen asunnossaan ei ole erillistä työhuonetta.
Miksi kyseessä on epäihanteellinen nykytila? No, koska hänen koiransa, lapsensa ja naapurinsa aiheuttavat taustamelua, hän pelkää kuulostavansa epäammattimaiselta asiakastukipuheluissaan.
Niinpä hänen haluttu lopputuloksensa on meluttomien asiakastukipuheluiden käyminen.
Saavuttaakseen tämän hänen on muutettava nykytilaansa ja edettävä kohti haluttua lopputulosta vähentämällä taustamelua. Tämä on tehtävä, joka hänen on suoritettava.
Yksi vaihtoehto on pitää kaikki poissa olohuoneesta – mutta tämä on melkoinen vaatimus koko työpäivän ajaksi pienessä asunnossa. Toinen vaihtoehto on muuttaa pois asunnosta ja sellaiseen asuntoon, jossa on äänieristetty työhuone – mutta tämä on työlästä ja stressaavaa, ja siihen liittyy paljon pitkäaikaisia kustannuksia. Lopuksi vaihtoehtona on palkata melunpoisto-ohjelmisto poistamaan kaikki melu reaaliajassa.
Vaihtoehtoisten ratkaisujen kustannukset huomioon ottaen hän maksaisi mielellään tusinan verran kuukaudessa tällaisesta palvelusta!
Näin melunpoisto-ohjelmisto suoritti onnistuneesti hänen tehtävänsä eli poisti taustamelun puheluista ja auttoi häntä saavuttamaan halutun lopputuloksen eli häiriöttömien puheluiden käymisen.
Have an account? Log In
JTBD:n lait
Strategyn-konsultointiyrityksen verkkosivustolla julkaistussa JTBD-viitekehyksen määritelmässään Tony tuo esiin muutamia kiinnostavia näitä tehtäviä koskevia ”tosiasioita”, jotka voivat auttaa meitä ymmärtämään paremmin JTBD:n olemusta.
- Tehtävä pysyy samana ajan kuluessa. Aiemmin ihmiset palkkasivat kokousmuistiinpanojen kirjoittajia tekemään muistiinpanoja heidän puolestaan kokouksen aikana. Nykyään he palkkaavat sen sijaan tekoälypohjaisia yhteenvetotyökaluja. Eri ratkaisut, sama tehtävä.
- Tehtävät ovat ”ratkaisuriippumattomia”. Tämä tarkoittaa, että asiakkaat voivat palkata erityyppisiä ratkaisuja saman tehtävän hoitamiseen. Se tarkoittaa myös, ettei tuotteesi tarvitse näyttää samanlaiselta kuin kilpailijoidesi tarjoamat tuotteet, jotta se voisi suorittaa tehtävän hyvin.
- Paras ratkaisu saa aina tehtävän. Jos kilpailua on, voittaja on tuote, joka hoitaa tehtävän paremmin, nopeammin tai edullisemmin (tai millä tahansa näiden kolmen yhdistelmällä).
- Ihmiset haluavat yhden ratkaisun yhtä tehtävää varten. Asiakkaat suosivat tuotteita, jotka pystyvät kattamaan koko tehtävän alusta loppuun, ja välttävät tilanteita, joissa tehtävän hoitaminen edellyttää useiden tuotteiden palkkaamista.
Yhteenvetona voidaan todeta, että Jobs To Be Done -viitekehys perustuu ajatukseen, että ihmiset todella haluavat lopullisia lopputuloksia eivätkä niiden saavuttamiseen käyttämiään työkaluja.
Prosessista he kuitenkin välittävät. Saavuttaakseen lopulliset tavoitteensa heidän on suoritettava tiettyjä tehtäviä (tai töitä), ja he ovat valmiita palkkaamaan jonkun tai jonkin (palvelun tai ohjelmiston) hoitamaan nämä tehtävät puolestaan.
Tunnistamalla nämä tehtävät ja mukauttamalla tuotteesi hoitamaan ne saumattomasti lisäät todennäköisyyttä, että ihmiset maksavat tuotteestasi ja käyttävät sitä jatkuvasti.
Kuinka JTBD-viitekehystä käytetään päivittäisessä tuotekehityksessä
Toivottavasti on selvää, kuinka tärkeää sinun on ymmärtää JTBD-viitekehyksen olemus ennen sen käytön opettelua, sillä seuraavat vaiheet ovat asiayhteydessään paljon järkevämpiä.
Se, mitä aion jakaa kanssasi, ei ole JTBD:n ”vaniljaversio” (josta voit lukea edellä mainituista monista kirjoista).
Sen sijaan haluan jakaa JTBD:n muunnelman, jota olen käyttänyt menestyksekkäästi tosielämässä joidenkin tuotteideni kohdalla.
Tässä on esimerkki Jobs to Be Done -tehtävästä omasta ammatillisesta kokemuksestani.
Asiakkaan tarpeiden ja haluttujen lopputulosten selvittäminen
Jokaisen menestyvän tuotteen ytimessä on hyvin toteutettu käyttäjätutkimus. Kun otetaan huomioon, kuinka riippuvainen JTBD on ajatuksesta ”ihmiset haluavat lopputuloksia, eivät työkaluja”, sinun tulisi aina aloittaa tunnistamalla käyttäjäsi ja selvittämällä, mitä he haluavat.
Minulla ei ole erityistä ”JTBD:n mukaan räätälöityä” tapaa tämän tutkimuksen tekemiseen. Sen sijaan tuotetiimini ja minä olemme luottaneet perinteisiin tapoihimme ja käyttäjien tarpeiden selvittämiseen tarkoitettuihin työkaluihin. Ainoa ero oli se, että keskityimme kysymyksissämme selvittämään lopullisen lopputuloksen, jonka käyttäjämme halusivat saavuttaa.
Haluan jakaa esimerkin verkkosivustojen push-ilmoituspalvelusta, jonka parissa työskentelimme.
Huomautus: Tämän työkalun avulla verkkosivustot voivat lähettää push-ilmoituksia kävijöilleen. Kyseessä oli uusi tuottoisa markkinointikanava, jota verkkosivustot saattoivat käyttää tuotteidensa mainostamiseen.
Kehittääksemme tätä palvelua varten käyttäjäpersoonat haastattelimme ihmisiä, jotka olivat käyttäneet suorien ja epäsuorien kilpailijoidemme tuotteita. Kun kilpailijan käyttäjää haastatellaan, esitetään perinteisesti tämänkaltaisia kysymyksiä:
Vaikka esitimme nämä kysymykset myös haastatteluissamme, pääpainomme oli saada vastauksia näihin kysymyksiin:
Ja siihen oli hyvä syy, että haastattelimme sekä suoria kilpailijoita (esimerkiksi OneSignal ja iZooto) että epäsuoria kilpailijoita (esimerkiksi Mailchimp ja Twilio). Mainitsimme aiemmin, että tehtävät ja toivotut lopputulokset ovat ratkaisusta riippumattomia. Tämä tarkoitti, että saamamme vastaukset lopputuloksesta olisivat samat (tai ainakin samankaltaiset) riippumatta siitä, mitä työkalua haastateltavamme käyttivät.
Saimme juuri tällaisia vastauksia. Ilmeisesti yleisin kohdemarkkinamme (joka koostui tuolloin verkkokaupoista) toivoma lopputulos oli niin kutsuttujen ”hylättyjen ostoskorien” määrän vähentäminen – ihmiset lisäävät tuotteita ostoskoriinsa ja jättävät ne sinne päiviksi tai viikoiksi.
Sekä sähköposti- että verkkopush-ilmoituspalveluiden tehtävänä oli muistuttaa käyttäjiä hylätystä ostoskorista ja tarjota alennus, jos he palasivat tekemään ostoksen.
Tähän päätimme lopulta keskittyä, ja rakensimme tuotteen, joka pystyi tekemään sen paremmin kuin mikään muu.
Edellä esittämäni esimerkki käsitteli käyttäjähaastatteluja, mutta se ei ole ainoa tapa selvittää, mitä asiakkaasi haluavat. Voit harkita myös seuraavia vaihtoehtoja:
- Markkinatutkimus sekä eri asiakassegmenttien ja demografisten tietojen määrittäminen.
- Käyttäjäkyselyt, joita voit toteuttaa käyttämällä huolella koostamaamme kysymyslistaa.
- Fokusryhmähaastattelut, joissa kutsut valitun ihmisryhmän keskustelemaan kanssasi tarpeistaan ja kokemuksistaan.
Riippumatta siitä, millaista asiakasymmärryksen hankintaa teet, muista aina asettaa etusijalle kysymykset, jotka paljastavat lopulliset tulokset, jotka asiakkaasi haluavat saavuttaa.
Tehtävän kuvauksen laatiminen
Kaikkien haastatteluistamme ja kyselyistämme saamiesi oppien perusteella sinulla pitäisi olla melko hyvä käsitys sekä käyttäjiesi haluamista lopputuloksista että tehtävistä, joita he tavallisesti suorittavat saavuttaakseen ne.
Nyt on aika konkretisoida nämä opit muotoilemalla JTBD-menetelmän tärkein tuotoksesi – tehtävän kuvaus. Se näyttää tältä:
Tämä tapa kuvata lopputuloksia ja tehtäviä on varsin hyödyllinen, koska se sisältää olennaisia tietoja, kuten:
- Tilanne ja ympäristö, jossa asiakas kokee ongelman. Meidän tapauksessamme kyse oli ihmisistä, jotka hylkäsivät ostoskorinsa.
- Tehtävä, joka asiakkaamme on suoritettava saavuttaakseen halutun lopputuloksen. Verkkokauppojen omistajille se tarkoitti muistutusviestien lähettämistä niille, jotka olivat hylänneet ostoskorinsa.
- Emotionaalinen ja rationaalinen syy asiakkaan halulle saavuttaa lopputulos. Jos ihmiset lisäävät tuotteita ostoskoriinsa ja unohtavat ne, tämä merkitsee asiakkaillemme menetettyä potentiaalista liikevaihtoa, joten heillä on rationaalinen syy vähentää tällaisten tapausten määrää.
- Lopuksi meillä on haluttu lopputulos. Tässä esimerkissä kauppojen omistajat halusivat päästä eroon näistä hylätyistä ostoskorista.
Olet ehkä huomannut, että käytimme push-ilmoituksista puhuttaessa termiä ”muistutusviestit” emmekä ”muistutussähköpostit”. Syynä on se, että asiakkaamme eivät oikeastaan välittäneet tämän viestin lähettämiseen käytetystä kanavasta, kunhan se onnistui pienentämään ostoskorien hylkäysastetta.
Tehtäväkartan luominen
Monien asiakkaidesi tehtävien ja tavoiteltujen tulosten kuvausten dokumentointi on jo itsessään saavutus. Se on kuitenkin vasta puolet työstä, sillä sinun on muutettava nämä tehtävät kunnolliseksi arvolupaukseksi, uusiksi tuotevaatimuksiksi (mukaan lukien etenemissuunnitelma) ja käyttäjäkokemukseksi.
Tässä voimme hyödyntää toista JTBD-tuotosta – tehtäväkarttaa.
Tehtäväkartta on visuaalinen esitys koko matkasta, jonka asiakkaidesi on kuljettava suorittaakseen tehtävänsä onnistuneesti. Se toimii välivaiheena tehtäväkuvausten ja asiakaspolkukartan tai niiden tuotevaatimusten välillä, jotka luovutat suunnittelutiimillesi.
Tässä on GitLabin kehittämä tehtäväkartan mallipohja.
Yllä olevan rakenteen kehitti Tony Ulwich, joka ehdotti sen käyttämistä tehtävien kartoittamiseen tulosohjautuvan innovaation viitekehyksessään.
Täytetään tämä nyt Spotify-esimerkin avulla, jossa tehtävänä on ”Asiakas luo tiettyyn mielialaansa sopivan mukautetun soittolistan.”
- Määritä: Käyttäjät ymmärtävät tarvitsevansa mielialaansa perustuvan henkilökohtaisen soittolistan.
- Etsi: He löytävät soittolistan luomiseen tarkoitetun toiminnon ja siirtyvät siihen.
- Valmistele: Käyttäjät etsivät ja valitsevat kappaleet, jotka he haluavat lisätä soittolistalle.
- Vahvista: He tarkistavat soittolistan varmistaakseen, että siinä ovat kaikki kappaleet, jotka he halusivat mielialaansa varten.
- Suorita: Käyttäjät tallentavat soittolistan ja antavat sille nimen.
- Seuraa: He tarkastelevat esimerkiksi kuuntelukertojen ja tykkäysten määrää arvioidakseen soittolistansa suosiota.
- Muokkaa: Käyttäjät hyödyntävät muiden antamaa palautetta soittolistoissaan lisäämällä tai poistamalla kappaleita.
- Päätä: Kun käyttäjät kokevat sen mielialan, jota varten tämä soittolista luotiin, he käynnistävät sen ja nauttivat musiikista.
Kartoittamastasi tehtävästä riippuen voit harkita joidenkin tässä mainittujen vaiheiden jättämistä pois, jos koet, ettei käyttäjien tarvitse tehdä kyseisessä vaiheessa mitään varsinaista toimenpidettä.
More Articles
Ratkaisun luominen, jonka ihmiset valitsevat tähän tehtävään
Lopulta olemme päässeet pisteeseen, jossa voit luoda tavanomaisia tuotehallinnan tuotoksia, kuten PRD-dokumentteja, suunnitelmia, käyttäjätarinoita ja paljon muuta käyttämällä päivittäiseen työhösi tarkoitettua tuotehallintaohjelmistoa.
Sinulla on jo luettelo vaiheista, joita käyttäjäsi käyvät läpi täyttääkseen täyttämättömät tarpeensa, joten sinun tarvitsee vain luoda ominaisuuksia, jotka kattavat käyttäjien kussakin vaiheessa tarvitsemat toimenpiteet.
Edellä kuvattuun tehtävään liittyvässä ”valmistele”-vaiheessa sinun on esimerkiksi kehitettävä toiminto, jonka avulla käyttäjät voivat etsiä kappaleita, suodattaa muiden käyttäjien soittolistoja ja lisätä näitä kappaleita omaan soittolistaansa.
Tehtäviisi liittyvien ominaisuuksien kehittämisen lisäksi älä unohda myös hallinnollisempia asioita, kuten hinnoittelua ja maksujen käsittelylogiikkaa, asiakaskokemusta heidän tietojensa ja tilinsä hallinnassa sekä heidän mahdollisuuttaan saada tukea.
Kaiken keskiössä on tuotteesi tekeminen ”valittavaksi”
JTBD (tehtävät, jotka on tehtävä) on poikkeuksellinen viitekehys ja ajattelutapa, sillä se auttaa sinua keskittämään työsi ominaisuuksiin, jotka tekevät tuotteestasi houkuttelevamman käyttäjille, jotka haluavat palkata sinut hoitamaan tehtävänsä heidän puolestaan.
Olitpa startup-yrityksessä tai teknologiajätissä (kuten Intercomissa tai Microsoftilla), voin vakuuttaa, että JTBD auttaa sinua lisäämään tuotehallintatyösi vaikutusta. Jos pidit JTBD:tä koskevien ajatusteni lukemisesta, muista tilata uutiskirjeemme, jotta saat vastaavaa sisältöä sähköpostiisi.
