Dzisiaj mam dla Ciebie mój trzyetapowy framework o nazwie DIG, który stosuję by za pomocą AI wstępnie przeanalizować każdy, nawet zupełnie nieznany zbiór danych.

Wyobraź sobie scenariusz: Customer Support przesyła Ci plik z feedbackiem użytkowników bez większego opisu czy wyjaśnienia. „Prosiłeś o dane, to przesyłamy dane (raw export). Nie mamy czasu tego opisywać”.

Jesteś na poziomie 0% zrozumienia. Co teraz? Pokaże Ci jak ja to robię z wykorzystaniem DIG:

• 1️⃣ Krok: D - Description

• 2️⃣ Krok: I – Introspection (Introspekcja)

• 3️⃣ Krok: G – Goal Setting (Ustalenie Celu)

Robię to na konkretnym przykładzie analizy wyników satysfakcji z ostatnich edycji Product Management Academy oraz publicznym datasecie oceny filmów z AppleTV (możesz samemu łatwo powtórzyć kroki i poeksperymentować 🔬):

Framework DIG: Jak ogarnąć surowe dane produktowe z pomocą AI?

Trzyetapowy framework do eksploracji danych. Przetestowałem go na 500 wynikach ankiety feedbackowej Product Management Academy.

newsletter.productcraft.pl/p/framework-dig-jak-ogarnac-surowe

👉 Sprawdź playbook

Hej 👋 !

Stało się 🎉. Oficjalnie startujemy otwartą sprzedaż XI edycji programu Product Management Academy (24.03 - 5.05 2026). Ponownie będziemy uczyć się i wdrażać do naszej pracy najważniejsze narzędzia, koncepcje i frameworki produktowe. 6 tygodni intensywnej pracy, gdzie na żywych case'ach przetestujesz metody, które działają.

Zaczynamy od tańszych biletów z puli „early birds” (750 zł oszczędności) i na razie informujemy o nich TYLKO osoby zapisanych na listę zainteresowanych (czyli m. in. Ciebie).

• 5️⃣+1️⃣ tygodni warsztatów w grupach, materiałów online, spotkań LIVE z mentorami, indywidualnych zdań i wdrażania do swojej pracy najważniejszych narzędzi, koncepcji i frameworków produktowych.

• 2️⃣ grupy warsztatowe (max. 20 osób) - do wyboru masz 2 grupy warsztatowe, które co tydzień będą wspólnie pracować na 3h warsztatach.

  • w grupie popołudniowej (czwartki, 16:30 - 19:30)

  • w grupie porannej (piątek, 9:00 - 12:00).

  • Zobacz szczegółowy harmonogram spotkań.

• 1️⃣0️⃣ biletów - teraz udostępniamy TYLKO 10 biletów, z możliwością zakupu TYLKO przez tego maila. Kolejna pula będzie droższa.

💰 Cena? W przedsprzedaży bilety kosztują... 2 634 zł netto (3 239,82 zł brutto, o ponad 800 zł taniej od ceny regularnej)! Tak, to nie pomyłka - w cenie 2-3 dniowego szkolenia masz, aż 6-tygodniowy program z warsztatami i materiałami online 😎.

…lub sprawdź szczegóły PMA na stronie

Informacje o sprzedaży 💰

Sprzedaż puli Early Birds potrwa do wyczerpania biletów. W tej puli dostępnych jest TYLKO 10 biletów (po 5 na każdą grupę). Warto się pospieszyć - pula Early Birds poprzednich edycji wyczerpały się w kilkadziesiąt godzin ⏰. Kolejne bilety będą dostępne za tydzień, w ramach droższej puli "standard" (3 887 zł brutto). Taniej więc już nie będzie ;)

Formalności i płatność:

• Możesz zapłacić bezpośrednio przez stronę - korzystamy z EasyCart, działają tam karty płatnicze, BLIK, Apple / Google Pay.

• Jeśli jesteś zdecydowany/-a, ale potrzebujesz więcej czasu na formalności, płatności przelewem, faktury pro-forma itp. - odpowiedz po prostu na tego maila, zarezerwujemy Ci bilet i ogarniemy formalności ;).

• Możecie wybrać się na PMA całym zespołem - od 3 uczestników dajemy dodatkową zniżkę 10%.

• Do każdego zamówienia wystawiamy fakturę VAT.

• Potrzebujesz rozbicia płatności na 2 raty? - odpowiedz po prostu na tego maila, zarezerwujemy Ci bilet i ogarniemy formalności ;).

Czym jest Product Management Academy? Co zawiera?

W PMA stawiamy na transformację - od skupienia na dowożeniu i zarządzaniu backlogiem (output) do product managera dowożącego realną wartość produktu (outcome).

Sami przechodziliśmy tę drogę i chcemy Wam w tym pomóc - Olga (Senior PM w Jira Product Discovery, wcześniej Jira Server, SentiOne, AirHelp) oraz Tomek (HoP w BrainBits, ex-SentiOne, Tutlo.com, PolskaPress)

Średni NPS wszystkich edycji to 85, a średnia ocena uczestników to 5,5 / 6 😍. Zobacz podsumowanie ostatniej edycji, dokładne kulisy edycji 2023 oraz całą masę publicznych ocen uczestników na LinkedIn na naszym profilu.

W ramach Akademii czekają na Ciebie:

• 📕 lekcje przygotowujące do warsztatów (żebyśmy zminimalizowali teorię),

• 🛠️ praktyczne warsztaty (5x 3h), na których ćwiczymy koncepcje,

• 👩‍🏫 spotkania LIVE Masterclass (4× 1,5h) z mentorami i ich case studies,

• ✏️ indywidualne „zadania projektowe” - do których dostajesz feedback,

• 📚 dodatkowe materiały online rozszerzające wiedzę z warsztatów,

• 💬 wsparcie zamkniętej społeczności i 12 miesięczny dostęp do kampusu Product Academy z mnóstwem dodatkowych materiałów i case studies.

Każdy moduł to od 5 do 8h materiału, który zostaje z Tobą także po PMA (na 12 msc). Zobacz szczegółowy harmonogram spotkań (sekcja "Program warsztatów i spotkań")

Kampus Product Academy, gdzie odbywa się Akademia

Pogram kierujemy do:

Czeka na Ciebie 7 modułów:

1. Kick-off - Zaczynamy od zmiany perspektywy - poznasz, na czym polega nowoczesny product management i mindset produktowy skupiony na Outcomach. Poznamy też model kompetencji product managera.

2. Product Foundation - Jak zacząć z produktem? Poznasz fundamenty systemu pracy z produktem i współpracy w zespole/firmie. Nauczysz się jak ułożyć sobie współpracę z przełożonym i interesariuszami. Poznasz najpopularniejsze rytuały produktowe.

3. Product Discovery - Dowiesz się czym są ryzyka produktowe i na czym polega praca nad discovery produktu. Nauczysz się odkrywać, identyfikować i walidować pomysły.

4. Product Delivery - Przepracujemy temat współpracy z zespołem technicznym przy wdrażaniu rozwiązań i realizacji inicjatyw produktowych (w oparciu o rolę PO we frameworku Scrum).

5. Product Analytics – Nauczysz się mierzyć to, co faktycznie ma wpływ na produkt i biznes. Dowiesz się, jak definiować KPI, planować eksperymenty i wyciągać wnioski z danych, aby stale podnosić wartość produktu.

6. Product Strategy - Odczarujemy temat strategi produktowej oraz przygotowania roadmapy. Nauczysz się tworzyć strategie, które nie lądują w szufladzie. Dowiesz się, jak priorytetyzować inicjatywy w oparciu o cele biznesowe (OKRs) i jak komunikować roadmapę, by zyskać buy-in całej organizacji.

7. Action Plan - przepracujemy jak wdrożyć zdobytą wiedzę w praktyce z wykorzystaniem Action Planów.

Za cel postawiliśmy sobie przygotowanie programu, po którym uczestnik będzie mógł wziąć najważniejsze narzędzia / koncepty / frameworki produktowe i od razu zastosować je w swojej pracy. Tak, jak my sami je stosujemy na co dzień.

👩‍🏫 Prowadzących warsztaty product managerów znajdziesz na LinkedIn: Tomek Tomaszewski (Head of Product BraintBits, ex-SentiOne) oraz Olga Springer (Senior Product Manager w Altassian). Naszą wiedzę uzupełnią też dodatkowo mentorzy (doświadczeni praktycy product managementu), którzy pojawią się w trakcie Akademii.

Jak PMA wygląda od środka?

Zastanawiasz się, jak to wygląda w praktyce? Nie musisz "kupować kota w worku". Poniżej znajdziesz intro, które wysyłamy do uczestników PMA, gdzie transparentnie pokazuję co nas czeka w trakcie 6 tygodni:

Jeśli masz jakiekolwiek pytania lub wątpliwości, to po prostu odpisz na tę wiadomość. Jestem po drugiej stronie i odpowiadam na maile!

Pozdrawiam,
--
Tomek Tomaszewski, Olga Springer
Product Management Academy / Product Academy

Przez ostatnie tygodnie pracowałem nad czymś, co traktuję jako naturalną kontynuację AI Product Bootcamp - programem 10x Product Bootcamp (1.04 - 7.05). Dzisiaj dowiadujecie się o tym jako pierwsi.

Dlaczego 10x? Bo samo AI nie zrobi z Ciebie lepszego PM-a. Ale połącz AI z doskonałym mindsetem produktowym - i nagle możesz osiągać 10x więcej. Ultrakrótkie iteracje, walidacja pomysłów i decyzje oparte na dowodach.

Tak pracują najlepsze zespoły które obserwuję (i w których mam przyjemność pracować o 8 lat rozwijając produkty AI).

🔹 10x Product Bootcamp (1.04 - 7.05)

• 🔹 6 tygodni "learning by doing". Razem przechodzimy przez kompletny product sprint od A do Z dla konkretnego wzywania - case study. Tak jak w prawdziwej pracy.

• 🔹 Pracujesz na cotygodniowych warsztatach, w małej grupie (max 20 osób), a nie tylko samotnie “w swoim czasie”. Przed warsztatem otrzymujesz 30 minutowy pre-work.

• 🔹 [Opcjonalnie] 4x power sessions i office hours z mentorami, praktyczne indywidualne zadania projektowe rozszerzające pracę nad case study, lekcje i materiały online.

Pierwsza edycja dla early adopterów, na razie planuję jedna grupę - tylko 20 miejsc. Dla pierwszych 10 osób cena przedsprzedażowa tylko 3 000 zł → 1 499 zł netto (1 843,77 zł brutto) 💰.

BTW. Jak wszystko zatryb to niedługo odkryjemy wiece interesujących kart związanych z botocampem 😉. Na razie pozdrawiam z małych wakacji. Stay Tuned!

Od 6 miesięcy Cursor stał się moim podstawowym środowiskiem pracy produktowej z AI.

Cursor to edytor kodu z agentami AI dla developerów. Ale właśnie dlatego może być najlepszym miejscem do pracy PM-a z LLMami - masz kontekst, historię, pliki, wszystko w jednym miejscu. Pisałem o nim w ostatnim newsletterze. 

Wiele osób o to pytało, więc postawiłem podzielić się jak to wygląda u mnie w praktyce na spotkaniu Masterclasss ⤵️

📆 Masterclass: Cursor dla PM/PO

• 📆 Czwartek, 15.01, 

• ⏰ 19:00 - 20:00

• 💰 BEZPŁATNIE (limit miejsc)

Zapraszam na masterclass na którym pokażę Mój setup i środowisko pracy z Cursorem oraz kilka praktycznych use case'ów z mojej codziennej pracy PM-a

Będzie demo + odpowiem do oporu na Wasze pytania. Zapraszam!

Znasz to uczucie? Backlog pęka w szwach, Stakeholderzy dorzucają kolejne "świetne" pomysły (oczywiście wszystkie na wczoraj), a Dev team patrzy na Ciebie wzrokiem mówiącym: "Serio? Kolejny feature?".

tu wchodzi cała na biało Twoja rola jako Product Managera: sztuka mówienia "nie" i wybierania tego, co ma największy sens i dowiezie największy wpływ.

Dziś bierzemy na warsztat klasyk priorytetyzacji produktowej - Model Kano.

• 1. Co to jest ten Model Kano?

• 2. Cztery kategorie funkcji

  • 2.1. Funkcje fundamentalne (Must-be)

  • 2.2. Funkcje wydajności (Performance)

  • 2.3. Funkcje atrakcyjne (Delighter)

  • 2.4. Funkcje obojętne (Indifferent)

• 3. Migracja funkcji atrakcyjnych do fundamentalnyc …

• 4. Wykorzystanie Modelu Kano

• 5. Moja praktyka

• 6. Podsumowanie

1. Co to jest ten Model Kano?

Noriaki Kano, japoński badacz i konsultant, pod koniec lat 80. zauważył coś, co dla nas dzisiaj wydaje się oczywiste, a wtedy było rewolucją: satysfakcja klienta nie rośnie liniowo wraz z liczbą funkcji w produkcie.

Innymi słowy: możesz dodać 100 nowych funkcji do aplikacji, a Użytkownicy i tak będą wściekli, jeśli ta jedna, podstawowa rzecz nie działa.

W modelu Kano funkcje produktu są sklasyfikowane w 4 kategoriach, na podstawie naniesienia ich na dwóch osiach:

• Oś Y (Satysfakcja): Od "Totalnie wkurzony" (dół) do "Zachwycony" (góra).

• Oś X (Inwestycja): Od "Brak funkcji/Słaba jakość" (lewo) do "Świetnie zrobione/Pełna funkcja" (prawo).

Przynależność funkcji do danej kategorii można ustalić poprzez zadawanie odpowiednich pytań użytkownikom produktu.

2. Cztery kategorie funkcji

Model Kano klasyfikuje przynależność funkcji do jednej z czterech kategorii, w zależności od tego, jak klienci reagują na podany poziom funkcjonalności.

2.1. Funkcje fundamentalne (Must-be)

Funkcje te są wymagane przez klientów. W przypadku gdy produkt nie będzie ich posiadał, zostanie określony jako niekompletny lub niezdatny do użytku. Implementacja tych funkcji nie spowoduje wysokiej satysfakcji u użytkowników. Co więcej, długa inwestycja w funkcje tylko i wyłącznie podstawowe nie podniesie satysfakcji w znacznym stopniu. Po osiągnieciu podstawowego poziomu oczekiwań, nie warto dłużej w niego inwestować.

Przykładem funkcji podstawowych mogą być hamulce w samochodzie czy możliwość wysyłania wiadomości tekstowych w telefonie.  Brak jakiejkolwiek z nich spowoduje wysokie niezadowolenie użytkownika.

Jednym z wyzwań w przypadku funkcji fundamentalnych jest to, że użytkownik rzadko o nich wspomina. Są dla niego oczywistością. Zadaniem Product Managera jest obserwacja i próba wydobycia podstawowych założeń.

• Charakterystyka: Userzy rzadko o nich mówią, bo traktują je jako oczywistość. Ale jak ich zabraknie? Nie będą zadowoleni.

• Wpływ na satysfakcję: Zrobienie ich idealnie nie da Ci "gwiazdek". Po prostu sprawi, że ludzie nie będą na Ciebie krzyczeć.

• Przykład: Hamulce w samochodzie. Możliwość logowania w aplikacji. Czysta pościel w hotelu.

• Mój tip: Inwestuj tu tylko tyle, żeby "działało". Nie przepalaj budżetu na optymalizację w nieskończoność

2.2. Funkcje wydajności (Performance)

Funkcje te nie są wymagane przez użytkowników natomiast ich brak powoduje obniżenie satysfakcji. Im więcej będzie ich dostarczonych tym większe zadowolenie zostanie osiągnięte i więcej klientów będzie chętnych aby kupić produkt. W przypadku tych funkcji istnieje liniowa zależność pomiędzy poziomem satysfakcji, a czasem inwestycji.

Przykładem może być szybkość łącza internetowego. Im szybsze będzie łącze, tym poziom zadowolenia będzie wyższy.

Podczas gdy produkt powinien zapewniać odpowiedni stosunek jakości do ceny, powinieneś mieć na uwadze liczbę wdrażanych funkcji podnoszących atrakcyjność twojego produktu. Czasami kluczem do osiągnięcia sukcesu nie jest wdrażanie coraz większej ilości takich funkcji, a stworzenie funkcjonalności, która będzie konkurencyjna na rynku.

• Charakterystyka: To są cechy, o które Userzy wprost proszą i o które walczysz z konkurencją. Zwykle mają liniową zależność między inwestycją a zadowoleniem.

• Wpływ na satysfakcję: liniowa. Szybsze ładowanie = większe zadowolenie.

• Przykład: Szybkość łącza internetowego. Pojemność dysku w chmurze. Zasięg samochodu elektrycznego.

2.3. Funkcje atrakcyjne (Delighter)

Funkcje te są zazwyczaj nieoczekiwane wprost przez użytkowników i jeśli się pojawiają - powodują pozytywną reakcję. W wielu przypadkach wystarczy niewielka inwestycja, która spowoduje wysoki skok satysfakcji.

W związku z tym, że użytkownicy nie myślą o tych funkcjach, ich brak nie spowoduje obniżenia poziomu satysfakcji. Ten aspekt jest również interesujący z jednego względu: funkcje te często nie muszą być doskonałe, aby wywołać pozytywny wpływ na użytkowników.

Zazwyczaj pomagają w budowie grupy lojalnych klientów. Warto inwestować w nie, są warte każdego poświęconego czasu!

• Charakterystyka: Funkcje nieoczekiwane. Jeśli ich nie ma - nikt nie płacze (bo nikt się ich nie spodziewa). Ale jak są? Satysfakcja leci w górę.

• Wpływ na satysfakcję: Mały nakład pracy może dać duży skok lojalności i satysfakcji.

• Przykład: Darmowe ciastko do kawy. Chatbot, który faktycznie rozumie Twój problem i odpowiada na pytanie (pracowałem nad tym w SentiOne 😉).

2.4. Funkcje obojętne (Indifferent)

Ostatnią kategorią są funkcje, których wartość nie ma większego znaczenia na poziom satysfakcji klientów. Nie ważne ile wysiłku włożymy w implementację, użytkownikom będą i tak raczej obojętne.

Obecność lub brak nie stanowi większej różnicy (linia pozioma). Nie warto inwestować czasu na takie funkcje.

• Charakterystyka: Usera to średnio obchodzi. Czy to zrobisz, czy nie - nie będzie wielkiej reakcji.

• Działanie: USUŃ TO Z BACKLOGU / PRODUKTU. Często są to „genialne pomysły" Prezesa, które nie mają pokrycia w realnych zachowaniach użytkownika.

3. Migracja funkcji atrakcyjnych do fundamentalnych

Pamiętaj o jednej ważnej rzeczy: Kategorie nie są dane raz na zawsze. Mogą zmieniać się w czasie.

