Když chcete překonat řeku, prostě postavíte most. Uděláte projekt. Jenže – co když problém lidí, kteří žijí na druhém břehu, může vyřešit něco jiného?

Nad rozdíly mezi projektovým a produktovým přístupem se zamýšlí Michal Ličko z tuzemského startupu Productboard, který začátkem nabral obří investici a patří mezi nejrychleji rostoucí české startupy.

***

Jde to ale vůbec, porovnat tyto dva světy? Jsou tak zásadně rozdílné. Nelze přitom říct, že jeden přístup je lepší než ten druhý – každý se totiž hodí na něco jiného. Samozřejmě se také vzájemně doplňují.

Vtip je ve zvolení té správné taktiky pro daný úkol. Což je právě to, v čem drtivá většina českých firem – a nejen těch – chybuje. Pojďme se blíže podívat na to, k čemu je každý z těchto dvou přístupů vhodný a jak je správně používat.

Projektově: rozsah, cena, termín

Projektovým manažerům jde především o dodání nějakého konkrétního výsledku, výstupu. Projekt má většinou pevně daný časový harmonogram, pracovní rozsah, rozpočet a předem zřejmý způsob řešení.

Pro příklad: zadání může znít postavit dům. Dvě patra, podlahová plocha 180 metrů čtverečních, za čtyři miliony korun. Jeho účel? Pohodlné bydlení pro čtyřčlennou rodinu a bernardýna.

Důležité je si uvědomit, že jde o konečnou aktivitu: nějaký tým se za účelem splnění cíle zformuje a po jeho dosažení často zaniká.

Dalším příkladem projektového přístupu mohou být například nejrůznější IT zakázky, především ty veřejné, nebo právní jako GDPR. U nich je přesně, pevně a jednoznačně dopředu dané, jaký má být výsledek, mají přesně daná schvalovací kritéria a tak dále. Není u nich moc prostoru pro vymýšlení, a především kvůli procesním překážkám se nepoužívá produktová strategie.

Pokud ale vyvíjíme něco nového – problém, kterým se ještě nikdo nezabýval, nebo jehož řešení přinejmenším nebylo dobré – od samého začátku a jde nám o to vyřešit ho co nejlépe, projektový přístup příliš vhodný není.

Produktově: proč a co?

Oproti tomu v produktovém managementu primárně řešíme nějaký problém nebo potřebu zákazníka. Na začátku se tak často ani vůbec neví, jak má konečný výstup vypadat, jaké to finální řešení problému bude.

Opět dám jednoduchý příklad. Koukáte se do otevřené lednice a dumáte, co uvařit k večeři. A ne a ne se rozhodnout. Řešení mohou být různá: můžete prostě něco náhodně naházet na pánev, koupit si kuchařskou knihu, sami ji napsat, vytvořit webový portál o vaření nebo rovnou natočit televizní pořad.

Foto: Productboard

Michal Ličko, Engineering Manager v Productboardu

Máte tedy daný problém a hledáte různé způsoby, jak ho vyřešit. Můžete se přitom rozhodnout řešit pouze část tohoto problému nebo konkrétní úhel pohledu, ze kterého na tento problém nahlížíte. Následně se pokoušíte přijít s něčím, co nejlépe naplňuje zvolený cíl, a taková řešení průběžně validovat se zákazníkem.

K tomu se používá například uživatelské testování nebo pohovor se zákazníkem. Hlavním úkolem produktového manažera je dokonale rozumět svým zákazníkům a jejich problémy a potřeby překládat do řešení – proto je průběžná validace se zákazníkem naprosto zásadní.

Naproti tomu, pokud bychom postupovali projektovou metodou, mohlo by se stát, že nalezené řešení, které mohlo být pro zákazníka funkční v době analýzy, nebude na konci už vyhovovat.

Rok práce v tahu

Technologické firmy na to pohříchu často jdou špatně: troufám si říct, že devět z deseti doplácí v první řadě na to, že neznají skutečnou zákazníkovu potřebu nebo velmi dlouhou dobu (někdy i roky) vyvíjejí něco, co ale už dávno neřeší zákazníkův problém. Nebo ne tak úplně. Za tu dobu se totiž posunuly také zákazníkovy potřeby. Výsledkem je zděšení, že dodané řešení nikdo nepoužívá, nebo má daleko menší úspěch, než se čekalo.

