Gdzie kończy się odpowiedzialność Product Managera, a zaczyna rola Tech Leada? I co zrobić, gdy biznes naciska na termin, PM chce dowieźć wynik, a zespół techniczny widzi ryzyko, którego nie da się zignorować? W tym odcinku On the Edge by E1S przyglądamy się współpracy Product Managera i Tech Leada od strony codziennych decyzji: ustalania zakresu, negocjowania terminów, ochrony zespołu przed context switchingiem i budowania zaufania, które pozwala mówić otwarcie „nie” – ale zawsze z argumentami i alternatywą. Natalia Szindler-Markiewicz, Senior Product Manager w Allegro, oraz Mariusz Batyra, Tech Lead w Edge One Solutions, pokazują, jak wspólne podejmowanie decyzji wpływa na przewidywalność delivery, relacje z biznesem i efektywność zespołu.
🎧 Posłuchaj odcinka i sprawdź, jak zbudować współpracę Product Manager–Tech Lead bez barykady między produktem a technologią.
Spotify:
YouTube:
Gdzie przebiega granica odpowiedzialności Product Managera i Tech Leada?
Prosty podział: Product Manager odpowiada za to, jaki problem warto rozwiązać i jaki efekt biznesowy powinien przynieść produkt. Tech Lead odpowiada za to, jak rozwiązanie zostanie zbudowane, jakie niesie ryzyko i czy zespół może je bezpiecznie dostarczyć.
W teorii podział wydaje się prosty. Product Manager odpowiada za to, co i dlaczego warto zbudować. Powinien rozumieć potrzeby użytkowników, cele biznesowe, priorytety interesariuszy i oczekiwane rezultaty. Odpowiedzialność Product Managera obejmuje także podejmowanie decyzji dotyczących wartości, kolejności inicjatyw oraz zakresu produktu. Nie oznacza jednak samodzielnego określania terminu ani sposobu realizacji.
Tech Lead odpowiada za to, jak rozwiązanie zostanie zbudowane. Ocenia wykonalność, ryzyko techniczne, zależności, wpływ na architekturę, bezpieczeństwo, utrzymanie i dostępne capacity zespołu. Odpowiedzialność Tech Leada nie ogranicza się do jakości kodu. Obejmuje również tworzenie warunków, w których zespół może pracować bez ciągłego chaosu, przeciążenia i zmiany kontekstu.
| Obszar | Product Manager | Tech Lead | Wspólna decyzja |
|---|---|---|---|
| Problem | Definiuje potrzebę użytkownika i cel biznesowy | Wskazuje ograniczenia i dostępne możliwości techniczne | Czy problem jest wystarczająco ważny i możliwy do rozwiązania? |
| Zakres | Określa priorytet oraz wartość elementów | Ocenia koszt, zależności i ryzyko | Jaki najmniejszy zakres pozwoli osiągnąć cel? |
| Termin | Dostarcza kontekst biznesowy i znaczenie daty | Ocenia wykonalność i poziom niepewności | Jaki zakres może zostać dostarczony w danym czasie? |
| Realizacja | Pilnuje efektu produktowego | Prowadzi decyzje techniczne i wspiera zespół | Jak reagować na nowe dane i zmianę ryzyka? |
Nie powinno się traktować tego modelu jako sztywny podział. PM może formalnie odpowiadać za zakres, ale nie powinien definiować go bez znajomości kosztu technicznego. Tech Lead może odpowiadać za sposób realizacji, ale nie powinien podejmować decyzji bez zrozumienia problemu użytkownika i celu biznesowego.
Co wymaga wspólnej decyzji?
- zakres możliwy do dostarczenia w określonym terminie,
- kolejność inicjatyw konkurujących o capacity zespołu,
- poziom akceptowalnego ryzyka,
- podział rozwiązania na etapy,
- reakcja na zmianę priorytetów,
- komunikacja konsekwencji do interesariuszy.
Wniosek: nie próbuj oddzielić ról grubą linią. Zdefiniuj właścicieli decyzji, ale zakres, termin i ryzyko omawiajcie wspólnie.
Kiedy zaangażować Tech Leada?
Najczęściej Tech Lead zostaje zaangażowany zbyt późno. Najpierw powstaje oczekiwany zakres, UX przygotowuje kompletne makiety, interesariusze akceptują kierunek, a dopiero później zespół techniczny otrzymuje materiał do estymacji. Na tym etapie każda uwaga Engineering wygląda jak próba opóźnienia projektu. Oczekiwania zostały już zbudowane, termin padł podczas spotkania, a rozwiązanie zaczęło być traktowane jak zatwierdzone.
Definicja problemu
PM przedstawia potrzebę użytkownika i efekt biznesowy. Tech Lead pomaga rozpoznać ograniczenia, zależności oraz dostępne możliwości techniczne.
Wczesne discovery
Tech Lead ocenia, jakie założenia należy zweryfikować, które systemy obejmie zmiana i czy warto rozpocząć od eksperymentu.
Refinement z zespołem i UX
Zespół analizuje przypadki brzegowe, zależności i elementy, które na makiecie wyglądają prosto, ale zwiększają złożoność realizacji.
Decyzja o realizacji
PM i Tech Lead uzgadniają zakres, poziom ryzyka, kolejność prac oraz sposób komunikacji terminu.
Wczesne zaangażowanie Tech Leada nie oznacza udziału w każdym spotkaniu. Powinien pojawić się wtedy, gdy nadal można zmienić zakres, sposób rozwiązania albo kolejność prac.
Pytania, które warto zadać przed przygotowaniem finalnych makiet
- Czy organizacja posiada już dane lub komponenty, które można wykorzystać?
- Jakie systemy i zespoły obejmie zmiana?
- Gdzie znajduje się największa niewiadoma techniczna?
- Czy termin wynika z realnego ograniczenia biznesowego?
- Czy pełne rozwiązanie jest potrzebne od pierwszego wdrożenia?
- Jak można zweryfikować założenie mniejszym kosztem?
Wniosek: zaproś Tech Leada, gdy nadal można zmienić problem, zakres i koncepcję rozwiązania. Nie czekaj do momentu, w którym potrzebujesz wyłącznie estymacji.
Kto powinien mówić „nie” biznesowi?
Ani Product Manager, ani Tech Lead nie powinni mówić biznesowi „nie” w pojedynkę. Tech Lead może wyjaśnić, że rozwiązanie jest niewykonalne w oczekiwanym terminie. Product Manager może uznać, że inicjatywa nie ma wystarczającej wartości. W obu przypadkach samo „nie” rzadko zamyka temat. Interesariusz nadal ma problem, który próbuje rozwiązać. Jeżeli zespół odpowie jedynie odmową, presja prawdopodobnie wróci w innej formie — często z wyższego poziomu organizacji i z jeszcze krótszym terminem.
Dojrzałe „nie” nie kończy rozmowy. Pokazuje cel, ograniczenie, konsekwencję oraz realną alternatywę.
01CelNazwij rezultat, którego potrzebuje biznes. Nie sprowadzaj rozmowy wyłącznie do funkcji lub daty. | 02OgraniczenieWskaż konkretną zależność, brak capacity, niepewność lub ryzyko techniczne. |
03KonsekwencjaPokaż, jaki cel zostanie przesunięty albo jakie ryzyko wzrośnie po przyjęciu nowej inicjatywy. | 04AlternatywaZaproponuj mniejszy zakres, etapowanie, eksperyment albo inną drogę do osiągnięcia celu. |
Jak może brzmieć odpowiedź?
Zamiast: „Nie dowieziemy tego do końca kwartału”.
Lepiej: „Pełny zakres wymaga przebudowy procesu w trzech systemach i nie zmieści się w tym kwartale bez zatrzymania migracji. Możemy jednak przed kampanią wdrożyć uproszczony wariant dla najważniejszego segmentu klientów, a pozostałą część dostarczyć w kolejnym etapie”.
Product Manager wnosi do tej rozmowy wiedzę o wartości i priorytetach. Tech Lead dostarcza argumenty dotyczące wykonalności i ryzyka. Dopiero połączenie obu perspektyw pozwala prowadzić negocjacje zamiast jedynie odrzucać oczekiwania.
„Nie mogę wrócić do biznesu i powiedzieć: nie, bo nie. Muszę wiedzieć, wokół czego możemy się poruszać”.
Najbardziej niebezpieczna sytuacja powstaje wtedy, gdy obie role mówią „tak”. PM nie chce rozczarować interesariuszy, a Tech Lead deklaruje termin bez rozmowy z zespołem. Krótkoterminowo biznes jest zadowolony. Później pojawiają się opóźnienia, błędy, praca po godzinach i utrata zaufania.
Wniosek: nie pytajcie, kto ma odmówić. Ustalcie wspólne stanowisko: co jest możliwe, jakim kosztem i jaka alternatywa najlepiej chroni cel biznesowy.
Jak rozmawiać o terminach i estymacji?
Estymacja nie jest deklaracją Product Managera ani osobistą obietnicą Tech Leada. Jest informacją o przewidywanym koszcie realizacji przy określonym poziomie wiedzy. Jeżeli biznes narzuca termin, zespół musi zarządzić trzema zmiennymi: zakresem, dostępnym capacity oraz poziomem ryzyka i jakości. Termin może pozostać stały, ale wtedy zakres powinien podlegać negocjacji.
Termin
Czy data wynika z regulacji, kampanii, umowy czy wyłącznie z oczekiwania?
Zakres
Które elementy są niezbędne do uzyskania efektu, a które mogą poczekać?
Capacity i ryzyko
Jakie inne zobowiązania ma zespół i jaki poziom niepewności zawiera inicjatywa?
Jak zmienić estymację w narzędzie decyzyjne?
Zamiast pytać wyłącznie „ile to potrwa?”, Product Manager i Tech Lead powinni wspólnie odpowiedzieć na pytania:
- Jaka część rozwiązania dostarcza największą wartość?
- Które elementy są niezbędne do osiągnięcia celu?
- Jakie założenia są nadal niepotwierdzone?
- Co może opóźnić delivery?
- Co świadomie przesuniemy, jeżeli rozpoczniemy tę inicjatywę?
- Jaką decyzję podejmiemy po zdobyciu dodatkowych danych?
Załóżmy, że zespół otrzymuje prośbę o rozbudowę panelu klienta przed wejściem nowych regulacji. Zamiast estymować cały pomysł jako jeden pakiet, może podzielić go na obowiązkowe zmiany regulacyjne, funkcje operacyjne i dodatkowe usprawnienia UX. Dzięki temu termin prawny zostaje zabezpieczony, a mniej krytyczne elementy nie blokują całości.
Przewidywalność delivery nie oznacza, że termin nigdy się nie zmieni. Oznacza, że ryzyka są widoczne, decyzje podejmowane świadomie, a interesariusze nie dowiadują się o problemie w ostatnim tygodniu projektu.
Wniosek: estymujcie warianty i konsekwencje, nie tylko liczbę dni. Dobra estymacja pomaga wybrać zakres, a nie wyłącznie obiecać datę.
Jak chronić zespół przed context switchingiem?
Tech Lead pełni ważną funkcję filtra informacyjnego. Nie dlatego, że zespół nie powinien znać strategii, ale dlatego, że nie każda przyszła inicjatywa wymaga natychmiastowego zaangażowania całego zespołu. Product Manager może jednego dnia rozmawiać o bieżącym sprincie, planie kolejnego kwartału i wizji produktu na dwa lata. Gdy wszystkie te wątki trafiają bezpośrednio do developerów, rozpoczyna się analiza problemów, które nie są jeszcze gotowe do realizacji. Zaangażowany zespół zacznie szukać przypadków brzegowych, oceniać zależności i przewidywać problemy. To wartościowe zachowanie, ale uruchomione za wcześnie prowadzi do context switchingu i odciąga uwagę od aktualnego celu.
| Poziom | Kto powinien uczestniczyć? | Cel komunikacji |
|---|---|---|
| Strategia | Cały zespół na odpowiednim poziomie szczegółowości | Zrozumienie kierunku produktu i przyszłych problemów |
| Discovery | PM, Tech Lead, UX, analityka i wybrani eksperci | Weryfikacja założeń i identyfikacja ryzyka |
| Delivery | Cały zespół realizacyjny | Koncentracja na uzgodnionym celu i zakresie |
W praktyce PM i Tech Lead mogą omawiać wczesne pomysły podczas regularnego spotkania one-to-one. Dopiero gdy temat osiągnie odpowiedni poziom dojrzałości, zapraszają do rozmowy UX, analitykę lub wybranych developerów.
„Jeżeli wszystko spadałoby na zespół, zamiast skupiać się na bieżącym celu, głowy wychodziłyby już w następny kwartał”.
Jak ograniczyć zmianę kontekstu?
- ustal regularny rytm rozmów PM–Tech Lead,
- oddzielaj informowanie o strategii od angażowania w analizę,
- nie wrzucaj luźnych pomysłów bez określenia ich statusu,
- ograniczaj liczbę równoległych inicjatyw,
- każdą pilną zmianę łącz z jawną decyzją o przesunięciu innej pracy,
- chroń czas zespołu na realizację aktualnego celu.
Wniosek: nie ukrywaj strategii przed zespołem, ale rozdzielaj informowanie od angażowania. Każdy temat powinien trafić do odpowiednich osób we właściwym momencie.
Jak budować zaufanie między PM-em, Tech Leadem i zespołem?
Zaufanie w zespole nie powstaje dzięki dobrej atmosferze. Powstaje, gdy zachowanie obu stron jest przewidywalne również pod presją.
Zespół ufa Product Managerowi, gdy PM:
| Product Manager ufa Tech Leadowi, gdy Tech Lead:
|
Zacznij od jawnych zasad współpracy
Na początku współpracy warto stworzyć prostą macierz odpowiedzialności. Nie musi być rozbudowanym dokumentem RACI obejmującym każdy proces. Powinna odpowiadać na praktyczne pytania:
- Kto podejmuje decyzję o priorytecie?
- Kto zatwierdza kierunek techniczny?
- Kto komunikuje zmianę terminu?
- Kto reprezentuje zespół przed interesariuszami?
- Kiedy decyzja wymaga wspólnego uzgodnienia?
- Jak eskalowany jest spór, którego nie można rozwiązać w duecie?
Trzy fundamenty zaufania: jawne zasady odpowiedzialności, stały rytm komunikacji oraz szybkie wyjaśnianie nieporozumień.
Drugim elementem jest wspólny rytm pracy: regularne rozmowy PM–Tech Lead, refinementy z zespołem, kwartalne przedstawienie celów oraz dokumentowanie najważniejszych ustaleń.
Trzecim jest otwarta komunikacja. Jeżeli sposób sformułowania wiadomości naruszył czyjąś granicę, lepiej wyjaśnić to od razu niż przez kilka tygodni interpretować intencje drugiej strony.
Zaufanie nie wyklucza konfliktu. Pozwala przejść przez konflikt bez utraty zdolności do współpracy.
Wniosek: buduj zaufanie poprzez powtarzalne zachowania, jasne decyzje i szybkie wyjaśnianie napięć, a nie poprzez deklaracje o dobrej współpracy.
Jakich błędów powinny unikać obie role?
PM przyjmuje każde oczekiwaniePresja zostaje przeniesiona na zespół, backlog rośnie, a priorytety tracą znaczenie. Rolą PM-a nie jest maksymalizowanie liczby zaakceptowanych próśb, lecz wartości osiąganej przy ograniczonych zasobach. | PM projektuje rozwiązanie techniczneZnajomość technologii pomaga zadawać lepsze pytania, ale nie daje mandatu do narzucania implementacji. „Wystarczy dodać jeden warunek” zwykle pomija zależności, testy, monitoring i obsługę błędów. |
Tech Lead automatycznie blokuje pomysłyOdpowiedź „nie da się” bez argumentów zostawia PM-a bez możliwości prowadzenia rozmowy z biznesem. Lider techniczny powinien pomagać znaleźć wykonalną drogę do celu. | Tech Lead obiecuje bez konsultacjiDeklaracja zakresu i terminu bez sprawdzenia capacity może zadowolić interesariuszy na jednym spotkaniu, ale koszt poniesie zespół i kolejne inicjatywy. |
Wspólny błąd: bronienie własnego obszaru zamiast celu
Gdy PM broni zakresu, a Tech Lead capacity, rozmowa szybko zmienia się w negocjacje pomiędzy dwiema stronami. Tymczasem obie role powinny bronić tego samego: osiągnięcia celu w sposób, który nie destabilizuje produktu i zespołu.
Wniosek: oceniaj zachowania nie przez pryzmat tego, czy wzmacniają pozycję danej roli, lecz czy zwiększają szansę na osiągnięcie celu bez ukrywania kosztów.
Jak zwiększyć przewidywalność delivery?
Przewidywalność delivery nie zaczyna się od dokładniejszej estymacji. Zaczyna się od jakości decyzji podejmowanych przed rozpoczęciem prac.
Jeden wspólny cel
Zespół powinien wiedzieć, jaki rezultat ma osiągnąć. Cel pomaga podejmować decyzje, gdy trzeba zmniejszyć zakres.
Wczesna identyfikacja ryzyka
Zależności, techniczne niewiadome i ograniczenia danych powinny być omawiane przed deklaracją terminu.
Jawna zmiana priorytetów
Każdy pilny temat powinien mieć koszt alternatywny. Należy wskazać, co zostanie przesunięte.
Dokumentowanie ustaleń
Krótki zapis po refinemencie ogranicza spory o to, co zostało uzgodnione i jakie ryzyko zaakceptowano.
Możliwość wzajemnego zastępstwa
PM i Tech Lead powinni znać kontekst na tyle dobrze, aby reprezentować wspólne ustalenia podczas urlopu, choroby lub krytycznego wdrożenia.
Dobra współpraca Product Managera i Tech Leada nie gwarantuje, że wszystkie projekty zakończą się zgodnie z pierwotnym planem. Gwarantuje jednak, że problemy nie będą ukrywane, a zmiany nie zaskoczą biznesu w ostatnim momencie.
Wniosek: przewidywalność buduje się przez przejrzyste decyzje, ograniczenie liczby rozpoczętych tematów i wczesne zarządzanie ryzykiem, a nie przez nacisk na bardziej stanowcze obietnice.
Model współpracy PM–Tech Lead w pięciu krokach
Najważniejsza zasada: PM i Tech Lead nie muszą zgadzać się od początku. Muszą jednak korzystać z jednego procesu dochodzenia do decyzji.
- Najpierw problem. PM wyjaśnia, kto ma problem, jaki jest jego koszt i dlaczego warto zająć się nim teraz.
- Następnie ograniczenia. Tech Lead wskazuje zależności, ryzyko i techniczne niewiadome bez narzucania od razu finalnego rozwiązania.
- Później warianty. Duet porównuje pełny zakres, rozwiązanie etapowe, eksperyment i rezygnację z inicjatywy.
- Jawna decyzja. Zespół wie, co realizuje, czego nie realizuje i jakie ryzyko zostało zaakceptowane.
- Wspólna komunikacja. PM i Tech Lead przedstawiają interesariuszom jedno stanowisko oraz te same konsekwencje.
Efekt biznesowy tego modelu
Mniej niespodziewanych opóźnień, mniej przypadkowych wrzutek, większa kontrola nad capacity i bardziej wiarygodna komunikacja delivery do zarządu oraz interesariuszy.
Najważniejsze wnioski
- Product Manager i Tech Lead nie powinni działać jak dwa konkurencyjne ośrodki decyzyjne.
- Product Manager odpowiada za problem, wartość i priorytety, a Tech Lead za wykonalność, ryzyko i sposób realizacji.
- Zakres, termin oraz poziom ryzyka wymagają wspólnej decyzji.
- Tech Lead powinien zostać zaangażowany przed zatwierdzeniem rozwiązania i zbudowaniem oczekiwań biznesu.
- Dojrzałe „nie” zawiera cel, ograniczenie, konsekwencję i alternatywę.
- Estymacja powinna wspierać wybór wariantu, a nie służyć wyłącznie do potwierdzania daty.
- Ochrona zespołu przed context switchingiem wymaga zarządzania momentem i poziomem szczegółowości komunikacji.
- Zaufanie powstaje dzięki przewidywalnym zachowaniom obu stron, zwłaszcza podczas presji i zmiany priorytetów.
- Przewidywalność delivery zależy bardziej od jakości decyzji niż od pozornej dokładności estymacji.
Podsumowanie
Product Manager i Tech Lead nie stoją po dwóch stronach barykady. Stoją po tej samej stronie problemu, ale widzą inne rodzaje ryzyka. PM widzi ryzyko utraty wartości, niedotrzymania zobowiązań wobec rynku lub pominięcia potrzeby użytkownika. Tech Lead widzi ryzyko techniczne, przeciążenie zespołu, zależności i konsekwencje skrótów podejmowanych pod presją. Organizacja traci przewidywalność nie dlatego, że role częściowo się nakładają. Traci ją wtedy, gdy te dwa rodzaje ryzyka są analizowane osobno, a decyzja powstaje bez wspólnej odpowiedzialności.
Dojrzały duet PM–Tech Lead potrafi:
- wcześnie włączyć perspektywę techniczną,
- oddzielić cel od pierwszego pomysłu na rozwiązanie,
- negocjować zakres zamiast ukrywać ryzyko,
- chronić zespół przed nadmiarem tematów,
- przekazywać biznesowi argumenty i alternatywy,
- szybko wyjaśniać nieporozumienia,
- mówić jednym głosem po podjęciu decyzji.
Ostatecznie nie chodzi o to, kto dowodzi. Chodzi o to, czy Product Management i Engineering Management tworzą jeden system podejmowania decyzji, czy dwa konkurencyjne ośrodki odpowiedzialności.
