Produkt Manager vs Produkt Ejeren

det er et interessant spørgsmål, og det tager tid at pakke ud. Lad os se på, hvor disse udtryk og discipliner stammer fra, og hvordan nogle fælles rammer forklarer dem.,

da jeg startede min karriere, blev jeg kaldt en forretningsanalytiker. Jeg lavede meget lidt” forretningsanalyse”, som vi ville se på it i traditionelle IT-virksomheder. Ærligt, jeg gjorde meget lidt af det, jeg underviser som produktstyring nu heller. Jeg fik til opgave at indsamle kravene fra salg, komme med en løsning, designe det, og derefter sende specifikationsdokumentet til udvikling, der skal bygges.

Jeg blev ved med at blive kaldt forretningsanalytiker, da jeg arbejdede hos banker og andre finansielle servicevirksomheder. Jeg blev ikke kaldt en produktchef, før jeg bailed ud af det og landede i en opstart., Det var alt det samme arbejde, jeg havde gjort før, men nu havde det et andet navn. Jeg kunne godt lide dette navn. “Product Manager” syntes at have gravitas til det, og da jeg kiggede på andre tech-virksomheder i dalen, kunne jeg se en klar karrierevej skåret ud for mig, mens forretningsanalytikere var forskellige hos alle virksomheder.

Jeg havde ikke hørt om udtrykket produktejer før år senere. Første gang jeg hørte udtrykket, spurgte jeg nogen, hvad det betød. De fortalte mig, at det var det samme som en produktchef, men det var et udtryk, der blev brugt i Scrum., Vi havde brugt Scrum i årevis, men jeg blev stadig kaldt en produktchef, så det faktum, at de ville være udskiftelige, gav mening for mig. Jeg tænkte sjældent på det efter det.

det var indtil jeg havde min første erfaring med at undervise i produktstyring hos et firma ved hjælp af SAFe frame .ork. Jeg lavede et værksted for en meget stor bank, da en af deltagerne chimede ind.

“Du lærer os at tale med brugere, men jeg er produktejer. Produktlederen taler med alle brugere og fortæller os, hvad kravene er., Jeg bruger al min tid på at skrive brugerhistorier ud af disse og arbejde med teamet for at udføre løsningen. Jeg er forvirret.”

det var da jeg begyndte at grave i forskellene mellem disse to roller og hvordan forskellige filosofier lærer dem. For at forstå, hvordan vi kom her

produktstyring kan spores tilbage til 1931. He .lett Packard var en af de første tech virksomheder til at gennemføre dette job og organisere sig af produkter tilbage i 1940 ‘ erne., De fleste Silicon Valley-virksomheder har haft produktchefer fra starten, og mange af mine venner, der har arbejdet der i 80 ‘erne og 90’ erne, var faktisk produktchefer. Så denne disciplin er ikke ny, men den udvikler sig hurtigt, da flere virksomheder begynder at skifte til soft .areorganisationer og begynde at strukturere sig omkring produkter.

Scrum kom på scenen lige før Agile Manifesto blev skrevet i 2001. Det introducerede begrebet en produktejer. Dette var en person, der var en pro .y for kunden og ville fortælle udviklerne kravene til, hvad der skulle bygges., I de tidlige dage, hvor mange af skaberne af disse processer arbejdede som konsulenter i virksomheder, var produktejeren kunden — en intern person i virksomheden, der ville sidde med teamet og prioritere efterslæbet af arbejdet. Faktisk siger 2017-læringsmålene for deres Certified Scrum Product O .ner-certificering af Scrum Alliance: “Lær at Produktejerens rolle typisk spilles af kunden eller kunderepræsentanten, såsom en produktchef.,”

Når du ser på Produktejerens rolle i de fleste Scrum-litteratur, inkluderer deres tre hovedansvar følgende:

• Definer Product backlog og opret Handlingsrettede brugerhistorier til udviklingsteamene. (Hvem skaber brugerhistorierne varierer afhængigt af Scrum træning)
• brudgom og prioritere arbejdet i Backloggen.
• accepter de udfyldte brugerhistorier for at sikre, at arbejdet opfylder kriterierne.,

mens læseplaner skifter mellem lærere og organisationer, er det de ting, der for det meste er fokuseret på i løbet af de to dages kurser for at certificere produktejere. Mens Scrum har en masse information om processerne og ritualerne for, hvad man skal gøre som produktejer, efterlader det masser af spørgsmål, der er vigtige for at skabe succesrige produkter ubesvarede. Disse er for det meste centreret omkring “hvordan ved vi, at vi bygger den rigtige ting?”

det er her Produktstyringen kommer ind., En god produktchef læres, hvordan man prioriterer arbejde mod klare resultatorienterede mål, hvordan man opdager og validerer reel kunde-og forretningsværdi, og hvilke processer der er nødvendige for at reducere usikkerheden om, at produktet vil lykkes i markedet.

uden denne baggrund inden for produktstyring kan nogen effektivt gennemgå bevægelserne af Product O .ner-rollen i Scrum, men de kan aldrig få succes med at sikre sig, at de bygger den rigtige ting.,

