Feedback klientów trafia do obsługi codziennie, a roadmapa produktu ma ograniczone miejsce. Pomiędzy nimi potrzebny jest krok, który zamienia pojedyncze prośby w opisane problemy, ocenia ich wpływ i sprawdza, czy pasują do celów produktu. Bez tego o kolejności prac decyduje najgłośniejszy klient albo ostatnia rozmowa, którą ktoś pamięta. Ten poradnik dotyczy właśnie tego kroku: przeglądu wielu próśb naraz, a nie oceny jednego zgłoszenia.

Jeżeli zastanawiasz się, czy konkretna wiadomość opisuje usterkę, czy nową potrzebę, zacznij od poradnika błąd czy nowa funkcja. Tutaj zakładamy, że takie kwalifikacje już masz i zebrało się ich kilkadziesiąt.

Grupuj według problemu, nie według proponowanego rozwiązania

Klient zwykle opisuje rozwiązanie, które przychodzi mu do głowy: „dodajcie eksport do Excela”, „potrzebny jest wydruk w PDF”, „połączcie to z programem księgowym”. W fikcyjnej aplikacji do grafików zajęć dla szkół tańca te trzy prośby mogą wynikać z jednej trudności: właściciel szkoły musi przekazać grafik osobie, która nie korzysta z aplikacji. Jeśli policzysz je osobno, każda wygląda na niszową. Policzone razem pokazują wyraźny problem.

Zapisuj więc najpierw sytuację i cel klienta, a dopiero potem jego propozycję. Pytanie „co chcesz zrobić z tym plikiem?” często mówi więcej niż sama nazwa formatu. Propozycję zachowaj, bo bywa trafna, ale nie traktuj jej jako gotowej specyfikacji. Spójny słownik etykiet ułatwia późniejsze liczenie; jak go zaprojektować, opisuje poradnik o tagowaniu rozmów i zgłoszeń.

Grupa nie musi być idealna od pierwszego dnia. Lepiej mieć kilka szerokich problemów z krótkim opisem niż setkę etykiet, z których każda zawiera jedną prośbę. Jeżeli ta sama trudność wraca jako zgłoszenie błędu, a nie prośba o funkcję, przeczytaj o powracających zgłoszeniach klientów, bo tam liczy się wspólna przyczyna, a nie decyzja o rozwoju produktu.

Karta grupy: pięć pól, które wystarczą do rozmowy o priorytecie

Każda grupa potrzebuje krótkiego opisu, który zrozumie osoba nieobecna przy rozmowach z klientami. Poniższa karta to propozycja procesu na fikcyjnym przykładzie, a nie wynik rzeczywistego wdrożenia.

Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.

PoleCo zapisaćFikcyjny przykład
ProblemTrudność klienta własnymi słowami zespołuGrafik trzeba przekazać osobie spoza aplikacji
Kto go maRodzaj klientów i sytuacja, w której się pojawiaWłaściciele szkół przed startem semestru
DowodyPowiązane rozmowy i zgłoszenia, cytaty, obserwacjeProśby o Excel, PDF i program księgowy
Obecne obejścieCo klienci robią dziś i ile ich to kosztujeRęczne przepisywanie grafiku do arkusza
DecyzjaWynik przeglądu, powód i data kolejnego sprawdzeniaDo oceny w następnym przeglądzie

Pole „Dowody” ma zawierać odnośniki do konkretnych rozmów, a nie samą liczbę. Liczba bez kontekstu nie pokaże, czy prosiło dziesięciu różnych klientów, czy jeden klient dziesięć razy. Pole „Obecne obejście” chroni przed przecenianiem: jeśli klienci radzą sobie w dwie minuty, problem może być prawdziwy, ale mniej pilny niż ten, który blokuje im pracę.

Oceń wpływ, pewność i dopasowanie do celów produktu

Porównując grupy, zadaj trzy pytania. Jak bardzo problem utrudnia klientom osiągnięcie celu, dla którego korzystają z produktu? Na ile jesteś pewien, że rozumiesz problem i jego zasięg? Czy rozwiązanie pasuje do kierunku, który zespół już wybrał na najbliższy okres? Grupa, która ma silny wpływ, ale nie pasuje do celów, nie znika, tylko czeka z zapisanym powodem.

Intercom opisuje metodę RICE: zasięg, wpływ i pewność oceny mnoży się, a wynik dzieli przez nakład pracy. Sam autor zastrzega, że wynik nie jest sztywną regułą i bywają powody, by zacząć od projektu z niższą oceną: Intercom: RICE.

Pewność oceny warto obniżyć, gdy grupa opiera się wyłącznie na deklaracjach w stylu „kupilibyśmy, gdybyście to dodali”. Zachowanie klienta, na przykład powtarzane ręczne obejście albo porzucony proces, jest mocniejszym sygnałem niż zapowiedź. Rozmiar klienta lub stanowczy ton to kontekst biznesowy, który można zapisać, ale nie powinien zastępować opisu problemu. Tę samą zasadę stosujemy przy poprawkach strony: jak oceniać pewność według dowodów z nagrań i map ciepła, opisuje poradnik o punktacji ICE dla poprawek UX.

Jakob Nielsen z Nielsen Norman Group (2001) zaleca obserwować, co użytkownicy robią, bo ich deklaracje, także te o tym, czy skorzystaliby z danej funkcji, słabo przewidują rzeczywiste zachowanie. Tekst dotyczy badań użyteczności i nie podaje metody układania roadmapy: NN/g: pierwsza zasada użyteczności.

