Jeśli lubisz globalne wyzwania i pracę na dużej skali, to jest fajna szansa dla Ciebie.

eService to lider rynku w Polsce, będący częścią amerykańskiej grupy Global Payments (Fortune 500). To praca w organizacji tworzącej kluczową infrastrukturę płatniczą. Otoczenie charakteryzuje się stabilnością i koniecznością dbania o systemy przetwarzające miliony transakcji dziennie, przy wsparciu globalnego know-how.

JOB ALERT: Product Manager - eService - Payments (POS / eCommerce)

Dwa obszary: eCommerce & terminale POS.

Zadania:

• Zarządzanie roadmapą dojrzałego produktu.

• Optymalizacja procesów.

• Tworzenie dokumentacji produktowej.

Wymagania i doświadczenie:

• Poziom Regular (min. 2-3 lata).

• Warsztat PM-a.

• Analityczne myślenie i umiejętność komunikacji z działami nietechnicznymi (Sprzedaż).

• Angielski (min. B2).

Oferta: Zatrudnienie: Umowa o Pracę (UoP). Pakiet: Standard korporacyjny (opieka medyczna, ubezpieczenie, szkolenia).

Link do aplikacji https://www.linkedin.com/jobs/view/4344950083

/

Revolut robi to inaczej. Nik Storonsky, CEO Revoluta, mówi wprost: Porażka to koszt prowadzenia biznesu.

W rozmowie z Harrym Stebbingsem dla podcastu 20VC (”What Revolut Needs to Do to Hit $100BN Valuation”, 2024) Storonsky szczegółowo opisał, jak jeden z najszybciej rosnących FinTechów na świecie zarządza ryzykiem innowacji, godząc się na stratę 18 milionów funtów, żeby zarobić miliardy.

Główna Teza: pracujemy na Betach

W innowacji nie ma pewności. Są tylko zakłady (Bets).

Spójrz na tę tabelę. To klasyka “Moneyball” – analiza sportowa. Mamy tu wynik Oczekiwany (Expected) vs Rzeczywisty (Actual).

(Tu wstawiasz tabelę z PDF: Rans San / WIN / EXPECTED vs ACTUAL)

Wydaje nam się, że jeśli mamy świetne dane, research i zespół, to sukces jest gwarantowany. Guzik prawda. Tak jak w zakładach sportowych, możesz mieć najlepszy model, ale ostateczny wynik weryfikuje “boisko” (rynek).

Dlatego najlepsi (jak Revolut) nie udają, że wiedzą wszystko. Oni budują system, który pozwala im obstawiać wiele zakładów i szybko ciąć straty, gdy “rzeczywistość” (Actual) rozjeżdża się z “oczekiwaniami” (Expected).

Statystyka sukcesu w Revolucie (Realne Dane)

Model operacyjny Revoluta – jak opisał go Storonsky w rozmowie z Harrym Stebbingsem – opiera się na brutalnej statystyce:

🔴 20% – NIETRAFIONE (Totalne klapy - UBIJANIE).
🟡 60% – ROKUJĄCE (Dowożą wartość, ale bez fajerwerków).
🟢 20% – SUPER TRAFY (To one finansują resztę i napędzają wykładniczy wzrost - ROZWIJANE 💸).

Źródło: Nik Storonsky, “What Revolut Needs to Do to Hit $100BN Valuation”, 20VC with Harry Stebbings, 2024 (

)

Jeśli Twoja strategia zakłada, że 100% projektów się uda – to oszukujesz sam siebie.

1. Czym jest “Bet” w skali Revoluta?

Dla Nika Storonsky’ego “Bet” to nie jest task w Jirze. To niezależna firma w firmie.

Zespół: Mały, autonomiczny (ok. 10 osób). Budżet: 2-3 miliony funtów. Czas: 12-18 miesięcy na weryfikację.

To pokazuje skalę globalnego gracza. Ale mechanizm jest uniwersalny.

Podobny sposób myślenia zaszczepiam u moich klientów z FinTech, gdzie apetyt na ryzyko jest większy niż w tradycyjnych instytucjach finansowych, ale też bardzo ograniczone zasoby. Dlatego zarządzanie ryzykiem produktowym jest jeszcze istotniejsze.

W mniejszych firmach “Bet” to:

• Zespół 3-5 osób

• Budżet 6-8 tygodni (Shape Up cycle)

• Jasny próg odcięcia: działa/nie działa

Kluczem pozostaje autonomia. Każdy “zakład” biegnie własnym torem.

2. Betting Table: Jak podejmować decyzje w niepewności?

Revolut nie uprawia demokracji. Decyzje o uruchomieniu projektu podejmuje komitet doświadczonych liderów (”Tych, którzy już coś dowieźli”).

Zasady są brutalnie proste:

Wszyscy na TAK? → Wdrażamy. Wszyscy na NIE? → Odrzucamy. Głosy podzielone? → Też wdrażamy.

To jest kluczowa lekcja. Wątpliwości nie zabijają projektu. Liderzy rozumieją, że innowacja jest nieoczywista. Czasem najbardziej kontrowersyjny pomysł staje się tym “Super Trafem” z górnych 20%.

3. Brutalna Weryfikacja: UBIJANIE or ROZWIJANIE

To, co odróżnia Revoluta od korporacji, to nie startowanie projektów, ale ich zabijanie.

Wyniki sprawdzane są bardzo szybko (po 1-4 miesiącach od wdrożenia):

NIETRAFIONE? (Porażka): Projekt jest UBIJANY ☠️. Zespół rozwiązany lub przesunięty. Straty są spisywane w koszty.

ROKUJĄCE? (Średniak): Projekt zostaje, ale nie dostaje nowych zasobów. Utrzymuje go jeden zespół.

SUPER TRAF? (Sukces): Projekt jest ROZWIJANY 💸. Zespół jest skalowany (z jednego robią się dwa lub trzy), budżet rośnie.

To jest Dywersyfikacja Ryzyka w czystej postaci. Jak w portfelu inwestycyjnym.

Wnioski dla Twojej firmy (Shape Up meets Betting)

Obserwując Revoluta i wdrażając podobne podejście u klientów z sektora FinTech, widzę uderzające podobieństwo do metodologii Shape Up:

✅ Projekt = Bet: Traktuj każdą inicjatywę jak zakład z określonym budżetem ryzyka (”Apetyt”).
✅ Betting Table: Decyzje podejmuje wąska grupa liderów, biorąc na siebie odpowiedzialność za ryzyko.
✅ Terminowość: Masz ograniczony czas na weryfikację hipotezy.
✅ Autonomia: Małe zespoły dowożą wynik bez mikrozarządzania.

W FinTech, gdzie zasoby są ograniczone, a regulacje wymagające, ten model jest jeszcze ważniejszy niż w Revolucie. Nie możesz sobie pozwolić na spalenie 18 milionów. Ale możesz spalić 2 miesiące pracy zespołu – jeśli szybko wyciągniesz wnioski i przerzucisz zasoby.

Prawda jest brutalna: Nie możesz mieć 100% pewności, co zadziała. Nikt nie wie.

A kto tak mówi – jest albo głupi, albo kłamie.

Revolut ma świetnych ludzi, ogrom danych i ogromne budżety, prawdopodobnie większe niż Twoja firma.

I co z tego?

20% projektów to totalnie NIETRAFIONE – klapy. 60% to ROKUJĄCE – ledwo się zwracają. Tylko 20% to SUPER TRAFY – game changery.

Różnica między Revolutem a większością firm nie jest w tym, że oni się nie mylą.

Różnica jest w tym, że oni zaakceptowali ten fakt. Nie udają, że da się wszystko przewidzieć. Nie uprawiają propagandy sukcesu. Od razu przyjmują te proporcje 20-60-20 za faktyczny stan w innowacji.

Zarządzają ryzykiem produktowym.

Jedyne co możesz zrobić, to:

→ Obstawiać wiele zakładów jednocześnie → Szybko UBIJAĆ te, które nie działają ☠️ → Masywnie ROZWIJAĆ te, żrą 💸

Revolut stracił 18 milionów funtów szukając przebojów. Ty możesz stracić 3 miesiące pracy zespołu.

Pytanie brzmi: czy masz masz na tyle deteeminacji żeby projekt ubić, kiedy zobaczysz że nie działa?Czy będziesz go ciągnąć kolejne pół roku, “bo szkoda włożonej już roboty”?

Tak buduje się innowacje.

Chcesz wdrożyć u siebie Betting Table i zarządzać ryzykiem jak najlepsi? Pomagam polskim FinTech przejść od roadmap-życzeń do zarządzania portfelem zakładów - napisz na priv tutaj lub na https://www.linkedin.com/in/dawid-jurand-szkie%C5%82ka/?locale=pl_PL

