To są notatki z prezentacji Hermance N’dounga, Product Manager w Atlassian, wygłoszonej na #mtpcon London. Wszystkie przedstawione tu przemyślenia, obserwacje i strategie pochodzą bezpośrednio z jej wystąpienia.

TL;DR

Stary system feature trackerów w Atlassian doprowadził do absurdów – klienci świętowali 15-lecie swoich requestów tortem na Twitterze
Feedback rotation: 4 PM-ów rotacyjnie przez tydzień odpowiada na wszystkie kanały feedbacku, co daje pełną wiedzę o produkcie i skraca czas discovery do 5 minut
Lighthouse users (6-10 wybranych klientów) uczestniczą w każdym etapie tworzenia feature’a – od problemu przez prototyp po beta testing
PM-owie w zespole są mierzeni wyłącznie po CSAT >75% – nie po liczbie feature’ów, budżecie ani terminach
Rezultat: CSAT 86% (konsekwentnie >82% od 3 lat) i najszybciej rosnący produkt w całym Atlassian
Transparentna komunikacja przez roadmapy, publiczne ogłoszenia i szczegółowe artykuły zamyka pętlę feedbacku
Milestony są dyktowane przez feedback – jeśli jest 41 insightów na MVP i tylko 1 na milestone 3, zespół się zatrzymuje

Kiedy customer centricity to tylko puste słowo

N’dounga zaczyna swoją prezentację od fundamentalnego pytania: jak osiągnąć prawdziwą customer centricity w firmie z ponad 20 produktami? Przez ostatnią dekadę Atlassian miał na to rozwiązanie – publiczny feature request tracker. Każdy mógł tam zalogować się (lub nawet bez logowania) i stworzyć request dla dowolnego produktu. Alternatywnie użytkownicy mogli upvotować istniejące propozycje.

Brzmi demokratycznie, jednak system kompletnie nie działał.

Tort urodzinowy dla 15-letniego feature requesta

Szczyt tej „customer centricity” przyszedł, gdy klient stworzył tort urodzinowy i opublikował go na Twitterze. Świętował 15. rocznicę swojego feature requesta, który wciąż czekał w kolejce. Ta anegdota doskonale ilustruje, jak bardzo dotychczasowy model zbierania feedbacku był zepsuty. Właśnie ta sytuacja stała się katalizatorem głębokiej zmiany w zespole Jira Product Discovery.

N’dounga wymienia trzy fundamentalne problemy:

Brak kontekstu – Użytkownicy zostawiali jedno zdanie bez wyjaśnienia use case’u. Czasem z powodów bezpieczeństwa nie mogli opisać pełnego problemu, dlatego pojedyncza linijka tekstu niewiele mówiła PM-owi.
Chaos głosów – Feedback od anonimowych użytkowników miał taką samą wagę jak feedback od CTO dużej firmy. Jak ujmuje to N’dounga: „Głos CTO był równie ważny jak głos Hermance próbującej zaplanować swój ślub w Trello.”
Nieskończona lista priorytetów – Zawsze był pierwszy, drugi i trzeci request. Po zrealizowaniu pierwszego pojawiał się nowy pierwszy, w rezultacie PM-owie chodzili spać z nieskończoną listą zadań do wykonania.

Dodatkowo po zrealizowaniu feature’a znikał on z listy. W konsekwencji klienci nie wiedzieli, co zespół faktycznie zbudował ani na czym się skupia, jeśli nie na ich requestach.

Nowy produkt, nowe zasady gry

Aby stworzyć nowy sposób podejścia do customer centricity, N’dounga wykorzystała nowy produkt – Jira Product Discovery. To narzędzie dla product managerów, gdzie mogą centralizować wszystkie pomysły, dodawać do nich dowolne kryteria oraz zbierać feedback i insights. Następnie mogą priorytetyzować je na podstawie zebranych informacji, a także tworzyć roadmapy do udostępnienia stakeholderom lub klientom.

Jak to ujmuje N’dounga: „To wszystko w Jira. Ale to nie jest Jira, ale jest w Jira.”

Zespół postanowił całkowicie zmienić sposób dodawania customer feedback do produktu. Rezultaty? CSAT na poziomie 86%, który nigdy nie spadł poniżej 82% od trzech lat. Dodatkowo jest to najszybciej rosnący produkt w Atlassian – szybciej niż Jira czy Trello.

