Motywacja.exe — czyli jak nie zawiesić się przy wymagających projektach | Backlog Refinement to bzdura: Jak zespoły marnują 10% swojego czasu i dlaczego Discovery powinno to zastąpić
Wydanie #200
W dzisiejszym wydaniu między innymi:
💜 Motywacja.exe — czyli jak nie zawiesić się przy wymagających projektach 👾 (by
)💜 Backlog Refinement to bzdura: Jak zespoły marnują 10% swojego czasu i dlaczego Discovery powinno to zastąpić (by
)💜 Foundation Sprint (artykuł gościa by Marcin Chyła)
💪 Ciekawe możliwości pracy w zarządzaniu produktem
🍪 Product Bites - małe porcje wiedzy o produkcie
🔥 MLA week#20
Dołącz do Premium, aby uzyskać dostęp do całej zawartości.
Przeczytanie tego wydania zajmie Ci prawie godzinę. Mnóstwo treści (lub mięsa)! (Dla wegan - dużo tofu!)
Weź notatnik 📰 i swój ulubiony napój 🍵☕
Wstępniak od Alex 💜
Teatr Doskonałości: Czas Zerwać z Udawaniem
Kłamstwo Social Mediów
Twój telefon rozświetla się kolejnym powiadomieniem z LinkedIn. Jakiś product guy, którego ledwo pamiętasz z konferencji sprzed trzech lat, właśnie ogłosił rundę finansowania Series B swojego startupu. Post aż kipi od perfekcyjnego humble-bragu: profesjonalne zdjęcia, pozy założyciela z tym specyficznym uśmiechem typu "zmieniam świat, ale staram się wyglądać przy tym nonszalancko". 1500+ polubień, 200+ komentarzy "Gratulacje!" i "Niesamowita podróż!"
Tymczasem ty siedzisz w swoim salonie o 22:30, tonąc w backlogu, który jest o jedno pilne zadanie od całkowitego załamania, zastanawiając się, czy "totalnie zjebane" jest akceptowalną aktualizacją statusu na jutrzejszy stand-up.
Witaj w teatrze doskonałości, gdzie wszyscy inni odnoszą sukcesy, a tylko ty ledwo trzymasz się kupy.
Tyle że to kłamstwo. Kompletne, pieprzone kłamstwo.
Ten założyciel z idealnym postem na LinkedIn? Jego produkt pali pieniądze, główny inżynier właśnie się zwolnił, a on sam jest w trakcie trzeciej bezsennej nocy wywołanej stresem. Ta "wizjonerska" liderka produktu, która prowadzi keynote'y o swoim nieskazitelnym procesie discovery? Ma stos skarg klientów, których unika, i od tygodni nie patrzyła na metryki użytkowników, bo przeraża ją to, co mogą pokazać.
Oto prawda, której nikt nie chce przyznać: Idealny product manager nie istnieje. Nieskazitelna podróż startupu to mit. Gładka roadmapa to fantazja. A gonienie za tymi iluzjami niszczy twoją faktyczną pracę, zdrowie psychiczne i, paradoksalnie, szansę na zbudowanie czegoś, co naprawdę ma znaczenie.
Nasza branża stworzyła potwora – tę nieustanną presję, by wydawać się, że masz wszystko pod kontrolą. Że zawsze jesteś data-driven, customer-obsessed i strategicznie błyskotliwy. Że twój zespół nigdy nie ma konfliktów, twoi dyrektorzy zawsze zgadzają się z twoją wizją, a twoje funkcje zawsze trafiają w punkt.
Ale, prawdziwa praca nad produktem to kurewski bałagan. Prawdziwa innowacja wyłania się z chaosu, porażek i bycia kompletnie, całkowicie zagubionym, zanim znajdziesz drogę. A udawanie, że jest inaczej, nie jest tylko nieuczciwością – to niszczy nas od środka.
Dziś nazywam bullshitem całą tę szopkę. Nie dlatego, że wszystko rozgryzłam – wręcz przeciwnie. Bo mam dość udawania. Mam dość idealnych postów na LinkedIn, podczas gdy mój Slack wybucha pożarami. Mam dość potakiwania na konferencjach, gdy prelegenci opisują procesy produktowe, które nigdy, ani razu, nie działały tak gładko w całej historii rozwoju oprogramowania.
Też masz tego dość, prawda?
Pozwól, że opowiem ci historię, która rozwaliła mi mózg. Kiedy zarządzałam zespołem produktowym, była taka menedżerka z innego działu, która zawsze kręciła się na naszym piętrze. Podczas spotkań była cholernie bezbłędna – idealnie przygotowane prezentacje, wnikliwe komentarze, zawsze opanowana, zawsze miała właściwą odpowiedź. Chodząca definicja osoby, która ma wszystko pod kontrolą.
Pewnego szczególnie gównianego dnia, kiedy wszystko wokół mnie się sypało, zobaczyłam ją siedzącą samotnie. Idealne wyczucie czasu, pomyślałam. Zapytam ją o jej sekret – jak być tak dopracowaną, jak ogarnąć to wszystko bez potu na czole.
Ale zanim zdążyłam zapytać, spojrzała na mnie zmęczonymi oczami i wyznała: "Ukrywam się na waszym piętrze. Ukrywam się przed swoim zespołem. Przed presją. Przed oczekiwaniami. Przed innymi ludźmi."
To uderzyło mnie jak cios w brzuch. Osoba, z którą się porównywałam – standard doskonałości, którego nie osiągałam – była równie przytłoczona jak ja. Po prostu lepiej odgrywała swoją rolę.
Porozmawiajmy o tym, co naprawdę dzieje się za tymi przefiltrowanymi zdjęciami i starannie skonstruowanymi case studies. Porozmawiajmy o wojnie psychologicznej, którą prowadzimy sami ze sobą. I może – tylko może – dajmy sobie pozwolenie, by być wspaniale niedoskonałymi, czasami błyskotliwymi bałaganami, którymi faktycznie jesteśmy.
Psychologiczny Koszt Doskonałości
To nie jest tylko kwestia złego samopoczucia podczas scrollowania LinkedIn. To gówno dosłownie przeprogramowuje twój mózg, i to nie w dobry sposób.
Porozmawiajmy o tym, co dzieje się w twojej głowie, gdy konsumujesz najlepsze momenty z karier innych ludzi. Psycholog społeczny Leon Festinger rozgryzł to już w latach 50. swoją Teorią Porównań Społecznych. Okazuje się, że mamy tę pierwotną potrzebę oceniania siebie przez porównywanie naszych zdolności i osiągnięć z innymi. To zakodowane w naszym ewolucyjnym kodzie – kiedy bycie na dole hierarchii plemiennej mogło oznaczać śmierć, twój mózg ewoluował, by stale sprawdzać swój status.
Przenieśmy się do 2025 roku, a twój pradawny mózg jest teraz bombardowany tysiącami starannie wyselekcjonowanych obrazów "sukcesu" każdego tygodnia. Twoja amygdala nie potrafi rozróżnić między rzeczywistym zagrożeniem dla twojego przetrwania a zagrożeniem, że wypadniesz jak porażka w porównaniu z tym dupkiem z product schoola, który teraz "rewolucjonizuje AI."
Oto jak działa ten cykl, i jest cholernie diaboliczny:
Widzisz czyjąś najlepszą rolkę (awans, finansowanie, uruchomienie produktu). Twój mózg dostaje małą dawkę dopaminy – "ooo, błyszcząca rzecz!" Potem przychodzi porównanie – "dlaczego ja tego nie osiągnąłem?" Wejście kortyzolu – twój hormon stresu skacze. Twój system wykrywania zagrożeń się aktywuje. Twoja kora przedczołowa – część mózgu odpowiedzialna za złożone myślenie i kreatywność – dosłownie się wyłącza.
Zgadza się. Ta sama część twojego mózgu, której potrzebujesz do dobrej pracy nad produktem, zostaje przejęta przez hormony stresu za każdym razem, gdy angażujesz się w tę grę porównań. I robimy to gówno sami sobie dziesiątki razy dziennie.
Daniel Kahneman nazwałby to doskonałym przykładem "iluzji skupienia" – kiedy skupiamy się na wyróżniających się przypadkach (szalenie udany PM, jednorożcowy startup), dramatycznie przeceniamy ich powszechność. "Nic w życiu nie jest tak ważne, jak myślisz, kiedy o tym myślisz" – pisze. Ale spróbuj powiedzieć to swojemu lękowi, gdy wpadasz w spiralę o 2 nad ranem.
A oto clou – im bardziej starasz się utrzymać tę iluzję, że masz wszystko pod kontrolą, tym gorzej się robi. Badania Amy Edmondson nad bezpieczeństwem psychologicznym pokazują, że środowiska, w których ludzie czują, że muszą wydawać się perfekcyjni, faktycznie dają gorsze wyniki. Zespoły, w których ludzie mogą przyznawać się do błędów i słabości, konsekwentnie przewyższają te, w których wszyscy udają, że są nieskazitelni.
Ale kultura zarządzania produktem jest szczególnie popierdolona pod tym względem. Gloryfikujemy "wizjonerów", którzy pozornie przewidzieli przyszłość, ignorując rzeczywistość, że większość udanych produktów jest wynikiem bałaganiarskiej iteracji, szczęśliwego wyczucia czasu i mnóstwa porażek po drodze.
Statystyki zdrowia psychicznego w naszej branży powinny włączać dzwonki alarmowe:
79% product managerów zgłasza doświadczenie wypalenia w ciągu ostatniego roku
68% twierdzi, że regularnie czuje się jak oszuści na swoich stanowiskach
Prawie połowa przyznaje, że ukrywa swoje zmagania przed zespołami z obawy przed wyglądaniem na niekompetentnych
Nie mówimy tu tylko o małym stresie. Mówimy o systemowym pieprzeniu umysłu, które niszczy naszą kreatywność, nasze zdrowie i ostatecznie naszą zdolność do budowania dobrych produktów.
Pamiętasz tę menedżerkę ukrywającą się na moim piętrze? Ona nie jest wyjątkiem. Ona jest pieprzoną regułą. Różnica polega na tym, że większość z nas nawet nie ma luksusu ukrywania się – po prostu dalej odgrywamy, postujemy, udajemy.
Za każdym razem, gdy prezentujesz idealnie zorganizowaną roadmapę, o której wiesz, że wybuchnie przy pierwszym kontakcie z rzeczywistością... Za każdym razem, gdy pewnie kiwasz głową na spotkaniu zarządu, gdy faktycznie jesteś kompletnie zagubiony... Za każdym razem, gdy piszesz post na LinkedIn, który przedstawia twój chaotyczny pivot jako strategiczny majstersztyk...
Nie tylko kłamiesz innym. Uprawiasz gaslighting na samym sobie. A twój mózg zbiera wszystkie rachunki, magazynując hormony stresu, aż twoje ciało zmusi cię do zatrzymania się – zwykle w sposób, który nie jest ładny.
Chcesz usłyszeć coś dzikiego? Badania Daniela Ariely'ego nad nieuczciwością pokazują, że utrzymywanie małych kłamstw tworzy obciążenie poznawcze, które wyczerpuje twoje zasoby mentalne. Energia mentalna, którą wydajesz na utrzymanie iluzji doskonałości, dosłownie kradnie z kreatywności i umiejętności rozwiązywania problemów, które sprawiają, że jesteś dobry w swojej właściwej pracy.
Więc co my tu robimy? Serio. Co my kurde robimy sami sobie?
Czy mam jakiś sprytny framework, żeby to wszystko naprawić? Jakiś pięciostopniowy proces do produktywnościowej nirwany? Jakiś magiczny akronim, który rozwiąże wszystko?
Nie. Nie mam.
To, co mam, jest prostsze i prawdopodobnie bardziej przydatne: Po prostu bądź dobry dla siebie. Dojdziesz tam. Jestem tu, jeśli potrzebujesz płakać, śmiać się lub wygadać. Wszyscy tu jesteśmy – w tej samej bałaganiarskiej, niedoskonałej łodzi, próbując budować znaczące rzeczy, będąc jednocześnie ludźmi.
Jak napisał Stanisław Lem w "Szpitalu Przemienienia": "Nie żałuj, nigdy nie żałuj, że mogłeś coś zrobić w życiu, a tego nie zrobiłeś. Nie zrobiłeś, bo nie mogłeś."
To mocno uderza, prawda? Nie zawodzisz w byciu idealnym, bo nie starasz się wystarczająco mocno. Jesteś człowiekiem, z ludzkimi ograniczeniami. Przestań żałować tego, co "mógłbyś zrobić", gdybyś tylko był tą wyimaginowaną, doskonałą wersją siebie. Ta wersja nie istnieje. Ani dla ciebie, ani dla nikogo.
Reality Check: Jak Naprawdę Wygląda Praca nad Produktem
Pozwól, że powiem ci, jak faktycznie wygląda praca nad produktem za starannie skonstruowanymi case studies i wystąpieniami konferencyjnymi.
Wygląda jak VP of Engineering piszący do ciebie SMS-a o 23:00, bo funkcja, którą uruchomiłeś rano, wysypuje się u 20% użytkowników. Wygląda jak uświadomienie sobie, że twoja piękna roadmapa jest teraz bezwartościowa, bo konkurent właśnie wypuścił dokładnie to samo, co budowałeś przez sześć miesięcy. Wygląda jak gapienie się na metryki użytkowników, które mówią ci, że nikogo nie obchodzi funkcja, na której, według twojego CEO, miał opierać się cały biznes.
To jest rzeczywistość. To jest ta praca.
Pamiętasz, kiedy Slack stał się dla wszystkich ukochanym przykładem idealnego product-market fit? Czego nie usłyszysz w większości opowieści, to to, że Slack narodził się z popiołów upadłej firmy gamingowej. Stewart Butterfield i jego zespół spędzili lata i miliony dolarów budując grę o nazwie Glitch, w którą prawie nikt nie chciał grać. Ich udany pivot nie był jakimś genialnym ruchem – był desperacką próbą uratowania czegokolwiek z tego, co wyglądało na całkowitą porażkę.
Instagram? Zaczął jako Burbn, dezorientująca aplikacja check-inowa, której użytkownicy nienawidzili. Twitter? Projekt poboczny upadającej firmy podcastowej. Lista jest długa.
To nie są wyjątki – to pierdolona reguła. Ale rzadko słyszymy te historie w ich bałaganiarskiej chwale, ponieważ, jak nazywa to Kahneman, cierpimy na "błąd wyniku" – oceniamy decyzje na podstawie ich rezultatów, a nie jakości procesu decyzyjnego w danym momencie. Kiedy produkty odnoszą sukces, wstecznie tworzymy narracje o wizjonerskim przywództwie i nieskazitelnym wykonaniu. Kiedy zawodzą, wskazujemy na oczywiste błędy, które wcale nie były oczywiste w danym momencie.
Konsultowałam dla startupu, który teraz jest wart miliardy. Chcesz wiedzieć, jak wyglądały ich wczesne dni? Ich pierwszy MVP był tak wybrakowany, że założyciel osobiście dzwonił do każdego nowego użytkownika, by przeprowadzić go przez obejścia. Ich początkowe ceny były tak źle dobrane, że musieli całkowicie zrestrukturyzować swój model biznesowy po sześciu miesiącach. Ich pierwszy head of product zrezygnował po trzech miesiącach, bo chaos był nie do zniesienia.
Nie dowiesz się niczego z tego z ich historii pochodzenia, która teraz jest powtarzana w blogach technologicznych. Wszystko brzmi nieuchronnie z perspektywy czasu. Ale ja tam byłam. To był pieprzony bałagan. Odnieśli sukces nie dlatego, że mieli wszystko rozgryzione, ale dlatego, że byli gotowi żyć w tym bałaganie wystarczająco długo, by znaleźć swoją drogę.
Oto czego Marty Cagan nie umieszcza w swoich książkach pogrubioną czcionką: większość decyzji produktowych jest podejmowana przy niepełnych informacjach, sprzecznych priorytetach i zbyt małej ilości czasu. Większość roadmap to fikcja w momencie ich publikacji. Większość zespołów po prostu stara się podejmować najmniej złe decyzje, jakie mogą, z tym, co wiedzą w danym momencie.
Teresa Torres mówi o ciągłym discovery, ale rzeczywistość jest taka, że większość z nas robi ciągłą kontrolę szkód. Nie zbieramy spokojnie spostrzeżeń użytkowników, by poinformować nasz następny genialny ruch – gorączkowo próbujemy ustalić, dlaczego użytkownicy rezygnują, dlaczego ta funkcja nie zyskuje trakcji, lub dlaczego zespół inżynieryjny mówi, że ta "prosta zmiana" faktycznie zajmie trzy miesiące.
Kiedy zaczęłam mentorować product managerów, spodziewałam się pomagać w strategii i frameworkach priorytetyzacji. Zamiast tego, większość sesji spędzam pomagając im nawigować konflikty zespołowe, zarządzać wypaleniem i radzić sobie z ciągłym poczuciem, że zawodzą. Bo to jest faktyczna praca.
Prace Annie Duke nad podejmowaniem decyzji wyjaśniają, dlaczego jesteśmy tak surowi dla siebie. Cierpimy na "resulting" – ocenianie naszych decyzji na podstawie wyników, a nie jakości naszego myślenia w danym czasie. Kiedy coś się nie udaje, zakładamy, że podjęliśmy złą decyzję, nawet jeśli była ona rozsądna w oparciu o to, co wiedzieliśmy wtedy.
Prawda jest taka, że nawet najlepsi ludzie od produktu często się mylą. Oryginalny algorytm rekomendacji Netflixa był tak wadliwy, że zorganizowali konkurs z nagrodą miliona dolarów, aby go ulepszyć. Amazon wypuścił Fire Phone'a, kompletną katastrofę. Google ma cmentarzysko produktów tak rozległe, że istnieją dedykowane strony internetowe śledzące ich porażki.
Ale nie umieszczamy tego na naszych profilach LinkedIn, prawda? Nie prezentujemy case studies o funkcjach, których nikt nie używał, lub o launchach, które okazały się klapą. Tworzymy narracje, w których nasze sukcesy były nieuchronne, a nasze porażki nie istnieją.
To tworzy okropnie zniekształcony obraz tego, jak wygląda sukces. To nie jest prosta linia w górę i w prawo. To splątany bałagan fałszywych startów, pivotów, porażek, okazjonalnych zwycięstw i ciągłej, wyczerpującej adaptacji.
Prawdziwa praca nad produktem to podejmowanie najlepszej możliwej decyzji przy ograniczonych informacjach, a następnie adaptacja, gdy nieuchronnie nie idzie dokładnie tak, jak zaplanowano. To posiadanie odwagi, by powiedzieć: "Nie wiem, ale oto, co spróbujemy." To budowanie czegoś, obserwowanie, jak to zawodzi, i posiadanie odporności, by wyciągnąć wnioski i spróbować ponownie.
To kurewski bałagan. I to nie jest bug – to feature. Bałagan to miejsce, gdzie zachodzi nauka. Bałagan to miejsce, gdzie mieszka innowacja. Jeśli twój proces wygląda na czysty i idealny, prawdopodobnie nie podejmujesz wystarczającego ryzyka, by zbudować coś, co ma znaczenie.
Paradoks Innowacji
Oto umysłoginąca ironia, która nie daje mi spać w nocy: nasza obsesja na punkcie doskonałości aktywnie zabija kreatywność, której potrzebujemy do budowania świetnych produktów. To nie tylko czyni nas nieszczęśliwymi – to czyni naszą pracę gorszą.
Perfekcjonizm to nie tylko cecha osobowości czy humble-brag podczas rozmów kwalifikacyjnych ("moją największą słabością jest to, że zbyt bardzo się przejmuję!"). To zabójca kreatywności. A nauka potwierdza to w sposób, który powinien przerażać każdego odpowiedzialnego za innowacje.
Zacznijmy od przełomowych badań Amy Edmondson nad bezpieczeństwem psychologicznym. Jej praca na Harvardzie pokazała coś, co powinno być kurewsko oczywiste, ale jakoś nie jest: zespoły, które boją się wyglądać głupio lub popełniać błędy, produkują mniej innowacji. Kropka. Kiedy ludzie boją się osądu, trzymają się bezpiecznych pomysłów. Nie podejmują ryzyka. Nie kwestionują założeń. Nie odzywają się, gdy widzą problemy.
Brzmi znajomo? Powinno, bo to dokładnie środowisko, które stworzyliśmy w zarządzaniu produktem.
Kiedy ostatnio zaproponowałeś naprawdę dziki pomysł na spotkaniu produktowym? Kiedy ostatnio przyznałeś, że nie masz pojęcia, jak rozwiązać problem? Kiedy ostatnio publicznie przyznałeś, że funkcja, którą promowałeś, zawodzi?
Jeśli zawahałeś się, nie jesteś sam. Stworzyliśmy kultury, w których wyglądanie na kompetentnego jest ważniejsze niż bycie innowacyjnym.
Oto gdzie robi się jeszcze bardziej popierdolone: nasze mózgi dosłownie nie mogą wprowadzać innowacji pod stałą presją. Z neurologicznego punktu widzenia, kreatywność wymaga aktywacji tego, co neuronaukowcy nazywają "siecią trybu domyślnego" – części twojego mózgu, która rozświetla się, gdy jesteś zrelaksowany, marzysz na jawie, bierzesz prysznic lub patrzysz przez okno. To wtedy tworzą się połączenia między pozornie niepowiązanymi koncepcjami, gdy pojawiają się spostrzeżenia, gdy dzieje się prawdziwa magia.
Ale zgadnij, co wyłącza tę sieć? Stres. Strach. Ciągła czujność utrzymywania idealnego wizerunku. Presja, by performować.
Jonah Lehrer wyjaśnia to perfekcyjnie: "Kiedy ludzie są zaniepokojeni czymś, kiedy martwią się o popełnianie błędów, kiedy są w grupie, która nie pozwala im podejmować ryzyka, są znacznie mniej skłonni do patrzenia na problemy ze świeżej perspektywy."
Dane są jasne: przełomowe kreatywne pomysły nie pojawiają się podczas 14-godzinnych dni wypełnionych spotkaniami. Pojawiają się w przestrzeniach pomiędzy. Pojawiają się, gdy twój mózg ma przestrzeń do wędrówki. Pojawiają się, gdy nie jesteś przerażony wyglądaniem głupio.
Pomyśl, skąd pochodziły twoje najlepsze pomysły produktowe. Założę się, że nie podczas tego spotkania z zarządem, gdy dwadzieścia osób się na ciebie gapiło. To było pod prysznicem. Na spacerze. Podczas rozmowy, gdzie czułeś się wystarczająco bezpiecznie, by myśleć na głos bez osądu.
Daniel Kahneman wyjaśnia to swoją koncepcją myślenia Systemu 1 i Systemu 2. Twój System 2 – powolne, analityczne, deliberatywne myślenie – jest świetny do realizacji pomysłów, ale to twój System 1 – szybkie, intuicyjne, asocjacyjne myślenie – generuje naprawdę innowacyjne połączenia. A System 1 nie działa dobrze pod presją. Potrzebuje przestrzeni. Potrzebuje zabawy. Potrzebuje pozwolenia na bycie w błędzie.
Oto więc paradoks innowacji: im bardziej desperacko próbujemy być doskonali, tym mniej kreatywni się stajemy. A im mniej kreatywni się stajemy, tym gorsze są nasze produkty. Im gorsze są nasze produkty, tym bardziej czujemy się jak porażki. Im bardziej czujemy się jak porażki, tym większą presję wywieramy na sobie, by być doskonałymi. I błędne koło trwa.
Prawdziwa ironia? Te "doskonałe" osoby od produktu, z którymi się porównujesz – te dające keynote'y o swoich genialnych spostrzeżeniach – one też mają momenty zwątpienia, dezorientacji i porażki. Po prostu nie mówią o nich publicznie. Zamiast tego, często znajdują bezpieczne przestrzenie – zaufanych kolegów, terapeutów, coachów – gdzie mogą być autentyczne, bałaganiarskie i ludzkie. Gdzie mogą powiedzieć: "Nie mam kurwa pojęcia, co robię" i nie być za to osądzane.
To bezpieczeństwo psychologiczne nie jest dobre tylko dla ich zdrowia psychicznego – jest bezpośrednio związane z ich zdolnością do budowania świetnych produktów. Za każdym "natychmiastowym sukcesem" stoi zespół, który stworzył wystarczające bezpieczeństwo, by eksperymentować, zawodzić, uczyć się i w końcu przełamać.
Co prowadzi nas do niewygodnej prawdy: Odpoczynek to nie jest miły dodatek. To podstawa innowacji. Twój mózg potrzebuje czasu przestoju, by tworzyć kreatywne połączenia. Potrzebuje przestrzeni do wędrówki. Potrzebuje pozwolenia na zabawę bez natychmiastowej presji, by produkować.
Niektóre z najbardziej innowacyjnych firm na świecie to rozgryzły. Słynny program 20% czasu w Google nie był tylko miłym benefitem – bazował na zrozumieniu, że kreatywność wymaga przestrzeni. 3M ma podobny program od dekad, co zaowocowało innowacjami jak karteczki Post-it. Nie pochodziły one ze starannie zarządzanych roadmap produktowych – wyłoniły się z dawania błyskotliwym ludziom przestrzeni do zabawy bez strachu przed porażką.
Oto więc brutalna prawda: jeśli pracujesz 60 godzin tygodniowo, jesteś ciągle połączony, zawsze "włączony" i przerażony wyglądaniem na niedoskonałego, nie tylko zmierzasz do wypalenia. Aktywnie sabotujesz swoją zdolność do wykonywania najważniejszej części swojej pracy: kreatywnego myślenia o problemach wartych rozwiązania.
Pozwolenie na Bycie Człowiekiem
Gdzie nas to zostawia? Uwięzionych między zabijającą innowacje presją doskonałości a rzeczywistością, że wciąż mamy produkty do zbudowania, zespoły do prowadzenia i metryki do osiągnięcia?
Nie do końca. Jest inna droga, ale wymaga czegoś radykalnego: dania sobie pozwolenia na bycie pieprzoną istotą ludzką.
To nie chodzi o podniesienie rąk i przyjęcie przeciętności. Chodzi o rozpoznanie, że twoje człowieczeństwo – twój bałagan, twoje wątpliwości, twoje ograniczenia – nie jest bugiem. To źródło twoich największych spostrzeżeń, najgłębszych połączeń i, ostatecznie, twojej najlepszej pracy.
James Clear, autor Atomic Habits, ujmuje to perfekcyjnie: "Nie wznosisz się do poziomu swoich celów. Spadasz do poziomu swoich systemów." Ale oto, czego brakuje w tym cytacie – te systemy muszą być zbudowane dla ludzi, nie dla robotów. Muszą uwzględniać fakt, że będziesz mieć złe dni. Będziesz przepuszczać rzeczy. Będziesz popełniać błędy. I to nie jest tylko w porządku – to jest konieczne.
Pozwól, że na chwilę będę praktyczna. Jak faktycznie wygląda dawanie sobie pozwolenia na bycie człowiekiem w zarządzaniu produktem?
Wygląda jak mówienie "nie wiem", kiedy nie wiesz, zamiast przebijać się przez bullshit.
Wygląda jak blokowanie czasu w kalendarzu na myślenie – nie spotkania, nie wykonywanie, tylko myślenie – i zaciekłe bronienie tego czasu.
Wygląda jak dzielenie się zasługami za sukcesy i branie odpowiedzialności za porażki, bo obie są częścią bałaganiarskiego procesu budowania rzeczy, które mają znaczenie.
Wygląda jak ustalanie granic, które chronią zdolność twojego mózgu do wykonywania najlepszej pracy – odmawianie rozmowy o 20:00, gdy wiesz, że potrzebujesz odpoczynku, wyłączanie powiadomień Slacka, gdy potrzebujesz się skupić, robienie prawdziwej przerwy na lunch, by pozwolić swojemu umysłowi wędrować.
Wygląda jak znalezienie swoich ludzi – kolegów, przyjaciół lub mentorów, z którymi możesz być swoją pełną, bałaganiarską osobą – i tworzenie przestrzeni, gdzie autentyczność jest ceniona ponad pozorami.
Co najważniejsze, wygląda jak traktowanie siebie z tą samą współczującą wyrozumiałością, którą pokazałbyś przyjacielowi lub koledze. Kiedy ostatnio powiedziałeś zmagającemu się członkowi zespołu: "Powinieneś pracować ciężej, mniej spać i przedzierać się przez wyczerpanie"? Nigdy, prawda? Bo wiesz, że to gówniana rada. Więc dlaczego mówimy to sobie każdego pieprzonego dnia?
Badania Brené Brown nad wrażliwością pokazują coś kontraintuicyjnego: ludzie, którzy wydają się najbardziej opanowani, najbardziej perfekcyjni, są często najmniej połączeni, najmniej innowacyjni i, ostatecznie, najmniej szczęśliwi. Prawdziwe połączenie – z nami samymi, naszymi zespołami i naszymi użytkownikami – wymaga wrażliwości. Wymaga przyznania, kiedy mamy trudności, proszenia o pomoc, gdy jej potrzebujemy, i pozwalania innym, by widzieli nasz niedoskonały proces.
Oto framework, który pomógł mi znaleźć równowagę między dążeniem do doskonałości a akceptacją swojego człowieczeństwa. Nazywam go "Priorytety, Ograniczenia i Łaska".
Priorytety: Co naprawdę ma znaczenie teraz? Nie wszystko na twojej liście, nie każda metryka, nie każde żądanie interesariusza. Jakie są jedna lub dwie rzeczy, które przesuną wskaźnik twojego najważniejszego celu? Skup się tam, a reszta niech będzie wystarczająco dobra.
Ograniczenia: Jakie są twoje faktyczne ludzkie ograniczenia? Ile snu potrzebujesz, by dobrze funkcjonować? Ile godzin możesz się głęboko skupić, zanim zaczną się zmniejszające korzyści? Jakie inne priorytety w twoim życiu potrzebują uwagi? Pracuj w ramach tych ograniczeń, nie przeciwko nim.
Łaska: Jak możesz być życzliwy dla siebie, gdy nieuchronnie nie sprostasz oczekiwaniom? Co powiedziałbyś przyjacielowi, który mierzy się z twoimi obecnymi wyzwaniami? Powiedz to sobie. Serio tak myśl.
To nie jest tylko porada, która ma dobrze brzmieć. To praktyczne, oparte na dowodach podejście, bezpośrednio związane z twoją zdolnością do budowania świetnych produktów. Kiedy pracujesz z potrzebami swojego mózgu, a nie przeciwko nim, tworzysz warunki dla kreatywności i spostrzeżeń. Kiedy akceptujesz swoje ograniczenia, podejmujesz lepsze decyzje o tym, gdzie skupić swoją energię. Kiedy traktujesz siebie ze współczuciem, szybciej dochodzisz do siebie po niepowodzeniach i budujesz odporność.
Chip i Dan Heath w swojej książce "Switch" mówią o relacji między racjonalnym umysłem (Jeździec) a emocjonalnym umysłem (Słoń). Jeździec może widzieć drogę przed sobą i planować podróż, ale to Słoń dostarcza mocy. Kiedy te dwa są w konflikcie – gdy twój racjonalny umysł pcha ku doskonałości, podczas gdy twój emocjonalny umysł jest wyczerpany – Słoń wygrywa za każdym razem. Lepiej uznać potrzeby Słonia z góry, niż być całkowicie ściągniętym ze ścieżki.
Strategiczna przewaga przyjmowania niedoskonałości nie jest tylko osobista – jest zawodowa. Liderzy, którzy uznają swoje ograniczenia, budują większe zaufanie ze swoimi zespołami. Zespoły, które przyjmują porażkę jako część procesu, uczą się szybciej i wprowadzają więcej innowacji. Firmy, które priorytetyzują bezpieczeństwo psychologiczne, przewyższają te, które wymagają doskonałości.
Więc weź kurewski oddech. Spójrz na swoją niemożliwą do zrobienia listę. Uznaj, że jesteś jednym człowiekiem z ograniczonym czasem, energią i uwagą. Następnie podejmij wybory, które szanują te ograniczenia, skupiając się na tym, co naprawdę ma znaczenie.
Jak przypomina nam Stanisław Lem: "Nie żałuj, że mogłeś coś zrobić w życiu, ale nie zrobiłeś. Nie zrobiłeś, bo nie mogłeś." Nie zawodzisz w byciu idealnym, bo nie starasz się wystarczająco. Jesteś człowiekiem, z ludzkimi ograniczeniami. Im szybciej to zaakceptujesz, tym szybciej zaczniesz wykonywać swoją najlepszą pracę w ramach tych ograniczeń, zamiast walczyć z nimi.
Przepustka na Radykalną Zmianę: Twój Następny Ruch
No i jesteśmy. Przeczytałeś to wszystko, kiwając głową, może nawet czując odrobinę ulgi, że nie jesteś jedynym tonącym za starannie wypielęgnowanym profilem LinkedIn. Ale bądźmy szczerzy: czytanie artykułu niczego nie zmieni. Słowa są łatwe. Zmiana jest trudna.
Pozwól więc, że rzucę ci wyzwanie: Co zrobiłbyś inaczej jutro, gdybyś nie był sparaliżowany potrzebą wyglądania na idealnego?
Jaką funkcję byś ubił, gdybyś nie bał się przyznać, że to był błąd?
Jaki szalony pomysł byś przedstawił, gdybyś nie martwił się wyglądaniem głupio?
Jaką rozmowę przeprowadziłbyś ze swoim zespołem, gdybyś mógł być całkowicie szczery co do swoich wątpliwości i obaw?
Jak wyglądałaby twoja roadmapa, gdyby uznawała bałaganiarską rzeczywistość rozwoju produktu zamiast udawać pewność tam, gdzie jej nie ma?
Odpowiedzi na te pytania to miejsce, gdzie mieszka twoja najważniejsza praca. To tam dzieje się innowacja. To tam zaczynasz budować produkty, które naprawdę mają znaczenie, zamiast produktów, które po prostu dobrze wyglądają w case studies.
Oto twoja przepustka na radykalną zmianę: Zacznij od małych rzeczy. Wybierz jedno jutrzejsze spotkanie, podczas którego będziesz trochę bardziej autentyczny. Wybierz jeden obszar, w którym złagodzisz niemożliwe standardy. Wybierz jedną godzinę, którą ochronisz na faktyczne myślenie zamiast ciągłego działania.
To nie są tylko miłe rzeczy do zrobienia dla siebie. To strategiczne ruchy, które sprawią, że będziesz lepszy w swojej pracy. To inwestycje w twoją zdolność kreatywną. To zaliczki na uniknięcie wypalenia, które pochłania naszą branżę.
A jeśli jesteś liderem, twoje pozwolenie na bycie człowiekiem ma efekt mnożnikowy. Za każdym razem, gdy przyznajesz się do niepewności, sprawiasz, że twój zespół czuje się bezpieczniej robiąc to samo. Za każdym razem, gdy ustalasz granice wokół swojego czasu lub energii, dajesz innym pozwolenie na to samo. Za każdym razem, gdy dzielisz się porażką i tym, czego się z niej nauczyłeś, tworzysz kulturę, w której nauka znaczy więcej niż dobre wyglądanie.
Twój zespół obserwuje. Czerpie wskazówki od ciebie o tym, co jest cenione – pozory doskonałości czy rzeczywistość innowacji. Jaki przekaz wysyłasz?
Nie proszę cię, żebyś wysadził swoją karierę w powietrze lub przestał dbać o jakość. Proszę cię, żebyś uznał, że twoje człowieczeństwo nie jest przeszkodą do pokonania – to twój największy atut jako osoby od produktu. Twoja empatia, twoja kreatywność, twoja zdolność do łączenia się z innymi – wszystkie pochodzą z tego samego miejsca co twoje wątpliwości, twoje ograniczenia i twoje błędy. To pakiety.
Więc gdy weekend się zbliża, oto moja ostatnia prowokacja: Twój backlog nadal będzie tam w poniedziałek. Twoja skrzynka odbiorcza nadal będzie przepełniona. Presja na wyniki nadal będzie istniała. Ale masz wybór, jak to nieść.
Możesz dalej nosić maskę, kontynuować przedstawienie, udawać, że masz wszystko rozgryzłem. Albo możesz wziąć oddech. Odłożyć ciężar na chwilę. Pamiętać, że jesteś istotą ludzką wykonującą trudną, kreatywną pracę w niepewnych warunkach. I to nie jest tylko w porządku – to jest cały pieprzony sens.
Bo zarządzanie produktem nie polega na budowaniu idealnych rzeczy. Polega na budowaniu rzeczy, które mają znaczenie. A bałagan, niepewność, ciągła adaptacja – to nie jest coś, co stoi ci na drodze. To jest właśnie ta praca.
Twój perfekcjonizm nie pomaga ci lepiej wykonywać tej pracy. Stoi na drodze bałaganiarskiej, kreatywnej, ludzkiej pracy budowania produktów, które faktycznie mają znaczenie.
Co więc zrobisz inaczej w poniedziałek?
Ja zacznę: Przestanę udawać, że mam wszystkie odpowiedzi. Przyznam, kiedy mam trudności. Stworzę przestrzeń, by mój zespół mógł zrobić to samo. I będę pamiętać, że za każdym idealnym postem na LinkedIn stoi inna istota ludzka, walcząca z tymi samymi bataliami, odczuwająca te same wątpliwości i prawdopodobnie rozpaczliwie potrzebująca tego samego pozwolenia, by być niedoskonale, autentycznie sobą.
Twój backlog nadal tam będzie. Twój zespół nadal będzie cię potrzebował. Twoje metryki nadal będą miały znaczenie.
Ale spotkasz się z nimi jako cała istota ludzka – nie jako performance, nie jako persona, nie jako starannie wypielęgnowany profesjonalny wizerunek.
I wtedy zaczyna się prawdziwa praca.
Albo nic nie rób. Odpocznij. Siedź i patrz w ścianę. Albo w sufit. Albo zamknij oczy. To też jest ok.
🗓️ Wydarzenia dla społeczności Product Art w kwietniu i kolejnych miesiącach
Mapowanie ekosystemu użytkowników - persony w B2B
Prowadzący: Aleksandra Dziewulska
Opis szkolenia:
Większość podejść do projektowania koncentruje się na głównym, bezpośrednim użytkowniku produktu lub usługi, pomijając szerszy ekosystem powiązanych użytkowników. W przypadku rozwiązań B2B, to szczególnie problematyczne, ponieważ produkty i usługi często angażują licznych interesariuszy w organizacji, każdy z nich wchodzący w interakcję z rozwiązaniem w inny sposób. Ten warsztat, oparty na metodologii "user ecosystem thinking" (myślenie ekosystemowe o użytkownikach), wprowadza uczestników w holistyczne podejście do identyfikowania i mapowania różnych typów użytkowników w ekosystemach B2B.
Czego się nauczysz:
Odkryjesz, jak wyjść poza tradycyjne myślenie o "użytkowniku końcowym" i zidentyfikować ukrytych użytkowników, którzy mają wpływ na sukces Twojego rozwiązania
Nauczysz się rozpoznawać różne archetypy użytkowników w kontekście B2B, od użytkowników bezpośrednich po pośredniczących, zależnych i autonomicznych
Przeprowadzisz ćwiczenia mapowania ekosystemu dla rzeczywistych przypadków użycia w B2B
Stworzysz bardziej kompleksowe persony uwzględniające interakcje między różnymi typami użytkowników
Dowiesz się, jak projektować z myślą o złożonych ekosystemach użytkowników, aby tworzyć lepsze, bardziej inkluzywne rozwiązania
Dla kogo:
Warsztat jest odpowiedni zarówno dla projektantów UX, badaczy, product managerów, jak i innych specjalistów zaangażowanych w tworzenie produktów i usług B2B. Wszystkie materiały warsztatowe, w tym karty archetypów użytkowników, zostaną udostępnione uczestnikom. Czas trwania: 4 godziny Poziom zaawansowania: Średnio zaawansowany Liczba uczestników: 6-40 osób
Nie musisz mieć biletu na ProductPro Summit, by wpaść na nasz warsztat - wydarzenie przeznaczone jest dla otwartej społeczności
Link do zapisów: LINK
House of Product Academy - Twoja droga do mistrzostwa w zarządzaniu produktem
Rozwiń swoje kompetencje produktowe pod okiem ekspertów!
House of Product Academy to kompleksowy program szkoleniowy stworzony z myślą o obecnych i przyszłych liderach produktowych. Niezależnie od tego, czy dopiero zaczynasz swoją przygodę z Product Managementem, czy chcesz podnieść swoje umiejętności na wyższy poziom, znajdziesz tu wszystko, czego potrzebujesz.
Co nas wyróżnia?
Praktyczna wiedza - zapomnij o suchej teorii, stawiamy na realne case study i ćwiczenia
Doświadczeni mentorzy - uczysz się od osób z wieloletnim doświadczeniem w prowadzeniu zespołów produktowych
Networking - poznaj innych profesjonalistów i buduj wartościowe kontakty w branży
Elastyczny format - szkolenia dopasowane do potrzeb i możliwości czasowych uczestników
Czego się nauczysz?
Strategii produktowej i definiowania wizji
Skutecznego planowania i priorytetyzacji zadań
Prowadzenia badań użytkowników i analizy danych
Współpracy z zespołami deweloperskimi i designerskimi
Zarządzania procesem rozwoju produktu od pomysłu po wdrożenie
Nie czekaj - zainwestuj w swoją karierę produktową już dziś! Szczegółowe informacje o najbliższych terminach, programie i cenach znajdziesz na naszej stronie.
Link do zapisów: LINK
Dla naszej społeczności zniżka 15% z kodem: productart
💪 Produktowe oferty pracy z ostatniego tygodnia
Potrzebujesz wsparcia w rekrutacji, przebranżowienia lub budowania kariery? Umów się na darmową kawę, żeby porozmawiać :) Szukasz szczegółów? TUTAJ!
Product Owner - ComScore via CC
Product Manager - FINGO
Product Manager - Synerise
Senior Product Manager - Baselinker
Product Manager - Kyotu Technology
💡Product Spotlight: Skupienie na osobach kształtujących doskonałość produktu
Nasza funkcja Product Spotlight poświęcona jest przedstawianiu naszej społeczności najbystrzejszych umysłów w zarządzaniu produktami, projektowaniu i strategii. Poprzez formę wywiadów pisemnych odkrywamy ich unikalne perspektywy, wiedzę i podróże, które doprowadziły ich do ukształtowania jednych z najbardziej wpływowych produktów w branży.
Każdy z nich oferuje:
Osobiste spostrzeżenia: Poznaj osobę stojącą za produktem - co ją napędza, jej wyzwania i sukcesy.
Porady ekspertów: Poznaj praktyczne wskazówki, ramy i strategie bezpośrednio od ekspertów.
Kontakt ze społecznością: Odkryj, w jaki sposób ich doświadczenia i pomysły mogą zainspirować Twoją własną podróż produktową.
Product Spotlight to Twoja szansa na nawiązanie kontaktu z ekspertami, którzy na nowo definiują doskonałość produktów i stają się częścią ożywionej rozmowy na temat tego, co jest potrzebne do tworzenia znaczących produktów. Bądź na bieżąco z ekskluzywnymi wywiadami w każdym wydaniu!
Aby jeszcze bardziej docenić wiedzę specjalistyczną, wiele z tych pisemnych wywiadów będzie kontynuowanych jako odcinki podcastów, oferując pogłębione tradycyjne wywiady, które podkreślają wyjątkowy talent i innowacyjność ekspertów z Polski.
Zapraszam Was do wypełniania zgłoszeń do Product Spotlight i podsyłania linku do ankiety zgłoszeniowej produktowcom, których chcielibyście tutaj zobaczyć.
🍪 Product Bites (3 bites)
🍪 Pułapka przedwczesnej optymalizacji: Kiedy dążenie do perfekcji staje się największym wrogiem twojego produktu
Dlaczego zbyt wczesne szlifowanie detali może kosztować cię sukces rynkowy
Przedwczesna optymalizacja to tendencja zespołów produktowych do doskonalenia funkcji, kodu lub procesów, zanim ustabilizują się podstawowe założenia produktu lub zanim pojawią się realne dane o użytkowaniu. To klasyczny przypadek stawiania wozu przed koniem w rozwoju produktu cyfrowego.
Problem: Obsesja na punkcie doskonałości kosztem postępu
Zjawisko to trafnie podsumował Donald Knuth, legendarny informatyk, który stwierdził: "Przedwczesna optymalizacja jest źródłem wszelkiego zła w programowaniu". Badania pokazują, że aż 64% zespołów produktowych przyznaje się do marnowania zasobów na optymalizację funkcji, które później zostały całkowicie wycofane lub radykalnie przeprojektowane.
Przedwczesna optymalizacja przejawia się na wielu poziomach:
Techniczne szlifowanie kodu, który może zostać całkowicie przepisany
Dopracowywanie funkcji, których fundamentalna wartość nie została jeszcze potwierdzona
Udoskonalanie procesów, które mogą nie pasować do zmieniających się potrzeb produktu
Nadmierne planowanie złożonych przypadków użycia przed weryfikacją podstawowych scenariuszy
Przykładem może być przypadek Quibi, które zainwestowało 1,75 miliarda dolarów w dopracowanie idealnego formatu wideo dla smartfonów, nie testując wystarczająco wcześnie podstawowej hipotezy biznesowej (czy użytkownicy faktycznie chcą płacić za krótkie treści premium oglądane w telefonie).
Rozwiązanie: Strategiczna niedoskonałość i progresywna perfekcja
Skuteczne zarządzanie produktem wymaga akceptacji "strategicznej niedoskonałości" – świadomego wyboru, które elementy pozostawić w stanie wystarczająco dobrym, aby osiągnąć kluczowe cele biznesowe.
1. Piramida optymalizacji produktowej
Zastosuj trójpoziomową hierarchię wymagającą różnych poziomów dopracowania:
Krytyczne elementy (20%): Funkcje bezpośrednio związane z propozycją wartości i głównym zastosowaniem produktu – wymagają najwyższego poziomu dopracowania
Wspomagające elementy (30%): Funkcje zwiększające wartość, ale nie definiujące jej – wymagają umiarkowanej optymalizacji
Funkcje dodatkowe (50%): Elementy obwodowe – wystarczy minimalna funkcjonalność
2. Mapowanie ryzyka optymalizacyjnego
Przed podjęciem decyzji o głębszej optymalizacji, zadaj te pytania:
Jaki procent użytkowników korzysta z tej funkcji?
Jak często jest używana?
Czy optymalizacja znacząco wpłynie na kluczowe metryki?
Jaki jest koszt alternatywny tej optymalizacji?
Czy mamy wystarczające dane, aby podejmować decyzje optymalizacyjne?
Firma Slack początkowo świadomie ograniczyła optymalizację funkcji archiwizacyjnych i zaawansowanego wyszukiwania, koncentrując zasoby na komunikacji w czasie rzeczywistym – funkcji używanej przez 100% użytkowników. Gdy baza użytkowników się rozrosła, dopiero wtedy zainwestowali w optymalizację funkcji drugorzędnych.
3. Framework "dojrzewania do perfekcji"
Zamiast dążenia do perfekcji od razu, zastosuj podejście fazowe:
Faza koncepcyjna: Minimum umożliwiające testowanie hipotez (≈60% docelowej jakości)
Faza adopcji: Poziom wystarczający dla rosnącej bazy użytkowników (≈80% docelowej jakości)
Faza skalowania: Pełna optymalizacja dla dużej skali (≈95% docelowej jakości)
Faza dojrzałości: Doskonalenie długoterminowe (≈99% docelowej jakości)
Wdrożenie: Równoważenie szybkości i jakości
Aby skutecznie wdrożyć te zasady:
Ustal jasne progi optymalizacji: Zdefiniuj kryteria decydujące o tym, kiedy funkcja jest wystarczająco dobra dla obecnego etapu.
Wprowadź "dni optymalizacji": Zamiast ciągłego dopracowywania, wyznacz dedykowane okresy na optymalizację po weryfikacji kluczowych hipotez.
Mierz koszt alternatywny: Wprowadź metodę dokumentowania korzyści utraconych przez koncentrację na optymalizacji kosztem nowych możliwości.
Kultywuj akceptację dla "wystarczająco dobrego": Celebruj przypadki, gdy zespół świadomie powstrzymał się od przedwczesnej optymalizacji i dzięki temu osiągnął szersze cele biznesowe.
Spotify upublicznił, że początkowo tolerował 70-80% poziomu jakości dla wielu funkcji, aby szybciej testować nowe pomysły. Z czasem metodycznie podnosił poziom jakości tylko dla funkcji, które okazały się kluczowe dla doświadczenia użytkownika.
Przeszkody we wdrażaniu
Główne wyzwania w unikaniu przedwczesnej optymalizacji:
Perfekcjonizm inżynieryjny: Naturalna tendencja programistów do doskonalenia kodu
Strach przed krytyką: Obawa, że niedoskonały produkt spotka się z negatywnymi opiniami
Brak jasnych progów: Niezdefiniowane kryteria "wystarczająco dobrego" dla różnych etapów
Aby je przezwyciężyć:
Wprowadź jawne miary "dostateczności" dla różnych etapów produktu
Edukuj stakeholderów na temat strategicznej wartości szybszego wydania niedoskonałego produktu
Utwórz kulturę pochwały dla "inteligentnej niedoskonałości"
Pamiętaj
Perfekcja jest procesem, nie punktem startowym. Każdy wielki produkt zaczynał jako niedoskonała wersja siebie. Jak powiedział Reid Hoffman, założyciel LinkedIn: "Jeśli nie wstydzisz się pierwszej wersji swojego produktu, to znaczy, że wydałeś go zbyt późno."
Prawdziwe mistrzostwo w zarządzaniu produktem nie polega na dążeniu do perfekcji wszędzie, ale na strategicznym wyborze, gdzie i kiedy dążyć do doskonałości. W świecie ograniczonych zasobów, umiejętność powstrzymania się od przedwczesnej optymalizacji może być twoją największą przewagą konkurencyjną.
🍪 Prawo Conway'a w rozwoju produktu: Jak struktura zespołu kształtuje architekturę twojego produktu
Dlaczego organizacja twojej firmy determinuje to, co tworzysz, nawet o tym nie wiedząc
Prawo Conway'a to zasada mówiąca, że systemy projektowane przez organizacje są nieodłącznym odzwierciedleniem struktury komunikacyjnej tych organizacji. Innymi słowy: architektura produktu nieuchronnie naśladuje architekturę zespołu, który go tworzy.
Problem: Niewidzialna ręka struktury organizacyjnej
W 1967 roku programista Melvin Conway zaobserwował prawidłowość, która od tego czasu została potwierdzona w niezliczonych organizacjach: "Organizacje, które projektują systemy, są zmuszone do tworzenia projektów będących kopiami struktur komunikacyjnych tych organizacji."
Badanie przeprowadzone przez Harvard Business School wykazało, że w 92% przypadków struktura modułowa oprogramowania odzwierciedlała strukturę zespołów, które je stworzyły. To zjawisko powoduje szereg wyzwań:
Fragmentacja doświadczenia użytkownika: Silosy organizacyjne prowadzą do niespójnych doświadczeń
Duplikacja funkcji: Różne zespoły tworzą podobne funkcje bez wiedzy o sobie nawzajem
Problemy z integracją: Interfejsy między modułami stają się skomplikowane, tak jak komunikacja między zespołami
Techniczne obciążenie dziedziczne: Historyczne struktury zespołów pozostawiają trwały ślad w architekturze
Microsoft musiał przeprowadzić masową reorganizację, aby stworzyć Windows Phone, ponieważ istniejąca struktura zespołów (zorganizowana wokół systemu Windows Desktop) czyniła niemożliwym stworzenie spójnego systemu mobilnego. Reorganizacja kosztowała ich 18 miesięcy opóźnienia względem konkurencji.
Rozwiązanie: Świadome projektowanie organizacji dla produktu
Zamiast ignorować Prawo Conway'a, możemy je wykorzystać jako strategiczny instrument w rozwoju produktu. Odpowiednio dostosowując strukturę zespołów, możemy kształtować architekturę produktu w pożądany sposób.
1. Inwersja Conway'a: Projektuj zespoły pod kątem docelowej architektury
Zamiast pozwalać, aby istniejąca struktura zespołu determinowała architekturę, najpierw zaprojektuj idealną architekturę produktu, a następnie ustrukturyzuj zespoły, aby ją odzwierciedlały:
Mapuj przepływy wartości: Zidentyfikuj główne przepływy wartości w produkcie
Projektuj interfejsy zespołów: Określ, gdzie komunikacja między zespołami powinna występować
Dostosuj struktury raportowania: Zorganizuj hierarchię tak, aby wspierała pożądane przepływy komunikacji
Spotify zastosował to podejście z ich słynnym modelem "Squad" - małe, wielofunkcyjne zespoły zorganizowane wokół konkretnych elementów doświadczenia użytkownika, co skutkowało spójnym interfejsem pomimo bardzo złożonej architektury zaplecza.
2. Macierz dopasowania Conway'a
Użyj tej struktury, aby ocenić, czy twoja organizacja jest właściwie skonfigurowana dla architektury, którą chcesz zbudować:
Dla monolitycznej aplikacji optymalna jest struktura centralnie koordynowanego zespołu. Kluczowe wskaźniki niedopasowania to fragmentacja UX i niespójny interfejs użytkownika.
Dla systemu mikroserwisowego optymalne są autonomiczne wielofunkcyjne zespoły. Kluczowe wskaźniki niedopasowania to ścisłe powiązania i problemy z integracją.
Dla platformy z API optymalna jest struktura z zespołem rdzeniowym i zespołami partnerskimi. Kluczowe wskaźniki niedopasowania to nieprzyjazne API i słaba adopcja.
Dla rozwiązania wieloplatformowego optymalna jest struktura macierzy funkcji i platform. Kluczowym wskaźnikiem niedopasowania jest niespójność między platformami.
3. Rytuały przeciwdziałające Conway'owi
Wprowadź praktyki, które zapobiegają naturalnej tendencji do izolacji zespołów:
Rotacja deweloperów: Okresowa praca w różnych zespołach (10% czasu)
Guild-y międzyzespołowe: Społeczności praktyków przecinające granice zespołów
Hackathony integracyjne: Dedykowane wydarzenia skupiające się na płynności między modułami
Mapy zależności architektury: Wizualizacja, jak zmiany w jednym komponencie wpływają na inne
Wdrożenie: Rewizja organizacyjna dla lepszych produktów
Aby skutecznie wykorzystać Prawo Conway'a:
Przeprowadź audyt dopasowania Conway'a
Porównaj strukturę organizacyjną z architekturą produktu
Zidentyfikuj obszary, gdzie struktura organizacyjna ogranicza rozwój produktu
Zredefiniuj granice zespołów wokół doświadczeń użytkownika
Zamiast organizować zespoły według technologii, zorganizuj je wokół elementów podróży użytkownika
Daj każdemu zespołowi własność end-to-end dla określonego aspektu doświadczenia użytkownika
Wprowadź "ambasadorów architektury"
Wyznacz osoby odpowiedzialne za spójność między zespołami
Rotacja tej roli co kwartał, aby promować szerokie zrozumienie
Zrównoważone wskaźniki interdyscyplinarne
Mierz i nagradzaj współpracę międzyzespołową tak samo jak osiągnięcia wewnątrz zespołu
Wprowadź metryki mierzące płynność doświadczenia użytkownika przez granice zespołów
Amazon celowo zreorganizował się w "zespoły dwupizzowe" (zespoły nie większe niż liczba osób, które można nakarmić dwiema pizzami) z pełną autonomią, ale bardzo rygorystycznymi wymaganiami dotyczącymi API. Ta struktura organizacyjna bezpośrednio wpłynęła na architekturę AWS jako zbioru dobrze zdefiniowanych usług mikroserwisowych.
Przeszkody i wyzwania
Główne przeszkody w efektywnym wykorzystaniu Prawa Conway'a:
Istniejąca struktura władzy: Zmiana struktur zespołów często napotyka na opór wynikający z ugruntowanych hierarchii
Koszty reorganizacji: Restrukturyzacja zespołów wymaga czasu i tymczasowo obniża produktywność
Konflikt z innymi priorytetami organizacyjnymi: Struktura Conway'a może nie być zgodna z innymi celami biznesowymi
Aby je przezwyciężyć:
Rozpocznij od małych, eksperymentalnych zmian strukturalnych i rozszerzaj na podstawie sukcesu
Edukuj liderów na temat kosztów utrzymywania nieodpowiedniej struktury
Szukaj okazji do dostosowania struktury podczas naturalnych punktów tranzycji (nowe wydania, zmiany strategiczne)
Pamiętaj
Twoja organizacja jest niewidzialnym architektem twojego produktu. Struktura twojego zespołu to silniejsza determinanta architektury twojego produktu niż jakikolwiek dokument specyfikacji technicznej czy decyzja projektowa.
Jak powiedziała Ruth Malan, ekspert ds. architektury oprogramowania: "Jeśli architektura systemu i architektura organizacji nie są zgodne, organizacja wygra za każdym razem."
Zamiast walczyć z Prawem Conway'a, wykorzystaj je jako potężne narzędzie. Projektuj swoją organizację z taką samą starannością, z jaką projektujesz swój produkt, pamiętając, że te dwa aspekty są nieodłącznie ze sobą powiązane. Zrozumienie i wykorzystanie tej dynamiki może przekształcić zarówno twoją organizację, jak i twój produkt.
🍪 Efekt złotej klatki: Dlaczego użytkownicy pozostają przy produktach, które ich frustrują
Paradoks lojalności wobec rozwiązań, które jednocześnie frustrują i uzależniają
Efekt złotej klatki to fenomen, w którym użytkownicy pozostają lojalni wobec produktów cyfrowych pomimo znacznej frustracji i niezadowolenia. Podobnie jak złota klatka – piękna, wartościowa, ale wciąż ograniczająca – te produkty oferują wartość, która przewyższa niedogodności, jednocześnie tworząc barierę wyjścia zbyt wysoką, by użytkownicy zdecydowali się ją pokonać.
Problem: Toksyczna lojalność i ukryte koszty
Badania przeprowadzone przez Nielsen Norman Group wykazały, że 73% użytkowników regularnie wyraża frustrację związaną z produktami cyfrowymi, z których korzystają codziennie, a mimo to 67% z nich nie rozważa zmiany na alternatywne rozwiązania.
Ten paradoks przejawia się w wielu postaciach:
Zablokowane ekosystemy: Użytkownicy Apple często narzekają na ograniczenia iOS, ale pozostają w ekosystemie ze względu na zainwestowane tysiące dolarów w aplikacje i usługi
Platformy społecznościowe: Użytkownicy Facebooka regularnie wyrażają obawy dotyczące prywatności, ale kontynuują korzystanie z platformy, ponieważ "wszyscy inni tam są"
Oprogramowanie korporacyjne: Pracownicy narzekają na przestarzałe systemy ERP, które jednak zawierają bezcenne dane historyczne i procesy firmowe
Aplikacje produktywnościowe: Użytkownicy krytykują interfejs Jiry, ale nie mogą zrezygnować z jej rozbudowanych funkcji zarządzania projektami
Microsoft Office jest klasycznym przykładem złotej klatki – według badania przeprowadzonego przez Forrester, 78% profesjonalistów wyraża frustrację związaną z co najmniej jednym aspektem pakietu, ale tylko 8% poważnie rozważa alternatywy ze względu na dominację formatu i integrację w środowiskach korporacyjnych.
Rozwiązanie: Przekształcanie klatek w ogrody
Zrozumienie efektu złotej klatki pozwala nam projektować produkty, które utrzymują lojalność użytkowników poprzez pozytywne bodźce, a nie przez wymuszanie.
1. Matryca lojalności vs. satysfakcji
Oceniaj swój produkt według dwóch osi, aby zidentyfikować, czy budujesz klatkę czy ogród:
Wysoka lojalność, niska satysfakcja: Złota klatka (niebezpieczna) - użytkownicy pozostają, ale są niezadowoleni, co tworzy okazję dla konkurencji.
Wysoka lojalność, wysoka satysfakcja: Cyfrowy ogród (idealny) - użytkownicy pozostają z produktem z wyboru, nie z przymusu.
Niska lojalność, niska satysfakcja: Produkt przejściowy (zagrożony) - użytkownicy szybko odchodzą, nie widząc wartości.
Niska lojalność, wysoka satysfakcja: Odkrywana perełka (wymaga rozwoju) - użytkownicy lubią produkt, ale nie wykształcili jeszcze nawyku korzystania.
2. Strategia pięciu filarów zdrowej retencji
Zamiast budować złote klatki, twórz cyfrowe ogrody oparte na pięciu filarach:
Wartość progresywna: Produkt staje się bardziej wartościowy w miarę użytkowania, ale nie tworzy sztucznych barier wyjścia
Zbieraj dane użytkownika, aby zapewnić lepsze rekomendacje, ale oferuj prosty eksport danych
Przykład: Spotify tworzy coraz lepsze rekomendacje muzyczne wraz z czasem, jednocześnie umożliwiając przenoszenie playlist
Płynna interoperacyjność: Umożliwiaj współpracę z konkurencyjnymi produktami zamiast blokować
Oferuj API i integracje z konkurencyjnymi rozwiązaniami
Przykład: Microsoft Teams, mimo rywalizacji ze Slackiem, oferuje integracje cross-platformowe
Transparentna migracja: Jasno komunikuj koszty zmiany i ułatwiaj ją
Twórz narzędzia ułatwiające import i eksport danych
Przykład: Notion oferuje narzędzia do łatwej migracji z Evernote i innych konkurencyjnych rozwiązań
Świadoma akceptacja ograniczeń: Jawnie komunikuj kompromisy produktowe
Wyjaśniaj, dlaczego pewne ograniczenia istnieją, zamiast je ukrywać
Przykład: Basecamp otwarcie komunikuje, że nie oferuje wszystkich funkcji konkurencji, koncentrując się na prostocie
Ścieżki powrotu: Umożliwiaj łatwy powrót użytkownikom, którzy odeszli
Przechowuj dane i preferencje przez rozsądny okres po odejściu
Przykład: Netflix utrzymuje profile i historię oglądania przez 10 miesięcy po anulowaniu subskrypcji
3. Audit barier wyjścia
Przeprowadź systematyczną ocenę, aby wykryć ukryte złote klatki w swoim produkcie:
Bariery danych: Czy użytkownicy mogą łatwo eksportować swoje dane? Ciężki dostęp do własnych danych to główny czynnik wiążący użytkowników.
Bariery poznawcze: Ile czasu zajmuje nauka korzystania z twojego produktu i jak to wpływa na chęć zmiany? Wysoki koszt poznawczy sprawia, że użytkownicy są mniej skłonni do nauki nowych systemów.
Bariery sieci: Jak mocno produkt polega na efektach sieciowych? Produkty, które wymagają, aby "wszyscy byli na pokładzie", tworzą naturalne klatki.
Bariery finansowe: Jakie są ukryte koszty zmiany (niewykorzystane subskrypcje, kupione dodatki)? Opłaty z góry i nierefundowane zakupy zwiększają niechęć do zmiany.
Bariery emocjonalne: Jak produkt wykorzystuje strach przed utratą i niepewność? Niepewność co do alternatyw może być silniejsza niż znana frustracja.
Wdrożenie: Tworzenie zdrowych relacji z użytkownikami
Aby skutecznie przekształcić złote klatki w cyfrowe ogrody:
Wprowadź "dzień otwartych drzwi"
Okresowo przypominaj użytkownikom o opcjach eksportu danych i możliwości migracji
Pokaż, że cenisz ich wybór pozostania, a nie fakt, że nie mogą odejść
Mierz "lojalność entuzjastyczną" vs "lojalność z przymusu"
Wykraczaj poza standardowe NPS, pytając: "Gdybyś musiał zacząć od nowa, czy wybrałbyś ponownie nasz produkt?"
Śledź odpowiedzi w czasie, aby ocenić, czy budujesz ogród czy klatkę
Eliminuj "gorzkie końcówki"
Zidentyfikuj i napraw najbardziej frustrujące elementy podróży użytkownika
Badania pokazują, że 62% użytkowników, którzy odchodzą, podaje pojedynczy, szczególnie irytujący element jako główną przyczynę
Opracuj "strategię szczęśliwego powrotu"
Twórz specjalne ścieżki dla powracających użytkowników
Odkryj, dlaczego odeszli i co ich skłoniło do powrotu
Slack publicznie zobowiązał się do strategii "lojalności przez zadowolenie, nie przez uwięzienie", oferując pełny zwrot za niewykorzystany czas subskrypcji i umożliwiając eksport całej historii komunikacji. W rezultacie, pomimo rosnącej konkurencji, odnotowali 93% wskaźnik retencji przedsiębiorstw i pozytywne NPS.
Przeszkody we wdrażaniu
Główne wyzwania w transformacji złotych klatek w cyfrowe ogrody:
Krótkoterminowe metryki biznesowe: Presja na utrzymanie użytkowników może prowadzić do tworzenia barier wyjścia. Zespoły produktowe często czują się oceniane wyłącznie na podstawie wskaźników retencji, co zachęca do tworzenia sztucznych przeszkód.
Strach przed konkurencją: Obawa, że ułatwienie odejścia doprowadzi do masowego exodusu. Paradoksalnie, badania pokazują, że firmy oferujące łatwą migrację często cieszą się wyższą lojalnością.
Inercja projektowa: Trudność w przeprojektowaniu głęboko zakorzenionych mechanizmów retencji. Systemy zbudowane wokół zamkniętego ekosystemu wymagają znacznej przebudowy, by stać się bardziej otwartymi.
Aby je przezwyciężyć:
Wprowadź metryki długoterminowej wartości klienta obok wskaźników retencji
Przeprowadź eksperymenty A/B pokazujące, że zadowoleni użytkownicy są bardziej lojalni niż uwięzieni
Wykorzystuj historie sukcesu firm, które prosperują dzięki otwartym ekosystemom (np. GitHub)
Pamiętaj
Prawdziwa lojalność użytkowników wynika z dobrowolnego wyboru, a nie z braku alternatyw. Złote klatki mogą zapewnić krótkoterminową retencję, ale tworzą okazje dla konkurentów i erodują zaufanie.
Jak powiedział twórca Basecamp Jason Fried: "Jeśli budujesz biznes, który opiera się na utrudnianiu odejścia klientom, budujesz biznes na piasku."
W erze, gdy użytkownicy mają coraz więcej opcji i są coraz bardziej świadomi manipulacji produktowych, najbezpieczniejszą strategią długoterminową jest budowanie produktu tak wartościowego, że użytkownicy wybierają go każdego dnia na nowo, mając pełną świadomość i swobodę wyboru alternatywy.
🔥 MLA # tydzień 20
Minimum Lovable Action (MLA) to niewielki, możliwy do wykonania krok, który możesz podjąć w tym tygodniu, aby posunąć swój zespół produktowy do przodu - bez remontów, bez czekania na idealne warunki. Napraw błąd, popraw ankietę lub zareaguj na jedną informację zwrotną.
Dlaczego ma to znaczenie? Kultury nie buduje się z dnia na dzień. To suma konsekwentnych, małych działań. MLA tworzy dynamikę - jedno małe zwycięstwo na raz - i zamienia te zwycięstwa w trwałą zmianę. Małe działania, duży wpływ!
MLA: Zorganizuj "Wymianę Miejsc"
Dlaczego ma to znaczenie:
Zespoły produktowe często cierpią z powodu ograniczonego zrozumienia wyzwań i perspektyw innych ról. Ta izolacja prowadzi do nieefektywnej komunikacji, nierealnych oczekiwań i napięć międzyzespołowych. Krótka, ustrukturyzowana "Wymiana Miejsc" buduje empatię, ujawnia ukryte przeszkody w procesach i tworzy podstawy dla bardziej zintegrowanego podejścia do rozwoju produktu. Ta prosta praktyka może zainicjować długoterminową transformację kultury współpracy w organizacji.
Jak wykonać:
Wybierz odpowiednich uczestników:
Zidentyfikuj dwie komplementarne role, które często współpracują, ale mają różne perspektywy (np. projektant UX i deweloper, product manager i marketer, inżynier i specjalista od obsługi klienta)
Wybierz osoby, które są otwarte na naukę i wykazują ciekawość pracy innych
Zaangażuj osoby z podobnym poziomem doświadczenia, aby zminimalizować stres związany z zadaniem
Wybierz odpowiedni czas i ramy:
Zaplanuj wymianę na godzinę - wystarczająco długo, aby zagłębić się w pracę, ale krótko, by zachować intensywność
Wybierz moment o niskim natężeniu pracy, gdy nie ma krytycznych terminów
Rozważ zaplanowanie wymiany podczas normalnego dnia pracy, a nie jako dodatkowe obciążenie
Sformułuj zaproszenie:
Przedstaw wymianę jako możliwość nauki, a nie oceny: "To okazja, aby lepiej zrozumieć, z czym mierzy się druga osoba"
Podkreśl korzyści dla obu stron: "Dzięki temu doświadczeniu będziemy mogli efektywniej współpracować w przyszłości"
Wyjaśnij, że chodzi o zrozumienie perspektywy, a nie o wykonanie zadań perfekcyjnie: "Celem nie jest zostanie ekspertem, ale zrozumienie kontekstu pracy drugiej osoby"
Przygotuj uczestników:
Poproś każdego uczestnika o przygotowanie krótkiego zadania dla drugiej osoby, które reprezentuje typowy element ich codziennej pracy
Zadanie powinno być dostępne dla początkujących, ale nadal pokazywać realistyczne wyzwania
Poproś uczestników o przygotowanie krótkiej listy pytań, które chcieliby zadać o pracy drugiej osoby
Przeprowadź wymianę z intencją:
Rozpocznij od 10-minutowego wprowadzenia, w którym każda osoba wyjaśnia kontekst swojej pracy i bieżące zadania
Daj 40 minut na aktywną pracę, w której każda osoba próbuje rozwiązać przygotowane zadanie drugiej osoby
Zachęcaj do zadawania pytań i myślenia na głos podczas rozwiązywania problemów
Osoba, której rolę się poznaje, powinna być dostępna, aby oferować wskazówki, ale nie przejmować kontroli
Kontynuuj po wymianie:
Zakończ 10-minutową sesją omówienia, w której każdy uczestnik dzieli się jednym zaskoczeniem i jednym spostrzeżeniem
Zachęć uczestników do zidentyfikowania jednej konkretnej zmiany, którą mogą wprowadzić w swojej pracy, aby ułatwić współpracę
Podziel się kluczowymi spostrzeżeniami z szerszym zespołem podczas następnego spotkania
Rozważ zaplanowanie kolejnych wymian między innymi rolami w przyszłości
Oczekiwane korzyści:
Natychmiastowe korzyści:
Szybko ujawnia nieporozumienia między rolami i zespołami
Identyfikuje nieefektywne procesy i narzędzia, które utrudniają współpracę
Tworzy wspólny język i kontekst dla przyszłych dyskusji
Poprawa relacji/kultury:
Buduje wzajemny szacunek i docenianie złożoności różnych ról
Zmniejsza tendencję do obwiniania innych za opóźnienia lub problemy
Tworzy więzi międzyludzkie, które wykraczają poza formalne interakcje zawodowe
Długoterminowe dostosowanie organizacyjne:
Zachęca do tworzenia bardziej realistycznych harmonogramów i oczekiwań
Wspiera bardziej zintegrowane podejście do rozwiązywania problemów
Stopniowo przekształca kulturę organizacyjną z silosowej w kolaboracyjną
Podziel się swoim doświadczeniem z wyzwaniem za pomocą hashtagu #MLAChallenge! Opowiedz, jakie role zamieniłeś miejscami i jakie najważniejsze wnioski wyciągnąłeś z tego doświadczenia.
📝 Foundation Sprint (artykuł gościa by Marcin Chyła)
Entuzjasta szczupłego i zwinnego podejścia do budowania produktów. Od ponad 10 lat w rolach produktowych — wierzę, że nie ma dobrych produktów bez dobrego zespołu i zdrowych relacji.
Inicjator konferencji Agile on the Boat, meetupu Product Peak oraz współzałożyciel społeczności Agile Wrocław.
Bliskie są mi praktyki i frameworki wspierające szybką walidację — szczególnie cenię Design Sprint, a także podejście oparte na metrykach. Z biegiem lat więcej radości sprawia mi walidacja pomysłów i odpalanie nowych, niż doprowadzanie zaczętych do końca :)
Po godzinach — amator wspinaczki, boksu i stolarstwa.
Przeprowadziłem kilkanaście sesji Design Sprintu. Lubię tę metodę i doceniam jej wartość. Wierzę w siłę pracy zespołowej, gdy kilka osób skupia się na jednym wyzwaniu produktowym. Warsztaty to zdecydowanie “moja bajka”. Nic dziwnego, że dołączyłem do grona early adopterów nowego frameworka – Foundation Sprint, stworzonego przez Jake’a Knappa i Johna Zeratsky’ego. W tym artykule dzielę się pierwszymi wrażeniami.
Foundation Sprint – jak sama nazwa wskazuje – to narzędzie do budowania fundamentu. To dwudniowy warsztat, który przeprowadza się przed Design Sprintem. Mamy przed sobą duże wyzwanie, ale nie wiemy jeszcze, jak się za nie zabrać. Czy stworzyć aplikację mobilną, czy może postawić na rozwiązanie webowe? A może zamiast nowej technologii lepiej uruchomić punkt obsługi klienta? Albo zaoferować wirtualnego asystenta? Foundation Sprint pomaga wybrać właściwą strategię działania. Nie skupia się na szczegółach – pokazuje jednak kierunek.
Foundation Sprint powstał, bo wielu zespołom brakowało porządnego startu. Autorzy zauważyli, że founderzy często „pędzą do rozwiązań” bez wystarczającego zrozumienia problemu i kierunku.
Zanim więc wybierzemy najlepsze podejście, potrzebujemy solidnej podstawy. Chodzi o wspólne zrozumienie: kim jest nasz klient i z jakim problemem się mierzy. I właśnie na tym skupia się pierwszy dzień warsztatu.
Pracując z zespołem, określiliśmy główną personę – Annę, liderkę zespołu sprzedaży w firmie B2B, która ma dość rozproszonych narzędzi i braku wsparcia przy onboardingu nowych handlowców.
Serio, Jake? To ma być ten „game changer”? Na to czekaliśmy prawie 10 lat?
W całej swojej „sprintowej” karierze nigdy nie zaczynałem od razu od Design Sprintu! Zawsze poprzedzał go jednodniowy warsztat, który nazywam Problem Framingiem. W jego trakcie wybieraliśmy kluczowego użytkownika, zdefiniowaliśmy najważniejszy problem oraz kontekst, w którym on występuje. Dyskutowaliśmy też, jaką wartość przyniesie rozwiązanie tego problemu.
Prawdę mówiąc, byłbym rozczarowany Foundation Sprintem, gdyby nie sprytne podejście do analizy konkurencji. Jeszcze pierwszego dnia warsztatu szukamy odpowiedzi na pytania: kto jest naszym największym konkurentem albo jak klient radzi sobie dziś z problemem.
W przypadku Anny i jej zespołu – to po prostu Google Docs, prywatne checklisty, Slack i „szeptany onboarding”. To jednak dopiero początek. Gdy już nazwiesz konkurencję, musisz zdecydować, w czym dokładnie chcesz być lepszy. W naszym przypadku postawiliśmy na aspekt spójności i automatyzacji – chcemy oferować narzędzie, które nie tylko centralizuje wiedzę, ale też aktywnie wspiera proces wdrażania.
Framework podsuwa gotowe obszary do analizy, ale też zachęca, by stworzyć własne – dopasowane do naszej branży i sytuacji. To bardzo praktyczne i odświeżające podejście.
Prawdziwa magia zaczyna się drugiego dnia warsztatu dzięki narzędziu o nazwie “Magic Lenses”. Zanim jednak po nie sięgniemy, każdy uczestnik tworzy krótki opis swojego pomysłu na rozwiązanie. Jedna osoba proponuje aplikację mobilną – prostą i zawsze pod ręką. Inna widzi większą wartość w Slack bocie – idealnym do szybkich interakcji w narzędziu, z którego zespół i tak już korzysta. Ktoś inny stawia na webowego chatbota z AI. Różne pomysły – ale które podejście jest najlepsze? Czas założyć soczewki.
Pierwsza z nich to Customer Lens. Oceniamy, na ile dane podejście jest użyteczne i atrakcyjne dla klienta. Czy jest proste w użyciu? Czy dobrze rozwiązuje jego problem? Załóżmy, że w tym przypadku najwyżej wypada aplikacja mobilna.
Druga to Pragmatic Lens, przez którą patrzymy realistycznie – ile czasu i zasobów potrzebujemy, żeby zbudować dane rozwiązanie? Zespół uznaje, że najszybszym i najtańszym podejściem będzie Slack bot.
Kolejna to Growth Lens. Oceniamy, czy podejście przyciągnie nowych klientów i czy będzie łatwe do rozwijania w przyszłości. Slack bot znów wypada najlepiej – jest popularny, dobrze znany w świecie korporacyjnym, a możliwości jego rozbudowy są szerokie.
Czwarta to Money Lens – patrzymy, gdzie możemy zarobić najwięcej. Aplikacja mobilna wygrywa, bo kluczowe funkcje można schować za paywallem, co pozwala na łatwą monetyzację.
W tym momencie mamy remis. Zarówno aplikacja mobilna, jak i Slack bot mają mocne prawe sierpowe. W takiej sytuacji warto dodać własną, niestandardową soczewkę – dopasowaną do kontekstu naszej firmy. Na przykład: które podejście najlepiej odróżnia nas od konkurencji? To właśnie ta dodatkowa perspektywa może posłać przeciwnika na deski.
Ostateczna decyzja należy do osoby decyzyjnej, ale Magiczne Soczewki sprawiają, że zespół ma wspólny język do rozmowy. Dzięki nim podejmujemy decyzje bardziej świadomie, a nie tylko na podstawie przeczucia.
Warsztat kończymy mocną hipotezą: Jeśli stworzymy Slack bota, który automatyzuje proces onboardingu dla nowych członków zespołu, to pomożemy liderom sprzedaży, takim jak Anna, w szybszym, efektywniejszym i spójnym wprowadzaniu nowych pracowników. Przy okazji: widzimy też mocny backup: aplikację mobilną.
I to jest wyzwanie, które możemy zaatakować Design Sprintem.
Podsumowując
Foundation Sprint korzysta ze sprawdzonych metod, które dobrze znamy z Design Sprintu. Znów pracujemy w multidyscyplinarnym zespole. Znów czyścimy kalendarze i utrzymujemy pełne skupienie na procesie. Znów mamy Decidera i facylitatora. I znów setki post-itów, silent brainstormingi, dot-voting.
Ale jest jedna kluczowa różnica. Design Sprint uruchamiamy, gdy problem jest już dobrze zrozumiany, a wybrane rozwiązanie trzeba zweryfikować z użytkownikami. Dlatego kończy się on makietą i testami, a nad całością czuwa zespół odpowiedzialny za dostarczenie rozwiązania.
Foundation Sprint to „prequel”. Sprawdza się wtedy, gdy problem jest złożony, nie do końca zdefiniowany, a możliwych podejść jest wiele. Tu spotykają się osoby odpowiedzialne za strategię — po to, by wspólnie wybrać właściwy kierunek.
PS: Książka opisująca powyższy framework jest dostępna w sprzedaży od 22 kwietnia
https://www.amazon.pl/Click-Make-What-People-Want/dp/1668072114
Jeżeli ktoś chce się zapoznać z nowym frameworkiem zapraszamy na pierwszy hackathon produktowy w Polsce, gdzie wypróbujemy tę metodę.
Zapisy: TUTAJ
📝 Motywacja.exe — czyli jak nie zawiesić się przy wymagających projektach 👾
Trudne projekty w IT to jak spotkanie z mityczną hydrą - odcinasz jeden problem, a wyrastają dwa nowe. Kto z nas nie miał tego momentu, gdy patrząc na listę zadań pomyślał: "To niemożliwe. Chyba zostanę hodowcą alpak w Peru"?
Ale co ciekawe, niektórzy z nas mimo wszystko zostają. Ba, nawet znajdują w tym jakąś przewrotną przyjemność! Ci sami ludzie, którzy potrafią prokrastynować 3
Keep reading with a 7-day free trial
Subscribe to 💜 PRODUCT ART 💜 to keep reading this post and get 7 days of free access to the full post archives.