1. Kontekst biznesowy To jest scale-up w czystej postaci. Zapomnij o sterylnych procesach korpo. Firma urosła globalnie, ale struktury wciąż gonią biznes. Booksy potrzebuje kogoś, kto wejdzie w ten chaos i go poukłada, a nie kogoś, kto będzie czekał na instrukcję obsługi stanowiska.

2. O co chodzi w tej roli? Nie aplikujesz do zespołu od “rezerwowania wizyt”. Trafiasz do Financial Services Stream. To strategiczny obszar, bo Booksy chce być kombajnem do zarządzania biznesem, a nie tylko kalendarzem. Twoje podwórko to:

• Booksy Wallet: Miejsce, gdzie salony trzymają i widzą swoje pieniądze (serce ekosystemu).

• New Financial Services: Gift Cards, promocje, lojalność – czyli narzędzia, które mają zwiększać przychód salonów.

3. Misja (co jest do dowiezienia?) Tu nie płacą za samo “zarządzanie backlogiem”. Masz dowieźć wyniki:

• Zaufanie do portfela: Masz sprawić, żeby merchant ufał portfelowi Booksy i dokładnie wiedział, co dzieje się z jego kasą (przejrzystość przepływów).

• Monetyzacja: Masz napędzić adopcję kart podarunkowych i promocji.

• Ochrona zespołu: Masz brać niejasne wymagania biznesowe i zamieniać je w konkretne zadania dla devów, chroniąc ich przed chaosem decyzyjnym.

4. Profil kandydata

• Mindset: “Order from Chaos”. Jeśli wkurza Cię, że coś nie jest opisane w dokumentacji – nie aplikuj. Jeśli lubisz sam tworzyć procesy – to miejsce dla Ciebie.

• Skillset: Fintech/Payments to warunek konieczny. Musisz rozumieć specyfikę płatności. To zbyt wrażliwy obszar, żeby uczyć się go od zera.

• Seniority: Masz być merytorycznym wsparciem dla midów i juniorów.

5. Oferta (konkrety)

• Kasa: 18 000 – 30 000 PLN gross (UoP/B2B).

• Tryb: 100% Remote (Polska, UK, Hiszpania, Portugalia).

Język: Angielski na co dzień (zespół jest międzynarodowy).

Aplikuj, jeśli: Znasz się na płatnościach, szukasz w pełni zdalnej pracy za dobre stawki i kręci Cię budowanie produktów w dynamicznym (czyt. nieułożonym) środowisku.

Aplikuj tutaj: https://apply.workable.com/booksy-1/j/33AD35BC6E/

Jak to zmienić?
Musisz przejść przez 3 fazy: od Mindsetu, przez Przygotowanie, aż po Budowanie i wdrożenia

Etap I. Mindset & zasoby
(Zanim ruszysz z pracą)

1. Zaakceptuj regulacje (Koniec z targowaniem)
Zaprzeczanie, gniew czy targowanie się nie ma sensu. To tylko pożera energię. Potraktuj regulacje jak twarde zasady gry. To Twoja plansza. Wygrywa ten, kto najlepiej zna jej granice i potrafi w nich grać.

2. Zabezpiecz Eksperta (Język Ryzyka) Nie zrobisz tego sam.
Potrzebujesz eksperta (Legal/Compliance) wewnątrz projektu. Jeśli nie masz takiej osoby – musisz ją zdobyć (zatrudnić lub wynająć).
Nie pytaj Zarządu “czy możemy”ale mów językiem faktów:

“Słuchajcie, potrzebuję budżetu na eksperta. Bez tego wchodzimy na minę niewiadomych,
Co nam grozi?

🔴 Ryzyko kar: Błędna ocena to powtarzalne kary (np. po 10 tys. zł każda).
🔴 Ryzyko operacyjne: Blokada działalności.
🔴 Ryzyko wizerunkowe: Łatka firmy, która ignoruje prawo.

Potrzebuję eksperta, który oszacuje prawdopodobieństwo i powie, co jest bezwzględnie do zrobienia.”

3. Zmapujcie wspólnie ryzyka (Macierz)
Zrób spotkanie w salce i użyj prostej macierzy ryzyka. Skup się na ćwiartce “Urgent/High Bloker” – to są rzeczy, które mogą położyć projekt. Resztę (niskie prawdopodobieństwo, niskie straty) zostawiasz na później.

Etap II. Przygotowanie
(Jak układać pracę)

4. Przygotuj Pitch (Konkret)
Zrób benchmark z AI, sam narysuj szkic rozwiązania, nie jest ważny detal ale sprzedanie idei.
Twoje materiały będą doskonałym punktem wyjścia do ustaleń z Tech/CTO, UX Designerem oraz Ekspertem/ Prawnikiem.

5. Włącz Prawnika w Makiety (Shaping) Niech Legal zobaczy flow i makiety na wczesnym etapie. Tak zyska kontekst i zrozumie, co chcesz wdrożyć.
Dzięki temu unikniesz przepalania pracy designera na rozwiązania niezgodne z prawem.

6. Design zgodny z prawem Bycie w zgodzie z regulacjami nie oznacza brzydkiego produktu. Złożone procesy (AML, KYC) można i trzeba ubrać w intuicyjny design. To zadanie dla UX na tym etapie.

Etap III. Budowanie i wdrożenia

7. Zasada dwóch pizz (Mały Zespół) Stwórz autonomiczny, mały zespół.
Jeśli ktoś nie jest niezbędny do dowiezienia projektu – nie zapraszaj go na spotkania. Tłum zabija decyzyjność.

8. Myśl terminem (Deadline to Deadline)
Powtarzaj jak mantrę: “Co musimy i jesteśmy w stanie wdrożyć w Q1?”. Skup się na MVP prawnym i technicznym. Reszta wylatuje z zakresu.
Pamiętaj - “lepsze jest wrogiem dobrego”

9. Bądź “Życzliwym Dyktatorem”
W sprawach regulacyjnych nie ma demokracji. Słuchasz ekspertów, ale to Ty bierzesz odpowiedzialność za decyzję “wdrażamy / nie wdrażamy”.

Plan jest prosty i klarowny dla wszystkich, łącznie z zarządem:

• Teraz: Ekspert ustala, co jest bezwzględnie do zrobienia.

• Q1/Q2: Wdrażamy kluczowe zmiany (60-80% wymogów).

• Q3: Reszta (o ile będzie potrzebna).

Te zasady te wynik moich kilkunastoletnich doświadczeń projektowych w roli PM, Product Advisor i Trenera w branżach FinTech, e commerce i SaaS.

Połączenie metodyki Shape Up z innymi frameworkami oraz wymiany doświadczeń w ramach Product Cafe FinTech Brew z Agnieszką Modras, Aleksandrą Wasilewską, Łukaszem Kucem i Witoldem Siekierzyńskim z 19.11.2025 w Rotundzie PKO BP.

Twój zespół utknął w “paraliżu regulacyjnym”? Jeśli czujesz, że Compliance blokuje Wasz rozwój, a “Time-to-market” leży – pogadajmy. Pomagam firmom FinTech układać procesy tak, by dowoziły innowacje zgodnie z prawem, a nie obok niego.

👉 Napisz do mnie na LinkedIn

1. KONTEKST BIZNESOWY

Booksy to globalny scale-up. Co to znaczy w praktyce? Że firma jest w fazie dynamicznego wzrostu i ekspansji na nowe rynki. Jeśli szukasz powolnej stabilizacji i odtwarzania gotowych procesów – to nie jest miejsce dla Ciebie. To rola dla kogoś, kto potrafi działać elastycznie, układać procesy tak, by nadążały za biznesem i priorytetyzować w niejednoznacznym środowisku.

2. INSIDER

Rekrutacja dotyczy 4 wakatów w obszarze Customer Domain. To kluczowa informacja, bo w zależności od Twoich mocnych stron (Analityka vs UX vs Strategia), możesz trafić do innego “koszyka”:

• Pricing & Monetization: (Raportowanie do Macieja Olbrychta). Rola mocno analityczna, skupiona na modelach przychodowych i optymalizacji cenników.

  

• Search Wyzwanie: jak sprawić, by klient w 3 sekundy znalazł idealnego fryzjera?.

  

• Customer Engagement: Wyzwanie: Loyalty. Jak sprawić, żeby klient wracał do aplikacji?.

  

3. PROFIL KANDYDÓW/KANDYDATEK

Senior, który zjadł zęby na SaaS, Marketplace lub B2B2C. Kluczowe są tu:

• Discovery & Experimentation: Musisz umieć badać i eksperymentować.

• Mindset: Balans między wizją a twardą egzekucją.

• Komunikacja: Zarządzanie interesariuszami i płynny angielski (język firmowy).

5. WARUNKI

• Lokalizacja: Fully Remote (możesz pracować z Polski, Hiszpanii, UK lub Portugalii).

• Benefity: Opieka medyczna (zależna od lokalizacji), Worksmile.

