Tuotehallinnassa on helppo huomata pukeutuvansa sankarin viittaan. Mutta entä jos todellinen tie menestykseen ja vaikuttavuuteen kulkeekin sen ohi, että on tiimin luotettu pelastaja?
Tässä jaksossa Hannah Clarkin seurana on Product Teacherin perustaja Clement Kao. He perehtyvät tuotehallinnan sankaruuden monimutkaisuuteen ja tarkastelevat strategioita tuotetiimien kestävämpään voimaannuttamiseen.
Haastattelun kohokohdat
- Clementin matka hallintokonsolista Product Teacheriksi [00:54]
- Clementin tausta on epätyypillinen: hän aloitti liikkeenjohdon konsulttina, siirtyi sitten UX-tutkijaksi ja data-analyytikoksi ja päätyi lopulta tuotepäälliköksi.
- Hän huomasi, että monet muutkin kamppailivat tuotehallinnan parissa ja että heiltä puuttui resursseja ja ohjausta.
- Uransa edetessä Clement ymmärsi, että hän voisi saada aikaan suuremman vaikutuksen auttamalla muita tuotepäälliköitä menestymään.
- Tämä johti hänet perustamaan Product Teacherin, jonka tavoitteena on auttaa tuotepäälliköitä uransa eri vaiheissa aloittelijoista kokeneisiin ammattilaisiin.
- Product Teacher on tukenut yli 7 000:ta tuotepäällikköä esimerkiksi alalle siirtymisessä, uralla etenemisessä sekä tuotestrategioiden ja prosessien kehittämisessä.
- Sankaruuden määritteleminen uudelleen tuotehallinnassa [02:44]
- Clement täsmentää, ettei sankaruus tuotehallinnassa ole itsessään huono asia; kyse on sen käytön tiheydestä ja asiayhteydestä.
- Tuotepäälliköiden odotetaan ottavan ohjat ja ratkaisevan ongelmia tarvittaessa, mutta sankaruuteen liian usein turvautuminen voi johtaa ongelmiin.
- Liiallinen riippuvuus sankaruudesta voi johtaa siihen, että muut tiimin jäsenet laiminlyövät vastuunsa, mikä saa organisaation kärsimään.
- Kun tuotepäälliköstä tulee ainoa sankari, se heikentää organisaation muita osa-alueita ja tekee siitä riippuvaisen yhdestä henkilöstä.
- Tasapaino on tärkeää: tuotepäälliköiden tulisi astua esiin vain silloin, kun se on todella tarpeen, ei päivittäisenä tai viikoittaisena rutiinina.
- Jos sankaruutta tarvitaan usein, se kertoo organisaation syvemmistä ongelmista, joihin on puututtava.
Tuotepäälliköiden tulisi olla valmiita astumaan esiin, kun sitä tarvitaan. Jos tästä kuitenkin tulee toistuvaa, taustalla saattaa olla ongelmia, jotka vaativat huomiota.
Clement Kao
- Miksi tuotepäälliköt päätyvät käyttämään liian monta hattua [04:54]
- Clement selittää, että monet tuotepäälliköt joutuvat sankarin rooliin työn rakenteiden muuttuessa ajan myötä.
- Vastuiden jakaminen useiden matriisien kesken on yleistynyt, ja ihmiset tukevat samanaikaisesti useita hankkeita tai tiimejä.
- Epäselvyys siitä, kenen pitäisi hoitaa tiettyjä tehtäviä, johtaa siihen, että tehtävät päätyvät oletusarvoisesti tuotepäällikölle.
- Startup-yrityksiltä ja pienemmiltä tiimeiltä puuttuvat usein selkeät ohjeet tehtävien jakamiseen, minkä vuoksi tuotepäälliköt ottavat vastuulleen monenlaisia tehtäviä.
- Kun tuotepäällikkö hoitaa jonkin tehtävän onnistuneesti, syntyy itseään vahvistava kierre, jossa hänen odotetaan jatkavan sen tekemistä.
- Esimerkkejä ovat tuotepäälliköt, jotka ottavat vastuulleen analytiikan, markkinatutkimuksen, keskustelut asiakkaiden kanssa tai myyntikeskustelut pysyvästi.
- Suuntaus on voimistunut viimeisen vuosikymmenen aikana, ja tuotepäälliköt kuormittuvat, koska heidän koetaan olevan päteviä monilla eri alueilla.
- Organisaation heikkouksien tunnistaminen ja korjaaminen [06:58]
- Clement ehdottaa, että toistuvat tilanteet, joissa tuotepäälliköiden täytyy toimia sankareina, voivat olla merkki organisaation puutteista.
- Satunnaisia sankaritekoja odotetaan, mutta toistuvat toimintamallit viittaavat syvempiin ongelmiin.
- Jälkiarviointeja arvostavien organisaatioiden tulisi käyttää niitä ongelmien analysointiin ja niiden toistumisen estämiseen.
- Jos samanlaisia ongelmia ilmenee toistuvasti, on ratkaisevan tärkeää puuttua niiden taustalla oleviin syihin, jotta tuotepäälliköt eivät jatkuvasti ottaisi vastuulleen tehtäviä oman vastuualueensa ulkopuolelta.
- Säännöllisten jälkiarviointien tulisi auttaa tunnistamaan ja korjaamaan toimintamalleja, joissa tuotepäälliköt kuormittuvat liikaa tai ottavat hoitaakseen tehtäviä, joita heidän ei pitäisi käsitellä.
- Tehokkaat jälkiarvioinnit: työkalu organisaation muuttamiseen [08:07]
- Clement korostaa syyllistämättömien jälkiarviointien merkitystä järjestelmätason ongelmien käsittelyssä.
- Hän kannattaa keskittymistä järjestelmään, ei yksittäisiin ihmisiin, jälkiarviointien aikana.
- Lennonjohdosta otetun esimerkin avulla hän osoittaa, että epäonnistumiset johtuvat harvoin yhden ihmisen toiminnasta vaan pikemminkin järjestelmätason ongelmista.
- Jälkiarviointien tulisi pyrkiä parantamaan järjestelmää epäonnistumisten estämiseksi sen sijaan, että syyllisiä etsittäisiin.
- Jälkiarviointien aikana ajattelutavan tulisi olla yhteistyöhön perustuva ja keskittyä siihen, miten järjestelmästä voidaan tehdä parempi kaikille.
- Tavoitteena tulisi olla jatkuva parantaminen, jotta vastuu ei lankeaisi joka kerta yksin tuotepäällikölle ongelman ilmetessä.
Yksi jälkiarvioinnin järjestämisen tärkeä näkökulma on varmistaa, että siinä ei syyllistetä ketään vaan keskitytään järjestelmään, ei ihmisiin.
Clement Kao
- Henkilökohtaisia ja organisaatioiden tapaustutkimuksia roolien selkeydestä [11:15]
- Clement kertoo henkilökohtaisen tarinan tilanteesta, jossa hän otti vastuulleen liian monia tuoteoperaatioihin liittyviä tehtäviä, mikä haittasi tiimin kasvua.
- Aluksi hän koki velvollisuudekseen tuotepäällikkönä varmistaa tuotteen menestyksen, mutta myöhemmin hän ymmärsi heikentävänsä tiimikavereidensa toimintamahdollisuuksia, koska ei delegoinut tehtäviä.
- Hänen esihenkilönsä puuttui tilanteeseen ja auttoi häntä ymmärtämään, että vastuita oli delegoitava muille tiimin jäsenille skaalautuvuuden ja pitkän aikavälin menestyksen varmistamiseksi.
- Onnistuneen korjaamisen keskeisiä tekijöitä olivat johdon sitoutuminen, vastuiden uudelleenmäärittely omistajuuden mahdollisuuksiksi sekä säännölliset seurantakeskustelut sujuvan siirtymän varmistamiseksi.
- Kokemus opetti Clementille vastuiden jakamisen ja tiimikavereiden voimaannuttamisen tärkeyden, jotta he voivat ottaa tehtävänsä omistajuuden.
- Clement kertoo myös tuoreesta tapaustutkimuksesta suuressa organisaatiossa, jossa tuotetiimi siirtyi ratkaisuarkkitehtuurista tuotepäälliköiden tehtäviin.
- Aluksi tiimi, joka koostui pääasiassa entisistä ratkaisuarkkitehdeistä, kamppaili rooliensa erottamisen kanssa, mikä johti päällekkäisyyksiin ja epäselvyyksiin.
- Tuotetiimi otti epähuomiossa vastuulleen ratkaisuarkkitehtuuriin kuuluvia tehtäviä, mikä haittasi skaalautuvuutta ja pitkän aikavälin menestystä.
- Useiden yhteydenottojen ja keskustelujen avulla tiimi linjasi roolinsa uudelleen ja selkeytti, että tuotepäälliköt keskittyvät tuotteen ydinalueiden kehittämiseen, kun taas ratkaisuarkkitehdit vastaavat asiakaskohtaisista ratkaisuista.
- Tiimin avoimuus palautteelle ja halukkuus määritellä suhteensa uudelleen jo varhaisessa vaiheessa vaikuttivat sen menestykseen.
- Tämä ennakoiva lähestymistapa ehkäisi pitkäaikaisia ongelmia ja varmisti, että jokainen tiimin jäsen vastasi omaan rooliinsa liittyvistä tehtävistä, mikä edisti skaalautuvuutta ja tehokkuutta.
- Clement kertoo henkilökohtaisen tarinan tilanteesta, jossa hän otti vastuulleen liian monia tuoteoperaatioihin liittyviä tehtäviä, mikä haittasi tiimin kasvua.
- Ajattelutavat ja kypsyys: organisaation kasvun hallinta [21:46]
- Arvioi henkilökohtaista työkuormaasi säännöllisesti tunnistaaksesi tehtävät, jotka eivät liity tuotteen ydintehtäviin. Tunnista myös ylikuormittuneisuuden tai veden alla olemisen tunteet, sillä ne voivat kertoa rooliodotusten ja todellisuuden välisestä ristiriidasta.
- Kerro esihenkilöllesi tehtävistä, jotka vievät aikaa mutta eivät liity tuotteen ydintehtäviin. Esitä tietoa ajankäytöstä ja työkuorman epätasapainon taustalla olevista syistä. Esihenkilöt hyötyvät ristiriitojen ymmärtämisestä, sillä se auttaa heitä saavuttamaan tiimin tavoitteet tehokkaasti.
- Työskentele esihenkilösi kanssa tunnistaaksesi tehtävät, jotka sopivat paremmin muille tiimeille. Kerro, miksi tietyt tehtävät tulisi siirtää ja miten se edistää organisaation skaalautuvuutta. Aloita keskustelut asiaankuuluvien tiimien kanssa vastuiden siirtämisen helpottamiseksi.
- Varmista tehtävien sujuva siirtyminen niistä vastaaville tiimeille. Tarjoa tarvittava taustatieto ja tuki uusille tiimeille, jotka ottavat vastuut hoitaakseen. Seuraa tilannetta säännöllisesti varmistaaksesi onnistuneen käyttöönoton ja ratkaise esiin tulevat ongelmat.
- Keskity selkeämmin tuotteen ydintehtäviin, mikä johtaa vaikuttavampiin tuloksiin. Saat lisää aikaa asiakkaiden, suunnittelun, teknisen toteutuksen ja liiketoimintastrategioiden syvälliseen tarkasteluun. Koet ajattelusi selkeytyvän ja tuottavuutesi paranevan, kun delegoit ydintehtäviin kuulumattomat tehtävät tehokkaasti.
- Varaa aikaa erityisesti työkuorman kestävyyden strategiseen suunnitteluun ja ennakointiin. Omaksu kaksoisrooli, jossa toinen rooli keskittyy tehtävien suorittamiseen ja toinen strategiseen ajatteluun ja suunnitteluun. Tunnista henkilökohtaisten sidosryhmätarpeiden merkitys tehokkaiden tuotepäällikön käytäntöjen edistämisessä.
Tapaa vieraamme
Clement Kao on Product Teacherin perustaja. Product Teacher on tuotepäällikkökoulutukseen keskittyvä yritys, joka vauhdittaa tuoteosaajien kehittymistä yrityksille suunnattujen koulutustyöpajojen, tilauksesta katsottavien videokurssien ja johtamisvalmennuksen avulla. Ennen Product Teacherin perustamista Clement toimitti useissa yrityksissä tuoteryhmäpäällikkönä yli 10 useiden miljoonien dollarien arvoista tuotetta ja edisti yhteisarvoltaan miljardien dollarien menestyksekkäitä irtautumisia. Clementin kirjoituksia on julkaistu Amplitudessa, Mixpanelissa, Gainsightissa ja muissa johtavissa julkaisuissa.
Tuotepäälliköt unohtavat usein, että he itse ovat keskeisiä sidosryhmiä eivätkä voi tehtäviään hoitaessaan laiminlyödä tätä näkökulmaa.
Clement Kao
Tämän jakson materiaalit:
- Tilaa CPO Club -uutiskirje
- Verkostoidu Clementin kanssa LinkedInissä
- Tutustu Product Teacheriin
Aiheeseen liittyvät artikkelit ja podcastit:
Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmiston avulla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.
Hannah Clark: Ennen kuin sukellamme aiheeseen, haluan täsmentää, mitä tarkoitan tuotehallinnan sankareilla. En tarkoita ajatusjohtajia, kuten Marty Cagania tai Lenny Rachitskia, vaan SINUA. Tarkoitan henkilöä, johon tuotetiimisi nojaa pelastamaan päivän, kun jokin asia leimahtaa tuleen. Tarkoitan sankaria, joka käyttää monia hattuja, mutta ei koskaan viittaa. Tarkoitan syytä siihen, ettet tunnu pystyvän työskentelemään alle 50 tuntia viikossa ja tunnet silti, ettet ole edistynyt yhtään enempää kuin edellisellä viikolla.
Jos tämä kuulostaa sinulta, hyviä uutisia — tämän päivän vieraana on Product Teacherin perustaja Clement Kao. Hän on valmentanut tuotejohtajia kaikenlaisissa ympäristöissä varhaisen vaiheen startup-yrityksistä Fortune 500 -yrityksiin ja nähnyt runsaasti tuotetiimien dynamiikkaa, mukaan lukien paljon sellaisia tilanteita, jotka tarvitsivat vakavaa pelastamista.
Keskustelemme pian siitä, miksi tuotetiimin sankarina oleminen on aivan omanlaisensa vaara. Jos tämä tuntuu tutulta, kuuntele loppuun asti, niin saat selville, kuinka voit saada yli-inhimillistä voimaa tilanteen kääntämiseksi. Aloitetaan.
Tervetuloa takaisin Product Manager Podcastiin. Tänään seurassani on Clement Kao. Hän on Product Teacherin perustaja.
Clement, kiitos paljon, että liityit seuraamme tänään.
Clement Kao: Kiitos paljon kutsusta.
Hannah Clark: Aloitetaan samalla tavalla kuin aina. Voisitko kertoa hieman taustastasi ja siitä, mikä johti sinut perustamaan Product Teacherin?
Clement Kao: Erinomainen kysymys. En alun perin aloittanut tuotehallinnassa heti valmistuttuani korkeakoulusta.
Aloitin itse asiassa hallintokonsolissa. Sitten minusta tuli hallintokonsolissa sattumalta käyttäjäkokemustutkija. Sen jälkeen minusta tuli sattumalta data-analyytikko. Ja sen jälkeen minusta tuli sattumalta tuotepäällikkö. Taustani on siis hyvin epätyypillinen. Jatkoin uraani tuotepäällikkönä aloittaen apulaistuotepäällikkönä tikkaiden alimmalta askelmalta ja etenin tuotepäälliköksi, vanhemmaksi tuotepäälliköksi, tuoteryhmän päälliköksi ja pääasialliseksi tuotepäälliköksi.
Yksi asia, jonka huomasin, oli se, että monet muut kamppailivat samojen asioiden kanssa kuin minä. Heillä ei välttämättä ollut oikeita resursseja saatavilla. Miten tämä tietty ongelma ratkaistaan? Miten tästä tietystä virheestä selvitään? Mitä kaikki nämä eri termit tarkoittavat ja miksi näillä asioilla on merkitystä?
Kun etenin yhä vanhemmaksi itsenäisenä tuotepäällikkönä, aloin kysyä itseltäni, miten voisin saada aikaan mahdollisimman suuren vaikutuksen. Aloin ymmärtää, ettei suurimman vaikutuksen tekeminen välttämättä tarkoittanut tuotehallinnan jatkamista yhdessä yrityksessä. Sen sijaan voisin auttaa satoja, ellei tuhansia, muita tuotepäälliköitä onnistumaan silloin, kun heistä tulee ensimmäistä kertaa tuotepäälliköitä.
Se voi olla hyvin hämmentävä siirtymä, minkä jälkeen heitä voi auttaa etenemään urallaan. Siksi päätin perustaa Product Teacherin. Product Teacher on auttanut yli 7 000:ta tuotepäällikköä menestymään työssään: olipa kyse tuotehallintaan siirtymisestä ensimmäistä kertaa, ylennyksen saamisesta tai siitä, että tuotepäällikkönä asetetaan tuot strategia ja varmistetaan selkeät prosessit kaikille tiimin jäsenille.
Matka on ollut uskomattoman palkitseva.
Hannah Clark: Hienoa. Kuulostaa siltä, että tämä on ollut uramatkasi tarkoituksellisin osa eikä…
Clement Kao: Kyllä. Se oli yksi asia, jota en tehnyt vahingossa.
Hannah Clark: Tänään tarkastelemme sankaruuden ajatusta tuotehallinnassa. Olet jossain määrin asettunut sitä vastaan. Mitä se tässä yhteydessä tarkoittaa, ja miten näet sen ilmenevän organisaatioissa, joiden kanssa olet työskennellyt?
Clement Kao: Erinomainen kysymys. Haluan täsmentää, etten sano sankaruuden olevan kokonaisuudessaan huono asia. Yksi tuotepäällikön keskeisistä vastuista on se, että viimeinen vastuu pysähtyy hänelle.
Sinun vastuullasi on varmistaa tuotteen onnistuminen, ja sinun on oltava valmis tarttumaan toimeen siinä, mikä kulloinkin on tarpeen. Jos meillä ei esimerkiksi ole laadunvarmistajaa ja asiat on testattava kunnolla ennen tuotantoon siirtämistä, tuotepäällikön on ehkä hypättävä mukaan. Jos suunnittelijamme on sairaana ja insinöörien työn vapauttamiseksi on saatava asia liikkeelle, tuotepäällikön on ehkä autettava. Jos asiakkailla on vaikeuksia ymmärtää tuotteen jotakin osaa, tuotepäällikön on ehkä otettava tuotetoimintojen rooli ja varmistettava käyttöönoton onnistuminen.
Tuotepäällikön täytyy pystyä astumaan mukaan. Keskeinen ongelma tuotehallinnan sankaruudessa syntyy kuitenkin silloin, kun sitä pidetään asiana, jota pitäisi tehdä jatkuvasti, sen sijaan että sitä tehtäisiin vain poikkeustilanteissa.
Tuotepäällikön pitää siis pystyä tarvittaessa astumaan esiin ja saamaan asiat tapahtumaan, mutta hänen ei pitäisi olla henkilö, joka tekee jatkuvasti kaiken. Näen usein tilanteita, joissa joku sanoo: ”Tuo tuotepäällikkö on todellinen sankari.” Todellisuudessa hän ottaa paljon työtehtäviä pois muilta kollegoilta saadakseen tuotteen toimimaan.
Se johtaa muun organisaation näivettymiseen. Tuotemarkkinoinnin, tuoteanalytiikan, asiakasmenestyksen tai myynnin näkökulmasta tarvittavia asioita ei enää tehdä kunnolla. Kaikki nämä osa-alueet muuttuvat heikommiksi ja vähemmän toistettaviksi, kun yhden henkilön varaan lasketaan kaiken tekeminen.
Olen nähnyt tämän ympärilläni. Kun tuotepäällikkö sairastuu, lähtee lomalle tai poistuu organisaatiosta, kaikki ovat vaikeassa tilanteessa.
Haluan siis korostaa, että tuotepäälliköiden pitää tietenkin olla valmiita astumaan esiin tarpeen vaatiessa. Jos tarve kuitenkin syntyy päivittäin tai viikoittain, taustalla on todennäköisesti syvempi ongelma, johon on puututtava.
Hannah Clark: Voimme kuvitella joitakin loogisia seurauksia sille, että tuotepäällikkö on jatkuvasti tällaisessa asemassa. Miksi uskot, että niin monet tuotepäälliköt ovat silti tässä tilanteessa?
Clement Kao: Erinomainen kysymys. Uskon, että tuotepäälliköt jäävät tähän asemaan usein siksi, että työn luonne on muuttunut ajan myötä. Kaikkien odotetaan hallitsevan jatkuvasti monia erilaisia asioita samanaikaisesti.
Aiemmin saattoi olla yksi käyttäjäkokemussuunnittelija, joka keskittyi yhteen aloitteeseen. Nyt sama henkilö saattaa tukea viittä tuotetta. Liiketoiminta-analyytikon oletettiin ehkä keskittyvän yhteen keskeiseen aloiteryhmään, mutta nyt hän tukee seitsemää eri tiimiä.
Kun työtä jaetaan näin ristiin, on paljon epäselvempää, kenen pitäisi ottaa vastuu. Kun jokin menee pieleen, ei ole selvää, kenen pitäisi astua esiin. Koska asia ei ole selvä, tuotepäällikkö joutuu oletusarvoisesti astumaan mukaan.
Jos olisi enemmän selkeyttä siitä, kuka vastaa mistäkin tilanteesta, tuotepäällikön ei tarvitsisi puuttua asiaan. Teknologiastartupien ja pienempien, itsenäisempien tiimien yleistyessä selkeät ohjeet siitä, kuka tekee mitä, kuitenkin puuttuvat usein.
Aina kun ajatellaan, ettei tiedetä, kenen pitäisi tehdä jokin asia, siitä tulee tuotepäällikön tehtävä. Kun hän tekee sen kerran hyvin, syntyy itseään vahvistava kehä: tuotepäällikkö teki tämän aiemmin ja teki sen todella hyvin, joten hänen kannattaa antaa tehdä se uudelleen.
Olen nähnyt tuotepäälliköiden ottavan vastuulleen kaiken analytiikan, kaiken markkinatutkimuksen, kaikki asiakaskeskustelut, kaikki myyntikeskustelut ja kauppojen päättämisen. He ovat tehneet nämä asiat paremmin kuin muut, joten niiden annetaan jäädä heille.
Näin tämä tilanne on mielestäni yleistynyt viimeisen noin vuosikymmenen aikana.
Hannah Clark: Onko olemassa varhaisia merkkejä siitä, ettei organisaatio ole tehnyt riittävästi suojellakseen tuotepäälliköitään sankarin asemaan joutumiselta tai ettei prosesseihin ole panostettu riittävästi?
Clement Kao: Yksi tapa ajatella asiaa on, että tunnistat sen, kun näet sen. Jos sinun täytyy hypätä mukaan kerran, se on täysin hyväksyttävää ja odotettua. Jos kuitenkin huomaat tekeväsi sitä usein — esimerkiksi lähes kuukausittain, jokaisen julkaisun yhteydessä tai aina virheen ilmetessä — kyseessä on kaava.
Jos sama asia tapahtuu kahdesti peräkkäin, tarvitaan todennäköisesti syvempi keskustelu. Jos organisaatio arvostaa jälkikäteisarviointeja, niitä kannattaa käyttää. Jos niitä ei tehdä, ne kannattaa ottaa käyttöön kysymällä, miksi ongelma syntyi.
Ensimmäisen kerran jälkeen tehdyn arvioinnin pitäisi ihannetapauksessa estää sama asia toistumasta. Jos se tapahtuu uudelleen, arvioinnissa pitäisi käsitellä sitä, miksi kyseessä on kaava. Näin voidaan havaita, että tuotepäälliköt tekevät säännöllisesti asioita, jotka ylittävät heidän vastuualueensa.
Hannah Clark: Jälkikäteisarvioinnit kuulostavat hieman epämukavalta ratkaisulta tällaiseen ongelmaan.
Clement Kao: Ne ovat erittäin epämukavia.
Hannah Clark: Millainen prosessi tuotepäällikön pitäisi järjestää, jotta jälkikäteisarviointi olisi riittävän hyvä ja kaikki saataisiin mukaan tekemään tarvittavat muutokset tilanteen korjaamiseksi?
Clement Kao: On todella tärkeää, että jälkikäteisarviointi tehdään syyttelemättä ja että tarkastelemme järjestelmää ihmisten sijaan. Emme halua arvioinnin muuttuvan keskusteluksi siitä, kuka oli liian kiireinen tai kuka ei tehnyt jotakin.
Otetaan esimerkiksi yritysasiakas, joka on turhautunut tuotteen nykyiseen käyttökokemukseen. Meillä saattaa olla tuotepäällikkö, joka osaa ohjelmoida, kun taas ohjelmistosuunnittelijat eivät tiukkojen määräaikojen vuoksi ehdi tehdä pientä tekstimuutosta. Tuotepäällikkö kirjoittaa koodin itse, yhdistää muutoksen ja vie sen tuotantoon.
Jälkikäteisarviointia ei pitäisi aloittaa sanomalla, että insinööri oli liian kiireinen. Sen sijaan pitäisi kysyä, miksi emme kiinnittäneet enemmän huomiota siihen, kun asiakas toi ongelman esiin kuusi kuukautta sitten. Miksi odotimme siihen asti, että asiakas turhautui vakavasti ja oli peruuttamassa sopimusta, ennen kuin tuotepäällikkö puuttui asiaan?
On tärkeää tarkastella järjestelmää. Kyse ei ole siitä, että tietty henkilö ei nostanut asiaa esiin oikeaan aikaan, vaan siitä, mitä voisimme prosessina ja järjestelmänä tehdä paremmin, jos sama tilanne syntyy uudelleen.
Ajattelin hiljattain lennonjohtoa. Lennonjohtajan tehtävä on varmistaa, että koneet nousevat ja laskeutuvat turvallisesti eikä törmäyksiä tapahdu. Jos törmäys tapahtuu, lennonjohtaja oli paikalla, mutta se ei tarkoita, että vika olisi sataprosenttisesti hänen. On olemassa monia toisiinsa vaikuttavia tekijöitä, jotka voivat muodostaa yhden vikapisteen.
Emme halua vahvistaa yhtä vikapistettä. Haluamme useita kohtia, joissa voimme estää ongelman syntymisen aiemmin. Vastuu ei saa olla vain sillä yhdellä henkilöllä, jonka titteli on tuotepäällikkö.
Jälkikäteisarvioinnin tärkein ajattelutapa on: käymme tämän läpi yhdessä. Emme osoittele sormella emmekä sano, että tietty henkilö on syyllinen ja hänen uransa on vaarassa. Tarkastamme järjestelmän. Mikä järjestelmässä meni pieleen? Miten voimme tehdä järjestelmästä ensi kerralla hieman paremman kaikille?
Tämä auttaa varmistamaan, että meillä on oikeat tukiroolit ja tukiprosessit. Tuotepäällikön ei tarvitse joka kerta yhdistää koodia tai estää asiakasta vaihtamasta toimittajaa.
Jos tuotepäällikkö kuitenkin tarvitaan jokaiseen asiakaskeskusteluun, on syytä miettiä uudelleen, miten asia järjestetään.
Hannah Clark: Se on järkevää. Ongelma täytyy ikään kuin selvittää käänteisesti ja löytää ratkaisu sen lähtökohdasta. Oletko nähnyt tuotetiimien kanssa työskennellessäsi organisaatioita, jotka ovat onnistuneet korjaamaan tällaisen ongelman?
Clement Kao: Kyllä. Kerron ensin omasta kokemuksestani. Jouduin eräässä vaiheessa tekemään kaikki tuotetoimintojen tehtävät, vaikka se ei olisi kuulunut minulle.
Työskentelin B2B-ohjelmistopalvelussa uuden tuotteen parissa, joka oli rinnakkainen nykyisen tuotteemme kanssa. Koska olin tehnyt asiakastutkimuksen ja ymmärsin asiakkaiden ongelmat, huolehdin julkaisutiedoista, tallenteista ja siitä, että asiakkaat osaisivat ottaa tuotteen käyttöön ja menestyä sen kanssa.
Se toimi, kun käyttäjiä oli kolme. Kun käyttäjiä oli 70, olin tehnyt virheen: en ollut nostanut asiaa esiin aiemmin. Olisin voinut jo kymmenennen tai viidennentoista asiakkaan kohdalla sanoa, ettei tehtäväni ole järjestää jokaista esittelyä ja koulutusta. Jonkun muun pitäisi omistaa se vastuu.
Ajattelin tuolloin, että koska olen tuotepäällikkö, minun pitää varmistaa tuotteen onnistuminen hinnalla millä hyvänsä. En ymmärtänyt, että vein asiakasmenestyksen ja tuotemarkkinoinnin ihmisiltä mahdollisuuden saada kokonaisvaltainen kuva asiakkaiden kokemuksesta.
Hyvistä tarkoitusperistäni huolimatta heikensin tiimikavereideni asemaa. En antanut heille mahdollisuutta omistaa kokonaisuutta alusta loppuun, vaan hyppäsin aina tarvittaessa mukaan.
Esihenkilöni huomasi tämän ja sanoi, että olin joutumassa veden alle ja tein asioita, jotka eivät teknisesti kuuluneet minulle. Vastasin, että viimeinen vastuu pysähtyy minulle. Hän sanoi, että näin toimimalla estin vankan asiakastukijärjestelmän rakentamisen.
Pystyin tukemaan yhtästä kymmeneen asiakasta, mutta 70 asiakkaan kohdalla olin venymisen rajalla. Jos asiakasmäärä kaksinkertaistuisi seuraavana vuonna, miten voisin selvitä? Se oli hyvä huomio.
Tämän jälkeen kokosimme kaikki asiaankuuluvat ihmiset yhteen ja päätimme, kuka omistaa minkäkin asian. Vastuun antaminen ei ollut taakka, vaan mahdollisuus. Annoimme ihmisille uusia rooleja ja uusia supervoimia.
Tässä onnistumisen kannalta oli olennaista kaksi asiaa. Ensinnäkin tuotepäälliköiden johtajien piti tukea ajatusta siitä, etteivät nämä tehtävät kuuluneet minulle. Toiseksi asia täytyi sanoittaa oikein. Emme antaneet ihmisille lisää epämiellyttävää työtä, vaan enemmän omistajuutta ja mahdollisuuden hallita kokonaisuutta alusta loppuun.
Sen jälkeen tarkistimme tilanteen säännöllisesti. Aluksi tapasimme viikoittain tai joka toinen viikko ja kävimme läpi, miten siirtyminen eteni, mitä tietoja piti siirtää ja mitä olin aiemmin tehnyt, mistä he nyt vastasivat.
Emme halunneet vain heittää vastuuta toiselle ja kadota. Olemme kaikki tiimikavereita, joten siirtymään tarvittiin muutama yhteinen tarkistuspiste. Uusien omistajien piti ymmärtää, mitä aiemmin tapahtui, mutta heidän ei tarvinnut jatkaa täsmälleen samalla tavalla. Nyt he omistivat asian ja saattoivat löytää paremman toimintatavan.
Hannah Clark: Pidän siitä, miten kuvaat tiimille palautuvaa toimijuutta ja työkuorman jakamista. Olen nähnyt samaa organisaatioissa, joissa joku ottaa epäoikeudenmukaisesti vastuun tehtävästä, joka ei oikeasti kuulu hänelle. Se rajoittaa hänen kehittymistään ja muiden mahdollisuuksia osallistua.
Clement Kao: Kerron vielä tuoreemmasta tapauksesta. Työskentelen parhaillani suuressa organisaatiossa, jossa tuotetiimi on melko uusi. Monet tiimin jäsenistä toimivat aiemmin ratkaisusuunnittelijoina.
Organisaatiossa oli aiemmin tietotekniikkatiimi, joka rakensi räätälöidyn ratkaisun jokaiselle asiakkaalle. Se ei ollut skaalautuva tuote. Johto päätti perustaa tuotetiimin, koska eri räätälöidyissä ratkaisuissa oli paljon yhteistä.
Ratkaisusuunnittelijoista osa siirtyi tuotetiimiin ja alkoi rakentaa skaalautuvaa teknologiaa yksittäisten ratkaisujen sijaan. Aiemman taustansa vuoksi he kuitenkin jatkoivat ratkaisusuunnittelua tuotepäälliköinä.
Ratkaisusuunnittelijat, joiden piti työskennellä asiakkaiden kanssa ja päättää, mitä rakennetaan, alkoivat kysyä, mikä heidän tehtävänsä enää oli. Tuotetiimi yritti tehdä sekä ratkaisusuunnittelua että tuotehallintaa.
Tuotetiimin täytyi keskittyä ydinasiakkaan rakentamiseen: vankan alustan luomiseen, jotta ratkaisusuunnittelijat voisivat yhdistää asiakkaiden tarvitsemat erityiset osat ilman räätälöityä kehitystyötä.
Tavoitteena oli siirtyä yhdestä tuotepäälliköstä ja yhdestä asiakkaasta malliin, jossa yksi tuotepäällikkö omistaa ytimen ja ratkaisusuunnittelijat työskentelevät yksittäisten asiakkaiden kanssa.
Tämä vaati useita keskusteluja koko tiimin kanssa. Tuotepäälliköt halusivat tehdä työnsä hyvin, mutta jos he veisivät ratkaisusuunnittelijoilta mahdollisuuden ratkaista asiakkaiden ongelmia, heillä ei olisi aikaa rakentaa teknologista ydintä, joka auttaisi kaikkia muita ratkaisusuunnittelijoita työskentelemään nopeammin.
Tiimin täytyi erottaa lyhyen ja pitkän aikavälin tarpeet toisistaan ja palauttaa omistajuus ratkaisusuunnittelijoille. Koska tuotetiimi oli ollut olemassa alle vuoden, tämä havaittiin ajoissa. Tuotepäällikkö omistaa tuotteen ja ratkaisusuunnittelija ratkaisun.
Hannah Clark: Haluaisin puhua vielä ajattelutavoista, organisaation kypsyydestä ja siitä, miten ne vaikuttavat työskentelyyn. Kun organisaatio kypsyy ja ihmiset kehittävät roolejaan ja prosessejaan, kaikki monimutkaistuu ja kuormitus kasvaa. Voi joutua tilanteeseen, joka ei tunnu kestävältä mutta näyttää ainoalta mahdolliselta vaihtoehdolta.
Jos tuotepäällikkö on jo kuormittunut ja on aiheuttanut tahattomasti organisaation näivettymistä, mitä hän voi odottaa tunnelin päässä, jos hän todella tekee työtä vapautuakseen näistä kahleista? Miten tällaisessa vaiheessa olevassa organisaatiossa voi puolustaa itseään?
Clement Kao: Erinomainen kysymys. Lähestyisin asiaa alhaalta ylöspäin. Ensimmäinen vaihe on tunnistaa, että olet veden alla tavalla, johon et alun perin sitoutunut.
Tätä havaintoa ei usein synny, koska olet niin kuormittunut. Jos työskentelet 70–80 tuntia viikossa, sinulla ei ole aikaa miettiä, kuuluuko tekemäsi työ edes tuotehallintaan.
Viikon alussa tai lopussa kannattaa käyttää kymmenen minuuttia sen pohtimiseen, miltä nykyinen työ tuntuu. Teetkö todella tuotetyötä? Liikutatko oikeita mittareita? Teetkö asioita, jotka eivät tuota suurinta arvoa, mutta joita sinun oletetaan silti tekevän?
Alat ehkä ymmärtää, että tehtäväsi pitäisi olla asiakkaan ongelman ymmärtäminen, suunnittelun ja insinöörityön koordinointi sekä tuotteen käyttöönoton suunnittelu. Jos teet paljon muutakin, on syytä kysyä, mitä tapahtuu.
Toinen vaihe on saada esihenkilösi mukaan. Esihenkilö ei välttämättä tiedä kaikesta tekemästäsi työstä, koska hänellä on omat mittarinsa ja vastuunsa. Kun kerrot käyttäväsi kymmenen tuntia viikossa asioihin, jotka eivät kuulu sinulle, hän todennäköisesti kysyy, mikset kertonut aiemmin.
Omien mittareidesi saavuttaminen on myös esihenkilösi etu. Et siis häiritse häntä, vaan autat häntä onnistumaan. Kerro, mitä teet, kuinka paljon aikaa siihen kuluu ja miksi uskot tekeväsi näitä asioita.
Kun olette samalla sivulla, voitte keskustella muiden tiimien kanssa siitä, kenelle eri tehtävien pitäisi kuulua. Ehkä teet käyttöliittymäsuunnittelua, vaikka organisaatiossa on suunnittelija. Ehkä teet satunnaisia SQL-kyselyitä, vaikka analytiikkatiimi voisi rakentaa koontinäytön, joka automatisoi työn pysyvästi.
Sankariksi ryhtyminen ei auta organisaatiota skaalautumaan. Sen sijaan kannattaa kertoa, mitä tekee, miksi tekee sitä ja mille tiimille vastuu kuuluisi paremmin. Silloin muut tiimit voivat saada paremman näkyvyyden, skaalautuvammat prosessit ja vähemmän sokeita pisteitä.
Kun vastuut on siirretty, varmista aluksi tiheät yhteydenotot ja vähennä niitä myöhemmin. Varmista, että uusi omistaja ymmärtää aiemman kontekstin ja että hänellä on edellytykset onnistua.
Tunnelin päässä on paljon enemmän aikaa ydintuotetyöhön: asiakkaiden syvälliseen ymmärtämiseen, luovaan yhteistyöhön suunnittelun ja insinöörityön kanssa, skaalautuvien ja kannattavien tuotteiden rakentamiseen sekä liiketoiminnan kanssa työskentelyyn markkinoillemenostrategian ja uusien asiakassegmenttien parissa.
Saat todennäköisesti selkeämmän mielen ja pystyt keskittymään ydintuotteeseen. Työ on vaikeaa, mutta erittäin arvokasta. Itse pystyin sen ansiosta rakentamaan vaikuttavampia tuotteita ja ymmärtämään asiakkaitani syvemmin.
Haluan antaa vielä yhden vinkin. Tuotepäälliköt haluavat usein muiden onnistuvan ja laiminlyövät siksi itsensä. Kymmenen minuuttia oman työviikon arviointiin tuntuu helposti ajalta, jonka voisi käyttää julkaisusuunnitelman tekemiseen, dokumentaation siistimiseen tai työjonon järjestämiseen.
Minulle oli hyödyllistä jakaa itseni kahtia. On olemassa toteuttava Clement, joka tekee työn, mutta myös erillinen tuotepäällikköjohtaja, joka vaatii minua suunnittelemaan kestävämmän työskentelytavan.
Jos se auttaa, tälle henkilölle voi antaa eri nimen. Toinen nimeni on Richard, joten sanoin itselleni: ”Richard, tuotetoimintojen johtaja, odottaa ensi viikolla suunnitelmaa skaalautuvampaan työskentelyyn.” Richard vaati tätä minulta, enkä voinut luistaa siitä.
Näin sain kalenteriini tapaamisen, jossa Richard tarkisti skaalautuvuutta koskevan suunnitelman. Tämä auttoi irtautumaan ajatuksesta, että olen aina vain toteuttaja. Omistan myös strategian.
Tuotepäälliköt unohtavat usein, että he itse ovat kriittisiä sidosryhmiä. He eivät saa laiminlyödä omaa tuotepäällikkörooliaan samalla, kun toteuttavat muiden toiveita.
Hannah Clark: Pidän epätavanomaisista taktiikoista, etenkin sellaisista, joiden avulla voi tehdä oman arvonsa ja panoksensa näkyväksi. On hämmästyttävää, että kaikkein sankarillisin teko organisaatiossa voi olla muiden ja sitä kautta itsensä voimaannuttaminen.
Clement, kiitos paljon, että liityit seuraamme. Tämä oli todella hienoa. Arvostan aina näkemyksiäsi. Sinulla on paljon annettavaa tällä alalla. Mistä ihmiset voivat löytää sinut verkossa?
Clement Kao: Löydät minut LinkedInistä. Olen luultavasti ainoa Clement Kao. Löydät minut myös osoitteesta productteacher.com ilman välilyöntejä tai väliviivoja. Siellä autan muita tuotealan ammattilaisia menestymään.
Hannah Clark: Hienoa. Nähdään siellä.
Clement Kao: Kiitos kutsusta.
Hannah Clark: Kiitos kuuntelusta. Saat lisää hyödyllisiä näkemyksiä, käytännön oppaita ja työkaluarvioita tilaamalla uutiskirjeemme osoitteessa theproductmanager.com/subscribe. Voit kuunnella lisää tämänkaltaisia keskusteluja tilaamalla The CPO Clubin siellä, missä kuuntelet podcasteja.
