Poniższe notatki powstały na podstawie wywiadu z Tange Cousson, Head of Product w JIRA Product Discovery. Wszystkie przedstawione przemyślenia, obserwacje i strategie pochodzą bezpośrednio od rozmówców.

TL;DR

Wonder-Explore-Make-Impact: Czterostopniowy proces odkrywania zastąpił chaotyczne podejście do rozwoju produktu
10-minutowe kompilacje wideo: Zamiast długich dokumentów zespół używa krótkich filmików z wypowiedziami klientów
Rotacja menedżerów produktu: Co tydzień inny menedżer produktu analizuje opinie zwrotne od użytkowników
Safety funnel: Lepiej zacząć od 10 zadowolonych klientów niż od tysięcy niezadowolonych
Bliskość z klientami: System pozwalający na utrzymanie 85% CSAT przy 18 000 klientów
Iteracyjne prototypowanie: Od slajdów po lovable.dev – walidacja przed pisaniem kodu
Techniczne wsparcie: Rozszerzenie Chrome do testowania gałęzi w czasie rzeczywistym

Odkrywanie produktu to według Tange Cousson najważniejsze zadanie menedżera produktu. Szef zespołu, który przez ostatnie pięć lat budował narzędzie używane dziś przez 18 000 firm, dzieli się systematycznym procesem. Dzięki temu podejściu zespół osiągnął 85% CSAT przy ogromnej skali.

Cztery etapy procesu odkrywania produktu

Cousson podkreśla, że proces tylko z pozoru przypomina waterfall. „To wygląda jak waterfall, ale nie jest waterfall. Rzeczy ciągle przechodzą z jednego etapu do drugiego na podstawie tego, czego się uczymy” – wyjaśnia. System działa na dwóch poziomach: makro (całego produktu) oraz mikro (konkretnych funkcji).

Wonder – eksploracja problemów bez założeń

Wonder to etap, w którym zespół nie jest pewien, co dokładnie buduje. Pojawiają się sygnały od klientów o problemach, jednak bez jasnego obrazu całości.

Proces Wonder obejmuje:

Przeprowadzenie około tuzina wywiadów z użytkownikami
Rozmowy trwają około godziny każda
Kontynuacja do momentu powtarzania się tych samych motywów
Tworzenie 10-minutowych kompilacji wideo zamiast długich dokumentów
Dokumentowanie różnych aspektów problemu z perspektywy klientów

Cousson jest bardzo konkretny co do oczekiwań: „Nie obchodzą mnie długie strony tłumaczące, jak duży jest problem. Zamiast tego daj mi maksymalnie 10 minut filmów z klientami mówiącymi o swoich problemach.”

Filozofia Wonder opiera się na „plain English, raw emotions”. Zespół stara się prezentować opinie zwrotne w słowach klientów, bez ozdobników i superlatywów. Celem nie jest, żeby brzmiało mądrze, ale żeby zespół poczuł autentyczny ból użytkowników.

Embrace the messiness to kolejna kluczowa zasada. Cousson używa analogii z piaskiem w wodzie: „Jeśli weźmiesz butelkę wody i wsypiesz piasek, a potem potrząśniesz – to robimy podczas wywiadów. Potem stawiasz butelkę na stole i czekasz, aż piasek opadnie na dno.”

Pisanie strony Wonder powinno zająć maksymalnie 2-3 godziny, jednak tylko wtedy, gdy już osiągnęłeś jasność. Zespół powinien móc obejrzeć materiał w ciszy przez 10 minut, a następnie w pół godziny podjąć decyzję o dalszych krokach.

Explore – walidacja rozwiązań z prawdziwymi użytkownikami

Explore nie oznacza zamknięcia się w pokoju z projektantami. Cel jest prosty: szybko znajdować sposoby testowania rozwiązań z użytkownikami, aż powiedzą „tak, to rozwiązałoby mój problem”.

Cousson pokazuje konkretny przykład z początków JIRA Product Discovery. Pierwszy prototyp to był zwykły slajd z różnymi filarami funkcjonalności. Zespół prezentował go menedżerom produktu, pytając o reakcje.

