Zapraszam do czwartej już część przewodnika po stosowaniu 20 pryncypiów „Product Operating Model" Marty Cagana. Tu jesteśmy 👇
PART 4: Product Discovery - pryncypia pracy nad odkrywaniem 👈
BONUS 🎁: Na końcu znajdziesz też praktyczny arkusz, który możesz użyć do samooceny stosowania pryncypiów w Twoim zespole. ⤵️
BTW. Pozostały 2 ostatnie bilety na jesienną edycję Product Management Academy. Jeśli chcesz poćwiczyć ze mną i innymi PM/PO produktowy warsztat - teraz jest ostatnia szansa na zapis!
Jeśli zespoły produktowe są sercem Product Operating Modelu, to Product Discovery jest jego mózgiem. To właśnie w tym obszarze dzieje się szybkie odkrywanie, jak rozwiązać problem, który został przypisany zespołowi.
Celem Discovery nie jest tylko znalezienie rozwiązania, ale przede wszystkim zebranie dowodów, że to rozwiązanie jest naprawdę wartościowe (klient będzie chciał z niego korzystać), użyteczne (użytkownik będzie w stanie zrozumieć i używać), wykonalne (zespół jest w stanie je zbudować) i opłacalne (będzie działać dla naszego biznesu).
Product Discovery to ciągłe, szybkie eksperymentowanie, w celu znalezienia rozwiązania, które spełnia wszystkie wspomniane ograniczenia i osiąga pożądany outcome.
Marty Cagan wyróżnia tu cztery główne zasady dobrego robienia discovery ⤵️
1️⃣ Minimalizacja Strat (Minimize Waste)
2️⃣ Ocena Ryzyk Produktowych (Assess Product Risks)
3️⃣ Szybkie Eksperymentowanie (Embrace Rapid Experimentation)
4️⃣ Odpowiedzialne Testowanie (Test Ideas Responsibly)
🎁 BONUS: Aby ułatwić Ci zastosowanie tego przewodnika w praktyce - na końcu znajdziesz też praktyczny arkusz, którego możesz użyć do samooceny stosowania pryncypiów w Twoim zespole.
1️⃣ Minimalizacja Strat (Minimize Waste)
To pryncypium dotyczy efektywności. Chodzi o to, aby szybko testować pomysły, zanim zainwestujemy w nie znaczne zasoby. Ideą jest unikanie budowania czegoś, co okaże się bezwartościowe lub nieużyteczne.
Minimalizacja strat oznacza, że testujemy hipotezy najszybszym i najtańszym możliwym sposobem, żeby zdobyć wiarygodny dowód (lub kontrdowód) przed inwestycją w delivery.
Marty podkreśla, że "discovery track" (ścieżka odkrywania) ma za zadanie szybko generować zweryfikowane elementy backlogu produktu, a "delivery track" (ścieżka dostarczania) - tworzyć możliwe do wydania oprogramowanie
W praktyce oznacza to, że Product Trio powinno wspólnie tworzyć prototypy, testy typu fake-door / concierge / Wizard-of-Oz, krótkie tech-spike’i i PoC, aby zbić ryzyka (value, usability, feasibility, viability) zanim wejdziemy w kosztowny kod produkcyjny.
Celem discovery nie jest „idealna odpowiedź”, tylko szybka decyzja: stawiamy na to / iterujemy / zabijamy pomysł.
✅ Po czym poznasz realizację tego pryncypium
Jak poznasz, że pryncypium NIE jest realizowane? | Jak poznasz, że pryncypium JEST obecne w firmie? |
|---|---|
❌ Zawsze zaczynacie od zbudowania MVP na produkcji. | ✅ Szukacie pomysłów na testy przez MVP - Prototypy / PoC / testy wartości i użyteczności na makietach. |
❌ Brak timeboxu na discovery dla inicjatywy; tematy „mielą się” tygodniami. | ✅ Timebox (np. 1–2 tyg.) + exit criteria na podjęcie decyzji co dalej z inicjatywą |
❌ Backlog pełen niezweryfikowanych pomysłów (np. „bo konkurencja ma”). | ✅ Jasne wskazanie dowodów przy epiku/story w backlogu; bez dowodu temat wraca do discovery. |
❌ Nie zabijacie realizowanych pomysłów - wszystko jedzie dalej „bo szkoda pracy” | ✅ Cześć rozwiązań jest wycofywana - nauka z odrzuconych pomsyłów jest dokumentowana i udostępniana. |
❌ Testujecie tyko finalne wersje (po miesiącach developmentu). | ✅ Szybkie testy prototypu (fake-door, landing, pricing smoke) przed budową. |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Jaki był ostatni eksperyment wykonany przed pisaniem kodu produkcyjnego - i czego się z niego dowiedziałeś?
Czy potrafisz wskazać ostatni temat, który zabiłeś na bazie eksperymentów?
Czy discovery jest timeboxowane (np. 1–2 tygodnie), a wyniki kończą się decyzją?
Czy testujesz wartość, użyteczność, wykonalność i opłacalność pomysłu - czy skupiasz się głównie na „czy umiemy zbudować”?
Czy dla bieżącego pomysłu masz hipotezę i kryteria decyzji (co musi się wydarzyć, by iść dalej)?
Czy każdy epik ma Evidence link (dowód, że warto go robić), zanim trafi do delivery?
🚀 Jak zacząć wspierać To swoim działaniem?
Discovery timebox + exit criteria dla najważniejszych inicjatyw. Ustalcie sobie proces np. jeden sprint na eksperymenty i podjęcie decyzji co dalej z inicjatywą.
Menu szybkich testów - uzgodnij w zespole listę gotowych metod, które możecie łatwo i szybko zastosować: fake-door, prototype test, concierge/WoZ, ankiety, tech-spike/PoC
Zróbcie sobie Discovery Kanban - Hipoteza → Planowanie testu → In-progress → Decyzja. Ogranicz WIP do 1–2 tematów.
Włącz tech leada od początku do discovery - Poproś o tech-spike na największe ryzyko techniczne (wydajność, integracje, koszty) równolegle do testów wartości.
Mierz „learning velocity” - liczba zweryfikowanych / obalonych hipotez na kwartał + czas od insightu do decyzji.
Dodaj do każdego Epika “Evidence Link” lub po prostu listę dowodów - eksperymentów które potwierdziły realizacje tego pomysłu.
🛠️ Moje praktyczne doświadczenia: minimalizacja strat to czasem ewaluacja na produkcji
Choć w pełni zgadzam się z pryncypium, że najpierw testujemy, a potem budujemy, to w praktyce najmniejszą stratą czasu potrafi być… wdrożenie drobnej zmiany na produkcję i pomiar metryk.
Często widzę zespoły, które z obawy przed „marnotrawstwem” nie podejmują decyzji.
Aby to działało, to ta mała zmiana na produkcji powinna mieć hipotezę, metrykę sukcesu, guardrails i exit criteria (kiedy porażka). Wtedy „szybkie wdrożenie” nie staje się feature factory, tylko najtańszą ścieżką do dowodu.
Fajnie to wizualizuje matryca → Zrozumienie problemu vs Ryzyko. Jeśli rozumiemy problem użytkownika + jest niskie ryzyko: wdrażamy małe MVP i mierzymy zachowania (ship-to-learn).
2️⃣ Ocena Ryzyk Produktowych (Assess Product Risks):
Zanim zaczniemy budować, musimy zrozumieć, co może pójść nie tak. Celem discovery nie jest dowieźć zakres, tylko zmniejszyć niepewność do poziomu akceptowalnego — tak, by wejście w delivery miało sens biznesowy i techniczny.
To pryncypium podpowiada, by robić wczesną ocenę czterech kluczowych ryzyk:
Wartości (Value risk): Czy klienci będą chcieli tego używać lub za to płacić?
Użyteczności (Usability risk): Czy użytkownik będzie w stanie zrozumieć, jak tego używać?
Wykonalności (Feasibility risk): Czy wiemy, jak to zbudować, mając dostępne technologie, umiejętności i czas?
Opłacalności (Viability risk): Czy to rozwiązanie będzie działać dla naszego biznesu (np. pod kątem marketingu, sprzedaży, finansów, obsługi prawnej)?
Ocena tych ryzyk na wczesnym etapie pozwala na ich minimalizację i uniknięcie kosztownych błędów w dalszej fazie rozwoju.
✅ Po czym poznasz realizację tego pryncypium
Jak poznasz, że pryncypium NIE jest realizowane? | Jak poznasz, że pryncypium JEST obecne w firmie? |
|---|---|
❌ Startujemy z implementację bez zidentyfikowania i nazwania ryzyk produktowych. | ✅ W każdej inicjatywie macie zidentyfikowane ryzyka produktowa. |
❌ „Wierzymy, że klienci to pokochają” bez dowodów. | ✅ Testujecie User Value Risk. |
❌ Użyteczność sprawdzamy dopiero po release. | ✅ Prowadzimy usabilty testy. Np. testy prototypu (5–7 osób) |
❌ Feasibility „wyjdzie w praniu” - podczas realizacji. | ✅ Gdy macie wątpliwości odnośnie feasibility - robicie tech spike/PoC. |
❌ Ryzyko Business Viability jest pomijane (np. „nie my jesteśmy od sprzedaży”). | ✅ Planujecie jak weryfikować Business Viability przed developmentem |
❌ Te same decyzje mimo różnych sygnałów o ryzyku. | ✅ Ocena ryzyk produktowych wpływa na decyzje odnośnie Waszych prac |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Czy dla bieżącej inicjatywy masz zidentyfikowane ryzyka we wszystkich czterech obszarach i plan na ich weryfikację?
Jakie zbieracie dowody wartości (Value) dla inicjatyw - liczby/insighty, nie opinie?
Jak często robisz testy użyteczności prototypu przed decyzją o delivery?
Kiedy ostatnio robiliście tech spike/PoC, by potwierdzić wykonalność krytycznych elementów?
Czy sprawdzasz “viability” inicjatywy z finansami/prawnym/GTM (np. koszty, zgodność, model cenowy)?
Kiedy ostatnio zmieniłeś zdanie / plany z powodu jednego z czterech ryzyk?
🚀 Jak zacząć wspierać To swoim działaniem?
Dodaj prostą tabelę ryzyk do szablonu każdego epika / inicjatywy: Value / Usability / Feasibility / Viability
„15 min na identyfikacje ryzyk” na starcie / kick-offie inicjatywy - 15 minutowy szybki scan z trio: co jest najryzykowniejsze teraz i jaki najtańszy test to zbije w 48 godzin.
Wprowadź RAT (Riskiest Assumption Test) do planowania inicjatyw - Nazwij jedno najbardziej ryzykowne założenie i zaplanuj mikro-eksperyment w kilka dni (prototyp, fake door, mini-PoC).
Zadajcie dobie pytanie na warsztatach dotyczących inicjatywy: „Co może pójść źle w kontekście Value / Usabiltiy / Feasibility / Viablity?” i dopiszcie 1–2 szybkie testy zapobiegawcze.
Zorganizuj dedykowany warsztat dla najważniejszych inicjatyw na których rozpiszcie sobie Wasze ryzyk
🛠️ Moje praktyczne doświadczenia: Ocena ryzyk w Product Requirements Document
Analiza czterech ryzyk (Value, Usability, Feasibility, Viability) stała się u mnie stałą sekcją każdego PRD
W PRD mam tabelę z 4 kolumnami (Value / Usability / Feasibility / Viability). W każdej kolumnie wpisuję kluczowe założenia z tego obszaru oraz moją ocenę niepewności.
Do oceny niepewności używam zwykle skali niepewności (Confidence Meter) Itamara Giliada.
Najpierw atakuję obszary z najwyższą niepewnością, a w szczególności ryzyka rynkowe: Value (czy ktoś tego chce/zapłaci) i Viability (czy to ma sens dla biznesu: finanse, prawo, GTM). Dopiero potem Usability/Feasibility.
3️⃣ Szybkie Eksperymentowanie (Embrace Rapid Experimentation)
Product Discovery to nie jednorazowe badanie, ale ciągły, szybki proces eksperymentowania.
Nasz cel to time-to-evidence (jak najszybciej zdobyć wiarygodny dowód), nie „perfekcyjna specyfikacja”.
Obejmuje to wykorzystywanie zarówno technik ilościowych (analiza danych), jak i jakościowych (testy użyteczności) do szybkiego tworzenia prototypów i przeprowadzania eksperymentów.
Chodzi o to, aby weryfikować hipotezy w sposób iteracyjny i zwinny, ucząc się na bieżąco, co działa, a co nie.
Nikt nie jest w stanie przewidzieć wszystkich problemów z góry - siła tkwi w szybkim uczeniu się i adaptacji.
✅ Po czym poznasz realizację tego pryncypium
Jak poznasz, że pryncypium NIE jest realizowane? | Jak poznasz, że pryncypium JEST obecne w firmie? |
|---|---|
❌ Długie briefy badawcze, po których i tak budujemy „na czuja”. | ✅ Backlog hipotez i kanban eksperymentów z jasnym statusem i właścicielem dla eksperymentu. |
❌ Brak timeboxu; discovery „mieli się” tygodniami. | ✅ Timebox na eksperyment, po którym podejmowana jest decyzja odnośnie realizacji inicjatywy, odrzuceniu lub pogłębieniu researchu |
❌ Nie prowadzicie eksperymentów (innych niż MVP) | ✅ Często realizujecie różnego rodzaju eksperymenty |
❌ Nie obniżacie zidentyfikowanych ryzyk za pomocą eksperymentów | ✅ Dla zidentyfikowanych ryzyk planujecie eksperymenty, które mają je obniżyć |
❌ Czekacie na 100% pewność w każdym discovery | ✅ Podejmujecie decyzje równoważąc ryzyko i czas na discovery |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Czy masz backlog hipotez i wiesz, która jest najbardziej ryzykowna teraz (RAT)?
Ile eksperymentów zrobiliście w ostatnich 2 tygodniach?
Czy Wasze eksperymenty mają metrykę sukcesu, guardrails i kryteria sukcesu?
Czy podejmując decyzję o eksperymentach myślisz o minimalizowaniu „time-to-evidence”?
Czy łączysz badania jakościowo i ilościowe w podejmowaniu decyzji?
Kiedy ostatnio ubił_ś jakiś pomysł po danych z eksperymentu?
🚀 Jak zacząć wspierać To swoim działaniem?
Stwórzcie sobie Waszą własną bibliotekę tanich eksperymentów - takich które jesteście w stanie przeprowadzać szybko. Być może zacznie od jednego typu (np. fake door test), ale to i tak będzie super na start.
Stwórzcie sobie backlog hipotez + kaban na planowanie RAT. Spisz hipotezy; zacznij od najbardziej ryzykownego założenia i zaplanuj testy.
Inicjatywa „One Cheap Test a Week” - co tydzień zróbcie minimum jeden tani eksperyment; 10-min podsumowanie: wynik → wniosek → decyzja.
Wprowadźcie sobie Timebox i kryteria sukcesu dla eksperymentów.
Zorganizuj stałe sloty/mini-panel z użytkownikami (np. 3–5 rozmów/tydz.), żeby nie blokować się na potrzebnym czasie na rekrutację użytkowników.
Wprowadź zasadę, że każdy eksperyment kończ krótkim wpisem: wynik → wniosek → decyzja → wpływ na roadmapę.
🛠️ Moje praktyczne doświadczenia: Discovery Backlog
Najbardziej dynamiczne testy prowadziłem przy wprowadzaniu na rynek SentiOne Automate. Cała praca moja oraz zespołu (PM, COO, Sales, Tech Lead, AI Lead) była skoncentrowana najpierw na walidacji kluczowych założeń pod Product–Market Fit, a później na feasibility (czy umiemy to zbudować w realnych ograniczeniach).
Co tydzień spotykaliśmy się w gronie zespołu produktowego; mieliśmy w Trello backlog hipotez i kanban eksperymentów. Na każdym przeglądzie robiliśmy: aktualizację postępu, decyzje i plan kolejnych testów zgodnie z metodą RAT (Riskiest Assumption Test).
Każda karta miała: hipotezę, metrykę sukcesu, ownera i termin. Dzięki temu łatwo było utrzymać wysokie “learning velocity”.
System świetnie się sprawdził: pozwolił zweryfikować wiele dużych, trudnych do sprawdzenia założeń na rynku enterprise, zanim podjęliśmy kosztowne decyzje o pełnej implementacji.
4️⃣ Odpowiedzialne Testowanie (Test Ideas Responsibly)
Discovery nie zwalnia nas z odpowiedzialności. Eksperymenty i prototypy powinny być przeprowadzane w sposób, który chroni firmę i jej klientów.
Oznacza to, że nie wszystko, co testujemy, musi być od razu wdrażane na produkcję. Często wystarczy prosty prototyp, który symuluje funkcjonalność, aby zebrać wartościowy feedback.
Testowanie pomysłów powinno być kontrolowane i etyczne, aby nie narazić ani danych klientów, ani reputacji firmy. Chodzi o to, by testować w bezpieczny sposób (na ile to możliwe), zanim podejmiemy decyzje o pełnym wdrożeniu.
Mówiąc krótko - uczymy się szybko, ale nie ryzykujemy niepotrzebnie.
✅ Po czym poznasz realizację tego pryncypium
Jak poznasz, że pryncypium NIE jest realizowane? | Jak poznasz, że pryncypium JEST obecne w firmie? |
|---|---|
❌ „Wrzućmy na produkcję i zobaczymy.” Brak feature flag, brak możliwości rollbacku. | ✅ Najpierw prototyp/PoC, a na produkcji możecie wdrażać wykorzystując feature flag. Macie możliwość rollbacku. |
❌ Użytkownicy finalnie nie wiedzą, że brali udział w teście (np. fake door). | ✅ Stawiacie na etykę i transparentność przy eksperymentach: jasny microcopy, opt-out, alternatywa („Zostaw kontakt”). |
❌ Przetwarzamy prywatne dane użytkowników w testach bez kontroli naszej (i usera) | ✅ Privacy by design - stosujemy gdy możemy dane syntetyczne/maskowane, minimalizacja zakresu, dostęp ograniczony. |
❌ Brak progów bezpieczeństwa; eksperymenty ciągną się mimo skarg od użytkowników. | ✅ Guardrails i warunek stopu dla eksperymentów: jeśli zostanie przekroczony to eksperyment jest wyłączony. |
❌ Strategia prowadzenia eksperymentów nie jest uzgadniana z działem prawnym, bezpieczeństwo, brand itp. | ✅ Triage strategii prowadzonych eksperymentów z odpowiednimi zespołami (prawny, RODO, bezpieczeństwo, brand). |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Czy ten eksperyment musi być na produkcji, czy możesz go zrobić bezpieczniej (prototyp, symulacja)?
Jakie masz guardrails i warunki stopu (np. skargi, błędy, spadek konwersji) dla swoich eksperymentów?
Czy komunikaty do userów przy Waszych eksperymentach są jasne (bez wprowadzania w błąd) i czy istnieje opcja rezygnacji/alternatywa?
Jak ograniczasz ryzyko dla danych w ramach prowadzonych eksperymentów (anonimizacja, minimalizacja, logi)?
Czy robisz check eksperymentów z z odpowiednimi zespołami (prawny, RODO, bezpieczeństwo, brand).
🚀 Jak zacząć wspierać To swoim działaniem?
Stwórzcie sobie krótką checklistę RODO / Security / Brand (10 min) do weryfikacji przed każdym eksperymentem
Wprowadźcie sobie warunek stopu dla eksperymentów produktowych (np. skargi, błędy, spadek konwersji)
Zapewnij opcję szybkiego wyłączenia eksperymentu w przypadku problemów
Wprowadźcie opcję stopniowych rolloutów dla eksperymentów (np. 1%→10%→50%) + monitoring w czasie rzeczywistym
Privacy by design - jeśli możecie to do testów stosujcie najpierw dane syntetyczne/maskowane,
Przygotujcie sobie gotowe i sprawdzone microcopy dla eksperymentów (np. fake doorów), które jest już sprawdzone w boju i wiecie że nie odnosiło negatywnych skutków.
🛠️ Moje praktyczne doświadczenia: opór na start jest naturalny
Opór w organizacji przy pierwszych eksperymentach jest normalny -gdy pierwszy raz robiliśmy fake door w SentiOne, Customer Support i Sales obawiali się irytacji klientów. To naturalne - chodzi o reputację i „niespełnioną obietnicę”.
Ważne żeby na start zaopiekować się taką obawą. My wprowadziliśmy „kill switch” (możliwość szybkiego wyłączenia eksperymentu), żeby móc natychmiast wyłączyć test po pierwszych negatywnych sygnałach - to mocno uspokoiło interesariuszy.
Pokazuj „Lessons Learned” po takim teście - buduje to zaufanie interesariuszy i ułatwia przepychanie kolejnych eksperymentów - widać, że działacie odpowiedzialnie, a testy realnie uczą organizację.
🎁 BONUS: Arkusz do samooceny
Poniżej znajdziesz kolejną wersję spreadsheetu do samooceny stosowania pryncypiów (uzupełniony o zasady związane z Product Discovery). Tak by ułatwić Ci zastosowanie tego co znajdziesz w tym przewodniku.
Arkusz będzie rósł wraz z kolejnymi wydaniami newslettera - na dziś obejmuje 4 obszary: Kulturę Produktową, Strategię Produktową, Zespoły Produktowe, Product Discovery, a w kolejnych wydaniach będę go rozwijać dalej.
Każde pryncypium zawiera sygnały pozytywne/negatywne oraz pytania do samooceny, które pomagają ocenić, na ile Ty i Twój zespół faktycznie stosujecie dane pryncypia. Możesz więc w praktyce zastosować ten poradnik.
Jak używać? zrób sobie solo-ocenę albo zespołowo w krótkiej sesji. Rozbieżności w ocenie traktujcie jako temat do rozmowy, nie spór o rację.
Aby skorzystać z arkusza - skupiuj go na swój Google Drive lub pobierz kopię.
➡️ W kolejnej części…
W ostatniej już części skupimy się pryncypiach związanych z Product Delivery. Zasubskrybuj newsletter, żeby nie przegapić.
