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 👈
PART 5: Product Delivery - pryncypia pracy nad budową rozwiązań
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
[Pozostało jeszcze 53% artykułu]