Moja rekomendacja: Aplikuj, jeśli jesteś “budowniczym” i nie boisz się niejednoznaczności. Odpuść, jeśli szukasz korporacyjnego spokoju.

🔗 Link do oficjalnej aplikacji: https://apply.workable.com/booksy-1/j/259D60B5AF/

DS: Co Was/Ciebie frustrowało w poprzednim sposobie pracy, czyli w kanbanie?
Dlaczego chciałeś spróbować Shape Up?

MM: Miałem ciągle wrażenie, że albo mamy zbyt wyatomizwoane zadania i po pewnym czasie zespół przestawał “łączyć kropki” między nimi i pojawiały się zgrzyty, albo zbyt duże, które kończyły się na wielotygodniowym delivery.

Czułem też, że za dużo rzeczy spoczywa wyłącznie na PM-a i zespół skupia się wyłącznie na delivery. Nie zastanowią się po co tworzymy daną funkcjonalność i jak zmieni ona rzeczywistość użytkowników.

Kolejnym poczuciem, które miałem jest to że przy klasycznej pracy w której UX Designer przygotowuje makiety i specyfikacje dla zespołu wcześniej to strata czasu nad czymś co i tak na koniec dnia będzie wielokrotnie zmieniane przy delivery.
(ten kto nie wyshipowal odwrotności zakładanego designu niech pierwszy rzuci kamieniem!)

DS: Czym jest dla Ciebie Shape Up?

MM: Bardzo dobrze napisanym zbiorem dobrych zdroworozsądkowych praktyk. Weźmy na przykład 6 tyg cykle, czemu 6 a nie 7? Bo 6 ‚felt right’ dla autorów, w ich przypadku 6 tyg to maksymalny czas jaki chcą poświęcić na duże, w ich rozumieniu pitch’e. Czy to znaczy że wszyscy powinniśmy pracować w 6 tyg cyklach? -nie! Ale procesy myślowy który każe nam zadać sobie pytanie Ile czasu/budżetu chcemy poświęcić na tą funkcjonalność? jest mega wartościowy.

DS: Jak wdrożyliście Shape Up?
MM: Zacząłem od wytłumaczenia zespołowi i managementu głównych zasad, na jakich opiera się Shape Up, m.in. czym jest budżet (apetyt), betting i kluczowy time-bound projektów.

Zaczęliśmy od przejścia tylko mojego zespołu z kanbana na Shape Up. Wdrażaliśmy go 1:1 zgodnie z książką “Spa Up”, ufając procesowi. Dopiero po dwóch cyklach zaczęliśmy dokonywać zmian.
Równolegle inne zespoły w firmie również zaczęły swój ‚romans’ z różnymi podejściem do Shape up’a. Większości nie przyjęła go jako głównej metodyki. Ale jego elementy jak pitche czy cykle zostało z nimi na dłużej.

DS: Jakie były wrażenia zespołu po pierwszych 2 cyklach, czyli po mniej więcej kwartale?

MM: Pozytywne. Widzieliśmy, że zaangażowanie i ‚fun’ z projektów urósł. Zespół był w stanie dowieść rzeczy w wyznaczonym czasie.

To co dla nas nie zadziałało najlepiej na początku to obsługa bugów i maintenance, klasyczne palenie ich w ramach cooldown w naszym wypadku generowało za dużą ilość ticketów do spalenia zaraz po sprincie więc zespół nie miał czasu na ‚oddech’ między cyklami.

DS: Czy szefostwo zwrócił uwagę na fakt przejścia na Shape Up? Czy nie bardzo, bo nie wchodzi głęboko w sposób pracy zespołu - o ile projekty są wdrażane w kwartale i realizuje się OKRy?

MM: Dostaliśmy duży kredyt zaufania i po czasie pracowaliśmy z managementem aby wpasować 6 tygodniowe cykle w kwartalny rytm życia firmy. Końcowo jeśli byliśmy w stanie określić swoje long termowe metryki i plany to byliśmy również w stanie wpasować projekty plany kwartalne.

Wiadomo pojawiały się w roadmapie funkcjonalność które są pushował zarząd.W takich wypadakchpracowaliśmy mocno nad oczekiwaniami i znajdowaliśmy rozwiązania, których development trwał nie dłużej niż 3 tyg.

Jednocześnie cykle i ich rytm pozwoliło mi osobiscie na częstsze check-iny z nimi i realnie oddanie im w ręce opcji ‚w razie czego mozecie zmienic zdanie 3 razy w kwartale, przed każdym betting table.

DS: Czy zauważyłeś zmianę w jakości dostarczanych rozwiązań po przejściu na Shape Up? Jeśli tak, to jaką?

MM: Tak moja główna obserwacja było to, że zespół zwiększył swoją autonomię. Był w stanie dostarczać rozwiązania lepiej dopasowane do potrzeb userów. Dodatkowo całkowity lead time od ideacji do produkcji skrócił się aż o połowę.

Moim zdaniem pierwsze wynika z tego, że w przypadku Shape up’a odpowiedzialność zespołu to znalezienie rozwiązania problemu w określonym czasie. Dzięki temu widziałem, że od pierwszego dnia był skupiony na prototypowaniu i iterowaniu na żywo. Miał 100% focus na rozwiązaniu core problemu.

Drugie wynika z faktu że zaczynaliśmy, każdy pitch tylko z rough idea designu, developerzy, researcherzy i designerzy pracowali razem. Budując designy krok po kroku. Dzięki temu omijaliśmy całą fazę “czekamy aż designer dowiezie’

DS: Jakie praktyki Shape Up stosujecie obecnie i w jakiej formie? Mam świadomość, że jako framework trzeba dostosować go do realiów firmy.

MM:

• Time-bound - trzymanie się założonego "budżetu" na dany projekt i porzucanie po jego przekroczeniu. Bo nigdy "jeszcze jeden dzień" nie okazuje się tylko jednym dniem.

• Betting table - otwarty dla całego 8-osobowego zespołu. Demokratycznie każdy może się odnieść do pitchu i wyrazić swoją opinię, ale decyduje PM.

• Pitche projekty;

  • są dopasowane i kontrybuują do kwartalnych OKRów

  • rzadko są 6-tyg., raczej 2,3,4-tygodniowe

  • są również refaktoryzacyjne, bywają dla celów refactorowych i wtedy przygotowywane są przez developerów

• Mało spotkań (oprócz tego mamy policy 3 dni bez spotkań)

• Małe zespoły projektowe - nad jednym projektem pracuje 2-3 developerów + PM + UX

DS: Czy tak jak zakłada Shape Up, porzucacie i ewentualnie wracacie do projektów, które z jakichś przyczyn były niewdrażalne w ustalonym terminie?

MM: Tak, potrafimy porzucić projekt i wrócić do niego po jakimś czasie po fazie discovery.
Na początku to bardzo bolało wiadomo, sunk fallacy cost, ale kilkukrotnie udało nam się po ucięciu zakresu wymyślić dużo lepsze podejście w kolejnym cyklu (lub 2 cykle dalej)
Wydaje mi się że w większości wypadków mogło być to spowodowane za dużym scope na początku, którego dobrze nie wycięliśmy z teamem lub zwykłym zmęczeniem materiału przy 6 tygodniowych projektach.

DS: Czy przedłużacie projekty na cool down?
MM: Tak, przy czym muszą spełniać kilka warunków

1. Wszystkie scopes sa albo wycięte albo na koncowce delivery (jesli sa jakies nie zaczęte lub w połowie drogi to no go)

2. Wejście na prod nie wymaga dużej akcji marketingowej / informacyjnej dla klientów (jeśli zrobimy to zaraz przy kolejnym cyklu, możemy mieć za dużo do komunikacji ;) )

DS: Podzieliliście pracę na Discovery i Delivery. Mógłbyś powiedzieć więcej?
MM:

Discovery:

Cel: Obniżenie ryzyka (nie chcemy robić 6 tyg czegoś co nie przyniesie zmian po drugiej stronie), przygotowanie pitchy pod kolejny cykl

Metody: Continuous Discovery habits od T. Torres, spotykamy sie co tydzien i na podstawie opportunities, które rozważamy ustalamy czy:

1. Są gotowe do shape’owania mamy na nie jakieś dowody że mają szansę eg. Gadaliśmy z klientami, zrobiliśmy smoke test etc, zależy co w danym momencie wydaje się najszybsze lub najbardziej skuteczne

2. Jesli nie sa to co musimy zrobic w ciagu nastepnego tygodnia zeby obnizyc ich ryzyko i albo przygotować na kolejny cykl albo całkiem odrzucić

Czas trwania: 6 tygodni równolegle do cyklu delivery

Delivery: cel, metody, czas trwania

Cel dowiezienie wartości dla klienta

Metody: Dzielimy zespół w grupy pod pitch, tam już kanban board

Czas trwania: 6 tyg ale pitche były 3-6 tyg

