Czy robisz Bullshit Product Management?

6 sygnałów ostrzegawczych od Davida Pereiry, CPO MailerLite

Kilka tygodni temu miałem okazję porozmawiać z Davidem Pereirą w podcaście "Dodane do Backlogu". David to CPO w MailerLite, autor książki "Untrapping Product Teams" i jeden z najbardziej bezkompromisowych głosów w świecie PMów.

Temat naszej rozmowy? Bullshit product management.

W ciągu godziny rozmowy usłyszałem rzeczy, które są niewygodne, ale bardzo prawdziwe. Rzeczy, które dotyczą większości PM-ów w PL - w tym mnie samego. Dlatego postanowiłem sobie i Wam wyciągnąć z tego esencję w formie poradnika jak budować produkty w środowisku bullshitu:

• 👉 CZĘŚĆ 1: Dziś odpowiemy na pytanie: czym jest bullshit PM i po czym poznasz, że jesteś w niego uwikłany?

• CZĘŚĆ 2: PIERWSZE KROKI - w drugiej części pokażę Ci 3 konkretne kroki jak zacząć lepiej pracować w środowisku bullshitu (bez rewolucji w organizacji).

• CZĘŚĆ 3: JAK KONTYNUOWAĆ ZMIANĘ? - na koniec trochę rad jak kontynuować zmianę i unikać najważniejszych pułapek.

• 1. Czym jest Bullshit Product Management?

• 2. Dzień, w którym David odkrył, że nie jest PMem

• 3. Jak rozpoznać, czy robisz BS PM?

  • 🔹 Sygnał #1: To się po prostu czuje na spotkaniac …

  • 🔹 Sygnał #2: Masz backlog z setką zadań, których …

  • 🔹 Sygnał #3: Pełny kalendarz spotkań - brak przes …

  • 🔹 Sygnał #4: Nie umiesz odpowiedzieć na pytanie „ …

  • 🔹 Sygnał #5: Brak ownershipu - zajmujesz się koor …

  • 🔹 Sygnał #6: Optymalizujesz velocity, a nie warto …

• 4. Szybki self-check (lista z sygnałami)

• 5. Co zrobić jeśli widzisz te sygnały?

---

Siedzisz na kolejnym spotkaniu. Wierciłeś się w krześle już od 10 minut. Jedyne, o czym myślisz, to: „Jak stąd wyjść?". Po spotkaniu otwierasz Jirę i piszesz kolejne zadanie do backlogu. Zatrzymujesz się na chwilę i myślisz: „Po co właściwie to robię?".

Ale nie masz czasu na takie refleksje, bo za 5 minut kolejny „call”. Patrzysz na kalendarz - każda godzina wypełniona. Pod koniec dnia zadajesz sobie pytanie: "Jaką wartość stworzyłem dziś?".

Byłeś zajęty przez 8 godzin. Ale nie potrafisz powiedzieć, jak Twoje działania wpłynęły na biznes albo na klientów.

Jeśli to brzmi znajomo, mam dla Ciebie dwie wiadomości:

• Zła wiadomość: prawdopodobnie robisz BULLSHIT product management zamiast prawdziwego product managementu.

• Dobra wiadomość: nie jesteś sam.

---

1. Czym jest Bullshit Product Management?

Zanim David odpowiedział na moje pytanie o definicję, zaczął od ważnego zastrzeżenia:

“Whenever I say ‘bullshit management’, some people get pissed off with that. They think that I am pointing fingers.”

Ale to nie o to chodzi. David mówi z doświadczenia. Bo sam przez 3 lata robił bullshit management (BS PM). Jak to określił w naszej rozmowie:

"I used to say that I was a backlog manager, mastering the art of bullshit management, and then eventually I got to become a product manager."

"In reality, for many years, I realized that I was not doing product management at all and I wanted to come up with a name to what I was doing."

