Notatki z rozmowy z Tenge Coussonem, Head of Product w JIRA Product Discovery. Wszystkie przemyślenia, obserwacje i metodologie pochodzą od rozmówców podcastu.

TL;DR

Framework Wonder-Explore-Make-Impact zastępuje chaotyczne podejście strukturalnym procesem z jasnym słownictwem
10-minutowe kompilacje filmów z klientami przewyższają skutecznością długie dokumenty dzięki autentycznym emocjom
Progresywna walidacja prowadzi od prostego slajdu przez prototypy do pełnego produktu z testowaniem małych grup
Safety funnel okazuje się skuteczniejszy od growth funnel – ograniczenie dostępu chroni przed złymi pierwszymi wrażeniami
Narzędzia jak testowanie gałęzi umożliwiają PM-om testowanie zmian w czasie rzeczywistym
Rezultat: 85%+ wskaźnik zadowolenia klienta utrzymywany podczas skalowania od 0 do 18,000 płacących klientów w niecałe 2 lata

Dlaczego tradycyjne podejście do discovery zawodzi

Product discovery stanowi według Tenge Coussona „zadanie numer jeden o wysokiej wartości dla PM-a”. Mimo to większość zespołów popełnia fundamentalne błędy w podejściu do tego procesu.

Najczęstsze problemy w discovery:

Długotrwałe projektowanie rozwiązania w izolacji od użytkowników
Tworzenie szczegółowych specyfikacji bez wcześniejszej walidacji
Przedłużone okresy budowania produktu z wykorzystaniem wyłącznie sprintów
Brak iteracji między fazą koncepcji a implementacją

Cousson zwraca uwagę, że metodologia Agile pierwotnie miała pokrywać oba elementy równocześnie. W praktyce jednak zespoły rozdzielają te procesy, co prowadzi do marnowania zasobów i budowania niewłaściwych rozwiązań.

Framework Wonder-Explore-Make-Impact w działaniu

Wonder: dogłębna eksploracja problemów

Wonder koncentruje się na zrozumieniu rzeczywistych problemów klientów bez wcześniejszych założeń. Jak opisuje to Cousson: „Nie jesteśmy pewni co robimy, ale mamy wielu klientów rozmawiających o określonych tematach”.

Przykładem takiego procesu była eksploracja problemu „global entities” (później przemianowanego na „global fields”). Klienci konsekwentnie sygnalizowali trudności z zarządzaniem wieloma projektami JIRA Product Discovery na większą skalę, jednak temat pozostawał „super mglisty”. PM Hermance Endunga otrzymała zadanie wyjaśnienia istoty tych problemów.

Proces rozpoczyna się od przeprowadzenia około tuzina wywiadów z użytkownikami, każdy trwający około godziny. Celem nie jest realizacja „super naukowego, kompleksowego podejścia”, lecz zrozumienie sposobu, w jaki klienci doświadczają problemów w swoich własnych słowach.

Kluczowa zasada: nie ma potrzeby ankietowania tysięcy użytkowników. Wystarczy kilku klientów wyrażających podobne problemy, aby rozpocząć wartościową eksplorację.

Explore: walidacja koncepcji z rzeczywistymi użytkownikami

Faza Explore koncentruje się na szybkim znajdowaniu sposobów testowania rozwiązań z użytkownikami. Zespół kontynuuje prace, dopóki klienci nie potwierdzą: „Tak, to faktycznie rozwiązałoby mój problem”.

Pierwszy prototyp JIRA Product Discovery stanowił zwykły slajd. Zespół prezentował prostą wizualizację z filarami produktu różnym menedżerom produktu, zadając pytanie: „Co myślisz? To rozwiązanie, które budujemy. Jak by ci pomogło?”

Czasami zespół wykorzystuje sondy techniczne jako część procesu Explore. Gdy złożoność techniczna pozostaje nieznana, zespół przez 2 tygodnie próbuje zbudować prototyp w kodzie, dokumentując każdą napotykaną blokadę. Takie podejście pomaga oszacować trudność implementacji przed podjęciem decyzji o inwestycji.

Obecnie zespół zastępuje Figma narzędziem Lovable. Uploadują screenshot z Figmy do Lovable i tworzą działający prototyp, z którym użytkownicy mogą interaktywnie pracować, jednak nadal rozumieją, że nie jest to finalny produkt.

Jeden z klientów, Brent, wyraził swoje potrzeby następująco: „Pracuję w organizacji napędzanej sprzedażą i muszę zjednoczyć ludzi wokół moich priorytetów”. Po tej walidacji zespół wiedział, że chce pomóc Brentowi – stał się on ich klientem referencyjnym.

Make: iteracyjne budowanie z ciągłą walidacją

