Dejte si pozor, zda si agilními frameworky nekřivíte roli produkťáka

Na téma Product Owner (PO) versus Product Manager (PM) toho bylo napsáno už hodně, ale zjevné implikace nepochopení role PO zřejmě pořád jasné nejsou. Pokusím se je tedy v tomto článku přiblížit.

Zkuste se na chvíli zamyslet, čím tráví nejvíc času váš produkťák a jak máte organizované týmy kolem vašich produktů. Máte na každý tým jednoho PO se svým Backlogem a samostatným týmem? Každý tým dělá na nějaké komponentě, ale byznysových produktů máte jen pár? Řešíte mezi takovými týmy hodně závislostí a nerovnoměrné vytížení? Je PO ten, kdo je ve středu těchto diskuzí a většinu času tráví v delivery?

Pokud odpovídáte “spíše ano”, udělejte si následující rychlý test:

• kdo rozhoduje o produktu a o tom, co se bude vyvíjet?
• může toto rozhodnutí váš Product Owner (PO) nějak ovlivnit?
• kdo rozhoduje o strategickém směřování produktu?
• kdo mluví primárně s klienty?
• kdo ověřuje domněnky a potřeby v pozadí požadavků, které se na tým chrlí?
• vlastní PO produktový budget (na tým, experimenty, výzkumy, cestování za klienty)?

Co vám vyšlo? Je váš produkťák většinu času s klienty, ve strategických a discovery diskuzích? Má významnou rozhodovací pravomoc? Nebo tato témata řeší a rozhoduje spíše management, obchod, někdo nad produkťákem nebo nějaké projektová komise? Pokud to druhé, je váš produkťák bohužel koordinační a projektová než produktová role, a zde je ukrytý problém.

Product Owner je jen sada kompetencí v agilním frameworku

PO role, jak je popsána v agilních frameworcích, je sada VYBRANÝCH produktových kompetencí a činností, které jsou důležité z pohledu daného frameworku. Nejedná se o kompletní výčet kompetencí a činností produkťáka, ani o popis práce specifické pracovní pozice. Proč? Protože většina těchto frameworků řeší primárně (ne nutně výlučně) delivery část celého komplexního vývojového procesu. Tyto frameworky NEJSOU záměrně zaměřenyna strategické činnosti, neřeší sběr a zjišťování potřeb, jejich validaci a pochopení. Nejsou zaměřeny na validaci požadavků, které se na vás sypou z mnoha zdrojů. Neřeší, jak efektivně validovat nápady bez kódování a podobně.

Proto je logicky PO role, jak je popsaná v záměrně cílených frameworcích, pouze omezený pohled na komplexnější práci pozice produkťáka. Takto popsanou sadu kompetencí by měl z pohledu agilního frameworku a produktového managementu NĚKDO vykonávat. Tím někým je už často existující pozice ve firmě, ne nutně nově vytvořená pozice. Product Owner je tedy jen definice kompetencí z pohledu agilního frameworku, nejde o ucelenou pracovní pozici v celé její šíři. Produkťák toho v praxi dělá totiž výrazně více:

• má pravomoc rozhodovat o produktu, může v různých situacích a kontextech říkat NE,
• řeší strategii produktu v kontextu ekosystému firmy i jeho byznys model,
• je v častém kontaktu s klienty,
• je odpovědný za discovery a tráví těmito činnostmi hodně času,
• měří a vyhodnocuje dopady a přínosy produktu,
• typicky vlastní i produktový budget (nejen ten na chlebíčky a team building).

Ve firmách, kde role PM není, jsou tímto skutečným produkťákem spíše následující pozice:

• Tribe Lead,
• Head of Product,
• Business Owner,
• Product Marketing,
• případně Sales nebo Business Analyst (což není moc dobré :)).

Pokud je PO konkrétní pracovní pozice dle zúžené definice agilního frameworku, pak se stává spíše sekretářkou Backlogu a projekťákem. Taková pozice má tedy mnohem blíže k projektovému managementu, který však má v samořízených týmech přebírat a řešit vícero rolí podle kontextu, ne jedna pozice, jeden člověk. Tímto modelem totiž odebíráte delivery odpovědnost lidem v týmu.

Pokud primárně vykonáváte rozhodnutí jiných a trávíte většinu času koordinací delivery, nejste produkťák a nejde o produktovou roli.

Kdo tedy skutečně řeší produktový management?

Pak je klíčovou otázkou, kdo je tedy u vás ve firmě skutečný produkťák? Ví o tom vůbec? Ví, co má dělat? Má na to dovednosti, kompetence a hlavně prostor?

Pokud o tom daný člověk neví, nemá na to prostor, kompetence ani čas, pak máte zaděláno na velký problém. Produktový management totiž nedělá nikdo, do produktu kecá každý se svým osobním názorem a výsledkem je paskvil, který se neprodává nebo moc nefunguje. Chybí pak také odpovědnost za výsledek. Byznys pozice obviňují delivery část, že problém je jejich nepochopení byznysu a pomalé doručení. Delivery část s PO v čele zase tvrdí, že produkt obchod a marketing neumí prodat nebo se hájí nejasným (rozuměj typicky žádným) zadáním, mnoha paralelními prioritami, výraznými změnami v čase apod. Dostaneme tedy přesný opak spolutvorby a spolupráce na produktu.