David przez 3 lata robił coś, co nie było ani project managementem, ani product managementem. Marnował czas na rzeczy, które nie tworzyły żadnej wartości. I potrzebował nazwy dla tego zjawiska. Nazwy, która zostaje w głowie.

Tak powstał termin bullshit product management.

“BS product management: it’s the art of doing things that create no value but drain your energy.”

To jeszcze raz po polsku: „Sztuka robienia rzeczy, które nie tworzą wartości, ale wyczerpują Twoją energię.”. Można to sprowadzić do prostego równania: Więcej bullshitu = mniej wartości.

Bullshit PM to nie jest wina PM-ów. To pułapka, w którą wszyscy wpadamy. Różnica między dobrym a przeciętnym PM-em? Dobry PM rozpoznaje, kiedy robi bullshit i wie, jak z tego wyjść.

---

2. Dzień, w którym David odkrył, że nie jest Product Managerem

Kiedy zapytałem Davida, kiedy pierwszy raz zdał sobie sprawę, że robi bullshit PM, odpowiedź była natychmiastowa: podczas oblania rozmowy rekrutacyjnej w Booking.com.

• David pracował w Brazylii jako product manager.

• Dostał awans na senior product managera. Dlaczego? Bo pomógł zespołowi zwiększyć velocity o 30% w ciągu 6 miesięcy. Dostarczali ponad 50 story pointów na sprint. David był "velocity masterem" i dostał awans.

• Był pełen siebie. Myślał: "Robię świetną robotę". Dostał awans. Booking.com zainteresował się nim. Wszystko szło idealnie. W głowie miał już przeprowadzkę z Brazylii do Europy. "Muszę robić coś dobrze" - myślał.

• Pierwsza rozmowa z Booking.com poszła dobrze – cultural fit. Ale druga rozmowa, z hiring managerem, już nie za bardzo. Nie potrafił wprost odpowiedzieć na takie pytania jak: Jak mierzysz impact? Jak przeprowadzasz eksperymenty? Jak podejmujesz decyzje produktowe?

“The truth is, I couldn’t answer half of the questions. They were not part of my day-to-day life.”

David wiedział, że rozmowa się nie udała. Ale zamiast się poddać, zapytał: “Może wykorzystamy ten czas, żebyś powiedział mi, czego mi brakuje?”. Odpowiedź rekrutera zmieniła wszystko:

“You’re very good at execution. The thing is, you don’t know what you are optimizing for. You continually execute. You can optimize how teams deliver output. But you don’t talk about outcome. I think you are unaware of that.”

To jest istota bullshit product management.

Robisz rzeczy. Dostarczasz nowe ficzery. Jesteś zajęty - ale nie wiesz, po co. Nie mierzysz wpływu. Nie mówisz o outcomach produktowych. Optymalizujesz coś, nie wiedząc po co.

I wtedy nagle odkrywasz, że przez 3 lata byłeś "backlog managerem", nie product managerem.

---

3. Jak rozpoznać, czy robisz BS PM?

Poniżej znajdziesz 6 sygnałów ostrzegawczych, które pomogą Ci rozpoznać bullshit PM u siebie. Przeczytaj każdy punkt i szczerze odpowiedz sobie na pytanie: "Czy to ja?".

Przyjrzyjmy się im bliżej ⤵️

🔹 Sygnał #1: To się po prostu czuje na spotkaniach

Czujesz po prostu wewnętrzny sprzeciw - czujesz, że tu jest po prostu coś nie tak.

Siedzisz na spotkaniu. Po 10 minutach zaczynasz się wiercić. Scrollujesz Slacka. Przeglądasz Jirę. Myślisz tylko o jednym: "Jak stąd wyjść?".

David opisał to idealnie: „You attend a meeting, you start moving in the chair. The only thing you want to do is not to be in that meeting”. Wiesz, że te spotkania są bezcelowe, ale organizacja myśli, że „tak musi być”.

