Kdy se z vývoje stává produktové přemýšlení?

Když jsem začínal programovat, bylo poměrně jednoduché poznat, jestli jsem odvedl dobrou práci. Aplikace fungovala, kód dělal to, co měl, stránka vypadala správně a chyby byly opravené. Výsledek byl do velké míry technický, takže se dal hodnotit technickými kritérii.

Čím víc jsem ale začal pracovat na skutečných produktech, tím méně tahle definice stačila. Můžete postavit technicky kvalitní funkcionalitu, která nikomu nepomůže. Můžete perfektně implementovat zadání, které nikdy nemělo vzniknout. Můžete zrychlit development a zároveň produkt neposunout vůbec nikam.

V určitou chvíli proto přestává být hlavní otázkou „Dokážeme to postavit?“ a začne být důležitější „Má vůbec smysl to stavět?“

Právě někde tady podle mě začíná produktové přemýšlení.

Neznamená přestat řešit technickou kvalitu. Znamená pouze přijmout, že technická kvalita je jedna část výsledku, ne jeho definice. Kód, design nebo infrastruktura mají hodnotu až ve chvíli, kdy společně vytvoří něco užitečného pro uživatele a ekonomicky smysluplného pro firmu.

Hotová práce není automaticky vytvořená hodnota

Ve vývoji se velmi snadno měří output. Kolik ticketů jsme dokončili, kolik funkcí nasadili, jak rychle jsme prošli sprintem nebo kolik práce zbývá v backlogu. Jsou to praktické metriky pro řízení práce, ale samy o sobě nám neříkají, jestli jsme produkt skutečně zlepšili.

Představme si například, že tým tři týdny pracuje na novém onboarding flow. Návrh je hotový, implementace prošla code review, testy jsou zelené a změna je v produkci. Z pohledu delivery je úkol splněný.

Product otázka ale začíná až potom. Dokončilo onboarding více lidí? Dostali se rychleji k první hodnotě produktu? Snížil se počet lidí, kteří proces opustili? Používají následně produkt častěji?

Pokud se nic z toho nezměnilo, můžeme mít perfektně dokončený projekt, který nepřinesl skoro žádný výsledek.

To je podle mě jeden z největších rozdílů mezi projektovým a produktovým pohledem. Projekt má konec. Produkt má výsledek, který chceme dlouhodobě měnit.

Nestačí tedy říct „feature je hotová“. Potřebujeme vědět, co se díky ní mělo změnit a jestli se to skutečně stalo.

Uživatel neplatí za naši implementaci

Developer může strávit několik dní elegantním refaktorem, optimalizací datového modelu nebo vytvořením architektury, na kterou je technicky oprávněně hrdý. Pro člověka na druhé straně produktu ale většina těchto věcí neexistuje.

Uživatel neví, jestli jsme použili PostgreSQL nebo MongoDB. Nezajímá ho, jestli má frontend perfektně oddělené komponenty nebo jakým způsobem jsme vyřešili caching. Zajímá ho, jestli produkt reaguje rychle, neztrácí jeho data a umožní mu bez zbytečného přemýšlení udělat to, kvůli čemu přišel.

To samozřejmě neznamená, že technická rozhodnutí nejsou důležitá. Naopak. Špatná architektura se později může projevit pomalejším vývojem, chybami nebo nespolehlivostí, kterou už uživatel pocítí velmi přímo.

Rozdíl je v tom, že technologie je prostředek k výsledku, ne výsledek samotný.

Stejný princip platí pro design. Krásný interface nemá velkou hodnotu, pokud člověk nepochopí, co má udělat. Marketing může přivést perfektně cílenou návštěvnost, ale pokud produkt nesplní očekávání vytvořené reklamou, nic jsme nevyhráli.

Product thinking podle mě začíná ve chvíli, kdy jednotlivá rozhodnutí přestaneme hodnotit jen podle kvality jejich vlastní disciplíny a začneme je posuzovat podle dopadu na celek.

Největší změna je začít před implementací klást jiné otázky

Čistě technické zadání často začíná řešením.

„Potřebujeme přidat export do Excelu.“

„Přidáme další filtr.“

„Uděláme mobilní aplikaci.“

„Předěláme dashboard.“

Když pracuji pouze jako exekutor zadání, můžu začít řešit, jak danou funkcionalitu implementovat. Při produktovém přemýšlení bych se ale před tím snažil pochopit, odkud požadavek vůbec přišel.

Proč uživatel export potřebuje? Co s daty následně dělá? Je skutečným problémem absence Excelu, nebo to, že současný reporting neumožňuje odpovědět na určitou otázku? Pokud dashboard předěláváme, co je na tom současném špatně? Nevidí člověk potřebnou informaci, nebo ji vidí, ale neví, co podle ní udělat?

Tím se dostáváme z řešení zpátky k problému.

Ne vždy potom zjistíme, že původní návrh byl špatný. Často byl správný. Rozdíl je v tom, že už víme proč ho stavíme, a můžeme podle toho dělat lepší rozhodnutí během realizace.