Iteracje były szybkie. Pierwszy koncept – skrzynka odbiorcza opinii zwrotnych przypominająca Gmail – wywołał umiarkowaną reakcję. Z kolei drugi prototyp – „capture, prioritize, deliver” z ideami powiązanymi z celami – spowodował natychmiastową reakcję.

Kluczowy moment walidacji nastąpił podczas rozmowy z klientem o imieniu Brent. Pracował w organizacji kierowanej przez sprzedaż. Gdy zobaczył drugi prototyp, powiedział: „Kiedy mogę to dostać? Walczę teraz. Mam spotkanie z CPO. Próbujemy prezentować mapę drogową, a CPO ciągle argumentuje, żebyśmy budowali konkretną funkcję.”

To był moment, gdy zespół wiedział, że trafił w coś ważnego. Nie napisali ani linii kodu, ale mieli jasną walidację problemu. Dziś zespół używa narzędzi takich jak lovable.dev do przekształcania zrzutów z Figma w działające prototypy.

Make – budowanie z ciągłą iteracją

Make rozpoczyna się od zresetowania designu oraz współpracy inżynierów, designerów i menedżerów produktu w jednym pomieszczeniu. Cousson używa koncepcji „safety funnel” vs „growth funnel”.

Zamiast od razu udostępniać produkt tysiącom klientów, zespół stopniowo zwiększa liczbę użytkowników. Najpierw 10 klientów, potem 100, następnie 1000. „Wolę myśleć o tym jak o kolejce przed klubem nocnym. Wpuszczamy ludzi, gdy wiemy, że będą się dobrze bawić” – tłumaczy Cousson.

Proces techniczny obejmuje:

Tygodniowe demo i przeglądy postępów
Maksymalnie 3 miesiące na pierwsze demo dla klientów
Ciągłe rozszerzanie i kurczenie zakresu na podstawie wniosków
Testowanie gałęzi za pomocą rozszerzenia Chrome
Technical spikes – 2 tygodnie eksploracji technicznej wykonalności
Live Feature Documents – żywe dokumenty definiujące wersje

Rozszerzenie Chrome pozwala menedżerom produktu testować każdą gałąź w czasie rzeczywistym. Cousson może załadować dowolną gałąź i natychmiast sprawdzić zmiany. „Najgorsza rzecz, jaka mogłaby się zdarzyć, to gdybym jako menedżer produktu mógł pracować z funkcją dopiero gdy zespół skończy.”

Gdy zespół osiąga 80% gotowości, jest w rzeczywistości w połowie drogi. Pozostałe 20% to często połowa całej pracy – polerowanie, testy, obsługa przypadków brzegowych.

Rezultat: zespół przeszedł od 1000 firm testujących za darmo do 18 000 płacących klientów w mniej niż dwa lata.

Impact – pomiar i długoterminowa optymalizacja

Impact rozpoczyna się kilka miesięcy po uruchomieniu funkcji. Zespół pisze „impact page” analizującą rzeczywistą wydajność. Na tym etapie podejmowane są decyzje o wstrzymaniu rozwoju funkcji, pozostawieniu jej dla małej grupy klientów, dalszym inwestowaniu w rozwój lub całkowitym wycofaniu.

Jak prowadzić skuteczne wywiady z użytkownikami

Błędy początkujących menedżerów produktu

Cousson przyznaje, że początkowo myślał, że jest świetny w wywiadach. Dopiero badaczka Georgie Bottomley uświadomiła mu prawdę: „Wiem, że jesteś dumny z tych 50 wywiadów. Ale powiem ci szczerze – nie nauczyłeś się nic.”

Najczęstsze błędy w wywiadach:

Prowadzenie rozmowy zamiast słuchania
Pchanie użytkowników w z góry założone kierunki
Zadawanie pytań naprowadzających
Przerywanie mówiącemu użytkownikowi
Dawanie opcji do wyboru zamiast otwartych pytań

Cousson ostrzega: „Inaczej mogę zagwarantować, że będziesz miał wiele rozmów, ale tylko udowodnią ci to, co już myślisz, że jest prawdą.”

Techniki zadawania pytań

Zasady skutecznych wywiadów:

Nigdy nie przerywaj mówiącego użytkownika – nawet jeśli cisza trwa wieczność, czekaj. Użytkownik w końcu zacznie mówić ze swojej perspektywy
Nie dawaj opcji do wyboru – zamiast „Co robisz rano? Pijesz kawę? Bierzesz prysznic?” zapytaj po prostu „Co robisz rano?” i czekaj w ciszy
Odbijaj się od tego, co mówią – nie miej sztywnego skryptu wywiadu. Reaguj na ich słowa i przenikaj głębiej w kierunku, który sami obrali
Unikaj słów kluczowych – jeśli testujesz hipotezę o problemie, nie wprowadzaj terminów związanych z tym problemem

Włączanie inżynierów w rozmowy z klientami daje dodatkową wartość. Gdy słyszą problemy bezpośrednio od użytkowników, ich reakcja jest natychmiastowa: „Następny tydzień to innovation week. Spróbuję rozwiązać ten problem.”

Narzędzia do dokumentowania

Zespół wykorzystuje kombinację narzędzi: Dovetail do przechowywania wywiadów z automatycznymi transkrypcjami, Loom do łączenia klipów wideo w spostrzeżenia, Pendo do segmentacji użytkowników według zachowań oraz JIRA Service Management do zbierania i kategoryzacji opinii zwrotnych.

Najważniejsze to wydobywanie momentów „aha” z każdej rozmowy. Hermans, jedna z menedżerek produktu, potrafi z 10-15 godzin rozmów stworzyć 10-minutową kompilację, która opowiada pełną historię problemu.

Bliskość z klientami jako przewaga konkurencyjna

System rotacji w zespole

Cousson tłumaczy, że w dużej organizacji jak Atlassian trudno jest komunikować status projektów. „Gdy mówimy o pomyśle, który jest super mglisty, musimy mu dać nazwę, bo inaczej ludzie założą, że jest dalej w procesie niż w rzeczywistości.”

Cztery etapy stały się językiem dla całej Atlassian. Praktycznie wszyscy w firmie wiedzą, co zespół robi, gdy mówi, że ma coś w Wonder.

Klasyfikacja opinii zwrotnych na trzy typy:

Big bets – duże zakłady strategiczne
Iteracje – ulepszenia istniejących doświadczeń
Small pebbles – drobne poprawki UX, które każdy inżynier może podnieść w wolnym czasie

Czterej menedżerowie produktu pracują w tygodniowej rotacji. Każdy tydzień inny menedżer produktu analizuje wszystkie opinie zwrotne od użytkowników. Miesięczne spotkania służą przeglądowi map drogowych na podstawie zgromadzonych wniosków.

Wielokanałowe zbieranie opinii zwrotnych

System punktów kontaktu z klientami:

Grupa społeczności – 10 pytań dziennie od użytkowników, szybkie odpowiedzi i rozwiązywanie problemów w czasie rzeczywistym
Bezpośrednie kanały Slack – około 20 klientów „na speed dial” do natychmiastowego kontaktu
Opinie zwrotne w aplikacji – przycisk w produkcie prowadzący do kolejki JIRA Service Management
Ankiety Pendo – pytania A/B bezpośrednio w aplikacji z opcją komentarzy

Utrzymanie 85% CSAT przy 18 000 klientów

Rezultat takiego podejścia: przy skalowaniu od 0 do 18 000 klientów, CSAT pozostał powyżej 85%. Cousson podkreśla: „To pierwszy raz w mojej karierze, gdy udało mi się osiągnąć taki wynik.”

Każdy nowy menedżer produktu początkowo uważa, że system się nie skaluje. Jednak Cousson ma jasne stanowisko: „Nie obchodzi mnie to. Mamy być zasypani tym wszystkim. To nas zmusi do myślenia, a nie komfort.”

Bezpośredni kontakt z klientami daje przewagę 10 razy bardziej wartościową niż jakiekolwiek automatyczne spostrzeżenia z AI. Cousson tłumaczy: „To da ci niesprawiedliwą przewagę, bo będziesz się ciągle uczył i zdobywał perspektywy, których wcześniej nie miałeś.”

