97% organizacji napotyka poważne przeszkody we wdrażaniu Modelu Produktowego. Większość zatrzymuje się na projekcie pilotażowym. Te, które próbują skalować, mają ten sam wniosek: pryncypia produktowe rozbijają się o strukturę organizacyjną, która nie pozwala im zadziałać w skali.
Co z tym zrobić?
Podzielę się pewną historią, która zainspirowała mnie do napisania tego artykułu. Historię opowiedział mi prezes pewnej globalnej, rosnącej firmy:
Gdy nasza firma miała kilkanaście osób, byliśmy pragmatykami. Decyzje zapadały szybko, a ludzie naturalnie dbali o jakość i spójność tego, co budowaliśmy. Praca szła dość gładko.
Potem firma urosła do ponad stu osób i wraz z jej wzrostem urosły problemy... i to wykładniczo.
Miałem wrażenie, że ci sami dobrzy ludzie, którzy wcześniej podejmowali trafne decyzje, nagle zaczęli zachowywać się jak "dzieci we mgle". Powstał swojego rodzaju paraliż decyzyjny i jakby "olewanie" obowiązków. Jakość i spójność produktu zaczęła spadać. Zamiast skupić się na dostarczaniu wartości, większość czasu gasiliśmy pożary, koordynowaliśmy pracę między zespołami i 'motywowaliśmy', a właściwie popychaliśmy ludzi do zadbania o produkt.
Mądre, zdroworozsądkowe, pragmatyczne działanie, które świetnie działało, gdy byliśmy mali, przestało działać w większej skali.
Jestem tym zmęczony. Głównie strofowaniem mojego zespołu z powodu częstego niedopilnowania naprawdę błahych rzeczy. Zacząłem nawet tworzyć równoległą organizację, gdzie mam znowu mały zespół, dedykowanych ludzi, którzy nie muszą 'współpracować' z innymi.
W czym jest problem? Dlaczego w większej skali to nie działa?
Odpowiadam zawsze tak samo, bo sytuacja jest moim chlebem powszednim:
Problem w opisanej historii nie polegał na tym, że ludzie się zmienili. Problem polegał na tym, że system, w którym pracowali, nie skalował się razem z nimi.
Jeśli chcesz zbudować efektywną organizację Produktową w skali, to nie masz innej opcji. Musisz:
poznać teoretyczne podstawy dynamiki organizacyjnej w skali (tj. teoria kolejkowania, myślenie systemowe, myślenie LEAN etc.)
stworzyć system organizacyjny dla wielozespołowej pracy - fundament działania firmy i ludzkich zachowań (kultury firmy),
rozwijać praktyki: produktowe, techniczne, HR-owe, managerskie etc. czyli wzmacniać kulturę pracy produktowej w skali.
Dla mnie jest to fantastyczna szansa na połączenie pryncypiów LeSS i Modelu Produktowego. Połączenie, które daje realne wyniki biznesowe i o wiele lepszą kulturę pracy. Dla potwierdzenia tego, poniżej opisuję fragment case-study transformacji firmy G2A, z którą miałem przyjemność dokonać takiej transformacji.
Ale zanim wyjaśnię co i jak, muszę rozprawić się z jednym nieporozumieniem. Ani LeSS, ani Model Produktowy to nie są frameworki. Oczywiście, początkowo LeSS łatwiej było nazywać "frameworkiem", ale wierzcie mi lub nie, nawet twórców LeSSa nie interesuje framework LeSS.
LeSS to system decyzyjny stworzony w opraciu o zbiór pryncypiów projektowania organizacyjnego.
Model Produktowy (Product Operating Model) to zbiór pryncypiów produktowego działania, czyli produktowych praktyk i sposobu myślenia.
To rozróżnienie jest kluczowe, bo oznacza, że nie konkurują ze sobą. Adresują różne warstwy tego samego problemu i ładnie ze sobą współgrają.
Żeby to zobaczyć wyraźnie, muszę najpierw pokazać Ci, co się psuje, gdy próbujesz skalować Model Produktowy bez fundamentu organizacyjnego i co się psuje, gdy masz świetną strukturę organizacyjną, ale brakuje ci praktyk produktowych.
Model Produktowy w wersji SVPG to prawdopodobnie najlepsza dostępna synteza tego, jak powinny działać zespoły produktowe. Pryncypia są mocne i sprawdzone w najlepszych firmach technologicznych świata:
Outcomes over Output - zespoły istnieją po to, żeby rozwiązywać problemy klientów i biznesu, nie po to, żeby dostarczać ficzery. Sukces mierzymy wynikami, nie ilością zdeployowanego kodu.
Empowered Teams - zespoły dostają problemy do rozwiązania i mają autonomię w znalezieniu najlepszego rozwiązania. Nie są „order-taker'ami" wykonującymi polecenia stakeholderów, i są rozliczane z rezultatów, nie z harmonogramu.
Product Discovery - zanim cokolwiek zbudujemy, szybko walidujemy, czy rozwiązanie jest wartościowe, użyteczne, wykonalne i biznesowo sensowne. Minimalizujemy waste przez testowanie hipotez, zamiast budować rzeczy, które mogą nie osiągnąć zamierzonego efektu.
Product Strategy - liderzy produktowi, razem z liderami technologii i designu, identyfikują najważniejsze problemy do rozwiązania w oparciu o insighty z danych, od klientów i z rynku, zamiast rozdzielać ficzery po zespołach według widzi-mi-się stakeholderów.
Small, Frequent Releases - produkty budowane są w krótkich cyklach (co dwa tygodnie lub częściej), co pozwala szybko reagować na potrzeby klientów, wykrywać problemy zanim zrobią to użytkownicy i dowodzić, że nowe możliwości faktycznie dostarczają wartość.
To są pryncypia, z którymi trudno się nie zgodzić. Więc gdzie jest problem?
Gdy firma rośnie z 2-3 zespołów do 10, 20 czy 50, dzieje się coś przewidywalnego i bolesnego. Liczba zależności między zespołami rośnie wykładniczo. Organizacje próbują tym zarządzić dodając warstwy koordynacji: sync meetingi, PI Planningi, PMO, koordynatorów, proxy-PO, Nexusy, rady decyzyjne etc. Każda z tych warstw i ról spowalnia przepływ wartości.
Efekt? Yuval Yeret, trener Scrum.org, opisuje to trafnie: zaledwie ok. 10% zespołów faktycznie dostarcza realną wartość. Pozostałe 90% czeka, w 'międzyczasie' pracuje nad małowartościowymi tematami, lub zarządza zależnościami i koordynacją. Seniorzy siedzą na spotkaniach alignmentowych zamiast budować produkt. Wszyscy ciężko pracują, ale efekt jest słaby. Narastająca presja zmusza wszystkich do obniżania jakości i spójności rozwiązań.
Sam Cagan przyznaje, że jest to realne ograniczenie. W artykule Team Autonomy and AI pisze wprost, że w większości obecnych topologii zespołów jednym z głównych czynników ograniczających autonomię jest to, że rozwiązanie nawet prostych problemów wymaga koordynacji wielu zespołów produktowych, bo każdy odpowiada tylko za niewielki fragment całego systemu.
Model Produktowy zakłada, że tzw. "empowered teams" powinny mieć autonomię w działaniu. Ale nie mówi, jak zaprojektować organizację, żeby ta autonomia była w ogóle możliwa, gdy masz 15 zespołów pracujących nad jednym produktem. Ponadto sama autonomia doprowadza do lokalnej optymalizacji (jak w skeczu Monty Pythona).
Ktoś powie: "Ale po co mieć 15 zespołów tworzących jeden Produkt? Wystarczy podzielić produkt w podprodukty, nie?". A no, nie. Bo to prowadzi do kolejnego problemu.
Model Produktowy SVPG opisuje domyślny skład zespołu produktowego, w którym każdy zespół ma swojego Product Managera odpowiedzialnego za wartość i rentowność tego, co buduje, oraz Product Designera odpowiedzialnego za doświadczenie klienta. Przy 1-3 zespołach to działa pięknie, szczególnie, że wtedy często UX jest współdzielony między zespołami. Przy 15 zespołach masz 15 PM-ów, z których każdy "owneruje" swój kawałek produktu. Utkniesz na wiecznych spotkaniach 'alignmentowych', bądź każdy zespół odizoluje się skupiając się "na swoim". Pojawią się problemy spójności całej ścieżki użytkownika i trudności w realizacji wielu tematów całościowo wpływających na wartość produktu.
Brzmi znajomo? To dokładnie ten sam problem, który opisywałem w poprzednim artykule o TOO (Team-Output Owners), tylko w ładniejszym opakowaniu. Zamiast "PO zarządzający backlogiem tasków" masz "PM odpowiedzialny za swój (pod)produkt". Ale dynamika jest ta sama:
Każdy optymalizuje swój kawałek, nikt nie patrzy na całość.
Kto decyduje, że problem A jest ważniejszy od problemu B, gdy oba leżą w scope'ach różnych PM-ów? Kto priorytetyzuje na poziomie całego produktu? Kto rezygnuje ze "swojego" problemu, bo problem kolegi jest istotniejszy i bardziej wartościowy dla biznesu?
To może będzie to robił Head of Produkt (czy Group PM / Chief Product Officer)? Po pierwsze, to czy na pewno chcesz obciążać swojego Head'a Produktu koordynacją cross-zespołową? Po drugie, niewiele to da, bo problemem jest izolacja zespołów - ich niska zdolność do pomagania sobie. Bo niby jak to mają robić? Porzucić swoje zadania, aby zrealizować zadania innego zespołu (PM'a)? Nie sądzę. Znowu utkniesz na spotkaniach "alignmentowych"... tym razem z Headem Productu.
To jest zarządzanie złożonością, nie jej eliminowanie. Struktura organizacyjna generuje problem, a potem próbujemy go rozwiązać dodając kolejne role tworząc jeszcze większy problem. Tak się nie da skalować. Nic dziwnego, że niektorzy wolą stworzyć "równoległą organizację", aby nie musieć się męczyć z aktualną strukturą i zależnościami.
Nawet przy najlepszych pryncypiach i najzdolniejszych PM-ach, jeśli masz zespoły, które mają "swój serwis/system/komponent" na własność, to nie mogą być one autonomiczne. Każda zmiana będzie wymagać koordynacji z innymi zespołami. Deployment jednego zespołu będzie blokować deployment drugiego. Poznasz czym są wielkie, blokujące merge conflikty i faza "stabilizacji". Rzadkie releasy staną się standardem. Błędy zaczną się pojawiać lawinowo. Twój dział technologii przestanie zwracać uwagę na usterki, bo będzie musiał coś odpuścić, aby pchać piętrzące się zmiany do przodu.
Model Produktowy zakłada, że zespoły powinny ownerować wartość end-to-end. Ale end-to-end ownership wymaga technik open-source, w którym kod jest wspólny i każdy może go modyfikować. "Własnościowe" systemy tworzą tarcia między zespołami, wymuszają zmiany priorytetów, albo przestoje. Zwiększają obciążenie związane z zarządzaniem zależnościami. Zmiana na "empowered product teams" bez zmiany właścicielstwa architektury i struktur zespołów to przepisanie etykiet na tych samych silosach.
Model Produktowy to widzi, ale nie daje narzędzi do zmiany. SVPG opisuje różne modele organizacyjne (GM Model, Functional Model, Hybrid) i daje ogólne heurystyki wyboru np. "GM model" pasuje do portfolio luźno powiązanych produktów, "Functional model" do ściśle zintegrowanych doświadczeń, ale nie opisuje konkretnego przejścia ani nie adresuje eliminacji zależności na poziomie strukturalnym. LeSS adresuje to wprost: szeroka definicja produktu, multi-skilled & multi-learning teams pracujące cross-komponentowo, i zmiana właścicielstwa architektury jako konsekwencja zmiany struktury zespołów, oraz zasad pracy z kodem.
Badania branżowe pokazują skalę problemu. Według raportu Planview z 2024, problemem nie jest zrozumienie pryncypiów Modelu Produktowego. 65% organizacji nie rozumie, jak ich zespoły dostarczają wartość klientowi. Połowa nadal mierzy sukces kosztami i terminami zamiast wartością biznesową. Zaledwie 15% potrafi włączyć feedback klienta w ciągu tygodni. Tylko 12% dotarło do etapu pełnego wdrożenia. Zdecydowana większość zatrzymuje się po fazie pilotażowej, nie przechodząc dalej.
Organizacje wiedzą co chce osiągnąć Model Produktowy - nie wiedzą, jak zmienić strukturę i przepływ pracy, żeby działało to w skali.
Typowy scenariusz wygląda tak: firma czyta Transformed, robi pilota z 1-2 zespołami, pilot wychodzi świetnie (bo jest mały scope, wybrany dedykowany team, jest dużo uwagi i wsparcia leadershipu). Potem próbuje skalować na 20 zespołów... i wszystko się sypie. Zależności, koordynacja, model finansowania, opór kulturowy, brak strukturalnej zmiany, niska współpraca, izolacja, niewłaściwe praktyki. Presja, terminy, niska jakość i spójność.
Dlaczego? Bo pilot nie wymagał zmiany struktury organizacyjnej. Mały zespół może działać jak "empowered product team" nawet w dysfunkcyjnej organizacji, bo wystarczy, że ma silnego sponsora. Ale skalowanie wymaga zmiany systemu, nie dodawania wyjątków.
AlixPartners diagnozuje: gdy organizacja rośnie, pojawiają się dodatkowi stakeholderzy, zależności i złożoności techniczne, a przejście z lokalnej na globalną optymalizację wymaga nowych umiejętności w orkiestracji i zarządzaniu trade-offami. Procesy finansowe zbudowane pod kapitalizację projektów i roczne cykle kolidują z ciągłym finansowaniem produktu. Model budżetowania, HR, struktury raportowania... to wszystko wymaga przebudowy. Model Produktowy mówi "powinno być inaczej", ale nie mówi jak zmienić te struktury.
To cytat z SVPG i jest absolutnie trafny.
Problem w tym, że "better management" w skali wymaga konkretnych decyzji organizacyjnych: jak powinna wyglądać hierarchia zarządcza? Kto powinien być managerem zespołów - technical lead z doświadczeniem, czy "people admin" bez wiedzy technicznej? Jak określić granice odpowiedzialności zespołów? Jak zredukować zależności (a nie nimi zarządzać)?
Model Produktowy zostawia te pytania otwarte. Pokazuje case studies m.in. z Google, ale każda z opisywanych firm ma zupełnie inną strukturę organizacyjną. SVPG celnie opisuje GM Model vs. Functional Model vs. Hybrid i daje ogólne heurystyki wyboru, ale nie opisuje konkretnego przejścia ani nie adresuje strukturalnej eliminacji zależności.
To jest dokładnie miejsce, gdzie wchodzi LeSS.
LeSS to nie kolejny "framework skalujący" w stylu SAFe (Cagan wyraźnie dystansuje się od SAFe, zresztą słusznie). LeSS to system decyzyjny do eliminowania złożoności organizacyjnej (a nie zarządzania nią) oparty na zbiorze pryncypiów de-skalowania.
Kluczowe elementy, które adresują opisane powyżej problemy:
Szeroka definicja produktu - zamiast 15 małych "produktów" (czytaj: komponentów) z 15 PM-ami, definiujesz jeden szeroki produkt z jednym Product Ownerem. To eliminuje lokalną optymalizację na poziomie strukturalnym, nie na poziomie "lepszej komunikacji między PM-ami".
Multi-skilled & multi-learning teams pracujące cross-komponentowo - zespoły, które potrafią dostarczyć wartość end-to-end, bez zależności od innych zespołów. To eliminuje "coordination tax" na poziomie architektury i kompetencji, nie na poziomie "lepszych sync meetingów".
Jeden Product Backlog - jedna lista priorytetów dla całego, szeroko określonego produktu. PO (strateg) priorytetyzuje na poziomie globalnym, nie lokalnym. Nie potrzeba dodatkowych warstw koordynacji, nie trzeba zarządzania portfolio, bo jest jedna, wspólna, przejrzysta kolejność.
Uproszczona struktura zarządzania - eliminacja koordynatorów, pośredników i warstw raportowania. Wartość przepływa bezpośrednio od decyzji strategicznego PO do zespołów. Koordynacja w LeSS to naturalna, ścisła współpraca między zespołami, które mają ten sam cel.
"More with LeSS" - pryncypium de-skalowania. Zamiast dodawać role i procesy, żeby zarządzać złożonością, eliminujesz źródło złożoności. Mniej ról, mniej procesów, mniej przekazywania - więcej rzeczywistej pracy nad produktem.
Ponadto Teoria Kolejkowania, Myślenie Systemowe i Myślenie LEAN - najpotężniejsze dziedziny wiedzy menegerskiej do świadomej, mądrej optymalizacji organizacji. Narzędzia do myślenia organizacyjnego i budowania spójnej ze strategią, niesamowicie sprawnej firmy.
LeSS daje fundamentalną odpowiedź na pytanie: "
Jak zaprojektować organizację, w której Caganowskie "empowered teams" mogą naprawdę funkcjonować w skali?
I tu muszę być uczciwy. LeSS daje świetny fundament organizacyjny - strukturę, która umożliwia autonomię, eliminuje zależności i upraszcza zarządzanie. Ale LeSS nie opisuje praktyk produktowych.
LeSS nie mówi ci:
Jak robić Product Discovery - jak walidować hipotezy, jak testować rozwiązania zanim je zbudujesz, jak używać np. Opportunity Solution Tree (Teresa Torres), czy GIST (Itamar Gilad) do strukturyzowania przestrzeni problemów i rozwiązań.
Jak budować strategię produktową - jak identyfikować najważniejsze problemy do rozwiązania, jak budować drzewo metryk, jak łączyć strategię biznesową z codzienną pracą zespołów.
Jak przejść z output-driven na outcome-driven - jak zmienić sposób myślenia z "dostarczamy ficzery" na "osiągamy wyniki biznesowe". Jak mierzyć sukces metrykami, nie story pointami.
Jak budować kompetencje PM, UX, Data w zespołach - Model Produktowy szczegółowo opisuje kompetencje, których zespoły potrzebują. LeSS mówi "zespoły powinny być multi-learning" - ale nie wchodzi w detale, jakie konkretnie kompetencje produktowe są potrzebne.
LeSS daje grunt, strukturę organizacyjną umożliwiającą prawdziwą współpracę i adaptacyjność.
Ale grunt sam nie wystarczy. Potrzebujesz też 'nasionek', czyli m.in. produktowych praktyk, które na tym gruncie wykiełkują.
W G2A doświadczyliśmy tego osobiście. LeSS dał nam fundament: szeroki produkt ("marketplace for digital goods"), jednego Product Ownera, 11 multi-uczących się zespołów, jeden Product Backlog, uproszczoną strukturę zarządzania. To samo skróciło nasz lead time z 214 do 40 dni i dało 5-krotnie szybszą adaptacyjność organizacyjną.
Ale to nie wystarczyło, żeby przestać być output-driven. Potrzebowaliśmy praktyk Modelu Produktowego:
Opportunity Solution Tree (Teresa Torres) zastąpiło roadmapę ficzerów. Product Backlog nie zawiera ficzerów tylko problemy i szanse do zaadresowania. PO priorytetyzuje problemy, zespoły iterują po rozwiązaniach.
Product Discovery stało się codzienną praktyką zespołów. Zamiast budować co im kazano, zespoły same odkrywają, co zadziała, testują hipotezy, walidują z danymi, pivotują gdy coś nie działa.
Drzewo metryk i tzw. Product Outcomes połączyły strategię biznesową z codzienną pracą. Zespoły wiedzą, jaką metrykę próbują poprawić i dlaczego to jest najważniejsze teraz.
Outcomes over output zmieniło rozmowę. Sprint Review nie brzmi "zdeployowaliśmy 3 ficzery", tylko "testowaliśmy dwa podejścia do problemu X, podejście A podniosło konwersję o 2%".
Bez LeSS - mielibyśmy świetne praktyki Discovery i piękne OST, ale 15 PM-ów optymalizujących lokalnie, coordination tax zjadający 60% capacity, i architekturę blokującą autonomię zespołów.
Bez Modelu Produktowego - mielibyśmy świetną strukturę organizacyjną, szybki flow i brak zależności, ale zespoły dalej dowoziłyby ficzery bez sprawdzania, czy cokolwiek zmieniają. Szybko, ale niekoniecznie we właściwym kierunku.
Bo te dwa światy rzadko ze sobą rozmawiają.
Społeczność LeSS skupia się na projektowaniu organizacyjnym, systemowym myśleniu, eliminacji złożoności.
Język to Larman, Vodde: systems thinking, Conway's Law, de-scaling, queuing theory, XP, delivery, tech etc.
Społeczność SVPG skupia się na praktykach produktowych, discovery, strategii.
Język to Cagan, Torres: empowered teams, outcomes, product vision, strategy, discovery, biz, product etc.
Obie społeczności mają rację. Obie adresują realne problemy. Ale rzadko ktoś łączy oba zestawy pryncypiów w spójną całość.
No i jeszcze nie pomaga obustronny hejcik i potrzeba przynależności (binary bias), bo "nasze jest lepsze niż wasze" ;-)
Był nawet ciekawy moment w 2019 roku, gdy Cagan napisał artykuł Product vs. Feature Teams, a Larman i Vodde odpowiedzieli postem On Product Teams and Feature Teams, wskazując na słabości w rozumowaniu Cagana (fałszywa dychotomia), ale jednocześnie przyznając, że artykuł Cagana jest mocny. W gruncie rzeczy obie strony mówią o tym samym: zespoły powinny być empowered, cross-functional, i odpowiedzialne za outcomes. Różnią się w tym, jak to osiągnąć strukturalnie - i tu uważam, że LeSS daje konkretniejsze odpowiedzi.
Z LeSS weź fundament organizacyjny i techniczny: Szeroką, biznesową definicję produktu. Jednego Product Ownera dla całego produktu. Feature teams pracujące cross-komponentowo - z kompetencjami PM, UX Research i Data Analysis wbudowanymi w zespoły (multi-learning teams). Jeden Product Backlog z globalną priorytetyzacją. Uproszczoną strukturę bez zbędnych warstw koordynacji. Pryncypium de-skalowania, czyli eliminuj źródła złożoności zamiast nimi zarządzać. Ciągłe dostarczanie (CI/CD) i instrumentację produktu jako standard, nie aspirację.
Z Modelu Produktowego weź podejście do budowania produktu: Strategię produktową opartą na insightach z danych, od klientów i z rynku, a nie na roadmapie ficzerów. Kulturę produktową: zaufanie zamiast kontroli, uczenie się zamiast unikania błędów. Empowered teams rozliczane z outcome'u, nie z outputu. Product Discovery jako sposób walidacji hipotez przed budowaniem.
Razem dostajesz: Organizację, w której współpracujące Empowered Teams nie są aspiracją, ale konsekwencją struktury. Realizację najbardziej wartościowej pracy zgodnie z globalnymi priorytetami. Strategiczne myślenie produktowe, które ma wreszcie grunt do wzrostu. Szybki flow, właściwy kierunek - a co najważniejsze - wspólny dla wszytkich zespołów. Adaptacyjność organizacyjną i mądre decyzje produktowe.
Zbudujesz machinę do sprawnej realizacji strategii i boostowania wyników biznesowych.
Model Produktowy bez fundamentu organizacyjnego to piękne pryncypia na slajdach i frustracja w korytarzach. LeSS bez praktyk produktowych to sprawna machina, która szybko produkuje… ale co właściwie? Dopiero połączenie obu daje to, czego naprawdę szukamy: organizację, która szybko odkrywa i dostarcza rzeczy, które naprawdę robią różnicę dla naszych klientów i dla naszego biznesu.
--
Artykuł oparty na doświadczeniach z transformacji w G2A oraz na analizie publikacji SVPG, społeczności LeSS i praktyków skalowania Modelu Produktowego.
Krzysztof Niewiński, Org Design Coach.