DS: Jaką rolę w Waszym procesie Shape Up odgrywa prototypowanie? Czy i jak wykorzystujecie prototypy w fazie shaping?

MM: duzo prototypujemy na etapie shapingu ale naprawde low costowo (mamy design system) lub przy użyciu narzędzi low-fi (tak rysujemy czasem na kartkach!) pozwala nam to zobaczyć kilka roznych rozwiazan problemow, jesli uwazamy są niektóre są całkiem spoko, to zakładamy że w delivery zespół będzie w stanie znaleźć coś 10x lepszego. Takie prototypy często uwzględniamy też w samym pitchu podobnie to metody black boardingu z książki.

DS: Jak radzicie sobie z onboardingiem nowych członków zespołu do metodyki Shape Up? Jakie są największe wyzwania?

MM: Shape up wymaga ogólnego doświadczenia w wytwarzaniu oprogramowania 😅 raczej był zaskoczeniem dla każdego developera, przy każdym onboardingu starałem się wyjaśnić podstawowe zasady, a w najbliższym cyklu taka nowa osoba pracowała ze swoim ‘buddy’ zeby nabrac wprawy, nic statystycznego ale powiedziałbym że potrzeba 2-3 cykli żeby poczuć to flow w pełni.

DS: Jak udaje Wam się pogodzić projekty Shape Up z: a) obsługą bugów i maintenanceʼem oraz b) projektami zależnościowymi od innych zespołów? To chyba wyzwanie w dużych korporacjach (wiem po doświadczeniach pracy w Allegro).

MM: Bug / maintenance: tutaj nie trzymaliśmy się założeń z książki, i poświęciliśmy im parę mi. / h dziennie każdego dnia. Dla części mniejszych staraliśmy się je zbierać i ‘palić’ na koniec tygodnia. W przypadku ‘większych rzeczy’ staraliśmy się sprawdzić czy nie nadaja sie przypadkiem na osobny pitch ;)!

DS: Jak wygląda podział (np. 8-osobowego) zespołu - ilu devów zazwyczaj pracuje nad projektami Shape Up, ilu zajmuje się bugami i maintenanceʼem?

MM: 2-3 per pitch w zależności od potrzeb backend/frontend, designer pracujący między pitchami w trakcie cyklu, bugi równolegle. Ale nie mniej niż 2 osoby, nie więcej niż 4.

DS: Czy i jak Shape Up wpłynął na planowanie długoterminowe i roadmap?
Jak godzicie 6-tygodniowe cykle z długoterminową strategią?

MM: W naszym wypadku firma pracuje w cyklach kwartalnych, co daje nam ~2.5 cyklu wew kwartału. Podczas ustalania planów kwartalnych staramy się skupić głównie celach, co daje nam pewną dowolność w delivery, oczywiście zdarzają się projekty które są explicit wymagane w danym kwartale, ale staramy ułożyć wtedy każdy cykl wew shape up’a tak żeby dowoził wyraźną wartość dla każdego z celi. Czyli jeśli w danym Q mamy CVR i aktywację jako główne wskaźniki to każdy cykl będzie atakował oba problemy w oddzielnych pitchach.

Do tego dochodzą nam miesięcznie check-in’y z managementem w których możemy kontrolować wspólnie kierunek i ewentualnie reagować / zmieniać kolejne cykle. Pierwsze spotkanie wypada pod koniec pierwszego cyklu gdzie widzimy zwykle pierwsze efekty / przewidywania i możemy odpowiednio wcześnie reagować, w planowaniu kolejnego, drugie spotkanie wypada na samym początku 2 cyklu co daje nam sanity check i zwykle potwierdzone wyniki z produkcji, trzecie organizujemy bliżej końca kwartału i tam skupiamy się na kolejnych 3 miesiącach.

DS: Jak wygląda u Was proces przepływu informacji zwrotnej (feedback loop) po zakończonych cyklach? Czy i jak wykorzystujecie te informacje w kolejnych iteracjach?

MM: W zależności od projektu zbieramy dane ilościowe lub jakościowe i na ich podstawie oceniamy czy
a) To co zrobiliśmy “działa” -> dowozi wyniki zgodne z naszymi oczekiwaniami na początku cyklu

b) Czy chcemy inwestować więcej w dane opportunity i jeśli tak to w jakim kierunku.

DS: Jakie warunki muszą być spełnione, aby Shape Up przyjął się w danej firmie? Chodzi mi o to, że jak rozmawialiśmy, musimy mieć w firmie np. seniorów developerów, którzy sami będą szukać rozwiązań dopasowanych do założonego czasu i zasobów (budżetu czy apetytu).

MM: Na Pewno ludzie muszą być (w nietoksycznym znaczeniu) przedsiębiorczy, w Shape Up dużo pracy która klasycznie jest zrzucana na PM’a “Potrzebujemy pełnej specyfikacji zanim zaczniemy!”, przechodzi na zespół, więc członkowie muszą być zainteresowani tym w jakiej formie dany projekt zostanie wydany, w jaki sposób rozwiążą postawiony problem w danym czasie, etc., Co moim zdaniem wymaga specyficznego zaangażowania i dojrzałości które najczęściej spotykałem u ludzi “Senior” natomiast to nie tylko kwestia stażu w pisaniu kodu ale mindset w którym jest się zainteresowanym produktem który się tworzy i to ten produkt i problemy stoją na pierwszym miejscu, technologia jest tylko sposobem ich rozwiązania, są programiści którzy mają lub wykształcili to w sobie, i tacy którzy tego nie mają, potrzebujemy obu typów w branży, natomiast w przypadku Shape Up mało rzeczy jest podanych “na tacy” i trzeba mieć w sobie głód budowniczego żeby się tym cieszyć.

DS: Na jakim etapie rozwoju firmy warto rozważyć wdrożenie SU? Mamy chyba podobne zdanie, że generalnie SU nie jest dla startupów będących na etapie problem-solution fit czy szerzej product-market fit. SU sprawdzi się dla skalujących się biznesów, czyli masz już PMF, kasę, zespół seniorów, design system i komponenty. Czy chciałbyś coś dodać?

MM: Agreed :)

DS: Jakie są kluczowe bariery we wdrażaniu Shape Up w makro skali w dużych organizacjach?

MM: Na pewno ogromne koszty czasowe i szkoleniowe związane ze zmianą frameworku np. ze scruma na Shape Up. Dodatkowo bałbym się dużej ilość stakeholders i ogólnie osób zaangażowanych w podejmowanie kluczowych decyzji. W przypadku 37signals wystarczą betting tables składające się z 3-4 osób podejmujących głównie decyzje produktowe na kolejne 6 msc w firmie. W firmach pokroju Docplanner’a czy Allegro wydaje mi się, że takie top down podejście byłoby niemożliwe, natomiast rozdrabnianie tego na betting table of betting table w dół drzewa firmy też wydaje się czasochłonnym procesem co ;) oddala nas od meritum Shape up’a. Long story short Ja bym się nie podejmował to jest sposób pracy stworzony przez firmę z dość małym head count’em i jak oni sami mówią nie wiedzą (i nie chcą) jak rozwiązywać i czy te rozwiązania zadziałałyby w przypadku firm z tysiącami pracowników.

Bonus: Pewnie warto obserwować co będzie się dziać w Shopify, jako, że jeden z founderów 37signals dołączył do boardu, wspominając właśnie o tym, że chciałby zobaczyć jak działa od środka firma tej wielkości.

DS: Nie rozmawialiśmy o UX. Czy funkcjonuje u Was Product Trio (termin od Teresy Torres) i jaka jest jego rola i sposób działania?

MM: Pytanie co rozumiesz przez UX ;) W naszym wypadku dzielimy role na:

Product -> Zwykle PM, czasem ktoś pełniący rolę

Design -> Osoba odpowiedzialna za wizualna część i defacto usage i UX rozwiązania

Research -> Osoba odpowiedzialna za wczesne walidacje (ankiety, wywiady, smoke testy), czasem PM jeśli nie mamy dedykowanej osoby

Data -> Osoba odpowiedzialna za wczesne walidacje + informacje o danych z przeszłości + wyniki po wyjściu na produkcję , czasem PM jeśli nie mamy dedykowanej osoby

W tym składzie spotykamy się co tydzień i pracujemy nad kolejnymi krokami dla danego zespołu, zwykle składa się to na sprawdzenie czy z obecnych rzeczy z walidacji któraś powinna iść do kolejnego cyklu, albo jakie inne akcje chcemy podjąć (zrobić dodatkowy test etc), żeby była gotowa do cyklu.

DS: Czemu Shape Up jest tak mało popularny?