Od prototypu do produktu – podejście safety funnel

Walidacja przed skalowaniem

Cousson używa metafory kolejki przed klubem nocnym. Zamiast natychmiast wpuszczać tysiące ludzi, lepiej wpuszczać stopniowo, zapewniając wszystkim dobrą zabawę.

Przykład z początków JIRA Product Discovery: zespół stworzył stronę docelową z hasłem „Dear product managers, your job is hard”. W dwa tygodnie 3000 firm podało emaile. 50 wywiadów z tej grupy potwierdziło problemy. Następnie nastąpiło stopniowe udostępnianie produktu segmentowanym grupom.

Cousson przyznaje, że gdy zaczynali, konkurent miał już 6000 klientów. „Mogliśmy powiedzieć – mamy konkurencję, musimy iść szybko. Ale my potroiliśmy się w dwa lata właśnie dzięki cierpliwości.”

Większość firm to nie są rocket ships. Cousson ostrzega przed naśladowaniem firm takich jak Lovable czy V0. „Większość biznesów nie jest taka. Łatwiej się rozbić, stosując to podejście, niż będąc trochę bardziej metodycznym.”

Iteracyjne podejście do rozwoju

Zespół resetuje design na początku etapu Make. Wszystko co było w Explore służy jako północna gwiazda, jednak rzeczywisty rozwój rozpoczyna się od nowa z inżynierami i designerami.

Przykład integracji whiteboard: inżynier w innovation week w 3 dni zintegrował whiteboardy z Confluence, pozwalając przeciągać pomysły między narzędziami. Fioletowy kolor oznacza aktywną gałąź – konkretny wskaźnik w ich systemie.

Zespół miał cel dostarczenia czegoś klientom w miesiąc, teraz to raczej 3 miesiące. Pełna funkcja może jednak wymagać 6+ miesięcy. Różnorodność potrzeb klientów sprawia, że nie ma prostej listy A, B, C. Żadne dwa projekty nie wyglądają tak samo.

Praktyczne wskazówki implementacji

Pierwsze kroki w nowym zespole

Cousson radzi: „Pierwszym zadaniem każdego menedżera produktu powinno być uruchomienie systemu kontaktu z klientami.”

Checklist:

Skonfiguruj narzędzia do rekrutacji użytkowników (Pendo, baza klientów)
Przygotuj szablon emaila do kontaktu z klientami (max 2 linijki + link do kalendarza)
Połącz kalendarz z narzędziem do rezerwacji spotkań
Skonfiguruj automatyczne nagrywanie wywiadów (Dovetail, Zoom)
Przygotuj proces wydobywania klipów wideo z rozmów
Uruchom grupę społeczności lub kanał Slack z klientami
Wdroż system zbierania opinii zwrotnych (JIRA Service Management)

Etap Wonder

Checklist:

Zidentyfikuj sygnały od klientów o problemach
Zaplanuj około 12 wywiadów z użytkownikami
Przeprowadź rozmowy (po około 1 godzina każda)
Wydobądź kluczowe momenty „aha” z każdej rozmowy
Stwórz 10-minutową kompilację wideo
Zapewnij różne perspektywy problemu (min. 10 klientów)
Przetestuj materiał z zespołem (10 min oglądania + 30 min dyskusji)
Podejmij decyzję o przejściu do Explore

Skuteczne wywiady z użytkownikami

Checklist:

Przygotuj otwarte pytania bez słów kluczowych
Nie przerywaj mówiącemu użytkownikowi
Toleruj niekomfortową ciszę
Nie dawaj opcji do wyboru – zadawaj otwarte pytania
Odbijaj się od tego, co mówią użytkownicy
Nagraj całą rozmowę
Natychmiast po wywiadzie zaznacz najważniejsze momenty
Wydobądź 2-3 kluczowe klipy wideo z każdej rozmowy

Safety funnel approach

Checklist:

Zacznij od 10 klientów gotowych na wczesną fazę
Upewnij się, że wszyscy mają pozytywne doświadczenie
Zmierz CSAT przed skalowaniem
Rozszerz do 100 klientów
Ponownie zmierz satysfakcję
Dopiero wtedy skaluj do tysięcy
Monitoruj metryki na każdym etapie

