Product Manager vs Product Owner (Suomi)

se on mielenkiintoinen kysymys ja sellainen, jonka purkaminen vie aikaa. Katsotaanpa, mistä nämä termit ja tieteenalat ovat peräisin ja miten jotkut yhteiset puitteet selittävät niitä.,

kun aloitin urani, minua kutsuttiin Yritysanalyytikoksi. Tein hyvin vähän ”bisnesanalyysia”, kun tarkastelimme sitä perinteisissä IT-yrityksissä. Rehellisesti sanottuna en tehnyt juuri mitään siitä, mitä opetan Tuotehallintana nytkään. Minun tehtäväni oli kerätä vaatimukset myynnistä, keksiä ratkaisu, suunnitella se, ja sitten lähettää eritelmä asiakirja kehittämiseen rakennetaan.

minua alettiin kutsua Yritysanalyytikoksi työskennellessäni pankeissa ja muissa rahoituspalveluyrityksissä. Minua ei kutsuttu tuotepäälliköksi ennen kuin pelastin sen ja päädyin startupiin., Se oli kaikki samaa työtä, mitä olin tehnyt aiemmin, mutta nyt sillä oli eri nimi. Pidin tästä nimestä. ”Tuotepäällikkö” tuntui olevan gravitas siihen, ja kun katsoin muita teknologiayrityksiä laaksossa, saatoin nähdä selkeän urapolun veistetty minulle, kun taas yritysanalyytikot olivat erilaisia jokaisessa yrityksessä.

olin kuullut termistä tuotteen omistaja vasta vuosia myöhemmin. Kun kuulin termin ensimmäisen kerran, kysyin joltakulta, mitä se tarkoittaa. He kertoivat, että se oli sama kuin tuotepäällikkö, mutta se oli Scrumissa käytetty termi., Olimme käyttäneet Scrumia vuosia, mutta minua kutsuttiin vielä tuotepäälliköksi, joten minulle oli järkevää, että ne olisivat vaihdettavissa keskenään. Mietin sitä harvoin sen jälkeen.

se oli siihen asti, kunnes sain ensimmäisen kokemukseni Tuotteen hallinnan opettamisesta yrityksessä, jossa käytettiin turvallisia puitteita. Tein työpajaa isolle pankille, kun yksi osallistujista ryntäsi sisään.

”opetat meitä puhumaan käyttäjille, mutta olen tuotteen omistaja. Tuotepäällikkö puhuu kaikille käyttäjille ja kertoo, mitkä ovat vaatimukset., Käytän kaiken aikani kirjoittaakseni näistä käyttäjien tarinoita ja työskennelläkseni tiimin kanssa ratkaisun toteuttamiseksi. Olen hämmentynyt.”

tässä vaiheessa aloin kaivella näiden kahden roolin eroja ja sitä, miten erilaiset filosofiat opettavat niitä. Jotta ymmärtäisimme, miten pääsimme tänne

tuotehallinta voidaan jäljittää vuoteen 1931. Hewlett Packard oli ensimmäisiä teknologiayrityksiä, joka toteutti tämän työn ja organisoi itsensä tuotteilla jo 1940-luvulla., Useimmilla Piilaakson yrityksillä on ollut tuotepäälliköitä alusta asti, ja monet 80-ja 90-luvuilla siellä työskennelleistä ystävistäni olivat todellakin tuotepäälliköitä. Tämä tieteenala ei siis ole uusi, mutta se kehittyy nopeasti, kun yhä useammat yritykset alkavat siirtyä ohjelmistojärjestöihin ja alkaa jäsentää itseään tuotteiden ympärille.

Scrum tuli näyttämölle juuri ennen ketterän manifestin kirjoittamista vuonna 2001. Siinä esiteltiin tuotteen omistajan käsite. Tämä oli henkilö, joka oli asiamies asiakkaalle ja kertoi kehittäjille vaatimukset siitä, mitä pitää rakentaa., Alkuaikoina, kun monet luojat nämä prosessit toimivat kuten konsultit, yritysten, Tuotteen Omistaja oli asiakas — sisäinen henkilö liiketoimintaa, joka voisi istua joukkueen kanssa ja priorisoida ruuhkaa työtä. Itse asiassa, 2017 oppimisen tavoitteet niiden Certified Scrum Product Owner Sertifiointi Scrum Alliance toteaa, ”Opettaa, että rooli Tuotteen Omistaja on tyypillisesti pelataan asiakas tai asiakkaan edustaja, kuten tuotepäällikkö.,”

