Clayton Christensen kertoi aikoinaan tarinan pikaruokayrityksestä, joka halusi myydä enemmän pirtelöitä. He haastattelivat asiakkaita makuvalinnoista, makeudesta ja kuppikoosta. Mikään muutos ei lisännyt myyntiä. Sitten eräs tutkija kokeili toisenlaista lähestymistapaa: hän seisoi parkkipaikalla ja katseli ihmisiä ostamassa pirtelöitä. Hän esitti yhden kysymyksen – ”mitä yritit saada aikaan, kun päätit ostaa pirtelön tänä aamuna?”
Vastaus: useimmilla aamupirtelön ostajilla oli edessään pitkä ja tylsä työmatka. He halusivat jotain, mikä pitäisi heidät kiireisinä eikä jättäisi heitä nälkäisiksi ennen lounasta. Pirtelö hoiti tämän paremmin kuin banaani (liian nopea), sämpylä (liian sotkuinen) tai kahvi (liian pieni). Tuote, jonka kanssa se kilpaili, ei ollut muut pirtelöt – se oli pitkästyminen ja nälkä.
Tämä tarina tiivistää Jobs-to-be-Doneen olennaisen. Ihmiset eivät osta tuotteita. He palkkaavat ne hoitamaan tehtävän elämässään.
JTBD-terminologiassa ”työ” (job) on edistystä, jota henkilö yrittää saavuttaa tietyssä tilanteessa. Se ei ole tehtävä (”minun täytyy lähettää tiedosto”). Se ei ole tavoite (”haluan olla tuottavampi”). Se on täsmällinen edistysaskel, jonka tietty henkilö yrittää ottaa tietyssä tilanteessa – kaikkine sitä ympäröivine yhteyksineen, rajoitteineen ja tunteineen.
Työssä on kolme osaa: tilanne (laukaisija, joka synnyttää tarpeen), motivaatio (mitä henkilö yrittää saavuttaa) ja lopputulos (onnistumisen määritelmä hänen näkökulmastaan). Kaikilla kolmella on merkitystä. Tuotetta, joka osuu motivaatioon mutta ohittaa tilanteen, käytetään vääriin aikoihin. Tuote, joka osuu tilanteeseen mutta ohittaa lopputuloksen, palkataan ja irtisanotaan nopeasti.
Muodollisten JTBD-lauseiden kirjoittaminen pakottaa selkeyteen siitä, mihin työhön tuotteesi todella palkataan – ja paljastaa kuilut sen välillä, mitä luulet työn olevan, ja sen, mitä käyttäjät oikeasti kokevat.
Huomaa, miten jokainen lause paljastaa jotain, mitä ominaisuuslista ei koskaan paljastaisi: tunteet pelissä, kilpailevien voimien yhteyden ja onnistumisen määritelmän käyttäjän näkökulmasta. Mikään näistä ei nousisi esiin kyselyssä, jossa kysytään ”mitä ominaisuuksia haluat?”
Jokaisella työllä on kolme ulottuvuutta, ja tuotteet, jotka vastaavat vain toiminnalliseen, jättävät todellista arvoa käyttämättä.
Slack ei kasvanut siksi, että se oli sähköpostia parempi viestien lähettämisessä (toiminnallinen). Se kasvoi, koska se sai tiimit tuntemaan olonsa yhteydessä oleviksi ja eläviksi (tunneperäinen) ja sai yksilöt tuntemaan olevansa osa reaaliaikaista keskustelua postilaatikkojonon sijaan (sosiaalinen). Ominaisuudet, jotka vastaavat vain toiminnalliseen työhön, muuttuvat helposti hyödykkeiksi. Tuotteet, jotka vastaavat kaikkiin kolmeen ulottuvuuteen, on paljon vaikeampi korvata.
Paras JTBD-tutkimus keskittyy palkkaamisen hetkeen – päätökseen ottaa tuote käyttöön – ja irtisanomisen hetkeen – päätökseen lopettaa sen käyttö. Molemmat hetket ovat täynnä signaaleja.
Palkkaamishaastattelussa kysy: ”Muistele viimeistä kertaa, kun päätit ottaa [tuotteen] käyttöön. Mitä silloin oli meneillään? Mitä yritit saada aikaan? Mitä muuta kokeilit ensin?” Irtisanomishaastattelussa: ”Milloin lopetit [tuotteen] käytön? Mitä olit tekemässä juuri ennen kuin päätit vaihtaa? Mitä vaihtoehto teki toisin?”
Vastaukset yllättävät sinut lähes aina. Käyttäjät kuvaavat tilanteita, turhautumisia ja motivaatioita, joita tiimisi ei ole koskaan osannut odottaa. Se on koko pointti. JTBD-tutkimus ei ole vahvistustutkimusta vaan löytötutkimusta. Et testaa oletuksiasi; korvaat ne todisteilla.
Kun olet tunnistanut ensisijaiset työt, joihin tuotteesi palkataan, käytä niitä suodattimena jokaisessa merkittävässä tuotepäätöksessä. Kysy jokaisen ehdotetun ominaisuuden kohdalla: minkä täsmällisen työn edistämisessä tämä auttaa käyttäjiä? Jos vastaus on ”ei mikään ensisijaisista töistämme”, se on vahva merkki ominaisuuden priorisoinnista alas – vaikka ominaisuus kuulostaisi houkuttelevalta.
JTBD paljastaa myös, missä palvelet liikaa. Jos käyttäjillä on työ, joka tulee jo riittävän hyvin hoidetuksi, lisäominaisuuksien lisääminen sille alueelle tuottaa pienenevää hyötyä – ja saattaa lisätä monimutkaisuutta, joka vaikeuttaa tuotteen käyttöä käyttäjille, joilla on toisenlaiset työt. Työnäkökulma näyttää, mihin kannattaa panostaa ja missä pysähtyä.