Narzędzia, które warto wdrożyć

Szablon emaila do klientów według Cousson: „Hej, dużo ostatnio używałeś JIRA Product Discovery. Jestem z zespołu, chciałbym porozmawiać o tym, jak możemy to ulepszyć dla Ciebie.” Maksymalnie 2 linijki + link do kalendarza.

Podstawowy stack:

Pendo – segmentacja użytkowników i ankiety w aplikacji
Dovetail – zarządzanie wywiadami i spostrzeżeniami
Loom – kompilacje wideo z najważniejszymi momentami
JIRA Service Management – centralizacja opinii zwrotnych
Platformy społecznościowe – bezpośredni kontakt z użytkownikami
Rovo – AI do analizy opinii zwrotnych na poziomie makro
Gong – znajdowanie rozmów sprzedażowych z konkretnymi słowami kluczowymi

Grupa społeczności otrzymuje około 10 pytań dziennie. Cousson pokazuje przykład: „Ktoś mówi 'był błąd, mogłem filtrować, a teraz nie mogę’. Zdarzyło się to wczoraj, dziś odpowiedziałem 'tak, patrzymy na to’ i kilka godzin później 'naprawiliśmy to dla Ciebie’.”

Szybkie rozwiązywanie problemów w społeczności sprawia, że użytkownicy wracają z kolejnymi pytaniami. Dlatego zespół może informować ich o eksperymentach z nowymi funkcjami. Cousson pokazał w społeczności funkcję, która teraz jest częścią Discovery Premium. Było 2000 wyświetleń, mnóstwo komentarzy i 4 strony dyskusji.

Kiedy pytać o pieniądze

Decyzja o płatności zależy od specyfiki rynku. W przypadku JIRA Product Discovery użytkownicy inwestowali dużo czasu w konfigurację procesów. 30% menedżerów produktu było aktywnych codziennie, co sygnalizowało wysoką wartość.

Cousson przyznaje: „Byłem bardzo niespokojny, dopóki nie zobaczyłem, jak ludzie rzeczywiście wyciągają karty kredytowe.” Walidacja przez conjoint surveys i badania potwierdziła gotowość do płacenia.

Sygnały gotowości do płacenia:

Użytkownicy inwestują znaczący czas w konfigurację (zmiana procesów)
Wysoki wskaźnik aktywnych użytkowników dziennie/miesięcznie
Pozytywne odpowiedzi na conjoint surveys
Klienci opisują ból związany z brakiem narzędzia
Proces jest krytyczny dla ich codziennej pracy
Zespół ma budżet na tego typu narzędzia

Kluczowy insight

Chaos to sygnał, nie problem

Standardowo myślimy: Im szybciej uporządkujemy sprzeczne informacje z wywiadów, tym lepiej posuwamy się do przodu.

W praktyce okazuje się, że: Chaos i sprzeczności to naturalna część procesu odkrywania, która wymaga cierpliwości, nie szybkiego porządkowania.

Dlaczego to jest istotne: Próba zbyt szybkiego kategoryzowania zabija autentyczne spostrzeżenia. Cousson mówi: „Niektóre dni czujesz, że idziesz do tyłu. To jest całkowicie normalne. Pozwól temu trwać – w końcu przejrzysz na wylot.”

Test na jutro: Następnym razem gdy po wywiadach czujesz chaos i sprzeczne sygnały, zamiast od razu tworzyć kategorie i wnioski spróbuj „postawić butelkę na stole” – zaczekaj tydzień z syntezą i sprawdź jakie wzorce same się wyłonią.

Ten wpis jest częścią kolekcji notatek z ciekawych podcastów, webinarów i innych treści. Materiał pochodzi z wywiadu z Tange Cousson, Head of Product w JIRA Product Discovery, przeprowadzonego w ramach serii „Complete Course: AI Product Discovery”. Oryginalny materiał dostępny jest tutaj: Complete Course: AI Product Discovery

Tag: Agile Development

Cztery etapy product discovery, które zmieniły sposób pracy w Atlassian #EN202