Ce este un manager de produs tehnic, oricum?

ce înseamnă cu adevărat să fii manager de produs” tehnic”? Și cum este diferit de doar un manager de produs? În această postare, împărtășesc diferența dintre aceste titluri plus cheie Do și nu pentru a vă ajuta să reușiți ca Manager de produs tehnic.

este posibil să fi observat multe variații ale titlului postului de manager de produs. Unele companii au manageri de produs strategici, în timp ce altele au titluri de Manager de produs legate de verticale specifice industriei, de exemplu, manageri de produse de comerț electronic și manageri de produse energetice. Printre companiile de software, veți vedea adesea titlurile Product Manager, Product Development Manager și Technical Product Manager. Dar care este diferența, oricum?

în realitate, termenul Manager de produs tehnic descrie o persoană, nu un rol. Mai exact, descrie un manager de produs care are un fundal tehnic și lucrează la un produs tehnologic. Nu descrie un manager de produs care trebuie să îndeplinească efectiv sarcini tehnice, cum ar fi proiectarea și codificarea software-ului. Același lucru este valabil și pentru un manager de dezvoltare a produselor. De fapt, nu dezvoltă produsul—îndeplinesc un rol de management al produsului în strânsă coordonare cu o echipă de dezvoltare Software.

pe scurt, pentru ca o companie să obțină cea mai mare valoare din rol, managerii de produse trebuie să se concentreze pe managementul produselor, nu pe dezvoltare. Dar unii manageri de produs trebuie să înțeleagă tehnologia companiei la un nivel profund și să interacționeze cu echipa de dezvoltare pentru a conduce cu succes strategia pentru produs. Companiile pot alege să numească acești oameni” manageri Tehnici de produs” pentru a atrage candidatul potrivit.

în opinia mea, abilitățile tehnice sunt unul dintre cei patru piloni ai conducerii produsului. Un manager de produs priceput în tehnologie are avantaje uriașe, cum ar fi:

• comunicare îmbunătățită (și încredere) de la echipa de dezvoltare.
• abilitatea de a înțelege tendințele tehnologice, de a vedea modul în care acestea influențează foaia de parcurs și modul în care acestea conduc inovația.
• comunicare îmbunătățită cu clienții dvs., de exemplu atunci când vorbiți cu CIO și CTO.
• abilitatea de a înțelege provocările tehnice și de a face compromisuri educate cu echipa ta.

cu toate acestea, prea des, managerii de produse tehnice își concentrează aceste abilități valoroase pe încercarea de a crea soluția tehnică pentru produsul lor, mai degrabă decât să rezolve nevoile de afaceri și de utilizator ale clientului lor țintă.

din această perspectivă, să ne uităm la cheie Do și nu pentru managerii de produse tehnice.

Manager de produs tehnic Do ‘ s:

1. Concentrați-vă pe partea de afaceri a rolului.

indiferent de industrie sau verticală, întreaga idee din spatele managementului de produs este de a conduce viziunea și execuția unui produs. Este responsabilitatea noastră să aducem pe piață produse pe care utilizatorii le doresc, care rezolvă o nevoie de afaceri și care generează profit pentru companie. Sunt întotdeauna fascinat să văd tehnologii care își lansează noua companie cu un produs care este o implementare tehnică foarte inteligentă, dar nu rezolvă nicio nevoie reală a clienților. Inutil să spun că aceste companii rareori se descurcă bine pe piață.

accentul unui manager de produs (tehnic sau nu) ar trebui să fie să înțeleagă de ce au nevoie utilizatorii și să lucreze cu toate departamentele necesare pentru a aduce produsul la viață. În acest sens, managerul de produs tehnic este un rol de afaceri cu un anumit accent pe tehnologie, spre deosebire de un rol de tehnolog, fără responsabilitate pentru succesul pe piață al produsului.

2. Folosiți-vă abilitățile tehnice pentru a îmbunătăți prioritizarea și planificarea.

dacă aveți o înțelegere clară a modului în care este construit produsul dvs., atunci puteți evalua riscul anumitor caracteristici sau puteți obține o senzație mai exactă despre durata poveștilor sau a sarcinilor. Deoarece sunteți capabil să comunicați cu echipa de dezvoltare mult mai detaliat, puteți înțelege implicațiile anumitor decizii și puteți face compromisuri în ceea ce privește complexitatea, profunzimea sau chiar termenele.

prin demonstrarea conducerii tehnice, veți putea câștiga rapid încrederea echipei dvs. de dezvoltare și va fi mai probabil să vă susțină în deciziile dure care necesită schimbări riscante, prioritizarea erorilor sau chiar negocierea temutei „datorii tehnice.”

3. Folosiți-vă abilitățile tehnice pentru a reduce decalajul de comunicare dintre inginerie și restul lumii.

persoanele cu medii tehnice uită de obicei că aproape nimeni altcineva nu înțelege (sau îi pasă) de detaliile tehnice. Aceasta este o oportunitate perfectă pentru managerul de produs tehnic de a-și folosi abilitățile pentru a traduce între inginerie și alte departamente, inclusiv Vânzări, Marketing de produse și client.

