W produktach nie wygrywa ten, kto ma najlepszy framework, tylko ten, kto ma właściwy mindset i pryncypia. To jest coś w co mocno wierzę.
Dlatego startuję nową serię w newsletterze w której biorę na warsztat 20 zasad z „Transformed” Marty’ego Cagana i pokazuję, jak one realnie działają. Z przykładami, checklistami i moim praktycznym kontekstem.
PART 1: Czym jest Product Operating Model + cztery pryncypia Kultury Produktowej 👈
PART 2: Strategia Produktowa - pryncypia podejmowania strategicznych decyzji
PART 3: Zespoły Produktowe - zasady budowania zespołów produktowych
PART 4: Product Discovery - pryncypia pracy nad odkrywaniem
PART 5: Product Delivery - pryncypia pracy nad budową rozwiązań
W pierwszej cześci zaczniemy od fundamentów - czym jest Product Operating Model, dlaczego pryncypia są ważniejsze niż frameworki, oraz przyjrzymy się pierwszemu zestawowi zasad: kulturze produktowej.
Od kilku miesięcy nosiłem się z myślą, żeby podzielić się z Wami głebiej czymś, w co po tysiącach przepracowanych godzin przy produktach cyfrowych bardzo mocno wierzę:
PRYNCYPIA i MINDSET produktowy są najważniejsze.
Żadne narzędzie, framework, proces czy szablony tego nie zastąpią. Nawet AI nie pomoże, jeśli nie masz fundamentalnych zasad w głowie. W tzw. międzyczasie wydarzyły się dwie rzeczy:
Marty Cagan wydał książkę „Transformed” w której pokazuje swój autorski Product Operating Model - model rozwoju produktów, którego sercem jest 20 produktowych pryncypiów
Nagrałem podcast z Martym, w którym bezpośrednio porozmawialiśmy o pryncypiach, co działa i jak to się ma do polskiego rynku.
Miałem Déjà vu - przeciaż ja w podobny sposób pracuję już od lat! I to jest to podejście, które zawsze starałem się budować w zespołach oraz przekazać PMom… tylko nie potrafiłem tego tak ładnie nazwać ;).
Dlatego przejdziemy wspólnie przez 20 pryncypiów Product Modelu z „Transformed”. Będzie praktycznie, na bazie mojego doświadczenia. Do każdego pryncypium przygotowałem:
📚 Krótki opis na start
✅ Tabelkę zachowań, która pomoże Ci zobaczyć czy w Twojej firmie / zespole obecne jest to pryncypium
💬 Pytania do self-assesmentu - zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasdą
🚀 Jak zacząć wspierać to pryncypium swoimi konkretnymi działaniami?
🛠️ Moje praktyczne doświadczenia ze stosowania tej zasady
Na pierwszy ogień - pryncypia Kulturu Produktowej. Ale wcześniej jeszcze zobaczmy czym w ogóle jest Product Operating Model?
1. Czym jest Product Operating Model?
Product Operating Model (często skracany do Product Model) to nic innego jak system operacyjny dla firmy produktowej - zbiór zasad, sposobów pracy i ról, które pozwalają najlepszym organizacjom na świecie regularnie dowozić doskonałe produkty, a nie tylko kolejne funkcje z backlogu.
Model został opisany przez Marty Cagana w jego książce „Transformed”. W jego sercu leży przekonanie, że sukces mierzy się osiąganiem outcome'ów, a nie tylko produkowaniem outputu.
Marty wyróżnia trzy kluczowe elementy Product Operating Model:
Wymiary (Dimensions): To najwyższy poziom, który definiuje, jak firma funkcjonuje w trzech obszarach:
Jak decydujesz, które problemy rozwiązać? (Product Strategy)
Jak rozwiązujesz te problemy? (Product Discovery)
Jak budujesz, testujesz i wdrażasz te rozwiązania? (Product Delivery)
Koncepcje (Concepts): Pięć fundamentalnych filarów, które tworzą fundament Product Modelu wraz z 20 pryncypiami.
Kultura Produktowa (Product Culture)
Strategia Produktowa (Product Strategy)
Zespoły Produktowe (Product Teams)
Product Discovery
Product Delivery
Kompetencje (Competencies): Kluczowe role i umiejętności niezbędne do skutecznego działania w tym modelu:
Product Managers
Product Designers
Tech Leads (Liderzy Techniczni)
Product Leaders (Liderzy Produktu, czyli menedżerowie PM-ów, designerów i inżynierów)
My skupimy się na sercu tego modelu - 20 pryncypiach, które leżą u podstaw tych wymiarów, koncepcji i kompetencji.
Zaczniemy od pryncypiów związanych z Kulutrą Produktową.
2. Kultura Produktowa (Product Culture)
Kultura produktowa to fundament. To ona definiuje, jak organizacja wykorzystuje swój talent do tworzenia produktów. Marty podkreśla, że nie chodzi tu o słynne “plakaty z wartościami” na ścianach, ale o codzienne decyzje, zachowania i priorytety w firmie.
To właśnie kultura decyduje, czy zespół ma przestrzeń na podejmowanie ryzyka, eksperymentowanie, uczenie się z błędów i tworzenie rozwiązań, które realnie zmieniają życie użytkowników. Silna kultura produktowa nie powstaje z deklaracji - rodzi się z tego, w jaki sposób liderzy nadają kierunek, jakie decyzje nagradzają i jakie zachowania tolerują.
W modelu opisanym w Transformed kultura produktowa jest warunkiem, by w ogóle mogły działać pozostałe elementy modelu operacyjnego produktu. Bez niej nawet najlepsze procesy, narzędzia i talenty zostaną zneutralizowane przez złe nawyki organizacyjne - micromanagement, brak zaufania, fiksację na terminach czy unikanie porażki.
Wiem to z autopsji. Próbowałem kiedyś wdrożyć zaawansowane techniki Discovery w firmie, gdzie wciąż panował "strach przed porażką" i rozliczanie z feature'ów. Efekt? Frustracja i powrót do starych nawyków. Dlatego właśnie kultura jest tak kluczowa!
Poniżej rozłożymy na czynniki pierwsze 4 pryncypia kultury produktowej ⤵️
1️⃣ Zasady ponad Procesy („Principles over Process”)
2️⃣ Zaufanie ponad Kontrolę (Trust over Control)
3️⃣ Innowacja ponad Przewidywalność (Innovation over Predictability)
4️⃣ Uczenie się ponad Porażkę (Learning over Failure)
1️⃣ Zasady ponad Procesy („Principles over Process”)
Procesy to narzędzia, pryncypia to kompas. Najlepsze firmy i zespoły produktowe są elastyczne, bo dobierają procesy do problemów, a nie odwrotnie.
Wiele firm gubi się w sztywnych procesach i ceremoniach. "Musimy robić daily stand-up o 9:00, bo taki u nas jest proces!", “Wszystkie zespoły rozliczamy z celów sprintu”,
Ważniejsze jest podążanie za pryncypiami. Np. prawdziwa produktowa zwinność (agility) polega na zrozumieniu zasad leżących u podstaw (np. ciągłego uczenia się i dostarczania wartości), a nie ślepym podążaniu za procesami.
Kiedy działamy zgodnie z pryncypiami, mamy odwagę rezygnować z elementów procesu, które nic nie wnoszą, i wdrażać te, które realnie pomagają. Nie ma jednego „świętego” sposobu pracy - jest za to zestaw wartości i zasad, które nas prowadzą.
✅ Po czym poznasz realizację tego pryncypium
Jak poznasz, że pryncypium NIE jest realizowane? | Jak poznasz, że pryncypium JEST obecne w firmie? |
|---|---|
❌ Sztywno trzymacie się ustalonego procesu „bo tak zawsze było”, - np. robicie miesięczne release’y, mimo że możecie wypuszczać nowe funkcje co tydzień. | ✅ Nie mieliście problemu, by dostosować częstotliwość i sposób wdrożeń do aktualnych potrzeb w konkretnym produkcie. |
❌ Priorytety na roadmapie ustawiane są pod sztywny harmonogram lub „commitmenty” z początku roku, nawet gdy pojawią się nowe dane lub ważniejsze problemy użytkowników. | ✅ Roadmapa jest żywym dokumentem - jeśli pojawia się insight z discovery czy zmiana na rynku, macie odwagę przesunąć lub wyrzucić elementy, które przestały mieć sens. |
❌ Wasze KPI to głównie wskaźniki procesu (velocity, liczba zamkniętych zadań, liczba feature’ów), a nie efekty biznesowe lub wpływ na użytkowników. | ✅ Mierzycie efekty pracy realnym wpływem na zachowania i wartość dla użytkownika (np. retencja, konwersja, NPS), a nie tylko tempem dostarczania. |
❌ Za wszelką cenę trzymacie się wybranej metodyki / frameworka (Scrum, SAFe, kanban) nawet tam, gdzie ewidentnie nie działa lub blokuje eksperymenty. | ✅ Nie macie problemy z łączeniem i modyfikowanie techniki - jeśli np. początek discovery lepiej zrobić warsztatowo zamiast w formie research planu z procesu, to tak robicie. |
❌ Decyzje produktowe skupiają się na „odhaczeniu” wszystkich kroków w procesie (np. obowiązkowy pitch deck + biznes case), nawet jeśli zespół ma już jasne dane i może działać szybciej. | ✅ Wybieracie tylko te elementy procesu, które pomagają w danym kontekście - jeśli dane są jasne, pomijacie zbędne formalności, by szybciej dostarczyć wartość. |
❌ Gdy ktoś pyta „dlaczego robimy to w ten sposób?”, odpowiedź brzmi: „bo tak mamy w procesie”. | ✅ Zachęcacie do kwestionowania sensu działań - jeśli coś nie wnosi wartości, zmieniacie lub rezygnujecie z tego. |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Czy wiemy, jakie pryncypia kierują naszą pracą i czy potrafimy je wytłumaczyć nowym członkom zespołu?
Jak często kwestionujemy sens ceremonii, spotkań i artefaktów, które stosujemy?
Czy potrafimy zrezygnować z elementu procesu, jeśli nie wnosi wartości w danym kontekście?
Czy dobieramy proces do problemu, czy raczej próbujemy problem „wcisnąć” w istniejący proces?
Jak często w raportowaniu mówimy o wpływie na użytkownika i biznes, a jak często o „odhaczonych” zadaniach?
Czy ktoś w zespole może zmienić sposób pracy bez długiej ścieżki akceptacji z góry?
Kiedy ostatnio zmodyfikowaliśmy proces w reakcji na nowy kontekst lub feedback?
🚀 Jak zacząć wspierać To swoim działaniem?
Regularnie kwestionuj sens ceremonii i artefaktów – raz na kwartał zespół wspólnie ocenia, które elementy procesu wnoszą realną wartość, a które są tylko “bo tak mamy w Scrum Guide”.
Każdy rozkminy zaczynaj (także głośno, na spotkaniu) od pytania „jaki problem chcemy rozwiązać?”, a dopiero później wybieraj technikę lub proces, który to umożliwi.
🛠️ Moje praktyczne doświadczenia:
Gdy dołączałem do SentiOne, miałem w głowie wyidealizowany obraz tego, jak powinien pracować zespół scrumowy - po licznych szkoleniach, rozmowach z agile coachami i lekturze Scrum Guide.
Na miejscu okazało się, że zespół… wcale nie działa “książkowo”. Nie wszystkie ceremonie były, nie wszystkie artefakty wyglądały “jak w książce”. Na początku byłem zmrożony – “przecież to się rozsypie!”.
A jednak - wiele z tych rzeczy działała. I to dużo lepiej niż w wielu firmach, w których Scrum był podobno wdrożony “modelowo”. Bo zespół bronił i pielęgnował konkretne zasady, a nie zestaw rytuałów.
2️⃣ Zaufanie ponad Kontrolę (Trust over Control):
To jeden z najtrudniejszych, ale i najbardziej satysfakcjonujących aspektów transformacji. Zamiast mikrozarządzania i przydzielania szczegółowych zadań, w modelu produktowym liderzy ufają zespołom, że znajdą najlepsze rozwiązania dla przypisanych im problemów.
Pamiętam, jak w jednej z moich ról Head of Product, musiałem nauczyć się odpuszczać i dawać zespołom swobodę. Na początku było ciężko, bo byłem przyzwyczajony do kontrolowania każdego detalu. Ale efekty przerosły moje oczekiwania – zespoły stały się bardziej innowacyjne i zaangażowane.
Bezos z Amazonu powiedział to najlepiej: "Leadership by context, not control".
✅ Po czym poznasz realizację tego pryncypium
Jak poznać, że pryncypium NIE jest realizowane? | Jak poznać, że pryncypium JEST realizowane? |
|---|---|
❌ Liderzy lub interesariusze narzucają zespołowi / PMowie dokładne rozwiązania („zróbcie to przyciskiem w prawym górnym rogu”), zamiast jasno opisać problem i kontekst. | ✅ Delegowanie przez określnie problemu, celi i ograniczeń, a zespół samodzielnie projektuje i testuje najlepsze rozwiązania.. |
❌ Częste czekanie na “Zielone światło” - Każdy krok prac musi być zatwierdzany przez menedżera / PMa. | ✅ Możecie sami podejmować wiele decyzje w ramach ustalonych celów bez czekania na „zielone światło” z góry. |
❌ Backlog jest listą szczegółowych zadań od przełożonych, a nie wynikiem discovery i decyzji zespołu. | ✅ Backlog tworzony jest przez zespół na podstawie problemów i insightów z badań, a nie tylko poleceń z góry. |
❌ Nieustające statusy - ciągłe tłumaczenie się ze statusu każdego ticketu. | ✅ Rozmawiamy głownie o wynikach, efektach (outcomes) i problemach, a nie śledzeniu statusu każdego drobnego kroku. |
❌ Brak zaufania do kompetencji zespołu - pojawia się przekonanie, że „oni sami tego dobrze nie zrobią”. | ✅ W firmie panuje założenie, że zatrudniliście ekspertów i to oni wiedzą najlepiej, jak podejść do rozwiązania problemu w swoim obszarze. |
❌ Informacje strategiczne są „na górze”, a my dostajemy tylko fragmenty - trudno zrozumieć kontekst decyzji. | ✅ Zespoły mają dostęp do pełnego kontekstu - rozumieją strategię, dane i ograniczenia biznesowe, co pozwala im działać samodzielnie. |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Czy liderzy dostarczają nam kontekst, problem i cele, a nie gotowe rozwiązania?
Czy backlog jest efektem naszej pracy discovery, czy listą zadań od interesariuszy?
Jak często możemy podjąć decyzję produktową bez zatwierdzenia na kilku poziomach?
Czy mamy pełny dostęp do danych i strategii, żeby samodzielnie podejmować decyzje?
Jak reagujemy, gdy wybierzemy inne rozwiązanie niż to, które lider miał w głowie?
Czy liderzy interesują się efektami (outcomes), a nie tylko statusem zadań?
Kiedy ostatnio popełniliśmy błąd i potraktowaliśmy go jako lekcję, a nie jako punkt do krytyki?
🚀 Jak zacząć wspierać To swoim działaniem?
Dawaj zespołowi problem, a nie rozwiązanie – zamiast mówić “zbudujcie moduł X”, powiedz “mamy do rozwiązania problem Y, użytkownika X” i pozwól zespołowi znaleźć najlepszy sposób.
Wprowadzaj “context sharing” zamiast “task assigning” - przy omawianiu backlogu, skup sie na tle, celach, danych i ograniczeniach, a nie na “liście zadań” do wykonania.
Akceptuj inne podejście niż Twoje - nawet jeśli wiesz, jak Ty byś to zrobił, pozwól zespołowi znaleźć własną drogę, a oceny dokonaj po efektach.
🛠️ Moje praktyczne doświadczenia:
Mieliśmy kiedyś zbudować duże, złożone rozwiązanie pozwalające na bezproblemowe przenoszenie modeli AI między środowiskami produkcyjnymi. W mojej głowie plan był jasny – wiedziałem, jakie kroki trzeba podjąć i jak to powinno wyglądać. Ale zamiast przekazać zespołowi gotową listę zadań, dałem im problem, cel i kontekst.
I tu przyszło duże zaskoczenie: zespół doszedł do rozwązania wielokrotnie tańszego, znacznie szybszego w realizacji, i finalnie… nie wymagało wcale przenoszenia modeli między środowiskami.
To była lekcja, że moje „najlepsze” rozwiązanie często jest tylko jedną z wielu opcji - i wcale niekoniecznie tę moją.
3️⃣ Innowacja ponad Przewidywalność (Innovation over Predictability):
Wiele firm stawia przewidywalność delivery na pierwszym miejscu, często kosztem innowacji.
Tradycyjne roadmapy, nastawione na dostarczenie konkretnych funkcji w konkretnych terminach, rzadko prowadzą do przełomowych rozwiązań.
Innowacja wymaga eksperymentowania i akceptacji ryzyka. Oznacza to, że nie wszystko się uda, a porażki są częścią procesu. Kluczowe jest, aby uczyć się z tych porażek i szybko iterować.
Najwolniejszym i najdroższym sposobem testowania pomysłu jest jego zbudowanie, zanim zostanie zweryfikowany
✅ Po czym poznasz realizację tego pryncypium
Jak poznać, że pryncypium NIE jest realizowane? | Jak poznać, że pryncypium JEST realizowane? |
|---|---|
❌ Trzymacie się roadmapy „na sztywno”, nawet jeśli badania lub dane pokazują, że zaplanowane funkcje nie rozwiążą problemu użytkowników. | ✅ Traktujecie roadmapę jako hipotezę - jeśli nowe insighty pokazują lepszy kierunek, zmieniamy priorytety bez poczucia „porażki w delivery”. |
❌ Sukces mierzycie głównie tym, że „dowieźliśmy na czas” to, co zaplanowaliśmy. | ✅ Możecie sami podejmować wiele decyzje w ramach ustalonych celów bez czekania na „zielone światło” z góry. |
❌ Unikacie ryzyka – wybieramy tylko bezpieczne zmiany i funkcje, które na pewno dostarczymy. | ✅ Rezerwujecie np. XX% czasu na eksperymenty, prototypy i testy ryzykownych pomysłów. |
❌ Porażki traktujecie jak coś co nie powinno się wydarzyć – w zespole rośnie strach przed testowaniem odważnych rozwiązań. | ✅ Ludzie i zespoły nie obawiaja się podejmować ryzykownych decyzji / estymat / pomysłow - część z nich się może być ryzykowa i kończy się porażką. |
❌ Zawsze realizujemy 100% celów / planów - jest na to nacisk. | ✅ Robicie ryzykowne rzeczy, więc naturalne jest że czasem się nie udają. |
❌ Każna porażka kończy sie szukaniem winnych i wyciąganiem konsekwencji. | ✅ Porażki to dla Was lekcje - analizujecie, co poszło nie tak i jak wykorzystać wnioski w kolejnych iteracjach. |
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Czy mamy w roadmapie przestrzeń na pomysły, które mogą się nie udać?
Jak często zmieniamy plan w reakcji na nowe dane?
Czy mierzymy efekty w kategoriach outcome’ów, czy tylko dostarczenia feature’ów?
Kiedy ostatnio przetestowaliśmy odważny, ryzykowny pomysł?
Jak reagujemy, gdy eksperyment się nie powiedzie – uczymy się czy zamykamy temat?
Czy innowacja jest elementem naszej codziennej pracy, czy dodatkiem „po godzinach”?
🚀 Jak możesz to zrealizować – konkretne zachowania:
Zostaw miejsce w roadmapie na eksperymenty - planuj w kwartale czas i zasoby na testowanie pomysłów, które mogą przynieść skokową wartość, zamiast wypełniać backlog w 100%.
Buduj roadmapę skupiona na outcomach, a nie terminowych outpach - zamiast “dowiezienia funkcji w Q3”, definiuj sukces jako osiągnięcie określonego wyniku (np. +15% adopcji funkcji Y).
Przestań jarać się velocity oraz utylizacją zasobów - wysoka prędkość developmentu czy pełne obłożenie zespołów nie mają znaczenia, jeśli efekty nie przekładają się na realną wartość dla klientów i biznesu.
Uznaj niepewność jako normalny element pracy – komunikuj zarządowi i interesariuszom, że w innowacji nie da się obiecać daty i zakresu z chirurgiczną precyzją, bo jest to proces odkrywania. Komunikuj, że to, co robicie, to tak naprawdę “bety”, a nie pewne rozwiązania.
Moje praktyczne doświadczenia:
W jednej z firm zaczynaliśmy kwartał z bardzo „zabetonowaną” roadmapą - każdy sprint miał już zaplanowane właśnie cele outpowe. Roadmapa miała terminy i konkretne “rozwiązania” do dowiezienia.
Wydawało się to bezpieczne, ale w praktyce zabijało CAŁĄ przestrzeń na nowe pomysły.
Kiedy udało mi się wywalczyć, żeby jeden zespół miał 20% czasu na eksperymenty, szybko okazało się, że w discovery trafiliśmy na rozwiązanie, które dostarczyło większy efekt biznesowy niż połowa zaplanowanych funkcji razem wzięta.
Co ciekawe - tego rozwiązania nie dałoby się wcisnąć w pierwotny harmonogram, bo w ogóle o nim wtedy nie wiedzieliśmy. To był dowód, że przewidywalność “co do dnia” może być wrogiem prawdziwej innowacji.
Jeżeli firma jest rozliczana wyłącznie z terminowego dowożenia roadmapy, zespoły naturalnie unikają ryzyka i wybierają tylko te rozwiązania, które są przewidywalne.
Problem w tym, że przewidywalne rzeczy rzadko są przełomowe. Warto znaleźć balans: część zespołów może pracować nad stabilnym delivery, a część – nad wysokoryzykowną, ale potencjalnie przełomową innowacją.
4️⃣ Uczenie się ponad Porażkę (Learning over Failure):
Celem eksperymentów produktowych nie jest unikanie porażki za wszelką cenę, ale maksymalizacja i przyspieszenie procesu uczenia się. Chodzi o zmianę mentalności: zamiast postrzegać nieudany test jako porażkę, traktuje się go jako cenną, szybko zdobytą wiedzę.
W organizacjach opartych na modelu produktowym, porażka nie jest karana, lecz traktowana jako okazja do nauki. To zasadnicza zmiana mentalności.
"Nasza kultura innowacji opiera się na zrozumieniu, że musimy zawodzić wcześnie i iterować, aż nam się uda" - to pozwala długoterminowo obniżać ryzyko i inwestować w te pomysły, które naprawdę mają potencjał.
✅ Po czym poznasz realizację tego pryncypium
Jak poznać, że pryncypium NIE jest realizowane? | Jak poznać, że pryncypium JEST realizowane? |
|---|---|
❌ Porażki postrzegacie jako coś, czego trzeba unikać - projekty mają „dowieźć” niezależnie od tego, czy mają sens. | ✅ Porażka w eksperymencie jest akceptowana, jeśli dostarczyła wartościowych insightów i uchroniła Was przed złym kierunkiem. |
❌ Nagradzani są tylko ci, którzy „dowozili” funkcje i wzrosty, a nie ci, którzy odkryli, że dany pomysł nie działa. | ✅ Doceniacie zarówno sukcesy, jak i odrzucenie nietrafionych pomysłów po rzetelnym teście. |
❌ Discovery trwa w nieskończoność, bo boicie się podjąć decyzję bez 100% pewności. | ✅ Discovery kończycie wtedy, gdy ryzyko jest wystarczająco zmniejszone, by podjąć decyzję i przejść do delivery. |
❌ Brak bezpieczeństwa psychologicznego – ludzie unikają ryzykownych pomysłów, by „nie zaliczyć wtopy”. | ✅ Czujecie się bezpieczni, mówiąc „to nie działa” - liderzy traktują to jako cenną wiedzę, nie jako porażkę zespołu. |
❌ Kolejne eksperymenty ciągną się miesiącami, bo chcemy mieć „100% pewności”. | ✅ Kończymy badania, gdy mamy wystarczająco danych, żeby podjąć świadomą decyzję, nawet jeśli wciąż jest ryzyko. |
🚀 Jak możesz to zrealizować – konkretne zachowania i techniki:
Hipotezy zamiast wymagań: Zamiast pracować nad listą wymagań ("zbudujcie funkcję X"), zespół formułuje hipotezy ("wierzymy, że jeśli zbudujemy funkcję X dla użytkowników Y, osiągniemy rezultat Z"). Takie podejście z góry zakłada, że pomysł może być błędny i wymaga weryfikacji.
Szybkie i tanie eksperymenty: Zamiast spędzać miesiące na budowaniu pełnej funkcji, zespoły używają tanich metod do testowania hipotez.
Bezpieczeństwo psychologiczne: Zespół musi czuć, że może swobodnie eksperymentować bez obawy o negatywne konsekwencje, jeśli hipoteza okaże się fałszywa. Liderzy muszą promować kulturę, w której unieważnienie hipotezy jest celebrowane jako wartościowa nauka, która uchroniła firmę przed zmarnowaniem zasobów.
Mierz „learning velocity”: np. ile nowych potwierdzonych lub odrzuconych hipotez zdobyliśmy w danym kwartale.
💬 Pytania do self-assesmentu:
Zadaj sobie te pytania, żeby zobaczyć czy sam żyjesz tą konkretną zasadą ⤵️
Czy nasze cele produktowe są sformułowane jako hipotezy, a nie listy wymagań?
Jak często eksperyment kończy się odrzuceniem pomysłu. Czy świętujemy to jako oszczędność zasobów?
Czy mamy ustalone kryteria, kiedy kończymy discovery i przechodzimy do delivery?
Jak szybko i tanio weryfikujemy pomysły – zanim zbudujemy pełne rozwiązanie?
Czy porażka pomysłu wpływa negatywnie na ocenę pracy zespołu lub PM-a?
Kiedy ostatnio udostępniliśmy innym zespołom wnioski z nietrafionego pomysłu?
Czy mówimy „musimy mieć pewność” częściej niż „mamy wystarczająco danych, żeby zdecydować”?
🛠️ Moje praktyczne doświadczenia:
Mówienie “porażka jest okej” brzmi dobrze na prezentacjach, ale w praktyce, jeśli firma wciąż nagradza tylko dowiezione funkcje i wzrosty, ludzie będą unikać ryzyka. TO niestety wymaga zmiany systemowej w leadershipie.
Drugą kwestią jest to, że to pryncypium nie oznacza, że mamy prowadzić nieustanne discovery, które nigdy się nie kończy. Przerabiałem to w praktyce - zespół tak bardzo chciał “mieć pewność”, że rozwiązanie jest dobre, że kolejne eksperymenty stawały się wymówką, by nie podjąć decyzji.
Testowaliśmy, walidowaliśmy, zbieraliśmy kolejne insighty… aż w pewnym momencie dotarło do mnie, że wpadliśmy w pułapkę paraliżu decyzyjnego.
Discovery ma służyć zmniejszeniu ryzyka, a nie jego całkowitemu wyeliminowaniu - bo to niemożliwe.
3. W kolejnej części…
W kolejnej części skupimy się pryncypiach związanych ze Strategią Produktową . Zasubskrybuj newsletter, żeby nie przegapić.