Praktyczny test: Otwórz swój kalendarz z ostatniego tygodnia. Policz, na ilu spotkaniach naprawdę chciałeś być. A na ilu siedziałeś, bo "trzeba"?

Jeśli ratio jest poniżej 50%, mamy problem.

Dlaczego to bullshit PM?

Bo jeśli większość Twojego czasu spędzasz na spotkaniach, na których nie chcesz być i które nie tworzą wartości - to nie robisz product managementu. Robisz "meeting management".

Jak ten sygnał wyglada w praktyce?

1. Spotkania bez celu. Agenda brzmi jak: „sync”, „update”, „alignment”. Zero decyzji, zero outcome’ów. Jeśli po 45 minutach nie potrafisz powiedzieć, po co to spotkanie się odbyło, to właśnie straciłeś 45 minut życia.

2. Backlog nie jest Twoim backlogiem. Dopisujesz kolejne taski, nawet jeśli wiesz, że 80% z nich nigdy nie wejdzie na produkcję. Robisz to, bo „tak trzeba”, “bo ktoś poprosił”, a nie dlatego, że ma to wartość.

3. Refinement bez refinementu. Uczestniczysz w spotkaniach refinementowych, które są bardziej o “przeczytaniu wymagań biznesu i dowiedzeniu się na kiedy mogą być”, niż o zrozumieniu problemu, znalezieniu i dopracowaniu wspólnie najlepszego rozwiązania.

4. Decyzje bez decyzji. Spotkania kończą się podsumowaniem w stylu: „To wrzucimy do backlogu” lub „Zobaczymy później”. W praktyce oznacza to: nikt nie wziął za nic odpowiedzialności.

5. Zastępujesz myślenie działaniem. Czujesz dyskomfort, więc wypełniasz kalendarz zadaniami, mówisz na wszystko “zajmę się tym, żeby mieć wrażenie, że coś kontrolujesz. W rzeczywistości pogłębiasz chaos większą liczbą tematów.

---

🔹 Sygnał #2: Masz backlog z setką zadań, których nigdy nie zrobisz

Otwórz swój backlog. Przewiń w dół. I jeszcze w dół. I jeszcze.

Ile tam masz zadań? 100? 300? A może tysiąc?

Brutalne pytanie: Ile z nich naprawdę zrobisz w ciągu następnych 6 miesięcy?

Prawda jest taka: większość z nich nigdy nie zostanie zrobiona. Ale trzymasz je tam „na wszelki wypadek". Albo dlatego, że „może kiedyś będą potrzebne". Albo dlatego, że ktoś kiedyś o to poprosił i nie chcesz go urazić.

Trzymasz te tysiące zadań z poczucia fałszywego bezpieczeństwa – „a nuż się przydadzą”.

„You look at your backlog, there are hundreds of items, if not thousands. You know you’re not going to deliver them at all, and you keep them in the backlog for its sake.”

Dlaczego to bullshit PM?

Bo Twój backlog nie jest realnym planem działania. To niekończący się spis wszystkich pojawiających się pomysłów. I za każdym razem, kiedy tam zaglądasz, tracisz energię na przegląd rzeczy, które nie mają znaczenia.

Praktyczny test: Ile zadań masz w backlogu? Ile z nich ma więcej niż 6 miesięcy? Kiedy ostatnio usunął_ś jakieś zadania (nie robiąc go)?

Jeśli odpowiedzi to: "500+", "większość" i "nigdy" - to właśnie to.

Jak ten sygnał wyglada w praktyce?

• Większość zadań ma ponad 6 miesięcy. Jeśli coś leży w backlogu dłużej niż pół roku, prawdopodobnie już nigdy tam nie wrócisz.

• Nie wiesz, kto i po co dodał dany item. Gdy przestajesz rozumieć kontekst, backlog staje się zbiorem losowych żądań.

