Tuotepäällikön ja tuoteomistajan eroista ja vastuista on kiistelty reilut kaksi vuosikymmentä. Siitä asti, kun tuoteomistajan rooli alkoi vakiintua. Taustalla on väittely siitä, minkä vastuun kukin omistaa ja mihin raja pitäisi vetää. Lähtökohta kiistelylle on väärä. Ei ole yhtä oikeaa jakoa, vaan tuotepäällikön ja tuoteomistajan vastuut pitää jakaa aina tapauskohtaisesti.

Roolien ja tittelien historiaa

Tuotehallinta, tai modernimmin tuotejohtaminen, juontaa juurensa aina 30-luvulle asti. Procter & Gamble esitteli Brand Manager roolin, jonka vastuulla olivat markkinoinnin neljä P:tä (Product, Price, Promotion, Place). Ajan kuluessa P&G:n käytännöt levisivät saippuabisneksestä muillekin aloille ja organisaatioihin alkoi muodostua tuotehallinta- ja tuotemarkkinointiyksiköitä. 

Näiden yksiköiden ja niissä toimivien tuotepäälliköiden vastuulla oli tuotteen määrittely (product), hinnoittelu (price), myyntikanava (place) ja markkinointi (promotion). Koska painotukset eri aloilla ja eri yrityksissä vaihtelivat, niin tuotepäällikönkin rooli muotoutui enemmän yrityksen tarpeiden kuin geneerisen roolikuvauksen mukaan. Mitä teknisempi ja monimutkaisempi tuote, sitä kehityslähtöisempi rooli yleisesti oli. Kuluttajatuotteissa markkinoinnin rooli korostui ja usein se myös eriytettiin tuotepäällikön tekemisestä.

Tuoteomistajan (Product Owner) historia on lyhyempi. Ohjelmistokehityksen alkaessa ketteröitymään 1990-luvun loppupuolella, luotiin scrum-viitekehys. Sen oleellisena roolina määritettiin Product Owner eli tuoteomistaja. Roolin tarkoitus oli toimia asiakkaiden tarpeiden ymmärtäjänä, niiden välittäjänä ja priorisoijana ohjelmistokehittäjille. Tarve roolille nousi kehitystiimin tarpeista ja tuoteomistajan rooli onkin säilynyt edelleen tuotekehityksen roolina, ei liiketoiminnan.

Kuka tuotteen lopulta omistaa?

Tuoteomistaja on harhaanjohtava nimike. Tuote ei nykyään ole välttämättä perinteisessä mielessä konkreettinen, myytävä esine. Se voi olla kuukausilaskutteinen palvelu tai jopa asiakasratkaisun keskeinen komponentti. Omistajuus tuotteesta on aina yrityksellä, vaikka vastuu kuuluisi tietylle henkilölle tai roolille.

Tuoteomistajan vastuulla on, että ohjelmistokehityksessä tehdään oikeita asioita oikeassa järjestyksessä. Tuotepäällikön vastuulla taas yleisemmin ovat kaikki neljä P:tä, eli tuotteen lisäksi sen paketointi, hinnoittelu ja asiakkaalle houkuttelevaksi tekeminen. Roolien päällekkäisyys koskee siis lähinnä tuotteen kehittämistä. Toisaalta päällekkäisyys voi olla koko tekemisen ytimessä esimerkiksi jatkuvasti kehittyvien ohjelmistojen tapauksessa, jossa tuote itsessään toimii jakelukanava ja asiakkaiden houkuttimena.

Hyvä esimerkki päällekkäisestä tekemisestä ja samojen termien käyttämisestä eri tarkoitukseen on tuotestrategia. Vaikka alkuperäiseen tuoteomistajan rooliin tuotestrategia ei kuulunutkaan, niin nykyisin se on poikkeuksetta osa tuoteomistajakoulutusta. Kuten se on osa myös tuotepäälliköiden koulutusohjelmia.

Kun tuotekehitysorganisaatiossa puhutaan tuotestrategiasta, tarkoitetaan yleensä suunnitelmaa siitä, minkälainen tuote halutaan kehittää, miten se kehitetään ja minkälaisissa vaiheissa. Teknologia-, arkkitehtuuri-, ja julkaisuvalinnoilla on tällaisessa strategiassa keskeinen rooli kehitettävien ominaisuuksien ohella. Sen sijaan hinnoittelua, tuotemarkkinointia, kohdemarkkinoita tai tuotteen asemointia niissä harvoin pohditaan. Mutta jos tuote on vaikka viini, niin menestys yleensä saavutetaan erilaisella strategialla, kuten Sinisen meren strategia meitä opettaaa.

Organisaation tarve määrittää roolit

Eri roolien, kuten myös titteleiden, sekaannus koskettaa lähinnä yrityksiä, jotka kehittävät ohjelmistoja. Näiden yritysten määrä kasvaa, joten haasteet roolien määrityksissä eivät tule katoamaan. On tapauskohtaista mitä rooleja organisaatiossa tulisi olla ja miten vastuut kannattaa jakaa.

Tuotevastuu alkuvaiheen startupissa

Perustettaessa uutta yritystä perustajilla on yleensä hyvä idea ja visio tuotteesta. Roolit jakaantuvat osaamisen perusteella ja tittelistä huolimatta tehdään juuri sitä, mitä seuraavaksi tarvitaan. Jossain kohdassa liiketoiminta laajenee ja perustajien pitää fokusoida tekemistään. Kehitystiimin kasvaessa tarvitaan joku ohjaamaan ja koordinoimaan sen suuntaa. Koska alussa tarve on yleensä kehityksessä, niin voisi olettaa, että on järkevä palkata tuoteomistaja perustajien keskittyessä kaupalliseen puoleen 

