”vad är skillnaden mellan en produktägare och en produktchef?”
det är en intressant fråga och en som tar tid att packa upp. Låt oss titta på var dessa termer och discipliner härstammar från och hur några vanliga ramar förklarar dem.,
När jag började min karriär kallades jag en affärsanalytiker. Jag gjorde väldigt lite ”affärsanalys” som vi skulle titta på det i traditionella IT-företag. Ärligt talat gjorde jag väldigt lite av vad jag undervisar som produkthantering nu heller. Jag fick i uppdrag att samla kraven från försäljning, komma med en lösning, utforma den, och sedan skicka specifikationsdokumentet till utveckling som ska byggas.
Jag fortsatte med att kallas en affärsanalytiker som jag arbetade på banker och andra finansiella tjänsteföretag. Jag kallades inte en produktchef förrän jag stack ut ur det och landade i en start., Det var samma arbete som jag hade gjort tidigare, men nu hade det ett annat namn. Jag gillade det här namnet. ”Produktchef” tycktes ha gravitas till det, och när jag tittade på andra tekniska företag i dalen kunde jag se en tydlig karriärväg utskuren för mig medan affärsanalytiker var olika på varje företag.
Jag hade inte hört talas om termen produktägare förrän år senare. Första gången jag hörde ordet frågade jag någon vad det betydde. De sa att det var samma som en produktchef, men det var en term som användes i Scrum., Vi hade använt Scrum i flera år, men jag kallades fortfarande en produktchef, så det faktum att de skulle vara utbytbara var meningsfullt för mig. Jag tänkte sällan på det efter det.
det var tills jag hade min första erfarenhet av att undervisa produkthantering hos ett företag som använder SAFe framework. Jag gjorde en workshop för en mycket stor bank när en av deltagarna chimed in.
”Du lär oss att prata med användare, men jag är produktägare. Produkthanteraren pratar med alla användare och berättar vad kraven är., Jag spenderar all min tid på att skriva användarhistorier ur dessa och arbeta med laget för att utföra lösningen. Jag är förvirrad.”
det här är när jag började gräva i skillnaderna mellan dessa två roller och hur olika filosofier lär dem. För att förstå hur vi kom hit
kan produkthantering spåras tillbaka till 1931. Hewlett Packard var ett av de första tekniska företagen att genomföra detta jobb och organisera sig av produkter tillbaka på 1940-talet., De flesta Silicon Valley-företag har haft produktchefer från början, och många av mina vänner som har arbetat där på 80-talet och 90-talet var verkligen produktchefer. Så denna disciplin är inte ny, men den utvecklas snabbt när fler företag börjar byta till mjukvaruorganisationer och börja strukturera sig kring produkter.
Scrum kom på scenen strax innan det Agila manifestet skrevs 2001. Det introducerade begreppet produktägare. Detta var en person som var en proxy för kunden och skulle berätta för utvecklarna kraven för vad som behövs för att byggas., I början, när många av skaparna av dessa processer arbetade som konsulter i företag, var produktägaren kunden-en intern person i verksamheten som skulle sitta med laget och prioritera eftersläpningen av arbetet. Faktum är att 2017-inlärningsmålen för deras certifierade Scrum-Produktägarcertifiering av Scrum Alliance säger, ” Lär att produktägarens roll vanligtvis spelas av kunden eller kundrepresentanten, till exempel en produktchef.,”
När man tittar på rollen som produktägaren i de flesta Scrum litteratur, deras tre huvudansvar inkluderar följande:
- definiera produkten eftersläpning och skapa angripbara användarhistorier för utvecklingsteam. (Vem skapar användarhistorierna varierar beroende på Scrum-träning)
- brudgummen och prioritera arbetet i eftersläpningen.
- Acceptera de färdiga användarhistorierna för att se till att arbetet uppfyller kriterierna.,
medan läroplanen förändras mellan lärare och organisationer, är det de saker som oftast är inriktade på under de två dagars kurser för att certifiera produktägare. Medan Scrum har mycket information om processer och ritualer om vad man ska göra som produktägare, lämnar det många frågor som är viktiga för att skapa framgångsrika produkter obesvarade. Dessa mestadels centrum runt ”Hur vet vi att vi bygger rätt sak?”
det är här produkthanteringen kommer in., En bra produktchef lärs hur man prioriterar arbete mot tydliga resultatorienterade mål, Hur man upptäcker och validerar verkligt kund-och affärsvärde och vilka processer som behövs för att minska osäkerheten om att produkten kommer att lyckas på marknaden.
utan denna bakgrund i produkthantering kan någon effektivt gå igenom produktägarens roll i Scrum, men de kan aldrig lyckas med att se till att de bygger rätt sak.,
om du tar bort ditt Scrum-team, Om du tar bort Scrum som en process för din organisation, är du fortfarande produktchef. Produkthantering och Scrum fungerar bra tillsammans, men produkthantering är inte beroende av Scrum. Det kan och bör existera med någon ram eller process.
Jag hade nyligen en produktägare vars utvecklare flyttades till en annan del av organisationen kom till mig eftersom de var oroliga att de inte kunde vara en produktperson på detta företag längre. Deras hela identitet till synes gångjärn på att ha ett team av utvecklare.,
som produktchef ändras dina roller och ansvarsområden beroende på ditt sammanhang och produktstadiet. Utan en Scrum team eller med ett mindre team, Du kan göra mer strategi och validering arbete med problem upptäckt i en produkt som inte har definierats ännu. Med ett Scrum-team kan du vara mer fokuserad på utförandet av lösningar. Som chef för produktchefer kan du vara ledande strategi för en större del av produkten och coaching dina lag att upptäcka och utföra bra.,
den säkra ramen lär detta annorlunda, och jag tror att det är en av de svagaste punkterna i hela ramen. I säkra, produktchefer är cheferna för produktägare och ansvarar för externa inför interaktioner och arbete. De talar till kunderna, de definierar kraven och omfattningen av de produkter som ska byggas, och de kommunicerar detta till Produktägarna. Produktägarna är interna, definierar komponenterna i lösningen och arbetar med utvecklare för att skicka den.,
Jag har utbildat dussintals lag som använder SAFe och jag har lärt mig att använda SAFe.jag har aldrig sett det här fungera bra. Produktägarna är kopplade från sina användare och oförmögna att skapa effektiva lösningar för dem som verkligen löser sina problem, eftersom de inte förstår problemen bra., Produktchefer är i huvudsak waterfalling ner kraven för dem och lagen får inte bevisa om dessa är rätt saker att bygga eller inte. Ingen gör valideringsarbete.
Jag har lyssnat på många argument att produktägare inte har tid att göra båda rollerna. I det aktuella sammanhanget är det sant. Produktägare jag talar med spendera 40 timmar i veckan skriva användarhistorier. Vid den tidpunkten måste du fråga dig själv, är dessa användarhistorier ens värdefulla? Vad prioriterar de dem mot? Hur vet de att det kommer att lösa ett problem?,
om du har en person som spenderar så mycket tid på att skriva användarhistorier varje vecka, faller du varje vecka i Byggfällan — koncentrerar dig på mängden objekt du släpper ut och inte kvaliteten.
med en bra strategiram på plats och hänsynslös prioritering kring några viktiga mål kan en person effektivt prata med kunder, förstå sina problem och hjälpa till att definiera lösningarna med laget. Även VD för Scrum.org håller med om detta kan vara fallet, om än det verkar, otroligt., Scrum Inc säger också att produktägaren ska spendera hälften av sin tid med att prata med kunder och hälften arbeta med laget. Jag är inte 100% ombord med denna splittring, men riktningen är bra. Mängden externt vs internt arbete kommer att skifta beroende på mognad och framgång för din produkt. Du borde aldrig göra allt detta arbete på en gång.,
Jag lär mina kunder att produktchefer i ledande roller (VPs eller produktledare eller mellanchefer) koncentrerar sig på att definiera visionen och strategin för lagen baserat på marknadsundersökningar, en förståelse för företagets mål och strategi och genom att titta på det nuvarande läget för framgång för sina produkter. Produktchefer utan Scrum-Team eller med mindre team (till exempel UX-Designer och en utvecklare) hjälper till att validera och bidra till den strategin för framtida produkter. När Vi validerar riktningen skapar vi större Scrum-Team runt dessa människor och bygger ut lösningar.,
det är viktigt att ha denna flexibilitet i lagstorlek samt beroende på scenen av din produkt. Om du ger en produktchef ett stort scrum-lags eftersläpning för att fortsätta fylla när du är i upptäcktsläge, kommer de att hålla den eftersläpningen fylld. Men de kommer också att slits mellan att hålla arbetet flödar till utvecklarna och försöker göra arbetet för att validera riktning. Som ett resultat blir det inte heller bra.
om du vill bygga produkter som skapar värde för dina företag och kunder behöver du bra Produkthanteringsstiftelser i ditt företag., Om du vill ha en karriärväg för ditt folk, måste du ge dem denna grund så att de kan växa till mer ledande roller. Så påminna ditt folk de är alla produktchefer. De kanske spelar rollen som en produktägare på ett Scrum-lag de flesta dagar, men vi behöver fortfarande dem att tänka som en produktchef och validera att vi bygger rätt saker.
— —
Melissa Perri är VD för Produx Labs, ett konsultföretag som hjälper organisationer att lära sig och anta bra produkthantering och Produktledningspraxis., Hon driver en online-skola för produktchefer vid Produktinstitutet och för produktledare på CPO Accelerator. Hon är universitetslektor vid Harvard Business School.
detta skrevs ursprungligen på melissaperri.com