Regularny przegląd: kolejność działań

Ocena grup nie powinna odbywać się przy każdej nowej wiadomości. Ustal stały rytm, na przykład raz na cykl planowania, i przygotuj materiał przed spotkaniem.

  1. Uporządkuj nowe prośby.Osoba z obsługi przypisuje nowe zgłoszenia do istniejących grup albo zakłada nową grupę z krótkim opisem problemu.
  2. Uzupełnij karty.Przy każdej grupie dopisz nowe dowody i sprawdź, czy obecne obejście nadal działa tak samo.
  3. Porównaj grupy.Zespół produktu ocenia wpływ, pewność i dopasowanie do celów oraz wybiera kilka grup do dalszej pracy.
  4. Zapisz decyzję i powód.Każda omówiona grupa dostaje wynik: do realizacji, do rozpoznania, odłożona lub odrzucona, wraz z jednym zdaniem uzasadnienia.
  5. Przekaż informację obsłudze.Zespół obsługi wie, co odpowiadać klientom i kiedy grupa wróci do przeglądu.

Priorytet na roadmapie to coś innego niż priorytet w kolejce obsługi. Klient może potrzebować szybkiej odpowiedzi na prośbę, która trafi do planu dopiero za kilka miesięcy albo wcale. Kolejność bieżących kontaktów porządkuje poradnik o priorytetach w kolejce zgłoszeń; tutaj oceniasz kolejność zmian w produkcie.

Co odpowiedzieć klientowi, zanim zapadnie decyzja

Klient powinien wiedzieć, że jego prośba została zrozumiana i zapisana, ale nie powinien słyszeć obietnicy, której nikt nie zatwierdził. Zdanie „przekażę to zespołowi, na pewno się pojawi” tworzy zobowiązanie bez właściciela. Lepiej opisać etap i to, co klient może zrobić dziś.

Wzór odpowiedzi

„Dziękuję za opis. Rozumiem, że potrzebują Państwo sposobu na przekazanie grafiku księgowej bez ręcznego przepisywania. Dołączyliśmy tę potrzebę do podobnych próśb, które zespół produktu omawia podczas regularnego przeglądu. Nie mogę dziś obiecać, czy i kiedy pojawi się takie rozwiązanie. Do tego czasu [opisz obejście, które sprawdziłeś na koncie klienta]. Gdy zapadnie decyzja w tej sprawie, wrócę z informacją”.

Gdy prośba dotyczy trwającego projektu realizowanego dla klienta, a nie rozwoju produktu, potrzebny jest inny tryb. Wtedy liczy się uzgodniony zakres i zapisana decyzja, co opisuje poradnik o tym, gdy następuje zmiana zakresu projektu przez klienta. Po decyzji w przeglądzie wróć do klientów powiązanych z grupą, także wtedy, gdy odpowiedź brzmi „nie w tym okresie”. Gotowe wzory odpowiedzi „nie zmienimy tego” i „jeszcze nie, wrócimy w ustalonym terminie” znajdziesz w poradniku o informowaniu klienta o naprawie błędu.

Ślad decyzji w tagach i Projektach Meetlead

W Meetlead możesz oznaczać rozmowy tagami i filtrować skrzynkę po kilku tagach naraz, co ułatwia zebranie dowodów dla jednej grupy. W aplikacji Projekty zadanie można powiązać ze zgłoszeniem, nagraniem i innymi zadaniami, umieścić w backlogu, przypisać do epiku, nadać priorytet i zapisać ustalenia w komentarzach. Epik może odpowiadać jednej grupie problemu.

Powiązania tworzy zespół ręcznie: Meetlead nie grupuje próśb automatycznie, nie liczy wyniku priorytetu i nie publikuje roadmapy klientom. Projekty wymagają konta, aktywnej aplikacji w witrynie i dostępu w planie. Przenosząc wybraną grupę do realizacji, korzystaj z zasad opisanych w poradniku od zgłoszenia do zadania, aby zadanie miało rezultat, właściciela i kryterium zakończenia.

  • Grupa ma opis problemu, a nie tylko nazwę funkcji.
  • Dowody prowadzą do konkretnych rozmów lub zgłoszeń.
  • Zapisano obecne obejście i jego koszt dla klienta.
  • Decyzja z przeglądu ma powód i datę ponownego sprawdzenia.
  • Obsługa wie, co odpowiedzieć klientom z tej grupy.

Pytania o prośby klientów i plan produktu

Czy liczba próśb wystarczy, żeby wpisać funkcję do roadmapy? Nie. Liczba pokazuje zasięg, ale nie mówi o wpływie, pewności ani dopasowaniu do celów. Kilka próśb od klientów, którym problem blokuje kluczową pracę, może ważyć więcej niż wiele próśb o drobne udogodnienie. Zapisuj liczbę razem z dowodami i obecnym obejściem.

Czy klientowi można odpowiedzieć „nie”? Tak, jeśli decyzja zapadła i znasz jej powód. Krótko wyjaśnij, czym zespół zajmuje się w najbliższym okresie, i wskaż dostępne obejście, jeśli istnieje. Uczciwe „nie teraz” z datą kolejnego przeglądu jest lepsze niż ogólne „dziękujemy za sugestię”, po którym klient pyta ponownie za miesiąc.