Cztery filary budowania produktu z klientami

Aby naprawić ten proces, zespół Jira Product Discovery oparł swoją pracę na czterech fundamentalnych zasadach, które N’dounga przedstawia w swojej prezentacji.

1. Proaktywne zbieranie feedbacku i rotacja

Pierwsza zmiana to wielokanałowy system zbierania feedbacku połączony z rotacją. Zespół Jira Product Discovery ma cztery źródła informacji zwrotnej:

Online community (publiczne forum) – głównie SMB i prospekci
Wewnętrzny Slack – feedback od pracowników Atlassian używających produktu
Enterprise customers – przez account managerów
In-product feedback collector – formularz dostępny bezpośrednio w produkcie

Prawdziwa zmiana jednak tkwi w tym, co N’dounga nazywa „feedback rotation”. Czterech PM-ów w zespole rotacyjnie, co tydzień, jest odpowiedzialnych za wszystkie kanały. Jeden PM przez cały tydzień sprawdza wszystkie źródła, odpowiada na pytania i centralizuje feedback w Jira Product Discovery.

Trzy kluczowe korzyści rotacji

N’dounga wymienia konkretne efekty tego podejścia:

Poszerza wiedzę o produkcie – Kiedy PM musi odpowiedzieć na pytanie, którego nie zna, pyta inżynierów i innych PM-ów, dzięki czemu każdy w zespole rozumie produkt w całości.
Ujednolica priorytety w zespole – Nie trzeba nikogo przekonywać do pracy nad konkretnym feature’m. W pierwszym tygodniu jeden PM dostaje określony feedback, w drugim tydzień kolejny PM dostaje dokładnie ten sam, w rezultacie cały zespół wie, co jest ważne dla klientów.
Skraca czas discovery – Gdy PM jest gotowy pracować nad feature’m, otwiera zakładkę insights, gdzie jest wszystko. To miesiące zbierania feedbacku przez cztery osoby – znacznie więcej niż mógłby zebrać sam.

2. Lighthouse users zamiast abstrakcyjnych person

Drugi filar to odejście od tradycyjnych person. N’dounga opisuje typowe podejście: weź dużą grupę użytkowników dla statystycznej istotności, zrób wywiady, zanonimizuj wszystko, sklasyfikuj w persony, napisz długi dokument o tym, jak ta persona chciałaby dany feature.

Problem w tym, że ludzie tak nie działają. Praca dla persony to nie praca dla prawdziwej osoby, dlatego zespół N’dounga tworzy 5-minutowe video highlights. Pięciu klientów, każdy ma minutę na wyjaśnienie problemu.

Według N’dounga ten format ma znacznie większy wpływ na zespół niż strona tekstu. Inżynierowie i designerzy rozumieją problem, który mają rozwiązać, ponadto czują większą odpowiedzialność za rozwiązanie realnego ludzkiego problemu. Stają się częścią rozwiązania, bo widzą prawdziwych ludzi z prawdziwymi problemami.

✅ Jak znaleźć idealnego Lighthouse user

Ludzi, z którymi współpracuje, N’dounga nazywa swoimi „Lighthouse users”. To 6-10 osób, które spełniają trzy konkretne kryteria:

Świetny komunikator – Już w tickecie lub poście na forum dobrze wyjaśnili problem, pokazali dlaczego to problem oraz opisali, co chcieliby mieć, żeby go rozwiązać.
Doświadczenie z problemem – Nie wystarczy, że widzieli problem raz. Musieli go doświadczyć wielokrotnie i próbować naprawić na różne sposoby, inaczej pokażesz im pierwsze rozwiązanie i będą zachwyceni bez punktu odniesienia.
Gotowość do zmian – Lighthouse users muszą być otwarci na nowe sposoby pracy, ponieważ będą współpracować z PM-em niemal jak pracownicy.

Każdy krok developmentu z użytkownikami

Po wybraniu 6-10 Lighthouse users, N’dounga robi z nimi każdy etap tworzenia feature’a:

Wywiady do zdefiniowania problem area i stworzenia video highlights pokazujących prawdziwy problem
Propozycje różnych rozwiązań z pytaniem, czy to by zadziałało
Testy prototypów z walidacją, czy prototyp rozwiązuje problem
Definicja MVP i milestones – tutaj Lighthouse users decydują, co jest MVP, a co milestone 1, 2, 3
Beta testing – jeśli akceptujesz rolę Lighthouse user, akceptujesz też włączenie feature’a na twoim production i jego testowanie
Walidacja końcowa – sprawdzenie, czy działa i czy przynosi wartość

✅ Jak wdrożyć model Lighthouse Users w swoim zespole

Jeśli chcesz zastosować tę metodę, oto proces oparty na podejściu Atlassian:

Krok 1: Identyfikacja kandydatów

Przeglądaj swoje kanały feedbacku (zgłoszenia, ankiety, fora) w poszukiwaniu użytkowników, którzy wyróżniają się jakością swoich opinii

Krok 2: Weryfikacja 3 kluczowych kryteriów

Czy jest świetnym komunikatorem? (Czy potrafi jasno opisać problem i jego kontekst?)
Czy dogłębnie doświadczył problemu? (Czy próbował go rozwiązać na różne sposoby?)
Czy jest gotów do adaptacji i współpracy? (Czy jest otwarty na testowanie wczesnych wersji i regularne dzielenie się opiniami?)

Krok 3: Zaangażowanie w cały cykl rozwoju

Zaproś kandydata do współpracy na etapach: wywiadów, konsultacji rozwiązań, testowania prototypów, udziału w becie i finalnej walidacji

3. Inkrementalny rozwój i walidacja oparta na danych

Trzeci filar to stopniowe skalowanie. Choć 6-10 Lighthouse users to dobry start dla nowego feature’a, przy większym obszarze produktu trzeba więcej walidacji. N’dounga pokazuje, jak zespół skaluje testowanie w zależności od skali projektu:

100 użytkowników – dla większego obszaru produktu
1000+ użytkowników – dla nowej edycji produktu (jak Premium edition, którą właśnie wprowadzają)

Przy 100 użytkownikach zespół idzie do miejsca w narzędziu, gdzie ludzie prawdopodobnie mają ten problem i pyta: „Czy chcesz przetestować nowy feature, który to rozwiązuje?” Z kolei przy nowej edycji całego produktu strona na website zbiera długą listę potencjalnych testerów.

Metryka, która zmienia wszystko

N’dounga podkreśla coś fundamentalnego: nie jest mierzona po liczbie zrealizowanych feature’ów, budżecie ani terminach. Jedyna metryka to CSAT >75%. Jeśli nie jest dobry, pracuje dalej nad feature’m.

Prelegentka precyzuje przy tym, że metryka ta dotyczy dużych, nowych funkcjonalności, a nie bieżących poprawek błędów.

Feedback dyktuje milestony, nie odwrotnie

N’dounga pokazuje konkretny przykład z roadmapy swojego produktu. Widać tam liczbę insightów zebranych dla każdego etapu:

MVP – 41 insightów
Milestone 2 – wystarczająco dużo feedbacku do realizacji
Milestone 3 (start pod koniec miesiąca) – tylko 1 insight

Pytanie, które sobie zadała: „Czy mam poprosić trzech inżynierów, żeby pracowali nad milestone 3 przez kolejne sześć miesięcy?” Odpowiedź: absolutnie nie. Zespół zatrzymał się na milestone 2, ponieważ ludzie nie potrzebują milestone 3 w tym momencie.

4. Zamykanie pętli – transparentna komunikacja

Czwarty filar to rozwiązanie problemu braku wiedzy klientów o tym, co zespół faktycznie buduje. N’dounga opisuje trzy poziomy komunikacji, które razem tworzą kompletny system:

Wewnętrzne roadmapy dla account managerów – kiedy enterprise customer zadaje pytanie, nie dostaje odpowiedzi „Sprawdź w publicznym trackerze”. Account manager patrzy na roadmap, a jeśli feature’a tam nie ma, kontaktuje się ze Slackiem. W rezultacie klient dostaje konkretną odpowiedź.

Publiczne ogłoszenia to nie małe release notes ani tylko banner w produkcie. To pełne artykuły wyjaśniające wszystko, gdzie ludzie mogą komentować, dlatego stamtąd przychodzi feedback: „Ten feature nie wystarczy” albo „Świetnie, nie potrzebuję milestone 2”.