Funkcja, która przynależy do tych atrakcyjnych, po pewnym czasie może stać się fundamentalną. Wraz z rozwojem technologii i jakości produktów, oczekiwania klientów również rosną. To, co wczoraj było "Delighterem", dziś jest "Performance", a jutro będzie "Must Have".

Przykład z życia: Pamiętasz pierwsze ekrany dotykowe w telefonach? To było coś niesamowitego (Delighter). Potem standardem stała się jakość tego dotyku (Performance). A dzisiaj? Spróbuj wypuścić telefon z klawiaturą fizyczną (no, chyba że celujesz w niszę hipsterów). Dotyk to absolutne „Must-be”.

4. Wykorzystanie Modelu Kano

Określiliśmy czym jest model Kano oraz jego podstawowe kategorie. Jak więc wykorzystać model w praktyce?

4.1. W pierwszym kroku zdefiniuj funkcje, które chciał(a)byś przeanalizować:

Ważnym aspektem tego kroku jest wybranie w miarę możliwości ograniczonej liczby funkcji. Pozwoli Ci to na łatwiejszą priorytetyzację zadań do wykonania. Powinieneś wybrać również tylko i wyłącznie takie funkcje, dzięki którym użytkownik osiągnie jakiekolwiek korzyści.

4.2. Następnie przyporządkuj poszczególną funkcję do danej kategorii:

W celu przyporządkowania funkcji do kategorii odpowiedz na dwa pytania (lub jeżeli masz taką możliwość - koniecznie zapytaj użytkowników twojego produktu):

• Jakie odczucia będą towarzyszyć użytkownikom, jeżeli produkt będzie zawierać funkcję?

• Jakie odczucia będą towarzyszyć użytkownikom, jeżeli produkt NIE będzie zawierał funkcji?

Mając na uwadze poniższe podsumowanie przyporządkuj odpowiedź do jednej z kategorii:

• Funkcje fundamentalne: obojętność użytkownika w przypadku obecności, niezadowolenie w przypadku braku

• Funkcje wydajności: zadowolenie użytkownika w przypadku obecności, niezadowolenie w przypadku braku

• Funkcje atrakcyjne: zadowolenie użytkownika w przypadku obecności, obojętność w przypadku braku

• Funkcje obojętne: obojętność użytkownika w przypadku obecności jak i braku

Dwa pytania, które zostały wymienione powyżej nie są jednoznacznym wyznacznikiem odpowiedzi. Możesz posłużyć się pytaniami pomocniczymi, jeżeli odpowiedzi są niejednoznaczne. Spróbuj znaleźć odpowiedź np. na pytanie: jakie znaczenie ma poszczególna funkcja w skali 1-10?

Jeżeli masz taką możliwość, wykorzystaj większą ilość użytkowników produktu do analizy poszczególnej funkcji.

W uproszczeniu:

• Jeśli User mówi: "Jak jest - to super, jak nie ma - to ok" -> Atrakcyjna (Delighter).

• Jeśli User mówi: "Jak jest - obojętne, jak nie ma - wkurzony jestem" -> Podstawowa (Must-be).

• Jeśli User mówi: "Jak jest - super, jak nie ma - słabo" -> Wydajnościowa (Performance).

4.3. Ustal priorytety dla analizowanych funkcji.

Istnieje wiele ścieżek, które doprowadzą Cię do celu. Jedną z możliwości jest skorzystanie z kolejności (od lewej): funkcje fundamentalne -> wydajności -> atrakcyjne -> obojętne.

W przypadku nowego produktu liczba funkcji fundamentalnych będzie z całą pewnością przeważała nad resztą. W miarę rozwoju aplikacji rozwijane będą głównie funkcje wydajności. Nie możesz zapominać także o funkcjach atrakcyjnych z perspektywy użytkownika. To właśnie te ostatnie spowodują największy wzrost poziomu satysfakcji. Unikaj jednak funkcji obojętnych.

5. Moja praktyka

Kiedy pracowałem w SentiOne nad naszymi botami AI (Automate), mieliśmy miliony pomysłów. Zespół R&D chciał wdrażać najnowsze modele NLP, Handlowcy chcieli integracji z każdym możliwym komunikatorem, a Klienci chcieli po prostu... żeby to działało.

Użyliśmy podejścia w stylu Kano, żeby nie zwariować.

• Must-be: Okazało się, że dla klienta enterprise must-havem nie jest wcale super inteligentne AI, ale bezpieczeństwo danych i stabilność. Bez tego nawet nie chcieli z nami gadać o "inteligencji". Gdybyśmy skupili się tylko na AI, poleglibyśmy na starcie.

• Performance: Skuteczność rozpoznawania intencji (NLU). Im wyższy % poprawnych odpowiedzi bota, tym chętniej klient płacił. Prosta zależność liniowa.

• Delighter: Wprowadziliśmy interfejs "no-code", gdzie każdy mógł wyklikać bota z klocków bez udziału programisty. Klienci byli zachwyceni – to był nasz "wow factor", który wygrywał przetargi.

• Indifferent: Okazało się, że zaawansowane analizy sentymentu w czasie rzeczywistym wewnątrz prostego bota obsługowego mało kogo obchodziły na tamtym etapie.

Co mi to dało? Zamiast budować "wszystko dla wszystkich", skupiliśmy się na tym, co dowozi wartość. Musieliśmy ubić niektóre "fajne" pomysły, ale dla produktu miało to jak najbardziej sens.

6. Podsumowanie

Nie istnieje jednoznaczna odpowiedź na to jak ustalić priorytety w produkcie.

Pomimo tego, że musimy wziąć pod uwagę wiele czynników, zadowolenie klienta z produktu jest bardzo ważne. Powinieneś cały czas monitorować poziom satysfakcji użytkowników.

W przypadku gdy funkcje atrakcyjne w twoim produkcie staną się tymi fundamentalnymi, koniecznie staraj się wdrożyć nowe rozwiązania. Pamiętaj, że unikalne rozwiązania na rynku będą Twoim niezaprzeczalnym atutem.

Co możesz zrobić już dzisiaj? Masz w backlogu funkcję, co do której nie jesteś pewien? Zrób szybki test korytarzowy z 5 użytkownikami używając pytań Kano (Funkcjonalne/Dysfunkcjonalne). Wyniki mogą Cię zszokować.

Dziś rozkładamy na czynniki pierwsze "świętą trójcę" zarządzania produktem: Wizję, Strategię i Roadmapę (+ Product Backlog).

I nie, nie będzie tu teoretyzowania z podręczników akademickich. Pokażę Ci, jak (i po co!) ułożyć te klocki, żeby nie skończyć jako "Backlog Manager", o czym często wspominam w mojej misji pomagania PM-om wyjść poza tę rolę.

Będziemy bazować na konkretach - moich 12 latach doświadczenia (SentiOne, Polska Press, Benefit Systems) oraz świetnym frameworku Product Strategy Stack od Raviego Mehty).

• 1. Big Picture - samo "robienie tasków" to droga d …

• 2. Product Strategy Stack

• 3. Rozbieramy to na części pierwsze

  • 3.1. Wizja

  • 3.2. Strategia (Strategy)

  • 3.3. Roadmapa (Roadmap)

  • 3.4. Product Backlog

• 4. Moja Praktyka

• 5. Podsumowanie

1. Big Picture - samo "robienie tasków" to droga donikąd

Wyobraź sobie, że wsiadasz do taksówki. Kierowca pyta: "Gdzie jedziemy?", a Ty odpowiadasz: "Proszę jechać szybko i efektywnie skręcać w prawo!". Brzmi absurdalnie?

A tak właśnie wygląda praca wielu zespołów produktowych. Świetnie dowożą kolejne zadania i sprinty (jadą szybko), optymalizują procesy (skręcają efektywnie), ale... nikt nie wie, dokąd właściwie zmierzają.

Wdrażanie innowacyjnych produktów to nie kwestia szczęścia. Oczywiście, fuks się przydaje, ale bez zdefiniowanej wizji i strategii oddalasz się od sukcesu, nawet jeśli Twój zespół ma wysokie “velociti” i zamykacie jedną epikę w backlogu po drugiej.

Skupianie się tylko i wyłącznie na najbliższych tygodniach (w Scrumie np. na najbliższym sprincie) bez zdefiniowanej wizji i strategii działania, może doprowadzić Cię do ślepego zaułka.

O ile to podejście może mieć swoje uzasadnienie w warunkach skrajnej niepewności i bardzo dynamicznego środowiska, o tyle sukces każdego rozwiązania zaczyna się od prawidłowych decyzji strategicznych.

2. Product Strategy Stack

W „Product Management Academy” i podczas mentoringów często widzę, że ludzie mylą cele ze strategią ("Naszą strategią jest wzrost o 20%"). Bzdura. Wzrost to wynik (outcome biznesowy). Strategia to plan, jak dojść do naszej wizji produktu i dzięki temu ten wynik biznesowy osiągnąć.

Jak nad tym koncepcyjnie zapanować?

Z pomocą przychodzi Product Strategy Stack od Ravi Mehta. To koncept, który świetnie porządkuje myślenie od ogółu do szczegółu. Wyobraź to sobie jako piramidę:

https://www.ravi-mehta.com/product-strategy-stack/

1. Wizja (Company / Product Mission) - świat, jaki widzisz i zmiana, jaką chcesz wprowadzić. Do jakiej wizji firmy/produktu dążycie? To Twoje "Dlaczego?".

2. Strategia Firmy (Company Strategy) - nawjażniejsze decyzje, jakie firma wyzwania chce zakatować w najbliższym czasie i w jaki sposób (które blokują nas przed dojściem do wizji)

3. Strategia Produktu (Product Strategy) - jak produkt wspiera strategię firmy? Jakie wyzwania produktowe atakujemy, by realizować tę strategię. W przypadku firm jednoproduktowych - strategia produktowa może być tożsama ze strategią produktową.

4. Roadmapa Produktu - plan, sekwencja naszych kroków w czasie, które realizują strategię.

5. Cele Produktowe (Product Goals) - Kwartalne lub miesięcznie cele (outcomes), które mierzą postęp realizacji.

6. Product Backlog - Taktyczne wykonanie. To tutaj lądują zadania które maja doprowadzić do osiągnięcia celów produktów. To w tym miejscu strategia zmienia się w działające rozwiązanie.

3. Rozbieramy to na części pierwsze

Jak więc podejść do rozwoju produktu od ogółu do szczegółu? Potrzebny jest Ci plan zarówno wysokiego poziomu jak i ten zawierający wystarczającą ilość szczegółów. Pomoże Ci w tym zdefiniowanie kolejno wizji, strategii, roadmapy oraz product backlogu.

3.1. Wizja

To Twój North Star" (notabene metryka north star mierzy postęp w realizacji wizji produktu). Odpowiada na pytanie: Dlaczego w ogóle to robimy? 

Wizja musi być inspirująca. Musisz w nią wierzyć. Jeśli Ty nie wiesz, po co robisz ten produkt, Twój zespół tym bardziej nie będzie wiedział.

Kiedy pracowałem nad narzędziami AI w SentiOne, naszą wizją nie było "zrobienie bota". Wizją było zautomatyzowanie obsługi klienta w taki sposób, by człowiek mógł zająć się kreatywnymi zadaniami, a nudną robotę zostawił maszynom.

Według Romana Pichlera wizja powinna charakteryzować się czterema czynnikami: być duża, inspirująca, zwięzła i dostępna.

• Duża wizja, jak np. „bycie świadomymi swoich wydatków” zwiększa szansę na zakup produktu przez osoby z węższą perspektywą, jak np. „chcę zaoszczędzić pieniądze na następne wakacje”. Co więcej, łatwiej jest zmienić strategię (o ile to konieczne) utrzymując jednocześnie taką samą wizję.

• Zwięzłość powoduje, że wizja jest łatwa do zakomunikowania i zrozumienia.

• Wizja inspirująca dostarcza motywacji i nadaje kierunek rozwoju.

• Wizja dostępna ułatwia współpracę, jednoczy ludzi i zapewnia ciągłość w zmieniającym się środowisku.

3.2. Strategia (Strategy)

Strategia to JAK zrealizujemy wizję. Są to nasze najważniejsze decyzje, jakie wyzwania produktowe chcemy zakatować w najbliższym czasie i w jaki sposób (które blokują nas przed dojściem do wizji).

Strategia definiuje:

• Na kim się teraz skupiamy? (Target Audience)

• Na jakim problemie / potrzebie? (Value Proposition)

• Jak wygramy z konkurencją? (Differentiators)

Pamiętaj: strategia to też decyzja, czego NIE robimy.

Istnieje kilka pomocnych technik i narzędzi, które wspierają zdefiniowanie strategii i jej kluczowych elementów: rynku i potrzeb, głównych funkcji oraz celów biznesowych.

Gorąco zachęcam Cię do skorzystania z Value i Business Model Canvas, a także Mapy Empatii, aby odpowiedzieć na kluczowe pytania o naszego użytkownika

Pamiętaj także, że strategia nie jest finalnym planem dla Twojego produktu. Wraz ze wzrostem świadomości czy dojrzałości rozwiązania, Twój plan również powinien ulegać zmianie. Dlatego dokonuj przeglądów Twojej strategii przynajmniej raz na kwartał.

3.3. Roadmapa (Roadmap)

I tu dochodzimy do ulubionego tematu wszystkich stakeholderów ("Na kiedy będzie feature X?"). Roadmapa to opis implementacji strategii w czasie.

Ale… to nie harmonogram w Excelu z datami dziennymi na dwa lata do przodu (to tzw. Gantt chart of death ;)). Dobra roadmapa skupia się na problemach do rozwiązania i celach (outcomes), a nie tylko na liście funkcji (outputs).

Więcej o roadmapie najdziesz tutaj: Roadmapa produktu w środowisku Agile .

3.4. Product Backlog

Na samym końcu znajduje się product backlog, który zawiera szczegóły potrzebne do zrealizowania roadmapy. To tutaj lądują zadania które maja doprowadzić do osiągnięcia celów produktów (w Scrumie historyjki użytkownika i epiki). To w tym miejscu strategia zmienia się w działające rozwiązanie.

Pamiętaj, aby Twój backlog charakteryzował się regułą DEEP:

• Detailed appropriately (odpowiednio szczegółowy – góra backlogu precyzyjna, dół ogólny),

• Estimated (oszacowany),

• Emergent (zmienny – ewoluuje wraz z wiedzą),

• Prioritised (spriorytetyzowany według wartości).

Chciałbym również podkreślić, że zmiany wprowadzane w backlogu produktu mogą mieć wpływ na roadmapę, strategię czy nawet wizję. Zmiany działają więc także w drugą stronę - nie tylko od ogółu do szczegółu.

4. Moja Praktyka

Nie zawsze byłem mądry 😅.

Pamiętam projekt, w którym zachłysnęliśmy się zwinnym podejściem. Robiliśmy fantastyczne sprinty, dowożyliśmy story pointsy jak szaleni. Zespół był zadowolony, Scrum Master płakał ze szczęścia.

Był tylko jeden problem - po pół roku okazało się, że zbudowaliśmy "najlepszy produkt, którego nikt nie potrzebował".

Skupiliśmy się na "małym obrazku" (sprinty, backlog), kompletnie ignorując "duży obraz" (wizja, strategia) :/. Najważniejszy jest balans:

• Zbyt duży nacisk na wizję bez egzekucji = marzycielstwo.

• Zbyt duży nacisk na egzekucję bez wizji = chaos i feature factory.

W SentiOne raz na kwartał robiliśmy "check" naszej strategii - czy nasze założenia są nadal aktualne? Rynek AI zmienia się z dnia na dzień (dosłownie!). Twoja strategia musi być żywa.

Na co uważać? Czego unikać?

1. Mylenie Celów ze Strategią: "Chcemy zarobić milion" to nie strategia. Strategia mówi, czy zarobimy ten milion sprzedając lody Eskimosom, czy AI do dużych banków.

2. Kopiowanie konkurencji: "Oni mają dark mode, to my też musimy".

3. Roadmapa jako lista życzeń interesariuszy: jeśli Twoja roadmapa to zbiór obietnic złożonych każdemu dyrektorowi w firmie, to masz po prostu listę życzeń, a nie realny produktowy plan.

4. Brak połączenia między warstwami: kiedy zespół nie wie, jak ich dzisiejszy task jest powiązany z roadmapą, a najlepiej strategią produktu. To zabija motywację.

5. Podsumowanie

by podsumować wszystko to, o czym napisałem powyżej spójrz proszę na poniższą tabelę:

Co możesz zrobić dzisiaj? Weź swój obecny produkt na warsztat. Zadaj sobie pytanie: czy potrafisz w jednym zdaniu zdefiniować jego wizję? Czy znasz strategię? Jeśli musisz się zastanawiać dłużej niż 10 sekund - wiesz, co masz do zrobienia.

Design Thinking to systemowe podejście do kreowania innowacyjnych rozwiązań złożonych problemów. Coś, co do tej pory wydawało się chaotycznym „wymyślaniem” zarezerwowanym dla nielicznych kreatywnych innowatorów, teraz stało się uporządkowanym procesem prowadzącym do niesamowitych rezultatów, z którego skorzystać może każdy biznes.

Wiele osób myśli, że Design Thinking to warsztaty z kolorowymi karteczkami, pizzą i "kreatywną zabawą". Bzdura. W praktyce to szczery proces weryfikacji, czy Twój genialny pomysł ma sens biznesowy i czy w ogóle rozwiązuje czyiś problem.

Dobre produkty powstają z empatii i twardych danych. Dziś pokażę Ci, jak wykorzystać Design Thinking, żeby nie przepalać budżetu na rzeczy, których nikt nie chce.

• 1. Czym jest Design Thinking?

• 2. Gdzie wykorzystać Design Thinking?

• 3. Proces Design Thinking

  • 3.1. Zdefiniuj problem

  • 3.2. Research / Empatyzacja - zobacz problem oczam …

  • 3.3. Ideacja - wygeneruj pomysły

  • 3.4. Prototypuj i wybierz rozwiązanie

  • 3.5. Implementacja i testowanie

• 4. Moja praktyka

• 5. Efekt końcowy

1. Czym jest Design Thinking?

Mówiąc najprościej: Design Thinking to usystematyzowany proces rozwiązywania złożonych problemów, który stawia człowieka (użytkownika) w centrum.

Pozwala na rozwijanie nowych produktów, usług, biznesów, rozwiązań. Opiera się o empatię (zrozumienie problemów i potrzeb), kreatywność w generowaniu pomysłów oraz racjonalność w analizie i ocenie efektów naszej pracy.

Za ojca metody uznaje się Davida M. Kelley, profesora Uniwersytetu Stanforda, który za cel stosowania Design Thinking uważa „łączenie ludzkich potrzeb z tym, co jest technicznie wykonalne i opłacalne”.

