Kuinka menestyä tuotejohtajana ominaisuustehtaassa (Aakash Gupta, Product Growth Guy)
Termistä ”ominaisuustehdas” on tullut jonkinlainen alan muotisana, jota heitellään usein ilmoille huumorin ja alistuneisuuden sekoituksella. Mutta mitä niin sanotussa ominaisuustehtaassa työskenteleminen todella tarkoittaa ja mikä vielä tärkeämpää, miten tuotepäälliköt voivat paitsi selviytyä myös menestyä tällaisissa ympäristöissä?
Tässä jaksossa Hannah Clarkin vieraana on Aakash Gupta — tuotejohtaja ja Tuotekasvu-uutiskirjeen kirjoittaja — ja yhdessä he laativat realistisen toimintasuunnitelman ominaisuustehtaissa työskenteleville tuotepäälliköille.
Haastattelun kohokohdat
- Aakash Guptan esittely, tuotekasvun asiantuntija [00:23]
- Aakash aloitti uransa tuotehallinnan parissa vuonna 2008, jolloin ala ei ollut vielä vakiintunut.
- Hän oppi tuotehallintaa startup-yrityksessä tekemällä monenlaisia tehtäviä, kuten suunnittelua, koodausta ja sisällönhallintajärjestelmän hallintaa.
- Sen jälkeen Aakash perusti oman startup-yrityksen, jossa hän koodasi tuotteeseen entistä enemmän.
- Sen jälkeen hän liittyi thredUPiin tuotepäälliköksi ja auttoi rakentamaan kasvutiimiä.
- Aakash on sittemmin toiminut tuotehallinnan tehtävissä Googlessa, Affirmilla, Epic Gamesilla ja Apollo.iossa.
- Ominaisuustehtaasta selviytyminen: tilanteen ymmärtäminen ja siihen sopeutuminen [03:29]
- 3 pääsyytä siihen, miksi organisaatiot muuttuvat ominaisuustehtaiksi:
- Valtuutetut ympäristöt – johtajat tai tuotejohtajat ottavat etenemissuunnitelman jälleen hallintaansa, koska he eivät luota siihen, että tuotepäälliköt pystyvät tekemään kaikki päätökset itsenäisesti.
- Muutosvaihe – yrityksillä on vaikeuksia ottaa ketteriä menetelmiä käyttöön, koska muut osastot ovat tottuneet vesiputousmalliin.
- Vesiputousympäristöt – perinteisesti joissakin yrityksissä tuotehallinta on ylhäältä alaspäin johdettua, jolloin johtajat määrittelevät ominaisuudet.
- Tuotepäälliköillä ei välttämättä ole edes valtuutetussa ympäristössä sataprosenttista määräysvaltaa etenemissuunnitelmaan. Taustalla käydään neuvotteluja ja tehdään kompromisseja.
- Ominaisuustehtaisiin perustuvat mallit voivat silti menestyä joissakin yrityksissä, kuten Applessa, jossa vahva johtajuus ohjaa keskeisiä tuotepäätöksiä.
- 3 pääsyytä siihen, miksi organisaatiot muuttuvat ominaisuustehtaiksi:
- Realistiset strategiat ominaisuustehtaissa työskenteleville PM:ille [07:07]
- Aakash tunnistaa kaksi vastakkaista näkemystä siitä, miten tuotepäälliköiden tulisi toimia ominaisuustehtaissa:
- Idealistit – uskovat, että PM:ien tulisi yrittää muuttaa organisaatiota.
- Realistit – uskovat, että useimmilla PM:illä ei ole riittävästi kokemusta organisaation muuttamiseen.
- Monet ominaisuustehtaissa työskentelevät PM:t ovat tyytymättömiä, koska heidän idealistiset odotuksensa eivät vastaa todellisuutta.
- Ominaisuustehtaissa työskentelevien PM:ien tulisi hyväksyä tilanne ja keskittyä onnistumaan olemassa olevien rajoitteiden puitteissa.
- Aakash tunnistaa kaksi vastakkaista näkemystä siitä, miten tuotepäälliköiden tulisi toimia ominaisuustehtaissa:
- Ominaisuustehtaaseen sopeutuminen: realistinen opas [09:51]
- Aakash luopui idealistisista lähestymistavoista ominaisuustehtaiden muuttamiseen koettuaan epäonnistumisia erilaisissa ympäristöissä:
- Epic Gamesilla suunnittelijat määrittelivät ominaisuudet sen perusteella, mikä heidän mielestään oli hienoa.
- Eräässä toisessa yrityksessä johtajat hylkäsivät hänen etenemissuunnitelmansa, koska siitä puuttuivat yksityiskohtaiset ominaisuudet ja konkreettiset mittarit.
- Monilla ominaisuustehtaissa työskentelevillä PM:illä on vaikeuksia, koska he ymmärtävät ympäristön väärin. He luulevat työskentelevänsä valtuutetussa ympäristössä, vaikka näin ei ole, eivätkä keskity toimittamaan yksityiskohtaisia määrittelyjä, joita tehdas edellyttää.
- Aakash neuvoo ominaisuustehtaissa työskenteleviä PM:iä keskittymään suorituksensa parantamiseen nykyisen järjestelmän puitteissa. Hänen mielestään merkittävien muutosten toteuttaminen edellyttää suurten tiimien johtamista johtaja- tai varatoimitusjohtajatasolla.
- Arvioi tuotehallinnan menestystä omassa ympäristössäsi:
- Haastattele pitkään tehtävässä toimineita ja hiljattain ylennettyjä PM:iä.
- Esitä heille täsmällisiä kysymyksiä heidän työstään, kuten parhaasta PRD:stä tai ylennysmateriaalista.
- Rakenna heidän kanssaan suhteita ennen kuin pyydät yksityiskohtaisia tietoja.
- Määrittele roolit ja vastuut sidosryhmien kanssa:
- Keskustele kahden kesken keskeisten henkilöiden, kuten suunnittelijan ja insinöörin, kanssa.
- Kerro selkeästi, mitä odotat heiltä ja mitä he voivat odottaa sinulta.
- Ymmärrä, miten kukin henkilö haluaa työskennellä, esimerkiksi luonnosteleeko PM vai tekeekö suunnittelija rautalankamalleja.
- Testaa ja mukaudu palautteen perusteella:
- Selvitä, millaiset työn tuotokset saavat sidosryhmiltä hyvän vastaanoton.
- Opettele heidän mieltymyksiään yhteistyön kautta.
- Hio lähestymistapaasi jatkuvasti sen perusteella, mikä toimii juuri sinun ympäristössäsi.
- Jokainen PM:n työ on erilainen. Ymmärrä odotukset ja mukauta lähestymistapaasi, jotta voit menestyä ominaisuustehtaan rajoitteiden puitteissa.
- Aakash luopui idealistisista lähestymistavoista ominaisuustehtaiden muuttamiseen koettuaan epäonnistumisia erilaisissa ympäristöissä:
Sinun on arvioitava, miltä tuotehallinnan menestys näyttää omassa ympäristössäsi. Haastattele niitä, jotka ovat toimineet PM:nä yrityksessäsi pisimpään, sekä niitä, jotka on hiljattain ylennetty. Nämä ovat kaksi erinomaista näkökulmaa, jotka kannattaa ottaa huomioon.
Aakash Gupta
- Edistymispolkusi rakentaminen ominaisuustehdasympäristössä [18:07]
- Kirjaamattomat ylennyskriteerit:
- Ymmärrä, mitkä tekijät vaikuttavat ylennyspäätöksiin suoran esihenkilösi lisäksi.
- Ylennyskomiteoihin osallistuu usein useita johtajia, joilla on ilmaisemattomia odotuksia.
- Luo suhteita muihin esihenkilöihin:
- Etsi ihmisiä, jotka onnistuvat edistämään tiimiensä jäseniä.
- Aloita rakentamalla ystävyyssuhteita ja tekemällä yhteistyötä projekteissa.
- Ota selvää ylennyskomiteoista epämuodollisten keskustelujen kautta.
- Keskitä huomiosi etenemispolkuun:
- Varaa työajan ulkopuolista aikaa verkostoitumiseen ja oppimiseen.
- Ymmärrä yrityksesi ylennyksen tarkat kriteerit.
- Hyödynnä vahvuuksiasi:
- Tunnista vahvimmat PM-taitosi (esimerkiksi kirjoittaminen ja sidosryhmien hallinta).
- Hyödynnä näitä vahvuuksia saadaksesi aikaan myönteisiä vaikutuksia välittömän roolisi ulkopuolella.
- Esittele työsi asiaankuuluville henkilöille, jotka voivat vaikuttaa ylennyspäätöksiin.
- Kirjaamattomat ylennyskriteerit:
- PM-taitojen hiominen eri tasoilla [22:19]
- Vaiheittainen lähestymistapa:
- Aloita kokeilemalla tiimisi sisällä ja osoittamalla onnistuminen.
- Kerää palautetta sidosryhmiltä ja kehitä lähestymistapaasi sen perusteella.
- Kehittämisen vaiheet rajoitteiden puitteissa:
- Ominaisuuksien tulosraportit:
- Analysoi, miksi ominaisuudet onnistuivat tai epäonnistuivat, ja keskity käyttäjävaikutuksiin.
- Käytä dataa ja käyttäjäoivalluksia vakuuttavan tarinan kertomiseen.
- Tämä osoittaa kykysi mitata onnistumista ja ohjata tulevia päätöksiä (myös ominaisuusvetoisessa ympäristössä).
- Vaikutuksen arviointi:
- Luo mahdollisimman vahva perustelu optimistisine oletuksineen arvioidaksesi ominaisuuksien mahdollista vaikutusta ennen niiden rakentamista.
- Tämä auttaa hallitsemaan odotuksia ja tunnistamaan ominaisuudet, jotka eivät todennäköisesti saavuta haluttuja tuloksia.
- Selvitystyö:
- Suorita vaikutuksen arvioinnin jälkeen asianmukainen käyttäjätutkimus ongelman ja mahdollisten ratkaisujen validoimiseksi.
- Käytä Dovetailin kaltaisia työkaluja tutkimustulosten tehokkaaseen jakamiseen sidosryhmien kanssa.
- Tämä osoittaa dataan perustuvan lähestymistavan tuotekehitykseen.
- OKR:t (GPM:ille):
- Ota OKR:t käyttöön, kun tiimisi hallitsee selvitystyön ja vaikutuksen arvioinnin. (Katso myös: OKR-tiekartat)
- Tehokkaat OKR:t perustuvat dataan ja ongelmien selkeään tunnistamiseen.
- OKR-puut (GPM:ille):
- Käytä OKR-puita yhdistääksesi OKR:t tiettyihin ongelmiin ja ratkaisuihin.
- Tämä varmistaa tavoitteiden ja niiden saavuttamiseksi toteutettavien aloitteiden välisen yhdenmukaisuuden.
- Tuotestrategiat (GPM:ille):
- Kehitä tuotestrategioita vasta, kun hallitset koko OKR- ja ratkaisukehitysprosessin.
- Aito tuotestrategia edellyttää tiekartan omistajuutta ja kykyä muuttaa ongelmat ratkaisuiksi.
- Ominaisuuksien tulosraportit:
- Keskity tuotehallinnan perustaitojen kehittämiseen tavalla, joka osoittaa niiden arvon ominaisuustehdasympäristössä. Hanki vähitellen lisää vaikutusvaltaa ja hallintaa tuotekehitysprosessiin.
- Vaiheittainen lähestymistapa:
Kaikki ajattelevat, että tuotehallinta liittyy tuotestrategiaan, mutta en usko, että voit todella kirjoittaa tuotestrategiaa, ennen kuin hallitset koko OKPS-puun. Siihen asti toimitusjohtaja laatii tuotestrategiaasi kaikissa käytännön tarkoituksissa. Kun sinulla on täysi valtuutus, voit ottaa tuotestrategian osaksi kokonaisuutta.
Aakash Gupta
- Koalition rakentaminen ja käytännön soveltaminen [28:58]
- Tunnista keskeiset päätöksentekijät – Aakashin tapauksessa Epic Gamesillä heitä olivat johtajan arvostamat johtavat insinöörit ja suunnittelijat.
- Ymmärrä heidän prioriteettinsa ja haasteensa – Insinöörit ja suunnittelijat arvostivat kovan työnsä tunnustamista ja halusivat nähdä työnsä vaikutukset.
- Muokkaa lähestymistapasi heidän tarpeidensa mukaiseksi – Aakash käytti ominaisuuksien tuloksia käsitteleviä kirjoituksia osoittaakseen aiempien ominaisuuksien vaikutukset ja sisällytti suorituskykymittareita hienovaraisesti.
- Tuota arvoa ennen vaatimusten esittämistä – Korostamalla heidän työnsä myönteisiä tuloksia Aakash saavutti heidän luottamuksensa ja sai heidät suhtautumaan avoimesti hänen suorituskyvyn parantamista koskeviin ehdotuksiinsa.
- Keskity suhteiden rakentamiseen ajan mittaan – Aakash rakensi strategisesti hyvät suhteet keskeisiin ihmisiin ajan kuluessa vaikuttaakseen tuotekehitysprosessiin.
- Yleiset virheet ominaisuustehtaaympäristöissä [32:35]
- Vain tuotantomittareiden tavoittelu: Keskity lopputuloksiin eli käyttäjävaikutuksiin ominaisuustehtaan määrittämien mittareiden rinnalla. Älä unohda hyvää tuotetajua.
- Teknisen velan laiminlyönti: Hallitse sekä tahatonta teknistä velkaa (käyttäjäkokemus) että tarkoituksellista teknistä velkaa (suuri ominaisuus). Priorisoi osan tahattomasta velasta hoitamista vauhdin ylläpitämiseksi.
- Käyttäjäpalautteen huomiotta jättäminen: Pyydä aktiivisesti käyttäjäpalautetta ja kehitä suunnitelmia iteroiden ennen ominaisuuksien julkaisemista.
- FOMO:n antaa ohjata etenemissuunnitelmaa: Älä tavoittele trendejä tai kilpailijoiden ominaisuuksia. Arvioi uusien ominaisuuksien mahdollinen arvo vaikutuksen koon perusteella ennen niiden rakentamista.
- Tiimin uuvuttaminen: Puolusta työkalujen, oppimisen ja kehityksen sekä tiimin yhteisten virkistyspäivien järjestämistä moraalin ja motivaation ylläpitämiseksi.
- Laajemman kokonaisuuden unohtaminen: Kehitä tuotestrategian taitojasi ja käytä niitä etenemissuunnitelmaan vaikuttamiseen, vaikka vain rajallisesti. Tavoittele vaikuttavia ominaisuuksia, jotka hyödyttävät yritystä merkittävästi.
Tutustu vieraaseemme
Aakash eteni pienen B2B SaaS -startup-yrityksen projektipäälliköstä yksisarvisyrityksen tuotepäälliköksi 15 vuodessa. Työskennellessään Affirmilla, Epic Gamesillä ja Apollo.iolla hän kartutti syvällisen tuotepäällikön asiantuntemuksen. Hän rakensi myös yhden suurimmista seuraajakunnista, sillä hänellä on LinkedInissä yli 206 000 seuraajaa. Nykyään hän kirjoittaa täysipäiväisesti tuotteen kasvun uutiskirjettä. Hän tekee siinä perusteellista tutkimusta jakaakseen viikoittaisia näkemyksiä, jotka auttavat tuotepäälliköitä menestymään.
Vaikka nopea julkaiseminen on tärkeää, uskon, että hyvin motivoitunut ja terve tiimi tuottaa yleensä parhaat tulokset.
Aakash Gupta
Tämän jakson resurssit:
- Tilaa CPO Clubin uutiskirje
- Ota yhteyttä Aakashiin LinkedInissä ja X:ssä
- Tutustu Aakashin verkkosivustoon
- Tutustu tuotteen kasvun uutiskirjeeseen
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: Ominaisuustehdas: substantiivi. Määritelmä: ohjelmistoyritys, joka keskittyy jatkuvasti uusien ominaisuuksien rakentamiseen ja julkaisemiseen sen sijaan, että se rakentaisi tuotetta, jota käyttäjät todella haluavat. Lauseessa käytettynä: “Luulin, että minut palkattiin ohjaamaan tuotetiimiä rohkeasti uuteen suuntaan, mutta sen sijaan työskentelenkin vain ominaisuustehtaassa.”
Kerro minulle: olisiko sinun kuvasi tuon sanakirjamääritelmän vieressä? Sinun ja tuhansien muiden tuotepäälliköiden, ystäväni. Jos asiat kerran ovat näin, mitä voit tehdä tilanteelle?
Vieraamme tänään on Aakash Gupta, joka kirjoittaa ikonista Product Growth -uutiskirjettä. Ennen kuin hän keskittyi uutiskirjeeseen kokopäiväisesti, Aakash työskenteli viimeiset 12 vuotta ylemmän ja johtotason tuotetehtävissä muun muassa Epic Gamesilla, Affirmilla ja Apollolla. Hän on siis kokenut lähes kaikki vaikutusvallan tasot, joita tuotepäälliköllä voi olla.
Kuten arvata saattaa, Aakash tuntee ominaistehtaita synnyttävät olosuhteet erittäin hyvin. Hänen toimintamallinsa tuotepäällikkönä näissä organisaatioissa on käytännöllinen ja virkistävän realistinen. Tämä on jakso, jota kannattaa kuunnella tarkasti alusta loppuun, joten aloitetaan.
Tervetuloa takaisin The CPO Club -podcastiin.
Aakash, kiitos paljon, että löysit aikaa keskustella kanssamme tänään.
Aakash Gupta: Ehdottomasti. Mukava olla täällä, ja kiitos kutsusta.
Hannah Clark: Ilo on meidän puolellamme. Voitko kertoa hieman urataustastasi ja siitä, miten päädyit nykyiseen tilanteeseesi?
Aakash Gupta: Kun aloitin tuotepäällikkönä noin vuonna 2008, ala ei mielestäni ollut vielä yhtä kehittynyt. Luulen, että INSPIRED julkaistiin samoihin aikoihin, ja se auttoi todella paljon. Sitä ennen oli ehkä Ben Horowitzin kirjoitus hyvästä ja huonosta tuotepäälliköstä, mutta muuten ala ei ollut vielä varsinaisesti ammattimaistunut. Se oli pitkälti olemassa Piilaakson yrityksissä ja startup-yrityksissä.
Päädyin alalle, koska sen startupin perustajat, jossa työskentelin, seurasivat uskollisesti kaikkea Y Combinatoriin liittyvää. Monilla Y Combinator -yrityksillä oli tuolloin tuotepäälliköitä. Niinpä vaikka yrityksessä oli liittyessäni vain kuusi työntekijää, aloitin tuotepäällikkönä. Onneksi minulla oli insinööritausta: olin koodannut useita sovelluksia ja ohjelmia sekä kokeillut hieman Photoshopia.
Aloittaessani tein siis vähän kaikkea. Suunnittelin verkkosivustomme kokonaan ja suunnittelin uudelleen suuria osia sovelluksestamme, vaikka suunnittelutaitoni olivat hyvin rajalliset. Hallinnoin myös verkkosivustomme sisällönhallintajärjestelmää ja kaikkea sen taustalla olevaa teknologiaa. Olin varhaisen vaiheen tuotepäällikkönä mukana kaikessa samalla, kun yritin ymmärtää ja opetella, mitä tuotepäällikön työ oikeastaan on. Se oli hyvin startup-tyylistä.
Sen jälkeen perustin oman startup-yrityksen nimeltä Rap to Beats. Tein siellä käytännössä samaa työtä, mutta koodasin enemmän ja rakensin sovelluksesta useampia versioita. Minulla on siis rakentajatausta tuotepäällikkyydessä. Sen jälkeen siirryin varsinaisiin tuotepäällikön tehtäviin thredUP-nimiseen yritykseen, joka on nykyään pörssiyhtiö.
Liityin yritykseen sen C-rahoituskierroksen aikana ja lähdin E-kierroksen jälkeen. Rakensimme yhdessä suuren osan varhaisista kasvutiimeistä. Vuonna 2014 Uberin suositteluohjelma oli kuuma aihe. Kun julkaisimme oman suositteluohjelmamme, se vauhditti kasvua valtavasti. Tällaisilla yksinkertaisilla asioilla pystyi saamaan aikaan paljon.
Sitä ei edes ollut optimoitu. Aloin julkaista tuotteita ja ymmärtää, että tuotepäällikkönä voimme muuttaa yritysten kasvun suuntaa perustavanlaatuisesti. Silloin sitouduin todella tuotepäällikön ammattiin. Sen jälkeen olen työskennellyt tuotepäällikkönä Googlen, Affirmin ja Epic Gamesin kaltaisissa yrityksissä sekä viimeksi Apollo.io:ssa, jossa toimin tuoteliiketoiminnan varajohtajana. Nyt työskentelen kokopäiväisesti uutiskirjeen parissa.
Hannah Clark: Hienoa. Tiedän, että monet nauttivat siitä todella paljon.
Tänään keskitymme ominaistehtaisiin ja erityisesti siihen, miten tuotepäälliköt voivat selviytyä tällaisessa organisaatiossa. Termistä on nykyään tullut alalla lähes kirosana.
Aloitetaan siis alusta. Miten organisaatiot muuttuvat ominaistehtaiksi, ja miksi tämä on niin yleinen lopputulos?
Aakash Gupta: Uskon itse asiassa, että kaikki tiet johtavat ominaistehtaaseen. Jos olet esimerkiksi ympäristössä, jossa tiimeillä on klassisella tavalla paljon päätösvaltaa, viimeisten neljän tai viiden vuoden aikana on tapahtunut muutamia asioita.
Airbnb:n kaltaisessa tilanteessa perustaja on voinut ottaa vallan takaisin ja sanoa, mitä haluaa rakennettavan. Tai tuotejohtajat ovat voineet ottaa ohjat käsiinsä irtisanomisten ja uudelleenjärjestelyjen avulla. Jatkuvia uudelleenjärjestelyjä käytetään usein keinona sijoittaa ihmiset rooleihin ja saada aikaan haluttuja työtuotteita ja ominaisuuksia.
Lopulta toimitusjohtajat tai tuotejohtajat ovat viime vuosien paineiden vuoksi todenneet, ettei päätösvaltaa voida vain antaa eteenpäin. He saattavat ajatella, että 26-vuotiaalle, jolla on neljän vuoden työkokemus, ei voida antaa miljardin dollarin liiketoiminnan tuoteratkaisuja.
Siksi jopa klassisesti valtuutetuissa ympäristöissä, kuten Googlessa ja Netflixissä, tuotepäälliköt eivät enää määritä sataa prosenttia etenemissuunnitelmasta. Usein käytössä on samanaikaisesti alhaalta ylöspäin ja ylhäältä alaspäin etenevä, osittain näkymätön prosessi.
Alhaalta ylöspäin etenevässä prosessissa tuotepäällikkö kehittää ideansa ja esittää ne suunnitteluun. Kun tarkastellaan lopulta hyväksyttyä kokonaisuutta, suuri osa siitä on kuitenkin asioita, jotka johtajien on pitänyt hyväksyä, joihin heidät on pitänyt vakuuttaa tai jotka he itse ovat alun perin ehdottaneet.
Monet yritykset koristavat valtuutettua ympäristöä OKR-tavoitteilla ja neljännesvuosittaisella suunnittelulla, mutta lopputulos on päivän päätteeksi ominaistehdas. Aluksi ehkä vain neljännes yrityksistä on aidosti valtuutettuja, ja nekin ajautuvat ominaistehtaiksi.
Muiden yritysten joukossa noin 30 prosenttia on muutosvaiheessa. Ne ymmärtävät, että ketteryyteen ja valtuutettuihin tuotepäälliköihin pitäisi siirtyä, mutta suunnittelun, suunnittelun, teknisen toteutuksen, liiketoiminnan ja myynnin kaltaiset toiminnot ovat edelleen tottuneet ominaistehtaan ja vesiputousmallin toimintatapaan. Muutos vie vuosia, ehkä noin kolme vuotta.
Tällaisissa yrityksissä tuotepäälliköt ovat vastuussa mittareista, mutta samalla heille määrätään, mitä ominaisuuksia heidän pitää rakentaa. Se on sotkuinen välimuoto.
Loput ovat selkeästi vesiputousmallisia ja ominaistehtaita, ja monet ovat täysin tyytyväisiä siihen. Applen kaltaisessa yrityksessä johto määrittää suuren osan tuote- ja ominaisuuspäätöksistä. Jony Ive ja Steve Jobs tekivät aikanaan monia keskeisiä päätöksiä.
Tämä malli voi siis edelleen menestyä. Vaikka parhaiden yritysten sanotaan usein olevan valtuutettuja, kaikki tiet johtavat mielestäni lopulta ominaistehtaaseen.
Hannah Clark: Kun ajatusketjua seuraa, se käy järkeen.
Käydään läpi joitakin kirjoittamassasi blogissa esittämiäsi vaiheita. Jos et ole lukenut kirjoitusta, se on kiinnostava, koska olet jakanut asian osiin ja ottanut hieman kiistanalaisen kannan siihen, miten ominaistehtaan tuotepäällikön tulisi toimia. Ennen vaiheisiin siirtymistä, voitko kertoa näkemyksestäsi ja erityisesti siitä, miten se liittyy Melissa Perryn ajatuksiin?
Aakash Gupta: Ajattelen, että on idealisteja ja realisteja. Idealistien joukossa ovat esimerkiksi Marty Cagan, Teresa Torres ja John Cutler, joita rakastan, ihailen ja joiden kaiken kirjoittaman luen. He uskovat, että tuotepäällikön pitäisi yrittää muuttaa organisaatiota, jos se on ominaistehdas.
Se on heidän keskeinen sanomansa ja monien heidän ilmaiseksi jakamiensa työkalujen ja näkemysten taustalla. Kunnioitan heitä, mutta itse, Melissa Perry ja muut realistisemman näkökulman edustajat ajattelemme, että tuotepäälliköllä ei välttämättä ole tarvittavaa kokemusta tai vaikutusvaltaa koko organisaation muuttamiseen, ellei hänellä ole esimerkiksi kahdeksan tai kymmenen vuoden kokemusta ja ryhmätason tuotepäällikön tai sitä ylempää asemaa.
Siksi kannattaa ehkä miettiä toista strategiaa. Olen nähnyt niin monien yrittävän elää idealistisen mallin mukaan. Tuotepäällikköfoorumin suosituimpia julkaisuja tarkastellessani kahdeksan kymmenestä kirjoituksesta kertoo siitä, kuinka tuotepäälliköt vihaavat työtään ja kokevat sen kurjaksi. Kun yksityiskohtia lukee, kyse on usein ominaistehtaassa työskentelevistä tuotepäälliköistä.
He ovat saattaneet liittyä tuotepäälliköiksi luettuaan INSPIRED-kirjan ja odottaa voivansa määrittää etenemissuunnitelman, mutta päätyvätkin toimitusjohtajan tilausten toteuttajiksi. Tämä on erittäin yleinen tilanne. Ihmiset ovat ominaistehtaissa ja tyytymättömiä työhönsä.
Neuvoni onkin realistisesti: hyväksy tilanne. Antaudu tehtaalle. On parempi tietää työskentelevänsä tehtaassa. Silloin voit kysyä, mitä tehtaan työntekijän pitää tehdä tilanteen hyväksymiseksi ja eteenpäin pääsemiseksi.
Hannah Clark: Ajattelutavalla on paljon vaikutusta siihen, kuinka hyvin pärjäämme vaikeissa tilanteissa. Tilanteen ei kuitenkaan tarvitse olla vaikea.
Puhutaan siis blogikirjoituksesi vaiheista. Ensimmäinen on tehtaalle antautuminen, jota jo sivusit. Milloin se todella kirkastui sinulle välttämättömäksi vaiheeksi?
Aakash Gupta: Epäonnistuneiden muutosyritysten kautta. Olen työskennellyt monenlaisissa ympäristöissä, kuten Epic Gamesilla Fortniten parissa. Peliyrityksissä ominaisuustehtaan päätökset syntyvät usein suunnittelijoiden ja luovien tekijöiden ideoista. He haluavat rakentaa jotakin todella hienoa.
Tuotepäällikkönä näin helposti paljon matalalla roikkuvia hedelmiä suorituskyvyn, käyttöönoton ja päivitysten osalta. Fortniten päivittäminen saattoi viedä valtavasti aikaa, vaikka päivityksiä julkaistiin kahdesti viikossa. Myös kaupallistamisessa olisi ollut helppoja parannuksia.
Yritin puhua tuloksista tuotosten sijaan ja saada ihmiset keskittymään vaikuttavuuteen, mutta viesti ei mennyt perille. Myös Affirmilla suunnittelin aluksi epäselvempiin ongelmiin perustuvaa etenemissuunnitelmaa. Se ei toiminut: johtajat odottivat tarkkoja ominaisuuksia, käyttöliittymäluonnoksia ja yksityiskohtaisia vaikutusarvioita.
Olen nähnyt samaa valmentaessani tuotepäälliköitä. He luulevat toimivansa valtuutetussa ympäristössä, mutta todellisuudessa työskentelevät ominaistehtaassa, jossa vaaditaan erittäin yksityiskohtaisia määrittelyjä. Jos he eivät tunnista tätä, heidän suorituksensa kärsii.
Olen pystynyt muuttamaan käytäntöjä vasta johtaja- ja varajohtajatasolla. Silloin työhön kuuluu organisaation käytäntöjen kehittäminen. Jos et ole kyseisellä tasolla, älä yritä korjata koko vastamallia. Keskity omaan suoriutumiseen.
Hannah Clark: Se johdattaa seuraavaan vaiheeseen: sopeutumiseen ympäristöön. Kirjoitit, että pitää keskittyä todelliseen työhönsä. Voitko avata tätä ja siihen liittyviä alavaiheita?
Aakash Gupta: Tuotepäällikön menestys näyttää erilaiselta eri ympäristöissä. Epic Gamesilla menestyivät hienojen ominaisuuksien esittelyt, jopa pelattavat demot. Affirmilla taas menestyivät tarkat, dataan ja taloudellisiin vaikutuksiin perustuvat etenemissuunnitelmat.
Siksi pitää selvittää, miltä tuotepäällikön menestys omassa ympäristössä näyttää. Haastattele yrityksen pisimpään työskennelleitä tuotepäälliköitä ja hiljattain ylennettyjä ihmisiä. Rakenna ensin luottamuksellinen suhde ja kysy sen jälkeen käytännön asioita: kirjoittavatko he jokaisesta ominaisuudesta määrittelyn, voivatko he jakaa parhaan määrittelynsä tai viimeisimmän ylennyshakemuksensa.
Kun aloitat työssä, keskustele erikseen teknisen vetäjän, teknisen esihenkilön, suunnittelijan, käyttäjätutkijan, analyytikon sekä esihenkilösi ja tämän esihenkilön kanssa. Selvitä roolit, vastuut ja odotukset. Kysy esimerkiksi suunnittelijalta, mitä hän ajattelee tuotepäällikön tekemistä luonnoksista. Jotkut eivät halua niitä lainkaan, toiset hyväksyvät ne kunhan niitä ei tehdä Figmassa.
Älä oleta, että toisen tiimin tuotepäällikön työ on samanlaista kuin omasi. Lähelläsi olevilla sidosryhmillä on omat odotuksensa. Keskity ensin yhteen askeleeseen ja ympärilläsi oleviin ihmisiin. Muodostakaa keskinäinen toimintatapa ja testaa sitä käytännössä.
Hannah Clark: Kuulostaa siltä, että lähimpien työkavereiden kanssa muodostuu oma mikrokulttuuri. Sen vivahteet, kieli ja keskinäiset odotukset pitää ymmärtää.
Se liittyy myös keskusteluihin ihmisten kanssa, jotka ovat onnistuneet tehtävässä pitkään. Seuraava vaiheesi on ylennyspolun luominen. Miten tällainen uraohje rakennetaan?
Aakash Gupta: Ominaistehtaassa on yleensä johdonmukaiset ylennyskriteerit. Ne ovat usein kirjoittamattomia, lausumattomia ja jopa esihenkilön väärin tulkitsemia. Esihenkilö ei aina ole ainoa päätöksentekijä.
Esimerkiksi Affirmilla kirjoitin ylennyshakemuksen, jonka käsitteli komitea, jossa oli koko oman tasoni yläpuolella oleva tuotejohto. Kun olet vakuuttanut oman esihenkilösi, sinun pitää siis rakentaa suhteet myös muihin tuotejohtajiin ja saada heidät sanomaan sinusta jotakin myönteistä.
Etsi ylennyksiä aktiivisesti tekeviä esihenkilöitä, rakenna heidän kanssaan ensin ystävyyssuhde ja tee yhteistyötä. Kysy sitten heidän kokemuksistaan ylennyskomiteoissa. Henkilökohtaiset keskustelut työajan jälkeen voivat paljastaa paljon siitä, miten ylennykset todella toimivat.
Ensin täytä tietovajeesi: selvitä, miten ylennyspolku toimii. Sen jälkeen tunnista omat vahvuutesi. Kaikki pudottavat joskus jonkin pallon. Ehkä suunnittelupalautteesi on kahdeksan kymmenestä ja vaikeiden sidosryhmien hallinta seitsemän. Nojaa vahvuuksiisi.
Jos olet hyvä kirjoittamaan, julkaise viikoittaisia päivityksiä ja jaa tuotestrategiaasi laajemmalle. Hyödynnä vahvuuksiasi yrityksen omia ylennyskriteerejä vasten.
Hannah Clark: Tämä on erittäin älykästä ja käytännöllistä. Seuraava vaihe on erillisten käytäntöjen kehittäminen. Mitä tarkoitat niillä ja miten näitä taitoja voi vahvistaa?
Aakash Gupta: Ryhmätason tuotepäällikön tai sitä ylemmällä tasolla tätä pitäisi tehdä koko organisaatiossa. Alemmalla tasolla kokeile sitä omassa tiimissäsi.
Kun olet osoittanut, että pystyt toimimaan sidosryhmien odottamalla tavalla, pyri nostamaan käytäntöjä vähitellen. Tehokkain järjestys on mielestäni seuraava.
Ensimmäinen on ominaisuuden tulosten jälkikatsaus. Se ei uhkaa ominaistehdasta. Ominaisuus julkaistiin, joten nyt voidaan kertoa, mitä tapahtui ja miksi. Kun sanot vain, että A voitti B:n, raportoit tuloksen. Kun sanot, että A voitti B:n tästä syystä, alat vaikuttaa siihen, mitä seuraavaksi tehdään.
Toinen on vaikutusten arviointi. Kun sinulle annetaan tuotoksen rakentaminen, tee vahvin mahdollinen tietoon perustuva perustelu siitä, miten ominaisuus tulee toimimaan. Jos toimitusjohtaja uskoo jonkin ominaisuuden kasvattavan liikevaihtoa viisi prosenttia, rakenna anteliaimmilla oletuksilla laskelma. Jos paras mahdollinen tulos on 0,1 prosenttia, epärealistinen odotus voidaan osoittaa ajoissa.
Kolmas on käyttäjätutkimus. Kun sinulle annetaan käyttöliittymäluonnos, kiitä siitä ja tee asianmukainen tutkimus. Näytä haastatteluvideoita ja käyttäjien ongelmia. Siirry ratkaisun löytämisestä ongelman löytämiseen.
Neljäs on OKR-tavoitteet. Niitä kannattaa ottaa käyttöön vasta, kun tiimit tekevät tutkimusta ja osaavat kirjoittaa tulosten jälkikatsauksia sekä arvioida vaikutuksia. Muuten OKR-tavoitteet jäävät helposti tyhjiksi.
Sen jälkeen tulevat OKPS-puut, jotka yhdistävät tavoitteet ongelmiin ja ratkaisuihin, ja lopuksi tuotestrategia. Tuotestrategia on aidosti sinun vasta silloin, kun hallitset koko OKPS-puun. Sitä ennen toimitusjohtaja määrittää strategiasi käytännössä.
Hannah Clark: Seuraava vaihe on liittouman rakentaminen. Olemme jo puhuneet tiiviistä suhteista suunnittelu- ja teknisiin resursseihin. Onko sinulla käytännön esimerkkiä?
Aakash Gupta: Epic Gamesilla halusin parantaa Fortniten suorituskykyä. Data osoitti, että heikolla laitteella tai yhteydellä pelaavat käyttäjät lopettivat paljon aiemmin kuin hyvän suorituskyvyn käyttäjät.
En voinut vain esittää tätä näkemystä ja vaatia suorituskyvyn priorisointia. Minun piti vaikuttaa keskeisiin suunnittelijoihin ja insinööreihin. Selvitettyäni, keitä päätöksentekijä kuunteli, keskityin kovimmin työskenteleviin ihmisiin.
Heillä ei ollut aikaa tarkastella julkaistujen muutosten vaikutuksia, joten aloin raportoida niitä: mitä tietty päivitys teki pelille, miten tarkkuuskiväärien käyttö muuttui, miten eri taitotasojen pelaajat pärjäsivät ja miten korkea viive vaikutti pelaajien poistumaan.
He innostuivat omasta työstään ja alkoivat kuunnella minua. Vähitellen suorituskyvystä tuli osa pelin kehittämistä. Tämä on esimerkki siitä, kuinka liittouma rakennetaan taaksepäin: ensin ymmärretään, keneen pitää vaikuttaa, ja sitten rakennetaan suhde ja luottamus.
Hannah Clark: Se on nerokasta. Rakennat suhteita, ihmiset luottavat sinuun ja vaikutusvaltasi kasvaa lähes huomaamatta.
Ennen lopetusta haluan käsitellä yleisiä virheitä, joita tuotepäälliköt tekevät ominaistehtaissa. Yksi on tietysti se, ettei ymmärrä olevansa ominaistehtaassa. Mitä muita virheitä on?
Aakash Gupta: Ensimmäinen on keskittyminen vain tuotosten mittareihin. Vaikka tehdas välittäisi Jira-tehopisteistä, suurten ominaisuuksien määrästä ja aikataulussa pysymisestä, sinun pitää silti seurata lopputuloksia. Älä lopeta hyvää tuotetyötä vain siksi, että antaudut tehtaan toimintatavalle.
Toinen virhe on teknisen velan laiminlyönti. Tiimi voi kiirehtiä uusia ominaisuuksia ja unohtaa kehittäjäkokemuksen, pitkät rakennusajat ja muut ongelmat. Erottele käyttäjäkokemukseen liittyvä vahingossa syntynyt tekninen velka tarkoituksellisesta velasta. Ensimmäistä pitää minimoida, jälkimmäistä voi joskus hyväksyä, jos palaat korjaamaan sen myöhemmin.
Kolmas virhe on käyttäjäpalautteen sivuuttaminen. Kysy aina, näytettiinkö lopullisia suunnitelmia käyttäjille ennen julkaisua. Kiire ei poista vastuuta. Se, mitä tiimisi julkaisee, on ansioluettelosi. Tee siis huonostakin ideasta paras mahdollinen versio.
Neljäs virhe on se, että FOMO ohjaa etenemissuunnitelmaa. Kilpailijan CRM ei tarkoita, että tarvitsette CRM:n. Toisen työkalun LinkedIn-julkaisut eivät automaattisesti tarkoita, että teidänkin työkalunne tarvitsee ne. Arvioi ominaisuuden kohderyhmän koko ja vaikutus. Jos edellistä tuotetta käyttää vain 0,2 prosenttia käyttäjistä, kannattaa kysyä, tarvitaanko toinen samanlainen tuote.
Viides virhe on tiimin uuvuttaminen. Nopeus on tärkeää, mutta terve ja motivoitunut tiimi tuottaa yleensä parhaat tulokset. Puolusta parempia työkaluja, oppimis- ja kehitysbudjettia sekä hyvin ajoitettua tiimipäivää. Pienetkin asiat, kuten leivonnaisten tuominen tai kiitoksen antaminen, vaikuttavat paljon. Ominaistehtaassa eivät kärsi vain tuotepäälliköt, vaan myös suunnittelijat ja insinöörit.
Kuudes virhe on kokonaiskuvan unohtaminen. Kun meille annetaan jatkuvasti vain mitä, unohdamme miksi. Mieti mittareita, käyttäjien ongelmia ja tuotestrategiaa. Vaikka tuotepäälliköiden työpaikkoja on nykyään vähemmän, strateginen vaikutus auttaa menestymään.
Jokaisessa ominaistehtaassa on yleensä 10–15 prosenttia etenemissuunnitelmasta, johon voit vaikuttaa. Käytä tämä osuus hyvin. Rakenna ominaisuuksia, jotka muuttavat yrityksen suuntaa. Parhaat tuntemani ominaistehtaan tuotepäälliköt eivät julkaise jatkuvasti, mutta kun he julkaisevat, vaikutus on valtava.
Hannah Clark: Todellinen pudotushetki. Aakash, kiitos paljon ajastasi. Jos joku kuulijoista ei vielä seuraa sinua, mistä sinut löytää verkossa?
Aakash Gupta: Ensisijaisesti uutiskirjeestä. Olen Substackissa. Jos sähköpostiosoitteen ponnahdusikkuna häiritsee, sen voi ohittaa ja jatkaa lukemista.
Kirjoitan nykyään tutkimuspohjaisia artikkeleita. Keskustelen usein yli kymmenen ihmisen kanssa ja haastattelen oikeita alan ammattilaisia. Kyse ei ole vain tavallisesta LinkedIn- tai X-sisällöstä, vaan todellisista tutkimuksista ja näkemyksistä. Tuotejohtamisen työnhausta keskustelimme hiljattain varajohtajiksi tai johtajiksi edenneiden tuotejohtajien sekä alalla rekrytoivien henkilöiden kanssa. Tavoitteeni on tuoda lukijoille oikeaa dataa ja todellisia näkemyksiä.
Hannah Clark: Hienoa. Nähdään siellä, ja kiitos vielä kerran.
Aakash Gupta: Kiitos, arvostan tätä.
Hannah Clark: Kiitos kuuntelusta. Saat lisää näkemyksiä, käytännön oppaita ja työkalujen arvioita tilaamalla uutiskirjeemme osoitteessa theproductmanager.com/subscribe. Voit kuunnella lisää tämän kaltaisia keskusteluja tilaamalla The CPO Clubin sieltä, mistä kuuntelet podcasteja.