Hvis du tager dit Scrum team væk, hvis du tager Scrum væk som en proces for din organisation, er du stadig en Product Manager. Product Management og Scrum arbejder godt sammen, men Product Management er ikke afhængig af Scrum. Det kan og bør eksistere med enhver ramme eller proces.

Jeg havde for nylig en produktejer, hvis udviklere blev flyttet til en anden del af organisationen, kom til mig, fordi de var bekymrede for, at de ikke længere kunne være en produktperson hos dette firma. Hele deres identitet tilsyneladende hængslet på at have et team af udviklere.,

som produktchef vil dine roller og ansvar ændre sig afhængigt af din kontekst og dit produkts stadie. Uden et Scrum-team eller med et mindre team kan du muligvis udføre mere strategi-og valideringsarbejde med problemopdagelse i et produkt, der endnu ikke er defineret. Med et Scrum-team er du måske mere fokuseret på udførelsen af løsninger. Som leder af produktledere kan du være førende strategi for en større del af produktet og coache dine teams til at opdage og udføre godt.,

den sikre ramme lærer dette anderledes, og jeg synes, det er et af de svageste punkter i hele rammen. I SAFe er produktledere ledere af produktejere og er ansvarlige for eksterne modstående interaktioner og arbejde. De taler med kunderne, de definerer kravene og omfanget af de produkter, der skal bygges, og de kommunikerer dette ned til Produktejerne. Produktejerne er interne overfor, definerer komponenterne i løsningen og arbejder med udviklere for at sende den.,

Jeg har trænet snesevis af teams, der bruger Computer, og jeg har aldrig set denne type arbejde. Produktejere er afbrudt fra deres brugere og ude af stand til at skabe effektive løsninger til dem, der virkelig løser deres problemer, fordi de ikke forstår problemerne godt., Produktcheferne er i det væsentlige vandfald ned kravene til dem, og holdene må ikke bevise, om dette er de rigtige ting at bygge eller ej. Ingen gør validering arbejde.

Jeg har lyttet til mange argumenter om, at produktejere ikke har tid til at udføre begge roller. I den nuværende sammenhæng er det sandt. De produktejere, jeg taler med, bruger 40 timer om ugen på at skrive brugerhistorier. På det tidspunkt skal du spørge dig selv, er disse brugerhistorier endda værdifulde? Hvad prioriterer de dem imod? Hvordan ved de, at det vil løse et problem?,

Hvis du har en person, der bruger så meget tid på at skrive brugerhistorier hver uge, falder du i Byggefælden — koncentrerer dig om mængden af varer, du frigiver, og ikke kvaliteten.

med en god strategiramme på plads og hensynsløs prioritering omkring et par centrale mål, kan en person effektivt tale med kunderne, forstå deres problemer og hjælpe med at definere løsningerne med teamet. Selv administrerende direktør for Scrum.org enig dette kan være tilfældet, omend det ser ud til at være modstræbende., Scrum Inc siger også, at produktejeren skal bruge halvdelen af deres tid på at tale med kunderne og halvdelen arbejde med teamet. Jeg er ikke 100% om bord med denne split, men retningen er god. Mængden af eksternt vs internt arbejde skifter afhængigt af dit produkts modenhed og succes. Du bør aldrig gøre alt dette arbejde på .n gang.,

jeg underviser mine klienter, at Produktet Ledere i ledende roller (VPs-eller Produkt Fører eller mellemledere) koncentrere sig om at definere vision og strategi for de hold, der er baseret på markedsundersøgelser, en forståelse af virksomhedens mål og strategi, og ved at se på den aktuelle succes med deres produkter. Produktcheferne uden Scrum-teams eller med mindre teams (en U. – Designer og en udvikler, for eksempel) hjælper med at validere og bidrage til denne strategi for fremtidige produkter. Når vi har valideret retningen, skaber vi større Scrum-teams omkring disse mennesker og bygger løsninger ud.,

det er vigtigt at have denne fleksibilitet i holdstørrelse også afhængigt af dit produkts fase. Hvis du giver en produktchef et stort scrum-teams backlog for at fortsætte med at udfylde, mens du er i opdagelsestilstand, vil de holde denne backlog fyldt. Men de vil også blive revet mellem at holde arbejdet flydende til udviklerne og forsøge at gøre arbejdet for at validere retning. Som et resultat bliver hverken gjort godt.

Hvis du vil bygge produkter, der skaber værdi for dine virksomheder og kunder, har du brug for gode Produktstyringsgrundlag i din virksomhed., Hvis du vil have en karrierevej for dine Folk, skal du give dem dette fundament, så de kan vokse til mere seniorroller. Så minde dine folk de er alle produktledere. De spiller muligvis rollen som en produktejer på et Scrum-team de fleste dage, men vi har stadig brug for dem til at tænke som en produktchef og validere, at vi bygger de rigtige ting.Melissa Perri er administrerende direktør for Produ.Labs, et konsulentfirma, der hjælper organisationer med at lære og vedtage god produktstyring og Produktledelsespraksis., Hun driver en online skole for produktledere hos Product Institute og for produktledere hos CPO Accelerator. Hun er lektor ved Harvard Business School.

dette blev oprindeligt sendt den melissaperri.com