Tego nie było w moim bingo na 2026 rok → ROBIMY SPOTKANIE LIVE z Ravi Mehta (Tinder, Facebook, Reforge) oraz Michelle Parsons (Spotify, Netflix i Hinge) 🤯.

Wspólnie z moja ekipą z podcastu “Dodane Do Backlogu” oraz Productlab Conf siadamy do rozmowy z dwójką senior product leaderów z absolutnie topowych firm na świecie, by pogadać o produkcie ⤵️

📆 29.07: F*ckups in Product

Spotkanie w formie luźnej, szczerej rozmowy o tym, co w ich karierach zadziałało, co nie i czego by już nigdy nie zrobili. Będzie też oczywiście czat dla Was 💬.

• 📆 Środa, 29.07, 

• ⏰ 18:00 - 19:30

• 💰 BEZPŁATNIE (obowiązują zapisy)

Całość nagrywamy też w formie podcastu "Dodane do backlogu" - premiera wkrótce po spotkaniu 🎧.

Ravi nawet pokusił się o komentarz po polsku 😄 

Kim są nasi goście?

Wielu z Was nie trzeba ich przedstawić - to dosłownie TOPka product managementu na świecie:

• 🔹 Ravi Mehta - ex-CPO Tindera, założyciel Outpace. Za sobą lata w Tinderze, Facebooku i Tripadvisorze. Jeden z głównych trenerów Reforge. To od niego najwięcej nauczyłem się o zarządzaniu zespołami produktowymi jako HoP.

• 🔹 Michelle Parsons - ex-CPO Hinge, teraz founderka Lora. Karierę spędziła budując produkty w Spotify, Netflixie i Hinge - i wie, jak bardzo krzywa bywa ta droga.

Niedawno skończyłem już… 38 lat 🎂. I tak jak przez ostatnie 4 lata - z tej okazji przygotowałem paczkę urodzinowych prezentów, którą rozdaję produktowcom 🎁.

W tym roku akcja jest w nowej odsłonie - do rozdania mam kilkadziesiąt dostępów do narzędzi, z których sam korzystam na co dzień, plus online pass na świetną konfę. Łączna wartość wszystkich dostępów to ponad 15 000 zł.

• 📈 38x PostHog (100$) - narzędzie, które aktualnie używam najczęściej do analityki produktowej

• 👩‍💻 5x Claude Pro (20$) - które używam jako swojego asystenta i agenta AI

• 🎫 5x onlinepass na konfę ProductLab (30$) - jedną z najważniejszych konferencji produktowych w Europie

Poza Product Academy, swoim doświadczeniem dziele się także w newsletterze Product Craft - i właśnie tam co roku prowadzę akcję urodzinową. Drop pakietów będzie w przyszłym tygodniu, ale konkretna data będzie niespodzianką - kto pierwszy, ten lepszy 👀.

To najlepszy moment żeby dołączyć do newslettera. Poza regularnymi materiałami o budowaniu produktów, masz szansę zgarnąć jeden z 48 pakietów.

Pamiętam moment, w którym mój zespół przez trzy tygodnie czekał na wyniki badań UX-owych, zanim "oficjalnie" pozwolono nam zacząć projektować.

Trzy tygodnie. Nic. Żadnego decyzji, żadnych makiet, żadnego postępu.

Właśnie wtedy usłyszałem o protopersonach od product designera, który spojrzał na mnie z lekkim zdziwieniem i powiedział: "No to zacznijcie od założeń, przecież wiecie, dla kogo to robicie?".

Miał rację. I od tamtej pory protopersony są stałym elementem mojego zestawu narzędzi na start każdego projektu.

• 1️⃣ Czym jest protopersona - i dlaczego to NIE jes …

• 2️⃣ Dlaczego potrzebujesz protopersony - argument …

• 3️⃣ Jak zbudować protopersonę - cztery obszary sza …

  • 3.1. Kim jest - założenia demograficzne lub psycho …

  • 3.3. Potrzeby i motywacje

  • 3.4. Problemy i bariery

• 4️⃣ Skąd brać dane - sześć źródeł, które masz pod …

• 5️⃣ Najważniejsza pułapka: efekt "wyświęconego dok …

• 6️⃣ Protopersona to hipoteza, nie prawda absolutna

1️⃣ Czym jest protopersona - i dlaczego to NIE jest persona

Zacznijmy od klasycznego nieporozumienia, które spotykam regularnie wśród junior PM-ów i PO-ów.

Persona = postać oparta na prawdziwych badaniach. Wywiady, ankiety, obserwacje, analiza danych. Solidna, ale droga i czasochłonna.

Protopersona = skrócony opis fikcyjnego przedstawiciela grupy użytkowników, oparty na założeniach i hipotezachosób zaangażowanych w budowanie produktu.

To nie jest to samo. I to jest w porządku.

Protopersona to narzędzie do szybkiego startu - pozwala całemu zespołowi projektowemu mieć wspólny obraz tego, dla kogo właściwie budujemy produkt, zanim zaczniemy wydawać czas i pieniądze na pełne badania.

2️⃣ Dlaczego potrzebujesz protopersony - argument za szybkością

W klasycznych projektach odkrywanie potrzeb grupy docelowej trwa tygodniami, a czasem miesiącami. Planujemy badania, analizy rynku, wywiady - i wszystko to jest wartościowe.

Ale co w tym czasie robi zespół? Czeka.

Protopersona to odpowiedź na to bezczynne czekanie. Zamiast blokować cały projekt na "wyniki badań", zaczynamy od ustrukturyzowanych założeń i ruszamy do przodu. Testujemy szybciej, uczymy się szybciej, i - co ważne - refinujemy protopersony wraz z rozwojem projektu.

Siła protopersony to szybkość wykonania. Słabość - jakość danych, na których ją tworzymy. Dlatego musimy być z tym świadomi od początku.

Ważna informacja praktyczna: jeśli budujesz nową funkcję dla istniejącego produktu, prawie na pewno znajdziesz wcześniejsze analizy, dane z analytics, albo wyniki poprzednich badań. Możesz z nich wyciągnąć założenia o użytkownikach i użyć jako punkt startowy. Nie zaczynasz wtedy od zera.

3️⃣ Jak zbudować protopersonę - cztery obszary szablonu

W internecie znajdziesz dziesiątki szablonów. Różnią się detalami, ale większość solidnych protoperson opiera się na czterech głównych obszarach. Oto one.

3.1. Kim jest - założenia demograficzne lub psychograficzne

Tutaj decydujesz, czy grupujesz użytkowników demograficznie (wiek, miejsce zamieszkania, zarobki) czy psychograficznie (wspólne cechy, potrzeby, zachowania niezależne od danych demograficznych).

Nie ma jednej właściwej odpowiedzi. Zależy od projektu.

Przykład demograficzny: gracze konsolowi z dużych miast, zarabiający powyżej 3 000 PLN miesięcznie.

Przykład psychograficzny: rodzice małych dzieci szukający rozrywki po 21:00, gdy dzieci śpią.

Gdy już ustalisz grupy, nadaj każdej protopersonie imię - najlepiej z charakterystycznym nazwiskiem, które podpowiada jej cechy. W jednym z moich projektów mieliśmy "Janka Rozważnego" - postać, która dwa razy zastanawia się przed każdym wydatkiem. Łatwiej jest powiedzieć "ta funkcja jest dla Janka" niż za każdym razem tłumaczyć całą charakterystykę grupy.

3.2. Charakterystyczne zachowania

Jak ta persona zachowuje się w kontekście twojego produktu? Co robi, kiedy to robi, dlaczego?

Przykłady z projektu gry konsolowej:

• Starsi gracze grają raczej po pracy, nie w trakcie dnia

• Gry dla dzieci kupują rodzice, ale to dziecko podejmuje decyzję o wyborze

• Przy wyższych zarobkach użytkownik może pozwolić sobie na więcej zakupów miesięcznie

Wypisuj krótkie punkty. Bez elaborowania. To ma być szybki spis, nie powieść.

3.3. Potrzeby i motywacje

Co sprawia, że ta osoba sięga po twój produkt lub go potrzebuje? Jakie głębsze potrzeby za tym stoją?

Tutaj warto uważać na zbyt ogólne założenia. "Chce rozrywki" to za mało. "Chce poczucia przynależności do społeczności graczy" - to już coś konkretnego, co może wpłynąć na decyzję o dodaniu trybu online.

To właśnie na tym etapie porównujesz swoje protopersony - jeśli dwie są niemal identyczne w potrzebach, prawdopodobnie nie ma sensu ich rozdzielać.

3.4. Problemy i bariery

