Mistä tuotevaatimukset tulevat?

Kokoonnuimme tuotejohtajien verkostotapaamisessa miettimään tuotevaatimuksia. Koko sana tuotevaatimus kuulostaa ehkä hiukan menneisyyden havinalta kun etenkin ohjelmistoalalla ‘vaatimukset’ on paljolti korvattu uusilla termeillä ja visuaalisimmilla tavoilla kuvata tavoiteltua toiminnallisuutta. Selkeitä vaatimuksia ohjelmistoalallakin silti edelleen on esimerkiksi yhteensopivuuksien, suorituskyvyn ja regulaation takia. Ja kun parempaakaan nimeä emme keksineet, niin päädyin tässäkin artikkelissa kirjoittamaan tuotevaatimuksista.

Eli mistä näitä vaatimuksia pitäisi kerätä tai odottaa ilmestyvän?

Olemassa olevat asiakkaat vs. potentiaalliset markkinat

Olemassa olevien tuotteiden ja liiketoiminnan hallinta on erilaista kuin uuden kehittäminen. Suurin osa tuotepäälliköistä ja usein tuotekehityksestäkin toimii jo markkinoilla olevien tuotteiden kanssa. Vaatimukset ja toivomukset kohdistuvat silloin markkinoilla oleviin tuotteisiin ja tulevat pääosin olemassa olevilta asiakkailta, joko suoraan tai esimerkiksi myynnin tai asiakastuen kautta.

Joissain yrityksissä palautetta kerätään järjestelmällisemminkin kuin toisissa. Asiakasmäärällä on suuri merkitys käytettyihin prosesseihin ja työkaluihin. Muutaman ison asiakkaan tapauksissa yrityksillä voi olla oma ”account team”, joka varmistaa että asiakkaan toiveet tulevat toteutetuiksi. Massamarkkinoilla tämä ei ole mahdollista, mutta esimerkiksi UserVoicen kaltaisilla työkaluilla voidaan tuotevaatimuksia kerätä ja jopa priorisoida.

Kun eri kanavia ja keinoja tuotevaatimusten keräämiseksi olemassa olevilta asiakkailta laitettiin aikajanalle, niin huomattiin suoran asiakaspalautteen kohdistuvan yleensä vain olemassa oleviin tuotteisiin (kts kuva alla).

 

Product requirement sources

Vakiintuneet yritykset ovatkin usein huonoja innovoimaan liiallisen asiakaslähtöisyyden takia! Kun asiakaskunta kasvaa ja asiakassuhteet tiivistyvät, niin tekemisen fokus kääntyy yhä enemmän olemassa olevien asiakkaiden palvelemiseen. Tämä on luonnollista ja ehdottoman järkevää, mutta samalla se rajoittaa uuden kehittämistä. Tyytyväisillä asiakkailla ei ole aikaa eikä tarvetta miettiä uusia innovaatioita. Heille yleensä riittää, että nykyisistä tuotteista saa tarvittavan tehon irti ja siksi heidän tuotevaatimuksetkin kohdistuvat olemassa olevan parantamiseen.

Tuotevaatimuksia kerätessä onkin hyvä muistaa, että olemassa olevat asiakkaat edustavat vain osaa tuotteesi kokonaismarkkinasta!

Mistä uusia ideoita (=vaatimuksia) seuraavan sukupolven tuotteille?

Mutta mitä jos kuitenkin pitäisi kehittää jotain uutta ja ehkäpä jopa uudelle asiakassegmentille? Siinä tapauksessa vaatimukset pitää kerätä muualta ja homma muuttuu haasteellisemmaksi. Vaatimusten keräämisen sijaan pitäisi löytää ongelmia, tarpeita ja uusia mahdollisuuksia. Katse pitää irrottaa olemassa olevista tuotteista asiakkaista ja keskittyä uusiin kanaviin.

Isoissa yrityksissä ideoita ja ymmärrystä tulevaisuudesta saattaa löytyä yrityksen sisältäkin, mutta laajempi ja syvempi ymmärrys saadaan yleensä talon ulkopuolelta. Yhtäkkiä seminaarit, analystien raportit, akateeminen tutkimus ja oman alueen ulkopuolelle menevät verkostot eivät tunnukaan turhilta. Tosin valmiita ”vaatimuksia” näistä kanavista harvemmin tulee (standardeja ja direktiivejä lukuun ottamatta), mutta ideoita ja ajatuksia tulevaisuuden tarpeista kyllä.

Ideoista tuotevaatimuksiin

Ideoiden kanssa ollaankin sitten yrittäjien ja startup-tuotepäälliköiden pelikentällä, eli pohtimassa mitkä ideat ovat niin hyviä että niitä pitäisi lähteä tuotteistamaan ja kaupallistamaan. Tässä vaiheessa ratkaisuja voidaan lähteä hakemaan suomalaisten teollisuusyritysten tällä hetkellä suosimilla hackathoneilla tai jos ratkaisusta on yrityksellä jo selkeä ajatus, niin asiakaspalautetta voi kerätä erilaisilla MVP-konsepteilla.

Ideat muuttuvat tuotevaatimuksiksi, kun niiden asiakastarve on testattu ja todistettu.

Ja mitä tästä opimme?

Ainakin harjoitus selkeytti taas kuvaa tuotteiden kehittämisestä ja tuotepäällikön roolista. Kanavat joista tuotevaatimuksia tai ideoita kerätään ohjaavat vahvasti tuotteiden kehitystä, mutta asiaa voi katsoa toisinkin päin. Opppeina tuotepäälliköille voisi kirjata:

  1. Ole tietoinen mitä kehität ja kerää tuotevaatimuksia ja ideoita sen mukaisesti.
  2. Palautekanavat ja -prosessit kannattaa valita tuotteen elinkaaren ja strategian mukaan.
  3. Jos haluaa katsoa tulevaisuuteen, niin markkinoita pitää tarkkailla olemassa olevien asiakkaiden palautetta laajemmin.

Kiitos näistä opeista tuotepäälliköiden verkostotapahtumaan osallistuneille!

 

Kirjoittaja: Harri Pendolin

Prodmanin perustaja ja Tuotepäällikkö-blogia jo vuodesta 2009 kirjoittanut Harri on tuotemies henkeen ja vereen. Harri on aina valmis jakamaan osaamistaan tuotejohtamisesta tai debatoimaan tuotepäällikön strategisista valinnoista. Twitteristä Harri löytyy nimellä @pendolin.