Zapraszam do ostatniej już część przewodnika po stosowaniu 20 pryncypiów „Product Operating Model" Marty Cagana. Będzie teoria, praktyka i moje własne doświadczenia. Tu jesteśmy 👇
PART 4: Product Model: Product Discovery
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. Jeśli chcesz poćwiczyć i powarsztatować ze mną mindset produktowy oraz wdrażanie tych pryncypiów w swoim produkcie - wpadaj na Product Management Academy!
Ostatni, ale nie mniej ważny obszar Product Operating Modelu to Product Delivery. To tutaj pomysły i rozwiązania, które zostały odkryte i zweryfikowane w fazie Discovery, stają się rzeczywistością. Product Delivery to proces budowania, testowania i wdrażania jakościowego rozwiązania - takiego, które jest niezawodne, dokładne, wydajne, skalowalne i co najważniejsze, dostarcza pożądane outcome'y.
Można pomyśleć, że "delivery" to przecież oczywista sprawa. Powstanie filozofii Agile, wynikało właśnie z poczucia, że Delivery trzeba usprawnić. I słusznie.
Nadal jednak spotykam się z zespołami, które wydają produkty raz / dwa razy na kwartał, a nawet rzadziej! 🤯 To jest przepis na katastrofę w dzisiejszym, szybko zmieniającym się świecie. Marty podkreśla, że kluczowe jest to, czy faktycznie często, niezawodnie i w małych przyrostach dostarczamy wartość klientom.
Oto cztery kluczowe pryncypia Product Delivery, na które stawiają firmy działające w Product Modelu ⤵️
1️⃣ Małe, Częste, Niezależne Wydania (Small, Frequent, Uncoupled Releases)
2️⃣ Instrumentacja (Instrumentation)
3️⃣ Monitorowanie (Monitoring)
4️⃣ Infrastruktura (Deployment Infrastructure):
🎁 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️⃣ Małe, Częste, Niezależne Wydania (Small, Frequent, Uncoupled Releases)
To podstawa efektywnego Delivery. W Product Modelu dąży się do ciągłego dostarczania małych zmian, idealnie wiele razy dziennie (Continuous Delivery/Deployment – CI/CD).
Każda zmiana jest wydzielona, bezpieczna i możliwa do szybkiego wycofania, a zespoły mogą wydawać niezależnie od siebie.
Nie chodzi o sztywne trzymanie się Scruma z 2-tygodniowymi sprintami, ale o to, by każda zmiana była gotowa do wydania, gdy tylko jest gotowa. Chodzi o ciągły przepływ: gdy coś jest gotowe - idzie na produkcję (za flagą, z obserwowalnością i planem rollbacku).
Małe batch’e redukują ryzyko, przyspieszają informację zwrotną od klientów i skracają czas do wartości.
Jeśli Wasz zespół wciąż wydaje produkt raz na kwartał, raz na miesiąc, to prawdopodobnie znaczy, że musicie nad tym popracować.
✅ Po czym poznasz realizację tego pryncypium
Jak poznasz, że pryncypium NIE jest realizowane? | Jak poznasz, że pryncypium JEST obecne w firmie? |
|---|---|
❌ „Release party” raz w miesiącu/kwartale; Tylko nocki / weekendy na wdrożenia. | ✅ Wielokrotne wdrożenia w godzinach pracy (często codzienne); bez dramatu i specjalnej otoczki. |
❌ Manualne testy regresji, brak automatyzacji. | ✅ CI/CD, automatyczne testy (unit / integration / smoke) w pipeline. |
❌ Każde wdrożenie wymaga synchronizacji wielu zespołów. | ✅ Niezależne releasy: kontrakty / API wstecznie kompatybilne pozwalające minimalizować zależności |
❌ Brak feature flag; “włączenie / wyłączenie” funkcji = konieczny hotfix. | ✅ Macie i korzystacie z feature flags, progressive rollout, plan rollbacku. |
❌ Wielkie branche w systemi kontroli wersji, „merge hell”, freeze przed releasem. | ✅ Trunk-based development, małe PR-y (Pull Request), szybkie code review. |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Jak często realnie wdrażacie na produkcję (tydzień/miesiąc/dzień/wiele razy dziennie)?
Czy możesz włączyć/wyłączyć nową funkcję bez releasu (feature flag)?
Czy Twój zespół może wydać wersje niezależnie od innych?
Czy macie automatyczne testy po każdym wdrożeniu?
Kiedy ostatnio wdrożyliście nową wersję w godzinach pracy userów bez problemów i przestoju?
Czy Wasze PR-y (Pull Request) są małe (< ~200-300 linii) i szybko przechodzą review?
🚀 Jak zacząć wspierać To swoim działaniem?
Rozbijaj epiki na małe, releasowalne zadania („co najmniej wartość” dla użytkownika), a nie duże paczki „UI teraz, logika później”.
Zacznij pracować z zespołem nad wypracowanie standaru: nowe rzeczy zawsze za ficzer flagą, rollout 1%→10%→50%→100%
Zmień perspektywę interesariuszy z „big launchy” na ciągłe dowożenie efektu; np. tygodniowe release notes z małym zmianami i wpływem na outcomy produktowe
Wspieraj inwestycje w testy automatyczne, pipeline CI/CD itp. jako „enablery” outcome’ów - walcz o to, by była na nie przestrzeń na roadmapie pracy zespołu
Ustal ze współzależnymi zespołami wsteczną kompatybilność API, kontrakty i okna wdrożeń - tak, by móc wydawać niezależnie.
Doceniaj małe, bezdramatyczne wdrożenia i dojrzałe decyzje o wycofaniu - to one budują tempo i bezpieczeństwo.
🛠️ Moje praktyczne doświadczenia: minimalizacja strat to czasem ewaluacja na produkcji
Z mojego doświadczenia to proste: jeśli zespół nie ma czasu na testy, automaty i porządki (jest ciśnięty tylko o nowe feature’y) - to nie będzie nad tym pracował. Dlatego zawsze rezerwuję część capacity na tech improvements / release enablers (np. 15–30% w zależności od sytuacji).
Tych większych nie ukrywam „pod stołem”. Wpisuję je wprost a roadmapę (np. „Test automation & CI/CD hardening”, „Feature flags rollout”), z oczekiwanym wpływem, np. szybsze i częstsze releasy,
W jednym z produktów, którym się zajmowałem, nie mieliśmy prawie żadnych testów automatycznych. Zrobiliśmy z tego oficjalną inicjatywę roadmapową. W jeden kwartał mocno nadgoniliśmy: powstał pipeline, testy na wszystkie krytyczne ścieżki. Od tego momentu także praca nad funkcjami przyspieszyła, bo każde wdrożenie miało siatkę bezpieczeństwa.
2️⃣ Instrumentacja (Instrumentation):
Jeśli jako PMowie odpowiadamy za outcome’y (a to istota Product Modelu), to nie możemy przy podejmowanie decyzji lecieć „na ślepo”.
Instrumentacja to celowo zaprojektowane zbieranie danych w produkcie - od poziomu infrastruktury i usług, przez backend, aż po zdarzenia w aplikacji (pokazujące zachowania użytkowników) i metryki biznesowe.
Wszystko to po to, aby zrozumieć, co naprawdę dzieje się w produkcie. Żebyś wiedział (a), czy nowa funkcja naprawdę działa (adopcja, konwersja), gdzie użytkownicy odpadają i czy system jest zdrowy. Bez tego „latasz na ślepo”.
Projekt powinien obejmować: plan śledzenia (tracking plan), spójne zdarzenia (eventy i atrybuty), logowanie błędów i czasów, monitoring SLO/SLA, tracing, a także dashboardy dla zespołu i firmy.
Instrumentacja nigdy nie jest „skończona”: ewoluuje wraz ze zrozumieniem zachowań użytkowników i kierunkiem strategii. W miarę jak uczysz się o produkcie, aktualizujesz eventy i dashboardy. Instrumentacja to nawyk, który rośnie razem z produktem.
✅ Po czym poznasz realizację tego pryncypium
Jak poznasz, że pryncypium NIE jest realizowane? | Jak poznasz, że pryncypium JEST obecne w firmie? |
|---|---|
❌ „Wypuściliście funkcję” i nie wiecie, czy ktoś jej używa. | ✅ Każde wydanie/ficzer ma metrykę sukcesu, eventy i dashboard; po releasie widzisz adopcję. |
❌ Dane są rozproszone i niespójne; te same rzeczy mierzycie różnymi nazwami. | ✅ Macie spójny tracking plan i taksonomię eventów. |
❌ Nie możecie łatwo sprawdzić co i jak użytkownicy robią w produkcie | ✅ Macie dostępne narzędzia analityczne, które pozwalają podpatrywać jak zachowują się użytkownicy |
❌ Nie ma właściciela dla konkretnych danych, które trzeba mierzyć | ✅ Są ownerzy poszczególnych obszarów telemetrii |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Czy macie tracking plan? (lista eventów/atrybutów, definicje metryk, właściciel) I czy zespół go zna?
Jak szybko dowiadujesz się o błędach / problemach z dostępnością / spowolnieniem systemu?
Czy macie dostępne narzędzia analityczne?
Czy dostęp do narzędzi analitycznych jest łatwy i transparentny dla wszystkich osób pracujących przy produkcie.
Czy eksperymenty/feature mają własne eventy, tak że możesz je monitorować
🚀 Jak zacząć wspierać To swoim działaniem?
Przygotuj „Tracking Plan 1.0”: top 10 - 15 eventów + atrybuty (kto/co/kiedy/gdzie), definicje metryk, owner. Udostępnij jako jedno źródło prawdy.
Zdefiniuj metryki sukcesu dla każdego feature’a (np. aktywacja + retencja) i wpisz je do PRD / karty inicjatywy.
Uzupełnij DoD o instrumentacje (np. konieczność dodania eventów analitycznych). Zadanie nie kończy się, jeśli nie ma eventów, planu dashboardu, alertów.
Ustal rytm „Instrumentation Review” w formie spotkania / review. Co 2–4 tygodnie mini analiza: które eventy są martwe/nieużywane, czego brakuje, co uprościć.
🛠️ Moje praktyczne doświadczenia: jak startowaliśmy z analityką produktową w SentiOne
Zaczęliśmy od prostoty: przygotowaliśmy prosty Excel z listą kluczowych eventów (najważniejsze akcje użytkownika + podstawowe parametry). Dla najważniejszych funkcji produktu, bez próby pokrycia wszystkiego. To wystarczyło, by ruszyć i nie ugrzęznąć w „idealnym planie”.
Jeśli chodzi o narzędzia to na start był to Google Analytics (szybki setup, niski próg wejścia, mieliśmy już w firmie), a potem migracja na Mixpanel, gdy potrzebowaliśmy lepszej pracy produktowej na lejkach, kohortach i eventach.
Super efekt dało dopisanie „wdrożenie potrzebnych eventów analitycznych” do Definition of Done. Dzięki temu zespół deweloperski sam zaczął szybko pilnować instrumentacji - nie jako „dodatku”, tylko elementu „done”.
3️⃣ Monitorowanie (Monitoring)
Instrumentacja zbiera dane, a monitorowanie sprawia, że te dane działają dla nas w czasie rzeczywistym.
Monitoring to ciągłe obserwowanie danych (zebranych dzięki instrumentacji) w celu wykrywania problemów, regresji lub trendów. Przykładowo:
Śledzenie spadków aktywności użytkowników po wdrożeniu nowej funkcji.
Alert, jeśli konwersja spada poniżej ustalonego progu.
Codzienne przeglądanie metryk produktowych.
Nasz cel jest prosty - chcemy szybko reagować na problemy i lepiej rozumieć wpływ zmian na produkt.
✅ Po czym poznasz realizację tego pryncypium
Jak poznasz, że pryncypium NIE jest realizowane? | Jak poznasz, że pryncypium JEST obecne w firmie? |
|---|---|
❌ O tym że system nie działa, ma przestoje, dowiadujecie się od klientów. | ✅ Macie alerty / monitoring, który ostrzega Was sam o problemach, błędach, opóźnieniach w działaniu systemu. |
❌ Po releasie nikt nie sprawdza metryk produktowych i systemowych | ✅ Wasze wdrożenia mają tzw. Release Health Window: właściciel, okno obserwacji (jak długo), metryki, plan rollbacku. |
❌ Jesteście zasypani alertami, jest ich dużo, przez co nie wpływają one na Wasze działania | ✅ Przemyślane progi dla alertów. Macie też zdefiniowanie konkretne akcje które mają się zadziać po konkretnych alertach |
❌ Nie wiemy, która zmiana popsuła metrykę. | ✅ Macie powiązanie zmian z eventami analitycznymi i metrykami |
❌ Macie dashboardy analityczne, ale nikt w nie nie zagląda. | ✅ Korzystanie z dashboardów analitycznych jest codzienną pracą wielu osób w produkcie |
❌ Brak regularnego przeglądu metryk produktowych. | ✅ Regularny przegląd metryk, dashboardów. |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Czy dla ostatniego wydania / ficzera masz metryki sukcesu i dashboard, zanim coś trafił na produkcję?
Jak szybko dowiadujesz się o błędach / problemach z dostępnością / spowolnieniem systemu?
Kto jest ownerem „Release Health Window” po wdrożeniu i jak długo trwa to okienko?
Czy potrafisz pokazać lejek dla kluczowego zachowania oraz kohorty/segmenty (np. nowi vs. powracający)?
Czy potrafisz w dashboardzie zobaczyć wpływ konkretnego releasu / feature’a na metryki?
Czy monitorujesz outcome’y produktowe (np. aktywacja, konwersja, retencja) obok metryk technicznych?
Czy Wasze dashboardy są używane (kto, jak często) i pomagają podjąć konkretne decyzje?
🚀 Jak zacząć wspierać To swoim działaniem?
Przygotuj pierwszy dashboard z najważniejszymi KPI produktowymi (i biznesowymi). Jeden widok: KPI, outcome’y, najważniejsze ścieżki / lejki w produkcie. Ułatwiasz decyzje bez grzebania w narzędziach.
Twórz „Feature Dashboard” dla wszystkich nowych ważnych funkcji, który będzie pokazywał najważniejsze metryki produktowe dla funkcji.
Ucz zespoły czytać dane, np. krótkie sesje „how-to analytics”: lejek, kohorty, a/b, eventy.
Ustal progi dla alertów razem z zespołem technicznym (alerty systemowe / dostępność) i produktowym (alerty produktowe / biznesowe).
Wprowadź tygodniowy „Metrics & Monitoring Review”. Np. 30 minut podczas którego sam lub z zespołem przeglądacie anomalie, podejmujecie decyzje, wyciągacie wnioski do Lessons Learned.
🛠️ Moje praktyczne doświadczenia:
W dojrzałych produktach jedną z pierwszych analitycznych rzeczy jaką ogarniam jest North Star Metric (NSM). Samo jej zdefiniowanie często kończy się rozmową o wizji i propozycji wartości produktu (bo tego potrzebujemy do zdefiniowania North Stara). Po ustaleniu NSM stawiam prosty dashboard.
Super sprawdził mi się też automatyczny mail/alert z wynikami North Stara (np. co poniedziałek rano) do grona zainteresowanych osób w produkcie: product leadership, sprzedaż, CS, marketing, Dev.
Zauważyłem, że dzięki temu metryki produktowe, stają się dużo częściej rozumiane i UŻYWANE w decyzjach an poziomie "biznesowym".
4️⃣ Infrastruktura wdrożeniowa (Deployment Infrastructure):
W Product Modelu nie wystarczy „móc wdrażać”. Potrzebujemy infrastruktury wdrożeniowej dostosowanej pod potrzeby produktowe, czyli takiej która pozwala bezpiecznie wypuszczać, wycofywać i testować zmiany na wybranych grupach użytkowników zanim trafią do wszystkich.
Kluczowe możliwości, które daje wam zaawansowana infrastruktura:
Feature flags / toggles - możecie włączać i wyłączać funkcje bez deploymentu kodu;
Canary releases - testujecie zmiany na 5% użytkowników, zanim trafią do wszystkich;
A/B testing - pokazujecie wariant A połowie użytkowników, wariant B drugiej połowie i mierzycie różnice;
Dark launches – wypuszczacie kod do produkcji, ale funkcja jest niewidoczna, możecie sprawdzić wydajność;
Quick rollback - coś poszło nie tak? Jeden przycisk i wracacie do poprzedniej wersji w sekundy, nie godziny.
Najlepsze firmy produktowe prowadzą setki równoległych eksperymentów jednocześnie, bo ich infrastruktura to umożliwia.
✅ Po czym poznasz realizację tego pryncypium
Jak poznasz, że pryncypium NIE jest realizowane? | Jak poznasz, że pryncypium JEST obecne w firmie? |
|---|---|
❌ Każdy deployment to wydarzenie - planujecie go na weekend, macie checklistę, wszyscy są w gotowości | ✅ Deployujecie kilka razy dziennie / w tygodniu, to zwykła część pracy, nikt się tym nie stresuje |
❌ Gdy coś idzie nie tak po deploymencie, naprawiacie bug następnym deploymentem za kilka dni | ✅ Macie szybki rollback - w 2 minuty cofacie się do poprzedniej wersji, gdy widzicie problem |
❌ Release = zawsze wszyscy dostają wszystko naraz. Brak możliwości stopniowego rollout’u. | ✅ Macie możliwość procentowego rolloutu / canary rollout (np. 1% → 10% → 50% → 100%), najlepiej konfigurowane z panelu. |
❌ Nie możecie testować dwóch różnych rozwiązań, bo "to by wymagało dwóch deploymentów" | ✅ Prowadzicie wiele eksperymentów równolegle - różne grupy użytkowników widzą różne warianty |
❌ Beta testing możecie robić tylko na środowisku z innymi danymi - nie wiecie jak funkcja będzie działać na prodzie | ✅ Możecie robić Dark launch - funkcja jest na prodzie, z prawdziwymi danymi, ale niewidoczna, testujecie wydajność i integracje |
❌ Brak lub trudne do realizacji A/B testy; zawsze wymagają one tygodni pracy. | ✅ Jesteście w stanie szybko A/B testować małe zmiany. |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Ile razy w tygodniu deployujecie do produkcji?
Ile czasu zajmuje wam rollback do poprzedniej wersji, gdy coś pójdzie nie tak?
Czy potraficie wypuścić nową funkcję do produkcji, ale uczynić ją niewidoczną dla użytkowników?
Czy możecie włączyć funkcję dla konkretnego użytkownika, segmentu lub procentu użytkowników bez nowego deploymentu?
Ile eksperymentów A/B prowadzicie w tym momencie równolegle?
Czy możecie wypuścić funkcję najpierw do 5% użytkowników, sprawdzić metryki, a potem zwiększyć do 100%?
🚀 Jak zacząć wspierać To swoim działaniem?
Wybierz JEDNĄ nową funkcję i wypuść ją za feature flagiem. Nie musisz od razu budować pełnej infrastruktury – zacznij małymi krokami
Zrób pierwszy canary release - poproś developera, żeby zaimplementował procentowy rollout dla funkcji z feature flagiem.
Zrób pierwszy A/B test - wybierz małą zmianę do przetestowania (treść przycisku, umiejscowienie elementu). Najpierw bezpośrednio w kodzie.
Przejrzyj i przetestuj narzędzia do A/B testów, feature flags (może Wasze istniejące narzędzia analityczne to umożliwiają?) - przedstaw je zespołowi.
Zacznij pracować DevOps/Platform team nad zbudowaniem / rozbudowaniem waszego Continuous Delivery o tematy potrzebne Wam od strony produktowej
Policz koszty braku. Zbierz 2–3 przykłady: ile godzin spalił ostatni rollback, ile MRR zagrożone przez brak Canary Release, jak zmian nie byliście w stanie przetestować, bo nie macie łatwiej opcji eksperymentów.
🛠️ Moje praktyczne doświadczenia: najtrudniej zacząć
W wielu firmach najtrudniej było w ogóle zacząć. Słyszałem klasyki: „to zajmie za dużo czasu”, „u nas się nie da”, „nie wiemy, czy to da wartość”. Wszyscy zgadzali się teoretycznie, że takie testowanie jest fajne, ale w praktyce nikt tego nie robił.
Ten opór zwykle znikał dopiero, gdy pojawiał się pierwszy, namacalny przykład. To co zawsze pomagało, to zrobienie pierwszego eksperymentu - bez czekania na idealną infrastrukturę.
W jednej firmie wszyscy mówili "u nas nie da się zrobić A/B testów, to za dużo roboty". Więc sam usiadłem wieczorem do Google Optimize, wykorzystałem Google Tag Managera i przeprowadziłem pierwszy A/B test. Całość zajęła mi kilka godziny, wielu rzeczy musiałem się sam nauczyć, ale co ważne bez zaburzania prac zespołu.
Test zadziałał: pokazał realną różnicę w zachowaniu użytkowników i pomógł podjąć konkretną decyzję produktową. Nagle z „nie da się” zrobiło się „jak możemy robić tego więcej?”. Zamiast prezentacji - lepiej przekonuje konkretny przykład wartości z takich usprawnień.
🎁 BONUS: Arkusz do samooceny
Poniżej znajdziesz ostatnią wersję spreadsheetu do samooceny stosowania pryncypiów (uzupełniony o zasady związane z Product Delivery). Tak by ułatwić Ci zastosowanie tego co znajdziesz w tym przewodniku.
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ę.
➡️ Co dalej? Kończymy projekt?
Za nami już wszystkie 20 najważniejszych zasad tworzenia produktów według Product Operating Model. To chyba najbardziej szczegółowy publicznie dostępny przewodnik po zrozumieniu i stosowaniu tych zasad - na pewno w PL, a prawdopodobnie też na świecie ;).
Aby jednak ułatwić Ci wykorzystaniu modelu do planowania zmian produktowych w Twojej organizacji - szykuję jeszcze jedną, bonusową część. Stay Tuned.
Zasubskrybuj newsletter, żeby nie przegapić!