Design Thinking, włącza myślenie projektowe (zarezerwowane dotychczas dla typowych projektantów wzornictwa przemysłowego) do każdego etapu rozwiązywania złożonego problemu i szukania innowacji. Techniki i narzędzia myślenia projektowego mogą się różnić w różnych przypadkach, ale proces zostaje taki sam. Proces pomaga w efektywnym zrozumieniu problemu, ideacji (kształtowaniu) możliwości, wybraniu i wdrożeniu rozwiązania.

Dla mnie, jako Product Managera, to przede wszystkim narzędzie do Product Discovery. To sposób na przejście od mglistego „wydaje mi się" do konkretnego "ten pomysł ma sens".

Opiera się na trzech filarach:

1. Empatia - musisz poczuć ból użytkownika.

2. Kreatywność - generowanie masy pomysłów (ilość > jakość na tym etapie).

3. Racjonalność - chłodna analiza i testowanie.

2. Gdzie wykorzystać Design Thinking?

Design Thinking świetnie nadaje się w każdym momencie tworzenia produktu, kiedy trudno znaleźć jedno „prawidłowe” rozwiązanie. Myślenie projektowe świetnie sprawdzi się przy:

• Tworzeniu nowych produktów i usług - szukasz Product-Market Fit i nie wiesz jeszcze, co dokładnie budujesz.

• Chcesz zredefiniować model biznesowy.

• Masz problem, który jest "wicked" (złożony, niejednoznaczny) - np. w SentiOne chcieliśmy zautomatyzować obsługę klienta za pomocą AI, nie wiedząc jeszcze, jak użytkownicy zareagują na boty.

• Twoje obecne rozwiązania przestały działać i szukasz nowych insightów.

• Znajdywaniu nowych potrzeb Twoich klientów.

3. Proces Design Thinking

Proces Design Thinking składa się z 5 kroków:

Ale uwaga - w życiu to rzadko idzie liniowo. Często będziesz się cofać. I to jest OK.

3.1. Zdefiniuj problem

Na początku trzeba się zastanowić, jaki problem będziemy rozwiązywać. Brzmi prosto i w sposób oczywisty, ale wbrew pozorom, bardzo często już na tym etapie pojawiają się pierwsze problemy.

• Bo jaki właściwie problem chcemy rozwiązać?

• Czy naszym problemem projektowym jest np. zaprojektowanie krzesła, czy może jednak stworzenie miejsca dla osoby przy stole?

Podstawowym zdaniem tej fazy jest zadawanie sobie kwestionujących pytań „dlaczego?” i dzięki temu dobre zdefiniowanie problemu, którym będziemy się zajmować.

W definiowaniu problemów świetnie sprawdzają się takie techniki jak „5 razy Dlaczego?”

3.2. Research / Empatyzacja - zobacz problem oczami użytkownika

Gdy już wiemy jaki problem będziemy rozwiązywać, musimy przeprowadzić jego analizę. Design Thinking stawia na empatyzację i obserwację. Powinniśmy na własne oczy zobaczyć problem i spróbować wczuć się w osoby, których on dotyczy.

Nie zgadniesz, co myśli klient, siedząc w klimatyzowanym biurze. Musisz wyjść "do ludzi". Co robić: Wywiady pogłębione (IDI), obserwacje, "safari" (korzystanie z produktu w naturalnym środowisku).

3.3. Ideacja - wygeneruj pomysły

Kolejnym krokiem jest wygenerowanie przez zespół tak wielu możliwych rozwiązań problemu, jak to tylko możliwe. Nie ma pomysłów dobrych i złych. Nie ma też obszarów, które przy ideacji powinniśmy omijać.

Bardzo ważny jest tutaj zróżnicowany zespół i zaufanie, dzięki któremu nikt nie będzie się bał zaprezentować nawet najbardziej szalonego pomysłu. Zaproś do tego etapu nie tylko deweloperów, ale też support, sprzedaż, a nawet księgową.

Podstawową techniką wspomagającą ideacje jest burza mózgów.

3.4. Prototypuj i wybierz rozwiązanie

Po wybraniu kilku najlepszych rozwiązań powinniśmy przystąpić do ich wizualnego zaprezentowania w formie prototypu. Pozwoli to nam na zaprezentowanie rozwiązań wszystkim zainteresowanym i zebranie feedbacku.

Dlaczego realny prototyp, a nie literacki opis w formie dokumentacji/prezentacji? Bo tylko podczas obcowania z realnym prototypem zainteresowani będą mogli się podzielić szczerymi opiniami, a my zaobserwujemy jak z niego korzystają.

Ważne jest to, żeby nie przesadzać ze skomplikowaniem modeli. Prototyp ma nam pozwolić zebrać szybko feedback. Bardzo często okazuje się, że nasze założenia były błędne i musimy wrócić do generowania pomysłów lub głębszego zrozumienia problemu. Prototyp ma być "good enough", żeby zebrać feedback. Nic więcej.

Do prototypowania fizycznych przedmiotów wystarczy często karton, pisaki, taśma. W przypadku rozwiązań elektronicznych przydane okazują się narzędzia do tworzenia prototypów np. Axure lub Figma, Miro.

3.5. Implementacja i testowanie

Jeśli jeden z naszych prototypów daje nadzieje na sukces, powinniśmy przejść do jego implementacji i wdrożenia w środowisku zainteresowanych osób. Kluczowym jest, by było to realne środowisko, a nie tylko testowe.

Powinniśmy też sobie wyznaczyć realne miary sukcesu: co będziemy mierzyć po wdrożeniu i jaki liczby będą świadczyły o sukcesie przedsięwzięcia. Wdrożenie i mierzenie sukcesu pozwoli nam wyciągnąć wnioski i ulepszać nasze rozwiązanie.

Obserwuj, nie sugeruj. Nie mów: "Tu kliknij, żeby zapłacić". Patrz, jak user męczy się, żeby znaleźć przycisk. To jest Twój insight.

4. Moja praktyka

Kiedy w SentiOne tworzyliśmy SentiOne Automate (platformę do budowy chatbotów i voicebotów), mieliśmy ogromne wyzwanie. Nasz silnik rozumienia języka naturalnego był świetny. Ale jak zbudować do niego interfejs?

Zastosowaliśmy myślenie projektowe, żeby zrozumieć grupę docelową - ludzi z obsługi klienta i projektantów botów, nie z programistów.

1. Empatia: Zrozumieliśmy, że oni nie chcą kodować, albo mogą używać prostej składni.

2. Problem: "Jak pozwolić nietechnicznej osobie zbudować bota?"

3. Rozwiązanie: Interfejs typu "drag & drop", wizualne klocki + prosty język tworzenia bota. Efekt? Stworzyliśmy narzędzie, które pozwala budować konwersacyjne boty bez angażowania zespołu IT.

Zobacz także case study wykorzystania design thinking w fintechu:

Design Thinking Process - case study (fintech)

Case Study wykorzystania procesu Design Thinking w krakowskim fintechu IG do wykrywania i rozwiązywania problemów oraz wspierania kultury współdzielenia wiedzy w organizacji.

www.productacademy.pl/p/design-thinking-process-case-study

5. Efekt końcowy

Końcowym efektem zastosowania procesu Design Thinking będzie głębsze zrozumienie problemu i stworzenie rozwiązania. Może to nie być rozwiązanie idealne, ale przejście przez kolejny cykl Design Thinking coraz bardziej nas do tego idealnego rozwiązania przybliży.

To proces redukcji ryzyka. Pozwala Ci popełnić błędy tanio (na etapie kartki papieru), a nie drogo (po 6 miesiącach kodowania).

Co możesz zrobić jutro? Nie planuj wielkiej rewolucji. Wybierz jeden problem, z którym mierzy się Twój zespół. Zrób jeden wywiad z użytkownikiem albo zbuduj jeden papierowy prototyp nowej funkcjonalności. Sprawdź, co się stanie.

Znasz to uczucie? Odpalasz nową funkcję, zespół świętuje, szampan się leje (albo chociaż kraftowe piwo), dashboardy świecą na zielono… a tydzień później Support zasypany jest zgłoszeniami, że „to nie działa tak, jak powinno”.

Zaczynasz grzebać w danych. Okazuje się, że technicznie wszystko gra. Kod jest piękny. Ale użytkownik po drodze potyka się trzy razy, denerwuje przy logowaniu, a na końcu nie rozumie komunikatu błedu.

Dlaczego? Bo patrzyliśmy na funkcjonalność, a nie na doświadczenie.

Dzisiaj biorę na warsztat temat, który brzmi jak korporacyjny buzzword, ale w praktyce jest fajnym narzędzi w arsenale Product Managera: Customer Experience Mapping. Chodzi w nim o zrozumienie, co tak naprawdę czuje Twój klient, gdy styka się z Twoją marką.

• 1. Co to jest Customer Experience Map?

• 2. Jak wygląda Customer Experience Map?

• 3. Dlaczego Twój produkt potrzebuje CX Mapy?

• 4. Czym to się różni od Customer Journey Map?

• 5. Jak to zrobić krok po kroku?

  • 5.1. Krok 1: Zdefiniuj zakres i cele

  • 5.2. Krok 2: Nie rób mapy w pojedynkę

  • 5.3. Krok 3: Korzystaj z wiedzy, którą już masz w …

  • 5.4. Krok 4: Opieraj się na badaniach

  • 5.5. Krok 5: Jeśli masz twarde dane użyj ich

  • 5.6. Krok 6: Przyłóż się do wizualizacji mapy

  • 5.7. Krok 7: Mapa doświadczeń to niekoniecznie pod …

• 6. Moja praktyka: jak wyłożyliśmy się na braku map …

• 7. Najlepsze praktyki

1. Co to jest Customer Experience Map?

Zacznijmy od prostego wyjaśnienia. Customer Experience Mapping (CX Mapping) to strategiczne narzędzie do wizualizacji i zrozumienia podróży klienta przez różne punkty styku (touchpoints) z Twoją marką lub produktem.

Często widzimy, że nasi użytkownicy mają różne potrzeby, różne doświadczenie czy różne sposoby korzystania z tych samych funkcji.

• Czy możemy w czytelny sposób przedstawić ich zachowania, bez długich elaboratów, opowieści i niekończących się dygresji?

• Czy jest sposób, aby nowym pracownikom pokazać, jak nasz produkt jest wykorzystywany?

• I czy w końcu jesteśmy w stanie łatwo naświetlić obszary, w których idzie nam dobrze i te w których powinniśmy coś poprawić? 

Na szczęście tak. Idealnym narzędziem do zwizualizowania potrzeb naszych klientów jest mapa doświadczeń, Customer Experience Map.

W skrócie: to mapa, która pokazuje nie tylko to, co klient robi, ale też co myśli i czuje na każdym etapie. Od pierwszego kontaktu z produktem, przez użytkowanie, aż po momenty po skorzystaniu.

2. Jak wygląda Customer Experience Map?

Zamiast tysiąca słów, lepiej zobaczyć.

Przykład 1: Rail Europa

Najsłynniejszy przykład to mapa stworzona przez Adaptive Path dla Rail Europe (zobacz tutaj). Pokazuje całą podróż osoby, która korzysta z kolei - od planowania wyjazdu, przez rezerwację, podróż, aż po wspomnienia po powrocie.

Co znajdziesz na tej mapie:

• Etapy procesu (Stages) - kolejne kroki, które przechodzi użytkownik

• Działania (Doing) - co konkretnie robi na każdym etapie

• Myśli i uczucia (Thinking & Feeling) - co mu chodzi po głowie, jakie ma emocje

• Szanse (Opportunities) - gdzie możesz poprawić produkt

Przykład od Adaptive Path przez wielu uważany jest za wzorzec mapy doświadczeń. Jest czytelny, kompleksowy i co ważne, nie wymaga dodatkowego tłumaczenia, a to bardzo ważna cecha customer experience map. Powinna bowiem być tak przedstawiona, aby można było ją powiesić w biurze i zostawić bez dodatkowych wyjaśnień.

Wadą, którą można znaleźć w tym przykładzie jest ogrom informacji, który może przerazić potencjalnych odbiorców. Osoby bardziej wrażliwe estetycznie mogą także zauważyć, że mapa ma, mówiąc delikatnie, oszczędną kolorystykę. Wprowadzenie różnych kolorów do różnych sekcji mogłoby wpłynąć pozytywnie na jej czytelność.

Przykład 2: CX Map z analizą emocji

Drugi przykład pokazuje coś ekstra - wykres emocji. Widzisz dokładnie, gdzie użytkownik jest szczęśliwy (górna strefa, git), a gdzie frustruje się (dolna strefa, do poprawy).

Przykład 3: Starbucks

Na deser mam jeszcze dla Ciebie przykład szczegółowej Customer Experience Map dla słynnego Starbucks

Źródło i szczegółowa wersja mapy.

3. Dlaczego Twój produkt potrzebuje CX Mapy?

Jeśli myślisz "fajne, ale po co mi to", mam dla Ciebie konkretne powody. W gąszczu ticketów na Jira łatwo zapomnieć, że po drugiej stronie ekranu jest człowiek.

Oto co zyskujesz:

• Mamy zebraną kluczową wiedzę w jednym miejscu - mapa powinna w prosty sposób obrazować najważniejsze interakcje klientów z naszym produktem.

• Szerzymy wiedzę o kliencie w firmie - w mapie pokazujemy, że wiemy jak nasz klient korzysta z naszego produktu i wiemy jaki zrobić użytek z tej wiedzy.

• Większa satysfakcja klienta: Kiedy rozumiesz, gdzie boli klienta, możesz to naprawić. Zadowolony klient wraca, poleca i płaci.

• Lepsze decyzje projektowe: Zamiast zgadywać „co by tu zmienić”, masz czarno na białym, gdzie są frustracje (pain points). Jeśli mapa pokazuje, że checkout to koszmar, wiesz, że tam idą zasoby.

• Koniec z silosami: To chyba najważniejsze. Marketing, Sprzedaż, Produkt i Obsługa Klienta często żyją w swoich bańkach. CX Map zmusza wszystkich do spojrzenia na cały obrazek, a nie tylko swój wycinek.

Mimo, że w tekście piszę o wizualizacji korzystania z istniejącego produktu nic nie stoi na przeszkodzie, żeby mapa była wkładem do tworzenia nowych rozwiązań.

Jeśli chcemy usprawnić jakiś proces np. korzystanie z parkingu miejskiego, ale nie mamy jeszcze pomysłu na konkretny produkt, stwórzmy mapę doświadczeń obecnego korzystania z parkingu i na jej podstawie zastanówmy się, w których miejscach możemy go poprawić.

Używałem tego w trzech różnych firmach. Za każdym razem ta sama reakcja: "Kurczę, w końcu rozumiemy, co się dzieje w naszym produkcie".

4. Czym to się różni od Customer Journey Map?

Dobre pytanie! Często używamy tych pojęć zamiennie, ale mimo podobieństw można wyróżnić subtelne różnice:

• Customer Experience Map (CX Map): Jest holistyczna. Obejmuje wszystkie interakcje z marką - od momentu, gdy klient w ogóle dowiaduje się o Twoim istnieniu, przez zakup, aż po lojalność i bycie ambasadorem. Skupia się mocno na emocjach i relacji.

• Customer Journey Map (CJ Map): Jest bardziej celowa i specyficzna. Skupia się na konkretnej ścieżce do osiągnięcia celu (np. „ścieżka zakupu ubezpieczenia” lub „onboarding w aplikacji”).

Werdykt: Jeśli chcesz naprawić konkretny proces - rób Journey Map. Jeśli chcesz zrozumieć kondycję relacji klienta z Twoją firmą i znaleźć strategiczne luki - rób raczej Experience Map.

5. Jak to zrobić krok po kroku?

No dobra, przejdźmy do konkretów. Jak stworzyć taką mapę i nie utonąć w chaosie? Proces ten można zamknąć w 5 logicznych krokach

5.1. Krok 1: Zdefiniuj zakres i cele

Zanim przykleisz pierwszy post-it, musisz wiedzieć „po co?”.

• Określ cel: Czy robisz tę mapę, żeby naprawić jeden konkretny touchpoint (np. formularz kontaktowy), czy chcesz zrozumieć całą podróż klienta od A do Z

• Ustal, co chcesz osiągnąć: Jasno zdefiniuj, jaki jest cel biznesowy tego ćwiczenia. Bez tego skończysz z ładnym obrazkiem, który nic nie wnosi.

5.2. Krok 2: Nie rób mapy w pojedynkę

Najważniejsza zasada: mapa musi być wiarygodna nie tylko dla Ciebie. Jeśli zrobisz ją sam przy biurku, nikt w nią nie uwierzy. Angażuj ludzi o różnych kompetencjach - to pomoże szerzyć wiedzę o kliencie w całej firmie.

Kogo zaprosić do mapowania?

• UX Designerzy/Badacze: to "must have" (najlepiej dwie osoby, jeśli macie podział ról).

• Programiści i Product Managerowie: żeby zderzyć wizję z techniczną rzeczywistością.

• Support i Analitycy: oni wiedzą, gdzie klientów boli najbardziej.

Pamiętaj, że włączanie zespołów wielofunkcyjnych (cross-functional teams) pozwala przełamać wewnętrzne silosy i spojrzeć na doświadczenie całościowo. Dzięki temu budowa mapy nie będzie tylko „fajną zabawą z post-itami”, ale kompleksowym procesem, w którym zderzają się różne punkty widzenia.

5.3. Krok 3: Korzystaj z wiedzy, którą już masz w firmie

Jeżeli mamy w firmie wiedzę o tym jak nasz produkt działa to świetnie - część pracy przy mapie mamy za sobą. Wyniki badań już przeprowadzonych są tak samo dobre jak te, które mamy zamiar przeprowadzić.

Niestety często w firmach znalezienie archiwalnych wyników jest trudniejsze niż by się wydawało. Niby przydałaby się jakaś strona z archiwum, ktoś miał ją zrobić ale nie wyszło. O wynikach wiemy, że ktoś je kiedyś zlecał, opracował wyniki.

W praktyce poszukiwanie archiwalnych badań okazuje się nie lada męczarnią. Dlatego warto wykorzystać to doświadczenie i kolejne przeprowadzone badania archiwizować, tak, żeby dało się je znaleźć np. za rok.

5.4. Krok 4: Opieraj się na badaniach

Mapa doświadczeń to nie miejsce na Twoją wyobraźnię czy osobiste odczucia względem produktu. Musisz wiedzieć, jak klienci go używają. Do tego niezbędne są solidne badania UX.

Możesz użyć różnych metod: wywiady, testy użyteczności, ankiety. U mnie świetnie się sprawdzają tzw. Dzienniczki (Diary Studies):

• Uczestnicy przez tydzień lub dwa opisują korzystanie z produktu

• Możesz czytać wpisy na bieżąco i dopytywać o szczegóły ("Dlaczego tutaj kliknąłeś?").

• Widzisz pełny kontekst - w jakich sytuacjach i z jakich powodów wchodzą w interakcję z produktem.

Po zakończeniu dzienniczków warto spotkać się z uczestnikami na pogłębiony wywiad.