To je důležité hlavně ve chvíli, kdy narazíme na trade-off. Pokud víme jen „musíme implementovat export“, těžko posoudíme, které jeho části jsou kritické a které mohou počkat. Pokud víme, že zákazník každý pátek potřebuje dostat určité údaje do účetního systému, můžeme hledat několik různých cest, jak stejného výsledku dosáhnout.

Produktové zadání proto podle mě neříká pouze co má vzniknout. Vysvětluje hlavně jaký problém chceme změnit.

Omezení nejsou překážka produktu. Jsou součást rozhodování.

V ideálním světě bychom mohli každému problému věnovat tolik času, lidí a peněz, kolik potřebuje. Reálný vývoj tak ale nefunguje.

Máme omezený rozpočet, kapacitu týmu, čas, technický stack, legacy systém, termíny a často i informace. Product thinking podle mě nespočívá v ignorování těchto omezení, ale právě v práci s nimi.

Řekněme, že máme dvě možnosti. První řešení pokryje 100 % představovaného use case, ale zabere šest týdnů. Druhé vyřeší 80 % problému za čtyři dny a později ho lze rozšířit.

Technicky může být první varianta elegantnější. Produktově ale nemusí být správná, pokud ještě ani nevíme, jestli uživatelé dané řešení opravdu potřebují.

Na druhé straně ani rychlejší varianta není automaticky lepší. Pokud budujeme kritickou část platebního systému nebo něco, co se bude později velmi těžko měnit, může být vyšší počáteční investice naprosto správná.

Proto mám problém s univerzálními radami typu „ship fast“ nebo „build it right“.

Obě mohou být správně.

Produktové rozhodování spočívá právě v posouzení konkrétního trade-offu v konkrétním kontextu.

Jak drahé bude čekat? Jak drahé bude udělat chybu? Jak snadno lze rozhodnutí později změnit? Kolik toho ještě nevíme? Jaká je pravděpodobnost, že tuto část produktu budeme vůbec potřebovat za rok?

Čím víc podobných rozhodnutí člověk dělá, tím víc zjišťuje, že produktový vývoj není hledání technicky nejlepšího řešení. Je to hledání nejlepšího řešení vzhledem k omezením, která máme.

Priorita není pořadí backlogu

Jedna z prvních věcí, kterou jsem si musel uvědomit, je, že skoro všechno může být nějakým způsobem užitečné.

Nová integrace by někomu pomohla. Lepší onboarding by byl příjemný. Refaktor by zrychlil development. Marketing potřebuje lepší tracking. Support by ocenil nový interní nástroj. Zákazníci chtějí další možnosti nastavení.

Kdybychom měli nekonečnou kapacitu, pravděpodobně bychom mohli udělat většinu z toho.

Jenže právě protože ji nemáme, produktová práce je do značné míry práce s opportunity cost. Každé ano jednomu směru je zároveň ne něčemu jinému.

Proto pro mě priorita neznamená pouze seřadit třicet položek backlogu čísly od jedné do třiceti. Znamená být schopný vysvětlit, proč je první věc výrazně důležitější než dvacátá a proč některé položky možná neuděláme nikdy.

To bývá nepříjemné, protože přidávání práce je psychologicky snadné. Odmítnout rozumný nápad jen proto, že existuje důležitější problém, už je těžší.

Dobrá roadmapa podle mě není seznam všeho, co bychom někdy chtěli postavit. Je to série sázek na to, které změny vytvoří v daném okamžiku největší hodnotu.

A stejně jako u každé sázky bychom měli být schopni později zjistit, jestli jsme měli pravdu.

Feedback není finální fáze po vydání

Jednoduchý model vývoje může vypadat jako:

nápad → návrh → implementace → release

Produktově mi ale mnohem víc dává smysl:

problém → hypotéza → řešení → pozorování → další rozhodnutí

Release v takovém modelu není konec práce. Je to chvíle, kdy konečně získáváme kvalitnější informace.

Do té doby pracujeme z velké části s předpoklady. Předpokládáme, že lidé problém mají, že naše řešení pochopí, že ho budou používat a že změna ovlivní chování způsobem, který očekáváme.

Po nasazení můžeme část těchto předpokladů porovnat s realitou.

To neznamená, že každý produkt potřebuje obrovskou analytickou infrastrukturu a A/B test pro každou změnu. Zpětná vazba může být kvalitativní i kvantitativní. Analytics, support tickety, rozhovory, recordings, obchodní data nebo prostě pozorování člověka při používání produktu mohou odhalit různé části stejného problému.

Důležité je, aby informace nezůstaly jen jako zajímavost.

Pokud něco měříme, ale výsledky nemění naše další rozhodnutí, nevytvořili jsme feedback loop. Vytvořili jsme dashboard.

Skutečný feedback loop musí mít cestu zpátky do produktu.

Metrika je užitečná jen tehdy, když víme, co podle ní uděláme

