• Product Craft
  • Posts
  • Stan product managementu w Polsce - wyniki ankiety

Stan product managementu w Polsce - wyniki ankiety

120+ product managerów wypełniło naszą ankietę. Jak wyglądają wyniki?

Aby dobrze przygotować się do podcastu z Marty Cagan’em, razem z ekipą „Dodane do backlogu” przeprowadziliśmy w grudniu ankietę, by zobaczyć jak wygląda rzeczywistość budowania produktów w Polsce 🇵🇱.

Okazało się, że ankietę wypełniło ponad 120 osób! Dziękujemy! Ankieta nie była idealna, ale nie ma chyba aktualnie lepszego przybliżenia naszej produktowej rzeczywistości. Dzisiaj w newsletterze znajdziesz dokładne wyniki tej ankiety 📈.

BTW. W środę Wojtek Smajda opublikuje szczegółową analizę danych (np. korelacji) i wnioski z ankiety w swoim newsletterze. Daj mu suba, żeby nie przegapić :).

Ankietę przeprowadziliśmy z wykorzystaniem siły naszych social mediów, kanałów dotarcia i networku. Chcieliśmy przygotować się do nagrywanego podcastu z Martym Caganem o jego spojrzeniu na nasze polskie produktowe realia.

Chcieliśmy dowiedzieć się więcej o tym:

  • jak wygląda tworzenie produktów w świecie polskich product managerów;

  • z jakimi problemami zderzają się zespoły produktowe;

  • zwalidowanie polskiej rzeczywistości z tezami opisywanymi w nowej książce Marty’ego Cagana “Transformed”, w której znajdziemy pryncypia pracy dobrych zespołów produktowych (na poziomie deklaracji).

Ankieta nie była idealna badawczo, nie jest na pewno też super-reprezentatywna. Ale ze 121 odpowiedzi (wszystkie pytania były obowiązkowe) wyłania się już jednak pewien obraz tego jak te nasza realia wyglądają.

Poniżej znajdziesz szczegółowe wyniki ⤵️

Ankieta była prowadzona w języku angielskim. Poniżej znajdują się moje tłumaczenia pytań i odpowiedzi. Pod wykresami znajdziesz jednak też treść oryginalnego pytania.

1️⃣ Kim są badani?

W pierwszej części spójrzmy kto brał udział w ankiecie - jakie role, z jak dużych zespołów, jakiego typu firmy:

  • W ankiecie najwięcej wzięło udział Product Mangerów / Leaderów.

  • Najwięcej badanych pracuje w firmach Enterprise, następnie Scaleup

Weź to pod uwagę przy patrzeniu na analizie pozostałych wyników.

1.1. Rola w zespole

Oryginalne pytanie: “What is your role?”

  • Product Manager - 66,1%

  • Product Leader (VP, Dyrektor Produktu) - 14,9%

  • Designer - 5,8%

  • Dev (inżynierowie) - 4,1%

  • Pozostał - 9,1%

1.2. Typ firmy

Oryginalne pytanie: „What type of company do you work for?”

  • Enterprise - 55,4%

  • Scale-up - 23,1%

  • Startup - 9,9%

  • Agencja / Konsulting - 9,9%

2️⃣ Zespół

Zobaczmy w jakich zespołach pracują nasi badani:

  • Najczęściej pracują w zespołach 6-10 osobowych, ale nie jest to znacząca przewaga

  • Prawie połowa ma w swoim składzie tzw. Trio Produktowe (Product Manager, Designer, Tech Lead)

  • Satysfakcję ze współpracy oceniamy średnio (3,7 / 5). Cieszy praktycznie brak najniższych ocen (tylko 0,8%)

Poniżej szczegółowe wyniki.

2.1. Wielkość zespołu

  • 6-10 osób - 33,1%

  • Więcej niż 20 osób - 25,6%

  • 1-5 osób - 24,8%

  • 11-20 osób - 16,5%

2.2. Skład zespołu produktowego (Product Trio)

Oryginalne pytanie: „Does your product team consist of a dedicated Product Manager, Product Designer, and Tech Lead working together?"

  • Tak, mamy wszystkie 3 role - 49,6%

  • Nie mamy dedykowanego Product Designera - 28,1%

  • Obowiązki są niejasne, a role wymieszane - 22,3%

2.3. Satysfakcja z interdyscyplinarnej współpracy

Ocena (w skali od 1 do 5) satysfakcji z współpracy między Product Managerem, Tech Leadem i Designerem:

Oryginalne pytanie: „On a scale of 1 to 5, how satisfied are you with the collaboration between Product Managers, Designers, and Tech Leads in your team?"

  • Ocena 1 - 0,8%

  • Ocena 2 - 10,7%

  • Ocena 3 - 33,1%

  • Ocena 4 - 31,4%

  • Ocena 5 - 24%

Średnia ocena satysfakcji to 3,7 / 5, a mediana to 3.

3️⃣ Jak budujemy produkty?

W trzeciej części robi się jeszcze ciekawiej. Zapytaliśmy o to, w jaki sposób firmy podchodzą do budowania produktów:

  • Zespoły pracują głównie w MIXie produktowego i projektowego podejścia . Tylko 1/5 pracuje w stricte produktowym podejściu.

  • Nasze iteracje mają zwykle 2 tygodnie (lub krótsze).

  • Discovery robimy rzadko. Tylko 1/5 zespołów robi aktywności discovery w każdych 1-2 tygodniach.

  • Priorytetyzujemy głównie na bazie priorytetów od stakeholderów i leadershipu.

  • Strategia produktowa ma niewielki wpływ na nasze priorytety (tylko 1/3 używa jej do priorytetyzacji, a wpływ strategii na nasze decyzje oceniamy na 2,95 / 5).

  • U ponad połowy badanych praktycznie nie ma sesji coachingowych z liderami (nie ma lub są rzadko).

Poniżej szczegółowe wyniki.

3.1. Projektowy vs Produktowy sposób pracy