Efekt? Masz nie tylko wiedzę, ale i mnóstwo soczystych cytatów, które sprawią, że Twoja mapa będzie "uczłowieczona" i przekonująca.

5.5. Krok 5: Jeśli masz twarde dane użyj ich

Twarde dane z analiz i ilościowych ankiet są (i pewnie zawsze będą) bardzo ważne. My wiemy, że to nie wszystko. Twarde dane z analityki czy ankiet ilościowych ucinają niepotrzebne dyskusje.

Przykład: Jeśli możesz napisać na mapie, że „75,6% użytkowników korzysta z tej funkcji”, to zamykasz usta sceptykom.

Oczywiście, zdobycie takich danych bywa kosztowne lub czasochłonne. Jeśli ma to zablokować proces na miesiące - odpuść. Mapa bez liczb też ma wartość, ale z liczbami jest po prostu trudniejsza do podważenia.

5.6. Krok 6: Przyłóż się do wizualizacji mapy

Przy tworzeniu mapy dochodzimy do momentu, kiedy czujesz już, jak powinna wyglądać. Masz ją gdzieś naszkicowaną, pokreśloną, oblepioną post-it'ami.

Dla osób zaangażowanych w tworzenie taki produkt jest tak samo dobry, jak pięknie dopracowany, wydrukowany na wielkim formacie projekt graficzny.

Dla osób postronnych jednak tak nie jest.

Nie zapomnij o ostatnim etapie: profesjonalnej wizualizacji. To, co dla zespołu twórczego jest gotowym produktem, dla osób postronnych musi zostać „sprzedane" w atrakcyjnej formie. Dopracowany graficznie projekt pokazuje, ile pracy włożyliście w proces i buduje autorytet dokumentu w firmie.

5.7. Krok 7: Mapa doświadczeń to niekoniecznie podróż jednego użytkownika

Co jeśli masz już opracowane kilka ważnych typów użytkowników produktu? Czy trzeba mapę uśredniać do jednej, pewnie nieistniejącej osoby? Albo wybrać tę najważniejszą?

Oczywiście nie. Jeśli chcesz, możesz na mapie umieścić więcej niż jedną personę i zaprezentować dla nich osobne wykresy emocji. To pokazuje, że ten sam proces może działać świetnie dla jednej grupy, a frustrować drugą.

6. Moja praktyka: jak wyłożyliśmy się na braku mapy?

Pozwól, że podzielę się historią z moich czasów pracy nad produktami AI. Budowaliśmy zaawansowanego czatbota dla jednego z klientów. Nasza Technologia? NLP, AI, automatyzacja. Byliśmy dumni z naszego silnika rozumienia języka naturalnego.

Ale kiedyś postanowiliśmy spojrzeć na to szerzej, właśnie przez pryzmat CX Mapy. Co się okazało?

• Technologia działała: Bot świetnie rozumiał intencje.

• Ale doświadczenie leżało: Użytkownik, zanim dotarł do bota, musiał przeklikać się przez irytujące menu na stronie.

Wniosek? Skupialiśmy się na środku procesu (rozmowa z botem), a ignorowaliśmy to, co działo się PRZED i PO. Klient nie oceniał nas za jakość algorytmu NLP, tylko za to, jak szybko załatwił sprawę.

Gdybyśmy nie zmapowali całego doświadczenia, dalej optymalizowalibyśmy algorytm o 0.5%, zamiast naprawić krytyczny błąd w przekierowaniu rozmowy.

7. Najlepsze praktyki

Zanim rzucisz się w wir warsztatów nad CX Mapą, kilka ostrzeżeń:

• Nie zgaduj! Największy błąd to tworzenie mapy w sali konferencyjnej, bez udziału klientów. Jeśli opierasz się na swoich założeniach („wydaje mi się, że klient to lubi”), to prosisz się o kłopoty. Musisz mieć balans między danymi jakościowymi (wywiady) a ilościowymi (analityka).

• Angażuj inne działy. CX Map robiona tylko przez Product Team wyląduje w szufladzie. Zaproś ludzi z Supportu, Sprzedaży, Marketingu. Oni wiedzą rzeczy, o których Ty nie masz pojęcia.

• Pamiętaj o dostępności. Często zapominamy, że nasi użytkownicy mogą mieć różne ograniczenia. Czy Twoja mapa uwzględnia accessibility?.

• Narzędzia - nie musisz zaczynać od drogiego softu. Kartka i post-ity są super na warsztatch offline. Ale jeśli pracujesz zdalnie to polecam Miro / Mural - aktualnie chyba standard branżowy do warsztatów.
  

Na koniec jesieni mamy dla Was jeszcze info o dwóch wydarzeniach w których maczamy palce:

• 1️⃣ Product Leadership Meetup #5 (czwartek, 27.11) - Lecimy już z piątą edycją naszego meetupu dla product leadershipu 🎉

• 2️⃣ Anty-konferencja Product Hive 2026 - będziemy tam, jesteśmy partnerami, mamy dla Was dodatkowy rabacik (early birds do końca listopada)

Poniżej znajdziesz szczegóły ⤵️

1️⃣ Product Leadership Meetup #5 (czwartek, 27.11)

Lecimy już z piątą edycją meetupu dla product leadershipu 🎉. Tym razem przepracujemy (będzie WARSZTAT) i wymienimy się doświadczeniami w temacie, który jest podstawowym narzędziem każdego lidera produktu w firmie...

Czyli... SPOTKANIA i WARSZTATY 🤝

Warsztaty w tym temacie poprowadzi dla nas Bogumiła Kwiatkowska-Koterba - Senior Product Manager w Żabka.

• 📆 Widzimy się w czwartek, 27 listopada | 20:00 - 22:00.

• 💰 Meetup jak zawsze za FREE, ale obowiązuje selekcja.

Będzie z kim zbić myśli - w meetupach biorą udział VP, CPO, Principal, Lead, Senior PMowie z takich organizacji jak OLX, Allegro, Brand24, Luxmed, Benefit Systems, Żabka, Statscore, HTD, Traffit.

2️⃣ Anty-konferencja Product Hive 2026 (rabacik)

Organizatorzy antykonferencji Product Hive zapraszają na dwa dni intensywnej pracy - 18-19 marca 2026 roku w Warszawie.

W gronie uczestników znajdziesz Product Managerów, Product Ownerów, UX Designerów, programistów, liderów zespołów i innych specjalistów związanych z tworzeniem i rozwojem produktów.

• Dzień 1 (LEARN) – inspirujące keynotes i żywe dyskusje z uczestnikami, prowadzone po angielsku. Będzie też m. in. Roman Pichler czy Gojko Adzic z zagranicznych gości.

• Dzień 2 (SHARE) – swobodne rozmowy, case studies i warsztaty w formule barcampowej - zarówno po polsku, jak i po angielsku. Agenda powstaje wspólnie - współtworzą ją zaproszeni eksperci oraz sami uczestnicy. Każdy może zaproponować własną sesję i zaprosić do niej innych.

W drugim dniu - agenda powstaje wspólnie - współtworzą ją zaproszeni eksperci oraz sami uczestnicy. Równolegle odbywa się kilka sesji w mniejszych grupach, co sprzyja interakcji i wymianie doświadczeń. Każdy może zaproponować własną sesję i zaprosić do niej innych.

📆 Do 31 listopada dostępne są dużo tańsze bilety “Early Bees”.

Dodatkowo, mam od organizatorów dla Was specjalny kod rabatowy 10%. Wystarczy, ze podczas zakupu biletu podacie kod: “PRODUCTACADEMY”

Słyszałeś już o spotkaniach 1:1? A może od dawna prowadzisz je w swoim zespole? Jeśli są one dla Ciebie nowością i chcesz dowiedzieć się co to takiego, wiesz o co w nich chodzi, ale nie wiesz jak się do nich zabrać lub po prostu szukasz pomysłów jak możesz takie spotkania ulepszyć, dobrze trafiłeś.

Opowiem Ci trochę o tym, czym są spotkania 1:1, jakie korzyści niosą i jak je prowadzić, żeby czerpać z nich jak najwięcej.

• 1. Teoria na dobry początek

• 2. Korzyści dla ciebie

• 3. Struktura 1:1

• 4. Przykładowa agenda

• 5. Dobre praktyki realizacji 1:1

• 6. Podsumowanie

1. Teoria na dobry początek

Spotkania 1:1, czy inaczej one-on-one, to regularne spotkania managera z pracownikiem, skupiające się na rozmowie o pracy, sukcesach, wyzwaniach i oczekiwaniach rozwojowych tego drugiego. Mogą one odbywać się raz w tygodniu, raz w miesiącu lub raz na kwartał – wszystko zależy od potrzeb indywidualnych zespołu i jak to najczęściej bywa - czasu.

Ważna rzecz, o której należy pamiętać - 1:1 nie powinny przybierać formy raportowania i nie mają na celu oceny pracownika. Jeśli będziesz wykorzystywać tą okazję do zdania statusu z projektu lub przekazywania swojego (często negatywnego lub – jak to lepiej brzmi – konstruktywnego) feedbacku, pracownik zniechęci się do spotkań a tobie nie przyniosą one pożądanych korzyści. Pamiętaj, że 1:1 to spotkania w głównej mierze “o pracowniku”. Daj mu dojść do głosu, a swój feedback lepiej przekazuj na bieżąco 🙂

2. Korzyści dla ciebie

Z pewnością chciałbyś dowiedzieć się, co dają takie spotkania skoro nie służą one do raportowania i oceny pracy. Mam dla Ciebie kilka korzyści.

2.1. Budowanie relacji

Regularne spotkania 1:1 przede wszystkim dają okazję do budowania głębszej relacji pomiędzy managerem, a pracownikiem. Dla Ciebie, może być to czas na lepsze poznanie członków Twojego zespołu, ich zainteresowań oraz wszelkich krótko- i długoterminowych wyzwań przed którymi stają poza pracą.

2.2. Informacje od wszystkich z zespołu

Z doświadczenia pewnie doskonale wiesz, że na grupowych spotkaniach pewne głosy są głośniejsze. Nie każdy ma możliwość wygłoszenia swojej opinii a osoby bardziej nieśmiałe mogą nie mieć chęci do wypowiedzi na forum.

Spotkania 1:1 dają okazję do wysłuchania opinii każdego członka zespołu w atmosferze poufności. Jest to również świetny sposób, aby dowiedzieć się o wszelkich problemach, które mogą się pojawić w zespole czy sprawdzić jego morale z pierwszej ręki.

2.3. Poznanie celów rozwojowych

Każdy z nas chciałby zatrzymać najlepszych swoim w zespole. Jednym z najważniejszych czynników dla pracownika, który decyduje o jego pozostaniu w organizacji, jest zapewnienie możliwość rozwoju. Spotkania 1:1 tworzą okazję do omówienia aspiracji zawodowych pracownika i dyskusji nad jego możliwymi ścieżkami kariery. Powinniście wspólnie zastanowić się nad tym:

• Jakie umiejętności (zajęcia, certyfikaty, doświadczenie) są potrzebne pracownikowi?

• Jakie zadania i projekty mogą być cenne dla wspierania rozwoju pracownika?

• Jakie są najcenniejsze talenty i umiejętności pracownika?

Spotkania 1:1 są doskonałym miejscem do eksplorowania tych tematów i opracowania kroków, jakie pracownik musi podjąć, aby się rozwijać.

2.4. Okazja do otrzymania feedbacku

Pomyśl, kiedy ostatnio zapytałeś swój zespół o feedback odnośnie Twojej pracy? Jeśli nie miałeś takiej okazji, 1:1 to moment na uzyskanie wartościowych opinii na swój temat. Pytanie wprost “Co sądzisz o mojej pracy?” może nie jest najlepszym pomysłem (bądźmy szczerzy – nikt nie chce podpaść szefowi). Spróbuj zapytać o to, w jaki sposób możesz wspierać pracownika np. w rozmowie o jego wyzwaniach lub rozwoju lub jakie działania możesz podjąć, żeby zespół był bardziej efektywny.

3. Struktura 1:1

Co omawiać na spotkaniach 1:1, szczególnie jeśli odbywają się one cyklicznie? 1:1 nie muszą być nudne ani powtarzalne, ale mogą mieć pewne wspólne elementy. Tematy do poruszenia mogą być różne i zawsze powinny być dostosowane do waszych potrzeb.

Zaproponuję wam kilka, które osobiście uważam za najważniejsze:

• Kluczowe sukcesy i wyzwania.

• Nadchodzące projekty.

• Cele rozwojowe i plany kariery.

• Sposób w jaki możesz wspomóc pracownika w jego pracy.

• Pogawędka o życiu, hobby, rodzinie.

Pamiętaj o robieniu notatek! Zapisuj wszystko, co uznasz za ważne. Z pewnością nie raz ustalicie między sobą kolejne kroki, które będziecie chcieli podjąć w danym temacie. Bez notatek ciężko będzie do nich wrócić na początku kolejnego spotkania. Pamiętaj, żeby notatki zawsze przejrzeć PRZED spotkaniem.

4. Przykładowa agenda

• 5 minut – Hello! – nieformalna rozmowa o hobby, rodzinie, planach wakacyjnych itp. Chodzi o to, żeby mieć ogólny pogląd o nastroju pracownika i wiedzieć co się u niego dzieje.

• 5 minut – Update i podsumowanie – bazując na swoich notatkach, sprawdź czy udało się wam wykonać działania zaplanowane na poprzednim 1:1.

• 25 minut – Sukcesy i wyzwania – zapytaj pracownika o jego ostatnie sukcesy i wyzwania oraz o to, jaki wpływ miały one na zespół/firmę/jego rozwój. To również dobra okazja, żeby dowiedzieć się czego potrzebuje od ciebie lub od zespołu.

• 5 minut – Rozwój kariery – sprawdź jakie działania pracownik ostatnio podjął w celu dalszego rozwoju.

• 10 minut – Gorące tematy – omówcie to, co będzie się działo w najbliższym czasie, niezależnie od tego, czy będzie się to tyczyć spraw firmowych czy personalnych.

• 10 minut – Wszystko inne – przedyskutujcie inne tematy, które chcielibyście poruszyć.

5. Dobre praktyki realizacji 1:1

Teorię, korzyści i strukturę prowadzenia spotkań 1:1 już poznałeś. Przejdźmy do spraw organizacyjnych. W spotkaniach 1:1 obowiązuje kilka dobrych praktyk, o których warto pamiętać.

5.1. Długość spotkania

Mówi się, że spotkanie 1:1 powinno trwać godzinę, ale tak naprawdę jego długość zależy od ciebie. To może być godzina, 30 minut lub nawet mniej. Niech trwa tak długo, jak to konieczne, aby omówić wszystkie ważne tematy.

5.2. Zaproszenie

Po twojej stronie, jako managera, leży organizacja spotkania i wysłanie zaproszenia do pracownika. Jeśli masz taką możliwość, zostaw sobie 15-minut wolnego przed kolejnym spotkaniem, na wypadek, gdyby wasza rozmowa się przedłużyła.

5.3. Odwołanie

Nawet jeśli coś ci wyskoczyło i nie możesz uczestniczyć w zaplanowanym spotkaniu, nie odwołuj go. To bardzo ważna zasada. Rozważ skrócenie spotkania lub przeprowadzenie go telefonicznie a w najgorszym wypadku przełóż je na inny dzień. Gdy często odwołujesz 1:1, wysyłasz wiadomość do pracownika, że on i jego sprawy są dla ciebie nieistotne.

5.4. Częstotliwość

Pisałam już wcześniej, że częstotliwość spotkań zależy od potrzeb indywidualnych. Możesz organizować spotkania raz w tygodniu, 2 razy w miesiącu czy raz na kwartał. Kluczem jest zaplanowanie ich w regularnych odstępach czasu, najlepiej jako cykliczne wydarzenie w waszych kalendarzach.

5.5. Lokalizacja

Nie zawsze 1:1 musi odbywać się w firmowej salce konferencyjnej. Jeśli masz taką możliwość, weź pracownika na kawę do pobliskiej kawiarni.

5.6. Uważność

Pamiętaj o wyciszeniu telefonu, zamknięciu laptopa i skupieniu się na rozmowie. Jeśli prowadzisz rozmowę online, lepiej zamknij wszystkie okna przeglądarki i wycisz Slack’a. Powtórzę się tutaj – to czas dla was.

5.7. Agenda

Aby spotkania były bardziej efektywne, przygotuj sobie wcześniej agendę. Potraktuj ją jako swego rodzaju checklistę, pilnując, żeby wszystkie najważniejsze punkty spotkania zostały omówione (przykładową agendę znajdziesz w dalszej części artykułu). Oczywiście zdarzają się sytuację, w których agendę wyrzucamy przez okno i prowadzimy długą, swobodną rozmowę, jednak w większości przypadków agenda zdecydowanie pomaga.

5.8. Komunikacja

Jeżeli podczas spotkania mówisz więcej niż słuchasz, robisz to źle. Spróbuj wypracować sobie środowisko, w którym pracownik mówi przynajmniej przez 70% czasu. Ćwicz zadawanie pytań zamiast mówić ludziom, co myślisz 🙂

5.9. Atmosfera

Spotkaniach 1:1 zdecydowanie powinny mieć nieformalną atmosferę. To nie jest czas na pokazywanie hierarchii i raportowanie. Dodatkowo, stwórz atmosferę wzajemnego szacunku i zaufania. Jestem przekonana, że przyniesie to korzyści obu stronom.

6. Podsumowanie

W zasadzie to tyle albo aż tyle. Mając powyższe wskazówki powinieneś być gotowy na wprowadzenie spotkań 1:1 w swoim zespole. Jeśli wcześniej takie spotkania prowadziłeś, mam nadzieję, że znalazłeś coś nowego dla siebie. Śmiało możesz wprowadzać swoje modyfikacje pamiętając, że przede wszystkim mają one służyć tobie. Pamiętaj o dobrych praktykach wspomnianych w artykule i o robieniu notatek!

Zakończyliśmy właśnie największa edycję Product Management Academy w historii, ale… w końcówce roku nie zwalniamy tempa. Mamy dla Was kolejne inicjatywy:

• 1️⃣ Kolejna edycja 10x Product Bootcamp - tym razem na warsztat bierzemy temat product discovery - użycie AI do testowania i prototypowania pomysłów

• 2️⃣ Otwarcie zapisów na kursu Akademii Analityki Produktowej - ​po dłuższej przerwie ponownie udostępnimy do sprzedaży kurs AAP

• 🔐 Accountability Group w zamkniętej społeczności naszych absolwentów.

Poniżej znajdziesz szczegóły ⤵️

1️⃣ Kolejna edycja 10x Product Bootcamp

Planujemy z uruchomienie 2 edycji 10x Product Bootcamp. W pierwszej edycji Bootcampu wzięło udział ponad 100 osób, a kilkadziesiąt osób zrobiło swojego produktowej co-pilota 🎉.