S produktovým thinkingem velmi rychle přichází touha všechno měřit. To je většinou dobře, ale i metriky se mohou stát další formou outputu.

Můžeme mít dashboard s padesáti čísly a stále netušit, jestli se produkt zlepšuje.

Proto se snažím u metriky přemýšlet hlavně nad dvěma otázkami:

Co nám toto číslo říká o hodnotě produktu?

a

Jaké rozhodnutí bychom změnili, pokud se pohne?

Pokud například měříme počet registrací, ale byznys vydělává až ve chvíli, kdy člověk začne produkt pravidelně používat, samotný signup může být velmi slabý indikátor výsledku.

Stejně tak „počet vytvořených projektů“ může v jedné aplikaci reprezentovat aktivaci, zatímco v jiné je prakticky bezcenný.

Metrika musí být svázaná s modelem toho, jak produkt vytváří hodnotu.

A právě tady mi přijde produktové myšlení zajímavé. Není to jen schopnost podívat se na data. Je to schopnost vytvořit hypotézu o vztahu mezi změnou produktu, chováním uživatele a obchodním výsledkem — a potom ji ověřovat.

Jednodušší produkt často vyžaduje více přemýšlení

Když jsem byl na začátku, jednoduchost pro mě znamenala hlavně méně práce.

Čím méně funkcí a obrazovek produkt měl, tím rychleji se dal postavit.

Postupně mi ale jednoduchost začala připadat důležitější i z druhé strany. Každá věc, kterou uživatel nemusí pochopit, konfigurovat nebo rozhodnout, snižuje friction.

To neznamená všechno z produktu odstranit. Znamená to přemýšlet, které části komplexity musí skutečně nést uživatel a které můžeme vyřešit za něj.

Vývojář má někdy tendenci vystavit interní strukturu systému přímo do interface. Máme šest typů objektu, takže vytvoříme šest sekcí. Backend podporuje deset stavů, takže je všechny ukážeme. Systém umožňuje dvacet konfigurací, takže zákazníkovi dáme dvacet přepínačů.

Technicky je to transparentní.

Produktově tím ale můžeme přenést naši vlastní komplexitu na člověka, který o ni vůbec nestojí.

Dobré produktové rozhodnutí proto někdy znamená schovat flexibilitu, vybrat rozumný default nebo dokonce omezit počet možných cest.

Ne proto, že uživateli nechceme dát kontrolu, ale protože možnost rozhodovat má také vlastní cenu.

Product thinking není role v organizační struktuře

Product manager samozřejmě může být člověk, který velkou část těchto rozhodnutí koordinuje. Nemyslím si ale, že produktové přemýšlení patří pouze jemu.

Developer, který rozumí problému zákazníka, dokáže navrhnout lepší technické řešení než developer, který vidí pouze ticket. Designer, který zná obchodní model, může lépe posoudit, které friction stojí za odstranění. Marketér, který rozumí produktu, dokáže přivádět vhodnější zákazníky a zároveň přinést zpět informace o trhu.

Čím menší tým je, tím důležitější podle mě tahle schopnost je. Není dost lidí na to, aby každý řešil jen velmi úzkou část reality a všechny vazby mezi nimi držel jeden product manager.

Neznamená to, že všichni rozhodují o všem. Specializace i jasná odpovědnost zůstávají důležité.

Ale člověk, který rozumí proč za svojí prací, má výrazně větší šanci udělat správné rozhodnutí ve chvíli, kdy zadání narazí na realitu.

A ono na ni narazí skoro vždycky.

Co se tedy změní, když začneme přemýšlet produktově?

Největší změna podle mě není v procesu ani v nástrojích. Je v definici dobře odvedené práce.

Nestačí, že jsme něco postavili správně.

Musíme se zajímat, jestli jsme postavili správnou věc, jestli ji lidé dokážou používat a jestli přinesla výsledek, kvůli kterému vznikla.

To postupně mění otázky, které si během práce klademe.

Místo „Je feature hotová?“ řešíme „Změnila něco?“

Místo „Co dalšího přidáme?“ přemýšlíme „Který problém je teď nejdůležitější?“

Místo „Jaké je technicky nejlepší řešení?“ se ptáme „Jaký trade-off je správný vzhledem k tomu, co dnes víme?“

A místo toho, abychom release považovali za konec práce, používáme ho jako další zdroj informací.

Kód tím samozřejmě nepřestává být důležitý. Ani design, infrastruktura nebo engineering discipline.

Jen dostanou širší kontext.

Protože cílem digitálního produktu není vytvořit co nejvíc softwaru.

Je jím vytvořit co nejvíc hodnoty pomocí softwaru.

A právě tenhle rozdíl pro mě nejlépe vystihuje moment, kdy se z čistého vývoje začíná stávat produktové přemýšlení.

Zdroje

• Marty Cagan — Inspired: How to Create Tech Products Customers Love
• Don Norman — The Design of Everyday Things