Co utrudnia tej grupie korzystanie z twojego produktu lub przeszkadza w osiągnięciu jej celu?

Przykład: gracz mobilny, który chce zabić czas w drodze do pracy, jest wykluczony przez grę przeznaczoną wyłącznie na konsole. To problem - ale też szansa. World of Warcraft zauważył to i stworzył mobilną aplikację do zarządzania wirtualną posiadłością. Efekt? Gracze byli z grą zarówno w domu, jak i w podróży.

4️⃣ Skąd brać dane - sześć źródeł, które masz pod ręką

Nie musisz mieć własnych użytkowników, żeby sensownie wypełnić protopersonę. Oto gdzie szukam danych w praktyce:

1. Fora dyskusyjne Klienci opisują tam problemy, dzielą się opiniami, zgłaszają pomysły. Spotify i Airbnb mają własne fora właśnie po to, żeby być blisko użytkowników. Jeśli nie masz własnego - szukaj tam, gdzie jest twoja branża.

2. Serwisy z opiniami Reddit, Quora, Customer Affairs zagranicą - Allegro Opinie lub Opineo w Polsce. Wpisz w Google'a nazwę marki/kategorii + "opinie" i zobaczysz, co użytkownicy faktycznie mówią. Szczególnie przydatne przy analizie konkurencji.

3. Social media Facebook, Instagram, LinkedIn, TikTok. Grupy, hashtagi, komentarze. Jeśli tworzysz produkt dla młodszej grupy - TikTok to kopalnia informacji o zachowaniach, której wielu PM-ów w Polsce jeszcze nie eksploatuje.

4. App Store i Google Play Komentarze w sklepach z aplikacjami to gotowa analiza potrzeb i frustracji. Przed redesignem jakiejkolwiek aplikacji - zacznij od przejrzenia aktualnych recenzji. Co użytkownicy kochają? Co ich wkurza?

5. Pracownicy firmy Z dużą ostrożnością - ale to działa. Osoby niezwiązane bezpośrednio z projektem, które mogą być potencjalnym odbiorcą. Pytaj otwartymi pytaniami, neutralnymi - nie pokazuj rozwiązania i nie pytaj, czy im się podoba. Pytaj o zachowania i problemy.

6. Publiczne raporty i dane GUS, Eurostat, Statista, Gemius. Makroekonomika i dane branżowe. Warto zaglądać nie tylko przy okazji tworzenia protoperson, ale regularnie - żeby czuć kontekst rynku.

Narzędzia analityczne takie jak Google Analytics czy Hotjar (wersja trial wystarczy na starcie) dają ci dane, jeśli masz już produkt lub stronę. Wiek, zainteresowania, zachowanie na stronie - to wszystko jest już w zasięgu ręki.

5️⃣ Najważniejsza pułapka: efekt "wyświęconego dokumentu"

Tutaj muszę powiedzieć coś, co może trochę zaboleć. Szczególnie jeśli lubisz ładne dokumenty i porządne tabele.

Napisana protopersona ma magiczną moc wyglądać jak prawda.

Widziałem to wielokrotnie. Zespół spędza kilka godzin na protopersonie, wychodzi ładny dokument z imieniem, zdjęciem stockowym i wypunktowanymi "potrzebami" - i nagle wszyscy traktują to jak fakty. Nikt nie wraca, nikt nie aktualizuje. Protopersona "żyje" przez miesiące, choć była stworzona w pierwszym tygodniu projektu na podstawie domysłów.

Dwa kluczowe przypomnienia:

• ✅ Protopersony rozwijamy cały czas - wraz z rozwojem projektu, nowymi danymi, rozmowami z użytkownikami. To żywy dokument, nie kamień węgielny.

• ✅ Czas tworzenia = max. 1 godzina na podstawowy draft. Jeśli siedzisz nad protopersonami dwa dni, lepiej poświęć ten czas na właściwe badania z użytkownikami.

6️⃣ Protopersona to hipoteza, nie prawda absolutna

Zanim trafisz na pierwszego prawdziwego użytkownika, potrzebujesz struktury. Protopersona daje ci właśnie to - ustrukturyzowane założenia, które pozwalają ruszać do przodu bez czekania tygodniami na wyniki badań.

Kluczowe wnioski:

• Protopersona = hipoteza, nie fakt. Traktuj ją jak punkt startowy, nie objawioną prawdę.

• Cztery obszary: Kim jest, Zachowania, Potrzeby/Motywacje, Problemy/Bariery.

• Czas tworzenia - max. godzina. Jeśli więcej - idź lepiej na badania.

• Dane znajdziesz bez własnych użytkowników: fora, recenzje, social media, analytics, raporty.

• Aktualizuj protopersony regularnie. Żaden projekt nie kończy się tą samą personą, którą zaczął.

Twoje zadanie na ten tydzień:

Wróć do swojego aktualnego projektu. Czy masz zdefiniowane protopersony? Jeśli tak - kiedy ostatni raz były aktualizowane? Jeśli nie - zablokuj sobie 60 minut i zacznij od kartki papieru lub Figmy. Gwarantuję, że to ćwiczenie ujawni niezgodności w zespole co do tego, kto jest waszym userem.

I o tych niezgodnościach warto rozmawiać wcześnie. Nie gdy makieta jest gotowa.

Wróciłem ostatnio myślami do momentu, kiedy zaczynałem jako PM w nowej firmie. Pierwsze dni - poczucie, jak bym był w zupełnie nowym mieście, bez dostępu do Google Maps ;). Wszyscy wokół wiedzą, gdzie co jest. Ty - nie. I pojawia się pokusa: siedzę cicho, obserwuję, uczę się. A potem wchodzę do gry.

Problem? To "wchodzę do gry" może przyjść za późno. I sygnał, który wysyłasz w pierwszych tygodniach, ma znaczenie. I tym sygnałem powinno być → wnoszę wartość do zespołu.

Nie ma lepszego sposobu na szybkie zbudowanie zaufania.

• 1️⃣ Dokumentuj to, czego się uczysz

• 2️⃣ Zrób audyt roadmapy (i jej założeń)

• 3️⃣ Wesprzyj bieżący sprint

• 4️⃣ Zrób analize konkurencji

• 5️⃣ Zrób rundę wywiadów wewnętrznych

• 6️⃣ Podsumuj opinie o Waszym produkcie

• 7️⃣ Posprzątaj albo przygotuj dashboard z metrykam …

• 8️⃣ Pisz tygodniowe memo