Tym razem na warsztat bierzemy temat product discovery - użycie AI do testowania i prototypowania pomysłów.

Zmieniamy też formułę - dalej stawiamy na praktykę i naukę przez realizację projektu, ale wiemy jak ciężko samodzielnie pracować z AI-em. Dlatego tym razem będziemy mieli 6-dni warsztatów, na których wspólnie pracujemy

Informacje o starcie sprzedaży wraz ze wszystkimi szczegółami wyślemy jak zawsze do osób zapisanych na listę zainteresowanych ⤵️

2️⃣ Otwarcie zapisów na kurs Akademii Analityki Produktowej

Wiele osób pisało i pytało o ten kurs: “Kiedy będzie można ponownie dołączyć?”. Ugięliśmy się i jeszcze w listopadzie otworzymy na tydzień możliwość zakupu Akademii Analityki Produktowej.

Jeśli chcesz nauczyć się się wykorzystywać metryki, frameworki i narzędzia analityki produktowej (Mixpanel) do podejmowania lepszych decyzji i tworzenia doskonałych produktów - to kurs dla Ciebie.

📆 Start sprzedaży: 24 listopada 2025.

🔐 Accountability Group #1

Tylko dla absolwentów naszych szkoleń (członków kampusu Product Academy) startujemy zupełnie nową inicjatywę - Accountability Group - wspólne 30 dniowe zobowiązanie.

Ile razy mówiłeś/aś sobie: "Powinienem/-am wdrożyć X w swojej pracy"... i zostało to tylko na etapie planów? Ja wiele razy :D. Dlatego startujemy z Accountability Group. Zaczynamy z grupą z ostatniej edycji PMA, ale zapraszam do dołączenia chętnych z całej społeczności Product Academy.

Jak to działa?

1. Wybierasz jeden konkretny cel na 30 dni (np. "zrobię 5 user interviews", "wdrożę framework X", cokolwiek produktowego), przedstawiasz swój cel innym, dodajesz do wspólnego trackera

2. Co poniedziałek przez 4 tygodnie robisz krótki check-in - co zrobiłeś, co dalej, co blokuje

3. Na koniec wspólne spotkanie online, gdzie dzielimy się swoimi doświadczeniami i efektami z tego miesiąca..

To eksperyment. Może zadziała, może nie. Ale warto spróbować.

📆 Zapisy trwają do soboty, 15 listopada.

Ale to nie wszystko - w przyszłym tygodniu będziemy mieli dla Was jeszcze kilka nowości - stay tuned :)

Pamiętasz ten moment, kiedy po raz pierwszy wysłałeś wiadomość na Slacku i w sekundę dostałeś odpowiedź od kolegi z zespołu? Albo kiedy Grammarly po raz pierwszy podkreślił Ci błąd w mailu, który właśnie miałeś wysłać do klienta?

To właśnie był Twój Aha moment z tymi produktami. I właśnie dlatego dalej z nich korzystasz.

Jeśli nie wiesz, jaki jest Aha moment w Twoim produkcie, to masz problem. Bo bez tego strzelasz na ślepo, próbując zrozumieć, dlaczego użytkownicy zostają (albo uciekają po pierwszej wizycie).

Dzisiaj rozkładamy Aha moment na czynniki pierwsze - czym jest, dlaczego decyduje o sukcesie produktu i jak go odkryć w swoim produkcie.

Table of Contents

• 1️⃣ Aha moment - co to jest?

• 2️⃣ "Aha! Moment" - po co jest? Do czego służy?

• 3️⃣ Przykłady Aha moment dla popularnych aplikacji

• 4️⃣ Jak odkryć "Aha! Moment"?

• 5️⃣ Jak prowadzić użytkowników do Aha momentu?

• 6️⃣ Podsumowanie: Aha moment to fundament Twojego …

1️⃣ Aha moment - co to jest?

Aha moment to konkretna chwila, kiedy użytkownik po raz pierwszy doświadcza realnej wartości Twojego produktu. To moment elektryzującego olśnienia: „O cholera, to naprawdę działa!”.

Nie chodzi o ładny onboarding, nie o fajny UX. Chodzi o moment, w którym produkt rozwiązuje realny problem użytkownika, a on to wyraźnie czuje.

• Dla Google była to sekunda, w której po wpisaniu zapytania zobaczyłeś dokładnie to, czego szukałeś.

• Dla Facebooka - moment, kiedy po rejestracji zobaczyłeś zdjęcia swoich znajomych ze szkoły.

• Dla Canvy - kiedy w 5 minut stworzyłeś profesjonalnie wyglądającą grafikę, mimo że nigdy nie używałeś Photoshopa.

„Aha moment” vs aktywacja

Uwaga - „Aha moment” to nie to samo co aktywacja, choć często używa się tych pojęć zamiennie.

• Aha moment = użytkownik doświadcza wartości ("wow, to mi pomoże!")

• Aktywacja = użytkownik faktycznie zaczyna używać produktu w rzeczywistych sytuacjach

Aha moment prowadzi do aktywacji. Bez tego pierwszego nie ma szans na drugie.

2️⃣ "Aha! Moment" - po co jest? Do czego służy?

Krótka odpowiedź: bez odkrycia Aha momentu nie osiągniesz product-market fit. I to nie jest przesada.

Mówiąc najprościej - cała Twoja praca oraz wysiłki Twojego zespołu powinny być ukierunkowane na odkrycie “Aha! Momentu”, a następnie - na jego wyskalowanie.

Wszystkie Twoje produktowe wysiłki kręcą się wokół słynnego AARRR (Acquisition, Activation, Retention, Referral, Revenue). Aha moment to fundament aktywacji - bez niego reszta nie ma sensu. Co ważne, jeśli odkrycie „Aha momentu” będzie dla użytkownika trudne lub niedostępne przy pierwszej wizycie, możesz bezpowrotnie stracić szansę na ponowne zaangażowanie go w twój produkt.

Co daje Ci zdefiniowanie Aha momentu?

1. Rozumiesz, jaką obietnicę wartości realizujesz z perspektywy klienta

Nie z perspektywy roadmapy. Nie z perspektywy stakeholderów. Z perspektywy osoby, która faktycznie płaci (czasem, pieniędzmi lub uwagą) za Twój produkt.

2. Projektujesz eksperymenty, które masowo przybliżają użytkowników do tego momentu

Zamiast bezmyślnie dodawać funkcje, skupiasz się na tym, co naprawdę robi różnicę. Każdy flow onboardingowy, każda notyfikacja, każdy email – wszystko prowadzi użytkownika do Aha momentu.

3. Tworzysz narrację dla działań marketingowych

Marketing nie mówi już "mamy super funkcje". Marketing mówi: "w 10 minut stworzysz swoją pierwszą kampanię" (Mailchimp) albo "w 7 dni połączysz się z 10 znajomymi" (Facebook).

4. Jeśli nie odkryłeś Aha momentu w swoim produkcie, to:

• Nie wiesz, co sprawia, że użytkownicy zostają (albo uciekają)

• Nie rozumiesz, jaki problem faktycznie rozwiązujesz

• Optymalizujesz metryki, które mogą być kompletnie nieistotne dla retencji

3️⃣ Przykłady Aha moment dla popularnych aplikacji

Teoria teorią, ale zobaczmy, jak to wygląda w praktyce. Oto kilka przykładów Aha momentów z produktów, które pewnie znasz.

Facebook: 7 znajomych w 10 dni

Zespół w Facebooku odkrył prostą zależność: użytkownicy, którzy w ciągu pierwszych 10 dni połączyli się z minimum 7 znajomymi, zostawali na platformie praktycznie na zawsze.

Dlaczego? Bo w tym momencie Facebook przestawał być pustym profilem, a stawał się miejscem, gdzie dzieje się coś interesującego. Zdjęcia z imprez, dyskusje w komentarzach, plany na weekend – wszystko w jednym miejscu.

Kiedy dotarłeś do tego momentu, myśl "sprawdzę, co na Facebooku" stała się nawykiem.

Twitter: 50 obserwowanych kont

Podobnie Twitter - użytkownik, który zaobserwował minimum 50 innych kont, miał znacznie większe szanse zostać aktywnym userem.

Dlaczego? Bo w tym momencie Twój feed zaczyna być ciekawy. Dostajesz wartościowy content, śmieszne tweety, breaking newsy. Twitter przestaje być pustką, a staje się źródłem informacji i rozrywki.

Slack: 2000 wiadomości w zespole

Slack odkrył, że kiedy zespół wymieni 2000 wiadomości, prawdopodobieństwo długoterminowego używania platformy rośnie drastycznie.

Nie chodzi o sam fakt wysłania 2000 wiadomości. Chodzi o to, że w tym momencie Slack staje się centrum komunikacji zespołu. Zespół przestaje pisać maile, przestaje się gubić w wątkach, zaczyna żyć Slackiem.

Canva: pierwszy design

Dla Canvy Aha moment to prosty: użytkownik tworzy swój pierwszy design.

I nie chodzi o to, że użył szablonu. Chodzi o to, że w 5 minut stworzył coś, co wygląda profesjonalnie – mimo że nigdy nie używał narzędzi graficznych. To moment: "wow, ja naprawdę to zrobiłem!".

4️⃣ Jak odkryć "Aha! Moment"?

Okej, widzisz przykłady, rozumiesz koncepcję. Ale jak to odkryć w swoim produkcie?

Mam dla Ciebie dobrą i złą wiadomość:

• Dobra: Aha moment zawsze istnieje w Twoim produkcie (jeśli w ogóle masz product-market fit)

• Zła: Nie ma jednego uniwersalnego sposobu na jego odkrycie. Musisz kopać.

Co warto zrobić:

1. Zidentyfikuj swoich power userów

Weź 10-20% najbardziej zaangażowanych użytkowników - tych, którzy korzystają regularnie, najrzadziej churnują i najchętniej polecają produkt. To Twoja złota kopalnia insightów.

2. Przeprowadź z nimi wywiady

Nie pytaj wprost „kiedy był Twój Aha moment?" - ludzie nie potrafią na to odpowiedzieć. Zamiast tego spyta::

• „Jak wspominasz moment rejestracji?”

• „Z których funkcji skorzystałeś na początku? Dlaczego?”

• „Kiedy odczuwasz wyraźną przyjemność z pracy z produktem?”

• „Kiedy po raz pierwszy pomyślałeś: wow, to działa?”

Wsłuchaj się w to, czego nie mówią wprost. Aha moment często siedzi w anegdocie, w szczególe, w emocji.

3. Zanurz się w danych behawioralnych

Używaj narzędzi analitycznych takich jak Mixpanel, Amplitude. Mają one zwykle konkretne dashboardy, który mogą Ci ułatwić poszukiwania:

• Path analysis – jaką drogę przechodzą użytkownicy, którzy zostają vs. ci, którzy churnują?

• Funnel analysis – gdzie użytkownicy dropują?

• Cohort analysis – porównaj zachowania różnych grup

• Event tracking – śledź konkretne akcje

4. Szukaj wzorców

• Jakie akcje powtarzają się u power userów w pierwszych dniach?

• Które funkcje używają najczęściej ci, którzy zostają?

• Jaka jest minimalna "dawka" zaangażowania potrzebna do retencji?

5. Testuj hipotezy przez A/B testy

Stwórz onboarding flows prowadzące do różnych potencjalnych Aha momentów. Zobacz, który flow daje najwyższą retencję. Dane nie kłamią.

Z mojego doświadczenia bardziej złożone produkty mogą mieć kilka Aha momentów, w zależności od persony użytkownika i use case'u. Możesz wtedy nie szukać jednego magicznego momentu dla wszystkich. Szukaj wzorców w różnych segmentach.

Jak to wygląda w praktyce?

Jakub Tutaj napisał szczegółowy artykuł na ten temat, w którym rozpisał cały proces krok po kroku, z konkretnymi przykładami i narzędziami. Warto zajrzeć!

Jak znaleźć pierwszy „Aha! moment” w Twoim produkcie? Case Study

Jak poradzić sobie w sytuacji, gdy nie znamy „Aha! momentu” naszych użytkowników?

www.productacademy.pl/p/jak-znalezc-pierwszy-aha-moment-w-twoim-produkcie

5️⃣ Jak prowadzić użytkowników do Aha momentu?

Okej, znalazłeś Aha moment. Co teraz? Teraz musisz zrobić wszystko, żeby użytkownicy do niego dotarli - i to jak najszybciej.

Badania pokazują, że im szybciej użytkownik dotrze do Aha momentu, tym większa szansa na długoterminową retencję. Jeśli nie dotrze w pierwszych dniach (czasem godzinach) – może już nie wrócić.

1. Personalizuj onboarding dla różnych segmentów

Różne persony = różne Aha momenty = różne onboarding flows.

Nie próbuj prowadzić wszystkich użytkowników tą samą ścieżką. To jak próba wsadzenia kwadratu do okrągłej dziury.

Jak to zrobić:

Welcome survey - na początku zapytaj użytkownika, kim jest i co chce osiągnąć. Na podstawie odpowiedzi triggeruj odpowiedni flow.

Przykładowo dla narzędzia produktami/projektami w startupie:

• „Jestem PM-em, chcę zarządzać roadmapą” → Flow skupiony na tworzeniu roadmap

• „Jestem developerem, chcę śledzić zadania” → Flow skupiony na board'ach i issue tracking

• „Jestem founderem, chcę zarządzać całym produktem” → Flow pokazujący overview całego systemu

Każda persona ma inny Aha moment. Dostosuj onboarding.

2. Używaj „interactive walkthroughs”

„Interactive walkthrough” = step-by-step guide, który nie tylko pokazuje, ale też zmusza użytkownika do wykonania akcji.

Dlaczego to działa? Bo sam fakt pokazania czegoś nie oznacza, że użytkownik to zrozumie. „Learning by doing” jest 10x bardziej efektywne.

Jak to zrobić:

• Tooltip 1: "Kliknij tutaj, żeby utworzyć pierwszy projekt"

• Tooltip 2: "Świetnie! Teraz dodaj pierwsze zadanie"

• Tooltip 3: "Ostatni krok – zaproś członka zespołu"

Użytkownik faktycznie przechodzi przez proces, nie tylko go ogląda. Zwiększa to drastycznie szansę na dotarcie do Aha momentu.

3. Pokaż kluczowe funkcje od razu (ale nie przytłaczaj)

Nowy użytkownik widzi Twój produkt pierwszy raz. Może być przerażony. Musisz mu pokazać, co jest ważne, ale nie możesz go przytłoczyć.

Przy pierwszym logowaniu - pokaż główne obszary UI, wyjaśnij, do czego służą. Krótko, zwięźle, z benefitami.

• ❌ Źle: "To jest sidebar I menu. To jest top bar."

• ✅ Dobrze: "Tutaj znajdziesz wszystkie swoje projekty. Tutaj stworzysz nowe zadania. A tutaj zobaczysz postępy zespołu."

Zawsze mów o benefitach, nie o funkcjach.

4. Usuń „friction” z całej ścieżki użytkownika

Friction = wszystko, co spowalnia lub blokuje użytkownika w drodze do „Aha momentu”.

Najczęstsze źródła friction:

• Za długi “welcome survey” (5+ pytań)

• Zbyt skomplikowany onboarding (integracje, konfiguracje)

• Brak jasnej ścieżki ("co teraz powinienem zrobić?")

• Zły UX (nieprzejrzyste UI, ukryte funkcje)

• Paywall za wcześnie (chcesz doświadczyć wartości, ale musisz zapłacić)

Jak znaleźć „friction”:

• Funnel analysis – gdzie użytkownicy dropują?

• Session recordings – gdzie się gubią, gdzie klikają w złe miejsca?

• User feedback – co ich frustruje?

5. Testuj, optymalizuj, powtarzaj

Nie ma jednego idealnego onboardingu. Musisz testować różne podejścia i patrzeć, co działa.

A/B testy:

• Testuj różne wersje „welcome survey”

• Testuj różne kolejności kroków w onboardingu

• Testuj różne copy (CTA, headery, opisy)

Mierz:

• Completion rate onboardingu

• Time to „Aha moment” (ile czasu mija od rejestracji do Aha momentu?)

• 7-day retention (ilu użytkowników wraca po tygodniu?)

• 30-day retention (długoterminowa retencja)

Iteruj. Onboarding to nigdy nie jest „GOTOWY”. Zawsze możesz go ulepszyć.

6️⃣ Podsumowanie: Aha moment to fundament Twojego produktu

Jeśli zapamiętasz tylko jedną rzecz z tego artykułu, niech to będzie ta:

Aha moment to nie tylko teoria i kolejny buzzword. To konkretna, mierzalna chwila, która decyduje, czy użytkownik zostanie, czy odejdzie.

Facebook wiedział, że to 7 znajomych w 10 dni. Slack wiedział, że to 2000 wiadomości. Twitter wiedział, że to 50 obserwowanych kont.

A Ty? Czy wiesz, jaki jest Aha moment w Twoim produkcie?

Jeśli nie - masz robotę do zrobienia. Zacznij od rozmów z power userami, zanurz się w danych, postaw hipotezy, testuj. Odkrycie Aha momentu to nie sprint, to maraton. Ale kiedy go znajdziesz - wszystko inne stanie się prostsze.

Bo zamiast strzelać na ślepo, będziesz dokładnie wiedział, gdzie prowadzić użytkowników. I jak sprawić, żeby zostawali na dłużej.

Jeśli trudno Wam w zespole zrozumieć jak działa produkt z punktu widzenia użytkownika, Wasze Epiki i User Stories są dziwnie prozbijane, to warsztat User Story Mapping jest absolutnie tematem dla Ciebie. Powiedzmy sobie jednak szczerze – komu coś takiego nigdy się nie zdarzyło? 😉

Nie ma wtedy sensu szukać winnych i przerzucać się odpowiedzialnością (z jednej story: „user story i epiki były słabo opisane!”, z drugiej strony: „nie przeczytałeś dokładnie user story!”). Reagujmy proaktywnie i minimalizujmy ryzyko braku wspólnego zrozumienia problemu. To właśnie w tym ma pomóc koncept user stories. Metodę user story mapping możesz zaś potraktować jako user stories na resorach.

Przykładowy User Story Map

O samych podstawach nie będę się rozpisywał, gdyż zrobił to już Damian Reweda w poradniku User Story Mapping - mapowanie historyjek użytkownika . Napiszę tylko tyle, że wartość techniki rośnie wprost proporcjonalnie z liczbą niewiadomych w produkcie i jego skomplikowaniu. Im projekt jest bardziej niejasny, tym bardziej opłaca się skorzystać z mapowania historyjek.

Cena kilku godzin całego zespołu jest naprawdę niska wobec znacznego ograniczenia późniejszych problemów komunikacyjnych i frustracji (jak wiemy projekty nie udają się nie dlatego, że ktoś czegoś nie umiał zrobić, a dlatego, że zawiodła komunikacja).

