Zatrudniaj PM-ów za to, co usunęli, a nie za to, co planują

Przeglądasz CV kandydata na Product Managera. Widzisz imponujące listy: „wdrożyłem 20 nowych funkcjonalności”, „zarządzałem harmonogramem na 3 lata do przodu”, „zwiększyłem backlog o 200%”. W większości warszawskich czy wrocławskich firm technologicznych taki kandydat zostałby przyjęty z otwartymi ramionami. Przecież wdrożenia to postęp, prawda? To błąd, który kosztuje Twoją firmę miliony złotych w długu technicznym i operacyjnym chaosie.

Najlepsi product managerowie (PM) na świecie nie są oceniani za to, jak dużo dodają do produktu. Są oceniani za to, jak dużo potrafią z niego wyciąć, zanim trafi to do produkcji. Produktywność w zarządzaniu produktem to nie liczba napisanych historii użytkownika, ale maksymalizacja wartości przy minimalnym nakładzie pracy deweloperskiej. Jeśli Twój PM mówi „tak” każdemu interesariuszowi, nie jest menedżerem – jest tylko drogim sekretarzem spisującym życzenia.

W tym artykule pokażemy Ci, jak całkowicie odwrócić proces rekrutacji. Zamiast pytać kandydata „co byś zbudował?”, zapytasz go „co byś usunął?”. Przeprowadzimy Cię przez proces „deletion interview” – symulacji, w której kandydat musi odrzucić 40% backlogu w 45 minut, działając na podstawie twardych danych z modułu „Analityka i raporty”, zgłoszeń supportu i danych sprzedażowych. Dowiesz się, jak wdrożyć kulturę, w której ustalanie priorytetów oznacza odejmowanie, a nie dodawanie, co w efekcie zwiększy przewidywalność Twoich sprintów o 15–25%.

Mit harmonogramu i pułapka dodawania

Wielu założycieli firm i dyrektorów wpada w pułapkę myślenia, że harmonogram (plan rozwoju produktu) to lista zakupów. Im dłuższy, tym lepszy, bo pokazuje „wizję”. W rzeczywistości długi harmonogram to często cmentarzysko pomysłów, które nigdy nie zostaną zrealizowane, ale blokują mentalną przestrzeń zespołu.

Psychologia nadmiaru

Dlaczego tak trudno jest nam usuwać? Badania psychologiczne (m.in. Leidy Klotz) wskazują, że ludzki mózg jest biologicznie zaprogramowany do rozwiązywania problemów poprzez dodawanie. Kiedy widzimy niedoskonały produkt, instynktownie myślimy: „czego tu brakuje?”, a nie „co jest tu zbędne?”. Zatrudniając PM-a, musisz szukać kogoś, kto potrafi przełamać ten kognitywny schemat. Kogoś, kto rozumie, że każda dodatkowa opcja w menu zwiększa czas decyzji użytkownika i ryzyko porzucenia aplikacji (paradoks wyboru).

Koszt alternatywny każdej funkcji

Każda nowa funkcja w produkcie to nie tylko koszt jej wytworzenia (programiści, design). To także:

• Koszt utrzymania (maintenance) – każda linijka kodu to potencjalny błąd w przyszłości.

• Koszt dokumentacji i szkolenia supportu – zespół obsługi musi wiedzieć, jak to działa.

• Koszt skomplikowania interfejsu dla użytkownika (UX debt) – im więcej przycisków, tym trudniej znaleźć ten właściwy.

• Koszt rozproszenia zespołu – kontekst, który trzeba utrzymywać w głowie.

Kiedy zatrudniasz PM-a, który uwielbia dodawać nowe rzeczy, zatrudniasz kogoś, kto systematycznie zwiększa te koszty. Potrzebujesz kogoś, kto działa jak redaktor naczelny, a nie jak autor piszący wszystko, co mu przyjdzie do głowy. Redaktor usuwa zbędne słowa, by tekst był czytelny. Dobry PM usuwa zbędne zadania, by produkt był użyteczny.

Syndrom „feature factory”

W Polsce wiele software house’ów i startupów działa w trybie „fabryki funkcji”. Mierzą sukces liczbą wdrożeń (output), a nie wpływem na biznes (outcome). PM w takim środowisku jest nagradzany za „dowożenie”. Twoim celem jest znalezienie kogoś, kto potrafi zatrzymać linię produkcyjną i zapytać: „Czy my w ogóle powinniśmy to budować?”.