Public roadmap z różnymi poziomami szczegółowości w zależności od etapu feature’a. Poziom szczegółowości na mapie zależy od etapu prac – całkiem nowy feature zawiera może tylko design, natomiast feature już zrealizowany ma loom z opisem i szczegółowy artykuł. Każdy z tych elementów to kolejna okazja do zebrania feedbacku.

Od hejtera do fana z własną koszulką

Rezultaty nowego podejścia mówią same za siebie. CSAT Jira Product Discovery to 86% i od trzech lat utrzymuje się powyżej 82%. To najszybciej rosnący produkt w całym Atlassian – szybciej niż Jira czy Trello.

N’dounga kończy prezentację cytatem z użytkownika, który ilustruje transformację percepcji produktu:

„Przeszedłem od bycia hejterem Jira do zachwyconeго uczestnika Jira. Szczególnie odkąd wprowadziliście nowe narzędzie Product Discovery.”

Użytkownik dodał, że tak bardzo chwali to oprogramowanie, iż koledzy zrobili mu zabawną koszulkę na ten temat i załączył jej zdjęcie. To konkretny, mierzalny efekt zmiany podejścia do customer centricity.

Kluczowe insighty

Brak feedbacku to też feedback

Standardowo myślimy: Zbieramy feedback żeby wiedzieć, co budować i w jakiej kolejności. Im więcej insightów, tym ważniejszy projekt, dlatego planujemy roadmapę z góry i realizujemy kolejne milestony zgodnie z planem.

W praktyce okazuje się, że: Feedback mówi nie tylko co robić, ale przede wszystkim kiedy się zatrzymać. Kiedy N’dounga zobaczyła 41 insightów na MVP, 15 na milestone 2 i tylko 1 na milestone 3 – zatrzymała trzech inżynierów, którzy mieli pracować nad tym przez pół roku. Brak feedbacku to sygnał, że klienci nie potrzebują tego feature’a teraz.

Dlaczego to jest istotne: Większość zespołów traktuje roadmapę jak zobowiązanie i realizuje kolejne etapy, bo „tak było zaplanowane”. Tymczasem klienci już dostali to, czego potrzebowali po milestone 2, w rezultacie każdy kolejny miesiąc developmentu to marnowanie czasu na coś, czego nikt nie chce, zamiast przejść do problemu, który faktycznie boli.

Test na jutro: Następnym razem gdy planujesz kolejny milestone swojego projektu, zamiast automatycznie go realizować, sprawdź ile konkretnych insightów od użytkowników masz na ten etap. Jeśli jest ich drastycznie mniej niż na poprzednie etapy – zastanów się, czy to nie sygnał, że klienci już mają to, czego potrzebują.

Sukces to satysfakcja, nie dostarczenie

Standardowo myślimy: Praca product managera polega na dostarczaniu funkcji na czas i w ramach budżetu. Sukces mierzymy postępem prac na mapie drogowej.

W praktyce okazuje się, że: Prawdziwą miarą sukcesu jest to, czy nowa funkcja przyniosła użytkownikom wartość, mierzona wskaźnikiem satysfakcji (CSAT). Reszta to tylko środki do celu.

Dlaczego to jest istotne: To przenosi punkt ciężkości z wewnętrznych metryk (output) na realny wpływ na klienta (outcome). Zespoły przestają budować funkcje, których nikt nie chce, nawet jeśli są one na mapie drogowej.

Test na jutro: Następnym razem gdy będziesz planować wdrożenie nowej, dużej funkcji, zamiast mierzenia sukcesu tylko przez fakt jej dostarczenia, od razu zdefiniuj, jak zmierzysz jej wskaźnik CSAT po wdrożeniu i ustaw próg sukcesu na poziomie 75%. Sprawdź, jak to zmienia rozmowy o priorytetach i definicję „ukończonej” pracy.

Ten wpis jest częścią mojej kolekcji notatek z ciekawych podcastów, webinarów i innych treści, które uważam za wartościowe i do których sam chcę wracać. Jeśli chcesz sprawdzić oryginalne źródło, znajdziesz je tutaj: How Atlassian transformed user frustration into product love – Hermance N’dounga at #mtpcon London

Tag: Product Management Best Practices

Jak Atlassian zmienił frustrację użytkowników w product love – notatki z prezentacji Hermance N’dounga #EN329