Tässä jaksossa perehdymme ”ominaisuustehdas”-ilmiöön, jossa yritykset keskittyvät tuotteiden ja ominaisuuksien nopeaan julkaisemiseen sen sijaan, että ne asettaisivat laadun tai käyttäjien tarpeet etusijalle. John Cutler keksi termin, ja se kuvaa täydellisesti monien tiimien kohtaamaa tilannetta: ominaisuuksia julkaistaan ilman selkeää ymmärrystä siitä, kenelle ne on tarkoitettu tai miten ne vaikuttavat liiketoimintaan. Jos tämä kuulostaa tutulta, jatka kuuntelemista, kun tutkimme, miten tästä kehästä voi vapautua.
Paneelikeskustelussamme kuulemme kolmea tuotejohtajaa — Aakash Guptaa, Andrea Saezia ja Paweł Hurynia — jotka jakavat näkemyksiään tuotteen kehittämisen siirtämisestä tuotoksiin keskittyvästä lähestymistavasta tuloslähtöiseen. He tarjoavat käytännöllisiä viitekehyksiä strategisen fokuksen säilyttämiseen, keskisuurten markkinoiden paineisiin vastaamiseen ja sellaisen kulttuurin edistämiseen, jossa merkitykselliset tulokset asetetaan pelkän ominaisuusmäärän edelle. Olitpa sitten kasvattamassa liiketoimintaa tai yrittämässä herättää tiimisi luovuuden uudelleen, tämä keskustelu tarjoaa käytännön neuvoja ominaisuustehtaan ajattelutavasta irtautumiseen.
Haastattelun kohokohdat
- Osio 1: Miksi ominaisuustehtaat ovat yleisiä [02:21]
- Ominaisuustehtaaksi ajautumiseen ei ole yhtä ainoaa polkua — siihen vaikuttavat monet tekijät.
- Syitä voivat olla paine saada kauppoja päätökseen, heikko tuotejohtaminen, ”hippon” eli parhaiten palkatun henkilön mielipiteen vaikutus tai kiiltävien uusien asioiden tavoittelu.
- Perimmäinen ongelma on usein vahvan tuotejohtajan strategisen vaikutusvallan puute.
- Tuotejohtajien on ohjattava strategiaa, hallittava kompromisseja ja neuvoteltava prioriteeteista.
- Joskus myönnytykset ovat välttämättömiä (esimerkiksi liikevaihtoa tuovien ominaisuuksien rakentaminen), mutta sen jälkeen on ratkaisevan tärkeää palauttaa toiminta tuotestrategian mukaiseksi.
- Ominaisuustehtaan välttäminen ei ole mustavalkoinen asia — kyse on pitkän aikavälin strategisen fokuksen säilyttämisestä satunnaisista kompromisseista huolimatta.
- Suuret teknologiayritykset, kuten Google ja Meta, ihannoidaan usein täydellisinä tuotehallinnan esimerkkeinä.
- Todellisuudessa näiden yritysten vaikuttavat ominaisuudet ovat yleensä johdon ohjaamia eivätkä tuotepäälliköiden löytämiä.
- Tuotepäälliköiden klassinen jatkuva tuotetutkimus on näissä ympäristöissä harvinaista.
- Monet huippuyritykset toimivat enemmän ominaisuustehtaiden tavoin kuin ihmiset olettavat.
- Myös Applen ja Snapchatin kaltaisissa yrityksissä ominaisuuksia kehitetään ylhäältä alaspäin.
- Tuotepäälliköiden tulisi oppia navigoimaan ominaisuustehdastilanteissa ja toimimaan niissä tehokkaasti, sillä tällaiset tilanteet ovat ainakin ajoittain yleisiä.
- Suuret teknologiayritykset voivat ottaa riskejä ja ”julkaista oppiakseen” suuren budjettinsa ansiosta.
- Useimmilla yrityksillä ei ole tällaista mahdollisuutta, eivätkä ne pysty kantamaan samanlaista riskitasoa.
- ”Liiku nopeasti ja riko asioita” -ajattelutavan jäljittely voi olla haitallista pienemmille tai vähemmän resursoiduille yrityksille.
- On epärealistista yrittää toimia Googlen tai Facebookin tavoin ilman niiden resursseja.
- Pienempien yritysten on lähestyttävä tuotepäätöksiä varovaisemmin ja strategisemmin.
Neuvotteluja ja myönnytyksiä on tehtävä, mutta tärkeintä on, että paikalla on tuotejohtaja, joka pystyy sanomaan: ”Selvä, teimme tuon. Nyt palautetaan toimintamme strategiamme ja sen mukaiseksi, mitä todella yritämme tehdä ja ratkaista.”
Andrea Saez
- Onko ominaisuustehtaana toimiminen aina huono asia? [07:21]
- Ominaisuustehtaana toimiminen ei ole lähtökohtaisesti huono asia — se voi olla toimiva ratkaisu liiketoimintamallista riippuen.
- Kaikki ominaisuuspyynnöt eivät vaadi perusteellista tutkimusta; jotkin ovat ilmeisiä (esimerkiksi Stripe-integraatio).
- Sidosryhmillä on usein arvokkaita näkemyksiä, joita tuotepäälliköiden ei pitäisi sivuuttaa.
- Organisaation olemassa olevan tietämyksen sivuuttaminen uusien tuotepäälliköiden liittyessä yritykseen on tuhlailevaa.
- Joissakin malleissa (esimerkiksi asiakas–toimittaja-mallissa) pyydettyjen ominaisuuksien rakentaminen on oikeutettu tapa ansaita rahaa.
- Jos yrityksen liiketoimintamalli perustuu tähän, se on parempi hyväksyä tai lähteä yrityksestä kuin yrittää muuttaa sitä.
- Osio 2: Ominaisuustehtaasta ulos johtavat tiet [09:15]
- Tuotteen ja markkinoiden yhteensopivuuden heikkenemisestä kertovat muun muassa negatiivinen palaute, suuri asiakaspoistuma ja pidemmät myyntisyklit.
- Nämä paineet johtavat usein hätiköityihin ominaisuuspäätöksiin, joiden tavoitteena on pelastaa kauppoja tai asiakkuuksia.
- Tämä reaktiivinen lähestymistapa voi aiheuttaa tuotteen kokonaisuuden hajoamisen.
- Ominaisuudet saattavat irrota toisistaan, ja käyttökokemus kärsii — Andrea arvostelee humoristisesti tästä esimerkkinä Jiran kaltaisia työkaluja.
- Perimmäinen ongelma on usein heikentyvä tuotteen ja markkinoiden yhteensopivuus, joka synnyttää paniikin ohjaamaa kehitystyötä.
Jos tiimit eivät ole yhtä mieltä siitä, miten luomme arvoa, mitä asiakkaita haluamme palvella, mitä ongelmia haluamme ratkaista ja mikä rakentamassamme on erilaista, arvon tuottaminen eri tiimien välillä voi olla erittäin vaikeaa.
Paweł Huryn
- Varhainen puuttuminen tuotehallintaan [10:35]
- Aloita selkeästä strategisesta yhdenmukaisuudesta koko organisaatiossa – määrittele, miten arvoa luodaan, keitä kohdeasiakkaat ovat ja mitä ongelmia ratkaistaan.
- Varmista, että kaikki ymmärtävät yrityksen ainutlaatuisen lähestymistavan ja strategisen kontekstin (Netflixin periaatteen mukaisesti ”konteksti, ei kontrolli”).
- Yhdenmukaista tiimien ja osastojen tavoitteet organisaation keskeisten prioriteettien kanssa.
- Anna tiimeille merkityksellisiä ongelmia ratkaistaviksi ja tavoiteltavia lopputuloksia sen sijaan, että määräisit ratkaisut etukäteen.
- Tarjoa tarvittaessa valmennusta, jotta tiimit voivat omaksua jatkuvan tuotelöydön käytännöt.
- ”Ominaisuustehdas” on kielteinen termi, mutta on tärkeää tunnistaa sen tuhoisat osa-alueet ja puuttua niihin.
- Ohjaa johtoryhmän huomio oikeisiin liiketoiminta-alueisiin, mittareihin ja käyttäjien ongelmiin, jotta vaikutus olisi mahdollisimman suuri.
- Vie johtoryhmälle oivalluksia, mukaan lukien käyttäjäoivalluksia (esim. istuntojen toistot ja analytiikka) sekä dataan perustuvia oivalluksia (esim. kasvumahdollisuudet).
- Nämä oivallukset auttavat kohdistamaan huomion tärkeisiin mittareihin ja ongelmiin laajemman strategian mukaisesti.
- Anna tiimien (suunnittelijoiden ja PM:ien) iteroida ja mukauttaa toimintaansa käyttäjäpalautteen perusteella sen sijaan, että ne noudattaisivat tiukasti johtoryhmän suunnitelmia.
- Ota käyttöön tarkistuspisteitä ja tuotearviointikokouksia, jotta johtoryhmä pysyy mukana prosessissa ja vältetään ”luovutusongelma”, jossa sen suunnitelmaa ei myöhemmin oteta hyvin vastaan.
- Tiimin yhdenmukaistaminen on ratkaisevan tärkeää – varmista, että yhdenmukaisuus on aitoa eikä vain pinnallista yksimielisyyttä.
- Johtoryhmän yhdenmukaisuus on olennaista; kaikkien on oltava samalla sivulla sen suhteen, mitä tehdään, miksi, miten ja kenelle.
- Yhdenmukaisuuden puute liittyy usein kohdeasiakkaaseen (ICP), sillä tiimit saattavat yrittää myydä eri kohderyhmille.
- Tämä yhdenmukaisuuden puute voi johtaa sellaisten ominaisuuksien lisäämiseen, jotka eivät todellisuudessa sovi ydintuotteeseen tai kohderyhmään.
Tärkeintä liiketoiminnassa ei ole keskittyä mihin tahansa liiketoiminnan osaan, vaan saada johtoryhmä keskittymään niihin osa-alueisiin, mittareihin ja käyttäjien ongelmiin, joilla todella on merkitystä. On tärkeää tuoda esiin oivalluksia, jotka vahvistavat uskottavuuttasi matkan varrella.
Aakash Gupta
- Epätäydellisten ominaisuuksien julkaiseminen [17:02]
- Joskus yritykset julkaisevat epätäydellisiä ominaisuuksia aikomuksenaan viimeistellä niitä myöhemmin, mutta voivat juuttua ”ominaisuustehtaan” kierteeseen eivätkä koskaan palaa parantamaan kyseisiä ominaisuuksia.
- Paweł uskoo, että epätäydellisten ominaisuuksien julkaiseminen (esim. 70–80 prosentin ratkaisu ongelmaan) on usein oikea lähestymistapa.
- Aikainen julkaiseminen mahdollistaa arvokkaan käyttäjäpalautteen saamisen ja tarjoaa tilaisuuden parantaa tuotetta todellisen datan eikä oletusten perusteella.
- Vaikka suunnitelmia olisi testattu, käyttäjien todellinen vuorovaikutus voi paljastaa erilaisia oivalluksia, joten iteratiivinen julkaiseminen on tärkeää.
- Julkaiseminen tietoisena tavoitteesta on tärkeää; kaiken ei tarvitse olla täydellistä.
- Yleinen ongelma on ”puolivalmiiden” ominaisuuksien julkaiseminen ja se, ettei niihin palata parannusten tekemiseksi, mikä johtaa ominaisuusloukkuun.
- Tiimit saattavat keskittyä uusiin ominaisuuksiin puuttumatta käytettävyyden perusongelmiin tai parantamatta olemassa olevia ominaisuuksia.
- On taipumus olettaa, että käyttäjät selvittävät keskeneräisten ominaisuuksien käytön itse sen sijaan, että niitä viimeisteltäisiin.
- ”Ominaisuustehdas”-ongelmaan kuuluu puolivalmiiden ominaisuuksien julkaiseminen ja se, ettei niihin koskaan palata kiiltävien uusien asioiden tavoittelun vuoksi.
- Tästä kierteestä irtautumiseksi tuo johtoryhmälle käyttäjäoivalluksia (esim. heikko asiakaspysyvyys ja vähäinen käyttöönotto) sekä dataan perustuvia oivalluksia (esim. istuntojen toistot ja asiakaspysyvyysasteet).
- Heikon käyttöönoton kaltaisten ongelmien korostaminen voi auttaa saamaan tukea ominaisuuksien iterointiin tai asiakaspysyvyysongelmien ratkaisemiseen.
- Joissakin tapauksissa on parempi poistaa käytöstä ominaisuudet, jotka eivät palvele käyttäjien keskeisiä tarpeita.
- Erityisesti B2B-liiketoiminnassa ydintuotteeseen keskittyminen on usein vaikuttavampaa kuin liian aikainen laajentuminen useisiin tuotteisiin.
- Osio 3: Olemme nyt tehdastilassa – mitä seuraavaksi? [21:31]
- Tuotejohtajan (esimerkiksi tuotepäällikön tai CPO:n) tehtävänä on tunnistaa organisaation puutteet ja puuttua niihin, ei vain juhlia onnistumisia.
- Työhön kuuluu aiemman suoriutumisen arviointi, julkaistujen ominaisuuksien analysointi sekä sen määrittäminen, onnistuivatko vai epäonnistuivatko ne.
- Jos 75 % ominaisuuksista epäonnistui, lähestymistapaa on tärkeää arvioida uudelleen ja strategiaa mukauttaa tulevaisuutta varten.
- Erinomaiset tuotejohtajat puhuvat sidosryhmien kieltä ja käyttävät dataa sekä oivalluksia päätösten vaikuttamiseen pelkän teorian sijaan.
- Vahvan tuotejohtamisen puute voi myötävaikuttaa ominaisuustehtaan ongelmaan.
- Vaikeissa tilanteissa, joissa perustajat tai toimitusjohtajat eivät ole yhteistyöhaluisia, voi urakehityksen kannalta olla tarpeen harkita siirtymistä uuteen tehtävään.
- CPO tai tuotepäällikkö tarvitsee toimitusjohtajan ja C-tason johtajien tuen sekä yhteisen näkemyksen voidakseen onnistua.
- Ilman C-tason yhteistä näkemystä edistyminen on vaikeaa, ja myynnin ohjaama kehitys voi heikentää tuotejohtamista.
- Mitattavaan käyttäjäkäyttäytymiseen keskittyminen on ratkaisevan tärkeää: ominaisuuksien tulisi kannustaa toistettaviin ja skaalautuviin toimintoihin, joista on käyttäjille hyötyä.
- Monia ominaisuuksia julkaistaan vain siksi, että ne saadaan toimitettua, pohtimatta, ratkaisevatko ne todella käyttäjien ongelmia tai tuovatko ne lisäarvoa.
- Lisäksi on huomioitava eettisesti, miten uudet ominaisuudet vaikuttavat käyttäjien elämään ja työnkulkuihin.
- Tuotepäälliköt, joilla ei ole merkittävää vaikutusvaltaa, voivat silti edistää muutosta omissa tiimeissään, vaikka he eivät pystyisikään muuttamaan koko organisaatiota.
- Aiemmassa tehtävässään Paweł johti hanketta, joka irtautui jäykästä turvallisesta ketterästä viitekehyksestä (jonka hän näkee vesiputousmallin kaltaisena) tuomalla esiin nykyisen lähestymistavan ongelmat.
- He ehdottivat kokeiluja ja työskentelivät ydinryhmän sekä yhteistyökumppaneiden kanssa ketterämpää menetelmää käyttäen, mikä onnistui heidän hankkeessaan.
- Vaikka koko organisaatiota ei muutettu, lähestymistapa toimi hyvin heidän hankkeessaan.
- Andrea tunnustaa Pawełin mainitseman organisaation sisäisen muutoksen edistämiseen liittyvän kovan työn.
- Hän ihailee muutosten toteuttamiseen vaadittavaa ponnistelua ja niiden henkistä kuormitusta, joka voi vaikuttaa ihmisen hyvinvointiin ja mielenterveyteen.
- Haasteista huolimatta Andrea uskoo, että onnistunut muutos tarjoaa merkittäviä oppimismahdollisuuksia, kun se on saavutettu.
- Kysymys- ja vastausosio [28:28]
- Ominaisuustehtaasta jatkuvaan arvonluontiin [28:36]
- Siirtyminen ominaisuustehtaasta jatkuvaan asiakasarvon luomiseen edellyttää keskittymistä asiakasarvoon tuotestrategian rinnalla.
- Andrea korostaa asiakasarvon tunnistamista, seuraamista ja siihen keskittymistä yhteistyössä keskeisten sidosryhmien, kuten myynnin, asiakasmenestyksen ja tuen, kanssa.
- Tuotteen arvonluontisuunnitelman (VCP) mallipohja auttaa tiimejä toimimaan samansuuntaisesti ja varmistaa yhteisen ymmärryksen arvosta.
- Tuotepäätöksiä ei pitäisi tehdä erillään muista; tiimien välinen yhteistyö on ratkaisevan tärkeää arvon tuottamiseksi.
- Strategisten keskustelujen ja yhteisen näkemyksen edistäminen [29:53]
- Tuotetavoitteen ympärille syntyvän yhteisen näkemyksen edistämiseksi kannattaa ensin kyseenalaistaa, onko nykyinen tavoite oikea, ja luoda yhteistyöhön perustuva prosessi.
- Työskentele analyytikon tai ulkopuolisen tahon kanssa datan ja oivallusten keräämiseksi niin, että kaikki osapuolet voivat oppia ja keskustella yhdessä.
- Käytä etäaivoriihiin työkaluja, kuten Miroa, erilaisten mittareiden ja tavoitteiden arviointiin sekä kunkin vaihtoehdon etujen ja haittojen käsittelyyn.
- Dokumentoi vaihtoehdot ja palaute keskustelujen aikana ja ota mukaan keskeiset tiimit, kuten datatieteilijät, PM:t, suunnittelijat ja insinöörit.
- Päätä prosessi lopulliseen kokoukseen, jossa tavoitteesta päätetään ja varmistetaan, että kaikilla on ollut mahdollisuus vaikuttaa ja sitoutua siihen, vaikka tämä veisi enemmän aikaa.
- Oivallusten ja ominaisuuksien välisen yhteyden katkeamisen käsittely [32:02]
- Tilanteessa oivallukset eivät ole yhteydessä toisiinsa, ja tuotepäällikkö ajaa ominaisuuksia nopeasti eteenpäin ilman asianmukaista validointia.
- Paweł ehdottaa ominaisuuksien taustalla olevan ratkaistavan ongelman selvittämistä käänteisesti sekä näiden oletusten validointia.
- Hän suosittelee varmistamaan, että ongelma vastaa organisaation laajempia tavoitteita ja strategiaa.
- Jonkun muun tiimin jäsenen kuin tuotepäällikön tulisi tutkia analytiikkadatan ja rakenteilla olevien ominaisuuksien välisiä ristiriitoja.
- Andrea on Pawełin kanssa samaa mieltä ja korostaa kahta keskeistä kysymystä: "Mitä ongelmaa yritämme ratkaista ja miksi?" sekä "Kenelle ratkaisemme sitä?"
- Hän kertoo kokemuksestaan tuotetiimissä, joka keskittyi nopeaan julkaisemiseen ilman selkeää perustelua.
- Andrea ehdottaa tiimin pyytämistä selittämään ongelman ja päätöksentekoprosessin, jotta arvon ymmärtäminen helpottuisi.
- Tuoteongelman jäsennystä käyttäen hän kannustaa tiimejä pohtimaan liiketoimintavaikutusta, asiakasarvoa ja toimintansa taustalla olevaa tarkoitusta.
- Ominaisuustehdas yrityksen eri vaiheissa [34:47]
- Aakash ehdottaa, että ominaisuustehtaita voi esiintyä missä tahansa yrityksen elinkaaren vaiheessa, jopa suurissa ja menestyvissä yrityksissä.
- Varhaisvaiheen yritykset saattavat kokea tarpeelliseksi kopioida menestyviä tuotteita, mikä johtaa ominaisuustehtaan kaltaiseen toimintaan.
- Keskeinen kysymys on, estääkö ominaisuustehdas sijoitetun pääoman tuoton saavuttamisen; PM:ien tulisi arvioida, tuottaako heidän työnsä yritykselle riittävästi arvoa.
- Ominaisuustehtaan piirteitä voi esiintyä sekä pienissä startup-yrityksissä että suurissa yrityksissä, kuten Metassa tai OpenAI:ssa.
- Liiketoiminnan ja teknisen osaamisen yhdistävän PM-taustan arvo [37:23]
- Andrea uskoo, että liiketoiminnan ja teknisen osaamisen yhdistävän taustan omaavat tuotepäälliköt ymmärtävät paremmin sijoitetun pääoman tuottoa ja myynnin vaikutusta.
- Puhtaasti tekniset PM:t saattavat keskittyä enemmän teknisiin näkökohtiin ja laiminlyödä liiketoimintaan liittyviä seikkoja, kuten sen, miten ominaisuuksia myydään tai miten ne vaikuttavat sijoitetun pääoman tuottoon.
- Keskeinen esimerkki on pohtia, miten ominaisuutta myydään ja mille asiakassegmentille (esimerkiksi yrityksille vai yksittäisille kuluttajille), minkä tekniset PM:t saattavat sivuuttaa.
- Liiketoimintaan keskittyvät PM:t yhdistävät yleensä teknisen ja myynnillisen näkökulman alusta alkaen.
- Aakash ehdottaa liiketoimintataustan hyödyntämistä keskittymällä vaikutuksiin ja kasvumalleihin.
- Liiketoimintataustaiset PM:t voivat tuoda vahvuutensa esiin esimerkiksi kirjoittamalla erinomaisia ominaisuuskuvauksia tai analysoimalla vaikutuksia.
- Tekniset PM:t voivat oppia liiketoimintataitoja ajan myötä, joten kannattaa keskittyä omiin vahvuuksiin sen sijaan, että vertailisi itseään muihin.
- PM:n rooli mahdollistaa joustavan sopeutumisen ja omien vahvuuksien hyödyntämisen, kuten Excelin käyttämisen data-analyysiin, jos se on oma vahvuus.
- Oivallusten muuttaminen työlistan tehtäviksi [40:10]
- Paweł korostaa eri lähteistä, kuten asiakashaastatteluista, sidosryhmiltä, markkinatutkimuksesta ja data-analytiikasta, saatujen oivallusten hyödyntämistä.
- Hän välttää käyttäjätarinoiden tai ominaisuuksien lisäämistä työlistalle liian aikaisin ja haluaa saattaa ensin selvitystyön päätökseen sekä testata oletukset.
- Oivallukset järjestetään erilliseen työlistaan tai työkaluun, kuten Miroon, ja yhdistetään käyttäjien tarpeisiin ennen niiden muuttamista käyttäjätarinoiksi.
- Yli 12 kuukautta vanhat työlistan kohteet arkistoidaan, jotta lista pysyy hallittavana; tärkeät kohteet voidaan palauttaa tarvittaessa.
- Ominaisuustehtaasta jatkuvaan arvonluontiin [28:36]
Tutustu vieraaseemme
Aakash Gupta on kokenut tuotejohtaja, jolla on yli 15 vuoden kokemus. Hän on toiminut muun muassa Apollon tuotepäällikkönä (tuotejohtajana), jossa hän osallistui yrityksen kasvattamiseen 1,2 miljardin dollarin arvoiseksi. Hän on myös johtanut tuotteiden kasvutoimintoja thredUPin, Affirmin ja Epic Gamesin kaltaisissa yrityksissä. Aakash on Tuotekasvu-uutiskirjeen kirjoittaja. Se on alansa suurimpia uutiskirjeitä maailmassa ja tarjoaa syvällisiä näkemyksiä tuotehallinnasta, johtamisesta ja urakehityksestä yli 160 000 tilaajalle. Hän on myös kirjoittanut teoksen ”Lopullinen opas PM-työpaikan saamiseen”, joka tarjoaa kattavia strategioita tuleville tuotepäälliköille. Aakash osallistuu aktiivisesti tuotehallinnan yhteisöön puheenvuorojen, podcastien ja verkkokurssien kautta ja jakaa laajaa tietämystään auttaakseen muita menestymään alalla.
Jos olet tuotepäällikkö (tuotejohtaja), Chief Product Officer tai mikä nimikkeesi sitten onkaan, ja olet organisaation ylin henkilö, perustehtäväsi on aina tuoda esiin kaikki organisaatiosi puutteet ja kaikki korjaamista vaativat ongelmat. Se on nimenomaan työsi.
Aakash Gupta
Paweł Huryn on Tuotekompassi-uutiskirjeen perustaja ja kirjoittaja. Uutiskirje tarjoaa toimivia näkemyksiä ja resursseja yli 105 000 tuotepäällikölle ympäri maailmaa, ja sitä arvostetaan laajasti. Pawełilla on yli 15 vuoden kokemus teknologia-alalta, mukaan lukien viisi vuotta tuotejohtajana ja yli vuosikymmenen kokemus tuotehallinnasta, joten hän on vakiinnuttanut asemansa alan johtavana asiantuntijana. Hänen osaamisalueitaan ovat tuotelöydös, strategia ja tekoälyn integrointi tuotehallintaan. Kirjoittamisen lisäksi Paweł osallistuu tuotehallinnan yhteisöön puheenvuorojen, verkkokurssien ja LinkedInin sekä YouTuben kaltaisilla alustoilla tapahtuvan aktiivisen toiminnan kautta. Hänen sitoutumisensa monimutkaisten aiheiden yksinkertaistamiseen ja käytännönläheisen ohjauksen tarjoamiseen on tehnyt hänestä luotetun mentorin sekä tuleville että kokeneille tuotepäälliköille.
Voit myös vaikuttaa moniin asioihin tiimissäsi. Älä siis vain pyydä lupaa, vaan aloita yhteistyö suunnittelijoidesi kanssa ja kutsu insinöörisi ideoimaan ratkaisuja sen sijaan, että valmistelisit kaiken etukäteen ja keskustelisit asiakkaiden kanssa yksin.
Paweł Huryn
Andrea Saez on kokenut tuotemarkkinoinnin ammattilainen, jolla on yli vuosikymmenen kokemus tuotekehityksen ja asiakasvuorovaikutuksen välisen kuilun kaventamisesta. Hän on toiminut vaikutusvaltaisissa tehtävissä startup- ja kasvuyrityksissä, kuten ProdPadissa, airfocusissa ja Trintissä, joissa hän keskittyi strategiaan, asemointiin ja tiimien väliseen yhteistyöhön. Andrea on yksi teoksen ”The Product Momentum Gap” kirjoittajista. Kirja käsittelee tuotestrategian ja asiakasarvon yhteensovittamista. Hän on myös aktiivinen puhuja ja kirjoittaja tuotehallinnan yhteisössä.
Voit olla paras CPO tai paras tuotepäällikkö (tuotejohtaja) ja yrittää tehdä kaiken oikein, mutta jos toimitusjohtajasi ja muut johtoryhmän jäsenet eivät tue sinua, et pääse etenemään.
Andrea Saez
Tämän jakson resurssit:
- Tilaa The CPO Club -uutiskirje
- Verkostoidu LinkedInissä Aakashin, Pawełin ja Andrean kanssa
- Tutustu Tuotekasvu-uutiskirjeeseen, Tuotekompassi-uutiskirjeeseen ja teokseen Tuotemomentumkuilu
Aiheeseen liittyvät artikkelit ja podcastit:
Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmiston avulla. Anna anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.
Hannah Clark: Ominaisuustehdas – substantiivi; yritys, joka julkaisee jatkuvasti tuotteita, ominaisuuksia ja parannuksia, mutta keskittyy ennen kaikkea määrään laadun sijaan. Alkuperäinen määrittelijä: John Cutler. Käytettynä lauseessa: ”Olemme julkaisseet kolme uutta ominaisuutta tällä vuosineljänneksellä, enkä tiedä, kenellekään niistä on oikeasti käyttöä. Tämä alkaa tuntua ominaisuustehtaalta.” Jos määritelmä osui hieman liian lähelle omaa tilannettasi, jatka kuuntelemista.
Tuoreessa paneelitapahtumassamme ”Johtavatko kaikki tiet ominaisuustehtaalle?” kokosimme yhteen kolme tuotejohtajaa, jotka ovat tarkastelleet tätä ilmiötä eri näkökulmista. Aakash Gupta on toiminut yksisarvisyrityksen tuotepäällikkönä ja kirjoittaa tällä hetkellä The Product Growth Newsletter -uutiskirjettä. Andrea Saez on tuotemarkkinoinnin johtaja ja The Product Momentum Gap -kirjan kirjoittaja, ja Paweł Huryn kirjoittaa The Product Compass Newsletter -uutiskirjettä.
He jakavat epämukavan totuuden tuotosten ja tulosten sekoittamisesta, käytännön viitekehyksiä strategisen fokuksen ja keskisuurten yritysten paineiden hallintaan sekä konkreettisia keinoja tiimin muuttamiseksi ominaisuuksien rakentajista tulosten aikaansaajiksi.
Yritätpä sitten kasvattaa vuosittaista toistuvaa liikevaihtoa yli sadan miljoonan tai palauttaa tiimisi innovatiivisen hengen, pidä tätä keskustelua reikäkorttinasi ulos ominaisuustehdasajattelusta. Aloitetaan.
Ai niin, keskustelemme tällaisista aiheista joka viikko, joten jos tämä kiinnostaa, mikset tilaisi uutiskirjettämme? Hyvä, aloitetaan.
Aloitamme nyt keskustelumme tarkastelemalla alustavia kyselytuloksia. Näyttää siltä, että niiden ihmisten välillä on melko tasainen jakauma, jotka pitävät organisaatioitaan ominaisuustehtaina, ja niiden, jotka eivät ole asiasta täysin varmoja. Perehdymme tähän määrittelemällä ensin termin.
Uskon, että kaikkia auttaa, kun olemme samalla sivulla siitä, mitä tarkoitamme puhuessamme ominaisuustehtaasta. Käyttämämme määritelmä on peräisin John Cutlerilta, joka tietääkseni keksi termin alun perin. Ominaisuustehdas on yritys, joka julkaisee jatkuvasti tuotteita, ominaisuuksia, parannuksia ja niin edelleen ja keskittyy ennen kaikkea määrään laadun sijaan.
Se keskittyy tuotoksiin tulosten sijaan. Tällä viittaamme tilanteeseen, jossa julkaisemme valtavan määrän ominaisuuksia, mutta ei ole aina selvää, tuottavatko ne todellista liiketoiminta-arvoa tai vetoavatko ne käyttäjiimme.
Tähän liittyy tietenkin useita ongelmia. Käsittelemme asian kolmessa osassa. Ensimmäinen osa käsittelee sitä, miksi ominaisuustehdas on niin yleinen. Sen jälkeen siirrymme toiseen osaan eli teihin, jotka johtavat pois ominaisuustehtaasta. Kolmas osa käsittelee kysymystä: olemme tehdastilassa – mitä nyt?
Aloitamme ensimmäisestä osasta. Esitän ensimmäisen kysymyksen ensin Andrealle. Kuinka hyvää tarkoittavista organisaatioista tulee ominaisuustehtaita? Miten tämä kehittyy?
Andrea Saez: Rehellisesti sanottuna ei ole olemassa yhtä ainoaa polkua. Ihmiset kysyvät minulta usein: miten estän tämän? Miten estän tämän? On useita polkuja, jotka voivat viedä siihen suuntaan.
Kaikki voi lähteä esimerkiksi siitä, että yritetään vain saada kauppoja päätökseen. Ehkä yrityksellä ei ole hyvää tuotepäällikköä, tuotepäällikköä tai tuotannosta vastaavaa varajohtajaa. Kyse voi olla myös HIPPO-ilmiöstä tai kiiltävän uuden kohteen syndroomasta. Sinne voi päätyä monella eri tavalla, mutta mielestäni taustalla oleva perustavanlaatuinen ongelma on tuot johtajan vaikutusvallan puute: hän ei pysty asettamaan strategiaa ja sanomaan, mitä teemme ja miksi teemme sen.
Lisäksi hänen on pystyttävä neuvottelemaan tilanteissa, joissa jokin ominaisuus on tietyistä syistä julkaistava, ja sen jälkeen palauttamaan tiimi takaisin strategian pariin. Todellisuudessa, vaikka haluaisinkin sanoa, ettemme koskaan toimisi näin, voimme joutua välttämään ominaisuustehdasta vain tiettyyn rajaan asti.
Jokaisen uralla ja jokaisen yrityksen matkalla tulee hetkiä, jolloin joudumme tekemään myönnytyksiä ja sanomaan: hyvä on, meidän on rakennettava tämä ominaisuus, koska tarvitsemme lisää liikevaihtoa ja rahaa. Kyse ei siis ole mielestäni mustavalkoisesta tilanteesta.
On tehtävä neuvotteluja ja myönnytyksiä, mutta tärkeintä on, että organisaatiossa on tuot johtaja, joka pystyy sanomaan: teimme tämän, ja nyt palataan strategiaamme, siihen mitä todella yritämme tehdä ja ratkaista.
Hannah Clark: Aakash, haluatko lisätä jotain? Tiedän, että jaoit kanssani aiemmin näkökulman, joka osittain inspiroi tätä keskustelua: vaikuttaa siltä, että kaikki tiet johtavat ominaisuustehtaalle. Millaisia kokemuksia sinulla on käytännössä?
Aakash Gupta: Mielestäni tapaamme sanoa, että tuolla on hienoja yrityksiä – Piilaakson Google, Netflix, Meta – ja että ne tekevät tuotekehitystä oikealla tavalla. Jos vain teet tuotekehitystä niiden tavoin, kaikki ongelmasi ratkeavat, saavutat mittarisi, liiketoimintasi menestyy ja urasi kehittyy. Sitten ihmiset seuraavat tätä neuvoa ja huomaavat nopeasti, että siinä on aukkoja.
Suurin aukko, jonka olen nähnyt, tulee esiin, kun puhun näissä yrityksissä työskenteleville tuotepäälliköille ja kysyn: mikä on suurin ominaisuus, jonka julkaisit viime neljänneksellä? He vastaavat esimerkiksi X ja Y. Sitten kysyn: mikä oli tämän ominaisuuden alkuperä?
Miten ominaisuus kehitettiin? Kuka keksi sen? Näissä suurissa teknologiayrityksissä kaikki vaikuttavat ominaisuudet päätettiin poikkeuksetta johtoryhmässä. Niistä keskusteltiin kiivaasti kuuden kuukauden ajan. Kyse ei ollut perinteisestä tuotepäällikön tekemästä löytämisestä, jossa hän keskustelee käyttäjien kanssa jatkuvasti esimerkiksi kahden viikon välein ja keksii loistavan ratkaisun, jota yksikään Googlen tai Metan johtaja ei ollut aiemmin ajatellut ja joka muuttaa yrityksen suunnan.
Sellaista ei yksinkertaisesti tapahdu. Mielestäni näissä yrityksissä tapahtuvaa siis ihannoidaan liikaa. Esimerkiksi Apple tai Snapchat ovat tästä hyviä esimerkkejä. Snapchaten toimitusjohtaja Evan Spiegel oli hiljattain useissa podcasteissa. Muutama suunnittelija ja toimitusjohtaja määräävät käytännössä kaikesta.
Se on puhdas ominaisuustehdas. Ihmiset siis todennäköisesti ihannoivat tätä liikaa, ja todellisuudessa monet tiet johtavat ominaisuustehtaan kaltaiseen ympäristöön. Ei ehkä koko ajan, kuten Andrea korosti, mutta joskus kyse voi olla myynnin, asiakasmenestyksen tai jonkin muun tahon vaatimuksesta.
Meidän kaikkien on opittava toimimaan tilanteessa, jossa olemme ominaisuustehtaassa.
Andrea Saez: Saanko olla hieman kiistanalainen, koska minua pyydettiin olemaan sitä ennen tätä keskustelua? Olen täysin samaa mieltä Aakashin kanssa, mutta yksi tärkeä asia on ymmärtää: niillä yrityksillä, joista Aakash puhui, on budjetti tehdä näitä asioita.
Ne voivat julkaista oppiakseen tai julkaista vain nähdäkseen, mitä tapahtuu, koska ne pystyvät ottamaan riskin takaisin. Useimmilla yrityksillä ei ole siihen varaa. Kun ne yrittävät toimia kuten Google tai Apple ja sanovat vain ”julkaise se”, kyse on riskialttiista ajattelusta. Facebookin ”liiku nopeasti ja riko asioita” -ajatus ei välttämättä sovi muille. Useimmat ihmiset eivät työskentele suurissa teknologiayrityksissä, ja jos työskentelevät, he ovat Aakashin kuvaamassa tilanteessa, jossa siihen on varaa. Minulla ei ole varaa siihen, joten minun on toimittava hieman älykkäämmin.
Hannah Clark: Nyt meillä on näkökulma siihen, miten nämä tilanteet voivat kehittyä ja kuka voi selvitä niistä.
Jos ajattelemme asiaa hyvästä huonoon ulottuvana jatkumona, onko ominaisuustehdas itsessään huono asia, vai voiko se joskus toimia liiketoimintamallista riippuen? Onko olemassa realistista ja toimivaa vaihtoehtoa?
Paweł Huryn: En täysin hyväksy ajatusta siitä, että meidän pitäisi aina tehdä myönnytyksiä puhuessamme sidosryhmille ominaisuuksista, toteuttaessamme ominaisuuksia tai arvioidessamme käyttäjien ominaisuuspyyntöjä. Ensinnäkin jotkin ongelmat ovat itsestään selviä. Jos sidosryhmä esimerkiksi kertoo tarvitsevansa Stripe-integraation, tarvitsemme Stripe-integraation.
Voimme tietenkin yrittää palauttaa asian rahoitusongelmaksi, mutta joissakin tapauksissa ongelma-alueen löytäminen ja tutkiminen ei ole välttämätöntä. Sidosryhmillä, kuten johtajilla, myynnillä tai asiakasmenestyksellä, voi myös olla näkemyksiä, joita käyttäjien kanssa keskusteleva tuotepäällikkö ei huomaa.
En siis halua sivuuttaa näitä näkemyksiä kokonaan. Olen nähnyt monia tuotepäälliköitä, jotka tulevat uuteen organisaatioon ja alkavat puhua käyttäjille. Organisaatiossa ei ollut aiempaa tietoa, mutta monet sidosryhmät olivat viettäneet satoja tunteja asiakkaiden kanssa joka kuukausi. Heidän tietojensa sivuuttaminen olisi mielestäni hukkaa.
Loppujen lopuksi yritysten on myös ansaittava rahaa. Joillekin yrityksille, jotka toimivat esimerkiksi asiakas-toimittaja-mallissa, asiakkaiden pyytämien asioiden tekeminen voi olla kannattava tapa ansaita rahaa, vaikka tuotepäälliköt tai tuotetiimit eivät siitä pitäisikään. Tällöin voimme vaihtaa yritystä sen sijaan, että yrittäisimme muuttaa sitä, koska kyse on sen liiketoimintamallista.
Hannah Clark: Se on hyvä huomio. Jos malli toimii ja pitää liiketoiminnan pystyssä, asiat voivat joskus vain mennä niin.
Palaamme heti Andrean puoleen ja siirrymme toiseen osaan: ominaisuustehtaasta pois johtaviin teihin. Jätetään siis moraalinen kysymys – onko tämä hyvää vai huonoa – sivuun ja keskustellaan siitä, miten arvioimme, onko organisaatio ominaisuustehdas. Mistä tiedämme, investoimmeko liikaa lyhyen aikavälin asioihin ja liian vähän pitkän aikavälin arvoon? Missä tasapaino on?
Andrea Saez: Ensimmäiset merkit liittyvät mielestäni siihen, saatko paljon kielteistä palautetta, näetkö asiakaspoistuman kasvavan tai pitenevätkö myyntisyklit. Nämä ovat merkkejä siitä, että tuote–markkina-sopivuus saattaa heikentyä. Silloin yleensä aletaan sanoa: julkaistaan tämä vain tai rakennetaan tämä vain, jotta tietyt asiakkaat saadaan pidettyä tai kaupat päätettyä.
Silloin asiat alkavat karata käsistä. Saatat huomata, että tuotteessa on paljon ominaisuuksia, mutta liittyvätkö ne toisiinsa? Onko niissä järkeä? Onko ne tarkoitettu yleisöllesi? Onko käyttökokemus järkevä? Pystyykö käyttäjä helposti navigoimaan käyttöliittymässä? Yleensä huomaat, että tuote–markkina-sopivuus alkaa heikentyä eikä ole enää yhtä vahva kuin aiemmin.
Hannah Clark: Puhutaan hieman varhaisesta puuttumisesta. Jos alamme harhautua, millaisia tarkistuksia ja tasapainottavia käytäntöjä voisimme ottaa käyttöön, jotta pysymme keskittyneinä arvon tuottamiseen ja uskollisina yrityksemme visiolle?
Paweł, haluatko ottaa tämän?
Paweł Huryn: Aloittaisin siitä, että määrittelemme koko organisaation kannalta tärkeät asiat ja strategian. Jos tiimit eivät ole yhtä mieltä siitä, miten luomme arvoa, mitä asiakkaita palvelemme ja mitä ongelmia haluamme ratkaista, eri tiimien voi olla erittäin vaikeaa tuottaa arvoa.
Ensimmäinen asia on siis strateginen linjautuminen ja tekemämme valinnat, jotta kaikki ovat tietoisia strategisesta kontekstista. Netflix kutsuu tätä ilmaisulla ”konteksti, ei kontrolli”. Toinen asia on tiimien linjaaminen tavoitteiden ympärille, jotta kaikki ymmärtävät organisaation tärkeimmät tavoitteet esimerkiksi vuosineljänneksen tai vuoden aikana.
Tiimit voivat linjata omat tai osastonsa tavoitteet organisaation tärkeimpien painopisteiden kanssa. Tämän jälkeen tarvitaan valtuuttamista, johon voi liittyä valmennusta, koska kaikki tuotetiimit eivät välttämättä osaa tehdä jatkuvaa tuotelöytämistä.
Yleisesti haluamme oletusarvoisesti – poikkeuksia toki on – antaa tiimeille merkityksellisiä ongelmia ratkaistaviksi ja selkeitä tavoiteltuja tuloksia. Näin ne voivat löytää keinot ratkaista ongelmat, luoda arvoa asiakkaille ja lopulta myös liiketoiminnalle.
Siinä se. Aloitetaan strategiasta ja päädytään tiimien valtuuttamiseen, jotta ne voivat käynnistää löytämisprosessin.
Hannah Clark: Tähän liittyy mielestäni eräs asia. Keskustelin hiljattain Duolingon tuotannosta vastaavan johtajan Cem Kansun kanssa visiosta ja arvoista.
Duolingolla on niin sanottuja pyhiä lehmiä: asioita, joihin ei kosketa tai joita ei muuteta, koska ne ovat keskeisiä yrityksen identiteetille. Ne toimivat kompassina päätöksenteossa ja auttavat päättämään, mistä kieltäydytään.
Se on mielestäni kiinnostava lähestymistapa.
Paweł Huryn: Juuri siksi ne ovat erittäin tärkeitä. Kyse ei ole vain asioista, joihin haluamme keskittyä, vaan myös selkeästi määritellyistä asioista, joita emme tee, asiakkaista, joita emme palvele, ja strategioista, joita emme toteuta. Näin kaikki voivat välttää niitä.
Hannah Clark: Ennen kuin siirryn kolmanteen osaan, haluaako joku paneelisteista lisätä jotain tarkistuksista tai varhaisesta puuttumisesta, jotta pysymme poissa ominaisuustehdasajattelusta?
Aakash Gupta: Ominaisuustehdas on kielteinen ilmaus. Kukaan ei halua olla ominaisuustehtaassa. Jos kuitenkin puramme ominaisuustehdaan osiin ja kysymme, mitkä osat ovat tuhoisimpia, tärkein asia on se, ettemme keskity liiketoiminnan oikeaan osaan.
Yrityksessä tärkeintä on saada johtoryhmä keskittymään niihin osiin, mittareihin ja käyttäjäongelmiin, joilla todella on merkitystä. Se on yleensä kaikkein vaikutusvaltaisin alue. Tätä varten on tuotava näkemyksiä, jotka rakentavat uskottavuutta.
Ajattelen yleensä kahdenlaisia näkemyksiä. Ensinnäkin käyttäjänäkemyksiä, joita tukevat esimerkiksi istuntojen tallenteet, käyttäjäanalytiikka, datakeskustelut tai mieluiten asiakkaiden kanssa käytyjen keskustelujen nauhoitteet.
Toiseksi todellisia datanäkemyksiä, jotka liittyvät yleensä kasvumalliin tai mahdollisuuden kokoon. Esimerkiksi: tiesitkö, että 16 prosenttia asiakkaistamme ei ole tehnyt asiaa Y? Jos saamme puolet heistä tekemään sen, se voi tuottaa X miljoonaa dollaria lisää liikevaihtoa. Kun tuot johtajille tällaisia näkemyksiä, pystyt vähitellen ohjaamaan keskustelua oikeisiin mittareihin ja ongelmiin.
Tämä on ensimmäinen kohta, josta Paweł puhui strategian yhteydessä. Toinen kohta on antaa kentällä työskenteleville tiimeille – suunnittelijoille ja tuotepäälliköille – mahdollisuus muuttaa suuntaa prototypoinnin, mallien testaamisen ja käyttäjäpalautteen perusteella.
Tätä varten toimivat tarkistuspisteet ja tuotearviointikokoukset, joissa johtajilla on edelleen mahdollisuus vaikuttaa. Johtajille ei pidä näyttää suunnitelmavaiheessa suunnitelmaa, palata kolmen kuukauden kuluttua tulosten kanssa ja kertoa, ettei se toiminut. He saattavat vastata, ettei heidän suunnitelmaansa toteutettu.
Johtajat pitää ottaa mukaan useiden tuotearviointien kautta. Voit kertoa, että heidän suunnitelmaansa testattiin käyttäjillä ja sitä parannettiin tiettyjen syiden vuoksi. Nämä kaksi asiaa – korkean tason strategia ja käytännön tarkistuspisteet – ovat mielestäni tärkeimmät vaikutuskeinot.
Hannah Clark: Tämä oli erittäin hyödyllinen näkemys. Haluaisiko joku vastata siihen?
Andrea Saez: En sanoisi mitään kovin erilaista. Olen täysin samaa mieltä Aakashin ja Pawelin kanssa. Lisäisin vain, että kun rakennatte linjausta, varmistakaa, että linjaus todella on olemassa.
Monet tiimit epäonnistuvat siinä, että ne sanovat kyllä ja viikon kuluttua kaikki juoksevat eri suuntiin. Johdon on oltava linjassa. Sen täytyy alkaa huipulta. Kaikkien on oltava yhtä mieltä siitä, mitä tehdään, miksi tehdään, miten tehdään ja kenelle tehdään.
Kysymys siitä, kenelle tehdään, aiheuttaa usein eniten ristiriitoja, koska kaikki yrittävät myydä eri ihmisille. Kun yritetään palvella erilaisia yleisöjä, mukaan alkaa hiipiä ominaisuuksia, jotka eivät ehkä sovi kokonaisuuteen.
Hannah Clark: Lyhytjänteisestä ominaisuuksien kehittämisestä kysytään, voiko yritys joskus julkaista ominaisuuksia, jotka eivät liity suoraan vision toteuttamiseen, mutta aikoo myöhemmin palata hiomaan niitä. Kun yritys kuitenkin joutuu ominaisuustehtaan kierteeseen, sieltä on vaikea päästä pois, eikä se koskaan palaa parantamaan alkuperäisiä, keskeneräisiä ominaisuuksia. Onko kenelläkään ajatuksia?
Paweł Huryn: Jos kyse on siitä, että julkaistaan ominaisuuksia, jotka eivät ole ihanteellisia tai täydellisiä, kokemukseni mukaan juuri niin pitäisi tehdä.
Ominaisuutta ei tarvitse julkaista kaikkine mahdollisine yksityiskohtineen ja reunatapauksineen. On parempi tehdä jotain, joka ratkaisee ongelman ehkä 70 tai 80 prosentille käyttäjistä yleisimmissä käyttötapauksissa, ja kerätä palautetta.
Aina se ei ole mahdollista, mutta useimmissa organisaatioissa, joissa olen työskennellyt, aloitimme yksinkertaisesti. Vaikka meillä olisi ollut neljän tai viiden kuukauden tavoitesuunnitelma, haimme nopeasti palautetta käyttäjiltä. Usein palautteen jälkeen paransimme myös alkuperäisiä oletuksiamme.
Vaikka testaisit suunnitelmasi, tekisit käytettävyystestejä ja haastattelisit asiakkaita, todelliset tuotantotulokset voivat olla erilaisia, kun asiakkaat käyttävät oikeaa dataa. Kannatan siis täysin sellaisten ominaisuuksien julkaisemista, jotka eivät ole täydellisiä.
Hannah Clark: Andrea, miten tämä sopii strategiaan? Mainitsit, ettei organisaatiollasi välttämättä ole varaa julkaista ominaisuuksia samalla tahdilla ja että toimien on oltava strategisempia. Näetkö asian eri tavalla?
Andrea Saez: Olen samaa mieltä Pawelin kanssa. Ominaisuuksia pitää julkaista tarkoituksella. Kaiken ei tarvitse olla täydellistä. En halua tehdä oletuksia, mutta Todd käytti ilmausta ”puolivalmis”, ja olen nähnyt tilanteita, joissa julkaistaan jotain ja sanotaan, että palaamme parantamaan sitä myöhemmin. Sitten siirrytään seuraaviin uusiin asioihin, eikä tiimi palaa tekemään parannuksia.
Se on ominaisuusloukku: julkaistaan vain uutta eikä palata parantamaan perusasioita, kuten käytettävyyttä. Oletamme, että käyttäjät kyllä ymmärtävät, koska ominaisuus on olemassa.
Aakash Gupta: Kommentoijamme ovat oikeassa. Brent ja Todd viittaavat ilmiöön, joka on yksi syy siihen, miksi ominaisuustehdas on niin haitallinen: julkaistaan puolivalmiita ominaisuuksia, niitä ei koskaan korjata tai päivitetä, ja siirrytään jatkuvasti seuraavaan kiiltävään kohteeseen.
Kun kysytään, miten tästä päästään pois, on tuotava käyttäjänäkemyksiä. Voit kertoa, että tarkastelimme viime viikolla sataa istuntotallennetta ja vain kolme ihmistä napsautti ominaisuutta. Tai että niiden käyttäjien 30 päivän säilyvyys, jotka kokeilivat ominaisuutta, on seitsemän prosenttia.
Näiden tietojen avulla johtajat voivat joko sallia ominaisuuden parantamisen tai päättää sen poistamisesta. Jos käyttöaste on seitsemän prosenttia, ensin voidaan yrittää saada ihmiset näkemään ja kokeilemaan ominaisuutta. Jos säilyvyydessä on ongelma, se pitää korjata.
Usein on kuitenkin järkevintä poistaa ominaisuuksia. Markkinoilla on liikaa ominaisuuksia, jotka vaikeuttavat käyttäjän ydintehtävän suorittamista. Tämä on erityisen haitallista B2B-yrityksissä, joissa yritämme muuttua alustayrityksiksi. Kun vuosittainen toistuva liikevaihto saavuttaa kymmenen miljoonaa, ajattelemme tarvitsevamme toisen tuotteen.
Todellisuudessa ydintuotteeseen keskittyminen tuottaa usein paljon suuremman vaikutuksen.
Andrea Saez: Pendo teki tutkimuksen, jonka mukaan 80 prosenttia ominaisuuksista jää käyttämättä. Se on valtava määrä.
Hannah Clark: Se on hurjaa.
Tämä johdattaa hyvin viimeiseen osaamme: olemme tehdastilassa – mitä nyt? Monet ovat todennäköisesti tulleet kuuntelemaan, koska työskentelevät jo ominaisuustehtaassa tai pelkäävät tilanteen pahenevan.
Oletetaan siis, että mallin muuttaminen lyhyellä aikavälillä on mahdotonta tai erittäin vaikeaa yrityksen vakiintuneen infrastruktuurin vuoksi. Millaisia johtamisen näkökulmasta tehtäviä asioita voimme tehdä päästäksemme pois ominaisuustehdasajattelusta ja keskittyäksemme enemmän arvoon?
Aakash Gupta: Jos olet johtaja, vastuu on sinulla. Jos olet tuotannosta vastaava varajohtaja, tuotannosta vastaava johtaja tai vastaavassa asemassa, sinun kuuluu nostaa jatkuvasti esiin organisaation puutteet ja ratkaistavat ongelmat.
Työsi ei ole kehuskella sillä, kuinka upeita olette ja kuinka paljon hienoja asioita julkaistaan. Olet paikalla ratkaisemassa yrityksen ongelmia. Ota esiin tärkeimmät ongelmat ja ominaisuustehdas yhtenä niistä.
Voit kysyä: mikä oli strategiamme viime vuonna? Mitä ominaisuuksia sitouduimme rakentamaan ja miten ne suoriutuivat? Kuinka moni onnistui? Jos 75 prosenttia ei onnistunut, haluammeko tehdä saman tänä vuonna? Jos emme, miten alamme muuttaa tilannetta?
Älä sano, että jokin ajattelija sanoo tuotepäälliköiden valtuuttamisen olevan tarpeen. Puhu sidosryhmien kieltä ja tuo heidän käyttöönsä oppimasi asiat. Se on hyvän tuotannosta vastaavan varajohtajan tehtävä.
Joskus perustajat ja toimitusjohtajat ovat kuitenkin vaikeita yhteistyökumppaneita. Voit olla kaikkien aikojen paras tuotannosta vastaava johtaja, mutta jos toimitusjohtaja pakottaa asiat läpi, sinun on ajateltava uraasi ja ehkä siirryttävä muualle.
Andrea Saez: Olin sanomassa aivan samaa. Voit olla paras tuotannosta vastaava johtaja tai tuotannosta vastaava varajohtaja ja tehdä kaiken oikein, mutta ilman toimitusjohtajan ja muun johtoryhmän tukea et pääse mihinkään.
Johtoryhmän täytyy olla aidosti linjassa, koska sen jälkeen kaikki on helpompaa. Olen työskennellyt tuotannosta vastaavien johtajien kanssa, joilla ei ollut lainkaan vaikutusvaltaa ja joiden sijaan myynti ohjasi kehitystä.
Lisäksi on tärkeää linjata ja ymmärtää mitattava käyttäytyminen. Monet rakennetut ominaisuudet eivät keskity toistettaviin ja skaalautuviin käyttäytymismalleihin eli siihen, mitä ihmiset tekevät päivittäin, koska se on heille välttämätöntä.
Ominaisuuksia julkaistaan joskus vain julkaisemisen vuoksi. Mutta tuottavatko ne asiakkaalle arvoa? Ratkaisevatko ne ongelman vai tekevätkö ne käyttäjän elämästä vaikeampaa? Tässä on myös eettinen näkökulma: miten ominaisuus vaikuttaa käyttäjän elämään, käyttäytymiseen ja työnkulkuun?
Paweł Huryn: Olen samaa mieltä kaikesta tähän asti sanotusta.
Haluan lisätä, että myös sellainen tuotepäällikkö tai tuotetiimi, jolla ei ole organisaatiossa paljon vaikutusvaltaa, voi usein viedä asioita oikeaan suuntaan. Koko organisaatiota ei tietenkään voi muuttaa, mutta esimerkiksi aiemmassa työssäni työskentelin BC:ssä, joka toimii resurssikeskuksena yli 30 tanskalaiselle pankille.
Aloitteeni oli ainoa, joka pääsi pois SAFe-kehyksestä, joka oli mielestäni pitkän aikavälin suunnitteluineen kuin vesiputousmalli. Analysoimme aiemmat aloitteet, nostimme ongelmat esiin ja mittasimme niitä. Osoitimme, että jos jatkamme samalla tavalla, yksi monimutkaisimmista aloitteista epäonnistuu kuten aiemmatkin.
Ehdotimme kokeilua: ydintiimi ja neljä muuta kanssamme työskentelevää tiimiä alkaisivat työskennellä ketterästi ilman raskasta kehystä. Emme muuttaneet koko organisaatiota, mutta omassa aloitteessamme se toimi hyvin.
Hannah Clark: Arvostan sitä, että toit esiin vähemmän vaikutusvaltaa omaavien näkökulman. Monet eivät ole tuotannosta vastaavia varajohtajia, mutta haluavat silti tehdä työstään mahdollisimman vaikuttavaa.
Paweł Huryn: Voit vaikuttaa moniin tiimisi sisäisiin asioihin. Älä siis aina kysy lupaa, vaan ala tehdä yhteistyötä suunnittelijoiden kanssa. Kutsu insinöörit mukaan ratkaisujen ideointiin sen sijaan, että valmistelisit kaiken itse ja puhuisit asiakkaiden kanssa yksin.
Andrea Saez: Haluan lisätä, että Paweł toi esiin, kuinka paljon kovaa työtä tämä vaatii.
Kun kuuntelin, miten teit tuon, ajattelin: miten hän onnistui? Se vaatii paljon työtä. Useimmiten urani aikana olen Aakashin kanssa ajatellut, etten jaksa käyttää tähän aikaa vaan etsin uuden työn. Tällaisen muutoksen tekeminen on todella vaikeaa.
Kunnioitus kaikille, jotka pystyvät siihen tai käyvät sitä parhaillaan läpi. Se kuluttaa hyvinvointia, mielenterveyttä ja arkea. Jos kuitenkin pääset toiselle puolelle, opit paljon.
Hannah Clark: Se on varmasti hieno kokemus vietäväksi seuraavaan tehtävään, jäätpä yritykseen tai et.
Jos haluat seurata tämän päivän puhujia, jokainen heistä on erinomainen ajatusjohtaja. Heiltä löytyy paljon hyvää sisältöä. Andrean kirja The Product Momentum Gap on saatavilla Amazonissa. Aakashin uutiskirje on The Product Growth Newsletter, joten tilaa se. Se on erinomainen resurssi.
Pawelin uutiskirjeen nimi on Product Compass. Aakash ja Paweł ovat tehneet yhteistyötä joissakin podcasteissa, ja Aakash on aktiivinen myös omassa podcastissaan. Tilaa paneelistiemme sisältö, sillä he julkaisevat jatkuvasti hyvää materiaalia.
Siirrytään kysymys- ja vastausosioon. Saimme yleisöltä hienoja kysymyksiä. Ensimmäinen tulee Aquedalta. Toivottavasti lausuin nimen oikein.
Miten pääsemme ominaisuustehtaasta jatkuvaan käyttäjä- ja asiakasarvon luomiseen, jolla on myönteinen liiketoimintavaikutus? Olemme sivunneet tätä, mutta ehkä voitte lisätä jotain.
Hän sanoo, että asiakasarvon osa yhtälöstä on peittynyt nopean voiton tavoittelun alle. Andrea, voisitko kertoa lyhyesti, mitä käsittelet kirjassasi?
Andrea Saez: Juuri sitä. Kyse on tuotey strategian ja asiakasarvon yhdistämisestä. Puhumme paljon asiakasarvosta, sen tunnistamisesta, seuraamisesta ja siihen keskittymisestä sekä tiimin kokoamisesta yhteen.
Meillä on pieni mallipohja nimeltä Product VCP eli tuotteen arvonluontisuunnitelma. Olennaista on, ettei tuotetiimi tee päätöksiä eristyksissä. On kuunneltava myyntiä, asiakasmenestystä ja tukea sekä tuotava kaikki tärkeät sidosryhmät työpajaan yhteistyöhön.
Näin ymmärretään, mitä arvo tarkoittaa ja miten sitä voidaan tuottaa.
Hannah Clark: Jos haluat nähdä tästä esimerkin, keskustelimme samasta aiheesta podcastissa noin vuosi sitten. Product Manager -podcastin jakso käsitteli sitä, kuinka tuot johtajat estävät tahattomasti liiketoiminnan kasvua.
Seuraava kysymys tulee Parkerilta. Mitä työkaluja tai menetelmiä käytätte strategisten keskustelujen ja yhteisen tuotetavoitteen ympärille rakentuvan linjauksen edistämiseen? Mikä on ollut tehokkainta? Nyt mennään hieman käytännöllisemmälle tasolle. Haluaisiko joku vastata?
Aakash Gupta: Jos yritämme luoda linjausta tietystä tavoitteesta, ei kannata aloittaa sanomalla, että tässä on oikea vastaus. Parempi tapa on sanoa ihmisille, joita ei ole vielä saatu mukaan: emme ehkä ole valinneet oikeaa tavoitetta. Käydäänkö yhdessä prosessi, jossa selvitämme oikean tavoitteen?
Prosessin pitää olla yhteistyöhön perustuva. Työskentelen mielelläni analyytikon tai muun henkilön kanssa, jota molemmat osapuolet arvostavat. Voimme pyytää häntä laatimaan tutkimusraportin ja esitellä sen yhdessä, minkä jälkeen kysymme kysymyksiä.
Tällöin opit yhdessä niiden ihmisten kanssa, joiden kanssa olet eri mieltä. Sen jälkeen voidaan järjestää ideointi, esimerkiksi Miroa käyttäen. Listataan mahdolliset mittarit ja tavoitteet sekä niiden hyvät ja huonot puolet.
Tuotepäällikkönä voit kirjata vaihtoehdot ja niiden edut ja haitat. Tämän jälkeen palataan jälleen ulkopuolisen asiantuntijan luo, otetaan mukaan data-analytiikan tiimi sekä ne tuotepäälliköt, suunnittelijat ja insinöörit, jotka ovat rakentaneet tuotetta viimeiset kuusi kuukautta.
Lopuksi käydään keskustelu ilman valmista vastausta ja tehdään päätös yhdessä. Prosessi vie enemmän aikaa, mutta sitoutuminen on yleensä vahvempaa.
Hannah Clark: Jätän aina sinulle tehtäväksi antaa selkeän ja konkreettisen prosessin, joten arvostan tätä.
Siirrytään Mikaylan kysymykseen. Liiketoiminta ja UX-tiimi ovat pyytäneet tuotteen uudistamista. Haluamme ymmärtää kipupisteet, saada näkemyksiä ja ymmärtää käyttäjäpolut. Tuote on tähän asti ollut ominaisuustehdas, ja käyttöliittymä on hajautunut, koska käytämme monia järjestelmiä sen kokoamiseen. Tuotepäällikkö kuitenkin painostaa tekemään jotain nopeasti, koska ”tiedämme jo asiat”, mutta selkeää suuntaa ei ole. Miten tästä pääsee pois?
Paweł Huryn: Tässä tilanteessa tuotepäällikkö painostaa ominaisuuksien julkaisemiseen ilman asianmukaista validointia.
Yrittäisin palauttaa keskustelun taaksepäin ja kysyä, minkä ongelman ominaisuus ratkaisee. Sen jälkeen tutkisin ja validoisin ongelman sekä mahdolliset ratkaisut. Haluaisin myös tietää, liittyykö ongelma organisaation ja yrityksen strategiaan sekä tällä hetkellä tärkeisiin tavoitteisiin.
Joku muu tiimistä voisi yrittää selvittää taustaoletukset ja etsiä ristiriitoja analytiikan, suppiloiden, kohorttianalyysien ja rakennettavien ominaisuuksien välillä. Ominaisuuksien taustalla täytyy olla oletuksia, jotka pitää validoida.
Andrea Saez: Olen samaa mieltä Pawelin kanssa. On kaksi taikakysymystä: minkä ongelman yritämme ratkaista ja miksi? Lisäksi pitää kysyä, kenelle ratkaisu tehdään.
Olen ollut vastaavassa tilanteessa, jossa tuotetiimi halusi vain julkaista, koska he uskoivat tietävänsä mitä tekivät. Sanoin, etten halua häiritä, mutta voisitteko selittää ongelman ja päätöksentekoprosessin, jotta ymmärrän sen? Tuotemarkkinoijana minun on myytävä ratkaisu, joten minun pitää ymmärtää sen arvo.
Voit käydä läpi pienen tuoteongelman kuvauksen: minkä ongelman yritämme ratkaista, miksi, kenelle, mikä on liiketoimintavaikutus ja mitä asiakasarvoa toimitamme. Tämä ohjaa keskustelua ja auttaa tiimiä pohtimaan, miksi se tekee asioita.
Hannah Clark: Se on hyvä ehdotus. Meillä on vielä kysymyksiä, mutta ajan vuoksi siirrymme eteenpäin. Kiitos Mikaylalle.
Seuraava kysymys tulee Br entiltä. Pitäisikö yrityksen tai tuotteen muuttua kypsyessään vähemmän ominaisuustehtaaksi? Voiko tämä kehitys olla merkki tuotetiimien väärästä käyttötavasta?
Andrea Saez: Kuka haluaa vastata? Hannah, haluan kuulla sinun näkemyksesi.
Hannah Clark: Olen tässä hieman ulkopuolinen, mutta minusta yrityksen pitäisi olla vähiten ominaisuustehdas alussa, kun sillä on hyvin tarkka tavoite ja tietty käyttäjäongelma ratkaistavanaan.
Vaikuttaa siltä, että ominaisuustehdas hiipii mukaan, kun liiketoiminnan säilyttämiseksi tehdään myönnytyksiä. Siksi kasvava yritys saattaa törmätä siihen useammin. En kuitenkaan ole itse joutunut käsittelemään näitä huolia, joten korjatkaa, jos olen väärässä.
Aakash Gupta: Prosenttiosuudet ovat luultavasti melko samanlaisia kaikissa elinkaaren vaiheissa. Alussa saatetaan ajatella, että tarvitsee vain kopioida toinen tuote. Silloin kaikki vaikuttaa selkeältä, mutta kyse on silti ominaisuustehtaasta.
Ominaisuustehdas voi syntyä missä tahansa vaiheessa. Olennaista on kysyä, mitkä ominaisuustehdasajattelun osat vahingoittavat meitä. Enkö pysty tuottamaan palkkani verran sijoitetun pääoman tuottoa? Jos minulle maksetaan 150 000 dollaria, tuotanko yritykselle 150 000 dollaria voittoa? Jos en, ominaisuustehdas on muuttunut henkilökohtaiseksi ongelmakseni, ja minun on alettava korjata asioita yksi kerrallaan.
Hyviä yrityksiä löytyy kaikista vaiheista. Jotkin suuret yritykset ovat onnistuneet valtuuttamaan tuotepäälliköt, mutta myös A- ja C-sarjan yrityksissä voi olla hyviä käytäntöjä. Jokaisessa vaiheessa on luultavasti samankaltainen jakauma, ja yli puolet yrityksistä toimii ainakin osittain ominaisuustehtaan tavoin.
Hannah Clark: Siirrytään Sahin kysymykseen. Millaisia lisäarvoa tuottavia hyötyjä tuotepäällikkö, jolla on liiketoiminnan ja teknologian yhdistävä tausta, tuo verrattuna puhtaasti teknisen taustan omaavaan tuotepäällikköön, kun puhutaan ominaisuuksista ja suunnittelusta?
Andrea Saez: Uskon, että yhteys on olemassa, vaikka voin olla väärässäkin. Hyvin puolueellisen kokemukseni mukaan puhtaasti tekniset tuotepäälliköt jäävät joskus vaille liiketoimintafokusta. Loppujen lopuksi rakennamme asioita, jotka pitää myydä.
En tarkoita, että kaikkien pitäisi keskittyä sataprosenttisesti sijoitetun pääoman tuottoon, mutta on tärkeää ymmärtää, että rakennamme jotain myytävää. Miten päätöksemme vaikuttavat liiketoimintaan ja tuottoon?
Liiketoimintataustaiset tuotepäälliköt ymmärtävät tämän alusta asti. Tekninen tuotepäällikkö voi keskittyä tekniseen puoleen eikä välttämättä mieti sijoitetun pääoman tuottoa.
Hyvä esimerkki on tilanne, jossa joku kysyy uuden ominaisuuden rakentamisesta ja minä kysyn ensimmäisenä: miten aiomme myydä tämän? Kenelle myymme sen? Jos yritys toimii B2B-markkinassa ja sillä on yksilö- ja yrityspaketit, onko ominaisuus suunniteltu ohjaamaan asiakasta tällä polulla?
Yritysasiakkaalla ei ole samaa ongelmaa kuin yksittäisellä käyttäjällä tai siemenvaiheen startupilla. Kaikki eivät käy tätä ajatusprosessia läpi, jos heiltä puuttuu liiketoimintatausta.
Aakash Gupta: Hän yrittää todennäköisesti kysyä, mitä hyötyä liiketoiminnan ja teknologian yhdistävästä taustasta on verrattuna puhtaasti tekniseen taustaan. Tämän päivän keskustelussa olet puhunut paljon työsi vaikutuksesta.
Jos sinulla on liiketoimintatausta, keskity sellaisiin tuotepäällikön taitoihin. Rakenna tiimillesi kasvumalli, arvioi ominaisuuksien vaikutus ja kirjoita hyviä ominaisuuskuvauksia ja tulosraportteja. Hyödynnä vahvuuksiasi äläkä murehdi liikaa muiden tekemisistä.
Teknisten tuotepäälliköiden pitää oppia liiketoimintataidot. Ne eivät ole kovin vaikeita, joten useimmat oppivat ne nopeasti. Keskity siihen, miten hyödynnät omia vahvuuksiasi. Jos olet hyvä Excelissä, tee enemmän Exceliin liittyvää työtä tuotepäällikkönä. Tuotepäällikön roolin hienous on siinä, että voit tehdä siitä omanlaisesi.
Andrea Saez: Olen täysin samaa mieltä.
Hannah Clark: Todd sanoi, että Paweł mainitsi aiemmin haluavansa säilyttää kaikki näkemykset. Missä vaiheessa muutatte näkemykset työjonon tehtäviksi? Työjonomme tuntuu ominaisuustehtaan tuotantolattialta. Suosittelemme yli 12 kuukautta vanhojen työjonon tehtävien arkistointia. Paweł, vastaisitko tähän?
Paweł Huryn: En ole varma, että puhuin kaikkien näkemysten säilyttämisestä. Saatoin tarkoittaa eri lähteistä tulevien näkemysten hyödyntämistä: asiakashaastatteluista, sidosryhmistä, markkinatutkimuksesta, analytiikasta, kyselyistä ja niin edelleen.
Olen aina välttänyt käyttäjätarinoiden tai ominaisuuksien lisäämistä kehittäjien työjonoon liian aikaisin. Haluaisin ensin viimeistellä löytämisvaiheen, jakaa suunnitelmat, testata keskeiset oletukset ja jakaa tulokset organisaatiolle.
Vasta kun luottamuksemme on riittävä, jaamme kokonaisuuden käyttäjätarinoiksi tai muiksi tehtäviksi yhdessä tiimin kanssa. Käytännössä voi olla kaksi työjonoa. Niiden ei tarvitse olla samassa työkalussa: toinen voi olla Miro tai muu visuaalinen työkalu, johon kerätään näkemyksiä ja yhdistetään ne käyttäjien tarpeisiin.
Työjonon siivoamisesta sanoisin, että arkistoi tai piilota kaikki liian pitkään työjonossa olleet kohteet. Jos työjonossa on tuhansia kohteita, sitä ei voi hallita. Kokemukseni mukaan niitä ei koskaan käsitellä. Jos ne ovat tärkeitä, ne tuodaan myöhemmin uudelleen esiin.
Hannah Clark: Kiitos kaikille osallistumisesta. Erityiskiitos paneelisteille ajastanne. Aakash, Andrea ja Paweł, kiitos paljon. Tämä oli todella hauska ja informatiivinen keskustelu. Kiitos kaikille tapahtumaamme osallistuneille ja aktiiviselle yleisölle. Toivottavasti näemme seuraavan kerran.
Kiitos kuuntelusta. Saat lisää näkemyksiä, käytännön oppaita ja työkaluarvosteluja tilaamalla uutiskirjeemme osoitteessa theproductmanager.com/subscribe. Voit kuulla lisää tämänkaltaisia keskusteluja tilaamalla Product Manager -podcastin sieltä, missä kuuntelet podcasteja.
