Vo väčšine produktových tímov je backlog miestom, kde naliehavosť zomiera. Všetko, čo sa doň dostalo, bolo v čase pridania naliehavé — sťažnosť zákazníka, požiadavka od obchodu, funkcia konkurenta, interný nápad. O pol roka neskôr je tam všetko stále, všetko sa stále zdá naliehavé a nikto presne nevie, čo urobiť ako ďalšie.
Problém nie je v nedostatku nástrojov. Existujú desiatky prioritizačných rámcov: RICE, MoSCoW, Kano, ICE, vážené bodovanie. Problém je v tom, že väčšina rámcov vyžaduje druh falošnej presnosti — priraďovanie čísel neznámym veciam — vďaka čomu pôsobia prísne, no v skutočnosti len „preperú“ pocit z brucha cez tabuľku.
To, čo skutočne funguje, je jednoduchšie: dva rozmery, posúdené úprimne, a disciplína konať podľa výsledku.
Prioritizácia sa zredukuje na dve otázky. Prvá: nakoľko to zlepší výsledok, na ktorom nám záleží? (Dopad.) Druhá: koľko nás bude stáť to dodať? (Náročnosť.) Všetko ostatné je buď spresnenie týchto dvoch, alebo rozptyľovanie od nich.
Istota sa niekedy pridáva ako tretí rozmer — „nakoľko sme si istí dopadom?“ — a stojí za to mať ju na pamäti. V praxi však väčšina tímov vie, kedy len hádajú. Disciplína spočíva v tom, že odhad úprimne označíte, nie že ho ohodnotíte na škále 1–5 a vložíte do vzorca.
Ťažké nie je pochopiť mriežku — ale byť úprimný pri jej vypĺňaní. Každý tím má funkcie, ktoré chce vybudovať a ktoré patria medzi „Žrútov času“, no stále sa preraďujú medzi „Veľké stávky“. Rámec funguje len vtedy, ak je tím schopný byť úprimný o dopade.
Dopad je rozmer, ktorý tímy považujú za najťažší na posúdenie, pretože si často vyžaduje predpovedať budúcnosť. Pokušenie je ohodnotiť ho číslom a cítiť sa vedecky. Lepší prístup je kvalitatívny, ale štruktúrovaný.
Pri každej zvažovanej funkcii si polož tri otázky:
Tímy systematicky podceňujú náročnosť. Je to dobre zdokumentované — súvisí to s klamom plánovania a optimistickým skreslením — a je to obzvlášť výrazné pri funkciách, ktoré sa dotýkajú viacerých systémov, vyžadujú koordináciu medzi tímami alebo zahŕňajú schopnosti, ktoré tím ešte nikdy nevytvoril.
Pomáhajú dva postupy. Po prvé, vždy sa najprv opýtaj vývojárov, až potom odhaduj náročnosť, nie naopak. Produktoví manažéri, ktorí náročnosť odhadujú sami, ju takmer vždy podceňujú. Po druhé, použi koncept „neznámych neznámych“ ako explicitný násobiteľ náročnosti. Každá funkcia, ktorá sa dotýka novej časti kódu, API tretej strany alebo používateľského toku, ktorý sa nedávno netestoval, si zaslúži skóre náročnosti 1,5-krát vyššie, než naznačuje zjavná práca.
Väčšina naliehavosti v produktovom backlogu nie je skutočná naliehavosť — je to čerstvosť. Zákazník sa minulý týždeň sťažoval, takže jeho požiadavka pôsobí neodkladne. Konkurent minulý mesiac niečo spustil, takže dohnať ho sa zdá kritické. Čerstvosť však nie je to isté ako dôležitosť a reagovať na čerstvosť je jeden z najspoľahlivejších spôsobov, ako nechať skutočne dôležitú prácu uniknúť.
Praktický test: opýtaj sa sám seba, či by si to stále považoval za naliehavé, keby si sa o tom dozvedel pred šiestimi mesiacmi namiesto minulého týždňa. Ak je odpoveď nie, ide o skreslenie z čerstvosti, nie o strategickú prioritu. Zaznamenaj si to, pokojne to vyhodnoť voči mriežke a odolaj pokušeniu uprednostniť to len preto, že je to čerstvé.
Mriežka nie vždy dá jednoznačnú odpoveď. Dve položky pristanú v tom istom kvadrante s podobným skóre a ty si stále musíš jednu vybrať. V takých prípadoch sú užitočné dve rozhodovacie kritériá: strategické zosúladenie (ktorá ťa viac približuje tomu, kde chceš byť o 18 mesiacov?) a vratnosť (ktorú je ťažšie vrátiť späť, ak je nesprávna?). Uprednostni položku, ktorá je strategicky lepšie zosúladená a lepšie vratná.