• 9️⃣ Dołącz do call z klientami (nawet jeśli nic ni …

• 🔟 Stwórz wiki dla najwazniejszcyh procesów

Każdy onboarding PM-a zaczyna się tak samo. Spotkania 1:1 z każdym w teamie. Czytanie dokumentacji (jeśli istnieje). Siedzenie na standup jako milczący obserwator. Słuchanie, notowanie, kiwanie głową.

To ma sens - kontekst i historia produktu to fundament. Bez nich możesz zrobić więcej szkody niż pożytku.

Ale jest pułapka.

Onboarding, który jest wyłącznie pasywny, wysyła zły sygnał. Menadżer i team zaczynają się zastanawiać: kiedy ten człowiek zacznie coś robić? Co my właściwie dostaliśmy?

I co ważniejsze - ty sam zaczynasz to czuć. Syndrom impostora zaczyna się właśnie wtedy, gdy przez 4 tygodnie jesteś obserwatorem, a nie uczestnikiem.

Dobra wiadomość jest taka, że pierwsze 30 dni to idealne okno do tego, żeby wnieść realną wartość - bez udawania, że wiesz wszystko. Bo właśnie świeże oczy widzą rzeczy, których zespół już dawno przestał dostrzegać.

Poniżej 10 konkretnych rzeczy, które możesz "dostarczyć" w pierwszym miesiącu:

1️⃣ Dokumentuj to, czego się uczysz

Uczysz się produktu? Świetnie. Ale nie rób tego tylko dla siebie.

Stwórz LIVE dokument (ja to zwykle robię w Google Docs) - "Product Context Dump" - gdzie opisujesz to, co odkrywasz. Kto jest Waszym ICP i jakie ma problemy. Jak sprzedajecie produkt. Słownik akronimów (każda firma ma swój własny język). Metryki, które "się liczą". Flowcharty procesu, który jest zbyt skomplikowany, żeby trzymać go w głowie.

Ten dokument ma dwie funkcje: pomaga ci strukturyzować wiedzę i jest gotowym onboarding guide dla następnego PM-a. Twój menadżer zobaczy w tym dowód, że nie tylko słuchasz, ale też organizujesz.

2️⃣ Zrób audyt roadmapy (i jej założeń)

To jest mój ulubiony trik, bo nikt go zazwyczaj nie robi.

Przejrzyj backlog i aktualną roadmapę. Dla każdego epiku lub większej inicjatywy wypisz jedno pytanie: "jakie założenie o zachowaniu użytkownika lub potrzebie rynkowej leży u podstaw tej decyzji?"

Świeże oczy widzą te rzeczy lepiej niż ktoś, kto od roku jest w środku i "wie jak jest". Przynieś ten audyt na spotkanie z menadżerem - nie jako krytykę, ale jako "oto co mi się nasuwa po przejrzeniu roadmapy, chciałem to z tobą przegadać."

3️⃣ Wesprzyj bieżący sprint

Nie czekaj na "swój" sprint. Zacznij od samego startu. Szukaj miejsc, gdzie możesz pomóc:

• wymagania, które są niejasne - doprecyzuj je.

• QA - Zaoferuj się, że przetestujesz i wyfilizujesz bugi.

• Pytania developerów do designu - weź udział w wyjaśnieniu.

To ważny sygnał dla teamu: nie siedzisz z boku, tylko działasz. Wchodzi tam, gdzie jest potrzebny.

4️⃣ Zrób analize konkurencji

Maks trzy firmy na start (nie muszą być wszystkie). Głębokość, nie szerokość.

Jeśli możesz - używaj ich produktu. Zarejestruj się, przejdź onboarding, kliknij przez kluczowe ficzery. Udokumentuj: kto jest ich głównym targetem, jakie problemy rozwiązują, jak wyglądają ceny, gdzie ewidentnie są słabsi od Was.

Prosta tabela porównawcza w Notion robi wrażenie. Szczególnie jeśli nikt wcześniej tego nie zebrał w jednym miejscu.

5️⃣ Zrób rundę wywiadów wewnętrznych

To jest jeden z najbardziej niedocenianych źródeł wiedzy o produkcie.

Sprzedarz, Customer Success, Support - każdy z nich ma inną perspektywę na klienta i produkt - i zazwyczaj nikt tego systematycznie nie agreguje.

Umów się na 30-minutowe rozmowy. Spytaj:

• jakie są najczęstsze objekcje w sprzedaży?

• Czego klienci nie rozumieją?

• Co ich frustruje po zakupie?

• Jakich pytań nie potrafimy odpowiedzieć?

W dwa tygodnie możesz zbudować lepsze rozumienie użytkownika niż niejeden PM, który siedzi w firmie od roku, ale nigdy nie rozmawiał z CS-em.

6️⃣ Podsumuj opinie o Waszym produkcie

G2, Capterra, App Store reviews - to jest nieprzetworzone złoto, do którego nikt nie ma czasu wracać regularnie.

Wrzuć ostatnie 50-100 recenzji do Claude'a lub ChatGPT z promptem: "Wyodrębnij top 5 problemów użytkowników i top 5 rzeczy, które chwalą. Daj mi kategorie, nie listę."

Zrób to samo dla konkurencji. Nagraj Looma z 5-minutowym omówieniem. Ten jeden plik może ci otworzyć wiele drzwi w rozmowach z produktem i sprzedażą.

7️⃣ Posprzątaj albo przygotuj dashboard z metrykami

"Metryki sukcesu" to oksymoron w wielu firmach. Bo albo jest ich nadmiar, albo nie ma ich wcale. Dlatego dobrym pomysłem może być zrobienie revewi istniejących dashboardów, ale przygotowanie pierwszego z nich.

Porozmawiaj ze swoim menadżerem o tym, co naprawdę mierzy sukces Waszego produktu. Jeśli jest Mixpanel, GA4 albo Amplitude - sprawdź, czy dashboardy są aktualne i czytelne. Jeśli dane są porozrzucane po czterech miejscach - zaproponuj jeden widok.

To praca, której nikt nie lubi robić. Dlatego nikt jej nie robi. Dlatego ją zrób ty :D.

8️⃣ Pisz tygodniowe memo

Bardzo prosta zasada: co tydzień, przed weekendem, wyślij jedno krótkie podsumowanie - dla swojego managera albo jeszcze lepiej publicznie.

• Co zrobiłem w tym tygodniu

• Czego się nauczyłem

• Gdzie mam bloker

• Co planuję na następny tydzień

Lenny Rachitsky pisze o tym często - to jeden z najprostszych sposobów na budowanie zaufania z przełożonym. Twój menadżer nie musi się zastanawiać "co ten człowiek właściwie robi". Wie. Bo mu mówisz.

9️⃣ Dołącz do call z klientami (nawet jeśli nic nie powiesz)

Poproś Sprzedaż albo CS o możliwość dołączenia do rozmów z klientami. Na start - tylko żeby posłuchać.

Tworzysz podczas tych rozmów prostą tabelę: typ klienta, główna objekcja lub ból, co ich przyciągnęło, co ich niepokoi. Po kilku rozmowach zaczniesz widzieć wzorce w segmentach klientów.

🔟 Stwórz wiki dla najwazniejszcyh procesów

Jak działa zgłaszanie bugów / CR? Jaki jest workflow od design do dev? Jak wygląda proces release'u nowych ficzerów? Co trzeba zrobić, żeby cokolwiek wjechało na produkcję?

To jest coś co żyje w głowach wielu osób, ale też bywa niejdnozanczne. Dlatego stwórz jeden dokument, w którym spiszesz te najważniejsze zasady. To ma dwa efekty: ty lepiej rozumiesz jak firma działa, a team dostaje coś konkretnego, czego wcześniej nie było.

Nie musisz robić wszystkich 10. Wybranie 3-4 i zrobienie ich dobrze jest lepsze niż próbowanie wszystkiego po łebkach. I jedno ważne zastrzeżenie: nie wchodź z tymi rzeczami jak bohater z gotowymi odpowiedziami. Wchodź z pytaniami i propozycjami:

Różnica między PM-em, który dostarcza wartość w pierwszych 30 dniach, a tym który irytuje zespół, to zazwyczaj właśnie ta jedna rzecz: czy słuchasz z pozycji eksperta, czy z pozycji kogoś kto naprawdę chce zrozumieć.

Najważniejsze wnioski:

• Pierwsze 30 dni to nie czas na siedzenie z boku. To okno na zbudowanie zaufania przez małe, konkretne dostarczenia.

• Świeże oczy to przewaga - audit założeń, dokumentacja procesów, synteza insightów - to rzeczy, które ludzie "wewnątrz" omijają.

• Najlepszy sygnał, jaki możesz wysłać: jestem tu, słucham - i jednocześnie działam.

Na pierwszy rzut oka wydawałoby się, że Product Owner może się skupić na roadmapie, pielęgnowaniu backlogu produktu i pracy z interesariuszami mając obok siebie zespół wytwórczy, który cyklicznie dostarcza wartości biznesowe.

I teraz, żeby PO mógł się skupić na „produktowych” obszarach, dobrze by było, aby „maszyna dostarczająca wartość” była odpowiednio naoliwiona. Dzisiaj przyjrzymy się kilku niuansom, o których istnieniu każdy produktowiec powinien wiedzieć.

• 1. Scrum a rola testera (wprowadzenie)

• 2. Zacznijmy od początku…

• 3. Backlog Refinement a Testerzy

• 4. Swarming

• 5. Definition of Done

• 6. Ścieżka informacji zwrotnej

• 7. Automatyzujmy co się da

• 8. Współpraca w praktyce

  • 1. Sprint Planning

  • 2. Daily Standup

  • 3. Backlog Refinement

  • 4. Sprint Review

  • 5. Proces jakości

  • 6. Zespół

• 9. Ale… po co mi to wszystko?

1. Scrum a rola testera (wprowadzenie)

Prowadząc warsztaty otwarte lub dedykowane dla firm, w zespołach, które zaczynają przygodę ze zwinnością często pojawia się wątpliwość, że przecież w Scrumie jest Product Owner, jest Scrum Master i jest zespół developerski. A gdzie miejsce dla Analityka, Testera lub (UX/UI) Designera?

Autorom Scruma przyświecała niegłupia idea, żeby nie wyróżniać w zespole ról – każda osoba niezbędna w procesie dostarczania wartości jest tak samo ważna. Intencja była dobra, choć w życiu jak to w życiu często jest inaczej i każdy w zespole wie, że Piotrek zajmuje się testami, Paulina tworzy design, a Marta pisze scenariusze testowe.

W Scrum Guide znajdziemy:

A zatem jest tam miejsce dla: Testera, Designera, Analityka – o ile te kompetencje są niezbędne do dostarczenia biznesowej wartości.

2. Zacznijmy od początku…

Gdy przyjrzymy się z jakich elementów składa się proces wytwarzania oprogramowania, to mamy (w kolejności):

• Analiza

• Projektowanie

• Wytwarzanie

• Testowanie

• Wdrożenie

• Utrzymanie

Wydawałoby się, że testerów wystarczy zaangażować w późniejszym etapie tworzenia produktu, że nie są potrzebni od samego początku.

Nic bardziej mylnego. Testerzy powinni być zaangażowani od pierwszego dnia i już za moment zobaczymy jak to wszystko zorganizować, żeby to miało sens.

3. Backlog Refinement a Testerzy

Czasami pojawia się pokusa, żeby przy pielęgnowaniu backlogu produktu poza Product Ownerem pojawił się tylko lider techniczny lub najbardziej doświadczony programista. No bo jak to całym zespołem rozmawiać o wymaganiach. Załóżmy, że spotkanie trwa godzinę, pomnóżmy to przez 10 osób w zespole, stawki godzinowe i wyjdzie nam, że to spotkanie jest całkiem drogie. I bardzo łatwo wpadamy tutaj w pułapkę „pozornych oszczędności” (podobnie jak to często bywa w przypadku pair-programming’u).

Sytuacja jest trochę lepsza, gdy w pielęgnowaniu backlogu produktu biorą udział wszyscy programiści z danego zespołu. Dlaczego? Z perspektywy osoby zarządzającej produktem chcielibyśmy móc skonfrontować pomysły i potrzeby biznesowe z realnością wykonania, czasochłonnością, potencjalnymi konsekwencjami. Z drugiej strony, zespół musi mieć czas, żeby przyswoić wymagania biznesowe i móc je przemyśleć. Czasem do pewnych zagadnień wraca się po kilku dniach z nowymi wnioskami albo wiedzą. Lepiej, żeby te pytania i wątpliwości pojawiły się podczas Backlog Refinementu, niż później, gdy dana osoba pracuje już przed komputerem i Product Ownera nie ma w pobliżu.

Patrząc z perspektywy procesu poznawania kontekstu biznesowego i wymagań, dlaczego podczas Backlog Refinementu mielibyśmy pominąć testerów? Tak samo jak programiści muszą przyswoić wymagania, tak samo testerzy muszą się zastanowić na czym dokładnie będzie polegała ich praca, co da się zautomatyzować i na jakie „typowe błędy” się przygotować. A przecież warto by było przy okazji oszacować pracochłonność potrzebną przy testach.

4. Swarming

Ile osób jest w stanie pracować nad jedną funkcjonalnością w tym samym czasie? Albo, pytając inaczej: gdyby cały zespół miał pracować tylko i wyłącznie nad jedną funkcjonalnością – to jak rozdzielić „pracę”, aby każda osoba w zespole mogła pomóc? W project managemencie znane jest pojęcie War room, czyli po prostu wszystkie ręce na stół. Gdyby się bliżej przyjrzeć temu co jest do zrobienia, to może okazać się, że nawet i 10-12 osób jest w stanie pracować nad jedną funkcjonalnością, np.:

• Programowanie

• Programowanie w parach (pair programming)

• Przygotowanie scenariuszy testowych (albo ich weryfikacja)

• Może jest potrzebna upewnić się lub zweryfikować pewne niejasności z Product Ownerem?

• A co z przygotowaniem środowiska testowego?

• Może można już napisać jakieś testy automatycznie?

• Warto na pewno by przejrzeć (z)realizowane zadanie z perspektywy Review i pokazywania danej funkcjonalności interesariuszom.

Zachęcam do przeprowadzenia takiego eksperymentu w zespole, bo to prowadzi nas to kolejnego aspektu (który zostanie poruszony w oddzielnym artykule), czyli T-shaped people. Pomysłem samego eksperymentu jest zakiełkowanie w zespole świadomości jak ważne jest wspieranie siebie nawzajem w codziennej pracy vs. postawa: „robię swoje i cała reszta mnie nie interesuje”. Ważne, żeby po eksperymencie był czas na chwilę refleksji dla całego zespołu lub żeby ten temat został omówiony podczas Retrospektywy.

5. Definition of Done

Temat „Definition of Done” pojawia się (lub powinien się pojawić) wszędzie tam, gdzie widać kłopoty z jakością: cofane wdrożenia, błędy regresji, stres związany z nadchodzącym wdrożeniem. Pojawia się też tam, gdzie występuje rozdźwięk między „prawie skończonymi zadaniami”, a tym co tak naprawdę nadaje się do wdrożenia i do pokazania użytkownikom końcowym.

Czym jest Definition of Done? Najprościej mówiąc, jest to checklista określająca, kiedy dokładnie realizowane zadanie można uznać za wykonane.

Kilka przykładowych kryteriów:

• Wszystkie kryteria akceptacji zostały spełnione.

• Kod jest przejrzysty, odpowiednio sformatowany, napisany zgodnie ze standardami programowania.

• Kod przetestowany jednostkowo.

• Kod poddano analizie statycznej.

Kiedy ten temat już się pojawia i zespół rozważa wprowadzenie lub zmianę DoD, dlaczego by nie zaangażować tutaj także testerów, którzy stanowią ważny element układanki dbania o jakość.

6. Ścieżka informacji zwrotnej

O tym jak kluczowa jest szybka ścieżka informacji zwrotnej można przeczytać w artykule: Potęga szybkiego feedbacku. Podstawowym pytaniem, który musi zadać sobie zespół, jest: Ile czasu mija od momentu, gdy programista skończył swoją pracę do momentu aż dowie się, czy to co zrobił jest zrobione poprawnie? Czy są to godziny, dni, tygodnie czy miesiące? Tak, w niektórych firmach nawet zdarzają się miesiące. Jeśli development i testy mamy mocno rozdzielone procesowo – trudno o skrócenie feedbacku, jakże ważnego w tej całej układance.

7. Automatyzujmy co się da

Przychodząc do biura lub po prostu zaczynając dzień pracy, chcielibyśmy mieć jak najwięcej świętego spokoju, aby móc skupić się najważniejszych obszarach związanych z produktem. Bardzo łatwo popsuć sobie ten święty spokój poprzez:

• Brak informacji co robi zespół (muszę trzymać kciuki czy jestem pewny, że na koniec sprintu będzie oczekiwany efekt);

• Duży poziom stresu podczas wdrożeń;

• Błędy regresji stają się zauważalnym problemem.

Jednym ze sposobów na zwiększenie poziomu komfortu jest automatyzacja i wprowadzenie Continuous integration – częsta i regularna integracja bieżących zmian w kodzie do głównego repozytorium produktu, skutkująca każdorazową weryfikacją zmian, sprawdzeniem testów automatycznych i “zbudowaniem” aplikacji.

W jednym z projektów, który mogłem obserwować w jednej z organizacji, podwykonawca tak przygotował środowisko testowe, że:

• Aktualizacja trwała 1-2 dni,

• Na 6 stanowisk do testowania, każde miało inną konfigurację i do końca nie było wiadomo co można testować,

• Środowisko testowe się resetowało co jakiś czas i potrzebne było ok 30 minut, aby od nowa można było zacząć testować.

Dla kontrprzykładu, gdy jako Product Owner prowadziłem tworzenie pewnego produktu R&D, już na samym początku poukładaliśmy sobie następujące elementy:

• Pushowane zmiany w kodzie były automatycznie weryfikowanie podstawowymi testami;

• Gdy wszystko było ok, nowa wersja wdrażana była automatycznie na środowisku testowym;

• Gdy i ten etap zakończył się sukcesem, na komunikator Slack szła informacja, że środowisko testowe zostało zaktualizowane;

• Dodatkowo, codziennie o 5 rano odpalane były testy wydajnościowe i integracyjne a ich wynik również lądował na Slacku.

W ten prosty sposób przychodząc rano do biura miałem pewność, że mogę spokojnie iść na warsztaty z interesariuszami oraz kluczowymi użytkownikami i po prostu skupić się na „produktowej” pracy.

8. Współpraca w praktyce

Na koniec prześledźmy jeszcze kluczowe punkty styku współpracy testerów i Product Ownera:

1. Sprint Planning

Testerzy aktywnie uczestniczą w spotkaniu planując swoją prace i to jak mogą wesprzeć zespół w pracach wytwórczych. (Patrz: krótka ścieżka informacji zwrotnej, swarming).

2. Daily Standup

Product Ownera na tym spotkaniu nie ma, ale dobrze by było, gdyby testerzy przynajmniej biernie uczestniczyli w Daily Standupie. Cel jest taki, aby byli oni na bieżąco ze wszystkimi ważnymi bieżącymi pracami po to, aby móc jeszcze lepiej wesprzeć cały zespół w dostarczeniu wartości biznesowej na koniec sprintu.

3. Backlog Refinement

Aktywne uczestnictwo testerów w spotkaniu, gdzie z jednej strony mogą zapoznać się z wymaganiami, z drugiej, mogą być ważnym głosem challangującym wymagania biznesowe.

4. Sprint Review

• Testerzy prezentują raport z wynikami testów wykonanych podczas sprintu (zarówno testów manualnych jak i automatycznych). Może to być spis wykonanych testów wraz z wynikami.

• Testerzy mogą zaprezentować rekomendacje lub obawy co do
  obecnego procesu jakości.

5. Proces jakości

Dobrze by było, aby testerzy wsparli zespół oraz PO w zakresie Definition of Done, monitorowali proces jakości w zespole, monitorowali poziom błędów powdrożeniowych (nowych i błędów regresji), stanowili ważny głos w rozmowie czy proces utrzymania jakości nie powinien być bardziej dojrzały.

6. Zespół

Testerzy jako część zespołu znacznie lepiej się sprawdzi niż gdybyśmy mieli oddzielne zespoły: developerski i QA.

9. Ale… po co mi to wszystko?

Czy nie powinno być tak, że to Scrum Master „pilnuje” jak działa proces zwinny w zespole?

Teoretycznie tak, ale…

• nie zawsze będziemy mieli do dyspozycji Scrum Mastera,

• nie zawsze Scrum Master jest wystarczająco doświadczony, żeby zaobserwować, że w danym obszarze jest problem,

• czasem Scrum Master skupia się na innych elementach procesu Scrumowego.

Uważam, że z perspektywy Product Ownera warto po prostu znać niuanse współpracy z zespołem wytwórczym, a w szczególności testerami. Jest to niezwykle istotne, żeby świadomie patrzeć na otaczającą nas rzeczywistość i móc trafnie ocenić na ile dojrzale poukładane są wszystkie elementy dookoła.

Czasem te drobiazgi potrafią przynieść nam korzyści bez wprowadzania „rewolucji”, a powyższe przykłady to po prostu dobre praktyki, o które warto zadbać.

Autor: Mateusz Kapica - CTO w firmie Widelab, Agile Project Manager z dużym doświadczeniem w międzynarodowych projektach IT. Aktywnie działa w branży IT od ponad 13 lat. Po trzech latach spędzonych w Danii przy projekcie rewolucjonizującym duńskie koleje, obecnie rozwija Widelab - Product Design and Development Studio. Ponad 700 godzin na sali szkoleniowej jako trener.

Częstym błędem jest niestety zbyt długie rozwijanie produktu w ukryciu. W wielu przypadkach okazuje się, że straciliśmy sporo czasu na wytworzenie funkcjonalności, które tak naprawdę są nieprzydatne. W najgorszym wypadku, nasz system czy aplikacja będzie tak przeciążona, że nikt nie będzie z niej korzystać.

Co zrobić aby odnieść sukces przy jak najmniejszym nakładzie czasu? Wykorzystaj Minimum Viable Product (MVP) oraz Minimum Marketable Product (MMP).

• 1. Minimum Viable Product

• 2. Minimum Marketable Product

• 3. Porównanie MVP oraz MMP

• 4. Zależność pomiędzy MVP a MMP

1. Minimum Viable Product

Minimum Viable Product (MVP) oznacza wykonanie jak najmniejszej liczby kroków, które pozwolą na ocenę naszych pomysłów, poprzez zebranie odpowiedniego feedbacku od użytkowników. Przykładem MVP może być funkcjonalny prototyp czy pierwsze wydanie wersji produktu dla ograniczonej liczby użytkowników w celu zebrania informacji zwrotnej.

Cała idea polega na stworzeniu wstępnej wersji dla określonej grupy, zgromadzeniu opinii i nauce, czyli wyciągnięciu wniosków w jakim kierunku iść dalej. Ponadto, cały proces powinien odbyć się przy jak najmniejszym wysiłku.

Częstym błędem w rozumieniu MVP jest to, aby zbudować pierwszą wersję produktu jak najszybciej. Nic bardziej mylnego! MVP powinno być wykorzystywane jako eksperyment, który pomoże zespołowi w zweryfikowaniu pomysłu, ryzyk i nauce. Nie myśl o produkcie, myśl o eksperymencie!

Główną osobą odpowiedzialną za zbudowanie wizji i jasnego celu MVP jest Product Owner/Manager. Wraz z zespołem powinni wybrać jak najmniejszą liczbę zadań/funkcjonalności potrzebną do wdrożenia (w Scrumie zwane historyjkami użytkownika). Oczywiście, długość tworzenia MVP zależy od liczby budowanych funkcjonalności oraz rynku, dla którego produkt jest tworzony.

Jednymi z gotowych narzędzi, które pomogą nam w przetestowaniu pomysłów są narzędzia do budowania prototypów. Wykorzystuj prototypy w swojej pracy, a często zaoszczędzisz sporo czasu. Inne narzędzie pozwalają natomiast na zbudowanie strony internetowej w kilka minut. Wszystko to odbywa się poprzez wypełnienie kilku pól w formularzu. Dodatkową opcją jest dodanie reklamy Google.

Jednym z dobrych przykładów stworzenia MVP jest Dropbox. W początkowej fazie autor zaprezentował swój pomysł poprzez stworzenie nagrania video, w którym przedstawił główną ideę. Po otrzymaniu pozytywnego feedbacku był pewien, że będzie to strzał w dziesiątkę!

2. Minimum Marketable Product

Minimum Marketable Product jest terminem odnoszącym się do produktu, który posiada najmniejszą liczbę właściwych cech, ale nadaje się do sprzedaży i wprowadzenia na rynek. Takie podejście pozwala na szybsze wdrożenie produktu do środowiska produkcyjnego i szybsze rozpoczęcie generowania zysków.

MMP pozwala na skupieniu się na ograniczonej liczbie funkcji zamiast długiego tworzenia produktu w ukryciu. Oprócz zminimalizowanego ryzyka, zyskujemy na koszcie i czasie. Zbudowanie perfekcyjnego produktu, który dopiero wypuścimy w świat nigdy nie jest najlepszym rozwiązaniem!

Jednym z najbardziej trafnych i znanych przykładów MMP jest wprowadzenie na rynek oryginalnego iPhona w 2007 roku.

Z jednej strony zespoły Apple’a włożyły dużo wysiłku i pracy aby zbudować działający produkt. Z drugiej jednak w telefonie brakowało znacznej liczby podstawowych funkcji np. kopiuj i wklej czy wysyłania wiadomości do wielu użytkowników jednocześnie! Po pierwszym sukcesie, Apple rozpoczął pracę nad rozbudową i udoskonalaniem systemu.

Jak więc zbudować MMP?

• Ogranicz produkt do konkretnego segmentu rynku (nie staraj się zadowolić wszystkich jednocześnie!)

• Wybierz tylko te funkcjonalności, które są niezbędne dla danej grupy docelowej (niezbędne oznacza te cechy, które spowodują odniesienie sukcesu na rynku. Wykorzystaj MVP do określenia właściwych funkcjonalności!)

3. Porównanie MVP oraz MMP

MVP i MMP to dwa różne narzędzia, które służą temu samemu celowi - szybszemu dotarciu do działającego produktu przy minimalnym ryzyku. Jeśli jednak mielibyśmy je porównać:

• MVP to eksperyment - Budujesz go po to, żeby się czegoś nauczyć - sprawdzić hipotezę, zebrać feedback, zrozumieć czy w ogóle idziesz w dobrą stronę. Niekoniecznie trafia do szerokiego rynku - często wystarczy ograniczona grupa użytkowników gotowych dać ci szczerą opinię.

• MMP to już produkt - Ma konkretne funkcje, działa i - co najważniejsze - można go sprzedać. Nie jest doskonały, ale jest wystarczający, żeby ktoś chciał za niego zapłacić.

Dobrym przykładem tej zależności był wspomniany wcześniej Dropbox. Nagranie video było MVP - zero kodu, tylko weryfikacja czy pomysł w ogóle kogoś interesuje. Dopiero po pozytywnym feedbacku zaczęto budować właściwy produkt. Pierwsza działająca wersja Dropboxa dostępna dla użytkowników - to już był MMP.

4. Zależność pomiędzy MVP a MMP

W najprostszym znaczeniu, możemy stwierdzić, że na jeden MMP składa się kilka MVP. Różnica polega na tym, że MVP traktujemy jako eksperymenty. Zbieraj opinie od użytkowników i na tej podstawie iteracyjnie ulepszaj swój produkt. Czasami Twoje MVP może składać się z prostego prototypu, dzięki któremu przetestujesz sensowność poszczególnego pomysłu. Takie podejście zwiększa sukces końcowej aplikacji czy systemu.

Jak poznać, że jesteś gotowy na MMP?

Jeden z najtrudniejszych momentów w budowaniu produktu to decyzja - kiedy skończyć eksperymenty i powiedzieć "to jest gotowe na rynek". Nie ma tu idealnej odpowiedzi, ale są konkretne sygnały, które mówią że czas działać.

Sprawdź poniższe punkty. Jeśli większość z nich jest prawdą - prawdopodobnie masz już MMP, nie MVP.

Sygnały od użytkowników

• Użytkownicy wracają do produktu bez żadnego przypominania z Twojej strony

• Ktoś zapytał czy może zapłacić - albo był zaskoczony, że produkt jest darmowy

• Użytkownicy polecają produkt znajomym z własnej inicjatywy

• Dostajesz feedback "kiedy będzie funkcja X?" - czyli ludzie planują zostać na dłużej

Sygnały z danych

• Retencja jest stabilna przez minimum 2-3 cykle

• Wiesz skąd przychodzą użytkownicy i który kanał działa najlepiej

• Główna metryka produktu rośnie lub jest stabilna - nie spada

Sygnały z hipotez

• Kluczowe założenia biznesowe zostały zweryfikowane - wiesz kto jest Twoim użytkownikiem i jaki problem rozwiązujesz

• Kolejne eksperymenty przynoszą coraz mniej nowej wiedzy - zaczynasz potwierdzać to co już wiesz

• Masz jasność co do segmentu rynku i funkcji niezbędnych dla tej grupy

Jeśli większość punktów jest odznaczona - przestań eksperymentować i zacznij sprzedawać. Najgorsze co możesz zrobić to czekać na idealny moment. On nie nadejdzie.

Pamiętaj aby zawsze mieć jasną i klarowną wizję produktu, który wytwarzasz. Myśląc o MVP, miej na uwadze również MMP. W przeciwnym wypadku może się okazać, że Twój produkt zawiera kilkadziesiąt funkcji, które są wartościowe osobno, ale nie mają większego sensu razem. A teraz do dzieła!

Każdy Product Manager zadaje sobie pytanie: jak mierzyć i optymalizować działania, aby skutecznie zwiększać bazę swoich klientów. Jest na to prosta odpowiedź: metryki AARRR.

To narzędzie umożliwia pomiar i optymalizację lejka konwersji Twoich użytkowników. Co więcej - jest na tyle proste, że nie wymaga technicznej wiedzy. Dzięki tym metrykom będziesz w stanie podejmować szybkie i trafne decyzje, które będą poparte konkretnymi liczbami.

• 1. Charakterystyka metryki AARRR

  • 1.1. Acquisition (Pozyskiwanie) - skąd biorą się u …

  • 1.2. Activation (Aktywacja) - czy użytkownik poczu …

  • 1.3. Retention (Powrót) - czy użytkownik wraca?

  • 1.4. Referral (Polecenie) - czy użytkownicy poleca …

  • 1.5. Revenue (Zysk) - czy użytkownik płaci?

• 2. Przykłady

• 3. Od czego zacząć?

• 4. Najczęstsze błędy przy AARRR

• 5. Podsumowanie

1. Charakterystyka metryki AARRR

AARRR składa się z 5 poziomów - każdy z nich odpowiada na inne pytanie o zachowanie użytkownika w Twoim produkcie.

1.1. Acquisition (Pozyskiwanie) - skąd biorą się użytkownicy?

Acquisition oznacza pozyskiwanie użytkowników do Twojego produktu. Dla każdego produktu pozyskanie oznacza jednak coś innego. Na przykład dla narzędzia do e-mail marketingu może to być zapisanie się na 30-dniową, bezpłatną wersję produktu. Z kolei dla bloga może oznaczać liczbę użytkowników w serwisie w danym czasie. Niemniej jednak warto na tym etapie sprawdzić skąd biorą się użytkownicy w Twoim serwisie. Czy odwiedzili stronę z mailingu, który im wysłałeś, a może znaleźli Twój serwis w wyszukiwarce Google? Są to niesamowicie cenne informacje, które pokażą najważniejsze źródła ruchu w Twoim produkcie.

1.2. Activation (Aktywacja) - czy użytkownik poczuł wartość produktu?

Activation to aktywacja użytkownika w produkcie, tzw. „1st happy visit”. Przykładowo skorzystanie z produktu do e-mail marketingu – utworzenie pierwszego maila. Z kolei dla serwisu blogowego, będzie to spędzenie minimum 2 minut w serwisie (rozumiane jako przeczytanie artykułu). Jeszcze innym przykladem jest  serwis ogłoszeniowy, dla którego aktywacją może być rejestracja lub zapis na powiadomienie e-mail.

1.3. Retention (Powrót) - czy użytkownik wraca?

Retention oznacza powrót użytkownika do produktu. Dla serwisu e-mail marketingowego będzie to ponowne zalogowanie się do serwisu . Natomiast dla bloga – powtórna wizyta lub wejście z newsletter`a, na który użytkownik wcześniej się zapisał.

1.4. Referral (Polecenie) - czy użytkownicy polecają Cię innym?

Refferal to polecenie produktu innemu użytkownikowi. Przykładowo może to oznaczać polecenie znajomego w zamian za jeden darmowy miesiąc korzystania z narzędzia do e-mail marketingu, jak i również dodanie linka do produktu w social media lub zaproszenie do polubienia Twojego fanpage’a na Facebook’u.

1.5. Revenue (Zysk) - czy użytkownik płaci?

Revenue to zapłata za skorzystanie z naszego produktu. W każdym biznesie ostatecznie chodzi o jego monetyzację. Dlatego kluczowym aspektem jest zrozumienie ścieżki użytkownika od pierwszego kontaktu z naszym produktem aż do jego zakupu.

2. Przykłady

Teoria to jedno. Ale AARRR to framework, który naprawdę rozumiesz dopiero wtedy, kiedy próbujesz go przyłożyć do konkretnego produktu.

Poniżej trzy przykłady:

• Narzędzie do e-mail marketingu - od zapisu na darmową wersję, przez wysłanie pierwszego maila, aż po zakup abonamentu

• Blog - od wejścia z wyszukiwarki, przez zapis na newsletter, aż po zakup szkolenia online

• Serwis ogłoszeniowy - od odwiedzin z różnych źródeł, przez zapis na powiadomienia, aż po zakup publikacji ogłoszenia

3. Od czego zacząć?

Znajsz już framework, ale… pytanie od czego w ogóle zacząć?

• Zmapuj swój lejek - dla każdego z 5 poziomów zdefiniuj jedną konkretną metrykę, która go reprezentuje w Twoim produkcie. Nie pięć metryk na poziom - jedną.

• Znajdź największy “przeciek” - porównaj wartości między poziomami. Gdzie jest największy spadek? To Twój punkt startowy.

• Zacznij od jednego poziomu - nie próbuj naprawiać wszystkiego naraz. Wybierz jeden poziom, postaw hipotezę dlaczego przecieka i przetestuj jedno rozwiązanie.

• Mierz w czasie - jedno odczytanie metryki nic nie mówi. Obserwuj trend przez minimum 4-6 tygodni zanim wyciągniesz wnioski.

AARRR jest przydatny tylko wtedy, kiedy traktujesz go jako narzędzie do podejmowania decyzji - nie jako tabelkę do raportu.

4. Najczęstsze błędy przy AARRR

Mam jeszcze dla Ciebie kilka pułapek, w które wpada większość zespołów przy pierwszym kontakcie z AARRR:

• Optymalizowanie akwizycji przy zerowej retencji - To najczęstszy błąd. Inwestujesz w reklamy, SEO, content - użytkownicy przychodzą, ale nie wracają. Zamiast szukać przyczyny, dokręcasz budżet akwizycyjny. Efekt: wlewasz wodę do dziurawego wiadra. Zanim zaczniesz skalować pozyskiwanie, upewnij się, że produkt faktycznie zatrzymuje użytkowników.

• Otymalizacja wszystkiego naraz - AARRR to 5 poziomów, ale nie oznacza to, że musisz optymalizować wszystkie jednocześnie. Zidentyfikuj, który poziom lejka "przecieka" najbardziej - i zacznij od niego. Rozproszenie uwagi na wszystkie metryki jednocześnie prowadzi do tego, że żadna z nich realnie się nie poprawia.

• Mylenie korelacji z przyczyną (klasyka) - Retencja spadła w tym samym tygodniu, co wysłałeś nowy onboarding - nie oznacza to, że onboarding jest przyczyną. Zanim wyciągniesz wnioski, sprawdź co jeszcze zmieniło się w tym czasie. Metryki pokazują co się dzieje, nie zawsze dlaczego.

5. Podsumowanie

Lejek metryk AARRR bardzo jasno pokazuje jak konwertuje dany biznes. Dzięki metrykom można trafnie zdiagnozować najważniejsze obszary do optymalizacji. Bardzo ważne jest, aby analizować metryki z dłuższej perspektywy czasowej i zweryfikować jak poszczególne dane zmieniają się w czasie – które spadają, które rosną i jak wpływają na siebie nawzajem.

Dzisiaj kontrowersyjny temat - SYNTETYCZNI użytkownicy 🫥.

Idea jest banalnie prosta: zamiast badać prawdziwych użytkowników, tworzysz agenta AI, który ich symuluje. Część AI-native zespołów produktowych chwali się ich stosowaniem w product researchu. Tylko czy to ma sens?

Podrzucam Ci wyniki moich eksperymentów, które prezentowałem podczas 10x Product Bootcampu. Pokażę Ci, gdzie to może zadziałać, gdzie jestem sceptyczny, i jak użyłem syntetycznych użytkowników w produkcie ⤵️

1. Czym są syntetyczni użytkownicy i jak działają (w pigułce)

2. Jak wygląda “wynajęcie” agentów do wywiadów i testów użyteczności?

3. Mój realny test Product Academy w Reforge Build - od persony, przez zadania, po wynik

4. Raport z insightami (krytyczne / medium / low) + replay sesji agenta na mobilu

5. Alternatywa - jak puścić agenta po stronie z poziomu Claude w Chrome

Więcej takich AI Workflows znajdziesz w Bazie Praktyk Produktowych w naszym ProductLABie (masz do niego dostęp jeśli jesteś absolwentem jednego naszych programów, w tym 10x Product Bootcampu). Ostatnio pojawiło się kilka nowych materiałów ⤵️

Dzisiaj kończymy pierwszą edycję 10x Product Bootcampu, będę niedługo pisał podsumowanie, bo było naprawdę intensywnie. 50% uczestników już wdrożyło zmiany w swojej pracy 🫣

Tymczasem mam dla Ciebie jedną z inspiracji do budowania własnych AI workflows, którą pokazywałem właśnie podczas Botocampu: jak z agentem AI analizuję teraz dane produktowe (Calude + PostHog)? Demo na moich konkretnych danych ⤵️

1. Jak podłączyć Clauda do PostHoga przez MCP - to dosłownie kilka kliknięć w connectors.

2. Wykrywanie patternów - pytam “czy widzisz tu jakiś pattern?” i Claude identyfikuje rytm tygodniowy w danych.

3. Analiza rage clicków - gdzie użytkownicy się gubią i na której stronie to się koncentruje.

4. Session recordings - Claude generuje bezpośrednie linki do nagrań sesji z problemem.

5. Weryfikacja hipotezy o nowym ficzerze - czy ktoś w ogóle z niego korzysta i jak wygląda trend po wdrożeniu.

6. Projekt analityczny - jak skonfigurować asystenta, żeby rozumiał Twój produkt i dawał lepsze odpowiedzi.

Więcej takich AI Workflows znajdziesz w Bazie Praktyk Produktowych w naszym ProductLABie (masz do niego dostęp jeśli jesteś absolwentem jednego naszych programów, w tym 10x Product Bootcampu). Ostatnio pojawiło się kilka nowych materiałów ⤵️

Muszę przyznać, że mam słabość do modeli. Podoba mi się w nich to, jak potrafią świetnie uprościć skomplikowane zjawiska, zachowując jednocześnie ich esencję. Dzięki temu ułatwiają współpracę, dostarczają język i obraz do wspólnego ich zrozumienia.

W tym artykule podzielę się trzema modelami, które wydają mi się najbardziej ciekawe i pożyteczne z perspektywy zarządzania produktem: Model Cynefin, Model Dyfuzji Informacji i Model Kano. Opowiem o ich pochodzeniu i zastosowaniu w pracy Product Managera.

• 1. Model Cynefin

• 2. Model dyfuzji innowacji

• 3. Model Kano

• 4. Podsumowanie

1. Model Cynefin

Opiszę ten model jako pierwszy, bo jest mi najbardziej bliski.

Model Cynefin został stworzony w 1999 przez Dave’a Swondena na potrzeby IBM. Przedstawia on 4 główne konteksty w jakich podejmowane są decyzje: prosty, skomplikowany, złożony, chaotyczny.

Prosty i skomplikowany to konteksty deterministyczne. Oznacza to tyle, że operując w tych właśnie kontekstach, jesteśmy w stanie zawczasu przewidzieć efekty naszych działań. W kontekście prostym związek przyczynowo-skutkowy jest dobrze widoczny i istnieje jedno rozwiązanie problemu. Przykład: Jeśli jestem spragniony powinien się nawodnić.

W kontekście skomplikowanym znalezienie rozwiązania wymaga dogłębnej analizy i zazwyczaj istnieje więcej niż jedno rozwiązanie. Przykładem tu może być budowa mostu. Nie jest to łatwy projekt i wymaga dużej wiedzy z zakresu inżynierii i fizyki. Prawa fizyki są jednak przewidywalne i możliwe jest zaprojektowanie konstrukcji, która wytrzyma przewidziany udźwig.

Inaczej sprawy się mają z kontekstem złożonym i chaotycznym. Konteksty te nie są deterministyczne. Nie jest możliwe przewidzenie efektów swoich decyzji. O ile jednak kontekst chaotyczny nie poddaje się żadnym regułom i kieruje się tylko przypadkiem, o tyle kontekst złożony można “okiełznać” poprzez eksperymentowanie.

Właśnie ten model moim zdaniem najlepiej obrazuje wyższość Agile i Lean Startup nad tradycyjnym podejściem Waterfall.

W moim doświadczeniu jednym z najczęstszych błędów w zarządzaniu produktem jest podchodzenie do złożonych problemów w sposób jakby były one skomplikowane. Poświęcamy dużo czasu na analizowanie i debatowanie problemu, w poszukiwaniu najlepszego rozwiązania. Wydaje nam się, że im więcej czasu poświęcimy na tej analizie tym lepszy rezultat otrzymamy. Jest to szczególnie zauważalne u osób technicznych, z wiedzą i doświadczeniem w obrębie programowania, gdyż problemy z jakimi mierzą się na co dzień programiści są bardzo często skomplikowane.

Tymczasem rozwój produktów digitalowych ma więcej wspólnego z kręceniem filmu niż z budową mostu. Oczekiwany rezultat zależy od jednego z najbardziej nieprzewidywalnych czynników w świecie przyrody – ludzkiego zachowania.

Nie zrozumcie mnie źle. Pewna dawka analizy i debaty jest jak najbardziej zdrowa i pożądana. Używając naszego doświadczenia, sprawdzonych heurystyk i inteligencji zbiorowej jesteśmy w stanie zwiększyć szansę na sukces. Jednak zawsze naszym priorytetem powinno być jak najszybsza walidacja hipotez poprzez wywiady pogłębione, ankiety, testy użyteczności, eksperymenty A/B, MVP itd. W ten sposób dużo szybciej dojdziemy do optymalnego rozwiązania. Zamiast godzinami debatować, które rozwiązanie jest lepsze, po prostu to przetestuj!

Jeśli nie masz łatwego dostępu do użytkowników przetestuj rozwiązanie na kolegach z pracy (najlepiej z działu sprzedaży lub wsparcia klienta). Nie jest to może idealne rozwiązanie, ale i tak będzie to o wiele lepiej wykorzystany czas.

2. Model dyfuzji innowacji

Za ojca tego modelu powszechnie uważa się Everatta Rogersa, profesora socjologii, który przedstawił go w publikacji “Diffusion of innovation” wydanej w 1961 r.

Model ten został wykorzystany przez Geoffreya Moore’a w książce “Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers” do opisu adopcji nowych technologii przez różne grupy społeczne.

Idea modelu jest taka, że każdy nowy produkt czy technologia jest przyswajana w fazach, przez kolejne segmenty odbiorców cechujące się odmiennym zachowaniem w kontekście adopcji innowacji.

Najpierw przyswajany jest przez małą grupę “Innowatorów”, którzy są fanami nowości i są skłonni podjąć ryzyko związane z używaniem niesprawdzonego produktu, jeśli tylko uznają go za innowacyjny. Cechuje ich duży entuzjazm i odporność na mankamenty niedojrzałego produktu. Najważniejsze dla nich jest poczucie prestiżu związane z byciem pionierem.

Kolejną grupą są “Early Adopters”, którzy są podobni do “Innowatorów” w swoim entuzjazmie i wyrozumiałości. Potrzebują jednak pewnej dozy społecznego dowodu słuszności (wiedzy o tym, że produkt jest używany przez innych).

Po nich przychodzą kolejne grupy: “Early Majority”, “Late Majority” i “Laggers”. Każda kolejny segment odbiorców ma mniejszą skłonność do adaptacji nowości i większe wymagania co do jakości i społecznego dowodu słuszności.

Model ten jest szczególnie przydatny na etapie wprowadzania produktu na rynek. Kolejne wersje produktu powinny być dostosowane do kolejnych segmentów odbiorców na wykresie.

I tak wersja MVP produktu może być bardzo prosta, bo trafia do grupy “Innowatorów” i “Early Adopters”. Na tym etapie powinno się zachować jeszcze dużą czujność. Sukces produktu w tych grupach odbiorców jest wskazaniem do dalszego jego rozwoju, jednak dopiero przekonanie do produktu grupy Early Majority (czubek wykresu) wskazuje na Product-Market fit.

Model Dyfuzji Innowacji przydaje się również w zrozumieniu ryzyka wprowadzania innowacyjnych technologii, czy metodyk do produktu. Dobrze jest inwestować w nowatorskie rozwiązania i projektować na przyszłość, jednak trzeba inwestować rozważnie, mając świadomość, że innowacja może się nie przyjąć, lub jej adopcja będzie trwała dużo dłużej niż zakładaliśmy. Jak mówi przysłowie “Myślał indyk o niedzieli…”.

3. Model Kano

Model ten został zaproponowany w 1984 roku przez japońskiego uczonego Noriaki Kano. Kano zakłada, że satysfakcja klienta z używania produktu rośnie wraz z inwestycją w dany produkt.

W zależności od tego jaką funkcję produktu rozwijamy zależność pomiędzy inwestycją, a satysfakcją może przybierać 4 różne formy:

Podstawowe wymagania (Must-Be) – funkcje produktu, które są absolutnie konieczne i ich brak powoduje rozczarowanie, lecz ich rozwój nie wpływa na zwiększenie satysfakcji użytkownika. Na przykład użytkownicy samochodu osobowego oczekują czterech kół, lecz dodanie kolejnych dwóch nie poprawi ich satysfakcji z używania auta.

Wydajność (Performance) – inwestycja w ten rodzaj funkcji produktu przekłada się w sposób liniowy na satysfakcję. Im bardziej samochód jest oszczędny czy bezawaryjny, tym większe zadowolenie użytkownika.

Ekscytacja (Attractive) – funkcje produktu, których użytkownik nie oczekuje, lecz ich odkrycie wprawia użytkownika w zachwyt. Do tej kategorii zaliczamy wszelkie “trafione” innowacje typu autonomiczne parkowanie, czy komputer pokładowy sterowany głosem. Inwestowanie w te funkcje powoduje wykładniczy wzrost satysfakcji użytkownika.

Obojętność (Indifferent) – inwestowanie w te funkcje produktu nie powodują żadnego wzrostu satysfakcji użytkownika. Są one mu zupełnie obojętne.

Kano proponuje ankietę, w której użytkownicy są pytani o ich stosunek do danej funkcji produktu i jej braku. Na podstawie kombinacji udzielonych odpowiedzi można odpowiednio skategoryzować daną funkcję produktu. Nie chcę tutaj się rozpisywać nad szczegółami działania tej ankiety, ale zainteresowanym polecam ten artykuł.

Model Kano jest modelem do priorytetyzacji. Idea jest taka, że funkcje rozwijamy w kolejności Podstawowe Wymagania > Wydajność > Ekscytacja. Oczywiście zachęcam do spróbowania takiego wykorzystania modelu, lecz nawet bez tego model jest przydatny, gdyż skłania do kilku istotnych refleksji.

• Po pierwsze dobrze jest sobie zdać sprawę z faktu, że każda nowa funkcja jaką dodajemy do produktu ma największe szanse (ok. 70%) być użytkownikom zupełnie obojętna. Wynika to ze złożoności ludzkich zachowań opisanej na początku artykułu.

• Po drugie, najbezpieczniej jest inwestować w funkcje w kategorii “Wydajność”. Oczywiście zbiór tych funkcji jest inny dla każdego produktu, lecz najczęściej znajduje się tu intuicyjność i szybkość działania interfejsu, a także stabilność systemu.

• Po trzecie nasza kreatywność będzie najczęściej wycelowana w szukanie funkcji ekscytujących. Z takimi pomysłami będą też do nas przychodzić zwykle wewnętrzni interesariusze, szczególnie ci z literką C w tytule (CEO, CFO, CPO itd.). Niestety bardzo mały promil ludzi ma zdolności wizjonerskie Steva Jobsa, Elona Muska czy Henry’ego Forda. Większość z nich nie trafi w gusta naszych użytkowników ponieważ nie będzie zaspokajać żadnych realnych potrzeb, a kreowanie nowych potrzeb to ekstremalnie trudna sztuka (na każdy jeden iPod przypada 1000 Segwayów).

• Po czwarte powinniśmy cały czas mieć oczy szeroko otwarte na niespełnione “podstawowe wymagania” i realizować je w pierwszej kolejności. Branża technologii jest bardzo dynamiczna i coś co jeszcze niedawno było miłym dodatkiem, może szybko zmienić się w podstawowe wymaganie.

Przestrzegam jednak przed zbyt pochopnym kwalifikowaniem funkcji jako podstawowe wymaganie tylko na podstawie analizy konkurencji. Każdy produkt jest inny i przyciąga inny typ klientów. To że większość konkurencyjnych produktów ma jakąś funkcję nie oznacza jeszcze, że nasi użytkownicy postrzegają ją jako niezbędną. Dlatego bardzo ważne jest zweryfikowanie takich założeń z użytkownikami.

Dla przykładu Basecamp jako jeden z nielicznych rozwiązań do zarządzania projektami nie posiada funkcji diagramów Gantta i raczej nie zanosi się na to żeby taką funkcję dodali. Po prostu nie pasuje to do ich wizji produktowej, ani oczekiwań ich “wzorowych klientów”.

Mając na uwadze wszystkie poprzednie punkty, najlepiej jest rozwijać produkt w sposób zrównoważony. Product Manager, niczym wytrawny inwestor giełdowy, powinien umieć dywersyfikować ryzyko. Traktuj swoją roadmapę jak zrównoważony portfel inwestycyjny zawierający funkcje z każdego z trzech opisanych wyżej typów. Dla przykładu 20% zasobów możesz poświęcić na ryzykowne innowacje, 30% na bezpieczne usprawnienia wydajności i 50% na konieczne podstawowe wymagania.

To tyle póki co w temacie modeli. Bardzo mnie ciekawi jakie modele Ciebie najbardziej inspirują. Zapraszam do dyskusji.

4. Podsumowanie

Modele, które wspólnie omówiliśmy – Cynefin, Dyfuzja Innowacji i Kano – to coś więcej niż teoretyczne schematy; to Twoje instrumenty do nawigacji w świecie pełnym niepewności:

• Cynefin uczy nas pokory wobec złożoności i promuje eksperymentowanie zamiast jałowych debat.

• Model Rogersa i Moore’a przypomina, że produkt musi dojrzewać wraz z rynkiem.

• Kano daje brutalnie szczery wgląd w to, co realnie buduje satysfakcję użytkownika, a co jest tylko „szumem”.

Pamiętaj jednak, że nawet najbardziej elegancki model jest jedynie mapą, a nie samym terenem. Jako Product Manager nie szukaj w nich gotowych recept, ale wspólnego języka dla swojego zespołu. Używaj ich, by szybciej wyciągać wnioski, mądrzej dywersyfikować ryzyko i – przede wszystkim – by zamiast „dowożenia funkcji” (outputs), skupić się na generowaniu realnej wartości (outcomes).

Bo ostatecznie to nie piękno Twojej roadmapy, ale rozwiązane problemy użytkowników świadczą o sukcesie produktu.

Autor: Mateusz Miodek - Head of Product w startupie HCM Deck. Wcześniej przez 7 lat pracował jako Product Manager i Head of Product w DataFeedWatch. Specjalizuje się w strategii produktów typu SaaS B2B. Jest wielkim fanem podejścia "Outcomes over Outputs" i filozofii "Empowered Product Teams" Marty Cagena.

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”