Product Manager vs Product Owner

Het is een interessante vraag en een die tijd kost om uit te pakken. Laten we eens kijken waar deze termen en disciplines vandaan komen en hoe sommige gemeenschappelijke kaders ze verklaren.,

toen ik mijn carrière begon, werd ik een Business analist genoemd. Ik deed heel weinig “business analysis” zoals we zouden kijken naar het in de traditionele IT-bedrijven. Eerlijk gezegd, Ik deed heel weinig van wat ik leer als Product Management nu ook. Ik was belast met het verzamelen van de eisen van de verkoop, het bedenken van een oplossing, het ontwerpen van het, en vervolgens het verzenden van de specificatie document om de ontwikkeling te bouwen.

Ik werd verder Business Analist genoemd omdat ik bij banken en andere financiële dienstverleners werkte. Ik werd geen Product Manager genoemd totdat ik eruit kwam en in een startup belandde., Het was allemaal hetzelfde werk dat ik eerder had gedaan, maar nu had het een andere naam. Ik vond deze naam leuk. “Product Manager” leek te hebben gravitas om het, en toen ik keek naar andere tech bedrijven in de vallei, ik kon zien een duidelijk carrià re pad uitgesneden voor mij terwijl Business analisten waren verschillend bij elk bedrijf.

Ik had pas jaren later van de term producteigenaar gehoord. De eerste keer dat ik de term hoorde, vroeg ik iemand wat het betekende. Ze zeiden dat het hetzelfde was als een productmanager, maar het was een term die gebruikt werd in Scrum., We gebruikten Scrum al jaren, maar ik werd nog steeds productmanager genoemd, dus het feit dat ze uitwisselbaar zouden zijn vond ik logisch. Daarna heb ik er zelden aan gedacht.

dat was totdat ik mijn eerste ervaring had met het onderwijzen van productmanagement bij een bedrijf met behulp van het SAFe framework. Ik was bezig met een workshop voor een zeer grote bank toen een van de aanwezigen inklikte.

” U leert ons om met gebruikers te praten, maar ik ben een producteigenaar. De productmanager praat met alle gebruikers en vertelt ons wat de vereisten zijn., Ik besteed al mijn tijd aan het schrijven van gebruikersverhalen uit deze en het werken met het team om de oplossing uit te voeren. Ik ben in de war.”

Dit is toen ik begon te graven in de verschillen tussen deze twee rollen en hoe verschillende filosofieën hen leren. Om te begrijpen hoe we hier zijn gekomen, kan

Product Management worden getraceerd tot 1931. Hewlett Packard was een van de eerste tech bedrijven om deze taak uit te voeren en zich te organiseren door producten terug in de jaren 1940., De meeste Silicon Valley-bedrijven hebben vanaf het begin productmanagers gehad, en veel van mijn vrienden die daar in de jaren 80 en 90 hebben gewerkt, waren inderdaad productmanagers. Dus deze discipline is niet nieuw, maar het evolueert snel als meer bedrijven beginnen te verschuiven naar software organisaties en beginnen zichzelf te structureren rond producten.

Scrum kwam op het toneel net voordat het Agile manifest werd geschreven in 2001. Het introduceerde het concept van een producteigenaar. Dit was een persoon die een proxy was voor de klant en de ontwikkelaars zou vertellen wat er moest worden gebouwd., In het begin, toen veel van de makers van deze processen werkten als consultants in bedrijven, was de producteigenaar de klant — een interne persoon in het bedrijf die bij het team zat en prioriteit gaf aan de achterstand in het werk. In feite, de 2017 learning objectives voor hun Certified Scrum Product Owner certificering door Scrum Alliance stelt, “leren dat de rol van de eigenaar van het product wordt meestal gespeeld door de klant, of klant vertegenwoordiger, zoals een product manager.,”

als je kijkt naar de rol van de producteigenaar in de meeste Scrum literatuur, zijn hun drie belangrijkste verantwoordelijkheden het volgende:

• Definieer de product achterstand en creëer bruikbare gebruikersverhalen voor de ontwikkelteams. (Wie de gebruikersverhalen maakt hangt af van Scrum training)
• Groom en prioriteer het werk in de backlog.
• accepteer de voltooide gebruikersverhalen om er zeker van te zijn dat het werk aan de criteria voldoet.,

hoewel het curriculum verandert tussen docenten en organisaties, zijn dit de zaken waar de tweedaagse cursussen meestal op gericht zijn om producteigenaren te certificeren. Terwijl Scrum veel informatie heeft over de processen en rituelen van wat te doen als producteigenaar, laat het veel vragen die belangrijk zijn voor het maken van succesvolle producten onbeantwoord. Deze centreren meestal rond ” hoe weten we dat we het juiste ding bouwen?”

Dit is waar het Product Management van belang is., Een goede Product Manager wordt geleerd hoe te prioriteren werk tegen duidelijke resultaat georiënteerde doelen, hoe te ontdekken en valideren echte klant en business waarde, en welke processen nodig zijn om de onzekerheid dat het product zal slagen in de markt te verminderen.

zonder deze achtergrond in Product Management, kan iemand effectief gaan door de bewegingen van de eigenaar van het product rol in Scrum, maar ze kunnen nooit succesvol zijn in het ervoor zorgen dat ze het juiste ding te bouwen.,

Als u uw Scrum team wegneemt, als u Scrum wegneemt als een proces voor uw organisatie, bent u nog steeds een productmanager. Productmanagement en Scrum werken goed samen, maar productmanagement is niet afhankelijk van Scrum. Het kan en moet bestaan met elk kader of proces.