de asemenea, managerii de produse tehnice sunt adesea angajați pentru a conduce produse care se adresează unui public foarte tehnic, cum ar fi API-uri, instrumente de dezvoltare, software IT etc. În aceste cazuri, caracteristicile produsului, poziționarea produsului și mesageria trebuie să rezoneze cu un public foarte tehnic. Aceasta este o altă oportunitate perfectă de a vă valorifica abilitățile tehnice pentru a comunica cu publicul dvs., pentru a primi feedback (în limba lor) și pentru a ajuta la încheierea unei tranzacții vorbind cu personalul tehnic al clientului.

Manager de produs tehnic nu ‘ s

1. Nu proiectați / soluționați singur produsul.

aceasta este o sursă cheie de confuzie în cadrul rolului de manager de produs tehnic. Mulți manageri de produse care provin din inginerie au dificultăți în a-și părăsi zona de confort și își dau seama că valoarea lor se află acum într-o zonă diferită. Acestea se concentrează pe definirea soluției tehnice pentru o anumită caracteristică în loc să definească rezultatul așteptat al utilizatorului sau valoarea afacerii. Ei petrec mai mult timp vorbind cu arhitecții lor și uitându-se peste umerii dezvoltatorilor, decât vorbind cu clienții și vânzările.

acest lucru cauzează probleme pe două fronturi:

1. echipa de dezvoltare se simte frustrată, deoarece detaliile soluției le sunt transmise doar de către PM. Ei nu au șansa de a proiecta și proiecta soluția, care este o mare parte a muncii lor, nu a ta.
2. cea mai mare parte a timpului PM este petrecut în detaliile tehnice, astfel încât nu mai este timp pentru planificarea și înțelegerea clientului.

pe scurt, această abordare nu adaugă valoare dezvoltatorilor, proprietarilor de afaceri sau produsului în sine. Chiar și managerii de produse tehnice trebuie să fie asociați cu clienți potențiali tehnici puternici sau manageri de dezvoltare care pot conduce aceste sarcini. Motto-ul meu este: „faptul că poți, nu înseamnă că ar trebui.”

când scrieți caracteristici și povești, concentrați-vă pe problema pe care doriți să o rezolvați și pe persoana pe care o vizați. Definiția ar trebui să includă o diagramă de flux a soluției (din perspectiva utilizatorului), inclusiv criteriile de acceptare. Nu ar trebui să fie o explicație detaliată a plasării fiecărui pixel, actualizări ale modelului de obiect sau modificările necesare ale tabelelor bazei de date.

2. Nu luați livrabile care nu sunt de gestionare a produselor.

multe companii (în special cele cu un proces de produs mai puțin matur) se gândesc la managerul de produs tehnic ca la o extensie a echipei de dezvoltare. Am văzut multe fișe de post care enumeră responsabilitățile obișnuite (foaie de parcurs, viziune, definiția caracteristicilor etc.), plus Responsabilități de dezvoltare, cum ar fi scrierea codului real, efectuarea testării QA, scrierea documentației etc. Pentru mine, acest lucru arată doar o mare neînțelegere a valorii rolului, iar aceste situații ar trebui evitate cu orice preț.

3. Nu vă lăsați prinși în Agile sau în orice metodologie utilizați.

sunt mereu uimit de cantitatea de discuții pe care o văd online despre Agile și managementul produselor. Deși înțeleg de ce-multe PMs tehnice provin din dezvoltare, așa că rămânerea extrem de implicată în fluxul agil de zi cu zi se simte foarte confortabil pentru ei.

cu toate acestea, realitatea este că Agile este o parte foarte mică a rolului managerului de produs. Concentrarea prea mult pe Agile poate fi de fapt un prejudiciu atunci când ia timp departe de responsabilitățile PM de bază, cum ar fi interacțiunea cu clienții și vânzările și definirea foii de parcurs.

pentru a atenua volumul de muncă, sunt un mare susținător al faptului că diferiți oameni îndeplinesc rolurile de manager de produs și de proprietar de produs. Această abordare este controversată și ar putea fi posibilă numai în companiile cu un proces de produs mai matur. Indiferent, cred că există o mare valoare în această separare pentru a vă asigura că niciun aspect al ciclului de viață al dezvoltării produsului sau al gestionării produsului nu cade prin fisuri, din cauza unui PM suprasolicitat.

pentru a obține o imagine mai bună a tuturor responsabilităților unui manager de produs, vă sugerez să analizați cadrele PM, cum ar fi cele de la Pragmatic Marketing și SiriusDecisions.

în rezumat

diferite companii au diferite titluri de gestionare a produselor și responsabilități în funcție de tipul lor de produs. Dar, indiferent, sarcina de bază a unui manager de produs este de a oferi viziunea produsului, de a crea foaia de parcurs și de a conduce execuția acestuia.

adăugarea cuvântului „tehnic” la titlu este utilă în postările de locuri de muncă pentru a evidenția nevoia de fundal tehnic. Dar, odată ajuns la locul de muncă, cheile succesului sunt aceleași ca și pentru fiecare manager de produs—menținerea concentrării asupra clienților, conducerea unei viziuni și asigurarea faptului că produsul satisface nevoile pieței.

acesta este un post de invitat scris de Daniel Elizalde, autorul construirii managerului: cele mai bune practici & inspirație pentru managerii de produse & lideri.