Znamená více funkcí lepší produkt? A jak poznat, kdy nová funkce produkt skutečně zlepší?

U digitálních produktů je velmi snadné zaměnit množství funkcí za množství hodnoty. Konkurence něco přidala, takže to potřebujeme také. Zákazník požádal o novou možnost, tak ji dáme do roadmapy. Obchod slyší určitou námitku, marketing chce další variantu produktu a development má nápad na něco, co by technicky šlo postavit.

Každý jednotlivý požadavek může dávat smysl. O rok později ale máme produkt, ve kterém je dvojnásobek funkcí, nastavení a možností — a který se zároveň používá hůř než předtím.

Tohle je podle mě jedna z největších pastí produktového vývoje. Nová funkce je viditelná, snadno se ukáže v changelogu a dá se odprezentovat zákazníkovi. Dopad na zbytek systému už tak viditelný není. Každá další funkce totiž nepřidává jen to, co sama umí. Přidává nové vztahy, stavy, rozhodnutí, data, edge cases a věci, které musí uživatel i tým pochopit.

A právě proto produkt podle mě neurčuje počet funkcí, ale hlavně to, jak dobře spolu fungují.

Samostatně dobrá funkce může zhoršit celý produkt

Představme si jednoduchou aplikaci pro řízení projektů. Na začátku obsahuje projekty, úkoly, termíny a komentáře. Člověk ji otevře a relativně rychle pochopí, jak má fungovat.

Postupně přidáme vlastní stavy, priority, subtasks, automatizace, vlastní pole, závislosti, time tracking, approvals, dokumenty, dashboardy, cíle, chat, AI asistenta a několik způsobů, jak si vytvořit vlastní view. Každou jednotlivou funkcionalitu dokážeme obhájit. Někdo ji potřebuje a někomu řeší reálný problém. Přesto může být výsledný produkt horší.

Uživatel už neřeší jen svůj projekt. Musí nejdřív rozhodnout, který z několika způsobů organizace má použít. Stejný úkol může být reprezentovaný různými způsoby, nastavení na jednom místě ovlivňuje chování jinde a nový člověk potřebuje dlouhý onboarding jen na to, aby pochopil interní logiku systému.

To neznamená, že komplexní produkty jsou automaticky špatné. Problém nastává ve chvíli, kdy komplexita produktu roste rychleji než jeho schopnost tuto komplexitu organizovat. Čím větší produkt je, tím důležitější je přesně vědět, jakou roli každá nová funkce v celku hraje.

Funkce nestojí jen čas potřebný k implementaci

Když se rozhodujeme, jestli něco postavit, náklady často počítáme hlavně podle první implementace. Designer potřebuje dva dny, vývoj týden a potom pár hodin testování.

Jenže skutečná cena funkce tím nekončí. Musí se dál udržovat, fungovat se všemi relevantními částmi produktu a řešit se u ní oprávnění, mobilní varianta, analytics, loading states, chyby, migrace dat, dokumentace nebo support. Pokud později změníme jinou část systému, musíme přemýšlet i nad tím, jestli jsme nerozbili právě tuhle.

Vlastní cenu navíc platí i uživatel. Musí pochopit, že funkce existuje, k čemu slouží a kdy ji má použít.

Proto podle mě není správná otázka jen „Kolik stojí tuto funkci postavit?“, ale spíš „Kolik nové komplexity přinese do produktu po zbytek svého života?“

Tohle číslo se odhaduje mnohem hůř, a právě proto bývá systematicky podhodnocené.

S každou funkcí nepřibývá jen jedna další věc

Představme si produkt se třemi relativně nezávislými částmi. Rozumět tomu, jak spolu fungují, není těžké. Přidáme čtvrtou, jenže ta nemusí interagovat jen sama se sebou. Může ovlivnit jednu, dvě nebo všechny tři původní části.

S dalšími funkcemi proto neroste pouze jejich počet. Roste i počet možných vztahů mezi nimi.

Dobře je to vidět například na oprávněních. Na začátku aplikace existuje administrator a user. Potom přidáme týmy, vlastní role, guest access, sdílení konkrétního projektu, soukromé úkoly a externí klienty. Najednou už neřešíme jen „přidej možnost sdílet projekt“.

Musíme vědět, jestli guest může vidět soukromý komentář, co se stane s přístupem po přesunutí úkolu do jiného projektu, jestli externí uživatel vidí custom fields a co uděláme ve chvíli, kdy někdo získá přístup dvěma různými cestami.

