Manager de Produs vs Product Owner

este o întrebare interesantă și una care necesită timp pentru a despacheta. Să ne uităm de unde provin acești Termeni și discipline și cum le explică unele cadre comune.,

când mi-am început cariera, am fost numit analist de afaceri. Am făcut foarte puțină „analiză de afaceri”, așa cum ne-am uita la ea în companiile IT tradiționale. Sincer, am făcut foarte puțin din ceea ce predau ca Management de produs acum. Am fost însărcinat cu colectarea cerințelor din vânzări, a veni cu o soluție, proiectarea acesteia și apoi expedierea documentului de specificație către dezvoltarea care urmează să fie construită.

am continuat să fiu numit analist de afaceri în timp ce lucram la bănci și alte companii de servicii financiare. Nu am fost numit manager de produs până când nu am scăpat de asta și am aterizat într-o pornire., Era aceeași lucrare pe care o făcusem înainte, dar acum avea un nume diferit. Mi-a plăcut acest nume. „Product Manager” părea să aibă gravitas să-l, și când m-am uitat la alte companii de tehnologie din Vale, am putut vedea o cale clară de carieră sculptate pentru mine în timp ce analiștii de afaceri au fost diferite la fiecare companie.

nu auzisem de termenul de proprietar de produs decât ani mai târziu. Prima dată când am auzit termenul, am întrebat pe cineva ce înseamnă. Mi-au spus că a fost la fel ca un manager de produs, dar a fost un termen folosit în Scrum., Am fost folosind Scrum de ani de zile, dar am fost încă numit un manager de produs, astfel încât faptul că acestea ar fi interschimbabile sens pentru mine. M-am gândit rar la asta după aceea.asta a fost până când am avut prima mea experiență de predare a managementului produselor la o companie care utilizează cadrul sigur. Făceam un atelier pentru o bancă foarte mare când unul dintre participanți a intrat.

„ne învățați să vorbim cu utilizatorii, dar eu sunt proprietarul produsului. Managerul de produs vorbește cu toți utilizatorii și ne spune care sunt cerințele., Îmi petrec tot timpul scriind povești despre utilizatori din acestea și lucrând cu echipa pentru a executa soluția. Sunt confuz.”

atunci am început să cercetez diferențele dintre aceste două roluri și modul în care filosofiile diferite le învață. Pentru a înțelege cum am ajuns aici

managementul produselor poate fi urmărit până în 1931. Hewlett Packard a fost una dintre primele companii de tehnologie care a implementat acest loc de muncă și s-a organizat pe produse în anii 1940., Cele mai multe companii din Silicon Valley au avut manageri de produse de la început, și mulți dintre prietenii mei care au lucrat acolo în anii 80 și 90 au fost într-adevăr, manageri de produse. Deci această disciplină nu este nouă, dar evoluează rapid pe măsură ce tot mai multe companii încep să se transforme în organizații software și să înceapă să se structureze în jurul produselor.

Scrum a apărut pe scenă chiar înainte ca Manifestul Agile să fie scris în 2001. Acesta a introdus conceptul de proprietar de produs. Aceasta a fost o persoană care a fost un proxy pentru client și le-ar spune dezvoltatorilor cerințele pentru ceea ce trebuia construit., În primele zile, când mulți dintre creatorii acestor procese lucrau ca consultanți în companii, Proprietarul Produsului era clientul — o persoană internă din afacere care să stea cu echipa și să acorde prioritate restanțelor de muncă. De fapt, obiectivele de învățare 2017 pentru certificarea proprietarului produsului Scrum certificat de către Scrum Alliance afirmă: „învățați că rolul proprietarului produsului este de obicei jucat de client sau de reprezentantul clientului, cum ar fi un manager de produs.,”

când te uiți la rolul proprietarului produsului în majoritatea literaturii Scrum, cele trei responsabilități principale ale acestora includ următoarele:

• definiți întârzierea produsului și creați povești de utilizator acționabile pentru echipele de dezvoltare. (Cine creează poveștile utilizatorilor variază în funcție de formarea Scrum)
• mire și prioritiza munca în restante.
• acceptați poveștile de utilizator completate pentru a vă asigura că lucrarea îndeplinește criteriile.,în timp ce curriculum-ul se schimbă între profesori și organizații, acestea sunt lucrurile pe care se concentrează în cea mai mare parte în timpul cursurilor de două zile pentru a certifica proprietarii de produse. În timp ce Scrum are o mulțime de informații cu privire la procesele și ritualurile de ce să facă ca un proprietar de produs, lasă o mulțime de întrebări care sunt importante pentru crearea de produse de succes fără răspuns. Acestea se concentrează mai ales în jurul „De unde știm că construim ceea ce trebuie?”

  aici intervine managementul produsului., Un Manager de Produs bun este învățat cum să acorde prioritate lucra împotriva clar rezultatul orientat pe obiective, cum pentru a descoperi și a valida client real și valoarea afacerii, și ce procese sunt necesare pentru a reduce incertitudinea că produsul va reuși în piață.fără acest context în managementul produselor, cineva poate trece în mod eficient prin mișcările rolului proprietarului produsului în Scrum, dar nu poate avea niciodată succes în a se asigura că construiesc ceea ce trebuie.,

  dacă eliminați Echipa Scrum, dacă eliminați Scrum ca proces pentru organizația dvs., sunteți în continuare Manager de produs. Managementul produselor și Scrum funcționează bine împreună, dar managementul produselor nu depinde de Scrum. Poate și ar trebui să existe cu orice cadru sau proces.am avut recent un proprietar de produs ai cărui dezvoltatori au fost mutați într-o altă parte a organizației să vină la mine pentru că erau îngrijorați că nu mai pot fi o persoană de produs la această companie. Întreaga lor identitate pare să se bazeze pe o echipă de dezvoltatori.,în calitate de manager de produs, rolurile și responsabilitățile dvs. se vor schimba în funcție de contextul și stadiul produsului dvs. Fără o echipă Scrum sau cu o echipă mai mică, s-ar putea să faceți mai multe lucrări de strategie și validare cu descoperirea problemelor într-un produs care nu a fost încă definit. Cu o echipă Scrum, este posibil să vă concentrați mai mult pe execuția soluțiilor. Ca manager al managerilor de produs, s-ar putea să conduceți strategia pentru o parte mai mare a produsului și să vă instruiți echipele să descopere și să execute bine.,

  cadrul sigur învață acest lucru diferit și cred că este unul dintre cele mai slabe puncte din întregul cadru. În SAFe, managerii de produse sunt managerii proprietarilor de produse și sunt responsabili pentru interacțiunile și munca cu care se confruntă exteriorul. Vorbesc cu clienții, definesc cerințele și domeniul de aplicare al produselor care urmează să fie construite și comunică acest lucru proprietarilor de produse. Proprietarii de produse se confruntă intern, definesc componentele soluției și lucrează cu dezvoltatorii pentru a le livra.,

  

  M-am antrenat zeci de echipe care sunt utilizați în condiții de Siguranță și nu am văzut niciodată acest lucru bine. Proprietarii de produse sunt deconectați de la utilizatorii lor și incapabili să creeze soluții eficiente pentru ei care să-și rezolve cu adevărat problemele, deoarece nu înțeleg bine problemele., Managerii de produse sunt, în esență, waterfalling în jos cerințele pentru a le și echipele nu au voie să dovedească dacă acestea sunt dreptul de lucruri pentru a construi sau nu. Nimeni nu face munca de validare.am ascultat multe argumente că proprietarii de produse nu au timp să facă ambele roluri. În contextul actual, este adevărat. Proprietarii de produse cu care vorbesc petrec 40 de ore pe săptămână scriind povești despre utilizatori. În acel moment, trebuie să vă întrebați, sunt acele povești ale utilizatorilor chiar valoroase? Împotriva cui le acordă prioritate? De unde știu că va rezolva o problemă?,dacă aveți o persoană care petrece atât de mult timp scriind povești despre utilizatori în fiecare săptămână, în fiecare săptămână, cădeți în capcana construirii — concentrându-vă pe cantitatea de articole pe care le eliberați și nu pe calitate.cu un cadru de strategie bun și o prioritizare nemiloasă în jurul câtorva obiective cheie, o persoană poate vorbi eficient cu clienții, înțelege problemele lor și poate ajuta la definirea soluțiilor cu echipa. Chiar și CEO-ul Scrum.org este de acord că acest lucru poate fi cazul, deși, se pare, begrudgingly., Scrum Inc mai spune că proprietarul produsului ar trebui să-și petreacă jumătate din timp vorbind cu clienții și jumătate lucrând cu echipa. Nu sunt 100% la bord cu această împărțire, dar direcția este bună. Cantitatea de muncă externă vs internă se va schimba în funcție de maturitatea și succesul produsului dvs. N-ar trebui să faci toată munca asta deodată.,îi învăț pe clienții mei că managerii de produs în funcții de conducere (VPs sau leaduri de produs sau middle manageri) se concentrează pe definirea viziunii și strategiei pentru echipe pe baza cercetării de piață, a înțelegerii obiectivelor și strategiei companiei și a analizării stării actuale de succes a produselor lor. Managerii de produs fără Echipe Scrum sau cu Echipe mai mici (un Designer UX și un dezvoltator, de exemplu) ajută la validarea și contribuie la acea strategie pentru produsele viitoare. Odată ce validăm direcția, creăm Echipe Scrum mai mari în jurul acestor oameni și construim soluții.,este important să aveți această flexibilitate și în dimensiunea echipei, în funcție de stadiul produsului dvs. Dacă oferiți unui manager de produs o întârziere mare a echipei scrum pentru a continua să completați în timp ce vă aflați în modul de descoperire, acesta va păstra completarea. Dar, ele vor fi, de asemenea, rupte între menținerea muncii care curge către dezvoltatori și încercarea de a face munca pentru a valida direcția. Ca rezultat, nici nu se face bine.dacă doriți să construiți produse care să creeze valoare pentru afacerile și clienții dvs., aveți nevoie de fundații bune de gestionare a produselor în compania dvs., Dacă doriți o cale de carieră pentru oamenii dvs., trebuie să le oferiți această fundație pentru a putea crește în roluri mai înalte. Amintește-le oamenilor tăi că toți sunt manageri de produse. Este posibil ca aceștia să joace rolul unui proprietar de produs într-o echipă Scrum în majoritatea zilelor, dar mai avem nevoie de ei să gândească ca un manager de produs și să valideze că construim lucrurile potrivite.Melissa Perri este CEO al Produx Labs, o companie de consultanță care ajută organizațiile să învețe și să adopte bune practici de management al produselor și de conducere a produselor., Conduce o școală online pentru managerii de produse la Product Institute și pentru liderii de produse la CPO Accelerator. Este lector senior la Harvard Business School.

  Acest lucru a fost postat inițial pe melissaperri.com