MM:
Pierwsza hipoteza - przez sam Basecamp, który może robić wrażenie, ale z drugiej strony jest dość małą (bo około 50-osobową) firmą i może nie pasować jako benchmark dla np. korporacji.
Druga hipoteza - hegemonia scruma. Firmy wydają miliony na jego wdrożenia. Dodatkowo firmy doradcze z wielkiej czwórki to właśnie warianty scruma rekomendują jako framework agile, w różnych wersjach (SAFe, Scrum of Scrums, and the Spotify model).
Trzecia hipoteza - Shape Up jest trudny wymagający. Zakłada wzięcia dużej odpowiedzialności przez cały zespół. Deklaracja i skupienie się na dowiezieniu działającej funkcjonalności w terminie wymaga dużej dojrzałości ze strony developerów i pozostałych członków zespołu.

DS: W związku z powyższym - czy Shape Up jest bardziej fair i współdzieli odpowiedzialność pomiędzy wszystkich członków zespołu (tj. PM-Dev-UX)? Mam wrażenie, że w pozostałych frameworkach np. scrumie ciężar odpowiedzialności i stresu spada na ramiona PM. Jakie jest Twoje zdanie?

MM: Nie wiem czy jest bardziej fair, ale zgadzam się, że duża ilość firm zrzuca na Product Managera, rolę walidatora designów czy kogoś kto pisze acceptance criteria, co moim zdaniem nie ma większego sensu, designer rozmawiający z klientami o rozwiązaniu zawsze zrobi rozwiązanie x10 lepsze niż PM micro manager, Programiści którzy rozumieją jaki mają cel ich zadania zaprojektują dużo lepszy system niż PM, więc dajmy ludziom robić to w czym są świetni ;)

DS: Czy w dobie AI nawet 2-3 tygodni na development to nie jakiś relikt przeszłości? I ten czas nie powinien być jeszcze krótszy?

MM: Ten czas 2-3 tygodni nie wynika tyle z samego czasu developmentu co ze specyfiki naszej firmy. Jesteśmy firmą międzynarodową, wdrażamy nasze funkcjonalności na różne rynki, dlatego każde wdrożenie wymaga przejścia przez sporo stageʼów. Tego narzędzia AI (no-code) nie przeskoczą. Natomiast w kwestii tego jak szybko możemy iterować i testować różne pomysły wewnętrznie, AI znacznie przyspieszyło naszą pracę i rzeczy które kiedyś zajmowały nam dni, dzisiaj są kwestią niekiedy minut, pozwala nam to dużo szybciej sprawdzić kilka-czasem naście potencjalnych rozwiązań zamiast kilku które zwykle moglibyśmy zrobić, plus wszystkie są dużo bliżej “wersji produkcyjnej” niż nasze dotychczasowe PoCs.

DS: Jakie widzisz połączenie Shape Up i narzędzi AI wspierających zarówno pracę PM podczas fazy discovery oraz developerów i UX podczas delivery? To się uzupełnia czy kłóci?

MM: AI już dzisiaj uzupełnia naszą pracę codziennie, Pomaga nam strukturyzować insighty nowe i sprzed lat, desk research często z kilku godzin czy dni skrócił się do kilku iteracji odpowiedniego prompta. O programowaniu wspomniałem wcześniej ale wszyscy testujemy z dobrymi wynikami różnych asystentów w ramach IDE, i dostarczamy coraz więcej kodu współtworzonego przez modele i naszych programistów

Mat Mikulski - Product Manager z 12-letnim doświadczeniem, od lat związany z Docplanner.com, gdzie jako Lead PM rozwijałem produkty dla pacjentów i lekarzy – używane przez miliony użytkowników. Obecnie koncentruję się na projektach z wykorzystaniem dużych modeli językowych (LLM). Poza tym wspieram mniejsze organizacje jako konsultant, pomagając im budować kulturę i procesy produktowe. Skupiam się na dostarczaniu realnej wartości – od strategii po delivery.

Dawid Jurand Szkiełka - specjalizuje się w transformacji produktowej i skalowaniu organizacji. Skutecznie wdrożył #ShapeUp w Useme.com. Dziś szkoli i wdraża #ShapeUp w innych organizacjach.
Doświadczenie zdobywał w Allegro, Wirtualnej Polsce, Agora i Saatchi & Saatchi.

Partner zarządzający Product Pro.
Członek renomowanego kolektywu Product Cafe.

Łączy #ShapeUp z podejściami jak Lean Startup i Product Discovery. Praktyk zarządzania produktem czerpiący inspiracje ze współczesnej filozofii.

• 2010: Początki w Spotify, Google i Airbnb

• 2014: Airbnb publikuje pierwsze materiały wewnętrzne

• 2017: Marty Cagan opisuje koncept w "Inspired"

• 2019: Teresa Torres w "Continuous Discovery Habits" rozwija temat

• 2019: Ryan Singer i Jason Fried wprowadzają "Shape Up"

Czym właściwie jest Product Trio?
To model efektywnej współpracy PRODUCT MANAGERA, UX DESIGNERA i TECH LEADA (co zbieżne jest z framework Shape Up)

Najważniejsze cechy Product Trio:

🔹 Równość i wzajemny szacunek w zespole (przy zachowaniu leadershipu PM) 🔹 Wymiana unikatowych perspektyw: strategia (PM), technologia (Tech Lead), użyteczność (UX)
🔹 Współodpowiedzialność za terminowość, budżet i osiągnięcie KPI
🔹 Autonomia decyzyjna zespołu

W praktyce Shape Up, już na etapie Pitchu, Product Trio wspólnie pracuje nad:

1️⃣ zdefiniowaniem problemu usera
2️⃣ wypracowaniem rozwiązania problemu
3️⃣ dopasowaniem rozwiązania do budżetu i czasu

💡Kluczowe jest skupienie na problemie/ Zespół ma swobodę w wyborze rozwiązania technicznego (przy uwzględnieniu budżetu i czasu) oraz działa w duchu eksperymentu.

W 2022 w useme.com wdrożyliśmy Shape Up i zauważyliśmy, jak doskonale sprawdza się w środowisku remote dzięki:

• współdzielonym dokumentom (Google Docs) z koncepcjami i decyzjami

• asynchronicznej komunikacji (Slack)

• warsztatom online (Miro)

• cyklicznym Weekly (z demo)

• ad-hocowym spotkaniom online

Korzyści?
✅ dla zespołu: to większe poczucie sprawczości i decyzyjności
✅ dla PM - lepsza kontrola nad projektem i mniej stresu
✅ dla managementu - trzymanie się budżetu i przewidywalność roadmapy

Wdrażasz Shape Up lub zastanawiasz się nad Product Trio w swojej organizacji? Chętnie podzielę się doświadczeniami z useme.com - napisz do mnie!

1. Cechy mentalne i decyzyjne

↳ Samodzielność strategiczna - wybiera właściwe cele i osiąga je bez potrzeby nadzoru
↳ Analityczne myślenie - rozwiązuje problemy poprzez dane i głęboką analizę
↳ Szybkość decyzyjna - podejmuje szybkie decyzje bez przedłużania procesów

2. Orientacja na wyniki
↳ Skupienie na realizacji - koncentruje się na rezultatach, nie na dyskusjach
↳ Efektywność zasobowa - osiąga maksymalne rezultaty przy minimalnych zasobach
↳ Kultura KPI - definiuje mierzalne cele i śledzi postępy
↳ Orientacja na wzrost - tworzy produkty, które szybko się skalują

3. Umiejętności adaptacyjne
↳ Szybka adaptacja - pracuje efektywnie już od pierwszych tygodni
↳ Ciągłe uczenie się - poszerza wiedzę, szczególnie w nowych obszarach
↳ Gotowość do eksperymentów - nie boi się testować i ponosić porażki

4. Umiejętności komunikacyjne i interpersonalne
↳ Efektywna współpraca - współpracuje zamiast wewnętrznie konkurować
↳ Komunikacja oparta na danych - jasno wyjaśnia koncepcje i prezentuje wyniki
↳ Bezpośrednia komunikacja - preferuje jasny język bez zbędnego żargonu

5. Myślenie zorientowane na użytkownika
↳ Projektowanie prostych interfejsów - tworzy przyjazne dla użytkownika rozwiązania przy zachowaniu złożonej funkcjonalności

💡 Ciekawostka: Nick Storonsky uważa zatrudnianie doświadczonych menedżerów wysokiej rangi za błąd. Z około 55 doświadczonych menedżerów zatrudnionych przez headhunterów, zwolnił aż 49-50! Jego zdaniem, doświadczenie i tytuł to za mało - liczy się przede wszystkim faktyczna zdolność do samodzielnego osiągania celów.

Te cechy wyraźnie łączą się z założeniami metodyki Shape Up promowanej przez Basecamp i również przeze mnie. Shape Up również kładzie nacisk na:

• Samodzielność zespołów

• Koncentrację na dostarczaniu konkretnych rezultatów w określonych ramach czasowych i budżecie

• Podejmowanie szybkich, świadomych decyzji