Ik had onlangs een producteigenaar wiens ontwikkelaars naar een ander deel van de organisatie waren verhuisd, die naar mij kwam omdat ze bang waren dat ze niet langer een productpersoon bij dit bedrijf konden zijn. Hun hele identiteit leek te hangen op het hebben van een team van ontwikkelaars.,

als productmanager veranderen uw rollen en verantwoordelijkheden afhankelijk van uw context en de fase van uw product. Zonder een Scrum team of met een kleiner team, je zou kunnen doen meer strategie en validatie werk met probleem ontdekking in een product dat nog niet is gedefinieerd. Met een Scrum team, kunt u meer gericht op de uitvoering van oplossingen. Als manager van productmanagers, je zou kunnen leiden strategie voor een groter deel van het product en het coachen van uw teams om te ontdekken en goed uit te voeren.,

The SAFe framework leert dit anders, en ik denk dat het een van de zwakste punten in het hele framework is. In SAFe zijn productmanagers de managers van producteigenaren en zijn ze verantwoordelijk voor externe interacties en werk. Ze spreken met de klanten, ze definiëren de eisen en reikwijdte van de te bouwen producten, en ze communiceren dit naar de producteigenaren. De producteigenaren zijn intern geconfronteerd, definiëren de componenten van de oplossing, en werken met ontwikkelaars om het te verzenden.,

Ik heb tientallen teams getraind die safe gebruiken en ik heb dit nog nooit goed zien werken. De producteigenaren zijn losgekoppeld van hun gebruikers en niet in staat om effectieve oplossingen voor hen te creëren die hun problemen echt oplossen, omdat ze de problemen niet goed begrijpen., De productmanagers zijn in wezen waterfalling beneden de eisen aan hen en de teams zijn niet toegestaan om te bewijzen of dit de juiste dingen om te bouwen of niet. Niemand doet validatiewerk.

Ik heb veel argumenten gehoord dat producteigenaren geen tijd hebben om beide rollen te vervullen. In de huidige context is dat waar. De producteigenaren die ik spreek met besteden 40 uur per week het schrijven van de gebruiker verhalen. Op dat moment moet je jezelf afvragen, zijn die gebruikersverhalen wel waardevol? Waar stellen ze hun prioriteiten tegenover? Hoe weten ze dat het een probleem oplost?,

als er één persoon is die elke week zoveel tijd spendeert aan het schrijven van gebruikersverhalen, trap je in de Build Trap — waarbij je je concentreert op de hoeveelheid items die je loslaat en niet op de kwaliteit.

met een goed strategisch kader en meedogenloze prioritering rond een paar belangrijke doelen, kan één persoon effectief met klanten praten, hun problemen begrijpen en helpen om de oplossingen met het team te definiëren. Zelfs de CEO van Scrum.org is het ermee eens dat dit het geval kan zijn, zij het naar het schijnt met tegenzin., Scrum Inc zegt ook dat de eigenaar van het Product moet besteden de helft van hun tijd te praten met klanten, en de helft werken met het team. Ik ben niet 100% akkoord met deze split, maar de richting is goed. De hoeveelheid externe vs interne werk zal verschuiven, afhankelijk van de volwassenheid en het succes van uw product. Je zou dit werk nooit in één keer moeten doen.,

Ik leer mijn klanten dat productmanagers in senior rollen (VP ‘ s of product Leads of middle managers) zich concentreren op het definiëren van de visie en strategie voor de teams op basis van marktonderzoek, een begrip van bedrijfsdoelstellingen en strategie, en door te kijken naar de huidige stand van succes van hun producten. De productmanagers zonder Scrum teams of met kleinere teams (bijvoorbeeld een UX ontwerper en een ontwikkelaar) helpen bij het valideren en bijdragen aan die strategie voor toekomstige producten. Zodra we de richting valideren, creëren we Grotere Scrum teams rond deze mensen en bouwen we oplossingen uit.,

Het is belangrijk om deze flexibiliteit in teamgrootte ook afhankelijk van de fase van uw product. Als u een productmanager de achterstand van een groot scrum-team geeft om te blijven vullen terwijl u in de discovery-modus bent, blijft die achterstand gevuld. Maar, ze zullen ook worden gescheurd tussen het houden van het werk stroomt naar de ontwikkelaars en proberen om het werk te doen om richting te valideren. Als gevolg daarvan wordt geen van beide goed gedaan.

Als u producten wilt bouwen die waarde creëren voor uw bedrijven en klanten, hebt u een goede basis voor productmanagement in uw bedrijf nodig., Als je een carrièrepad voor je mensen wilt, moet je ze deze basis geven zodat ze kunnen uitgroeien tot meer senior rollen. Dus herinner uw mensen ze zijn allemaal productmanagers. Ze kunnen de rol van een Product eigenaar spelen op een Scrum team de meeste dagen, maar we hebben nog steeds nodig om te denken als een Product Manager en valideren dat we het bouwen van de juiste dingen.

— —

Melissa Perri is de CEO van Produx Labs, een adviesbureau dat organisaties helpt om goede praktijken op het gebied van productmanagement en productleiderschap te leren en toe te passen., Ze runt een online school voor productmanagers bij Product Institute en voor productleiders bij CPO Accelerator. Ze is hoofddocent aan de Harvard Business School.

Dit was oorspronkelijk geplaatst op melissaperri.com