Faza Make rozpoczyna się od całkowitego resetu designu. Wszystko, co było prezentowane klientom w fazie Explore, zostaje przeprojektowane we współpracy inżynierów, designerów i PM-ów pracujących razem.

Fundamentalne pytanie brzmi: „Co to jest wersja 0?” – minimum funkcjonalności, które można przekazać 10 klientom do testowania. Zespół wykorzystuje Live Feature Documents – żywe dokumenty definiujące kluczowe przepływy, które mają działać.

Na początku dokumenty te są aktualizowane niemal codziennie, później raz w tygodniu. W miarę odkrywania nowych aspektów dodawane są kolejne elementy, a gdy postęp staje się widoczny, zespół oznacza funkcje, które mogą zostać przełożone na później. To nie są bilety JIRA – to wspólna praca całego zespołu: PM, designera i inżynierów.

Cotygodniowe demonstracje umożliwiają dyskusje o zakresie, który ma tendencję do rozszerzania i kurczenia się w miarę lepszego zrozumienia problemu. Maksymalny czas na pierwszą wersję dla klientów wynosi 3 miesiące.

Impact: pomiar i długoterminowa optymalizacja

Impact to faza, w której problem został przetłumaczony na funkcjonalność w produkcie. Zespół mierzy wydajność, ponieważ rozwiązanie „może działać dobrze dla małej liczby użytkowników, ale musi działać dobrze dla bardzo dużej liczby”.

Kilka miesięcy po uruchomieniu zespół przygotowuje „stronę impact” analizującą rzeczywiste wyniki. Na tej podstawie podejmowana jest decyzja o zawieszeniu, kontynuowaniu lub zwiększeniu inwestycji w rozwiązanie.

Sztuka prowadzenia wywiadów bez wpływania na odpowiedzi

Typowe błędy menedżerów produktu

Cousson początkowo był przekonany o swoich umiejętnościach prowadzenia wywiadów. Mówił rzeczy, które brzmiały mądrze, a ludzie się z nim zgadzali. Dopiero researcher Georgie Bottomley uświadomiła mu rzeczywistość: „Wiem, że jesteś dumny z tych 50 wywiadów. Kolego, nic się nie nauczyłeś. Prowadzisz wszystkie te rozmowy, pchasz użytkowników w kierunki, których sami by nie obrali”.

Skuteczne techniki prowadzenia rozmów

Bottomley przekazała Coussonowi prosty skrypt wywiadów z dużą ilością przestrzeni na ciszę:

Poproś o przedstawienie się
Poproś o opisanie tego, co robią w firmie
Od tego momentu nie masz przygotowanego skryptu – reagujesz na to, co mówią

Fundamentalne zasady podczas wywiadów:

Nigdy nie przerywaj użytkownika, który mówi
Nie oferuj opcji do wyboru – zadawaj pytania otwarte i czekaj
Pozwalaj na niezręczną ciszę – mobilizuje ona do szczerych odpowiedzi
Jeśli chcesz walidować problem z opiniami zwrotnymi, nigdy nie używaj słowa „feedback” w rozmowie

Od prototypu do 18,000 płacących klientów

Safety funnel: jakość przed ilością

Kluczowa koncepcja przypomina kolejkę przed klubem nocnym. Cousson preferuje wpuszczanie ludzi dopiero wtedy, gdy ma pewność, że będą się dobrze bawić.

Jak wyjaśnia: „Jeśli damy im coś, co nie jest dobre, przyjdą raz, spojrzą i pomyślą 'to nie dla mnie’. Odzyskanie ich będzie walką pod górę”.

Proces kontrolowanego skalowania:

10 klientów → 100 klientów → 1,000 klientów → 18,000 płacących w niecałe 2 lata
Wskaźnik zadowolenia klienta utrzymywany powyżej 85% przez cały okres skalowania

Walidacja rynku przed budową produktu

Przed rozpoczęciem budowy jakiejkolwiek funkcjonalności zespół umieścił na stronie Atlassian reklamę: „Drodzy menedżerowie produktu, wasza praca jest trudna z różnych powodów. Czy jesteście dumni z tego co wypuszczacie? Chcielibyśmy wam pomóc”.

W ciągu dwóch tygodni 3,000 firm podało swoje adresy e-mail. Rezultat ten zapewnił dwie kluczowe informacje: walidację istnienia problemu oraz możliwość przeprowadzenia 50 wywiadów z użytkownikami, które potwierdziły wszystkie założenia.

Strategia free vs paid: największe ryzyko produktowe

Jak przyznaje Cousson, „to był największy gamble w JPD”. Przez długi okres ludzie korzystali z produktu bezpłatnie, a menedżer produktu odczuwał dyskomfort związany z tym, jak daleko posunęli się bez zmuszania użytkowników do płacenia.