Oryginalne pytanie: „What best describes your current way of working?”

  • MIX obydwu - mieszanka obu tych aspektów (niektóre inicjatywy koncentrują się na Outcome'ach, inne bardziej na projektach) - 57,5%

  • Realizujemy projekty w oparciu o ustalone plany i harmonogramy - 21,7%

  • Pracujemy jako zespół produktowy, stale iterując, by osiągnąć outcome'y produktowe - 20,8%

3.2. Długość iteracji

Oryginalne pytanie: „What best describes your current iteration process?”

  • Krótszy lub równy 2-tygodnie - 52.07%

  • Dłuższy niż 2-tygodnie, ale krótszy niż miesiąc - 21.49%

  • Cykl miesięczny lub dłuższy - 1.65%

  • Nie mamy ustrukturyzowanego cyklu - 24.79%

3.3. Częstotliwość discovery

Jak często zespoły prowadzą discovery, zanim przejdą do budowania rozwiązania:

Oryginalne pytanie: „How often does your team conduct product discovery to test ideas before building?”

  • Rzadko - 42,1%

  • „Continuously” (co 1-2 tygodnie) - 25,6%

  • Raz na kwartał - 24%

  • Miesięcznie - 8,3%

3.4. Na jakiej podstawie priorytetyzujemy?

Na jakiej podstawie Twój zespół wybiera, którymi problemami się zając? (pytanie wielokrotnego wyboru)

Oryginalne pytanie: „Classify based on the relevance how does your team currently prioritize which problems to solve?”

  • Na bazie priorytetów od stakeholderów i leadershipu, 69,4%

  • Na podstawie insightów od klientów i danych - 47,9%

  • Na podstawie wizji i strategii produktowej - 33,1%

  • Brak formalnego procesu priorytetyzacji - 11,6%

3.5. Wpływ strategii produktowej

W jakim stopniu strategia produktowa wpływa na podejmowanie decyzji przez zespół (w skali od 1-5)?

Oryginalne pytanie:„On a scale of 1 to 5, how well does your product strategy guide your team’s decision-making?”

  • Ocena 1: 9.9%

  • Ocena 2: 21,5%

  • Ocena 3: 37,2%

  • Ocena 4: 25,6%

  • Ocena 5: 5,8%

Średnia ocena wpływu to 2,9 na 5, a mediana to 3.

3.6. Coaching 1:1 z liderem - częstotliwość

Jak często liderzy produktu (np. Head of Product lub Team Lead) prowadzą indywidualne sesje coachingowe z członkami swoich zespołów produktowych?

Oryginalne pytanie: „How often do product leaders (e.g., Heads of Product or Team Leaders) conduct one-on-one coaching sessions with their product team members?”

  • Rzadko - 31,4%

  • Wcale - 23,1%

  • Tygodniowo - 18,2%

  • Co 2 tygodnie - 16,5%

  • Miesięcznie - 10,7%

4️⃣ Największe wyzwania

Na koniec zobaczmy jakie deklaratywnie największe wyzwania mają zespoły w swojej pracy produktowej. Dane pogłębiliśmy też pytaniami jakościowymi.

  • Jako największą barierą w usprawnianiu discovery badani wskazują kulturę firmy promująca delivery (“kult cargo”?).

  • Dużą przeszkodą w szybkim budowaniu produktów są zależności międzyzespołowe.

  • Brak jasnej wizji produktu i alignementu ze stakeholderami wskazywane są jako główne wyzwania przy priorytetyzacji.

  • Nie ma wskazanego jednoznacznie obszaru, który jest największym wyzwaniem przy rozwoju produktów. Ciekawy natomiast jest feedback jakościowy do każdej z możliwych odpowiedzi.

Do wyciągania głębszych wniosków na podstawie tych wyników podchodziłbym z większym sceptycyzmem. Jeśli ogólnie mamy problemy z product managementem, to PM-owie niekoniecznie muszą dobrze dostrzegać ich sedno.

Natomiast tutaj chcieliśmy sprawdzić, jak wyzwania wskazywane w „Transformed” Marty’ego Cagana mają się do naszej rzeczywistości. Deklaratywne dane fajnie nam pokazują, jak te problemy są postrzegane wśród PM-ów.

Poniżej znajdzesz szczegółowe odpowiedzi:

4.1. Bariery w usprawnianiu discovery

Oryginalne pytanie: „What is the biggest barrier to improving your discovery process?”

  • Kultura firmy promująca delivery ponad discovery - 42,1%

  • Za mało czasu na Discovery - 24,8%

  • Ograniczony dostęp do feedbacku klientów - 15,7%

  • Brak umiejętności i narzędzi do szybkiego testowania - 9,9%

  • Inne - 7,4%

Co jeszcze wspomnieli badani (“Inne”):

  • „Engineering i proces product discovery są prowadzone w oddzielnych zespołach.”

  • „Mały rynek, wczesny etap rozwoju.”

  • „Długi czas Delivery sprawia, że discovery, które zrobiliśmy, staje się nieaktualne po dostarczeniu (rynek szybko się zmienia).”

  • „Procesy w firmie – discovery dla mojego produktu jest poza moją kontrolą.”

  • „Skomplikowane produkt legacy z opóźnioną adopcją.”

  • „Brak zaangażowania Tech Teamu w Discovery.”

4.2. Wyzwania w szybkim budowaniu produktu

Oryginalne pytanie: „What is your biggest challenge in building products quickly?”

  • Zależności (z innymi zespołami) - 33,1%

  • Brak capacity w zespole DEV - 24,0%

  • Brak alignementu ze stakeholderami - 22,3%

  • Długa pętla zwrotna - 12,4%

  • Inne - 8,3%

4.3. Wyzwania przy priorytetyzacji

Oryginalne pytanie: „What is the biggest challenge in deciding what problems to solve?”

  • Brak jasnej wizji produktu - 30,6%

  • Brak alignementu pomiędzy leadershipem i zespołami produktowymi - 26,4%

  • Ograniczone zrozumienie potrzeb klientów - 19,8%

  • Inne - 12,4%

  • Dane nie są brane po uwagę - 10,7%

Jako, że kategoria „Inne” ma istotny odsetek odpowiedzi, poniżej znajdziesz to co wskazali w niej badani:

  • „Brak przewidywalności i zrozumienia, ile naprawdę zajmie rozwiązanie problemu (dotyczy funkcji AI, które są znacznie trudniejsze do przewidzenia i oszacowania).”

  • „Decyzje nie są problemem, problemem jest ich egzekucja.”

  • „Ograniczony dostęp do użytkowników.”, „Brak danych.”

  • „Decyzja: zadowolić klienta czy budować rentowność produktu?”

  • „Kultura firmy skupiona na delivery, a nie na rozwiązywaniu problemów.”

  • „Za dużo rzeczy dzieje się naraz, zbyt wiele problemów do rozwiązania – zarówno tych od klientów (problems/opportunities), jak i ograniczeń technicznych.”

  • „Niejasne i sprzeczne insighty z discovery.”

  • „Nie mamy pozwolenia na podejmowanie decyzji.”

  • „Mamy wiele korelacji, ale ograniczone spostrzeżenia dotyczące związków przyczynowo-skutkowych”

4.4. Obszary krytyczne dla sukcesu zespołu

Oryginalne pytanie: „Of the three areas which do you think is MOST critical for your team’s success today?”

  • Decydowanie, które problemy rozwiązywać - 38.8%

  • Discovery najlepszych rozwiązań - 32,2%

  • Szybkie Delivery - 28,9%

Spytaliśmy badanych, dlaczego wybrali wskazaną opcję. Poniżej znajdziesz najciekawsze odpowiedzi:

Dlaczego „Decydowanie, które problemy rozwiązywać”?

  • „Jeśli nie ma jasnej wizji i zrozumienia potrzeb klientów, opieramy się na intuicji senior stakeholderów. Mogą oni zmieniać zdanie bez konkretnego powodu. To jak nawigowanie we mgle. Jeśli jednak mamy solidne zrozumienie problemów do rozwiązania, to produkt, design i tech mogą się łatwiej wyrównać i budować właściwe rozwiązania.”

  • „Mamy ogromny backlog i roadmapy bez wyraźnej strategii. Wysyłamy funkcje, ale tak naprawdę nie posuwamy się do przodu – nie pracujemy nad game changerami, a jedynie utrzymujemy obecne przychody, zamiast je zwiększać.”

  • „Decydowanie, które problemy rozwiązywać, to najważniejszy obszar, bo bezpośrednio wpływa na wartość i efekty pracy zespołu. Bez jasnych priorytetów i skupienia na właściwych problemach łatwo zmarnować zasoby na inicjatywy, które nie odpowiadają na potrzeby użytkowników ani cele biznesowe.”

  • „Obecnie zespół produktowy nie może samodzielnie decydować, które problemy rozwiązywać – wszystko bazuje na pomysłach i prośbach founderów. Potrzebujemy systemu do priorytetyzacji problemów i solidnego discovery.”

  • C-level patrzy na powierzchnię i wydaje się im, że każdy problem produktowy da się rozwiązać poprzez (brrrr!) low-hanging fruits lub super fancy frontendowe zmiany. Przez to trudno priorytetyzować rzeczy, które naprawdę rozwiązują problemy i mają wpływ, ale wymagają czasu na zaprojektowanie, walidację, pierwsze ruchy, redesign i testy AB.”

Dlaczego „Discovery najlepszych rozwiązań”?

  • „Nie możemy zrobić wszystkiego, co chcemy, dlatego najważniejsze jest wiedzieć, co robić. Jak powiedział Albert Einstein: ‘Gdybym miał godzinę na uratowanie świata, 55 minut poświęciłbym na zdefiniowanie problemu, a 5 minut na znalezienie rozwiązania.’”

  • „Jeśli discovery nie jest dobrze przeprowadzone, możemy priorytetyzować i dostarczać niewłaściwe rzeczy.”

  • „Obecnie dostarczamy funkcje, które nie są dobrze dopasowane do tego, co robią inne zespoły. Gdyby discovery działało lepiej, szybciej wykrywalibyśmy sprzeczne funkcje.”

  • „Obecnie produkt rozwijany jest głównie na podstawie tego, co według zarządu klienci powinni chcieć, a nie tego, czego faktycznie potrzebują.”

  • „Szybkie naprawianie problemów bez discovery i zaprojektowania najlepszego rozwiązania sprawia, że produkt staje się trudny w utrzymaniu i zwiększa koszty dalszego rozwoju.”

Dlaczego „Szybkie Delivery”?

  • Team dependencies wpływają na tempo pracy – w korporacji liczy się przede wszystkim delivery, więc sukces zespołów mierzy się szybkością dostarczania, a nie rozwiązywaniem problemów.”

  • „Pracuję w fin-techu, nasze produkty są złożone, mamy wiele zależności między zespołami, a do tego compliance procesy nas spowalniają. Brak QA powoduje, że developerzy, BA i Product Managerowie muszą angażować się w testowanie.”

  • Zbyt długo utknęliśmy na etapie designu – dopóki interesariusze nie zatwierdzą wszystkiego, a potem priorytet dostają bugi i małe zmiany, przez co przez miesiące nie ma realnego postępu w rozwoju produktu.”

  • Rynek zmienia się bardzo dynamicznie, a żeby utrzymać przewagę konkurencyjną, trzeba dostarczać szybko.”

  • „Nawet błędne decyzje można szybko skorygować, ale brak działania oznacza stratę szans rynkowych.”

💬 Co myślicie o tych wynikach?

Jak Wasze zespoły wyglądają na ich tle? Marty Cagan podsumował wyniki jednym zdaniem:

W ogóle mnie one nie dziwią - opisują coś, co nazywa się po prostu „Feature Teams”

Ja może jeszcze coś dorzucę wkrótce od siebie, natomiast jeśli chcecie bardziej dokładnej analizy danych (np. korelacji) w środę Wojtek Smajda opublikuje szczegółową analizę danych w swoim newsletterze. Daj mu suba, aby nie przegapić :).

Wielkie podziękownia dla waszytskich, którzy uzupełnili ankietę, współtwórców (Wojtek Smajda, Marcin Jędrzejczak) oraz robiący pierwsze review wyników (Jakub Koryciński, Anna Jassak, Joanna Madrjas, Tomasz Skórski) 🙏

Reply

or to participate.