• Priorytetyzacja to fikcja. Kiedy backlog jest zbyt duży i nie masz celu, żaden framework (RICE, MoSCoW, ICE) nie uratuje Cię przed chaosem.

• Zespół nie ufa backlogowi. Jeśli devowie lub designerzy patrzą na backlog jak na żart, to znaczy, że stracił on sens.

• Zamiast mówić o problemach użytkowników, rozmawiacie głownie o technicznej kolejności tasków. To znak, że proces przejął kontrolę nad sensem.

---

🔹 Sygnał #3: Pełny kalendarz spotkań - brak przestrzeni na myślenie

Patrzysz na swój kalendarz i widzisz kolorowy chaos. Spotkanie za spotkaniem, zero przerw, lunch jedzony przy ekranie.

Nie masz 15 minut na przeczytanie feedbacku od klientów. Nie masz godziny na przemyślenie strategii. Ledwo starczy Ci czasu na oddech.

David Pereira powiedział wprost:

“You look at your calendar, it’s full. It looks like a Tetris, you barely have space to breathe.”

To nie jest oznaka produktywności. PM nie jest po to, żeby biegać ze spotkania na spotkanie, tylko żeby myśleć (ja to nazywam „deep work”), pracować z i nad użytkownikami, łączyć kropki.

Praktyczny test: Otwórz swój kalendarz z ostatniego tygodnia. Policz godziny:

• Spotkania: _____ godzin

• Deep work (strategia, analiza, discovery): _____ godzin

• Puste przestrzenie: _____ godzin

Jeśli współczynnik “spotkań” do “deep work” jest gorsze niż 60:40, to prawdopodobnie robisz bullshit PM.

Dlaczego to problem?

Bo product management to nie zarządzanie kalendarzem. To podejmowanie decyzji, strategia, discovery, analiza. A na to potrzebujesz czasu na myślenie. Jeśli go nie masz - nie robisz PM, robisz „calendar management", by znaleźć choć chwilę na… odpowiedzenie na maile.

Jak ten sygnał wyglada w praktyce?

• Nie masz czasu na refleksję. Kończysz dzień z głową pełną kontekstu, ale bez żadnych wniosków.

• Spotkania się powielają. Review, retro, sync, stakeholder alignment – każde brzmi inaczej, ale sprowadza się do tego samego: update’y bez decyzji.

• Nie masz „focus time”. Nawet godzina bez spotkania to luksus. Zamiast tworzyć wartość, odtwarzasz rzeczywistość w PowerPointach.

• Odpowiadasz na Slacku z opóźnieniem, bo jesteś na callu. Cały dzień. To moment, w którym stajesz się bottleneckiem – nie liderem.

• Twój tydzień kończy się, zanim się zacznie. W poniedziałek czujesz, że nic strategicznego nie zrobisz do piątku, bo wszystko już zablokowały kalendarzowe rytuały.

---

🔹 Sygnał #4: Nie umiesz odpowiedzieć na pytanie „jaką wartość stworzyłem dziś?”

To jedno z najprostszych i jednocześnie najbardziej bezlitosnych pytań, jakie może zadać sobie Product Manager: „Jak moje dzisiejsze działania realnie wpłynęły na biznes albo klientów? Jaką wniosł_m wartość?”

„How did I contribute to value creation today?”

„You struggle to answer this question. You do know you were busy throughout the day, but you struggle to understand how your actions contributed to impact for business and customers.”

Jeśli kończysz dzień zmęczony, z długą listą wykonanych zadań (outputy), ale nie potrafisz wskazać realnego wpływu na użytkownika lub biznes (outcome’y), to znak, że tkwisz w trybie Bullshit PM.

❌ OUTPUTS - to NIE jest konkretna wartość:

• Zaktualizowałem 20 zadań w backlogu

• Byłem na 6 spotkaniach

• Napisałem 3 user stories

• Zrobiłem refinement backlogu

✅ OUTCOMES - to JEST wartość:

