Jak sestavit produktovou roadmapu ze zpětné vazby zákazníků

Jak sestavit produktovou roadmapu se dá shrnout takto: sesbírejte, o co už zákazníci žádali, seskupte to podle problému za každým požadavkem, skupiny seřaďte podle pravidla, které dokážete vysvětlit, rozhodněte, jak moc jste si u každé jistí, a výsledek zveřejněte ve formátu, který odpovídá tomu, kdo ho čte. Na pořadí záleží. Týmy, které začnou rozvržením a naplní ho nápady, dostanou dokument, který vypadá hotově a nenese žádné důkazy. Týmy, které začnou požadavky, dostanou kratší roadmapu s důvodem za každým řádkem.

Kde začít, když sestavujete produktovou roadmapu?

Začněte důkazy, které už máte, ne prázdnou stránkou. Otevřené požadavky na funkce, konverzace se supportem označené stejnou stížností, poznámky z obchodních hovorů a data o používání vašeho produktu jsou všechno vstupy. Dejte je do jednoho seznamu a u každé položky zapište, odkud pochází.

Požadavky málokdy přijdou v použitelném tvaru. «Přidat integraci se Slackem» a «upozornit tým, když se úkol změní» mohou být stejná potřeba. Proto je dalším krokem seskupování a proto stojí za to mít tracker, který sloučí duplicity; jak na to, popisují duplicitní požadavky na funkce. Pamatujte, že tickety supportu a požadavky na funkce nesou jiný druh signálu a roadmapa postavená jen na jednom z nich se nakloní špatným směrem.

Jak z požadavků vytvořit položky produktové roadmapy?

Seskupte požadavky podle problému, každou skupinu pojmenujte jako výsledek a ponechte počet. Skupina čtrnácti požadavků, které všechny popisují ztrátu filtru po obnovení stránky, se stane jednou položkou: «Zachovat filtr, který jste použili naposledy». Počet jde do sloupce zdroje, takže každý, kdo roadmapu čte, vidí, jakou váhu za ní je.

Výsledek pište slovy zákazníka. «Implementovat perzistenci uložených pohledů» řekne inženýrovi, co postavit, a zákazníkovi nic. Formulace výsledku také vynutí užitečnou otázku: pokud nedokážete říct, co se pro zákazníka změní, možná se díváte na interní úkol, který patří na jiný seznam.

Jak rozhodnout, co půjde první?

Vyberte jedno hodnoticí pravidlo, zapište ho a použijte na každou položku. Nejběžnější je RICE, které hodnotí dosah, dopad, jistotu a pracnost; Intercomův článek o RICE je původní zdroj. Stejně dobře funguje jednodušší pravidlo, pokud ho umíte vysvětlit: počet požadavků vážený tím, zda je žadatel aktivní platící účet, děleno hrubou pracností.

Důležité je, aby pravidlo bylo vyslovené, protože první zákazník, který se zeptá, proč jeho požadavek na seznamu není, bude chtít odpověď. Kde se pravidlo a váš úsudek rozcházejí, napište to do řádku. Prioritizace požadavků na funkce probírá způsoby hodnocení, otázku vážení podle tržeb a co hlasy říkají a neříkají.

Jak moc si jste jistí u každé položky?

Než cokoli zveřejníte, označte každou položku jistotou. Stačí jednoduchá škála o třech hodnotách: závazek znamená, že by tým překvapilo, kdyby to v okně nevyšlo, odhad znamená, že to je plán, pokud se něco nezmění, a zkoumání znamená žádný slib.

Tento jediný sloupec předejde většině škod na roadmapě. Bez něj zákazník čte položku ve zkoumání jako závazek, obchod ji cituje a o čtvrtletí později z toho je stížnost. Esej Martyho Cagana o alternativě k roadmapám přináší podstatný argument: seznam funkcí s daty je seznam odhadů vydávaných za plány a řešením je být výslovný v tom, co víte.

Jaký formát by roadmapa měla mít?

Rozvržení vybírejte jako poslední, podle čtenáře. Zákazníci, kteří se ptají, zda jste je slyšeli, potřebují krátký veřejný pohled. Vedení, které se ptá, proč zrovna tato práce, potřebuje témata nebo výsledky. Tým, který mění směr každý měsíc, se dobře cítí s Now, Next a Later bez dat. Příklady produktové roadmapy ukazují šest formátů s realistickými položkami a jak který selhává, a šablona produktové roadmapy dává pole ke zkopírování, až si vyberete.

Většina týmů skončí se dvěma dokumenty: strategickou roadmapou pro interní čtenáře a zkrácenou veřejnou, která ukazuje jen to, na čem jste ochotní být měřeni. Pokud jednu zveřejňujete, veřejná roadmap popisuje, jak ji řídit štítky na issue, která už sledujete.

Jak roadmapu uchránit před zastaráním?

Dejte každému řádku datum revize a držte roadmapu tam, kde už práce probíhá. Roadmapa upravovaná ručně v samostatném nástroji zastará, protože ji nikdo nemá v denní práci. Pokud každý sloupec odpovídá štítku na issue, roadmapa se změní, když se změní štítek.

Uzavřete smyčku, když se položka vydá. Lidé, kteří o ni žádali, by se to měli dozvědět a obvyklým místem je záznam changelogu; celou cestu popisuje smyčka zpětné vazby zákazníka. Pokud se rozhodnete něco nestavět, řekněte to také. Jasné ne je pro žadatele užitečné a formulace pokrývá odmítnutí požadavků na funkce.

FAQ

Jaké jsou kroky, jak sestavit produktovou roadmapu? Sesbírejte požadavky a data, seskupte je podle problému za každým, seřaďte je podle zapsaného pravidla, označte každou položku jistotou, zvolte formát pro čtenáře a určete datum revize. Začátek u důkazů drží roadmapu krátkou a obhajitelnou.

Na čem by měla být produktová roadmapa založená? Na požadavcích zákazníků, tématech supportu, datech o používání a vaší strategii, v pořadí podle toho, jak často se přeskakují. Roadmapa bez zdroje za řádky je seznam přání.

Jak dlouhé období by produktová roadmapa měla pokrývat? Dost dlouhé, aby bylo užitečné, a dost krátké, aby bylo uvěřitelné. U mnoha malých týmů je to aktuální čtvrtletí podrobně a další jedno nebo dvě jako témata. Cokoli vzdálenější patří pod «later» bez dat.

Kdo by se měl na sestavení produktové roadmapy podílet? Rozhoduje vlastník produktu, vývoj ověřuje proveditelnost a pracnost a support s obchodem dodávají požadavky a témata, která slyší. Zákazníci vidí výsledek ve veřejné verzi, ale neupravují ji.

Technická tvrzení v tomto článku nikdo nezávisle neověřil. Pokud tu něco nesedí, dej nám vědět a opravíme to.

Související na changeloop: Dokumentace pro vývojáře, Příklady changelogu