Skupię się natomiast na kilku radach - jak dobrze przeprowadzić warsztat User Story Mappingu z mojego doświadczenia.

• 1. Agenda warsztatu User Story Mapping

• 2. Jak poprowadzić warsztat?

  • 2.1. Organizacja

  • 2.2. Moderacja

  • 2.3. Rozgrzewka

  • 2.4. Rozbudowywanie mapy

  • 2.5. Wykorzystanie

• 3. User Story Mapping zdalnie?

• 4. A co z Event Storming?

• 5. Podsumowanie

1. Agenda warsztatu User Story Mapping

Zacznijmy od agendy, którą najczęściej stosuję na warsztatach (godziny są przykładowe). Taka intensywna, jednodniowa sesja może przebiegać w następujący sposób:

• 9:00 - 9:45 – przedstawienie celu i zasad warsztatu, ćwiczenia rozgrzewkowe

• 9:45 - 10:15 – definiowanie person (ćwiczenie grupowe)

• 10:15 - 10:30 – przerwa

• 10:30 - 12:30 – mapowanie (uczestnicy wspólnie umieszczają post-ity na tablicy, ustalanie flow, grupowanie i porządkowanie)

• 12:30 - 13:30 – przerwa obiadowa (podczas przerwy moderator może dodatkowo uporządkować mapę)

• 13:30 - 15:00 – wstępna wycena post-itów przez zespół programistyczny, product owner dzieli mapę zgodnie z kolejnością wydań

• 15:00 - 15:15 – przerwa

• 15:15 - 16:15 – product owner wraz z zespołem programistycznym wycenia pierwsze wydanie

• 16:15 - 16:30 – podsumowanie

Taka agenda user story mappingu to intensywny, ale niezwykle produktywny dzień. W praktyce przypomina sprint discovery - dużo interakcji, wspólnego myślenia i porządkowania chaosu w głowach zespołu.

Kluczowe jest tu tempo i struktura:

• zaczynasz od wspólnego celu i zbudowania kontekstu,

• potem przechodzisz przez poznanie użytkowników (persony),

• a następnie mapowanie całego doświadczenia krok po kroku.

Przerwy są nieprzypadkowe - to momenty na złapanie dystansu i uporządkowanie mapy (często moderator robi wtedy mały „cleanup” na tablicy).

Popołudnie to już moment decyzji - estymacje, priorytetyzacja i podział na wydania.

Efekt? Zespół kończy dzień z klarownym obrazem produktu, wspólnym językiem i pierwszą wersją roadmapy, która faktycznie ma sens.

2. Jak poprowadzić warsztat? Najważniejsze wskazówki

Przeprowadzenie takiej sesji nie jest szczególnie skomplikowanym zadaniem. Zasady są proste, a forma bardzo angażująca dla uczestników. Jeśli w Twojej firmie nie ma nikogo, kto ma doświadczenie warsztatowe, to jestem przekonany, że sam sobie poradzisz.

Jest jednak kilka rzeczy, o których IMHO warto pamiętać. Poniżej przedstawiam pięć moich doświadczeń, które pomogą przeprowadzić taki warsztat:

2.1. Organizacja

Na spotkaniu na pewno musi być obecny cały zespół programistyczny, designer i product owner (oraz klient w przypadku projektu zewnętrznego). Mile widziani byliby przedstawiciele biznesu (sponsor, marketing, sprzedaż), natomiast na pewno sam dobrze wyczujesz, kogo z Twojej firmy dodatkowo zaangażować. Nie przesadź jednak z liczbą uczestników. Wbrew pozorom im mniej osób zaprosisz, tym większe jednostkowe zaangażowanie uzyskasz (12 osób to moim zdaniem maksimum).

Zadbaj o to, by zespół zarezerwował sobie na warsztat cały dzień. Odpowiednio wcześniej wyślij zaproszenie na spotkanie poprzez kalendarz, aby nikt o nim nie zapomniał i miał na niego przeznaczony czas. Potrzebne jest pełne skupienie. Najlepiej gdyby uczestnicy w tym dniu nie musieli zaglądać do komputerów. Oczywiście laptopy w sali są wykluczone! Może to być brutalne, ale wyniesienie z sali krzeseł również wpłynie pozytywnie na aktywność.

W pewnym momencie warsztatu zorientujesz się, że ciężko zapanować nad post-itami. Dlatego przygotuj karteczki w różnych kolorach oraz kartki w formacie A3 i A4. Bardzo przydaje się również technika poprawnego przyklejania post-itów 😉

2.2. Moderacja

Przyznam, że nie jestem fanem przeprowadzania warsztatów przez lidera projektu (produktowca). Powodem jest tak zwany efekt badacza, kiedy nieświadomie kierujemy dyskusję w kierunku preferowanego przez nas rozwiązania. Poza tym po prostu nie da się zarówno uważnie moderować i myśleć kreatywnie, a czynne zaangażowanie produktowca w mapowanie jest bardzo ważne. Dlatego rekomendowałbym przekazanie odpowiedzialności za przeprowadzanie warsztatu na np. product designera.

Jeżeli jednak uważasz, że jesteś najlepszą osobą do moderacji takiego spotkania, to postaraj się po prostu dać uczestnikom dużo swobody w budowaniu mapy. Pamiętaj jednak, że jako product owner jesteś… no właśnie, ownerem! Ostateczne decyzje jak „przyciąć” i wykorzystać mapę należą absolutnie do Ciebie.

2.3. Rozgrzewka

Jeżeli przeprowadzacie warsztat po raz pierwszy, to poświęć pierwsze 30 minut na ćwiczenia rozgrzewkowe. Wspólnie z zespołem zastosujcie metodę user story mapping do wymodelowania flow typowego poranka. Następnie wymodelujcie go przy scenariuszu, gdy na „zebranie się” macie 15 minut (czy będziesz w obozie konieczności umycia zębów, czy też w opozycji? ;)).

Dzięki rozgrzewce bardzo dobrze zrozumiecie zasady mapowania, a cała grupa przystąpi do docelowego ćwiczenia w dobrych humorach i z pełnym zaangażowaniem.

2.4. „A co z tym?”, czyli rozbudowanie mapy o dodatkowe warunki

„A co z tym?” to podejście rekomendowane przez Jeffa Pattona. Uczestnicy warsztatu analizują poszczególne karteczki, zadając pytania typu „a co jeśli się zepsuje?”, „a co jeśli użytkownik nie poradzi sobie z obsługą”, itd.

Wynikiem jest rozbudowanie mapy o dodatkowe warunki czy przypadki brzegowe, o których mogliście nie pomyśleć (mapowanie ryzyka), a także o wiele dodatkowych, kreatywnych pomysłów.

Skutkiem ubocznym jest znaczny rozrost mapy i późniejsze trudności z jej organizacją. Podczas dalszej pracy należy zatem koncentrować się na głównych składowych flow, a pozostałymi zająć się już poza warsztatem.

2.5. Wykorzystanie

User story mapping to technika, która nie jest zarezerwowana tylko dla dużych projektów. Gdy czujecie, że dane zadanie nie jest do końca jasne, zawsze w kilka minut możecie rozrysować je w formie post-itów według zasady “mapuj tylko to, co jest potrzebne do opowiedzenia historii o funkcji” (Jeff Patton). To technika zwinna. Stosujcie ją więc po prostu kiedy chcecie i jak chcecie.

Jeff Patton radzi, powołując się na koncepcję „grzejnika informacyjnego” (A.Cockburn, Agile Software Development), by efekty pracy zespołu pozostawiać na ścianie. Ma to kilka zalet. Po pierwsze przez kolejne tygodnie działa to na Was inspirująco (pojawiają się nowe pomysły). Po drugie buduje zaciekawienie, a finalnie zrozumienie zadań Waszego zespołu przez resztę organizacji. Po trzecie daje Wam poczucie, że idziecie z pracami według większego planu. Wpływa to bardzo pozytywnie na morale.

3. User Story Mapping zdalnie?

Nie ma żadnych przeszkód by przeprowadzać warsztaty user story mapping zdalnie. Jeśli chodzi o rekomendowane narzędzie, to mogę polecić Miro/Mural.

Trzeba jednak przyznać, że to właśnie kreatywne sesje grupowe tracą najwięcej na braku bezpośredniego kontaktu. Dużą zaletą mapowania historyjek są bowiem dynamiczne interakcje między uczestnikami. Moderator ma też lepsze możliwości wpływu na grupę, a zwłaszcza na mniej zaangażowane lub wycofane osoby.

4. A co z Event Storming?

Metoda user story mapping jest często mylona z event storming. Obie techniki działają w sposób podobny. Różnicą jest to, że:

• User story mapping skoncentrowane jest na zbudowaniu flow aplikacji (odpowiadamy na pytanie „kiedy?”) i mocniej pobudza myślenie kreatywne.

• Event storming jest natomiast metodą, którą poleca się do bardziej szczegółowej analizy i głębszego wchodzenia w problem z perspektywy procesów i funkcji (odpowiadamy na pytanie „co?”).

Warto dodać, że to pierwsze spotkanie dedykowane jest zwłaszcza nowym przedsięwzięciom, natomiast drugie lepiej sprawdza się przy działających procesach.

Można również uogólnić, że user story mapping to technika, z której najwięcej wyciągnie produktowiec i osoby odpowiedzialne ze strategię, zaś event storming to spotkanie na którym prym wiodą analitycy biznesowi i programiści.

Przy rozpoczęciu pracy z nowym produktem dobrą praktyką jest przeprowadzenie warsztatu user story mapping, by dobrze zrozumieć flow, a następnie pogłębienie sesji za pośrednictwem warsztatu event storming. Oczywiście możesz spróbować połączyć oba spotkania lub wybrać tylko jedno. Na zakończenie warsztatu user story mapping możesz poprosić zespół programistyczny o wycenienie post-itów w ramach story pointów, natomiast na warsztacie event storming zajmiecie się ich rozbiciem na mniejsze zadania i dopracowaniem wycen.

5. Podsumowanie

Projekty z reguły nie udają się nie dlatego, że zabrakło umiejętności, a dlatego że zawiodła szeroko pojęta komunikacja. Im dłużej pracuję jako product manager, tym bardziej utwierdzam się w przekonaniu, że to właśnie umiejętności komunikacyjne są kluczowe na tym stanowisku. User story mapping to jedna z najlepszych technik, by zapewnić zrozumienie problemu przez wszystkie zaangażowane osoby. Te warsztaty są nie tylko bardzo pożyteczne, ale i ekscytujące! Warto dać im szansę, a metodę wdrożyć na stałe do naszego trybu pracy.

Wiele osób pytało, więc finalnie podjęliśmy decyzję - będą dodatkowe bilety na najbliższą edycję Product Management Academy 2025 (23 września – 4 listopada 2024).

Ze względu na duże zainteresowanie jesienną edycją, postanowiliśmy uruchomić dodatkową, 3️⃣ grupę warsztatową PMA (warsztaty co tydzień w czwartek: 9:00 - 12:00).

• ⏰ W czwartek o 7:00 wystartuje ponownie otwarta sprzedaż. Będzie dostępnych ok. 10 biletów. Dam Ci o tym znać mailowo.

• ➡️ Jeśli jednak jesteś już teraz zdecydowana (-a) albo zainteresowany (-a) ale masz wątpliwości - odpisz na tę wiadomość. Będziemy wiedzieli jak dużą grupę planować oraz będziemy mogli dograć najlepszy sposób płatności z Tobą (wiemy, że oferta jest last minute i może wymagać indywidualnego podejścia) / odpowiedzieć na Twoje wątpliwości.

Jeśli masz jakiekolwiek pytania lub wątpliwości - jestem po drugiej stronie i odpowiadam na maile :).

Czym jest Product Management Academy 🎓?

Każda kolejna edycja PMA to coś wyjątkowego - 6-tygodniowy intensywny program warsztatów z product managementu, prowadzony przez doświadczonych praktyków zarządzania produktami. Program, dzięki któremu wejdziesz na wyższy poziom zarządzania produktami.

📆 Na uczestników czekają cotygodniowe warsztaty w grupach (5x 3h), a dodatkowo - indywidualne zadania, spotkania LIVE z mentorami, dodatkowe materiały online, ćwiczenia i wsparcie zamkniętej społeczności.... Warsztaty prowadzimy w 3 grupach (swoją grupę wybierasz przy zakupie biletu):

• w grupie czwartkowej porannej (czwartki, 9:00 - 12:00)

• w grupie czwartkowej popołudniowej (czwartki, 16:30 - 19:30) [WYPRZEDANE]

• w grupie porannej (piątek, 9:00 - 12:00) [WYPRZEDANE]

Zobacz szczegółowy harmonogram spotkań (sekcja "Program warsztatów i spotkań"). Nie pasuje Ci jakiś termin spotkania? Nic straconego, wszystkie będą nagrywane.

Kampus Product Academy, gdzie odbywa się Akademia

Za cel postawiliśmy sobie przygotowanie programu, po którym uczestnik będzie mógł wziąć najważniejsze narzędzia / koncepty / frameworki produktowe i od razu zastosować je w swojej pracy. Tak, jak my sami je stosujemy na co dzień.

NPS poprzedniej edycji to 95, a średnia ocen uczestników to 4,6 / 5 😍. Zobacz podsumowanie edycji 2023 oraz całą masę publicznych ocen uczestników na naszym profilu LinkedIn.

👩‍🏫 Prowadzących warsztaty product managerów znajdziesz na LinkedIn: Tomek Tomaszewski (Product Academy, ex-Head of Product w SentiOne) oraz Olga Springer (Senior Product Manager w Altassian). Naszą wiedzę uzupełnią też dodatkowi mentorzy (doświadczeni praktycy product managmentu), którzy pojawią się w trakcie Akademii.

Do usłyszenia! 🖐️
--
Tomek Tomaszewski
Product Academy

W drugiej części lata mamy dla Ciebie kilka inicjatyw:

• 1️⃣ Ostatnia tura biletów na Product Management Academy 2025 - startujemy w czwartek o 7:00

• 2️⃣ Product Strategy Meetup #3 - ​kolejne spotkanie liderów produktu, którzy mierzą się z wyzwaniami w budowaniu i wdrażaniu strategii produktowej.

• 3️⃣ Społeczność 10x - aplikuj do zamkniętej wersji BETA.

Poniżej znajdziesz szczegóły ⤵️

1️⃣ Ostatnia tura biletów na Product Management Academy 2025

Dwie pierwsze tury biletów na jesienną edycję Product Management Academy (23.09 - 4.11) wyprzedały się zaledwie w kilka godzin.

⏰ W czwartek o 7:00 uruchamiamy sprzedaż ostatnich kilku biletów.

Informacje o starcie sprzedaży wraz ze wszystkimi szczegółami wyślemy jak zawsze do osób zapisanych na listę zainteresowanych PMA ⤵️

2️⃣ Społeczność 10x

Właśnie trwa 10x Product Bootcamp - prawie 100 osób realizuje własne projekty wdrażające AI w ich pracę produktową 🛠️. Jednak to dopiero początek 🚀.

Wierzymy, że budowanie produktów właśnie przechodzi fundamentalną zmianę. Najlepsi liderzy produktowi już dziś wychodzą poza swoją tradycyjną rolę, by działać 10x szybciej, podejmować trafniejsze decyzje i zdobywać kompetencje, które wcześniej wymagały całych zespołów. To nie tylko AI, ale AI jest katalizatorem tej zmiany.

Dlatego budujemy społeczność 10x - miejsce, w którym ambitni i doświadczeni liderzy produktowi dzielą się doświadczeniami, eksperymentują i wspólnie się napędzają.

Start wkrótce, ale już dziś można aplikować do zamkniętej BETY ⤵️

3️⃣ Product Strategy Meetup #3 | 4.09, 20:00

Mamy już potwierdzoną kolejną edycję naszego Product Strategy Meetupu - angażującego meetup online, na którym liderzy produktowy dzielą się swoim doświadczeniem i wiedza.

📆 Spotkanie odbędzie się w czwartek, 4 września o godzinie 20:00.

• ​To meetup, nie webinar - spotykamy się online, by wymieniać się doświadczeniami

• ​Selekcja uczestników - tylko mający doświadczenie i wpływ na strategię produktową (PM, Head of Product, Founderzy)

• ​Lightning Talks, dyskusje + wymiana doświadczeń w małych grupach (4-5 osób)

• ​Brak nagrań, brak AI-notatek, by mówić szczerze o realnych wyzwaniach

👉 Temat spotkania oraz możliwość aplikacji na wydarzenia uruchomimy w drugiej połowie sierpnia. Damy znać mailowo :).

W międzyczasie możesz zasubskrybować kalendarz Product Academy na Lu.ma, gdzie znajdują się nasze wydarzenia ⤵️

Design Thinking Process to hasło, które w ostatnim czasie zyskało ogromną popularność. Internet pęka w szwach od artykułów, definicji i grafik ilustrujących ten proces. Założę się o dobrą caffe latte, że większość osób z branży IT już o nim słyszała, a pozostali usłyszą lada moment.

Z uwagi na tę popularność, nie chcę powielać ogólnodostępnych definicji. Zamiast tego, skupię się na konkretnym studium przypadku i moich doświadczeniach z tą metodą. Chcę pokazać jej uniwersalność i dodatkowe korzyści, które nie zawsze są widoczne na pierwszy rzut oka.

• 1️⃣ Dlaczego potrzebujemy Design Thinking w pracy …

  • 1.1. Kto, kiedy, po co i jak? Czyli jak należy ten …

  • 1.2. Kiedy sięgnąć po Design Thinking?

  • 1.3. Niezbędne Narzędzia w Procesie Design Thinkin …

• 2️⃣ Case Study: Tydzień z Design Thinking w naszym …

  • 2.1. Czwartek: Empatia i Definiowanie Problemu

  • 2.2. Poniedziałek: Zanurzenie w Dane i Przełamywan …

  • 2.3. Wtorek: Krok w tył, dwa kroki do przodu

  • 2.4. Środa: Detale, półmetek i informacja zwrotna

  • 2.5. Czwartek: Czas na "Design Crita"

  • 2.6. Piątek: Finałowa prezentacja i testy

• 3️⃣ Podsumowanie i "Lessons Learned"

Kim jestem i dlaczego o tym piszę?

Nazywam się Magdalena Ptak - na co dzień mam przyjemność pracować jako UX Designer i prowadzić zespół Designerów Produktów w jednym z krakowskich fintechów (IG). Praca projektanta w tak wymagającej i delikatnej domenie biznesowej, jaką są finanse, bywa sporym wyzwaniem.

Wcześniej współpracowałam z kilkoma Krakowskimi Software House’mi, realizując projekty dla: The Coca-Cola Company HQ, Heineken, T-Mobile, Porsche Austria, Farmfoods, Tesco, Payfont (mobile IOS App), Polo Ralph Lauren, ASDA, Macys, Michael Kors, American Bankers Association

1️⃣ Dlaczego potrzebujemy Design Thinking w pracy produktowej?