• Efektywne zarządzanie zasobami poprzez precyzyjne "kształtowanie" pracy przed jej rozpoczęciem

• Eksperymentowanie z "zakładami" (bets) na nowe funkcje, podobnie jak Revolut równolegle testuje wiele inicjatyw

Zgadasz się z opinią Nicka?

Jak oni to robią?
1. 6 KPI/celów głównych na rok.
Koncentracja na niewielu, ale kluczowych wskaźnikach
Te cele/KPI są kaskadowane na; działy, zespoły i cele indywidualne.
Każdy zespół, dział i osoba mają swoje wskaźniki KPI do śledzenia postępów.

2. 20+ betów na rok
Revolut prowadzi równolegle około 20+ inicjatyw produktowych.
(w ciągu ostatnich 2,5-3 lat wprowadzili 27 nowych inicjatyw produktowych)
Bet jest wdrażany przez 10 osobowy zespół.

3. Betting - wybór betów
Zespół doświadczonych osób, które wcześniej wprowadziły produkty głosuje na bety.
a. jeśli wszyscy są za - bet jest wdrażany
b. jeśli głosy są podzielone - bet jest też wdrażany
c. jeśli wszyscy są przeciw - bet jest odrzucany

4. Po 1-4 miesięcy od wdrożeniu produktu:
Śledzą wyniki (przychody, wzrost) w pierwszych miesiącach (1-4 miesiące)
a. Dla najlepszych 30-40% produktów znacząco zwiększają zasoby i tworzą dodatkowe zespoły
b. Produkty, które nie wykazują wzrostu, pozostają z minimalnym zespołem
c. Nietrafione produkty - brak wzrostu są ubijane.
Wszystkie wyniki są widoczne w systemie śledzenia z pulpitem pokazującym stan każdej inicjatywy

Dlaczego warto im się przyglądać Revolutowi?
Tempo wzrostu. Revolut obecnie działa na 39 rynkach (10 milionów aktywnych użytkowników). Na 19-20 z tych rynków są liderem rynku.

A opisany model betów pozwala Revolucie na innowacje w tempie startupu,
mimo skali globalnej korporacji.

Zauważyłem, że Revolut ma sporo wspólnych elementów z Shape Up:
✅ każdy projekt traktują jak bet, akceptując porażki
✅ Betting wybór betów
✅ skupienie na terminowość
✅ ma relatywnie małe ale autonomiczne zespoły

A jak wygląda u Ciebie podejmowanie ryzyka produktowego?
I skuteczność betów?

Problem: Zafiksowanie na jednym rozwiązaniu technicznym Już na etapie refinementu skupialiśmy się na konkretnym rozwiązaniu technicznym i analizowaliśmy je ze wszystkich stron. Wierzyliśmy, że dzięki temu precyzyjnie je wycenimy, a to pozwoli nam uniknąć opóźnień. Niestety, nasze estymacje często okazywały się nietrafne. Zadania "puchły", taski wypadały ze sprintów.

I tu pojawia się paradoks - im więcej czasu zainwestowaliśmy w dane rozwiązanie, tym trudniej było nam z niego zrezygnować i otworzyć się na alternatywy. To klasyczny efekt utopionych kosztów, zwany też efektem Concorde'a.

Przełom: Wdrożenie Shape Up Sytuacja zmieniła się, gdy zaczęliśmy stosować praktyki Shape Up:
1️⃣ Pitch - karta projektu skupiona na problemie użytkownika, z jasno określonym czasem i budżetem. Rozwiązania techniczne są w niej tylko zarysowane jako opcje, bez przywiązania do konkretów.
2️⃣ Małe, zwinne zespoły - Product Trio (PM + Tech Lead + UX) szybciej iteruje i znajduje optymalne rozwiązania. Prężne trio, dogadane i skupione na celu, potrafi zdziałać cuda.
3️⃣ Totalny focus na problemie w ustalonym czasie i budżecie - jeśli prostsze i tańsze rozwiązanie adresuje potrzebę użytkownika, wybieramy je zamiast "fetyszyzować technologię".

Przykład z Useme: Status studenta Problem: studenci tracili czas na przesyłanie legitymacji mailowo. Rozważane opcje:
🛠️ Inteligentny uploader rozpoznający datę
🛠️ Prosty uploader + ręczne wpisanie daty
🛠️ Date picker
🛠️ Checkbox z oświadczeniem

Wybraliśmy prosty uploader + date picker. Czemu? Bo dał się wdrożyć w 6-tygodniowym cyklu i adresował problem studentów.

Shape Up dał nam swobodę "żonglowania" rozwiązaniami pod kątem problemu i czasu.

Ale zaraz zapytasz - a co z innowacjami? Przychodzą wraz z rozwiązywaniem realnych problemów użytkowników, nie na siłę.

Jak możesz pomóc swoim zespołom zmienić mindset?
✅ Zachęć do skupienia się na problemie, nie rozwiązaniu
✅ Pomóż otworzyć się na alternatywy, np. przez burze mózgów z Problem-Solution Tree
✅ Daj przyzwolenie na wybór tańszego rozwiązania - uniknięcie efektu Concorde'a
✅Zaproponuj elementy Shape Up, dając zespołom autonomię we wdrożeniu

To wymaga zmiany myślenia, ale jak pokazuje nasz przykład - warto.
Efekt to dostarczanie wartości dla użytkownika terminowo i w budżecie.

Widzisz podobne wyzwania w zespołach - daj znać w komentarzu?
Chcesz wdrożyć Shape up - doradzam jako konsultant.

Jeśli chcecie dowiedzieć się więcej o Shape Up i tym, jak usprawniamy procesy - piszcie śmiało na PRIV, chętnie podzielę się wiedzą.
Doradzę jako konsultant we testowych wdrożeniach Shape Up w firmach.

1. "Working Backwards" - Colin Bryar, Bill Carr

2. "Continuous Discovery Habits" - Teresa Torres

3. "Shape Up" - Ryan Singer

4. "The Pyramid Principle" - Barbara Minto

5. "Zainspirowani” - Marty Cagan

ad. 1. "Working Backwards" - Colin Bryar, Bill Carr Poznasz sprawdzone w Amazonie praktyki jak 6-stronicowe dokumenty czy skupienie na wartości dla klienta. Dowiesz się jak podejmować decyzje produktowe w oparciu o dane i jak budować kulturę odpowiedzialności za rezultaty.

ad.2. "Continuous Discovery Habits" - Teresa Torres Dowiesz się jak skutecznie współpracować w Product Trio (PM+UX+Tech Lead) przy odkrywaniu potrzeb użytkowników. Nauczysz się prowadzić regularne wywiady z użytkownikami i podejmować decyzje produktowe w oparciu o dane, nie opinie.

ad. 3. "Shape Up" - Ryan Singer Poznasz kompletną metodykę pracy nad produktem, od koncepcji po wdrożenie. Zrozumiesz jak pracować w 6-tygodniowych cyklach i jak skutecznie ograniczać zakres projektu, by dostarczać wartość na czas.

ad. 4. "The Pyramid Principle" - Barbara Minto Opanujesz sztukę klarownego komunikowania złożonych koncepcji i tworzenia przekonujących prezentacji. Te umiejętności są niezbędne przy tworzeniu pitchy i przekonywaniu interesariuszy do Twoich pomysłów.

ad. 5. "Zainspirowani" - Marty Cagan Poznasz fundamenty pracy produktowej: jak określać wizję produktu, budować strategię i roadmapę. Nauczysz się jak prowadzić discovery i delivery, oraz jak budować silne zespoły produktowe działające w duchu empowermentu.

Każda z tych pozycji wnosi inną perspektywę i pomoże Ci wdrożyć skuteczne praktyki produktowe. A razem tworzą naprawdę mocny fundament wiedzy o tworzeniu produktów.

Co sądzisz o tych lekturach? Które z nich znasz i polecasz? A może masz swoje typy, których tu zabrakło? Koniecznie daj znać w komentarzu - razem stwórzmy produktową biblioteczkę!

W poprzednich postach pisałem o fundamentach metodyki Shape Up: 6-tyg. cyklach, małych, autonomicznych zespołach i eliminacji zbędnych ceremonii. Dziś omawiam super narzędzie (i moją sekretną broń;) - PITCH.

Czym jest Pitch?
To dokument, w którym przelewasz na papier swój pomysł na projekt. Ale nie chodzi tu o zwykły opis ale kartę projektu skupionej na wartości. Dobry pitch to przemyślana i spójna koncepcja, która odpowiada na kluczowe pytania:

❓ Czy rozwiązujecie ważny problem dla użytkowników?
❓ Czy wiecie, jak ma wyglądać efekt - rozwiązanie problemu?
❓ Czy Wasze rozwiązanie techniczne faktycznie adresuje problem?
❓ Czy to realne, że wdrożycie je w 6 tygodni?