Przygotowanie wywiadu eliminacyjnego

Tradycyjna rozmowa kwalifikacyjna sprawdza charyzmę i umiejętność opowiadania historii. Wywiad eliminacyjny sprawdza brutalną logikę biznesową i asertywność. To test na odporność na presję społeczną – bo najtrudniej jest powiedzieć „nie” komuś ważnemu.

Krok 1: stwórz „zatruty” backlog

Przygotuj arkusz lub tablicę z listą 20–30 potencjalnych funkcji/zadań. To powinna być mieszanka:

1. Rzeczy oczywistych: (np. „Naprawa krytycznego błędu logowania”).

2. Rzeczy modnych, ale wątpliwych: (np. „Wdrożenie AI do generowania awatarów” w aplikacji księgowej).

3. Rzeczy głośnych, ale mało ważnych: (np. prośba CEO o zmianę koloru przycisku – to klasyczna pułapka na kandydatów bez kręgosłupa).

4. Długu technologicznego: (np. „Aktualizacja biblioteki X” – test na zrozumienie fundamentów technicznych).

Krok 2: dostarcz dane kontekstowe

Kandydat nie może zgadywać. Musi mieć dostęp do (symulowanych) danych. Przygotuj proste raporty:

• Głos sprzedaży: „Klienci Enterprise pytają o funkcję X, ale nikt jeszcze nie podpisał kontraktu warunkowanego tą funkcją”.

• Głos supportu: „70% zgłoszeń dotyczy powolnego ładowania raportów”.

• Głos analityki: „Funkcja Y wdrożona rok temu jest używana przez 2% użytkowników”.

Krok 3: zadanie

Powiedz kandydatowi: 

„Masz zasoby, by zrealizować tylko 3 z tych 20 zadań w najbliższym kwartale. Twoim celem nie jest wybranie trzech najlepszych. Twoim celem jest uzasadnienie usunięcia (lub odłożenia na rok) pozostałych 17. Masz 45 minut”. 

Obserwuj, czy kandydat zaczyna od szukania „perełek”, czy od odrzucania śmieci. Najlepsi zaczynają od agresywnego czyszczenia listy.

Czego szukać w odpowiedziach kandydata?

Obserwuj proces myślowy kandydata. Nie szukasz kogoś, kto zgadnie prawidłową odpowiedź (bo taka nie istnieje). Szukasz kogoś, kto potrafi powiedzieć „nie” na podstawie dowodów. Zwróć uwagę na to, jak kandydat traktuje „święte krowy” – pomysły zgłoszone przez założycieli.

Czerwone flagi (kogo nie zatrudniać):

• Zadowalacz: próbuje wcisnąć 5 zadań zamiast 3, ściskając zespół lub obiecując nadgodziny. To gwarancja wypalenia zespołu po kwartale.

• Polityk: wybiera zadanie zgłoszone przez CEO tylko dlatego, że zgłosił je CEO, ignorując dane o jego niskiej wartości. Taki PM nie ochroni produktu przed ego interesariuszy.

• Technokrata: skupia się wyłącznie na nowinkach technologicznych, ignorując potrzeby biznesowe i ból użytkowników.

Zielone flagi (kogo zatrudniać):

• Bezwzględny selekcjoner: od razu wyrzuca rzeczy o niskim wpływie (low impact), nawet jeśli są łatwe do zrobienia (low effort). Rozumie, że łatwe nie znaczy wartościowe.

• Badacz danych: zadaje pytania o dane. „Ile dokładnie stracimy, jeśli nie zrobimy funkcji Z?”. Szuka dowodu, a nie opinii.

• Negocjator: proponuje mniejsze wersje rozwiązań (MVP), aby sprawdzić hipotezę, zamiast budować całą funkcję. Na przykład: zamiast „budowy nowego modułu raportowego”, proponuje „ręczne wysłanie 10 raportów mailem, by sprawdzić, czy klienci ich użyją”.

Wykorzystanie danych

Dobry PM nie mówi „nie”, bo ma taki kaprys. Mówi „nie”, bo tak pokazują liczby. Podczas wdrażania nowego pracownika, musisz dać mu narzędzia, które pozwolą mu bronić swoich decyzji przed zarządem.

Tutaj kluczową rolę odgrywa funkcja Bitrix24 analityka i raporty. PM nie powinien spędzać godzin na ręcznym sklejaniu Exceli. Powinien mieć dashboard, który pokazuje:

1. Wykorzystanie funkcji: które części systemu są martwe? (Kandydaci do usunięcia).

2. Trendy zgłoszeń: co najbardziej boli użytkowników?

3. Konwersję: czy ostatnie wdrożenia realnie wpłynęły na sprzedaż?

Ucz swojego PM-a, że każda nowa propozycja funkcjonalności musi być zderzona z tymi danymi. Jeśli ktoś proponuje „przebudowę panelu klienta”, PM powinien otworzyć analitykę i zapytać: „Dlaczego, skoro obecny panel ma 98% skuteczności w realizacji zadań użytkownika?”. Dane to jedyny sposób na uciszenie HIPPO (Highest Paid Person's Opinion).

Precyzowanie problemu przed rozwiązaniem

Częstym błędem słabych PM-ów jest przyjmowanie rozwiązań od klientów, zamiast diagnozowania problemów. Klient mówi: „Chcę przycisk eksportu do PDF”. Słaby PM dodaje zadanie „Zrobić eksport do PDF”. Dobry PM pyta: „Po co ci ten PDF?”. Okazuje się, że klient chce wysłać dane księgowej. Lepszym rozwiązaniem może być automatyczna wysyłka mailem lub integracja API.

Aby wspomóc PM-a w tej detektywistycznej pracy, wykorzystaj CoPilot w CRM. To narzędzie oparte na AI może analizować setki transkrypcji rozmów sprzedażowych, maili i czatów z klientami.

Zamiast czytać tysiące logów, PM może zadać CoPilotowi pytanie:

• „Jakie są najczęstsze obiekcje klientów dotyczące modułu raportowania?”

• „Zidentyfikuj wzorce w prośbach o nowe funkcje w sektorze logistycznym”.

CoPilot pomaga napisać krystalicznie czyste definicje problemów (problem statements). Dzięki temu do backlogu trafiają tylko zadania, które rozwiązują zweryfikowane, realne problemy, a nie zachcianki. To drastycznie redukuje liczbę zadań typu „nice-to-have”, które tylko zaśmiecają proces deweloperski.

Instytucjonalizacja usuwania: „czystka kwartalna”

Zatrudnienie odpowiedniego człowieka to początek. Musisz stworzyć rytuał, który promuje usuwanie. Wprowadź zasadę „kwartalnej czystki backlogu”. Backlog w wielu firmach staje się listą życzeń, do której wrzuca się wszystko, „żeby nie zapomnieć”. W rzeczywistości staje się listą wyrzutów sumienia.

Raz na kwartał, PM wraz z tech leadem przeglądają zadania starsze niż 3 miesiące. Zasada domyślna: usuń. Jeśli zadanie leży w backlogu przez 90 dni i nikt go nie zrobił, to znaczy, że nie jest ważne. Jeśli stanie się ważne, wróci jako nowe zgłoszenie.

To bolesny proces dla wielu organizacji. „Ale może się przydać!”, „Już to przeanalizowaliśmy!”. To koszty utopione (sunk costs). Trzymanie starych zadań to koszt poznawczy – za każdym razem, gdy przeglądasz backlog, musisz tracić energię na ich filtrowanie.

Dobry PM, którego zatrudniłeś dzięki metodzie „deletion interview”, będzie czuł satysfakcję z tego procesu. Będzie wiedział, że czysty backlog to skupiony zespół.

Wyniki: czego oczekiwać po 6 miesiącach?

Jeśli wdrożysz tę strategię rekrutacji i pracy, zmiany będą namacalne.

1. Wzrost morale deweloperów: programiści nienawidzą budować rzeczy, które lądują w koszu. Kiedy widzą, że PM chroni ich przed bezsensowną pracą, ich zaangażowanie rośnie.

2. Szybszy time-to-market: mniej zadań w kolejce oznacza, że te ważne przechodzą przez system szybciej.

3. Lepszy produkt: produkt, który ma mniej funkcji, ale są one dopracowane i rozwiązują realne problemy, zawsze wygrywa z „kombajnem”, w którym nic nie działa dobrze.

Podsumowanie

Zmiana podejścia do rekrutacji PM-a to inwestycja w higienę Twojej firmy. Przestań szukać wizjonerów, którzy chcą zbudować drugi Google. Zacznij szukać pragmatyków, którzy potrafią powiedzieć „nie” 99 razy, żeby to jedno „tak” miało znaczenie.

Oto kluczowe kroki do wdrożenia:

• Zmień rekrutację: wprowadź „deletion interview”. Oceniaj logikę usuwania zadań, a nie kreatywność w ich dodawaniu.

• Wymagaj danych: użyj analityki i raportów, aby każda decyzja produktowa miała pokrycie w liczbach.

• Wspieraj AI: wykorzystaj CoPilot w CRM do diagnozy prawdziwych problemów klientów przed rozpoczęciem prac.

• Pilnuj limitów: użyj zarządzania projektami, by wymusić limity WIP i kulturę kończenia zadań.

• Czyść regularnie: usuwaj bez litości stare zadania z backlogu.

Pamiętaj: w zarządzaniu produktem, mniej znaczy nie tylko więcej. Mniej znaczy szybciej, taniej i lepiej.

FAQ:

Jakie materiały udostępnić kandydatowi podczas testu usuwania?

Nie dawaj kandydatowi czystej kartki. Musi pracować na „żywym organizmie”. Udostępnij mu trzy rzeczy:

1. Wydrukowany (lub w formacie PDF) backlog z 20–30 historyjkami użytkownika, zawierający szacowany czas realizacji (w dniach lub story points).

2. Zestaw 5 „kart person”, opisujących kluczowych klientów i ich bóle (oparte na prawdziwych danych z CRM).

3. Arkusz Excel z surowymi danymi z supportu (top 10 zgłaszanych błędów) i analityki (top 10 najrzadziej używanych funkcji). To sprawia, że symulacja jest realistyczna. PM musi łączyć kropki między różnymi źródłami danych, a nie tylko kierować się intuicją.

Jak uniknąć stronniczości przy ocenianiu kandydata?

Stwórz prostą kartę oceny (scorecard) przed rozmową. Zdefiniuj kryteria sukcesu: „kandydat użył danych finansowych do odrzucenia funkcji X”, „kandydat zapytał o cel biznesowy funkcji Y”, „kandydat zauważył, że funkcja Z jest technicznie ryzykowna”. Oceniasz proces dochodzenia do decyzji, a nie to, czy kandydat jest miły. Jeśli kandydat usunie Twoją ulubioną funkcję, ale uzasadni to spadkiem konwersji – dostaje punkty. Jeśli zostawi ją, bo „szef tak chce” – traci punkty.

Jakie metryki dowodzą, że priorytetyzacja działa po zatrudnieniu?

Szukaj sygnałów w „cyklu życia zadania” (cycle time). Jeśli PM dobrze priorytetyzuje (czyli usuwa szum), średni czas od „rozpoczęcia” do „wdrożenia” powinien spaść, ponieważ zespół nie jest rozpraszany kontekstem. Inną kluczową metryką jest „feature adoption rate” (wskaźnik adopcji funkcji). Jeśli PM buduje mniej, ale trafniej, to procent użytkowników korzystających z nowych funkcji powinien drastycznie wzrosnąć (np. z 10% do 40% w pierwszym miesiącu po wdrożeniu).

Jak działy Sprzedaży i Wsparcia zasilają pętlę priorytetyzacji?

Działy te nie powinny dyktować rozwiązań („zróbcie ten guzik”), ale dostarczać dowodów na problemy. Wdróż system tagowania zgłoszeń w CRM. Jeśli 50 klientów zgłosi problem z „eksportem danych”, to jest to sygnał (input) dla PM-a. Rola PM-a polega na agregacji tych sygnałów i decyzji, czy rozwiązujemy to systemowo, czy może problem dotyczy tylko nieistotnego segmentu klientów. PM musi mieć regularne spotkania z liderami Sprzedaży i Wsparcia, ale nie po to, by zbierać zamówienia, lecz by walidować hipotezy.

Jaki jest odpowiedni limit WIP dla zespołu 6 inżynierów?

Dla zespołu 6-osobowego, zdrowy limit WIP (zadań w toku) to zazwyczaj mniej niż liczba członków zespołu, np. 4 lub 5. Dlaczego? Ponieważ wymusza to współpracę (pair programming, code review). Jeśli limit wynosi 6 lub więcej, każdy pracuje w swoim silosie, co wydłuża integrację i testy. Jeśli limit jest niższy niż liczba osób, wolni inżynierowie muszą pomóc kolegom domknąć otwarte tematy (np. testując lub pisząc dokumentację), zamiast otwierać nowe. To najszybsza droga do zwiększenia przepustowości zespołu.