W typowym modelu scrumowym zespoły produktowe, w skład których wchodzą Product Designerzy, realizują kolejne kamienie milowe z roadmapy produktu. Ta roadmapa jest często wypadkową wymagań biznesu, czasem kompromisem wypracowanym przez Product Ownera uwzględniającego perspektywę techniczną. Bądźmy jednak szczerzy – to biznes najczęściej definiuje kierunek rozwoju produktu, co jest zrozumiałe, bo produkt musi na siebie zarabiać.

Mam jednak głębokie przekonanie, że prawdziwe zaangażowanie zespołu i poczucie sensu płyną ze wspólnie wypracowanych celów. I to jest właśnie idealne miejsce na zastosowanie Design Thinking Process.

1.1. Kto, kiedy, po co i jak? Czyli jak należy ten cały Design Thinking Process poprowadzić?

Jako UX Designerzy, nasza codzienna praca naturalnie krąży wokół technik związanych z Design Thinking. Łączymy wymagania biznesu z możliwościami technologii, a przede wszystkim jesteśmy adwokatami użytkownika końcowego. Skupiamy się na definiowaniu i rozwiązywaniu problemów.

Product Designerzy i UX Designerzy wydają się predysponowani do roli facylitatora w tym procesie, ponieważ posiadają unikalny zestaw kompetencji:

• Umiejętności miękkie: empatia, aktywne słuchanie, obserwacja, świetna komunikacja.

• Zrozumienie technologii: zdolność pojmowania technicznych zawiłości.

Ten miks jest bezcenny podczas planowania i moderowania warsztatów z zespołem deweloperskim, interesariuszami i wszystkimi osobami w organizacji, których wiedza może okazać się kluczowa.

1.2. Kiedy sięgnąć po Design Thinking?

Design Thinking Process jest narzędziem, z którego warto skorzystać zawsze, bywają jednak momenty w cyklu pracy zespołu, kiedy wręcz trzeba to zrobić. Z mojego doświadczenia wynika, że taki moment nadchodzi, gdy pojawia się stagnacja w zespole, a morale jego członków spada.

Warto wówczas zebrać interesariuszy i cały zespół projektowy w jednym pokoju, stworzyć atmosferę równości i bezpieczeństwa, tak aby każdy z obecnych był w stanie swobodnie podzielić się pomysłami dotyczącymi usprawnienia produktu.

Podczas etapu generowania idei kluczowa jest jedna zasada: liczą się pomysły, a nie rola osoby, która się nimi dzieli!

Technicznie można to zorganizować w kilku krokach:

1. Stwórz "Kreatywną Ścianę Pomysłów": Każdy uczestnik zapisuje swoje pomysły na samoprzylepnych karteczkach i umieszcza je na wspólnej tablicy.

2. Moderuj i zapewnij równość: Zadaniem facylitatora jest dbanie o to, by każdy głos został usłyszany i każda karteczka znalazła się na tablicy.

3. Przedstaw i pogrupuj pomysły: Wszystkie idee są prezentowane, a autorzy mają szansę je doprecyzować. Podobne pomysły są grupowane w kategorie.

4. Zagłosuj na najlepsze idee: Każdy uczestnik otrzymuje określoną liczbę głosów (np. 3) i oddaje je na pomysły, które uważa za najbardziej wartościowe.

5. Wybierz pomysł do realizacji: Na koniec wybierana jest idea, która zyskała największe poparcie i jest realna do opracowania w ograniczonym czasie.

Po takim spotkaniu każdy powinien czuć, że jego wkład był ważny. To buduje zaangażowanie na dalszych etapach.

1.3. Niezbędne Narzędzia w Procesie Design Thinking

• Logistyka (Kalendarz, E-mail): Kluczowe jest odpowiednio wczesne zaplanowanie warsztatów i poinformowanie uczestników. Zgranie kalendarzy kilkunastu osób bywa wyzwaniem, dlatego szanujmy swój czas, ustalajmy agendy i bądźmy przygotowani.

• Miro (Wirtualna Tablica): Niezastąpione narzędzie do współpracy w czasie rzeczywistym. Idealne do planowania procesu, zbierania pomysłów i podsumowywania pracy.

• Figma (lub inne narzędzie do prototypowania): Niezbędna do wizualizacji i prezentacji proponowanych rozwiązań w formie interaktywnych makiet.

2️⃣ Case Study: Tydzień z Design Thinking w naszym Zespole

Cały proces osadziliśmy w ramach jednego, intensywnego tygodnia pracy, który poprzedziliśmy około dwutygodniowym okresem przygotowań logistycznych. Oto jak wyglądał nasz warsztatowy tydzień, dzień po dniu.

2.1. Czwartek: Empatia i Definiowanie Problemu

Wybraliśmy czwartek jako start naszego sporintu. Pierwsze spotkanie z całym zespołem produktowym i kluczowymi interesariuszami miało na celu zidentyfikowanie największych bolączek i wyzwań.

• Cel spotkania: Stworzenie bezpiecznej przestrzeni do swobodnej wymiany myśli i zdiagnozowanie problemów z perspektywy różnych ról w zespole.

• Przebieg warsztatu:

  • Burza mózgów: Każdy uczestnik zapisywał na samoprzylepnych karteczkach zarówno problemy, które dostrzega w produkcie lub procesie, jak i pomysły na nowe funkcjonalności. Celowo nie ograniczaliśmy formy, aby uzyskać jak najszerszy obraz sytuacji.

  • "Kreatywna ściana": Wszystkie karteczki trafiły na wspólną tablicę, tworząc mapę myśli całego zespołu.

  • Głosowanie: Każdy otrzymał trzy głosy, aby wskazać tematy, które uważa za najważniejsze.

• Kluczowe odkrycie: Po podliczeniu głosów wyłoniliśmy trzy najistotniejsze kwestie. Po krótkiej dyskusji wspólnie zdecydowaliśmy się skupić na jednym, konkretnym problemie, który miał największy potencjał do rozwiązania w ciągu nadchodzącego tygodnia.

• Moment "Aha!": Największą wartością tego spotkania było to, że interesariusze po raz pierwszy usłyszeli, jak bardzo frustrujące dla deweloperów jest kodowanie banerów marketingowych "ad hoc". Uświadomili sobie, że te zadania odciągają zespół od realizacji kluczowych celów z roadmapy produktu.

2.2. Poniedziałek: Zanurzenie w Dane i Przełamywanie Silosów

9:00 rano na zegarku oznacza, że mamy 5 pełnych dni, aby postarać się i „dowieźć” rozwiązanie na wyselekcjonowany problem. Otwieramy miro – i patrzymy na plan, a następnie po kolei dzwonimy do wcześniej wytypowanych osób (mając przygotowane pytania i agendę), które pomogą nam zgromadzić więcej informacji i uzupełnić luki w naszej wiedzy.

• Plan działania: Otworzyliśmy naszą tablicę w Miro, przejrzeliśmy plan i z przygotowaną listą pytań zaczęliśmy kontaktować się z ekspertami w całej organizacji.

• Przełamywanie barier: To był dzień intensywnych rozmów, które pozwoliły nam przełamać firmowe "silosy informacyjne". Skontaktowaliśmy się z:

  • Periklisem z zespołu Data Science,

  • Elizą i Caitillin z Marketing & Content,

  • Shobaną, która jest deweloperką webową.

• Wszyscy wspomniani wcześniej dzielą się z nami wiedzą i pomagają nam zrozumieć ich perspektywę, pojawiają się nowe dane i nowe pytania, na tym etapie mamy wrażenie, że, mamy więcej pytań, niż odpowiedzi.

• Efekt: Pod koniec dnia nieśmiało próbujemy zrobić pierwszy design – szkic na ścianie pokoju konferencyjnego, jest na nim wiele znaków zapytania i pustych przestrzeni, nie jesteśmy do niego bardzo przywiązani – więc jako doświadczenia UX Designerzy liczymy się z tym, że kolejnego dnia rano, po przyjściu do pracy i spojrzeniu na tą pierwszą iterację krytycznym okiem – być może stwierdzimy kolektywnie, że ją zmazujemy!

2.3. Wtorek: Krok w tył, dwa kroki do przodu

9:00 rano, 2 UXów i 1 UI Designer, otwierają miro board oraz krytycznym okiem oceniają wczorajszą pierwszą iterację rozwiązania na ścianie. Wspólnie stwierdzamy, że zbyt szybko chcieliśmy rysować rozwiązanie, a za mało jeszcze wiemy i rozumiemy.

Robimy krok w tył, konsultujemy kilka niewiadomych z deweloperami, sprawdzamy co jest możliwe do zaimplementowania ze strony technicznej – biorąc pod uwagę ograniczenia technologii i dług technologiczny. Robimy pracę UXową „od podstaw”:

• Zmiana strategii: Zdecydowaliśmy się zrobić krok w tył, aby lepiej zrozumieć fundamenty problemu.

• Działania:

  • Konsultacje techniczne: Ponownie spotkaliśmy się z deweloperami, aby dogłębnie zrozumieć ograniczenia technologiczne i istniejący dług techniczny.

  • Praca UX "od podstaw": Zaczęliśmy od narysowania szczegółowego diagramu procesu. Umieściliśmy w nim kluczowe role ("aktorów") oraz zdefiniowaliśmy interakcje i zależności czasowe między nimi. Musieliśmy najpierw rozłożyć stary proces na czynniki pierwsze, aby móc zbudować nowy.

  • Digitalizacja: Pod koniec dnia przenieśliśmy nasze odręczne szkice i diagramy do Figmy, co stanowiło solidną podstawę do dalszej pracy.

2.4. Środa: Detale, półmetek i informacja zwrotna

Środek tygodnia zaczęliśmy od spotkania z zespołem produktowym i biznesem (niemal ten sam skład, który uczestniczył w pierwszym spotkaniu, gdy wybieraliśmy problem dla naszego warsztatu z Design Thinking Process).

Chcieliśmy podzielić się informacjami, które zebraliśmy oraz przedstawić kierunek, w którym chcielibyśmy pójść proponując rozwiązanie. Miro i figma pomogły nam lepiej zwizualizować koncepty i wytłumaczyć co robiliśmy dotychczas oraz co planujemy w kolejnych krokach. Dostaliśmy informację zwrotną od wszystkich zaangażowanych, nastąpiła kolejna wymiana wiedzy, doświadczyliśmy wielu momentów „aha”, bez dwóch zdań był to wartościowy czas.

• Spotkanie z zespołem: Zorganizowaliśmy spotkanie w niemal tym samym składzie, co na początku.

  • Cel: Podzielenie się zebranymi informacjami i przedstawienie wstępnej koncepcji rozwiązania.

  • Narzędzia: Użyliśmy Miro i Figmy, aby zwizualizować nasze postępy i ułatwić zrozumienie proponowanych zmian.

  • Wynik: Otrzymaliśmy bezcenną informację zwrotną i doświadczyliśmy wielu momentów "aha", gdy różne osoby zaczęły łączyć kropki.

• Ciągła komunikacja: Poza oficjalnym spotkaniem, byliśmy w stałym, nieformalnym kontakcie z Product Ownerem, Tech Liderem i głównym interesariuszem. To pozwoliło nam na bieżąco weryfikować założenia i unikać potencjalnych błędów.

• Postępy: Dzień zakończyliśmy z drugą, znacznie bardziej szczegółową wersją diagramu oraz pierwszą wersją klikalnego prototypu w Figmie.

2.5. Czwartek: Czas na "Design Crita"

Prototyp gotowy, jest czwartek godzina 10:30 – dla nas i naszego zespołu Product Designerów to dzień, kiedy nastaje cotygodniowy czas konstruktywnej krytyki od naszych kolegów po fachu. Jest to moment, w którym uzasadniamy swoje decyzje projektowe, tłumaczymy, dlaczego wybraliśmy to, a nie inne rozwiązanie.

• Sesja konstruktywnej krytyki: "Design Crit" to nasz cotygodniowy rytuał, podczas którego prezentujemy projekty i bronimy swoich decyzji projektowych.

• Przebieg: Zespół zadawał dociekliwe pytania i rzucał wyzwanie naszym założeniom. Krytyka nie jest tu brana do siebie - jej celem jest stworzenie jak najlepszego produktu.

• Wynik: Koledzy zwrócili uwagę na kilka niedopracowanych "edge case'ów" (skrajnych przypadków użycia), którym nie poświęciliśmy wystarczającej uwagi. Mieliśmy jeszcze pół dnia, aby poprawić te sporne miejsca w prototypie przed finałową prezentacją.

2.6. Piątek: Finałowa prezentacja i testy

Koniec tygodnia to czas, aby zaprezentować wynik naszej przeszło tygodniowej, warsztatowej pracy. O ustalonym czasie i miejscu, stawili się wszyscy uczestnicy, którzy wzięli udział w pierwszym spotkaniu.

Zanim przeszliśmy do przedstawienia propozycji rozwiązania, przedstawiliśmy uczestnikom kilka danych, jakie udało nam się zebrać w trakcie procesu, które dodatkowo podkreśliły istotność wziętego na warsztat problemu.

Jedną z takich informacji było wyliczenie i zestawienie na podstawie danych historycznych dwóch metryk obrazujących, że kodowanie banerów marketingowych ad hoc, pochłonęło porównywalną liczbę roboczogodzin co stworzenie wersji MVP jednego z większych feature’ów w portalu (dashboardu dla klientów). Zestawienie tych dwóch danych, umocniło zasadność wybranego problemu oraz dało podwaliny dla argumentacji naszego rozwiązania, dlaczego warto zainwestować czas, aby stworzyć kompleksowe rozwiązanie.

• Rozpoczęcie prezentacji: 

  • Finalna prezentacja rozpoczęła się od przypomnienia problemu, czyli: „W jaki sposób serwować treści marketingowe na jednym z portali – minimalizując przy tym zaangażowanie zespołu deweloperskiego (deweloperów i testerów)”.

  • Podczas prezentacji, poinformowaliśmy zespół o naszych odkryciach, czyli dodatkowych narzędziach (CQ, Adobie Audience Manager), używanych do serwowania i segmentowania treści marketingowych w innych zespołach oraz o możliwości ich użycia w kontekście naszego produktu.

  • Omawiając prototyp, zaproponowaliśmy nowych aktorów w procesie publikacji oraz przedstawiliśmy ich workflow w czasie. Postaraliśmy się też wytypować dodatkowe osoby, których pomoc będzie niezbędna w zaimplementowaniu nowego procesu (czyli dostosowanie i wdrożenie istniejących narzędzi) oraz wykazaliśmy orientacyjne estymacje pracochłonności. Ponadto odkryliśmy, że nie da się zupełnie wyłączyć QA testera z zespołu produktowego z nowego procesu, ponieważ zanim nowe treści marketingowe zostaną opublikowane i tak cały portal musi być sprawdzony i przetestowany.

• Prezentacja rozwiązania:

  • Konstruując rozwiązanie problemu, oprócz wizualizacji i prototypu, staraliśmy się przedstawić dane, obrazujące takie metryki jak ilość osób, zaangażowanych w nowy proces + koszt zaimplementowania nowego procesu + możliwe predykcje (jaki będzie koszt gdy zostawimy stary proces, a jaki gdy wdrożymy nowy przy zainwestowaniu zasobów w tym momencie). Te wszystkie dane zostały przedstawione na ostatnim spotkaniu.

  • Jako Designerzy i facylitatorzy Design Thinking Proces postaraliśmy się „połączyć wszystkie kropki w skończonym czasie” oraz opracować możliwe do zaimplementowania rozwiązanie dla zdefiniowanego wcześniej problemu.

  • Decyzję czy i kiedy warto je wdrożyć – pozostawiliśmy Product Ownerowi i interesariuszom.

Wierzymy, że dzięki warsztatom z Design Thinking Process, zespół produktowy otrzymał solidną instrukcję jak pozbyć się problemu, biznes natomiast dowiedział się o problemie, który frustruje członków zespołu i całkiem sporo kosztuje firmę.

3️⃣ Podsumowanie i "Lessons Learned"

Czego się nauczyliśmy przeprowadzając warsztaty z Design Thinking Process?

1. Wiedza w zespole nie jest równa. Osoby techniczne często nie czują sprawczości. Design Thinking pomaga wyrównać wiedzę i oczyścić atmosferę.

2. Duże organizacje mają problem z dzieleniem się wiedzą. Dotarcie do właściwych osób bywa trudne. Rola facylitatora wymaga rozwiniętych umiejętności miękkich.

3. Design Thinking to proces definiowania rozwiązania, a nie jego wdrażania. Implementacja to osobny, wymagający projekt.

4. Facylitacja to praca na pełen etat. Prowadzenie warsztatów DT wymaga zaangażowania co najmniej dwóch osób i trudno to pogodzić z innymi obowiązkami.

5. Proces jest intensywny i nie zawsze kończy się sukcesem. Mimo to, jest niezwykle satysfakcjonujący. Pod koniec tygodnia czuliśmy się wyczerpani, ale i spełnieni.

6. Otrzymaliśmy bardzo pozytywny feedback od wszystkich zaangażowanych osób.

7. Nasze rozwiązanie do dziś czeka w kolejce na wdrożenie. Jako designerzy wciąż czekamy na ten moment, by poczuć pełne spełnienie.

Nasz Proces w Liczbach:

• Dni: 7 (+1 dzień na planowanie)

• Osób zaangażowanych: 25 (+ 17 designerów na Design Crit)

• Spotkań: 3 duże + niezliczona ilość mniejszych

• Ilość iteracji designu: 3

• Ilość użytych żółtych karteczek: 273 (fizycznych i w Miro)

P.S. 1. Nasz proces został zmodyfikowany i dostosowany do warunków organizacji, jednak trzymaliśmy się jego kluczowych założeń.

P.S. 2. Dziękuję moim Dizajnerom – Marcinowi i Adrianowi – za ciężką pracę, a Ani (PO) za pozytywne podejście do projektu.

Czujesz, że AI rewolucjonizuje pracę nad produktami, ale brakuje Ci realnych inspiracji jak wykorzystać ją w swojej pracy? Stosujesz kilka promptów, ale efekty są dalekie od oczekiwań? Brakuje Ci konkretnego celu i wsparcia, by pójść krok dalej?

Dlatego koniec z teorią. Czas na praktykę i realne efekty. Odpalamy z Jakub Uniejewski dla Was zupełnie nowy, praktyczny format w PA ⤵️

✨ AI Product Bootcamp (6-27 sierpnia)

Zapraszamy na pilotażową edycję AI Product Bootcamp ✨ - 3 tygodniowego bootcampu, podczas którego wspólnie eksperymentujemy i pracujemy nad konkretnym zastosowaniami asystentów AI w naszej produktowej pracy.

To nie jest kolejny kurs, który pokażesz na LinkedIn. To bootcamp, podczas którego robisz własny projekt i z którego wyjdziesz z gotowym, namacalnym usprawnieniem swojej pracy. Ty jesteś głównym twórcą, My - Twoim wsparciem.