Kluczowe elementy pitcha:
1️⃣ Grupa docelowa - dla kogo jest rozwiązanie i jaka jest wielkość tej grupy
2️⃣ Wartość dla użytkowników - jaki problem rozwiązujemy i jak ważny jest on dla odbiorców
3️⃣ Wartość biznesowa - jak to przełoży się na realizację celów i wyniki firmy
4️⃣ Notka prasowa - opis rozwiązania z perspektywy użytkowników i wpływu na ich życie
5️⃣ Zakres prac - user stories, kluczowe funkcjonalności, makiety low-fi UX (Figma) elementy techniczne, konieczne zmiany w innych obszarach
6️⃣ "Królicze nory" - czego świadomie NIE robicie w ramach tego projektu
7️⃣ Q&A - kwestie do ustalenia, problemy i ryzyka

W Useme.com udostępniamy pitche w firmie (na Google docs z opcją komentowania) i jest pierwszy TEST ich wartości i sensu. Feedback osób z firmy pozwala ocenić, czy:
✅ Zajmujemy się ważnym problemem dla użytkowników
✅ Projekt ma sens biznesowy
✅ Rozwiązanie jest użyteczne i adresuje problem
✅ 6 tygodni na realizację to realny termin
✅ Nie pominęliśmy istotnych ryzyk, np. prawnych

Jeśli po feedbacku osób z firmy widzisz, że pitcha jest niekompletny lub ma błędne założenia musisz:
⚒️ - dalej pracować nad koncepcją aż będzie gotowa
lub
🪦- porzucić ją i oszczędzić sobie czasu, pracy i pieniędzy.
Tak, w ten sposób odrzuciliśmy wiele projektów w Useme.com unikając porażek, spowodowanych w inwestowanie czasu w projekty mało wartościowe lub niewyrażalne w rozsądnym czasie.

Podsumowując: dobry pitch to esencja projektu. Daje przemyślaną i kompletną koncepcję, która zapewnia wartość dla użytkowników i firmy oraz realizację w założonym terminie. Tworząc go zyskujesz większą pewność, że Twój projekt ma sens i jest realizowalny w ustalonym czasie.

Polecam Ci książki które dadzą Ci pełniejszą wiedzę w temacie:
1. “Shape Up” Ryan Singer (dowiesz się czym jest Shape UP)
2. The Pyramid Principle Barbara Minto (dowiesz się jak tworzyć logiczną i przekonujące koncepcję)
3. "Working Backwards" Bryan Colin, Bill Carr (jak koncentrowali się na wartości w Amazonie)

💡Dobra a jak Ty tworzysz koncepcję nowych funkcjonalności?
☕️Masz pytanie o Shape Up - napisz do mnie. Pomagam też we wdrażaniu Shape Up jako konsultant, głównie w skalujących się startupach oraz w większych firmach.

PS Widzimy się w kolejnym postach w których m in. przybliżę Ci metodę priorytetyzacji RICE, która świetnie współgra z pitchami.

Jak to wygląda w wielu firmach? Mnóstwo czasu spędzamy na daily standupy, refinementy, retro po każdym sprincie, duże demo..etc.. A kiedy tworzymy wartości dla użytkowników?

Nie mówię, że wszystkie te spotkania są z gruntu złe. Ale często przeradzają się w rytuały, które niewiele wnoszą, a jedynie wybijają nas z flow i zabierają czas na faktyczną pracę.

Przykłady? Proszę:
❌ Daily - które często przeradzają się w raportowanie, a nie faktyczną synchronizację i rozwiązywanie problemów (i prawie każdy uczestnik skupia się na tym, "jak dobrze powiedzieć co robiłem?", zamiast aktywnie słuchać innych)
❌ Refinementy z udziałem całych zespołów, gdzie aktywnie uczestniczy tylko część developerów. Efektem tych wielogodzinnych sesji są nietrafne wyceny, bo przecież projekty i tak się przeciągają.
❌ Demo z tuzinami osób, na których trzeba "sprzedać" efekty pracy, zamiast na bieżąco zbierać feedback na mniejszych prezentacjach działających rozwiązań
❌ Retro po każdym sprincie - serio? aż tak, często mamy wartościowe pomysły na usprawnienia procesu?

A gdyby tak... wyrzucić to wszystko i zacząć od nowa?

Tak zrobiliśmy w Useme.com, wdrażając Shape Up. Zamiast sztywnych ceremonii postawiliśmy na:

1️⃣ Weekly w wąskim gronie Product Trio (o nim w poprzednich postach) na których omawiamy; postęp pracy, wyzwania, podejmujemy decyzje i ustalamy potrzeby względem innych zespołów.

2️⃣ Krótkie spotkania ad hoc (1-3 osoby) dedykowane konkretnemu tematowi

3️⃣ Asynchroniczna komunikacja na Slacku - dedykowane kanały pod projekt, wątki, grupa ograniczona do niezbędnego minimum

4️⃣ Retro po 6-tygodniowym cyklu - bo wtedy faktycznie zebrały się tematy do omówienia i pomysły na usprawnienia

Efekty?
✅ znacznie lepsza koncentracja (deep work)
✅ więcej czasu na faktyczną pracę, a w efekcie
✅ dostarczanie funkcjonalności, które rozwiązują prawdziwe problemy użytkowników.

Jeśli jesteś fanem Scruma - rozumiem, nie chcę nikogo urazić. Moje przemyślenia wynikają z 10+ lat doświadczeń i niezliczonych rozmów z Wami, ekspertami z branży. Pokrywają się z konkluzjami legend z Basecamp.

Wierzę, że warto czasem kwestionować status quo i poszukać lepszych rozwiązań.

💡A jakie są Wasze doświadczenia? Ile czasu spędzacie na ceremoniach? Czy widzicie przestrzeń do zmian? Dajcie znać w komentarzach!

Polecane książki związane z tematem.
1. “Praca głęboka” Cal Newport
2. “Shape Up” Ryan Singer
3. “Esencjalista” Greg McKeown

Jeśli chcecie dowiedzieć się więcej o Shape Up i tym, jak usprawniamy procesy - piszcie śmiało na PRIV, chętnie podzielę się wiedzą.
Doradzę jako konsultant we testowych wdrożeniach Shape Up w organizacjach.

Alternatywą to małe, autonomiczne i dedykowane zespoły.

Kolejny fundament Shape Up, który zrewolucjonizował podejście do prowadzenia projektów w Useme:

Co to właściwie oznacza - że zespół jest:

1. Dedykowany - to taki, który przez cały 6 tyg. cykl projektowy pracuje wyłącznie nad jedną inicjatywą. Bez rozpraszania się na inne projekty, zadania, bugi, czy "gaszenie pożarów".
   Brzmi jak "luksus"? Owszem, ale w też sposób nie mamy wymówek typu "nie zdążyliśmy, bo musieliśmy zrobić X i Y" i musimy wdrożyć funkcjonalność.

2. Autonomiczny - bo sam podejmuje większość decyzji - bez konieczności akceptacji “góry”.

3. Mały - bo złożony z Produkt Trio: PM + UX + Tech Lead + wsparcia analityków, testerów, marketerów, copy, growth itp.).

Jakie to daje korzyści w projekcie, zespole?
✅ Większa odpowiedzialność i zaangażowanie, bo nie można "schować się" za innych
✅ Lepsza efektywność, bo praca każdego jest widoczna
✅ Szybsze decyzje, bez czekania na "górę"
✅ Lepsze decyzje, bo podejmowane przez osoby bliżej problemu

Jakie korzyści dla całej firmy?
✅ Szybsze działanie - wdrożenia
✅ Regularne wdrażanie funkcjonalności o realnej wartości dla użytkowników
✅ Większa poczucie odpowiedzialności i zaanagażowania

Jak spróbować?

1. Zacznij od jednego, pilotażowego projektu.

2. Wybierz ważny, ale nie krytyczny obszar.

3. Zbierz zespół: UX, Tech Lead, + tester, biznes, analityk

To działa. Wprowadzenie małych, autonomicznych i dedykowanych zespołów było jednym z kamieni milowych w usprawnianiu procesów produktowych w Useme.

Polecane książki związane z tematem.
1. “Shape Up” Ryan Singer
2. "Continuous Discovery Habits" Teresa Torres
3. “Inspired: How To Create Products Customers Love” Marty Cagan
4. “Empowered: Ordinary People, Extraordinary Products” Marty Cagan, Chris Jones

💡Czy Twoja firma jest gotowa na taki ruch? Czy masz gotowość w zespole?
☕️ Planujesz pierwszy projekt w tej metodyce - napisz do mnie na priv lub umów się na konsultację. Pomagam we wdrożeniach Shape Up w firmach.

#3 Nieprzekraczalny 6-tygodniowy termin w Shape Up.
Kontrowersyjna, ale skuteczna reguła