kun tarkastellaan tuotteen omistajan roolia useimmissa Scrum-kirjallisuudessa, niiden kolmeen päävastuuseen kuuluvat seuraavat:

• Määrittele tuotepalkkio ja luo toiminnallisia käyttäjätarinoita kehitystiimeille. (Kuka luo käyttäjätarinat vaihtelee Scrum-harjoittelusta riippuen)
• sulhanen ja priorisoi työ ruukussa.
• hyväksy valmiit käyttäjätarinat varmistaaksesi, että teos täyttää kriteerit.,

vaikka opetussuunnitelma vaihtuu opettajien ja järjestöjen välillä, näihin asioihin keskitytään lähinnä kahden päivän kursseilla tuotteiden omistajien sertifioimiseksi. Vaikka Scrumilla on paljon tietoa prosesseista ja rituaaleista, mitä tehdä tuotteen omistajana, se jättää paljon kysymyksiä, jotka ovat tärkeitä onnistuneiden tuotteiden luomisessa. Nämä keskittyvät lähinnä ” Mistä tiedämme, että rakennamme oikein?”

tässä tulee tuotteen hallinta., Hyvää tuotepäällikköä opetetaan priorisoimaan työ selkeiden tulosorientoituneiden tavoitteiden vastaisesti, miten löytää ja validoida todellinen asiakas-ja yritysarvo ja mitä prosesseja tarvitaan vähentämään epävarmuutta siitä, että tuote menestyy markkinoilla.

ilman tätä tuotehallinnan taustaa joku voi tehokkaasti käydä läpi tuotteen omistajan roolin Scrumissa, mutta he eivät voi koskaan onnistua varmistamaan, että he rakentavat oikein.,

Jos otat Scrum-tiimisi pois, jos otat Scrumin pois organisaatiosi prosessina, olet edelleen tuotepäällikkö. Tuotehallinta ja Scrum toimivat hyvin yhdessä, mutta tuotehallinta ei ole Scrumin varassa. Se voi ja sen pitäisi olla olemassa millä tahansa kehyksellä tai prosessilla.

minulla oli hiljattain tuoteomistaja, jonka kehittäjät siirtyivät toiseen organisaation osaan, tulivat luokseni, koska pelkäsivät, etteivät he voisi enää olla tuoteihminen tässä yrityksessä. Niiden koko identiteetti näennäisesti saranoitu ottaa tiimi kehittäjät.,

tuotepäällikkönä roolisi ja vastuusi muuttuvat kontekstistasi ja tuotteesi vaiheesta riippuen. Ilman Scrum-tiimiä tai pienempää tiimiä saatat tehdä enemmän strategia-ja validointityötä ongelmalöytöjen kanssa tuotteessa, jota ei ole vielä määritelty. Scrum-tiimin kanssa saatat keskittyä enemmän ratkaisujen toteuttamiseen. Kuten johtaja tuotepäälliköt, saatat olla johtava strategia suurempi osa tuotetta ja valmennus joukkueet löytää ja toteuttaa hyvin.,

the SAFe framework opettaa tämän eri tavalla, ja mielestäni se on yksi heikoimpia kohtia koko kehyksessä. SAFe: ssä tuotepäälliköt ovat Tuoteomistajien johtajia ja vastaavat ulkopuolisesta vuorovaikutuksesta ja työstä. He keskustelevat asiakkaiden kanssa, määrittelevät rakennettavien tuotteiden vaatimukset ja laajuuden, ja viestivät tästä Tuotteen omistajille. Tuotteen omistajat ovat sisäinen päin, määrittelevät ratkaisun komponentit ja työskentelevät kehittäjien kanssa lähettääkseen sen.,

olen valmentanut kymmeniä talleja, jotka käyttävät safe-järjestelmää, enkä ole koskaan nähnyt tämän toimivan hyvin. Tuotteen Omistajat ovat irrotettu niiden käyttäjät ja kyvyttömäksi luomaan tehokkaita ratkaisuja niille, jotka todella ratkaista heidän ongelmansa, koska he eivät ymmärrä ongelmat hyvin., Tuotepäälliköt lähinnä vesittävät heille asetetut vaatimukset, eivätkä tiimit saa todistaa, ovatko nämä oikeita asioita rakentaa vai ei. Kukaan ei tee validointityötä.