• Przeprowadziłem 3 wywiady z klientami i odkryłem, że 70% nie używa feature X, który planowaliśmy rozwijać

• Przeanalizowałem dane i odkryłem, że zmiana onboardingu może zwiększyć retention o 15%

• Zidentyfikowałem spriorytetyzowałem najważniejsze problemy w produkcie i zaproponowałem rozwiązanie

• Pomogłem zespołowi podjąć decyzję: zrezygnowaliśmy z feature Y, bo nie ma product-market fit

Praktyczny test: Na koniec każdego dnia zapisz w jednym zdaniu:

"Dziś stworzyłem wartość poprzez ___________"

Jeśli przez 3 dni z rzędu nie potrafisz tego wypełnić - robisz bullshit PM.

Dlaczego to problem?

David powiedział to dosadnie w naszej rozmowie:

“Being busy doesn’t mean creating value.”

“I was just wasting time doing things that created no value.”

Możesz przepracować 10 godzin dziennie, być na wszystkich spotkaniach, odpowiadać na wszystkie Slacki i zamykać wszystkie tickety. Ale jeśli na koniec dnia nie potrafisz powiedzieć, jak to wpłynęło na biznes lub klientów - marnujesz swój czas.

Jak ten sygnał wyglada w praktyce?

1. Dowożenie zamiast tworzenia wartości. Mierzysz sukces liczbą ukończonych ticketów w Jira (output), nie zmianą zachowań użytkowników (product outcomes).

2. Brak miary sukcesu. Robisz featury, projekty, inicjatywy - ale nikt nie zdefiniował, co ma się po nich zmienić.

3. Odłączony od użytkownika. Nie rozmawiasz z klientami, nie widzisz danych o użyciu produktu, nie masz feedbacku. Operujesz w próżni.

4. Mówisz językiem outputu. „Wdrożyliśmy”, „zrobiliśmy”, „skończyliśmy sprint”. Ale nie potrafisz dokończyć zdania: „dzięki temu użytkownicy teraz…”

5. Brak refleksji. Każdy tydzień wygląda tak samo - planowanie, delivery, retrospekcja. Zero momentów na zastanowienie się: czy to w ogóle miało sens?

6. Mylisz aktywność z postępem. Twój szef pyta "jak idzie projekt?", odpowiadasz "mamy zrobione 30 zadań / story points".

7. Wypalenie bez rezultatów. Pracujesz ciężko, ale nie widzisz efektów. Po roku pytasz się "co ja właściwie osiągnąłem?" i nie masz odpowiedzi.

---

🔹 Sygnał #5: Brak ownershipu - zajmujesz się koordynacją

To jeden z najbardziej podstępnych objawów Bullshit Product Managementu. Z zewnątrz wygląda, że wszystko gra: dowozisz sprinty, masz roadmapę, współpracujesz z zespołem.

Ale pod spodem - nie prowadzisz realnie produktu, tylko koordynujesz działania. Reagujesz, zamiast kierować. Wymyślasz procesy, zamiast podejmować decyzję.

David Pereira ujął to bardzo celnie:

“When you lack ownership, you’re just managing tasks. You stop leading the product and start serving the process.”

Brak ownershipu nie oznacza, że się nie starasz. Oznacza, że Twój fokus przesunął się z odpowiedzialności za wartość na utrzymanie procesu.

Praktyczny test: Odpowiedz sobie szczerze: kto ostatnio zdecydował, co będziecie robić w następnym sprincie?

• ✅ Ty, na podstawie discovery, analizy i strategii?

• ❌ A może CEO, który "ma pomysł"? Najgłośniejszy stakeholder? To, co było w backlogu od 3 miesięcy?

Jeśli częściej decydują inni - nie jesteś PM, tylko koordynatorem przyjmującym zamówienia.

Dlaczego to problem?

Bo product management to nie (tylko) koordynacja działań. Kiedy nie masz ownershipu:

