Nedávno jsem psal o nekonvenčním způsobu, jakým Airbnb řídí svůj produktový vývoj. Role product managerů je v Airbnb jiná, než je běžné – víc u marketingu, a naopak méně u rozhodování o prioritách (to se děje víc direktivně od vedení firmy).
V produktové komunitě vzbudil tento přístup spoustu užitečné diskuse a v prosinci se vyjádřil i Marty Cagan, autor mnoha konceptů, které dnes v moderním vývoji produktu považujeme za samozřejmé. Podle mě nejzajímavější je tato úvaha:
If you define product management, as I do, as being responsible for the value and viability of what gets built, then there really isn’t an alternative to product management – someone is doing this one way or another.
However, product managers have never been the only way to cover the product management responsibilities, and there are definitely alternatives, some much better than others.
Product management je podle něj o hodnotě a životaschopnosti toho, co se buduje. A o to se ve firmě vždycky někdo stará, vždy o tom někdo rozhoduje, ať kvalifikovaně či nevědomě.
Může to být product manager nebo někdo místo něj. Někdy se této práce chopí vývojář, designér, ale nejčastěji je ve firmách vidět tento model: o hodnotě a životaschopnosti budovaného produktu rozhoduje někdo ze skupiny majitel firmy, CEO, stakeholder nebo business owner (typicky top manažeři). Většinou to funguje nějak takto:
- CEO nebo stakeholders vyberou nové funkce, které se budou vyvíjet v následujícím období, a určí jejich vzájemnou prioritu.
- Pro nové funkce je potřeba zjistit, jak dlouho bude jejich vývoj trvat, aby mohl vzniknout plán s termíny uvedení nových funkcí.
- Priorita se zpřesňuje pomocí business casů – zjednodušeně kolik funkce vydělá vs. kolik bude stát.
- Na základě těchto informací vznikne roadmapa na kvartál, půlrok nebo rok.
- Týmy produktu, designu a vývoje mají za úkol doručit funkce na roadmapě v daném harmonogramu (někdy se humorně označuje jako „lipstick on the pig model“).
Tento model vývoje je docela běžný u nás i v zahraničí, a možná jste v něm poznali i vaši firmu. Podobným způsobem se nakonec ve firmě řídí i mnoho jiných oblastí.
Zajímavé ale je, že mnoho firem, které takto produkty vyvíjí, si stěžují na pomalost vývoje a málo inovací, které se k zákazníkům dostanou. Kde je zakopaný pes?
- Odhad, kolik funkce vydělá/přinese, je obvykle velmi nepřesný. Snažíme se získat přesná čísla na základě mnoha nejistých předpokladů, které jsme si nijak neověřili.
- Odhad, jak dlouho bude vývoj funkce trvat, je ještě víc nepřesný. Obvykle před odhadováním není hotové zadání, design, a tak se doba vývoje funkce může lišit od odhadu o stovky procent.
- Půlka funkcí, které nakonec vyvineme, nebude fungovat tak, jak jsme si představovali. Uživatelé je třeba nebudou využívat, nebudou pokrývat jejich potřeby. Další část vyvinutých funkcí bude potřebovat ještě hodně iterací a ladění, aby měly šanci dosáhnout očekávaných benefitů. (Toto jsou dvě nepříjemné produktové pravdy Martyho Cagana.)
Když to shrnu, produktové inovace jsou většinou hodně komplexní a těžko se odhadují a plánují dopředu. Když se o to někdo pokouší, vznikne poměrně velké riziko, že to nakonec podle odhadu nedopadne – co se týče přínosu, nákladů i času. A ta odchylka není v desítkách, ale obvykle ve stovkách procent. Bohužel se to dozvíte až ve chvíli, kdy je vše vyvinuto, tedy už byly vynaloženy kompletní náklady na funkcionalitu.
Možná se ptáte, co se s tím dá dělat. Můžete zvážit následující:
- Zadávejte produktovým týmům problémy k řešení. Do roadmapy dejte požadované outcomes a metriky, kterými budete sledovat progres. Nezadávejte konkrétní rozsáhlé funkce k implementaci. Nechte na týmech, aby našly efektivní cestu k řešení problému. Díky zapojení produktového, technického a UX pohledu může být problém vyřešen jednodušším způsobem, než se původně zdálo.
- Ověřením předpokladů si snižte riziko neúspěchu dřív, než všechno vyvinete. Snažte se pomocí magických otázek proč? a jak? odhalit, na jakých předpokladech inovace navrhované k vývoji stojí. Co musí platit o zákaznících nebo tržní realitě, aby tato inovace přinesla, co očekáváme? Předpoklady se pak dají více prozkoumat pomocí analytiky a dotazování zákazníků a hlavně ověřit v reálném provozu pomocí prototypů, které vyvinete za zlomek času.
- Mluvení se zákazníky, experimentování, prototypování, analýza dat – toto má být významná součást práce produktového týmu. Každý problém začíná právě tímto, ne hned přípravou zadání a vývojem. Teprve toto je agilní přístup k vývoji produktu.
- Příležitosti a problémy k řešení sbírejte také od produktových týmů (včetně designérů a vývojářů). Díky tomu, že jsou hlouběji v problémech a přichází často do styku se zákaznickými problémy, mohou přinést do hry nový pohled. A taky je práce pak bude víc bavit. (Důležitým zdrojem nápadů je stále ale i management, tedy cesta „shora“.)
Opět malé shrnutí: Dobrá produktová práce vede ke snižování rizika toho, že vyvinete funkcionalitu, kterou vaši uživatelé nebudou používat, vám nic nepřinese, a zároveň na ní strávíte třikrát více času, než jste si mysleli. A to díky hledání a porovnávání více možných řešení problému, levnému ověřování předpokladů pomocí prototypů a zapojení zákaznického a technického pohledu do celého procesu.
A když se vrátím na začátek – produktovou práci může dělat i někdo jiný než product manager. Jen je potřeba zajistit, aby měl kapacitu a schopnosti k tomu, aby ji dělal způsobem popsaným v předchozím seznamu. Firma jinak zbytečně přichází o rychlost a efektivitu vývoje.
Budu rád, když mi dáte vědět, co si o tomto tématu myslíte, případně jaké jsou vaše zkušenosti. Napište mi e-mail nebo se zapojte do diskuse na LinkedIn.