Zdarzyło Ci się kiedyś robić product review, poprosić o feedback, ale w głębi duszy liczyć, że wszyscy tylko pokiwają głową i powiedzą „super, jedziemy dalej”?
Mi tak 🙈.
To jedna z najbardziej podstępnych pułapek w pracy PM-a: zamiast szczerego feedbacku, szukamy akceptacji. Szczególnie wtedy, gdy jesteśmy już „za pięć dwunasta”, tuż przed sprintem albo deadlinem.
W tym newsletterze mój „HOT TAKE” w tym temacie:
1. Po co robisz review produktu? Szukasz feedbacku, czy potwierdzenia?
Jako Head of Product, regularnie spotykałem się z moimi PM-ami na różne formy Product Review. Często wychodziło to z inicjatywy samego PMa, mieliśmy też naturalne punkty review na naszych syncach i dedykowanych spotkaniach 1-1.
Przychodził do mnie taki PM, zwykle dzień przed deadlinem albo startem sprintu, z którym zespół będzie już pracował nad implementacją, z niemal gotowym rozwiązaniem i rzucał: „Tomek, rzucisz okiem? Potrzebuję feedbacku”.
No to rzucałem. I mówiłem szczerze:
„Fajnie, ale czy to na pewno rozwiązuje problem, który zdefiniowaliśmy na początku?”
„Ten flow wydaje się przekombinowany, użytkownik się w tym pogubi.”
„A co z ryzykami, o których gadaliśmy? Mam wrażenie, że je zignorowaliśmy.”
Reakcja? Miks rozczarowania i lekkiej irytacji, grzeczne „No tak, to ma sens, ale…” i potem mocne BRONIENI swojego pomysłu.
No ale w sumie, jaka może być inne reakcja, jak właściwie nie ma już czasu na większe poprawki?
Teraz z perspektywy czasu widzę, że jako PMowie w takiej sytuacji tak naprawdę nie przychodzimy po feedback. Przychodzimy po potwierdzenie naszego pomysłu (+oklaski). Tak naprawdę chcemy usłyszeć: „Stary, świetna robota, robimy i deployujemy to!”.
2. Moje grzechy - sam też wpadałem w tę pułapkę
Najgorsze? Jak sięgam pamiętam - ja też często robiłem dokładnie to samo :P.
Prezentacja dla zarządu? Niby prosiłem o uwagi, ale w głębi duszy liczyłem na zielone światło.
Sprint Review? Bardziej DEMO i pokazanie „ile zrobiliśmy”, niż realna sesja feedbackowa.
Warsztat z interesariuszami? Zamiast otwartej dyskusji nad problemem, gotowe slajd z tezą: „To jest najlepsze rozwiązanie”.
Włożyłem w coś tygodnie pracy, zaangażowałem się emocjonalnie. Ostatnie, czego chciałem, to usłyszeć, że cała ta koncepcja jest do bani.
Brzmi znajomo? No właśnie.
3. Syndrom „szukania potwierdzenia"
To zjawisko nazywam syndromem „szukania potwierdzenia" za pięć dwunasta. Im bliżej deadline'u, tym bardziej nasza potrzeba uzyskania szczerego feedbacku spada, a rośnie POTRZEBA AKCEPTACJI.
Dlaczego tak się dzieje?
Inwestycja emocjonalna i czasowa: Włożyłeś w projekt serce, czas i energię. Podważenie go na finiszu boli jak cholera. To jak usłyszeć, że maraton, który właśnie kończysz, biegłeś w złą stronę i Twój czas się nie liczy. No nie chciałbym tego usłyszeć jak biegłem swój pierwszy w Lizbonie :P.
Brak przestrzeni na zmiany: Co z tego, że feedback jest trafny, skoro nie masz już czasu, budżetu ani mocy przerobowych, żeby wprowadzić fundamentalne zmiany? Szczera krytyka staje się wtedy bezużyteczna i tylko frustruje.
Strach przed oceną: Na ostatniej prostej feedback przestaje być sposobem na rozwój/poprawę, a zaczyna być odbierany jako ocena Twojej pracy. Twoich kompetencji. A nikt nie lubi czuć się oceniany negatywnie.
Agile'owa hipokryzja: Mówimy często swoim zespołom i interesariuszom o budowaniu przyrostowym, o MVP, o szybkiej walidacji z rynkiem. A jak przychodzi co do czego, to własną pracę (np. nową strategię, duży feature) "waterfallowo" dopieszczamy w ukryciu przez tygodnie, by na końcu pokazać gotowca. Gdzie tu iteracyjność i wczesne zbieranie feedbacku?
Prawda jest brutalna: prosząc o feedback na ostatnią chwilę, tak naprawdę prosisz o AKCEPTACJĘ. Mówisz:
„Proszę, powiedz mi, że wszystko jest OK, bo i tak nic już nie mogę zmienić”.
A przecież Twoim zadaniem NIE jest MIEĆ ZAWSZE RACJĘ, tylko ZWIĘKSZYĆ PEWNOŚĆ, że robimy najlepsze rozwiązanie.
To się wiąże z tym, że potrzebujesz pętli zwrotnej - jak najszybciej. Bo to ona pomoże Ci to najlepsze rozwiązanie znaleźć i dopracować. To nie jest proste. Sam tego doświadczałem i, szczerze mówiąc, cały czas podświadomie walczę z chęcią unikania krytyki.
4. Jak sobie z tym radzić?
Jak sobie z tym radzić, skoro to takie trudne? Też cały czas czuję ten lekki strach przed krytyką. To normalne, ludzkie. Ale zamiast z tym walczyć, nauczyłem się to po swojemu „hackować”:
1️⃣ Wplatam feedback w proces od samego początku - nie traktuję go jako opcjonalnego dodatku na koniec, ale jako obowiązkowy element Twojej pracy.
2️⃣ Blokuję z góry czas w kalendarzu na feedback - już na starcie prac nad nowym pomysłem, umawiam spotkania z kluczowymi interesariuszami, zespołem czy przełożonym (np. w połowie). W każdych większych inicjatywach mam od razu wbite odpowiednio wcześniej np. Problem Review, Solution Direction Review i Delivery Review.
3️⃣ Tworzę zobowiązanie, od którego nie ucieknę - kiedy spotkanie jest w kalendarzu, trudniej jest je odwołać i powiedzieć "jeszcze nie jestem gotowy". To publiczne zobowiązanie zmusza Cię do pokazania pracy, nawet jeśli jest niedoskonała. I właśnie o to chodzi!
4️⃣ Wprost nazwam jaka jest moja intencja Review - np. „Chcę usłyszeć, co tu jest ryzykowne, nie czy to się podoba”. To ustawia rozmowę w tryb „de-risking”, nie „oceny”.
5️⃣ Robię z tego rytuał zespołowy - gdy review jest normą w teamie, przestaje być „personalne”. To po prostu część pracy, tak jak developerzy mają “code review”.
I to działa. Po pierwsze - na start łatwiej mi się przemóc z zaplanowaniem takich review (nie czuje jeszcze takiej presji). Po drugie - mam większe poczucie bezpieczeństwa, że nie idziemy w ślepy zaułek. Po trzecie - szybciej buduję zaufanie z zespołem i stakeholderami, bo oni widzą, że ich głos realnie wpływa na kierunek.
Fun fact: 8 na 10 osób, które czytają ten post, nie są jeszcze subskrybentami ProductCraft. Nie przegap kolejnego materiału o budowaniu produktów 10x szybciej, mądrzej i z większym impaktem - zasubskrybuj teraz ⤵️
5. Kiedy i jak robić Product Review (żeby to miało sens)?
Jak robić Product Review dobrze? Złota zasada jest prosta: pytaj wcześnie i często.
-
5.1. Etap 1: Koncepcja / Problem
Masz tylko zarys pomysłu. Kilka notatek z discovery, może 2–3 rozmowy z klientami, czasem pojedynczy insight z danych. Nic jeszcze nie jest zaprojektowane.
🎯 Cel review: upewnić się, że atakujesz właściwy problem i że nie ma fundamentalnych dziur w Twoich założeniach.
O co warto pytać: | Czego unikać: |
|---|---|
✅ Czy to jest realny i palący problem dla naszych userów? | ❌ „Myślisz, że to fajny pomysł?” |
✅ Jakie są największe ryzyka i niewiadome w tym pomyśle? | ❌ „Czy powinniśmy to robić?” |
✅ Czy na pewno dobrze rozumiemy sedno tego problemu? | ❌ „Które rozwiązanie brzmi lepiej?” |
✅ Jakie kierunku warto rozważyć w tym obszarze? |
📕Produktowe artefkaty, które pomagają: Problem statement (1–2 zdania), Oportunituy Brief, Lista założeń, Pierwsze zebrane insighty
-
5.2. Etap 2: Masz już obrany kierunek
Masz już wstępne kierunki rozwiązania, skłaniasz się do jakiegoś kierunku. Mogą to być szkice, makiety low-fi w Figmie, user flow w Miro. Jeszcze nie PRD, ale pierwsze „jak mogłoby to działać”.
🎯 Cel review: sprawdzić argumentacje na temat założeń i kierunku rozwiązania, zanim zespół włoży w realizację duży wysiłek.
O co warto pytać: | Czego unikać: |
|---|---|
✅ Czy ten kierunek wydaje się logiczny? | ❌ „Podoba Ci się to rozwiązanie?” |
✅ Jakie edge cases mogą się tu pojawić? | ❌ „Podoba Ci się ten design?” |
✅ Co w tym flow jest najbardziej niejasne lub skomplikowane? | ❌ „Co byś dodał jeszcze do tego flow?” |
✅ Jakie inne drogi moglibyśmy obrać, by rozwiązać ten problem? | ❌ „To jest najlepsze, prawda?” |
✅ Jak bardzo jesteście pewnie naszej argumentacji dotyczącej założeń / hipotez. |
📕Produktowe artefakty, które pomagają: Inisghty z badań, Mapowanie założeń produktowych i ocena niepewności produktowej, Proste prototypy, User flow z główną ścieżką.
-
5.3. Etap 3: Dopracowane rozwiązanie
Masz już PRD, hi-fi prototyp albo szczegółowy design. Zespół jest blisko developmentu, czasem wręcz przed startem sprintu.
🎯 Cel review: wyłapać błędy w rozwiązaniu, uprościć delivery/testy rozwiązania, zredukować ryzyka związane z rozwiązaniem.
O co warto pytać: | Czego unikać: |
|---|---|
✅ Jak możemy to uprościć, żeby dowieźć wartość szybciej (MVP)? | ❌ „Wszystko jasne, prawda?” |
✅ Co powinniśmy najpierw przetestować z rozwiązania? | ❌ „To co, deployujemy w przyszłym tygodniu?” |
✅ Czy coś w tym rozwiązaniu jest niejasne? | ❌ To już nie czas na zmiany!” |
✅ Jak powinniśmy mierzyć sukces po wdrożeniu? | ❌ „Zróbmy to szybko, najwyżej poprawimy potem” |
✅ Na co powinniśmy uważać? |
📕Produktowe artefakty, które pomagają: PRD (1–2 strony, nie 20), Hi-fi prototyp, Plan rollout + metryki sukcesu.
6. Zrób sobie rachunek sumienia
Na koniec mam dla Ciebie małe wyzwanie. Zastanów się:
Kiedy ostatnio prosiłeś/aś o feedback? Czy naprawdę chciałeś/aś usłyszeć szczerą opinię, czy po cichu liczyłeś/aś na zielone światło i poklepanie po plecach?
Odpowiedź zostaw dla siebie. Ale jeśli czujesz, że coś jest na rzeczy, następnym razem spróbuj zrobić product review już na etapie koncepcji. Zobaczysz, jaka to różnica.