• Produkt traci kierunek. Decyzje są rozproszone, a roadmapa staje się zbiorem kompromisów zamiast strategii.

• Patrzenie krótkoterminowe. Gdy PM nie ma głosu, decyzje zaczynają być podejmowane z perspektywy krótkoterminowych KPI (“bo to teraz dla nas pilne”), a nie długoterminowej wartości.

• Tracisz zaufanie. Jeśli zespół widzi, że unikasz decyzji, przestaje wierzyć, że możesz ich prowadzić.

Jak ten sygnał wyglada w praktyce?

• Czekasz na kierunek od innych. Zamiast samodzielnie inicjować decyzje, szukasz potwierdzenia u stakeholderów. „Poczekajmy, aż biznes zdecyduje”, „Najpierw niech CTO powie, co sądzi”. Brzmi znajomo?

• Nie masz własnego zdania o produkcie. Kiedy ktoś pyta: „Dlaczego robicie ten feature?”, Twoja odpowiedź brzmi: „Bo tak ustaliliśmy na spotkaniu o roadmapie”.

• Zespół nie wie, jaki jest cel. Delivery idzie, ale nikt nie potrafi powiedzieć, dlaczego coś robicie i co się stanie, jeśli to zadziała.

• Brak partnerstwa z biznesem. W spotkaniach jesteś bardziej notariuszem niż liderem. Zapisujesz decyzje zamiast je współtworzyć.

• Proces > wartość. Skupiasz się na tym, żeby backlog był czysty, sprint dobrze zamknięty, a velocity wzrosło - ale nie pytasz, czy użytkownicy cokolwiek z tego mają.

---

🔹 Sygnał #6: Optymalizujesz velocity, a nie wartość

Ten sygnał jest najbardziej podstępny, bo daje fałszywe poczucie sukcesu - czujesz się dobrym PM-em, choć w rzeczywistości jesteś sprawnym Project/Backlog Managerem.

To jest pułapka w którą wpadł David: dostał awans właśnie za to, że pomógł zespołowi zwiększyć Output (ilość Story Points) o 30%. Szybko stał się „velocity masterem”. To jest typowe dla Bullshit PM: nagradzamy PMów i mierzymy głownie szybkość dostarczania (Output), a nie wpływ na klienta i biznes (Outcome).

Możesz zamykać Sprint za Sprintem ze 100% realizacją zadań, ale jeśli te dowożone Feature’y nie rozwiązują realnych problemów (co pokazały badania Davida w jego zespole: 50% feature’ów starszych niż rok jest nieużywanych), to cała ta prędkość jest bezsensowna.

Mówiąc krótko: dostarczasz bezwartościowy Bullshit z rekordową prędkością.

Praktyczny test: Zadaj sobie te 4 pytań. Jeśli odpowiedź na więcej niż 3 pytania to "nie" - optymalizujesz output, nie outcome.

• Czy wiesz, ile % Waszych ostatnich 10 ficzerów jest aktywnie używanych?

• Czy mierzycie outcome każdej inicjatywy po wypuszczeniu?

• Czy na Sprint Review mówicie więcej głownie o zamkniętych zadaniach, velocity, czy bardziej o produktowym outcomiw?

• Czy Wasze OKRy to konkretne dostarczone ficzery czy metryki produktowe?

Dlaczego to problem?

Bo optymalizujesz swoją prace pod złą metrykę.

Velocity mówi Ci, jak szybko zespół dostarcza output. Ale nie mówi Ci nic o tym, czy ten output ma sens. Nie mówię, że nie powinieneś myśleć nad jakością i szybkością dostarczania, ale… to nie powinien być Twój najważniejszy cel. Możesz mieć najwyższą velocity w firmie i jednocześnie budować produkt, którego nikt nie używa.

