Oletko joutunut organisaatiossasi väärinymmärrysten, keskenään kilpailevien prioriteettien ja epäselvyyden sumuun?
Tässä jaksossa Hannah Clarkin vieraana on Bijan Shahrokhi — ProductManagementExercises.com-sivuston ja ProductMonkey.ai:n perustaja — jakamassa näkemyksiään tehokkaasta viestinnästä, objektiivisesta priorisoinnista ja muusta.
Kuuntele jakso ja opi, miten voit maksimoida tuotetiimisi tehokkuuden.
Haastattelun kohokohdat
- Bijanin matka tuotehallinnan pariin [00:20]
- Bijan on tuotepäällikkö, jolla on yli 10 vuoden työkokemus.
- Hän tutustui tuotehallintaan sattumalta vaikeuksissa olleen startup-yrityksen aikana.
- Hän työskenteli suuremmissa organisaatioissa, minkä jälkeen hän liittyi kahteen startup-yritykseen ja käynnisti ne; toinen yritys hankittiin ja toinen menestyi.
- Tällä hetkellä hän keskittyy Product Management Exercises -sivustoon ja käynnisti ProductMonkey.ai-palvelun tuotehallintayhteisöä varten.
- Epäselvyyden vaikutus organisaatioissa [02:24]
- Selkeys tarkoittaa sidosryhmien yhteisymmärrystä siitä, mitä täytyy rakentaa.
- Organisaatiolta puuttuu selkeys, kun eri sidosryhmillä on erilaiset näkemykset onnistumiskriteereistä.
- Esimerkki: tekninen näkökulma keskittyy suorituskykymittareihin, kun taas liiketoiminnan näkökulma keskittyy asiakaspalautteeseen.
- Selkeyden puute käy ilmi, kun keskusteluissa paljastuu ristiriitaista tietoa tai käsittelemättömiä aiheita.
Selkein merkki organisaation selkeyteen liittyvistä ongelmista on se, että kysyttäessä eri ihmisiltä seuraavan virstanpylvään onnistumiskriteereistä vastauksena kuullaan erilaisia tarinoita.
Bijan Shahrokhi
- Esimerkki selkeyden puutteesta startup-yrityksessä [03:50]
- Bijan kertoo tarinan projektista, jonka rahat olivat loppumaisillaan.
- Perustajien ja insinöörien näkemyksissä havaittiin merkittävä ero julkaisuaikataulun suhteen.
- Ensimmäiset kolme kuukautta käytettiin sidosryhmien toisistaan poikkeavien näkemysten käsittelemiseen.
- Tunnistettiin ominaisuudet, joista oltiin vahvasti eri mieltä, ja pyrittiin selkeyteen sen suhteen, sisällytettäisiinkö ne ensimmäiseen julkaisuun.
- Päätöksenteon seurauksena yksinkertaistetun version rakentamiseen kului vuosi.
- Hän korostaa päätöksenteon selkeyden merkitystä onnistuneessa tuotekehityksessä.
- Selkeyden puutteen vaikutukset organisaation kulttuuriin [06:26]
- Bijan korostaa, että selkeyttä edistävien prosessien puute organisaatiossa johtaa merkittävään riskiin siitä, ettei tuotteita saada julkaistua.
- Monet lupaavat projektit epäonnistuvat, koska rahat loppuvat ennen markkinoille pääsyä.
- R&D-projekteissa, erityisesti akateemisesti suuntautuneiden perustajien johtamissa projekteissa, pyritään usein täydellisyyteen, mikä johtaa jatkuvaan rakentamiseen ilman julkaisua.
- Täydellisyyden tavoittelu estää näitä projekteja pääsemästä markkinoille ja vaikeuttaa niiden vision toteutumista.
- Yleiset sudenkuopat MVP:iden rakentamisessa [07:56]
- Startup-yritykset yhdistävät virheellisesti MVP:n rikkinäisen ja käyttökelvottoman tuotteen toimittamiseen.
- Bijan korostaa, ettei MVP:tä pidä sekoittaa virheelliseen tuotteeseen.
- Hän kertoo esimerkin sijoittamastaan yritysratkaisusta, jossa oli käytettävyysongelmia.
- Hän painottaa, että keskeisen käyttäjäkokemuksen ja arvolupauksen on toimittava sujuvasti alusta loppuun.
- Bijanin prosessi selkeyden saavuttamiseksi organisaatioissa [09:59]
- Bijan esittelee vaiheittaisen prosessin selkeyden saavuttamiseksi organisaatioissa.
- Lähestymistapaan kuuluu kahdenkeskisiä tapaamisia sidosryhmien kanssa heidän yksilöllisten näkemystensä ymmärtämiseksi.
- Jatkuva edestakainen viestintä auttaa käsittelemään eriäviä mielipiteitä ja huolenaiheita.
- Ratkaisemattomissa kysymyksissä järjestetään ryhmäkeskusteluja, jotta päätöksiin voidaan päästä yhdessä.
- Tämän prosessin tuloksena syntyy yhtenäinen tuotestrategia, määrittely tai prioriteetit.
- Tavoitteet priorisoidaan alussa ja varmistetaan yhteinen näkemys ennen selkeyttä tavoittelevan prosessin jatkamista.
- Tuotteen priorisointi ja kilpailevien prioriteettien käsittely [15:53]
- Bijan ehdottaa pisteytysmallia, joka perustuu vaikutukseen, todennäköisyyteen ja toteutuksen helppouteen.
- Pisteet vaihtelevat välillä 1–5, jossa 5 tarkoittaa suurinta vaikutusta tai helpointa toteutusta.
- Kaava on "vaikutus x todennäköisyys + toteutuksen helppous".
- Tämä objektiivinen menetelmä mahdollistaa yhteisymmärryksen rakentamisen ja selkeän priorisoinnin.
- Palautteen ja keskustelujen henkilöimättömyys on ratkaisevan tärkeää priorisointikeskusteluissa.
- Bijan käsittelee tilanteita, joissa uusia prioriteetteja ehdotetaan alkuperäisen priorisoinnin jälkeen.
- Vaihtoehtoina ovat jonkin muun asian prioriteetin laskeminen tai lisäresurssien osoittaminen, jotta olemassa olevien prioriteettien eteneminen ei hidastu.
Keskeinen periaate on varmistaa, ettei prioriteettilistasi hidastu uusien kohteiden lisäämisen vuoksi. Tämä on tuotepäällikön tehtävä, mutta käytännöt voivat vaihdella organisaatioittain ja vaikuttaa toimitusten oikea-aikaisuuteen.
Bijan Shahrokhi
- Johdatus Product Monkey AI:hin ja tuottavuusvinkkeihin [21:05]
- Product Monkey AI automatisoi yksityiskohtaisten tuotevaatimusten ja hyväksymiskriteerien kirjoittamisen.
- Työkalu kerää tietoja projektista, organisaatiosta ja käyttäjäpolusta.
- Käyttäjän ohjauksen avulla Product Monkey AI tuottaa yksityiskohtaisia tuotevaatimuksia, testausskenaarioita ja paljon muuta.
- Tavoitteena on säästää tuotepäälliköiden aikaa tarjoamalla suunnittelutiimeille 80-prosenttisesti valmis luonnos.
- Product Monkey AI pyrkii nopeuttamaan selkeyden tuomista suunnittelutiimeille ja vähentämään yksityiskohtaiseen dokumentointiin käytettävää aikaa.
Tapaa vieraamme
Bijan on tuotehallinnan johtaja, jolla on yli 10 vuoden kokemus mullistavien teknologioiden rakentamisesta. Hän toimi äskettäin tuotepäällikkönä O(1)Labsilla, jossa hän työskenteli Mina Protocolin, maailman kevyimmän lohkoketjun ja L1-projektin, parissa. Protokolla käyttää nollatietotodistuksia tarjotakseen kooltaan kiinteän, luvattoman 22KB:n lohkoketjun.
Hän päätti jättää tiimin sen jälkeen, kun Mina oli julkaistu mainnetissä, hän oli rakentanut tuotetiimin ja auttanut tiimiä keräämään $92M viimeisimmällä rahoituskierroksellaan. Ennen O(1)Labsia hän toimi tuotepäällikkönä Ethereumin toisen kerroksen vaatimustenmukaisuusprotokolla Harborissa, kunnes Bitgo osti yrityksen.
Hän perusti myös sivuston productmanagementexercises.com, joka on yli 100 000 tuotepäällikön maailmanlaajuinen yhteisö. He auttavat toisiaan valmistautumaan PM-haastatteluihin maailman johtavissa teknologiayrityksissä.
Tuotejohtajina on tärkeää ymmärtää, ettei MVP:n pitäisi olla buginen tuote, jonka arvo on epäselvä. Keskity sujuvasti toimivan keskeisen käyttökokemuksen toimittamiseen, vaikka joitakin ominaisuuksia jätettäisiin pois.
Bijan Shahrokhi
Tämän jakson resurssit:
- Tilaa The CPO Clubin uutiskirje
- Ota yhteyttä Bijaniin palveluissa LinkedIn ja Twitter
- Tutustu sivustoihin Product Management Exercises ja ProductMonkey.ai
Aiheeseen liittyvät artikkelit ja podcastit:
Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmiston avulla. Anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole täysin oikeassa joka kerta.
Hannah Clark: Tämä on käytännössä klisee, mutta sitä tapahtuu jatkuvasti: sanot jotain kolmelle ihmiselle, ja he kuulevat kolme eri asiaa. Se ei ole kovin vakavaa, jos sanot: ”Käyn hakemassa kahvia, haluaako joku jotain?” Mutta kun rakennat MVP:tä jatkuvasti lyhenevällä toiminta-ajalla tai yrität julkaista jotain tiukassa aikataulussa, selkeyden puute voi koitua startupin kohtaloksi.
Tämän päivän vieraamme on Bijan Shahrokhi, Product Management Exercisesin ja Product Monkey AI:n perustaja. Bijan on uransa jälkimmäisen osan aikana auttanut tuotejohtajia työskentelemään tuottavammin ja johtamaan tiimejä paremmin. Kyky tuoda selkeyttä ja yhteistä suuntaa tuotetiimiin on näiden taitojen perusta. Hetken kuluttua Bijan kertoo helposti toistettavasta prosessista, joka vaatii hieman aikaa etukäteen, mutta voi pelastaa vaikeuksissa olevan startupin. Aloitetaan.
Tervetuloa takaisin, kuuntelijat. Seurassani on tänään Bijan Shahrokhi. Hän on ProductManagementExercises.com-sivuston perustaja, ja hän on hiljattain julkaissut erityisesti tuotejohtajille tarkoitetun tuottavuustyökalun nimeltä ProductMonkey.ai.
Bijan, kiitos paljon, että liityit seuraamme tänään.
Bijan Shahrokhi: Kiitos paljon kutsusta.
Hannah Clark: Hienoa. Aloitamme aina samalla tavalla. Haluaisitko kertoa hieman taustastasi ja siitä, miten päädyit nykyiseen tilanteeseesi?
Bijan Shahrokhi: Toki. Olen sydämeltäni tuotejohtaja. Olen ollut tuotejohtajana yli kymmenen vuotta, täysin sattumalta.
En edes tiennyt, mitä tuotejohtaminen oli, ennen kuin minulla oli startup, joka ei menestynyt kovin hyvin. Kysyin ystävältäni, mitä hänen mielestään minun pitäisi tehdä seuraavaksi, ja hän sanoi: ”Sinun pitäisi ryhtyä tuotejohtajaksi.” Ajattelin, että hetkinen. Se kuulostaa hyvin kiinnostavalta: tuote ja tuotteen johtaminen. Tätä haluan tehdä.
Siitä lähtien minusta tuli tuotejohtaja. Olen tehnyt viimeisten kymmenen vuoden aikana monenlaisia asioita. Työskentelin urani ensimmäiset pari vuotta suuremmissa organisaatioissa, esimerkiksi pankissa tuotejohtajana ja myöhemmin tuotestrategina. Sen jälkeen olin mukana kahdessa startupissa. Molemmissa tapauksissa tuote julkaistiin liittyessäni yritykseen, ja suurempi toimija ekosysteemissä osti toisen niistä puolentoista vuoden kuluessa.
Toinen oli itse asiassa menestyksekäs projekti. Sen arvo oli parhaimmillaan useita miljardeja dollareita. Se on yhä toiminnassa ja kasvaa edelleen voimakkaasti. Sen jälkeen olen viime vuosina keskittynyt pääasiassa Product Management Exercisesiin. Hiljattain julkaisimme tuotejohtamisen yhteisölle uuden tuotteen nimeltä ProductMonkey.ai.
Hannah Clark: Mahtavaa. Tänään puhumme siis organisaatioiden selkeydestä, joka on sinulle henkilökohtaisesti tärkeä aihe. Selkeydellä tarkoitan sitä, että kaikki sidosryhmät ovat samalla sivulla ja jakavat saman käsityksen siitä, mitä tapahtuu ja mitä pitäisi rakentaa.
Miltä organisaation selkeyden puute mielestäsi näyttää?
Bijan Shahrokhi: Hyvä kysymys. Suurin ja ilmeisin merkki selkeyden puutteesta on se, että kysyt eri ihmisiltä eri puolilla organisaatiota, mitkä heidän mielestään ovat seuraavan suuren virstanpylvään onnistumiskriteerit, ja alat kuulla erilaisia tarinoita.
Annan esimerkin. Oletetaan, että kyseessä on hyvin tekninen tuote, jossa seurataan monia suorituskykymittareita, kuten viivettä, nopeutta, tapahtumien määrää sekunnissa tai suoritettavien tehtävien määrää. Jos tekninen henkilö organisaatiossa ei määrittele tätä selkeästi, hän saattaa yrittää rakentaa jotain, joka kestää erittäin suuren määrän tapahtumia.
Jos taas kysyt liiketoiminta- ja asiakaslähtöisemmältä henkilöltä, hän saattaa sanoa, että meidän tarvitsee vain saada jotain ulos, jotta voimme alkaa kerätä palautetta asiakkailtamme. Tiedät selkeyden puuttuvan, kun keskustelet organisaation eri ihmisten kanssa ja kuulet erilaisia lukuja tai he sanovat: ”Emme koskaan ajatelleet sitä” tai ”Emme koskaan keskustelleet siitä.” Se on tuotejohtajalle yleensä suuri varoitusmerkki: hetkinen, tässä ei taida olla riittävästi selkeyttä.
Hannah Clark: Kuulostaa siltä, että sinulla on tästä omakohtaisia kokemuksia. Nimiä mainitsematta, tuleeko mieleesi jokin esimerkki?
Bijan Shahrokhi: Kyllä. Viimeinen projekti, josta kerroin ja jonka arvo nousi miljardeihin, oli yritys, jolla oli vain muutama kuukausi aikaa ennen käteisen loppumista, eikä se ollut vielä julkaissut tuotetta.
He luulivat olevansa vain muutaman kuukauden päässä tuotteen julkaisemisesta. Kun liityin yritykseen, minulle kerrottiin aluksi, että julkaisuun oli kolme kuukautta. Liityttyäni tajusin, että joidenkin perustajien mielessä julkaisuun oli ehkä viidestä kymmeneen vuotta.
Myös joidenkin insinöörien mielestä heidän toimittamansa kokonaisuus oli muutaman kuukauden päässä valmistumisesta. Näiden näkemysten välillä oli valtava kuilu. Tämän vuoksi he olivat kehittäneet tuotetta yli kolme vuotta, sillä insinööritiimi esitteli jatkuvasti jotain lähes valmiina olevaa. Perustajat tai liiketoimintaihmiset katsoivat sitä ja sanoivat: ”Hetkinen, ettehän te ole valmiita.”
Se ei vastannut heidän käsitystään. He määrittelivät uudelleen, mitä pitäisi rakentaa, ja insinöörit palasivat rakentamaan sitä pettyneinä ja tuntien, etteivät he tuottaneet organisaatiolle todellista arvoa. Käytin tuolloin ensimmäiset kolme kuukauttani tuotejohtajana tavatakseni monia sidosryhmiä ja ymmärtääkseni, mitkä ominaisuudet herättivät organisaation sisällä voimakkaasti erilaisia näkemyksiä.
Esimerkiksi huomasin, että yhden ominaisuuden osalta osa organisaatiosta piti sitä välttämättömänä ensimmäisessä julkaisussa, kun taas toinen puoli ei pitänyt sitä tärkeänä. Aloimme keskustella näistä asioista ja selvitimme, rakennettaisiinko ne vai ei. Kyse saattoi olla kyllä–ei-päätöksestä tai päätöksestä toteuttaa ominaisuudesta hyvin kevyt versio.
Määrittelimme tarkasti, mitä siihen kuuluisi. Vasta sen jälkeen meiltä kesti noin vuosi rakentaa kevyt versio siitä, mitä alun perin kuviteltiin julkaistavan kolmessa kuukaudessa. Rehellisesti sanottuna pelkkään selkeyttämiseen siitä, mitä vuoden aikana rakennettaisiin, kului muutama kuukausi.
Toivottavasti tämä osoittaa, että selkeyden avulla jotain voidaan saada julkaistua. Kun tuote on julkaistu, käyttäjiltä, yhteisöltä ja koko ekosysteemiltä saadun palautteen avulla voidaan päättää, mitkä tuotantoputkessa olevista asioista pitäisi priorisoida seuraavaksi.
Hannah Clark: Se on valtava saavutus. Tuollaisen kuilun umpeen kurominen vaikuttaa lähes mahdottomalta. On vaikuttavaa lähestyä asiaa tuolla tavalla. Jos otamme hieman etäisyyttä, mitä laajempia seurauksia syntyy, kun organisaatio ei ole rakentanut selkeyttä tukevia prosesseja osaksi kulttuuriaan, ei vain tuotetiimiin?
Bijan Shahrokhi: Suurin vaikutus on yleensä se, etteivät he saa mitään julkaistua. Tämä on suuri ongelma. Monet hienot projektit eivät koskaan päädy käyttäjille, koska rahat loppuvat ennen kuin yritys ehtii alkaa tuottaa kassavirtaa. Valitettavasti todellisuus on vielä ankarampi tutkimus- ja kehitysperustaisissa projekteissa. Tieteeseen pohjautuvia läpimurtoja tavoittelevia T&K-projekteja johtavat usein perustajat, joilla on vahva akateeminen tausta.
Vahvan akateemisen taustan omaavat ihmiset — enkä tarkoita tätä loukkauksena, sillä myös minulla on vahva tekninen ja akateeminen tausta — etsivät helposti täydellisyyttä. Kun organisaatiota johdetaan näin, rakentamista jatketaan ja uusia asioita lisätään. He ovat jatkuvasti huolissaan äärimmäisistä tilanteista, vaikka rehellisesti sanottuna niiden tapahtuminen projektin alku- tai kokeiluvaiheessa ei olisi maailmanloppu.
Lopputulos on, ettei tuotetta koskaan julkaista eikä maailma pääse näkemään, millainen visio uudesta teknologiasta heillä oli.
Hannah Clark: Tuo koko ”valmis vastaan täydellinen” -asetelma on meille tuttu. Siinä perfektionistit kamppailevat niiden kanssa, jotka haluavat vain julkaista, eikö niin? Yksi alue, jolla selkeys on erityisen tärkeää, on mainitsemasi MVP:n kehittäminen. Siinä tehdään helposti paljon virheitä ja väärinymmärryksiä, jotka voivat lopulta olla tuhoisia.
Mitä yleisiä sudenkuoppia MVP:tä rakentavien tiimien pitäisi välttää, ja millaisia ratkaisuja niihin on?
Bijan Shahrokhi: Suurin virhe, jonka olen nähnyt startupien tekevän MVP:n kohdalla, on sen sekoittaminen rikkinäisen ja käyttökelvottoman tuotteen toimittamiseen.
Olen nähnyt tämän monta kertaa. Mainitsematta nimiä voin antaa esimerkin. Olen sijoittanut erääseen yrityksille suunnattuun ratkaisuun, josta olen erittäin innostunut. Olin innostunut siitä alusta asti, koska pystyin kuvittelemaan haluavani käyttää sitä.
Myös Product Management Exercises -organisaationi olisi voinut käyttää sitä päivittäin. Suurin este käyttöönotolle on ollut se, että tuote on niin virheellinen, ettemme voi edes käyttää sitä. Tuotejohtajien on siis kiinnitettävä tähän huomiota ja varmistettava, että MVP ei tarkoita virheellistä tuotetta, joka ei kykene osoittamaan tuotteen arvolupausta.
On edelleen varmistettava, että käyttäjäkokemuksen ydin tai käyttäjälle toimitettava keskeinen arvo toimii sujuvasti alusta loppuun. Monia tarpeettomia asioita voi rajata pois, mutta keskeinen tuotekokemus on pystyttävä toimittamaan.
Tämä on yksi suurimmista virheistä, joita yritykset tekevät: ne ymmärtävät MVP:n väärin ja kuvittelevat, että se tarkoittaa jonkin rikkinäisen asian julkaisemista.
Hannah Clark: Kyse on siis melkein siitä, että yksi ryhmä ei halua odottaa julkaisua siihen asti, että kaikki on täydellistä, kun taas toinen on spektrin toisessa päässä. Selvä.
Sinulla on melko perusteellinen prosessi selkeyden etsimiseen organisaatioissa, johon viittasit aiemmin. Jos kuuntelijat haluaisivat kopioida ja liittää tämän lähestymistavan omaan työnkulkuunsa, mitä vaiheita suosittelisit, jotta kaikki tiimin jäsenet pääsisivät yhteisymmärrykseen?
Bijan Shahrokhi: Kiitos kysymyksestä. On kiinnostavaa, että kysyit tätä, sillä monet PM Exercisesin ihmiset ovat kokeneet prosessin hyödylliseksi. Rehellisesti sanottuna se on melko suoraviivainen ja keskittyy vaikean työn tekemiseen varhain, ennen projektin aloittamista. Se etenee vaiheittain, joten käyn sen nopeasti läpi.
Käytännössä käytät aluksi paljon aikaa yhteisen suunnan luomiseen koko organisaatiossa vaiheittaisen prosessin avulla. Aloitat vasta, kun uskot kaikkien olevan samalla sivulla. Tämä lähestymistapa on käytössä monissa suurissa organisaatioissa, kuten rahoituslaitoksissa.
Kun siirryimme vesiputousmallista ketterään ja Scrum-menetelmään, ajattelimme, ettei tulevaisuuden suunnasta tarvitse olla selvyyttä ja että tarvitsee vain tietää, mitä seuraavien kahden viikon aikana tehdään. Se ei ollut ketteryyden tarkoitus. Tarkoitus oli toimittaa jotain merkityksellistä kahden viikon välein ja samalla tietää selkeästi, mihin ollaan menossa muutaman kuukauden aikajänteellä.
Miten tämä tehdään? Jos johdan projektia tai tuotetta, jossa huomaan olevan paljon epäselvyyttä, järjestän ensin kahdenkeskisiä tapaamisia sidosryhmien kanssa. Niiden täytyy olla kahdenkeskisiä, ei ryhmätilaisuuksia, koska joku saattaa jakaa arkaluontoiseen aiheeseen liittyvän mielipiteen ja joku toinen keskeyttää. Tuotteen ”oraakkelina” et pysty käsittelemään kaikkea tarvittavaa asiayhteyttä kunnolla.
Sinun pitää saada jokainen keskustelemaan kanssasi ja varmistaa, että ymmärrät hänen näkökulmansa. Oletetaan, että kyse on kompromissista: rakennetaanko X vai ei. Se on binäärinen päätös, mutta sama malli toimii monissa muissakin tilanteissa.
Tapaat jokaisen, selvität hänen näkemyksensä siitä, miksi asia pitäisi tai ei pitäisi toteuttaa, ja kysyt, mitä asioita sinun pitäisi päätöstä tehdessä huomioida. He antavat todennäköisesti neljä tai viisi asiaa, jotka ovat heidän maailmassaan erittäin tärkeitä.
Tämä on erityisen tärkeää T&K-ympäristössä. Mitä teknisempi tuote on tai mitä enemmän sillä on riippuvuuksia organisaation muihin työkaluihin, sitä tärkeämmäksi tämä muodostuu, koska mukana on eri alojen asiantuntijoita. Tapaat seuraavan henkilön, sitten seuraavan, ja lopulta kaikki kahden kesken.
Ajan myötä oma näkemyksesi kompromissista joko vahvistuu tai alat muodostaa uusia näkemyksiä. Kompromissit voivat muuttua, ja saatat huomata joidenkin asioiden olevan vaikeampia tai helpompia kuin aluksi ajattelit.
Kun keräät lisää tietoa kahdenkeskisissä keskusteluissa, palaat joidenkin ihmisten luo ja sanot: ”Kun tapasimme aluksi, kerroit, että nämä olivat suurimmat huolenaiheesi. Muiden kanssa käymieni keskustelujen perusteella uskon, ettei niiden pitäisi olla huolenaiheita. Tässä on perusteluni. Kerro, miksi olen väärässä, tai vahvista, että olen oikeassa.”
Tämän aikaa vievän edestakaisen keskustelun aikana huomaat usein, että monet tiimin kohtaamat haasteet johtuivat yksinkertaisesti viestinnän puutteesta. Kukaan ei ollut käyttänyt aikaa erilaisten kompromissien selkeään avaamiseen organisaation eri sidosryhmille, ja monet asiat alkavat ratketa.
Ajan myötä saat yhä enemmän selkeyttä niistä kompromisseista, jotka on huomioitava. Tätä lähestymistapaa voi käyttää myös tuotteen prioriteetteihin. Jossain vaiheessa huomaat, että muutama asia herättää edelleen erilaisia näkemyksiä. Puolet tiimistä voi pitää tiettyä ominaisuutta, esimerkiksi turvallisuutta, erittäin tärkeänä, kun taas toinen puoli ei pidä sitä tärkeänä.
Tässä vaiheessa järjestät ryhmäkeskustelun. Sanot: ”Tämä ominaisuus on meille merkityksellinen, mutta meillä on kaksi erilaista näkökulmaa. Haluaisin, että keskustelemme asiasta.” Tällaisen keskustelun avulla päädytään yleensä päätökseen.
Joskus tarvitaan toimintakohteita, kuten lisätutkimusta. Silloin järjestät uuden tapaamisen ja palaat asiaan: ”Tämä oli alkuperäinen tavoitteemme. Teimme tutkimuksen ja tässä ovat uudet havainnot. Mitä teemme?” Lopulta teette päätöksen.
Kun kaikki kompromissit on määritelty selkeästi, tiimin on paljon helpompi päättää, valitaanko tietty suunta kompromissien perusteella vai määritelläänkö tuotestrategia ja tuotteen prioriteetit. Silloin voidaan sanoa: ”Nyt olemme päättäneet, että tämä on prioriteettimme ja keskitymme siihen.”
Korkealla tasolla ajateltuna vaihe yksi on aloittaa kahdenkeskisillä tapaamisilla, joissa ymmärrät selkeästi jokaisen näkökulman. Vaihe kaksi on käydä tarvittaessa edestakaista keskustelua heidän kanssaan ja varmistaa, että kaikki erilaisia mielipiteitä herättävät asiat käsitellään. Jos niitä ei saada ratkaistua, merkitse ne ryhmäkeskusteluihin.
Vaihe kolme on ryhmäkeskustelut. Lopputuloksena on yhtenäinen tuotestrategia, tuotemäärittely tai joukko tuoteprioriteetteja. Eri tilanteissa voi olla ylimääräinen välivaihe. Tuoteprioriteeteissa täytyy esimerkiksi pohtia tavoitetta: ehkä alussa on käytettävä aikaa sen määrittelyyn, että tavoitteena on saada jotain nopeasti julkaistua ja oppia siitä. Sen jälkeen selvitetään, onko joku eri mieltä. Jos kaikki ovat samaa mieltä, prosessia voi jatkaa.
Hannah Clark: Haluaisin puhua hieman lisää tuoteprioriteeteista yleensä. Vaikka olisimme melko lähellä yhteisymmärrystä tai tuntisimme sopineemme tavoitteista ja onnistumisen määritelmästä, kilpailevien prioriteettien tasapainottaminen voi silti olla vaikeaa.
Tuotteen ominaisuuksien priorisointiin on tietysti sata erilaista viitekehystä. Mitkä menetelmät ovat olleet sinulle menestyksekkäimpiä ja laajimmin sovellettavia, kun käsittelet kilpailevia prioriteetteja?
Bijan Shahrokhi: Yksi lähestymistapa on pisteyttää asiat ja tarkastella niitä muutamasta eri näkökulmasta.
Ensimmäinen on vaikutus, joka kyseisellä ominaisuudella tai tuotteella mielestäni on kohdeyleisöön tai kohdekäyttäjiin. Toinen on todennäköisyys sille, että pystymme todella saavuttamaan tuon vaikutuksen. Monissa tapauksissa emme tiedä, tuleeko uusi tuote todella kiinnostamaan yleisöä.
Silloin todennäköisyys on pienempi. Kolmas tekijä on toteutuksen helppous. Ajattelemani kaava on ”vaikutus kerrottuna vaikutuksen todennäköisyydellä, plus toteutuksen helppous”. Vaikutus arvioidaan asteikolla yhdestä viiteen, jossa viisi on suurin ja yksi pienin vaikutus.
Toteutuksen helppoudessa viisi tarkoittaa, että asia on helppo toteuttaa, ja yksi tarkoittaa suurta työmäärää. Näin saat pistemäärän. Pidän tästä lähestymistavasta, koska se on objektiivinen. Voit käydä saman prosessin avulla tiimin jäsenen kanssa keskustelun ja sanoa: ”Tässä on taulukkoni organisaation keskeisistä projekteista ja näkemykseni siitä, miten ne sijoittuvat vaikutuksen ja toteutustyön perusteella. Näiden pisteiden perusteella nämä ovat tärkeimmät projektit.”
Tiimin jäsen voi huomauttaa, että olet unohtanut kolme muuta projektia, tai että yksi projekti pitäisi jakaa kolmeen osaan, koska se on paljon suurempi kuin kuvittelet. Hän voi myös olla eri mieltä vaikutuksesta tai työmäärästä. Nyt keskustelu on kuitenkin objektiivista ja keskittyy asioihin.
Pisteytysjärjestelmän etu on se, ettei tarvitse arvioida tarkasti, kuinka kauan kaikki kestää. Asioita tarkastellaan suhteessa toisiin projekteihin, joten on helpompi muodostaa nopeasti yhteisymmärrys niiden tuottamasta arvosta ja vaatimasta työmäärästä. Tuloksena on selkeästi määritelty prioriteettilista, esimerkiksi viisi asiaa, joihin keskitytään seuraavalla vuosineljänneksellä.
Kun uusi asia tai uusi työntekijä ehdottaa jotakin, katsot prioriteettitaulukkoa ja sanot: ”Keskustelimme tästä ja päätimme, ettei se ole juuri nyt prioriteetti näistä syistä. Kun nämä kaksi tai kolme asiaa on tehty, priorisoimme sen.” Joskus huomaat, että listaan on lisättävä asioita. Myös näitä tilanteita voi käsitellä samalla tavalla.
Mielestäni lähestymistapa on objektiivinen ja helpottaa prioriteettien määrittelyä.
Hannah Clark: Arvostan sitä. Olemme puhuneet The Product Managerissa palautteen ja priorisointikeskustelujen tekemisestä persoonattomiksi, jotta ihmiset eivät koe, että heidän sivuprojektinsa tai agendansa on siirretty alemmas henkilökohtaisista syistä.
Tuo on erittäin käytännöllinen menetelmä. Mitä sanoitkaan, että voisimme käsitellä seuraavaksi?
Bijan Shahrokhi: Puhuin tilanteista, joissa joku sanoo asian tarvitsevan olla prioriteetti, ja huomaat, että sen todella pitäisi olla prioriteetti.
Miten tällaisessa tilanteessa toimitaan? Sitä ei voi vain lisätä prioriteettilistalle. On joko löydettävä tapa toteuttaa se niin, ettei se hidasta jo korkealla prioriteetilla olevia asioita, tai jokin muu asia on poistettava listalta ja korvattava uudella pisteytyksen perusteella.
Toinen vaihtoehto on käyttää lisäresursseja uuden prioriteetin toteuttamiseen. Periaate on, etteivät nykyisen prioriteettilistan asiat hidastu vain siksi, että listalle lisätään uusi asia. Mielestäni tämä kuuluu tuotejohtajan tehtäviin, vaikka näin ei ole kaikissa organisaatioissa. Siitä syntyy ongelmia, jos asioita ei saada toimitettua.
Hyvä tuotejohtaja kiinnittää asiaan huomiota ja miettii uuden tiedon perusteella, miten uusi prioriteetti käsitellään: poistaako hän jotain listalta vai hankkiiko hän lisäresursseja, jotka pystyvät työskentelemään asian parissa vaikuttamatta muiden asioiden toimitusnopeuteen.
Hannah Clark: Mielenkiintoista. Haluaisin vaihtaa hieman aihetta, sillä aikamme alkaa olla lopussa. Halusin puhua tuottavuudesta, joka on toinen sinulle tärkeä aihe ja todennäköisesti yksi tärkeimmistä syistä, miksi perustit productmonkey.ai:n.
Onko sinulla yleisiä tuottavuusvinkkejä yleisöllemme ja tietoa Product Monkey AI:sta, joka voisi kiinnostaa ihmisiä? Se on todella hieno työkalu.
Bijan Shahrokhi: Product Monkey AI:n avulla automatisoin tehtävää, joka on mielestäni meille tuotejohtajille välttämätön, mutta josta en pidä: yksityiskohtaisten vaatimusten ja hyväksymiskriteerien kirjoittamista. Hankimme mahdollisimman paljon tietoa projektista, jonka parissa työskentelet, organisaatiostasi ja käsittelemästäsi käyttäjäpolusta.
Kun ohjaat prosessia asianmukaisesti tekoälyn avulla, voimme tuottaa yksityiskohtaiset tuotevaatimukset, hyväksymiskriteerit, testaustilanteet sekä tapahtumat ja mittarit, joihin tuotetta rakennettaessa pitäisi kiinnittää huomiota. Saat nopeasti luonnoksen, joka kattaa noin 80 prosenttia insinööritiimin työtehtävien ja tuotedokumenttien työstä.
Sen jälkeen voit käyttää aikasi viimeisen 20 prosentin viimeistelyyn. Kuten mainitsin, yksi tuotejohtajien tuottamista hyödyistä on selkeyden tuominen. Product Monkey AI voi auttaa siinä lyhentämällä aikaa, jonka tuotejohtajat tarvitsevat selkeyden tuomiseen insinööritiimeille.
Hannah Clark: Hienoa. Olen varma, että monet kuuntelijat löytävät työkalusta paljon hyötyä. Bijan, kiitos paljon, että liityit seuraamme. Mistä ihmiset voivat seurata sinua verkossa, jos he haluavat tietää, mitä muuta teet?
Bijan Shahrokhi: He voivat tulla Twitteriin tai X:ään, kuten sitä nykyään kutsumme. X-käyttäjänimeni on bijan_sha. Löydät minut sieltä. Voit myös vierailla PM Exercisesissa tai Product Management Exercisesissa. Voit hakea kummalla tahansa nimellä, ja löydät sivustomme, jonka kautta voit olla minuun yhteydessä.
Hannah Clark: Hienoa. Kiitos paljon ajastasi.
Bijan Shahrokhi: Kiitos paljon kutsusta.
Hannah Clark: Kiitos kuuntelusta. Lisää hyviä näkemyksiä, oppaita ja työkaluarvosteluja saat tilaamalla uutiskirjeemme osoitteessa theproductmanager.com/subscribe. Voit kuunnella lisää tämän kaltaisia keskusteluja tilaamalla The CPO Clubin sieltä, missä kuuntelet podcasteja.
