Onko asiakas osana tuotekehitystänne? Kuinka asiakaslähtöistä tuotekehityksenne on?

Markkina vaatii tuotekehitykseltä yhä ripeämpää otetta. Nopeudesta uhkaa tulla itseisarvo, jonka aikana unohtuu kenelle ja miksi tuotetta tai palvelua tehdään. Asiakas unohtuu tai parhaimmillaan asiakas tulee mieleen vasta sitten, kun siitä erikseen muistuttaa. Mitä jos asiakas olisikin koko ajan läsnä tuotekehityksen war roomissa? Hänet otettaisiin jengiin mukaan yhtenä tiimin jäsenenä?

Tunnista asiakas. Luo Persoona.

Asiakas ilmenee tuotekehityksessä monessa muodossa: segmentteinä, käyttäjäryhminä, ostajapersoonina, vaikuttajahamoina jne. Yksinkertaisimmillaan tuote tai palvelu kehitetään asiakkaalle (käyttäjälle), ja sen ostaa asiakas (ostaja). B2B-toimialalla projekteja saatetaan tehdä projektitasolla, jolloin tuote tai palvelu kehitetään jokseenkin alusta loppuun yhdelle tietylle asiakkaalle. Tällöin on luontevaa, että asiakas on hyvinkin lähellä tuotekehitystä. Tyypillisempää on kehittää tuote tai palvelu tietylle segmentille. Puhutaan markkinalähtöisestä tuotekehityksestä. Silloinkin puhutaan asiakkaasta yksikössä, vaikka kyseessä on kokonainen markkina.

Persoonassa yhdistyy markkina ja rooli segmentissä. Se on arkkityyppi. Luomalla persoonan (Lataa tästä: Persoona työkalu Print ) – asiakashahmon – tuotekehitys varmistaa, ettei kehitä tuotteita ja palveluita itselleen vaan käyttäjähahmolle. Käyttäjäpersoonan luominen alkaa siitä, että ymmärtää, mitkä ovat käyttäjän ongelma(t), toiveet ja tarpeet tuotteen tai palvelun suhteen. On selvää, että näitä ei voi ymmärtää, ellei jollakin tapaa hyppää asiakkaan saappaisiin ja mieleen.

Asiakas löytyy myös Jirasta

Easy Agile Personas on lisäosa, jonka voi ostaa Jiraan. Siinä asiakkaat määritellään etukäteen. Jatkossa käyttäjätarinaan voi lisätä, ketä kyseinen tarina koskettaa ja kuinka merkittävä se on kyseiselle persoonalle. Kun arvotetaan asiakkaan näkökulmasta, työkalu antaa selkeän näkymän siihen, mitkä stoorit ovat kuinkakin arvokkaita kullekin asiakkaalle.

Löydä yrityksesi asiakasdatan kaivo

Asiakasymmärrystä voi kerätä monella eri tapaa, ja sitä laadukkaampaa käyttäjädata on mitä useammalla tavalla sitä kerää. Helpointa on tutustua jo olemassa olevaan dataan, mitä jo löytyy organisaatiosta. Haasteena valitettavan usein on, että data löytyy sirpaleina sieltä täältä yksittäisten henkilöiden muistista ja kovalevyiltä CRM-järjestelmään, Business Intelligenceen ja intraan. Kukin tietää tai olettaa jotakin asiakkaasta, mutta tietoa ei jaeta, jolloin kokonaisymmärrys asiakkaasta jää vaillinaiseksi. Organisaatiota yhdistääkin asiakas, joka on piiloutunut siilojen lonkeroihin.

Jotta asiakkaan saa herätettyä henkiin, olisi ensinnäkin hyvä toimia aktiivisesti sen suhteen, että asiakasdataa sen monissa muodoissa kerätään ja dokumentoidaan tiettyyn paikkaan niin, että kaikilla on näkyvyys siihen. Dataa voi kerätä monista lähteistä, mutta vähintäänkin siitä jalostettu tieto pitäisi koota yhteen paikkaan, esimerkiksi Confluenceen. Sieltä voisi löytyä esimerkiksi yrityksen persoonat, olennaisimmat asiakaspolut ja asiakaskokemuksen tärkeimmät tekijät. Asiakasta ei sovi piilottaa kaivon syövereihin, vaan asiakastieto on niin tärkeää, että se pitää olla kaikkien ulottuvilla.

”Tuo asiakas läpi organisaation.” – Richard Branson