Dlaczego strategia sprawdziła się w modelu B2B:

Zespoły musiały zainwestować znaczący czas w skonfigurowanie procesów
Żaden projekt JIRA Product Discovery nie wygląda identycznie – każdy wymaga dostosowania
30% miesięcznie aktywnych menedżerów produktu było także aktywnych codziennie
Walidacja przez badania conjoint surveys potwierdziła gotowość do płacenia

Cousson porównuje to do modelu Bolt: „Pierwszych 5 promptów za darmo, szósty wymagał karty kredytowej – pomyślałem 'tak, zapłaciłbym 20$ za to'”. W przypadku produktów B2C byłby znacznie bardziej ostrożny z takim podejściem.

Konkurencyjny rezultat: Gdy zespół rozpoczynał pracę, konkurent posiadał 6,000 klientów. Atlassian osiągnął potrójny wynik w ciągu 2 lat – wzrost może przyspieszyć wykładniczo, gdy produkt jest gotowy.

Narzędzia i procesy wspierające ciągły discovery

Konfiguracja technologiczna dla współczesnego menedżera produktu

Cousson podkreśla fundamentalną zasadę: „Twoja pierwsza praca po dołączeniu do zespołu, gdzie ludzie nie rozmawiają często z klientami, to wprowadzenie tych procesów”.

Ich konfiguracja technologiczna obejmuje:

Pendo – segmentację klientów, pytania i ankiety w aplikacji
Dovetail – transkrypcje wywiadów, fragmenty wideo, organizację spostrzeżeń
JIRA Service Management – kolejkę surowych opinii zwrotnych od użytkowników
Rovo – narzędzie AI do analizy opinii zwrotnych: „W ostatnich 6 miesięcy, co ludzie mówią?”
Slack – bezpośredni kontakt z około 20 klientami „na szybkim wybieraniu”
Loom – łączenie fragmentów wideo w kompilacje
Community grupa – około 10 pytań dziennie, 2000+ wyświetleń postów, 4 strony komentarzy przy ważnych funkcjach

Zespół 4 menedżerów produktu pracuje w rotacji – co tydzień jedna osoba analizuje wszystkie opinie zwrotne i przekształca je w spostrzeżenia oraz pomysły. Miesięcznie zespół omawia zmiany i aktualizuje mapy drogowe.

Wpływ na zespół inżynierski: Gdy inżynierowie słyszą problemy klientów bezpośrednio, ich reakcja brzmi: „Jest innovation week w przyszłym tygodniu, spróbuję rozwiązania tego problemu” i rzeczywiście się angażują. To dokładnie taka energia, jakiej Cousson oczekuje wokół problemów.

Testowanie gałęzi: techniczne wsparcie szybkich iteracji

Menedżer produktu może testować każdą zmianę w czasie rzeczywistym. Cousson demonstruje rozszerzenie Chrome, które pozwala załadować JIRA Product Discovery z dowolną gałęzią kodu, nawet jeśli nie jest zintegrowana z głównym środowiskiem.

Jak wyjaśnia: „Najgorsza rzecz, jaka może się zdarzyć, to gdy jako PM mogę pracować z czymś dopiero gdy zespół skończy. Zamiast tego mówię im: gdy stworzysz gałąź i jest coś dla mnie do obejrzenia, po prostu wyślij mi gałąź”.

Konkretny przykład: Podczas innovation week jeden z inżynierów w 3 dni zbudował integrację z whiteboardami Confluence. Cousson mógł natychmiast przetestować funkcję – przeciąganie i upuszczanie pomysłów na whiteboard, łączenie ich z innymi elementami. Wykorzystał rozszerzenie Chrome, które pokazuje fioletowy wskaźnik podczas pracy na gałęzi, nie na master.

Takie podejście umożliwia mikroiteracje – zmianę przycisku, interakcji – i natychmiastowe testowanie przez menedżera produktu bez oczekiwania na pełną integrację z pipeline’em.

Kluczowe wnioski z doświadczenia Atlassian

Najważniejsze spostrzeżenia z praktyki:

Inwestycja w szkolenie z research to zmiana życia menedżera produktu – warto znaleźć prawdziwego user researchera i poprosić o szkolenie
10-minutowe kompilacje filmów przewyższają dokumenty – autentyczne emocje klientów mobilizują zespoły skuteczniej niż abstrakcyjne opisy
Akceptacja chaosu – początkowe wywiady przypominają butelkę wody z piaskiem, trzeba poczekać aż się ustatkuje
Metodologia Shape Up – nie wprowadza się funkcji którą zaprojektowano, lecz redukuje ją o 50% do wersji wprowadzanej jako pierwsza
Wszystkie menedżery produktu początkowo mówią „to się nie skaluje” – jednak powinni być „przytłoczeni” opiniami zwrotnymi, to sprawia, że myślą, nie komfort
AI jako przyspieszacz, nie zastępca – wykorzystywanie AI do dotarcia do właściwych rozmów, nie do zastąpienia ich