Hyvä tiimi ymmärtää sekä omat osaamisensa että tulevaisuuden tarpeet. Tuoteomistaja voi olla se tarvittava rooli, mutta aina ei näin ole. Yrityksestä voi puuttua osaamista tuotemarkkinoinnista, hinnoittelusta tai liiketoimintamallin hiomisesta. Perustajien aika saattaa kulua yrityksen rahoituksen, palkkausten, myynnin tai teknologiavalintojen hoitamiseen. Silloin tuotepäällikkö, joka pystyy allokoimaan osan ajasta tiimin ohjaamiseen, on parempi ratkaisu. 

Valinnassa pitää miettiä myös yrityksen tai tuotteen elinkaaren seuraavaa vaihetta ja tarvetta. Tuotepäällikkö, joka pystyy ohjaamaan kehitystiimiä, voi olla helpompi löytää kuin tuoteomistaja, joka pystyy tekemään tuotemarkkinointia.

Monimutkaisten asiakasratkaisujen kerrostuneet tai jakautuneet vastuut

Monimutkainen asiakasratkaisu voi tarkoittaa autoa, satamanosturia tai pankkijärjestelmää. Nämä ratkaisut ovat niin kompleksisia, että tuotejohtamiseen tarvitaan useita henkilöitä. Kehitystiimejä voi olla kymmeniä ja niiden vastuualueet erilaisia. Tällaisissa tapauksissa yleensä roolit määritetään organisoitumisen mukaan.

SAFe on esimerkki hierarkisesta kehitysmallista, jossa tuotepäälliköt ovat päätöksenteossa tuoteomistajien yläpuolella. Roolit ja vastuut on tarkasti määritelty. Toisaalta ne ovat kaukana siitä, mitä samat roolit ovat kasvuyrityksessä. Tuotepäälliköt ovat yleensä vastuussa isoista kokonaisuuksista ja niiden suunnasta, tuoteomistajat taas pienemmistä komponenteista ja niiden toteuttamisesta. Pahimmassa tapauksessa tuoteomistajista tuleekin vain sisäisten asiakkaiden toiveiden täyttäjiä ja käyttäjätarinoiden kirjoittajia, joiden työ on kaukana tuotestrategian pohtimisesta. Tuoteomistajien yläpuolella organisaatiokaaviossa olevat roolitkin voivat olla kehityspainotteisia. Samaa roolia toisessa organisaatiossa toimittava voi olla titteliltään Area Product Owner, kun SAFe-mallin sijaan onkin käytössä LeSS.

Tuotearkkitehtuuri ja tuotekehityksen organisoituminen ohjaavat suurten yritysten organisoitumista ja eri titteleillä tehtäviä töitä.

Itseohjautuvat tiimit

Viime vuosien suurimpia trendejä on ollut tiimien itseohjautuvuus, kattaen myös asiakastarpeiden tunnistamisen. Nykyaikaiset tiimit eivät ainoastaan kehitä organisaation sisältä tulevan tarvelistan mukaisia ominaisuuksia. Ne pyrkivät itse ymmärtämään asiakkaidensa ongelmat, testaamaan ratkaisuehdotukset ja tuottamaan lopulliset ratkaisut.

Jotta itseohjautuvat tiimit voisivat toimia, niin niissä pitää olla laajasti erilaista osaamista niin teknologioista, käyttökokemuksesta kuin asiakastarpeiden ja toimialan ymmärryksestä.  Usein myös markkinointi- ja myyntiosaamista tarvitaan, jotta voidaan testata ratkaisun haluttavuutta.

Itseohjautuvia tiimejä syntyy niin kasvuyrityksiin kuin vakiintuneisiinkin firmoihin, jotka haluavat purkaa hierarkisia rakenteitaan ja antaa vastuuta enemmän tekijätasolle. Itseohjautuvissa tiimeissä on yleensä tuoteomistaja tai tuotepäällikkö, mutta kumpi näissä tapauksissa on parempi vaihtoehto?

Kysymys palaa tiimin vastuisiin. Itseohjautuva tiimi voi olla kehitystiimi tai vastuussa koko tuotteesta. Jos yrityksessä oletetaan tiimin kykenevän hoitamaan kehityksen lisäksi kaupallistamisen, niin osaamisen pitää ulottua tuotemarkkinointiin. Tämän osaaminen suurimmalta osalta tuoteomistajia puuttuu. 

Mitä tai mitkä roolit tarvitaan?

Pääasiallisesti voi sanoa, että tuoteomistaja on kehityksen rooli ja tuotepäällikkö liiketoiminnan. Tämä yksinkertainen muistisääntö helpottaisi jo paljon hämmennystä näiden kahden roolin välillä.

Hyvä tuoteomistaja on usein erikoisosaaja. Tuotepäällikön rooli on laajempi ja vaatii leveää osaamispohjaa. Organisaatiota rakennettaessa ja uusia paikkoja avatessa yritysten kannattaa korostaa, mitä he uusilta rooleiltaan odottavat ja minkälaisia mahdollisuuksia he työnhakijoille tarjoavat.

Työnhakijankin näkökulmastakin on parempi, kun odotukset roolille on selkeästi kuvattu ja ennen kaikkea silloin, kun titteli ja rooli eroavat toisistaan. Työnhakijalle tärkeätä on ymmärtää urapolku ja omat kehittymisen mahdollisuudet, eli odotetaanko syväosaamista vai laajempaa strategista ja liiketoiminnallista näkemystä ja mihin kaikkeen työssä voi itse vaikuttaa.

Muut kiistelyt roolien ja niiden vastuiden jakaantumisen osalta voidaan lopettaa. Vain organisaatiot itse voivat tietää mitä ne tarvitsevat.