Jos organisaatiossanne on onnekkaasti möyhennetty data yhteen paikkaan, sieltä on helppo noukkia tarvittava tieto. Relevantin informaation hankkimisessa auttaa organisaation muu henkilöstö: osaa siis kysyä apua esim. Customer Insight Managerilta tai käy haastattelemassa asiakaspalvelua. Ongelma ei ole, etteikö asiakasdataa olisi, vaan haaste on sen löytäminen ja jalostaminen tiedoksi.

Koodari asiakaspalvelijan puvussa

Olen nähnyt, kuinka oivalluttavaa ja ilahduttavaa on törmäyttää eri toimihenkilöitä. Siksi haastan koodarin tutustumaan asiakaspalvelijan työhön ja asiakaspalvelijan tutustumaan koodarin työhön. Syntyisikö asiakasdatan törmäyttämistä liiketoimintaa hyödyttävällä tavalla ja sitä myöten uutta osaamista ja näkökulmaa?

Kysy asiakkaalta

Asiakasymmärrystä on hyödyllistä myös kerätä primäärilähteestä eli kentältä eli suoraan asiakkaalta. Koska tämä on laajempi kokonaisuus, tuotekehitys harvemmin itse hyppää kenttätyöhön. Olennaista onkin vaatia sitä organisaatiotasolla toteutettavaksi.

Tai toki tuotekehitys voi kutsua asiakkaan kehittämään tuotetta yhdessä, mikä on tyypillistä isoissa projekteissa, mutta toteutettavissa markkinalähtöisessä tuotekehityksessä niin, että satunnainen asiakas toimii oman itsensä asiantuntijana ja edustajana. Vaaran sana siitä, että jos asiakas–asiantuntija sanoo haluavansa ”vihreän”, hän ei välttämättä käytäkään ”vihreää”. Toiveet, tarpeet eivät välttämättä täsmää yksi yhteen todellisuuden kanssa. Klassinen esimerkki on, että käyttäjätestauksessa asiakkaat mollasivat matkapuhelinten kosketusnäytöt, mutta kuitenkin ostivat sellaisia puhelimia. Siksi yksi asiakas–asiantuntija ei kerro totuutta, vaan asiakkaan ajatuksia tulee käsitellä varoen ja monipuolisesti. Asiakas voi olla mukana tuotekehityksessä vain, kun testataan tai halutaan palautetta vain muutamasta ominaisuudesta.

Osallistuta asiakas

Asiakkaan mieltymyksiä voi udella esimerkiksi Buy-a-Feature -pelin avulla. Pelissä listataan tuotteen ominaisuudet, joille jokaiselle asetetaan asiakasarvoon, kustannuksiin tai muuhun perustuva hinta. Asiakas saa tietyn summan pelirahaa, jolla voi ostaa edullisia tai ”liian” kalliita ominaisuuksia. Asiakaspelaajilla on joihinkin ominaisuuksiin varaa vain yhdessä; siksi heidän tulee tehdä yhteistyötä. Koska asiakkaiden mieltymykset eivät ole selvät, peli yhteistyönä toteutettuna priorisoi ominaisuuksia asiakasnäkökulmasta. Keskustelu paljastaa, mitä asiakkaat todellisuudessa haluavat.

Käyttäjän – missä muodossa tahansa – tulisi olla läsnä tiimin seremonioissa. On hyvä miettiä, kuka milloinkin edustaa käyttäjää: useimmiten se on tuoteomistaja tai tuotepäällikkö, mutta miksei se tarpeen mukaan voisi olla ihan aito asiakaskin tai kollega organisaation eri osastolta. Ylipäätään piilevien tarpeiden kartoittaminen on äärimmäisen tärkeää. Saadakseen selville todelliset toiveet ja tarpeet, täytyy hyödyntää asiakasnäkökulmaa monipuolisesti ja kysyä oikeita (joista osa siis nimenomaan vääriä) kysymyksiä.

Parhaimmillaan asiakas kuitenkin herättää tuotekehityksessä asiakasnäkökulman. Ilman asiakkaan ääntä tuotekehitys saattaa joutua palaamaan suunnittelupöydälle tai koodaamaan ominaisuuksia uusiksi.

”Kun tuotetta jo koodataan, saattaa törmätä uuteen tai parempaan ideaan siitä, miten tuottaa arvoa asiakkaalle. Mitä aikaisemmin tämän tajuaa, sitä parempi.” – Risto Varetsalo