Jak zbudować roadmapę produktu na podstawie feedbacku

Jak zbudować roadmapę produktu, sprowadza się do tego: zbierzcie to, o co klienci już prosili, pogrupujcie to według problemu stojącego za każdą prośbą, uszeregujcie grupy regułą, którą potraficie wyjaśnić, ustalcie, jak bardzo jesteście pewni każdej, i opublikujcie wynik w formacie dopasowanym do czytelnika. Kolejność ma znaczenie. Zespoły, które zaczynają od układu i wypełniają go pomysłami, dostają dokument wyglądający na skończony, za którym nie stoją żadne dowody. Zespoły, które zaczynają od próśb, dostają krótszą roadmapę z uzasadnieniem przy każdym wierszu.

Od czego zacząć budowę roadmapy produktu?

Zacznijcie od dowodów, które już macie, a nie od pustej kartki. Otwarte prośby o funkcje, rozmowy z supportem oznaczone tą samą skargą, notatki z rozmów handlowych i dane o użyciu waszego produktu to wszystko materiał wejściowy. Włóżcie to do jednej listy i zapiszcie, skąd pochodzi każda pozycja.

Prośby rzadko przychodzą w użytecznym kształcie. “Dodajcie integrację ze Slackiem” i “powiadamiajcie mój zespół o zmianie zadania” mogą być tą samą potrzebą. Dlatego następny krok to grupowanie i dlatego warto mieć system, który scala duplikaty; opisują to duplikaty próśb o funkcje. Pamiętajcie też, że zgłoszenia supportu i prośby o funkcje niosą różne rodzaje sygnału, a roadmapa zbudowana tylko z jednego z nich pochyli się w złą stronę.

Jak zamienić prośby w pozycje roadmapy produktu?

Pogrupujcie prośby według problemu, nazwijcie każdą grupę jako rezultat i zachowajcie liczbę. Grupa czternastu próśb, które opisują utratę filtra po odświeżeniu, staje się jedną pozycją: “Zachowaj filtr użyty ostatnio”. Liczba trafia do kolumny źródła, więc każdy czytający roadmapę widzi, jaki ciężar za nią stoi.

Rezultat piszcie słowami klienta. “Zaimplementuj trwałość zapisanych widoków” mówi inżynierowi, co zbudować, a klientowi nic. Sformułowanie w postaci rezultatu wymusza też użyteczne pytanie: jeśli nie umiecie powiedzieć, co zmienia się dla klienta, możliwe, że patrzycie na wewnętrzne zadanie, które należy do innej listy.

Jak zdecydować, co idzie pierwsze?

Wybierzcie jedną regułę punktacji, zapiszcie ją i stosujcie do każdej pozycji. Najpopularniejsza jest RICE, która ocenia zasięg, wpływ, pewność i nakład pracy; tekst Intercom o RICE to oryginalne źródło. Równie dobrze działa prostsza reguła, jeśli umiecie ją wyjaśnić: liczba próśb, ważona tym, czy proszący jest aktywnym płacącym kontem, podzielona przez zgrubny nakład pracy.

Liczy się to, żeby reguła była jawna, bo pierwszy klient, który zapyta, dlaczego jego prośby nie ma na liście, będzie chciał odpowiedzi. Gdy reguła i wasz osąd się rozmijają, napiszcie to w wierszu. Priorytetyzacja próśb o funkcje omawia metody punktacji, kwestię ważenia przychodem i to, co głosy mówią, a czego nie.

Jak bardzo jesteście pewni każdej pozycji?

Oznaczcie każdą pozycję pewnością, zanim cokolwiek opublikujecie. Wystarczy prosta skala z trzech wartości: zobowiązanie oznacza, że zespół byłby zaskoczony, gdyby nie wydał tego w tym oknie, prognoza oznacza, że to plan, o ile nic się nie zmieni, a badanie oznacza brak obietnicy.

Ta jedna kolumna zapobiega większości szkód, jakie wyrządzają roadmapy. Bez niej klient czyta pozycję “badamy” jak zobowiązanie, sprzedaż ją cytuje, a kwartał później jest z tego reklamacja. Esej Marty’ego Cagana o alternatywie dla roadmap przedstawia podstawowy argument: lista funkcji z datami to lista domysłów podana jako plany, a lekarstwem jest jawność co do tego, co wiecie.

Jaki format powinna mieć roadmapa?

Układ wybierajcie na końcu, według czytelnika. Klienci pytający, czy ich usłyszano, potrzebują krótkiego widoku publicznego. Zarząd pytający, po co ta praca, potrzebuje tematów lub rezultatów. Zespół zmieniający kierunek co miesiąc dobrze czuje się z Now, Next i Later bez dat. Przykłady roadmapy produktu pokazują sześć formatów z realistycznymi pozycjami i to, jak każdy zawodzi, a szablon roadmapy produktu daje pola do skopiowania, gdy już wybierzecie.

Większość zespołów kończy z dwoma dokumentami: strategiczną roadmapą dla czytelników wewnętrznych i okrojoną publiczną, pokazującą tylko to, z czego jesteście gotowi się rozliczać. Jeśli publikujecie taką, publiczna roadmapa opisuje, jak sterować nią etykietami na zgłoszeniach, które już śledzicie.

Jak nie dopuścić, by roadmapa się zestarzała?

Dajcie każdemu wierszowi datę przeglądu i trzymajcie roadmapę tam, gdzie już toczy się praca. Roadmapa aktualizowana ręcznie w osobnym narzędziu starzeje się, bo niczyja codzienna praca jej nie obejmuje. Jeśli każda kolumna odpowiada etykiecie na zgłoszeniu, roadmapa zmienia się razem z etykietą.

Zamknijcie pętlę, gdy pozycja wychodzi. Osoby, które o nią prosiły, powinny się dowiedzieć, a wpis w changelogu jest zwykle właściwym miejscem; opisuje to pętla feedbacku klienta. Jeśli zdecydujecie, że czegoś nie zrobicie, też to powiedzcie. Jasne “nie” pomaga osobie, która prosiła, a sformułowania omawia odrzucanie próśb o funkcje.

FAQ

Jakie są kroki, jak zbudować roadmapę produktu? Zbierzcie prośby i dane, pogrupujcie je według problemu za każdą, uszeregujcie zapisaną regułą, oznaczcie każdą pozycję pewnością, wybierzcie format dla czytelnika i ustalcie datę przeglądu. Start od dowodów utrzymuje roadmapę krótką i obronną.

Na czym powinna opierać się roadmapa produktu? Na prośbach klientów, tematach z supportu, danych o użyciu i waszej strategii, w kolejności tego, jak rzadko się je pomija. Roadmapa bez źródła za wierszami to lista życzeń.

Jak długi okres powinna obejmować roadmapa produktu? Na tyle długi, by była przydatna, i na tyle krótki, by dało się jej uwierzyć. Dla wielu małych zespołów to bieżący kwartał ze szczegółami i jeden lub dwa następne jako tematy. Wszystko dalsze należy pod “later”, bez dat.

Kto powinien uczestniczyć w budowie roadmapy produktu? Właściciel produktu decyduje, inżynieria ocenia wykonalność i nakład pracy, a support i sprzedaż dostarczają prośby i tematy, które słyszą. Klienci widzą wynik w wersji publicznej, ale jej nie edytują.

Twierdzenia techniczne w tym artykule nie zostały niezależnie zweryfikowane. Jeśli coś się nie zgadza, daj nam znać, a poprawimy to.

Powiązane w changeloop: Dokumentacja dla deweloperów, Przykłady changeloga