Skalowanie które przynosi rezultaty: Przejście od 0 do 18,000 płacących klientów z utrzymaniem 85%+ wskaźnika zadowolenia klienta stanowi efekt cierpliwości i metodycznego budowania fundamentów zamiast pogoni za szybkim wzrostem.

Kluczowy insight

Przytłoczenie zamiast optymalizacji

Standardowe myślenie: Menedżer produktu powinien filtrować opinie zwrotne, ustalać priorytety kanałów komunikacji i „skalować” procesy, aby uniknąć przeciążenia. Efektywność stanowi klucz.

Rzeczywistość: Najlepsi menedżerowie produktu celowo się „przytłaczają” opiniami zwrotnymi od klientów. Jak wyjaśnia Cousson: „Każdy nowy PM mówi że się nie skaluje. A ja na to: nie obchodzi mnie to. Powinniśmy być przytłoczeni tym wszystkim. To sprawia, że myślimy. Nie komfort”.

Dlaczego to ma znaczenie: Komfort w pracy menedżera produktu sygnalizuje, że znajduje się za daleko od prawdziwych problemów klientów. Chaos opinii zwrotnych zmusza do myślenia i prowadzi do przełomowych spostrzeżeń, których nie można dostrzec w „zoptymalizowanym” systemie.

Test na jutro: Następnym razem, gdy otrzymasz falę opinii zwrotnych od klientów, zamiast od razu je kategoryzować i filtrować, spróbuj przez tydzień „się w nich wykąpać” – czytaj wszystko, słuchaj nagrań, obserwuj wzorce – i sprawdź, czy nie wyłonią się zupełnie nowe perspektywy na problemy użytkowników.

Praktyczne listy kontrolne do wdrożenia

Konfiguracja procesu discovery w zespole

Kluczowe narzędzia:

Platforma do segmentacji użytkowników i pytań w aplikacji (Pendo)
Narzędzie do transkrypcji i fragmentów wideo (Dovetail)
Kolejka opinii zwrotnych z tagowaniem i kategoryzacją (JIRA Service Management)
Narzędzie AI do analizy opinii zwrotnych na skalę (Rovo lub podobne)
Bezpośrednie kanały komunikacji z klientami (Slack, community)
Kalendarz z funkcją rezerwacji dla wywiadów
Konfiguracja testowania gałęzi dla menedżerów produktu (rozszerzenie Chrome lub podobne)

Procesy organizacyjne:

Rotacja menedżerów produktu przy analizie opinii zwrotnych (1 osoba/tydzień)
Cotygodniowe omówienia spostrzeżeń z zespołem
Miesięczne przeglądy map drogowych na podstawie wniosków
Lista 10-20 klientów referencyjnych do bezpośredniego kontaktu

Prowadzenie efektywnych wywiadów

Przygotowanie i przeprowadzenie:

Prosty skrypt: przedstawienie → opis pracy → pytania otwarte
Nagrywanie za zgodą do późniejszej analizy
Zapraszanie inżynierów na wybrane wywiady (buduje empatię)
NIE przerywaj mówiącego użytkownika – 3 minuty ciszy to sukces
NIE oferuj opcji do wyboru – pozwól na niezręczną ciszę
Natychmiast po wywiadzie oznacz kluczowe momenty „aha”

Walidacja i progresywne wdrażanie

Faza Explore:

Rozpocznij od najprostszej formy (może być zwykły slajd)
Rozważ sondę techniczną, jeśli złożoność techniczna pozostaje nieznana
Wykorzystaj Lovable lub podobne narzędzia do interaktywnych prototypów
Szukaj reakcji „Kiedy mogę to otrzymać?” zamiast „To interesujące”

Progresywne wdrażanie:

Start: 10 klientów referencyjnych, którzy rzeczywiście potrzebują rozwiązania
Wykorzystuj Live Feature Documents zamiast statycznych specyfikacji
Mierz wskaźnik zadowolenia klienta przed rozszerzaniem na kolejne grupy
Kryteria przejścia: zadowoleni użytkownicy + brak problemów z wdrażaniem użytkowników
Przyjmij sposób myślenia „kolejka przed klubem” – wpuszczaj, gdy masz pewność dobrego doświadczenia

Ten wpis stanowi część mojej kolekcji notatek z wartościowych podcastów, webinarów i innych treści. Oryginalny materiał źródłowy dostępny jest tutaj: Complete Course: AI Product Discovery

Tag: Atlassian Metodologia

Product Discovery według Atlassian: Od chaosu do 18,000 zadowolonych klientów #EN192