olen kuunnellut monia väitteitä, joiden mukaan Tuoteomistajilla ei ole aikaa tehdä molempia rooleja. Nykytilanteessa se on totta. Tuotteiden omistajat, joiden kanssa puhun, viettävät 40 tuntia viikossa kirjoittaen käyttäjien tarinoita. Siinä vaiheessa pitää miettiä, ovatko ne käyttäjätarinat edes arvokkaita? Mitä vastaan he priorisoivat? Mistä he tietävät, että se ratkaisee ongelman?,

Jos sinulla on yksi henkilö viettää paljon aikaa kirjoittaa käyttäjän tarinoita joka viikko, joka viikko, olet joutumasta Rakentaa Ansa — keskittyä määrä kohteita voit vapauttaa ja ei laatu.

hyvällä strategiakehyksellä ja armottomalla priorisoinnilla muutaman avaintavoitteen ympärille yksi ihminen voi tehokkaasti keskustella asiakkaiden kanssa, ymmärtää heidän ongelmiaan ja auttaa määrittelemään ratkaisuja tiimin kanssa. Jopa toimitusjohtaja Scrum.org on samaa mieltä siitä, että näin voi olla, vaikkakin näyttää siltä, että se on nurinkurista., Scrum Inc sanoo myös, että tuotteen omistajan tulisi käyttää puolet ajastaan asiakkaiden kanssa puhumiseen ja puolet tiimityöhön. En ole tässä jaossa sataprosenttisesti mukana, mutta suunta on hyvä. Ulkoisen vs sisäisen työn määrä vaihtelee tuotteen kypsyyden ja menestyksen mukaan. Sinun ei pitäisi tehdä tätä työtä kerralla.,

opetan asiakkailleni, että tuotepäälliköt ylimmän roolit (VPs tai Johtaa Tuotteen tai keskijohdon) keskittyä määritellään visio ja strategia joukkueet perustuu markkinoiden tutkimus, ymmärtää yrityksen tavoitteet ja strategia, ja tarkastelemalla nykytilaa menestys niiden tuotteita. Tuotepäälliköt ilman Scrum-tiimejä tai pienemmillä tiimeillä (esimerkiksi UX-suunnittelija ja yksi kehittäjä) auttavat validoimaan ja edistämään tätä tulevien tuotteiden strategiaa. Kun vahvistamme suunnan, luomme suurempia Scrum-tiimejä näiden ihmisten ympärille ja rakennamme ratkaisuja.,

on tärkeää, että tämä joustavuus on mahdollista myös tiimikoossa tuotteen vaiheesta riippuen. Jos annat Tuotepäällikölle suuren scrum-tiimin Lokin, joka pitää täyttöä discovery-tilassa, he pitävät sen täytettynä. Mutta, ne myös revitään välillä pitää työn virtaa kehittäjille ja yrittää tehdä työtä validoida suuntaan. Tämän seurauksena kumpikaan ei menesty hyvin.

Jos haluat rakentaa tuotteita, jotka tuottavat arvoa yrityksille ja asiakkaille, tarvitaan hyvä Tuote Hallinnan perustan oman yrityksen., Jos haluat uran ihmisiä, sinun täytyy antaa heille tämä perusta, jotta he voivat kasvaa enemmän johtavia rooleja. Muistuta siis väkeäsi, että he ovat kaikki tuotepäälliköitä. He saattavat olla tuotteen omistajan roolissa Scrum-tiimissä useimpina päivinä, mutta tarvitsemme heitä silti ajattelemaan kuin tuotepäällikkö ja vahvistamaan, että rakennamme oikeita asioita.

— —

Melissa Perri on TOIMITUSJOHTAJA Produx Labs, konsultointi, joka auttaa organisaatioita oppimaan ja omaksumaan hyviä Tuotteen Hallinnan ja Tuotteen Johtajuuden käytäntöjä., Hän johtaa tuotepäälliköiden ja TUOTEJOHTAJIEN nettikoulua CPO Acceleratorissa. Hän on luennoitsija Harvard Business Schoolissa.

Tämä oli alun perin lähetetty melissaperri.com