Pod koho by ve firmě měl spadat Product, tedy Product Manageři se svým vedoucím?
Dnes dám na začátek rovnou odpověď: Pokud je váš digitální produkt pro firmu podstatný, pak by produktový šéf měl být přímo pod CEO.
Sám jsem zažil různé set-upy, ale dnes bych se rád pověnoval jednomu, který se vyskytuje častěji: Product spadá pod CTO spolu s vývojem. Myslíte si, že to je dobře, a proč ne? Pojďme to rozebrat:
- Product přináší do hry potřeby a problémy zákazníků, businessový pohled, komunikaci a napojuje je na technické možnosti. Vývoj přináší technický pohled, jak věci zrealizovat a dlouhodobě systémy provozovat.
- Produkt = CO se bude budovat?
- Vývoj = JAK to vybudujeme a budeme provozovat?
- CTO obvykle sám má spíše technický background, ten je na tuto pozici „must“. Když se podíváte na produktovo-vývojové oddělení pod CTO, obvykle tam najdete hlavně téma JAK věci zrealizovat, co nám umožňují naše technické možnosti. Najdete tam silnou pozici refactoringu a napravování architektury systémů. Všechno tohle je důležité, ale stejně důležitá je i zmiňovaná otázka CO budovat.
- Co dělají produkťáci v takovém oddělení? Obvykle jsou vedeni k tomu, aby co nejvíce usnadnili život vývojářům. Píší detailní specifikace. Rozdělují tickety v Jiře tak, aby každý vývojář přesně věděl, co má dnes naprogramovat. Stand-upy často slouží k tomu, že produkťák zadává práci a kontroluje dodané úkoly.
- Důležitější otázkou ale je, co produkťáci v takovém oddělení NEdělají. Obvykle nemluví moc často se zákazníky a pokud ano, nedaří se jim insight dostat do vývoje. Chybí jim často větší kontext cílů, které má firma, a jejich důvodů, spíš jen zachycují požadavky na meetingu a přepisují je do specifikace v Jiře.
Product má být ve firmě také převodní pákou mezi tím, co se děje v businessu, u zákazníků, a tím co se má dít v IT. Aby to Product mohl dobře dělat, musí být co nejblíže informacím, dostávat je z první ruky, nebýt upozaděn. Když upozaděn je, vede to často ke špatnému vzájemnému pochopení mezi businessem a IT vývojem, a poté narůstá nedůvěra a nesoulad – což se snadno transformuje do pouhého zadávání features a termínů, tedy neoptimálního využití IT kapacit.
PS 1: Neměla by nastávat ani opačná situace, kde je vývoj podřízen Productu. Analogicky to vede k silné preferenci CO se bude budovat a upozaďování otázky JAK věci realizovat a provozovat.
PS 2: Někteří z vás možná zažili podobnou situaci, kterou tu dnes popisuji. Někteří z vás ale možná zažili i pozitivní případ, kdy Product pod CTO neznamená mnou popisované problémy. Jsem rád, že i takové případy existují, a třeba tento text pomůže k tomu, aby jich bylo víc. Zapojte se do diskuse!