Krótko, intensywnie, RAZEM, w konkretnym obszarze produktowej pracy. Po cichym otworzeniu zapisów wczoraj, mamy już ponad kilkadziesiąt osób na pokładzie!

🛠️ Tematy pierwszej edycji

W pierwszej, pilotażowej edycji bootcampu zajmiemy się dwoma fundamentalnymi obszarami, w których AI może stać się Twoim najlepszym asystentem:

• 1️⃣ AI jako Co-Pilot inicjatyw produktowych - W tym temacie będziemy wykorzystywać AI do realnego wsparcia w codziennym prowadzeniu inicjatyw produktowych.

• 2️⃣ Analiza feedbacku użytkowników - W tym temacie będziemy wykorzystywać asystentów AI do analizy opinii od klientów, by wyciągać z nich kluczowe wnioski i błyskawicznie identyfikować najważniejsze problemy i potrzeby.

To pilotażowa edycja. Po wakacjach planujemy kolejne skupione na takich tematach jak: Tworzenie i testowanie prototypów, AI w Product Discovery, AI-powered komunikacja, AI-powered Product Strategy.

📆 Przebieg Bootcampu

Podczas bootcampu czekają Cię 5 spotkań online oraz projekt do realizacji:

• ⚡️ 2x POWER SESSIONS na start (6 - 7.08) - zaczynamy od konkretów - 2x mikro-szkolenia i inspiracje w tematach bootcampu. Pozwolą Ci one wystartować z własnym projektem.

• 🛠️ PRACA NAD WŁASNYM PROJEKTEM (7 - 22.08) - Wybierasz własne wyzwanie zawodowe lub pracujesz na przygotowanym przez nas case study. Masz prowadzących, grupę, wsparcie, dodatkowe materiały i rytm.

• 🌟 DEMO DAY i refleksja (22.08) - Na koniec bootcampu prezentujemy i omawiamy nasze projekty. Uczymy się od siebie nawzajem i wychodzimy z bagażem praktycznych inspiracji.

✅ ZAPISZ się na Bootcamp

Ile normalnie kosztują takie bootcampy? 500, 1000, 1500 zł? My w pierwszej edycji postawiliśmy na cenę “no brainer”:

Do 20 lipca jest to tylko 243 zł netto (298,89 zł brutto) 🤯.

Wartość, jaką otrzymujesz, jest kilkukrotnie wyższa, a my liczymy na Twoją opinię po zakończeniu bootcampu.

Zabierz cały swój ZESPÓŁ produktowy - dla zespołów (+3 osoby) mamy specjalną ofertę. Odpowiedz po prostu na tego maila.

To nie koniec zmian w Product Academy. Czujemy, że budowanie produktów właśnie przechodzi fundamentalną zmianę. Najlepsi liderzy produktowi już dziś wychodzą poza swoją tradycyjną rolę, a najlepsze zespoły pracują 10 razy szybciej, mądrzej i z większym impaktem.

Dlatego po cichu budujemy społeczność 10x - miejsce, w którym ambitni i doświadczeni liderzy produktowi dzielą się doświadczeniami, eksperymentują i wspólnie się napędzają w tej zmianie. Stay Tuned :)

Niedawno zrobiliśmy listę najważniejszych produktowych konferencji w Polsce. Dostaliśmy od Was wiele ciepłych głosów (że bardzo Wam się przydało), ale też… pytania o takie samo zestawienie dla konferencji UX.

Sami bywamy na tych wydarzeniach. UX i Produkt to tak pokrewne dziedziny, że świat UX Designerów, UX Researchów i Product Managerów mocno się przenika - w końcu wszyscy chcemy tworzyć doskonałe produkty. Dlatego przygotowaliśmy naszą subiektywną listę takich wydarzeń:

• 🌟 UX w Lesie - 23.08, Gdynia

• 🌟 WaysConf - 17-18.09, Kraków

• UX Research Confetti

• CAKE conf 2025

Poniżej znajdziesz zestawienie tych najciekawszych wydarzeń ⤵️. Jesteśmy partnerami pierwszych dwóch inicjatyw ⭐️.

🌟 UX w lesie (plenerowy barcamp) - 23.08

Charytatywna (nie)konferencja UX, na której siądziesz przy ognisku, posłuchasz historii i wymienisz się doświadczeniami, organizowana przez Krzysztofa Miotka. Krzyśka znamy, lubimy i razem działy w Product Academy 🖤.

• 3 sceny - UX w AI, UX w Fintech i UX w ecommerce (ok, tutaj standard konferencyjny 😉)

• W PEŁNI PLENEROWA - Ognisko, sceny w namiotach wojskowych, przy lesie i plaży.

• Formuła „BarCamp” - Jest 9 prelegentów, a reszta zgłasza się kupując bilet, aby pochwalić się swoimi case study (swoją drogą, to dobre miejsce na pierwsze wystąpienie)

• Networking z gitarą, kiełbaskami i wege opcjami. Więc atmosfery nie trzeba tłumaczyć! :) Wszystko w cenie.

• Zysk z konferencji idzie na cele charytatywne (!)

Spotykamy się 📆 23 sierpnia w📌 Gdyni. Cena biletu od 250 zł + vat.

🌟 WaysConf - 17-18 września

WaysConf to największa konferencja w Europie Środkowej skupiona na designie i produkcie. Na wydarzenie zjeżdżają produktowcy z najlepszych firm technologicznych z całego świata.

Czekają na Ciebie zarówno prezentacji, jak i dyskusje oraz interaktywne warsztaty. W tym roku organizatorzy przygotowali 3 ścieżki tematyczne: Craft
 & Build, Research
& Analysis, Product 
& Strategy.

• 📆 17-18 września 2025

• 📌 Kraków

• 💰 od 420 zł + VAT

Jestem w radzie programowej tej konferencji, więc rekomendowałem najlepszych prelegentów na ścieżkę produktową ;).

UX Research Confetti

UX Research Confetti to chyba jedyna duża konferencja w Polsce poświęcona badaniom UX. Organizowana przez zespół UX Research z Allegro, ma na celu popularyzację wiedzy i podnoszenie świadomości w zakresie badań UX.

Konferencja łączy prelekcje online (na YouTube) z wydarzeniami stacjonarnymi, często w biurze Allegro w Poznaniu. Uczestnicy mogą brać udział w praktycznych warsztatach i programie mentorskim.

• 📆 Kiedy: co roku w okolicy maja - czerwca

• 📌 Poznań + Online

• 💰 Bezpłatna

Tegoroczna edycja już niestety z nami. Ale ja co roku czekam na kolejną edycję (choć zawsze uczestniczyłem tylko online).

CAKE conf 2025

Cake Conf to konferencja skierowana do specjalistów i entuzjastów z branży contentu, w tym UX / technical writerów, projektantów UX i content designerów. Jedyna taka w Polsce. Celem wydarzenia jest stworzenie przestrzeni do wymiany wiedzy na różnorodne tematy związane z tworzeniem i projektowanie treści.

• 📆 Kiedy: 19-20 września

• 📌 Kraków

• 💰 od 450 zł

To chyba pierwsza edycja tego wydarzenia, ale mocno przyciągający są prelegenci. Fajnie, że też obszar projektowania treści doczekał się swoich wydarzeń.

Macie jakieś swoje ulubione wydarzenia? Coś pominęliśmy? - piszcie w komentarzu!

Dziś na warsztat bierzemy temat, który prędzej czy później spędza sen z powiek każdemu Product Managerowi - estymowanie zadań. 🤯 Mówiąc wprost: jak wycenić, ile czasu i wysiłku pochłonie dane zadanie, żeby zespół wiedział, na czym stoi, a stakeholderzy nie patrzyli na nas jak na wróżbitów z kryształowej kuli.

Nie ma co się oszukiwać, dokładniejsze estymaty pozwalają zwiększyć przewidywalność pracy zespołu.

Możliwych do wykorzystania metod estymacji jest wiele i w różnym stopniu sprawdzają się one na poszczególnych poziomach zarządzania produktem. Inny poziom precyzji potrzebujemy dla zadań, które wchodzą do najbliższego sprintu, a inny dla epików, które mają być częścią produktu planowanego na następny rok.

Poniżej przyjrzymy się trzem najpopularniejszym metodom estymacji: 1️⃣ Estymowanie absolutne, 2️⃣ Planning Poker oraz 3️⃣ Team Estimation Game. Dziś rozłożę je dla Was na czynniki pierwsze, dorzucając moje własne spostrzeżenia z frontu.

1️⃣ Estymowanie absolutne (wycena godzinowa)

To metoda, którą znasz pewnie od zawsze. Polega na „wycenie” pracochłonności zadania w konkretnych jednostkach czasu, najczęściej w godzinach.

Jak to działa?

Zespół po prostu podaje konkretną liczbę godzin, którą ich zdaniem zajmie wykonanie zadania.

Moje obserwacje:

• Subiektywność nad obiektywność: Pamiętam, jak kiedyś w SentiOne próbowaliśmy wyceniać wszystko w godzinach. Programista z 10-letnim doświadczeniem wyceniał funkcję na 4 godziny, junior na 16. Kto miał rację? Oboje! Bo godzina pracy doświadczonego dev’a to nie to samo co godzina stażysty. To kluczowa kwestia, którą łatwo zbagatelizować.

• Zespoły często mają tendencję do zaniżania estymacji, zwłaszcza jeśli czują presję. „Szybka poprawka - 2 godziny!”, a potem okazywało się, że to 2 dni… 🤦‍♂️

• Brak punktu odniesienia - jeśli nie masz porównania do podobnych, zrealizowanych już zadań, estymacja absolutna staje się zgadywanką. Ciężko jest trafić w „punkt”, gdy nie masz do czego się odnieść.

• Sugerowanie się innymi. Wszyscy wiemy, jak to jest, gdy ktoś rzuci pierwszą liczbę, a reszta zespołu - świadomie lub nie - podąża za nią. Mało jest wtedy miejsca na prawdziwą dyskusję i weryfikację.

2️⃣ Planning Poker

Planning Poker to prawdziwy klasyk w świecie zwinnego zarządzania. Wywodzi się z metodyk Agile, takich jak Scrum, i najlepiej sprawdza się w połączeniu z jednostkami relatywnymi, czyli dobrze znanymi story pointami.

Czym są wyceny relatywne (np. story pointy)? 

Wyceny relatywne, w przeciwieństwie do estymacji absolutnych (np. w godzinach), nie podają konkretnego czasu potrzebnego na wykonanie zadania. Zamiast tego, oceniają one złożoność ,niepewność i wysiłek potrzebny do wykonania zadania w odniesieniu do innych zadań.

• Wyobraź sobie, że masz trzy obiekty: piórko, cegłę i samochód. Nie wyceniasz ich w kilogramach (absolutnie), ale mówisz, że cegła jest cięższa od piórka, a samochód od cegły.

• Story pointy działają podobnie – 1 story point to „małe” zadanie, 8 to zadanie 8x większe od małego, a 21 to „bardzo duże” zadanie (większe 21x od małego zadania).

• Zespół musi najpierw ustalić wspólny punkt odniesienia, czyli zadanie o danej wartości story pointów, do którego będzie porównywał wszystkie inne. To pozwala skupić się na złożoności problemu,

Jak działa Planning Poker?

1. Każdy z graczy (zazwyczaj członkowie zespołu deweloperskiego) dostaje talię kart z liczbami, zwykle z ciągu Fibonacciego (np. 1, 2, 3, 5, 8, 13, 21). Same wartości to jest kwestia umowna – należy jednak pamiętać, że im większa wycena tym zazwyczaj bardziej niedokładna. Można też dorzucić karty specjalne, takie jak symbol nieskończoności (zadanie jest za duże, by je oszacować) czy filiżanka kawy (potrzebujemy przerwy!) ☕.

2. Jako Product Owner lub Product Manager, Twoim zadaniem jest przedstawić zespołowi zakres danego zadania oraz odpowiedzieć na ewentualne pytania.

3. Gdy wszystko jest jasne, na ustalony znak (np. „trzy-czte-ry!”) wszyscy gracze jednocześnie wykładają karty z wybranymi przez siebie wycenami.

4. Dyskusja i konsensus - jeśli wartości się różnią, osoby z najniższą i najwyższą wyceną uzasadniają swoje wybory. To jest moment na prawdziwą dyskusję, wykrycie brakujących informacji i wspólne zrozumienie zadania. Następnie powtarzamy rundę, aż dojdziemy do konsensusu. Czasem przyda się moderator, np. Scrum Master.

Moje obserwacje:

• ➕ Dzięki jednoczesnemu wyłożeniu kart, unikamy efektu „kotwicy” i narzucenia od razu kierunku przez doświadczonych deków

• ➕ Różnice w wycenach zmuszają zespół do głębokiej debaty nad zadaniem, co często prowadzi do odkrycia ukrytych ryzyk czy zależności.

• ➕ Zespół buduje wspólne zrozumienie zadania i jego złożoności

• ➖ Metoda może być czasochłonna, zwłaszcza przy dużych i skomplikowanych zadaniach, które wymagają wielu rund dyskusji. Widziałem źle sfacylitowane sesje, które ciągnęły się godzinami!

• ➖ Mniej doświadczeni developerzy mogą odczuwać presję podczas dyskusji, by dostosować się do opinii bardziej doświadczonych kolegów. Ważna jest rola moderatora, który zadba o bezpieczną atmosferę.

• ➖ Z racji wykorzystania estymacji relatywnej, zespół potrzebuje wspólnego punktu odniesienia (bazowego zadania), do którego będzie porównywać resztę. Wypracowanie tych punktów odniesienia, które pozwala na szybką wycenę zwykle trochę trwa w zespole.

3️⃣ Team Estimation Game

Team Estimation Game to metoda, która również może wykorzystuje story pointy. Natomiast jej najważniejsza idea polega na tym, że staramy się wspólnie zadania posortować od najmniejszego do największego.

Sama metoda wymaga nieco przygotowania, ale potrafi być bardzo angażująca i budować wspólne zrozumienie w zespole.

Jak działa Team Estimation Game?

1. Drukujesz wszystkie zadania, które mają zostać oszacowane, oraz karty z wartościami liczbowymi reprezentującymi zakres możliwych wycen (np. od 1 do 21).

2. Uczestnicy gry, mają za zadanie uporządkować wszystkie zadania od najmniejszego do największego. Oczywiście również tutaj nie da się pominąć roli dobrze przygotowanego Product Managera, który wyjaśnia wszystkie pojawiające się wątpliwości.

   1. Pierwszy gracz bierze pierwszą kartę ze stosu, czyta ją na głos i kładzie na środek stołu.

   2. Drugi gracz bierze kolejną, czyta i może wykonać jeden z dwóch ruchów - położyć kartę na dole (mniejsza pracochłonność) lub na górze (większa pracochłonność) karty, która już znajduje się na stole, jednocześnie uzasadniając swoją decyzję.

   3. Kolejni gracze mają do dyspozycji te same ruchy - mogą wziąć następną kartę ze stosu i ułożyć ją w odpowiednim miejscu na liście lub zmienić położenie jednej z kart znajdujących się już na stole. Oczywiście dalej trzeba uzasadnić swoją decyzję.

   4. Gra toczy się do momentu rozłożenia wszystkich kart ze stosu. Jeżeli wśród wszystkich graczy zapanuje zgoda, przechodzi się do ostatniego etapu.

3. Celem ostatniego etapu jest ułożenie kart w grupy, którym przypisuje się wspólne wyceny.

   1. Na początku kartę reprezentującą najmniejszą możliwą wycenę np. 1 umieszcza się obok pierwszej karty po lewej stronie (najmniejsza pracochłonność).

   2. Następnie pierwszy gracz otrzymuje kartę z następną możliwą wartością estymaty np. 2 i wybiera dla niej miejsce „w szeregu”. Każdy następny gracz albo bierze kolejną kartę z estymacją, albo zmienia pozycje dowolnej karty znajdującej się już na stole (dotyczy to zarówno kart z zadaniami, jak i tych reprezentujących wyceny).

   3. Gra toczy się do momentu, kiedy uda się pogrupować wszystkie zadania w pionowe kolumny. Nie wszystkie karty z wycenami muszą zostać ostatecznie wykorzystane, najważniejsze jest osiągnięcie konsensusu

Moje obserwacje:

• ➕ Jest to bardziej swobodna i interaktywna metoda, która angażuje cały zespół. Widziałem, jak zespoły, które nie przepadały za estymacją, wciągały się w grę.

• ➕ Każdy może zabrać głos i przedstawić swoje uzasadnienie, co prowadzi do bogatszej dyskusji.

• ➕ Czasem łatwiej najpierw posortować zadania i dopiero potem nadawać i wyceny (w planning pokerze tego nie ma).

• ➖ Czasami dyskusje mogą się zapętlić, a zespół ma trudności z osiągnięciem konsensusu, co prowadzi do frustracji. To się zdarzało w Rocket Studio przy bardziej skomplikowanych projektach.

• ➖ Bez dobrego moderatora sesja może się przedłużać w nieskończoność.

  ➖ Wymaga sporo przygotowania - potrzeba wydrukowania kart i ułożenia ich na stole.

Podsumowanie

Podczas mojej codziennej pracy jako Head of Product, czy Product Manager, doszedłem do jednego wniosku: nie ma jednej idealnej metody estymacji. Każda z nich ma swoje wady i zalety, i każda sprawdzi się w innym kontekście. To trochę jak wybór odpowiedniego narzędzia do konkretnego zadania - młotek do gwoździ, śrubokręt do śrub.

• Dla długoterminowych planów (Epiki, Inicjatywy): Często używam estymacji absolutnej na bardzo wysokim poziomie, ale z dużą dozą ostrożności. To raczej „T-shirt Sizing” (S, M, L, XL) niż precyzyjne godziny. Daje to ogólne pojęcie o skali, ale nie wiążę się z konkretnymi datami.

• Dla sprintów i precyzyjnych zadań: Moim faworytem jest zdecydowanie Planning Poker. Po latach doświadczeń, widzę, że ta metoda wymusza najważniejsze - dyskusję i wspólne zrozumienie zespołu. Nie raz uratowało nas to przed błędnymi założeniami.

• Gdy zespół jest nowy lub potrzebuje „rozruszania”: Team Estimation Game jest świetny, aby zespół się zintegrował i nauczył relatywnego myślenia o złożoności. To fajna, angażująca gra, która buduje zaufanie.

Pamiętaj, że estymowanie to nie tylko technika, to przede wszystkim proces komunikacji i budowania wspólnego zrozumienia w zespole. Im lepiej rozumiecie, co i dlaczego budujecie, tym dokładniejsze będą Wasze oszacowania.

Mam nadzieję, że ten deep dive pomoże Ci w lepszym zarządzaniu produktem i uniknięciu pułapek związanych z estymacją. Daj znać w komentarzach, jakich metod używasz i co sprawdza się u Ciebie najlepiej!