Typický scénář? Aniž by se provedla pořádná analýza trhu, někdo řekne, co se bude dělat — protože se domnívá, že to ví. To je takzvaná ZEBRA (z anglického zero evidence but really arrogant). ZEBRA bývá někdo, kdo je ve firmě už hodně dlouho a ostatní se mu neodvažují oponovat. Dalším podobným druhem je HiPPO (highest paid person opinion), v podstatě totéž jako ZEBRA, jen s tím rozdílem, že používá moc plynoucí z hierarchie. A takový člověk také určuje, co se bude dělat.

Anebo jiná situace. Obchodník se vrátí od klienta a říká: „Chtějí, abychom do aplikace přidali takovou a takovou funkci. Díky tomu uzavřeme ohromný obchod.“ Tomu se říká RHINO neboli really high value new opportunity. Podstatou je, že co je dobré pro jednoho konkrétního, byť velkého zákazníka, nemusí vyhovovat ostatním.

Produktový management není zakázkový vývoj – nelze si objednávat funkcionalitu prostřednictvím obchodních zástupců. Co se děje dál? V lepším případě se seznam nápadů seřadí podle priorit. Často pak vývoj odbavuje tento seznam metodou „co položka, to projekt“, která mnohdy trvá rok a déle. Nakonec to s velkou slávou dodají klientovi.

Jenže ten záhy zjistí, že tu funkci vlastně už nevyužije, protože již má jiné potřeby, nebo dojde k tomu, že proces byl špatně nastavený a bylo potřeba ho mezitím upravit.  Výsledkem je požadavek na změnu. Obchodník přijde i podruhé, ale tentokrát se slovy: „Kdybychom tam změnili jen tuhle drobnost, už by jim to vyhovovalo a ten obchod je tutovka.“ Ani tentokrát to ovšem nemusí být naposledy, a tak není divu, že se takový projekt pravděpodobně protáhne. Někdy i několikanásobně.

Produktový manažer na to jde jinak: průběžně zjišťuje potřeby na trhu, zajímá se, co zákazníky trápí a co potřebují, dělá kvantitativní i kvalitativní analýzy. Navrhované řešení přitom může být jen ve fázi prototypu s různou mírou detailu. Zlehčeně řečeno může jít o wireframe (takzvaný low fidelity prototype) nakreslený v kavárně na ubrousek nebo prototyp, který vypadá jako reálná aplikace a jímž se lze proklikat (high fidelity prototype). Co je zde zcela zásadní, je ona zpětná vazba od zákazníka. Ale ne ledajakého.

Důležité je vědět, pro koho funkcionalitu dělám – na čí potřebu odpovídám. Lépe řečeno musím vědět, kdo je můj ideální zákazník neboli ICP (ideal customer profile). Definovat to lze různě: může to být kupříkladu B2B SaaS společnost v Česku nebo na Slovensku s vývojovým týmem o třiceti až padesáti vývojářích a s obratem 150 milionů korun. Myšlenku nebo prototyp pak typicky chceme validovat s největším možným počtem těchto zákazníků.

Produktový manažer se zkrátka snaží znát a dokonale porozumět těm, kteří produkt používají a pro než je určen. Produktový přístup znovu a pořád dokola kontinuálně navrhuje zlepšení a ověřuje, zda jednotlivá vylepšení fungují a přinášejí kýžený užitek. Tedy zda řeší problémy zákazníků.

Dobře vybrat je umění

Když se vrátím k myšlence zmíněné v úvodu – zadáním je překonat řeku. Projektovou metodou tedy „prostě a jednoduše postavíte most“ a hotovo. Lze na to jít ale také inovativně. Protože lidi v podstatě nemusí zajímat, že se díky němu dostanou na druhý břeh řeky. Zajímá je, že se dostanou o půl hodiny rychleji do práce nebo že snadno pěšky dojdou za svou babičkou, která na druhém břehu bydlí