V tomto stavu můžeme mít prsty i my, co propagujeme agilní řízení, tedy agilní kouči, Scrum masteři apod. Někdy nevysvětlíme celý kontext práce produkťáka a nadšeně popisujeme jen danou část z frameworku, jako by byla to nejdůležitější. Někdy nám může chybět povědomí o tom, co má dobrý produkťák dělat, jak funguje, jak zapojuje tým a stakeholdery.Mohou proto vznikat zavádějící agilní interpretace produkťáka právě jen na omezený pohled dle definice PO ve Scrumu či v jiném agilním frameworku. Důsledkem tohoto zúžení může být snaha PO a týmu ladit delivery něčeho, co třeba vůbec nemá existovat (nevhodně navržený produkt řešící nezajímavou potřebu) nebo má produkťák řešit primárně jiné věci, které ale záměrně agilní frameworky nepopisují.

Nejhorší anti-pattern

Další příčinou tohoto stavu je také škálování modelu, který fungoval v rámci malé firmy nebo malého produktového týmu. V takovém týmu vznikla přirozeně pozice produkťáka, který skutečně řešil aspekty produktového managementu v celé šíři od strategie a identifikace potřeb, přes discovery a delivery kroky až po měření a vyhodnocování přínosů. Jak ale rostl produkt i firma, tak jsme začali kopírovat tento model na každý další nově přidaný tým:

Jeden tým = jeden Product Owner (PO) se svým vlastním Backlogem, ale produkt to není!

Co se však stane, když produkt jako celek doručuje více týmů a každý má svého PO se svým vlastním backlogem? Mluví spolu dostatečně? Kdo má pod palcem celkový pohled na produkt (produktovou vizi, strategii a architekturu řešení)? Kdo řeší protichůdná rozhodnutí a názory jednotlivých POs? Potkávají se POs mezi sebou vůbec? Daří se jednotlivé části produktu, které jsou vyvíjené zvlášť, integrovat? Fungují pak bez problémů dohromady? Toto téma více rozepíši v dalším článku. Více je řešíme také v rámci našich Fragmentů produktového managementu.

Posledním důvodem chybějícího produktového managementu ve firmě je chybějící fokus člověka, který má produkt vlastnit. Často roli produkťáka zastává někdo, kdo má vyšší managerskou roli, jako jsou Tribe Leads, Business Owners nebo naopak někdo v první úrovni managementu typu Team Lead nebo Liniový Manažer. Tyto pozice mají primárně jiné úkoly, často buď strategické nebo naopak provozní a na produktovou práci jim nezbývá čas. I kdyby čas měli, často neví, že jsou za produkt odpovědní. Mohou jim také chybět zmíněné dovednosti a znalosti.

Bohužel jsem ten “projektový PO”, co s tím můžu dělat?

Pokud jste spíše ten projektový PO, snažte se více zapojit do těch dalších klíčových aktivit produktového managementu, které nejsou popsány agilními frameworky v záměrně zúžené roli PO. Může jít o následující kroky a aktivity:

• zkuste se spolu s dalšími POs dostat blíže k rozhodování o tom, co se bude v produktu dělat (společně s vaším managerem, Tribe Leadem, Business Ownerem nebo Product Marketingem),
• snažte se dostat k zákazníkům, abyste s nimi mohli začít pravidelně mluvit, například jako doprovod obchodníka na schůzce nebo jako přísedící na supportu,
• společně s designérem a zástupci vývoje (tech lead, senior dev) zkuste začít dělat alespoň nějakou discovery (základní data, výzkum od stolu, rozhovor s pár klienty) ideálně napříč vícero týmy daného produktu,
• používejte zjištění a data z této discovery v komunikaci s vedením, vývojovým týmem, obchodem a argumentujte, pokud si myslíte něco jiného (zase i společně s dalšími POs, dataři a jinými rolemi),
• snažte se dostat k datům o dopadu a přínosech produktu. Ukazují, jak si stojíte?
• začněte tato data využívat pro hodnocení nápadů na nové funkce produktu,
• snažte se podle reálných přínosů ovlivnit další činnosti kolem produktu včetně nových funkcí,
• zkuste také alespoň přibližně vyčíslit náklady na tým a použijte je pro argumentaci projektových investic: opravdu se tento náklad na projekt byznysově vyplatí?
• snažte se díky těmto poznáním ovlivnit vizi a strategii produktu, i když je vlastní a řeší někdo jiný.

Pokud je to jen trochu možné, zkuste vytvořit společně s dalšími POs produktovou vizi, strategii a ideálně i společný backlog. Nad nimi se pak potkávejte a společně bavte. Dohromady tím vytvoříte aspoň virtuálního produktového manažera 🙂

Pokud můžete, snažte se také zvědomit danému člověku v jiné roli, že má i produktovou odpovědnost a začněte to společně řešit. Můžete si vymezit a rozdělit kompetence, či se dokonce začít bavit o změnách organizačního designu týmů a předefinování rolí a pozic.

Ale hlavně nečekejte, že někdo jiný to má zkusit či dělat za vás nebo vám má kroky schvalovat!Lidé na výše popsaných pozicích často neví, že oni jsou tím skutečným produkťákem. Někdy neví, jak tu práci dělat, nemají na ni prostor a budou za vaši pomoc jen a jen rádi.

Buďte aktivní, experimentujte, noste první verze a uvidíte sami.

Budu rád, pokud posdílíte své zkušenosti v komentářích.