Historia Davida to idealna ilustracja: dostał awans za zwiększenie velocity o 30%, ale kiedy zapytano go „jak mierzysz impact?", nie potrafił odpowiedzieć. Optymalizował coś, nie wiedząc po co. I nagle odkrył, że przez 3 lata był "backlog managerem", nie product managerem.

Jak ten sygnał wyglada w praktyce?

• Celebrujecie głownie „dostarczenie ficzerów". Sprint review to pokaz nowych features. Nikt nie pyta "czy ktoś tego używa" ani "jaki problem rozwiązaliśmy". Wypuszczacie feature i od razu bierzecie się za kolejny, bez sprawdzania adoption.

• Skupiacie się głownie na optymalizacji procesu, nie wyniku. Rozmawiacie o velocity i estymacjach głownie, za to nie pojawiają się tematy czy ostatnie funkcje miały wpływ na retencje użytkownika, metryki outcomowe czy nawet przychody. Metryki sukcesu dla zespołu to story pointy, ukończone zadania, a nie produktowe outcomy.

• Zespół nie zna KPI (produktowych, biznesowych). Developerzy są dumni, że „zamknęli 20 tasków". Ale zapytaj ich „jaki problem biznesowy/użytkownika rozwiązaliście?" - usłyszysz ciszę. Zespół nie wie, jak ich praca wpływa na klientów.

• OKRy mówią o dostarczeniu, nie o wpływie. Wasze cele: „Dostarczyć ficzer X w Q2", “Przeprowadzić X testów”. a nie ma nic w stylu: "Zwiększyć retencje ficzera X z 60% do 70%", „Rozwiązać problem Y”.

• Brak ewaluacji wypuszczonych ficzerów. Ficzer wychodzi na produkcje i… znika z radaru. Po miesiącu nie sprawdzacie: Czy ludzie tego używają? Czy warto to dalej rozwijać?

---

4. Szybki self-check (lista z sygnałami)

Zrobiłem też prostą interaktywną stronę w artefaktach Claude.ai, która pozwoli Ci w 2 minuty spojrzeć w lustro i zobaczyć ile z sygnałów Bullshit PM identyfikujesz u siebie ⤵️

Ważne: Bądź ze sobą szczery. To narzędzie dla Ciebie, nie ocena z zewnątrz. Nikt poza Tobą nie zobaczy wyników. To narzędzie do autorefleksji, nie wyrok. Nawet jeśli rozpoznasz u siebie 6 z 7 sygnałów - nie jesteś sam.

---

5. Co zrobić jeśli widzisz te sygnały?

Jeśli rozpoznałeś u siebie więcej niż 3 sygnały, prawdopodobnie czujesz się teraz niekomfortowo. Może nawet trochę „Przecież robię, co mogę!", "To nie moja wina, że organizacja tak działa!", „Ale ja nie mam wpływu na...".

I masz rację.

Bullshit Product Management to rzadko wina samego PM-a. To konsekwencja kultury organizacyjnej, presji na delivery, braku przestrzeni na discovery, stakeholderów, którzy "wiedzą lepiej".

Ale - i to jest kluczowe - możesz zacząć robić lepszy product management także w takim środowisku. David podczas podcastu powiedział coś, co zapadło mi mocno w pamięć. To cytat od jego mamy:

“You can always find an excuse for things you don’t want to do. But when you really want to do, just do it.”

Jeśli chcesz przestać robić bullshit PM - możesz. Ale musisz chcieć.

Najpierw musisz rozpoznać problem (o tym był ten artykuł), a potem zacząć działać. Skupimy się na tym w części 2 ⤵️

---

➡️ W kolejnej części

W drugiej części pokażę Ci trzy konkretne kroki, jak zacząć robić „prawdziwy” product mangement w środowisku bullshit PM. Czyli jak zacząć - BEZ ROBIENIA REWOLUCJI w organizacji.

Jak robić produkt w środowisku bullshitu? 3 pierwsze kroki