Ale co když je řešením problému postavit na našem břehu továrnu, přestěhovat babičku, nebo investovat do kurzů plavání a naučit lidi přeplavat? Může to znít absurdně, ale pokud by produktový manažer přemýšlel v zažitých vzorcích a stereotypech, nikdy nedojde k inovacím.

Firmy tak často a zbytečně ve svém úsilí a tažení za výsledkem selhávají, protože používají projektový přístup tam, kde se nehodí. Jejich vylepšení (a často to ani vylepšení vůbec není) pak nikdo nepoužívá a všichni jsou překvapení a zklamaní – vždyť před rokem se přece došlo k závěru, že se to používat bude.

Dalším problémem u projektového managementu je, že často jde až na cílový stav – po cestě se nevytvářejí žádné prototypy, a proto to stojí extrémní množství peněz. A to je další výhoda produktového přístupu: rychle a za málo peněz lze poznat, kudy cesta nevede.

Jako poslední příklad uvedu historku z jedné velké české internetové společnosti, v níž jsem dlouhé roky působil. Krásně to ilustruje, jak to dopadá, když se použije projektová metoda v situaci, která přímo volá po produktovém přístupu. Příběh se odehrává v oddělení, které tvoří přes polovinu celého obratu firmy a v němž pracuje zhruba čtvrtina jejích zaměstnanců.

Divize se ze své podstaty vždy orientovala na obchodní výsledky. Což nemusí být nutně špatně. Nápad nebo konkrétní požadavek může vzejít od konkrétního zákazníka, ale to je potřeba potvrdit – zjistit, jestli to chce ještě někdo jiný. V praxi to vypadá tak, že nadšený obchodník přiběhne za business manažerem (v dané firmě jde o obdobu produktového manažera), který si tuto myšlenku zapíše na svůj seznam.

Každý z těchto manažerů má na starosti jednu sekci byznysu, o kterou se stará a kterou rozvíjí. Svůj seznam nápadů prioritizuje často na základě analýz trhu a konkurence. V této fázi to není nic špatného. Vylepšit by se určitě dala měřitelná validace těchto nápadů se zákazníky. Něco jako „chystáme se implementovat tuto funkci, oceníte to?“. Pak dát zákazníkům prostor pro zpětnou vazbu a tu zohlednit v nastavení priorit.

Kámen úrazu však spočívá v něčem jiném. Business manažeři musejí v divizní prioritizaci mezi sebou bojovat o zdroje a velkou roli zde hraje i vliv na okamžitý zisk v aktuálním fiskálním roce. Když už nápad dostane prioritu na divizní úrovni, je naplánován do roadmapy – a zde se dostáváme k jádru problému.

Vývoj není organizován dle skutečných produktů, ale jakýchsi pseudoproduktů, které ale samy o sobě nenesou žádnou obchodní hodnotu a reprezentují spíše technické součásti systému (jako webové stránky, statistiky, backend a podobně). Nezřídka se stává, že to zahrnuje pět i více týmů, které jsou navíc řízeny „produktovými“ manažery (nejblíže připomíná business analytika). Tyto týmy je třeba koordinovat a neustále dohlížet na dodávky závislostí, což je role projektového manažera.

Celý proces je hrozně těžkopádný a dochází ke spoustě kompetenčních sporů a dohadům o to, kdo měl co udělat. Příkladem může být projekt (spíše program) běžící několik let, o jehož obchodním výsledku lze přinejmenším polemizovat (stále nebyl dokončen), spousta projektů, které se vůbec neměly dostat do realizace, a časté změny zadání těsně před dokončením.

Řešením by přitom bylo dát produktovým manažerům prostor pro práci – konkrétní stálé zdroje napříč technologickým spektrem, s jejichž pomocí se pokusí řešit problémy zákazníků v konkrétní oblasti podnikání. Budou moci dělat prototypy, které včas prověří životaschopnost řešení se zákazníkem, a včas se dozvědí, že se dostali do slepé uličky.

Obecně lze říci, že pokud se potřeby zákazníka, potažmo trh, na kterém působí, mění velmi rychle, pak se musí velmi rychle umět adaptovat i samotný proces vývoje funkcionality. Základem je být otevřený změně, akceptovat ji jako žádoucí a neustále se ujišťovat, že stále jdeme po správné cestě.