Jedną z najbardziej charakterystycznych cech metodyki Shape Up jest sztywne określenie czasu trwania projektu na 6 tygodni. Co więcej, jeśli projekt nie zostanie ukończony w tym terminie, jest bezwzględnie porzucany. Brzmi kontrowersyjnie? To pierwsza reakcja większości zespołów. Jednak to właśnie ten radykalny limit jest kluczem do efektywności Shape Up.

Dlaczego ścisłe określenie czasu trwania projektu jest tak ważne?

✅ Wymusza priorytetyzację i skupienie na dostarczaniu działającej funkcjonalności pomagającej użytkownikom. Nie ma miejsca na "ozdobniki", tylko to co realnie działa.

✅ Zabezpiecza przed paradoksem Concorde'a (zwanym też "efektem kosztów utopionych") - ciągnięciem projektu w nieskończoność tylko dlatego, że już włożono w niego dużo pracy.

✅ Uczy zespół planowania, podejmowania trudnych decyzji i co najważniejsze brania odpowiedzialności.

Muszę przyznać, że porzucanie niedokończonego projektu jest zawsze bolesne. Jednak alternatywą są ciągnące się wiecznie "prawie gotowe" projekty, konsumujące zasoby i wstrzymujące inne inicjatywy.

Przykładem projektu, który musieliśmy przerwać w Useme, było logowanie via Google. Choć pomysł wydawał się super, okazało się, że nie przemyśleliśmy wystarczająco jego logiki i konsekwencji. Mijał 5 tydzień, a my byliśmy zagrzebani w niedokończonej pracy, bez perspektywy szybkiego wdrożenia.Nie czuliśmy, że kolejne tygodnie dadzą przełom. Podjęliśmy trudną decyzję o niekontynuowaniu prac. Bardziej prawdopodobne było wpadnięcie w pułapkę paradoksu Concorde'a. Wróciliśmy do tego pomysłu kilka miesięcy później lepiej przygotowani - z analizą logiki biznesowej i technicznej. Ta lekcja nauczyła nas, że lepiej zatrzymać się wcześniej i wrócić silniejszym, niż brnąć w ślepą uliczkę.

Kluczowym momentem każdego 6-tygodniowego cyklu Shape Up jest jego połowa - wtedy zespół musi obiektywnie ocenić postępy. Jeśli dowiezienie pełnego zakresu nie jest realne, musi go uprościć, znaleźć tańsze rozwiązanie lub jeśli go nie ma - porzucić projekt. Według reguły, przekroczenie terminu nie wchodzi w grę.

Czy nam w Useme zawsze udaje się zachować dyscyplinę 6-tygodniowych ram czasowych? Nie - też jesteśmy tylko ludźmi. Ale z każdym kolejnym cyklem poprawiamy proces i przekraczamy terminy coraz rzadziej i mniej dotkliwie.

Podsumowując:

• Określenie nieprzekraczalnych ram czasowych to trudna, ale wartościowa praktyka

• Główne korzyści to lepsza priorytetyzacja, unikanie paradoksu Concorde'a i ciągła nauka

• Egzekucja tej reguły bywa bolesna, ale przynosi dobre efekty długoterminowe

💡A jak wygląda to w Waszej organizacji - stosujecie sztywne terminy dla projektów? Jak sobie z tym radzicie?

☕️ Planujesz pierwszy projekt w tej metodyce - napisz do mnie na priv lub Umów się na konsultację.
Pomaga we wdrożeniach Shape Up w firmach.

Dziś skupię się na pierwszym, kluczowym elemencie tej metodyki:

I. Koncentracji na rozwiązaniu jednego, ważnego problemu użytkownika.

1. Co oznacza 'koncentracja na rozwiązaniu'?

• Pragmatyzm wygrywa z finezją technologiczną - słowo 'jakieś' nie jest tu przypadkowe. Jeśli prosty checkbox rozwiązuje problem równie skutecznie co zaawansowany uploader, wybieramy to pierwsze

• Powstrzymujemy się przed złożonymi funkcjonalnościami, jeśli nie są niezbędne

• Liczy się efekt dla użytkownika, nie elegancja techniczna rozwiązania

2. Jak definiujemy 'ważny problem'?

• Istotność dla użytkowników:

  • Czy problem regularnie pojawia się w rozmowach z użytkownikami? Pojawia się w feature requestach?

  • Czy widać błysk w oczach użytkowników, gdy opisujemy potencjalne rozwiązanie(Job-To-Be-Done)?

• Zasięg oddziaływania:

  • Ilu użytkowników obecnie dotyka ten problem?

  • Jaki jest potencjalny zasięg dla planowanej funkcjonalności?

💡W ocenie 'ważności' wspieramy się framework'iem RICE, który pozwala zbalansować dane jakościowe i ilościowe (więcej o RICE w kolejnym poście).

3. Dlaczego rozwiązania jednego problemu a nie kilku? To pozwala nam na utrzymaniu koncentracji, nie wpadania wątki poboczne zwiększające ryzyko 'zagrzebania się" w detalach i finalnie nie dowiezieniu funkcjonalności w ciągu 6-tygodni.

Co nam dało takie podejście? Po zastosowania Shape Up widzimy wymierne efekty:

✅ Co 6 tygodni wdrażamy wartościowe funkcjonalności (nie zawsze są to game-changery, ale systematycznie się do nich zbliżamy)
✅ Zespół nauczył się skupiać na realnym rozwiązywaniu problemów użytkowników
✅ Znacząco poprawiła się komunikacja, zarówno wewnątrz zespołu, jak i z innymi działami

To dopiero początek naszej drogi z Shape Up. W kolejnych postach opiszę szczegółowo pozostałe elementy: przemyślany pitch, małe zespoły i mniej spotkań.

💡Chcesz podzielić się swoimi doświadczeniami z Shape Up - napisz komentarz.
☕️ Planujesz pierwszy projekt w tej metodyce - napisz do mnie na priv.

Fundamenty Shape Up:

• Cykle 6-tygodniowe - nieprzekraczalne ramy czasowe dla każdego projektu. Zespół ma pełną koncentrację na jednym problemie użytkownika, bez rozpraszania się innymi zadaniami czy bugami.

• Radykalne podejście do zakresu i terminu - jeśli w połowie cyklu okazuje się, że zakres jest zbyt duży, obcinamy go "do żywego". Liczy się dostarczenie wartości, nawet jeśli oznacza to wybór prostszego rozwiązania technicznego (np. checkbox zamiast systemu uploadowania plików).

• Autonomiczne zespoły produktowe - to klasyczne Product Trio (świetnie opisane przez Teresę Torres w "Continuous Discovery Habits"), wspierane przez testerów oraz zespół biznesowy w szybkim podejmowaniu decyzji.

• Pitch - przemyślany dokument koncepcyjny, przypominający nieco 6-stronicowe dokumenty z Amazona (opisane przez Bryana Colina Carrego w "Working Backwards"). Powinien zawierać:

  • Jasne przedstawienie problemu użytkownika i proponowanego rozwiązania (można wykorzystać user story lub format Press Release).

  • Priorytetyzację zadań według MoSCoW i zdecydowanie który element jest kluczowy, a który może “wypaść” z zakresu.

  • Wyraźne określenie elementów, które są poza zakresem projektu.

  • Kluczowe flow w formie makiet i diagramów.

W przeciwieństwie do Scruma, gdzie taski spadają ze sprintu na sprint, Shape Up wymusza konkretne ramy czasowe i skupienie na wartości. A w przypadku niedowiezienia celu tj. braku wdrożenia działającej funkcjonalności w terminie - porzucenie prac nad projektem (w celu uniknięcia paradoksu Concorde inaczej efekt kosztów utopionych)

Czy decyzja o przerwaniu prac bywa bolesna? - oj tak, nawet bardzo. Czy jest konieczne? - owszem tak.

Shape Up jest szczególnie atrakcyjny dla zespołów zmęczonych ciągłym spadami ze sprintu na sprint i uciekającej wartości dla użytkownika, jak to bywa często w scrumie. Wymaga dojrzałości produktowej i umiejętności podejmowania trudnych decyzji, ale w zamian oferuje framework skutecznie koncentrujący się na dostarczaniu realnej wartości dla użytkownika, trzymając się deadlinów.

Daj znać, czy zainteresowała Cię tematyka Shape Up i chciałbyś/chciała abym ją przybliżył w kolejnych artykułach.

Polecane materiały:
1. “Shape Up” Ryan Singer
2. "Continuous Discovery Habits" Teresa Torres
3. “Competing Against Luck”Clayton Christensen
4. "Working Backwards" Bryan Colin, Bill Carr

Autor: Dawid Szkiełka - niezależny Product Advisor wspierający firmy w transformacji produktowej i skalowaniu. Wdrożył z sukcesem Shape Up m.in. w Useme.com.
ex-Allegro, ex-Wirtualna Polska, ex-Agora, ex-Saatchi & Saatchi