Samotná funkce mohla být jednoduchá. Její vztah ke zbytku produktu jednoduchý být nemusí. A právě na těchto vazbách podle mě vzniká velká část technického i produktového dluhu.

Uživatel nezažívá jednotlivé features

Organizačně je pohodlné rozdělit produkt na search, checkout, notifications, onboarding, profile nebo billing. Z pohledu vývoje to dává smysl, protože systém nějak strukturovat musíme.

Zákazník ale podobné hranice většinou vůbec nevnímá.

Chce například objednat produkt. To může znamenat projít katalog, vyhledat správnou variantu, otevřít detail, vybrat parametry, přidat zboží do košíku, zkontrolovat dopravu, zaplatit a následně dostat potvrzení. Technicky jde o několik různých funkcí a možná několik částí codebase. Pro zákazníka je to pořád jeden proces.

Pokud každá jeho část funguje perfektně samostatně, ale dohromady je zkušenost nekonzistentní, produkt dobrý není.

Tohle podle mě vysvětluje i část situací, kdy firma přidá požadovanou funkci a výsledky se téměř nezmění. Zákazník totiž možná nepotřeboval další izolovanou schopnost, ale jednodušší cestu k výsledku.

Zákaznický feedback není automaticky roadmapa

Zpětná vazba od zákazníků je extrémně cenná, ale nedělal bych z ní automaticky seznam funkcí k implementaci.

Zákazník přirozeně navrhuje řešení ze svého pohledu. Jeden chce další filtr, jiný export, další vlastní workflow a velký enterprise klient speciální oprávnění. Pokud každému požadavku jednoduše řekneme ano, nemusí vzniknout produkt, který lépe řeší problémy trhu. Může vzniknout součet lokálních požadavků několika nejhlasitějších zákazníků.

Proto mě u nového požadavku zajímá hlavně problém pod ním. Proč to člověk potřebuje? Jak často tato situace nastává? Kolika dalších uživatelů se týká? Existuje jednodušší způsob, jak problém vyřešit? A hlavně: zapadá navržené řešení do logiky produktu, který chceme dlouhodobě stavět?

Někdy z toho vyjde přesně funkce, kterou zákazník navrhl. Jindy zjistíme, že problém lze vyřešit změnou něčeho, co už existuje. A občas je správnou odpovědí prostě ne — ne proto, že zákazníka neposloucháme, ale protože produktový tým musí chránit i kvalitu celku.

Dobrá architektura není jen technická záležitost

Pod architekturou si většinou představíme backend, databázi, služby, dependencies nebo strukturu codebase. Podobný princip ale podle mě existuje i na úrovni samotného produktu.

Produkt potřebuje konzistentní pravidla. Pokud uživatel na jednom místě vytvoří objekt jedním způsobem a na druhém úplně jinak, vytváříme mentální režii. Pokud se stejný koncept na třech místech jmenuje jinak, musí se ho člověk naučit třikrát. A pokud každá nová funkce přináší vlastní pattern, navigaci a způsob ovládání, produkt se začne postupně rozpadat na několik menších aplikací schovaných uvnitř jedné.

Dobrá produktová architektura podle mě znamená, že nové funkce používají existující model produktu tam, kde to dává smysl — stejné objekty, podobná pravidla, konzistentní interaction model a očekávání uživatele.

Díky tomu může produkt získávat nové schopnosti, aniž by člověk musel pokaždé pochopit další miniaturní systém.

Někdy je nejlepší nová funkce odstranění staré

Když přidáme novou funkci, máme co ukázat. Když jednu odstraníme, může to na první pohled působit, že produkt zmenšujeme.

Jenže dlouhodobě může být odstranění jedné špatně používané funkce hodnotnější než přidání několika nových. Každá nepotřebná část produktu zabírá místo nejen v interface, ale také v codebase a v hlavách lidí. Musíme ji podporovat, testovat, vysvětlovat a při každé nové změně rozhodovat, jak se má chovat v kombinaci s ostatními věcmi.

Pokud ji používá minimum zákazníků a nevytváří významnou hodnotu, samotný fakt, že už existuje, není dobrým důvodem ji držet navždy. Samozřejmě je potřeba dávat pozor na funkce, které používá malá, ale kritická skupina zákazníků. Obecný princip ale zůstává:

Roadmapa nemusí obsahovat jen věci, které přidáme. Může obsahovat i věci, které zjednodušíme, spojíme nebo odstraníme.

Produkt se může zlepšovat i tím, že toho umí méně — pokud těch méně věcí funguje výrazně lépe dohromady.

Před další funkcí bych řešil hlavně její místo v celku

Nemám rád checklisty na úplně všechno, ale u nových funkcí mi několik otázek dává smysl.

Nejdřív bych chtěl vědět, jaký problém skutečně řeší a pro koho. Pokud neumíme problém dobře pojmenovat bez popisu samotné funkce, možná začínáme řešením příliš brzo.

Pak bych se podíval na to, co už v produktu existuje. Dokážeme stejného výsledku dosáhnout rozšířením nebo zjednodušením současného workflow, nebo opravdu potřebujeme nový koncept?

Dále mě zajímá dopad na zbytek produktu. S čím bude funkce interagovat, jaká nová pravidla a stavy zavede, co bude muset uživatel pochopit navíc a jaký dlouhodobý maintenance přináší.

A nakonec bych chtěl vědět, jak poznáme, že byla správným rozhodnutím. Ne že jsme ji dokončili, ale že změnila výsledek, kvůli kterému jsme ji stavěli.

Pokud na poslední otázku nemáme odpověď, bude velmi těžké o půl roku později určit, jestli funkce vytváří hodnotu, nebo v produktu zůstala jen proto, že už jednou vznikla.

Feature velocity může být velmi zavádějící metrika

Je příjemné mít pocit, že se produkt rychle posouvá. Každý týden něco nasadíme, roadmapa se plní a changelog roste.

Množství dokončených funkcí ale samo o sobě příliš neříká o tom, jestli je produkt skutečně lepší.

Tým může během čtvrtletí dodat třicet features a vytvořit horší výsledek než tým, který dodal pět. Ten druhý totiž mohl odstranit zásadní friction point, zjednodušit onboarding, zvýšit reliability a opravit jeden workflow, na kterém závisí většina hodnoty produktu.

Development output se měří snadno. Produktová hodnota podstatně hůř. To ale není důvod nahradit ji počtem ticketů.

Podle mě je mnohem zdravější hodnotit změny podle outcome, který mají vytvořit. Dokončená funkce je pouze prostředek.

Dobré produkty mají silné názory

Čím víc možností uživateli dáme, tím flexibilnější produkt teoreticky je. Každá možnost ale zároveň přesouvá další rozhodnutí z product týmu na zákazníka.

Má použít variantu A nebo B? Které nastavení je správně? Jak má workflow nakonfigurovat? Jakou z pěti cest má zvolit?

Někdy je flexibilita skutečně potřebná. Enterprise software bez ní například často fungovat nemůže. U spousty produktů je ale kvalitní default hodnotnější než deset konfigurací.

Dobrý produkt podle mě dokáže říct: „Myslíme si, že většina lidí by to měla dělat takhle.“ A teprve tam, kde je skutečný důvod, umožní pravidla změnit.

Každá volba, kterou můžeme bezpečně udělat za uživatele, je jedna volba, kterou uživatel nemusí řešit sám. Produkt se tím může stát jednodušší, aniž by nutně ztratil schopnosti.

Takže features opravdu nejsou důležité?

Samozřejmě jsou. Bez funkcí produkt nic neumí.

Samotná existence funkce ale nevytváří hodnotu. Tu vytváří až ve chvíli, kdy člověku pomůže dosáhnout výsledku a zároveň nezhorší zbytek produktu natolik, že získanou hodnotu zase ztratíme.

Proto bych o produktu nepřemýšlel jako o seznamu věcí, které umí, ale spíš jako o síti pravidel, workflow a vztahů, které dohromady vytvářejí určitou zkušenost.

Pak se mění i otázka, kterou si před další položkou roadmapy položíme. Ne „Jakou funkci bychom ještě mohli přidat?“, ale „Co musí být v celém produktu jinak, aby uživatel dosáhl výsledku jednodušeji?“

Někdy bude odpovědí úplně nová funkcionalita. Jindy zlepšení toho, co už máme. A někdy zjistíme, že produkt bude lepší právě tehdy, když něco dalšího nepostavíme.

Zdroje

• Len Bass, Paul Clements & Rick Kazman — Software Architecture in Practice
• Philippe Kruchten, Robert L. Nord & Ipek Ozkaya — Technical Debt: From Metaphor to Theory and Practice