Jak product trio eliminuje silosy i przyspiesza delivery – lekcje z Muse i Tesco #EN325

Nota: To są moje notatki z majowego wydarzenia ProductTank London 2024. Wszystkie przemyślenia, obserwacje i wnioski pochodzą od prelegentów: Zuzany, Aldera i Jakuba z zespołu Muse oraz Amandy i Johna z Tesco. Nie dodaję własnych interpretacji – przekazuję to co usłyszałem, tak jak zostało przedstawione przez praktyków.

TL;DR

„Product trio” to autonomiczna jednostka PM + designer + engineering manager, która wspólnie odpowiada za rezultaty zamiast przekazywać sobie pracę jak pałeczkę w sztafecie
Model ten mityguje cztery kluczowe ryzyka produktowe: business viability, value, usability i feasibility dzięki obecności wszystkich perspektyw przy każdej decyzji
Zespół Muse stracił 3-4 miesiące na funkcjonalność której nikt nie używał, ponieważ PM i engineer zgodzili się na feature bez konsultacji z designerem i bez walidacji z klientami
Trio skaluje się wertykalnie w organizacji – od poziomu IC przez directors i VPs aż do CPTO, co zapewnia akceptację na każdym szczeblu przy dużych inicjatywach
Backend engineer uratował Muse 6 miesięcy pracy podczas jednej rozmowy z klientem, gdyż rozpoznał że „potrzeba” klienta to w rzeczywistości obejście problemu starego systemu
Frameworki jak Opportunity Solution Tree, value mapping i slicing board pomagają trio systematycznie przechodzić od identyfikacji problemu do testowania rozwiązań
Największym wyzwaniem wewnętrznym nie jest brak narzędzi, lecz budowanie relacji w trio – gdy jedna osoba milczy, zespół traci kluczową perspektywę

Czym jest product trio i dlaczego tradycyjny podział przestał działać

Według Zuzany z Muse, standardowa definicja „product trio” obejmuje trzy role: product manager, product designer i engineering manager. Problem jednak leży gdzie indziej – samo posadzenie tych osób w jednym zespole nie gwarantuje współpracy.

Historia pokazuje typowy scenariusz: PM definiuje zakres i pisze brief. Designer otrzymuje ten dokument (czasem już z założonym rozwiązaniem) i projektuje według własnego uznania. Następnie przekazuje gotowy design zespołowi inżynierskiemu z komunikatem „zbudujcie to”. Rezultat? Każda rola pracuje w izolacji, mimo że formalnie znajdują się w tym samym zespole. Zamiast trio powstaje kaskadowy model przekazywania odpowiedzialności.

Prawdziwe trio działa inaczej. Jak wyjaśniają prelegenci z Muse, to autonomiczna cross-functional jednostka wspólnie odpowiadająca za osiągnięty rezultat. Nie ma momentów „przekazania” w stylu „moja część się skończyła, teraz to Twoja sprawa”. Trio wspólnie posiada całą strategię produktową, dlatego że w iteracyjnym procesie rozwoju wszyscy trzej uczestniczą na każdym etapie.

Zaangażowanie trio na każdym etapie cyklu produktowego

Alder z Muse podkreśla istotę zaangażowania trio w każdy krok procesu:

Discovery (badanie):

PM i design pracują najbliżej podczas eksperymentów i rozmów z klientami
Engineering uczestniczy minimum w pierwszej, środkowej i ostatniej rozmowie z każdym klientem
Inżynierowie wnoszą odmienną perspektywę i zadają pytania których PM czy designer by nie zadał

Solutioning (tworzenie rozwiązań):

Design i engineering wspólnie budują prototypy, piszą fragmenty kodu do eksperymentów
PM reprezentuje głos klienta i ocenia business value oraz viability
Wszyscy trzej wspólnie oceniają feasibility w 15-minutowej rozmowie przed rozpoczęciem głębszej pracy

Delivery (wdrożenie):

Engineering i PM prowadzą deployment – kod trafia do produkcji, PM koordynuje wprowadzenie na rynek
Design pozostaje aktywny w pętli feedbacku umożliwiając szybkie pivoty
Wspólny pomiar sukcesu i iteracja na podstawie reakcji klientów

Ta możliwość szybkiej 15-minutowej synchronizacji między trzema osobami przed zagłębieniem się w pracę radykalnie skraca czas podejmowania i wdrażania decyzji.

Cztery ryzyka z trzech perspektyw – konkretny rozkład odpowiedzialności

Według Aldera, istota pracy w trio sprowadza się do wspólnej mitygacji kluczowych ryzyk przez pryzmat trzech odmiennych perspektyw:

Product Manager analizuje:

Zgodność z business strategy
Wpływ na kluczowe OKRs
Viability rynkową i potencjał sukcesu

Designer ocenia:

Desirability – czy klienci tego faktycznie chcą
Usability – czy będą w stanie z tego korzystać
Inclusive design i accessibility dla wszystkich segmentów użytkowników

Engineering weryfikuje:

Feasibility techniczne w obecnym stacku
Build limitations i constraints
Potrzeby refactoringu lub code cleanup
Zależności od innych zespołów (build dependencies)

Amanda z Tesco podkreśla znaczenie ostatniego punktu w dużych organizacjach. Nie budujesz w próżni – musisz wiedzieć które zespoły API, backend czy inne platformy będą musiały wesprzeć implementację danej funkcjonalności.

Ta zdolność do oceny ryzyk z trzech kątów otwiera przestrzeń dla innowacji. PM dąży do zbudowania czegoś wartościowego. Zuzana jako designer pragnie żeby było estetyczne i robiło wrażenie. Jakub jako engineering manager chce wykorzystać technologię która ekscytuje cały zespół inżynierów.

15-minutowa rozmowa we trójkę przed rozpoczęciem właściwej pracy – i na stole leżą już trzy odmienne perspektywy. To nie jest kompromis, lecz innowacja przez różnorodność.

Skalowanie modelu trio w strukturze organizacyjnej

Alder wyjaśnia mechanizm działania: trio funkcjonuje zarówno wertykalnie jak i horyzontalnie. Muse ma obecnie ponad 20 zespołów produktowych, każdy ze swoim trio na poziomie indywidualnego współpracownika. Jednak to dopiero początek struktury.

Zuzana komunikuje się z innymi designerami w różnych zespołach. Jakub współpracuje z pozostałymi engineering managerami. Alder łączy się z innymi PMami. Gdy funkcjonalność wymaga współpracy między zespołami, znacznie łatwiej jest zaangażować więcej osób, zwiększyć akceptację i maksymalizować wpływ.

Trio skaluje się również pionowo w hierarchii:

Director level – zawsze obecny director product, design i engineering
VP level – identyczna struktura, głosy reprezentujące każdą domenę
CPTO level – Muse ma CPTO zamiast rozdzielenia na CTO i CPO

Kiedy pomysły docierają do CPTO lub zarządu, akceptacja jest już zapewniona na każdym szczeblu. Nie ma sytuacji gdzie engineering na końcu procesu stwierdza „to się nie da zrobić”. Wszystkie trudne pytania zostały zadane i odpowiedziane na początku, na każdym poziomie organizacji.

Historia porażki: 4 miesiące zmarnowanego developmentu

Jakub dzieli się konkretnym przypadkiem nieudanej inicjatywy. Kilka lat temu on i Alder uczestniczyli w spotkaniu ze sprzedażą. Przedstawiciele sales argumentowali: klienci potrzebują nowego statusu dla rezerwacji która jeszcze nie jest potwierdzona. Hotel mógłby negocjować szczegóły z gościem przed finalnym potwierdzeniem. Brzmiało logicznie – system zawierał już podobną funkcjonalność, nieaktywną, ale istniejącą.

Sales zapewniał „mamy dziesiątki klientów w kolejce do tej funkcji, zarabiamy fortunę jeśli to wdrożymy”. PM i engineering zgodzili się podczas spotkania. Kluczowy błąd: nie konsultowali decyzji z Zuzaną ani pozostałym zespołem inżynierskim. Wrócili i powtórzyli zespołowi tę samą narrację – świetna funkcjonalność której wszyscy pragną, gwarantowane zyski, możliwa wcześniejsza emerytura po wdrożeniu.

Wszyscy byli podekscytowani. Funkcjonalność spędziła następnie 3-4 miesiące w „development hell”. Kolejne problemy wymuszały kolejne poprawki. W końcu wdrożyli ją do produkcji i obserwowali szybką porażkę. Nikt nie używał. Nikt tego nie potrzebował. Klienci szukali czegoś zupełnie innego – najprostszego sposobu na zarządzanie dostępnością w skali dla dużych klientów, agencji turystycznych i firm.

Druga próba kilka lat później:

Identyczne okoliczności, podobne prośby. Tym razem jednak zastosowali metodę trio:

Rozmowy z klientami przed jakimkolwiek kodem
Designerzy konsultowali z backend engineerami, content team z QA
Frontend engineers synchronizowali się z PMami – wszyscy na tej samej linii
Każdy rozumiał dostarczaną wartość, nie tylko „zadanie do wykonania”

Rezultat był radykalnie inny. Zbudowali kompletnie nowe narzędzie do zarządzania dostępnością, odblokowali nowe verticale i możliwości biznesowe. Jak podkreśla Jakub, wszyscy znajdowali się na tej samej stronie więc proces przebiegł szybko w małych pętlach iteracyjnych z jasną długoterminową wizją.

Frameworki przyspieszające discovery

Alder opisuje systematyczne podejście zespołu Muse do przechodzenia przez discovery coraz efektywniej. Wykorzystują zestaw modeli które umożliwiają szybkie przejście od customer outcome do testowania konceptów.

Opportunity Solution Tree stanowi punkt startowy:

Definicja głównego rezultatu do dostarczenia klientom
Podział na slices/themes
Eksploracja opportunities w każdym slice

Value mapping zajmuje około 30 minut we trójkę:

Oś X: technically difficult vs easy to build
Oś Y: huge value for users vs low value
Prawy górny kwadrant (trudne + wartościowe) = strategiczne inicjatywy wymagające większych zespołów i czasu
Lewy górny kwadrant (łatwe + wartościowe) = „quick wins” gdzie spędzają najwięcej energii
Dolne kwadranty = kandydaci do obniżenia priorytetu, wymaga uczciwości co do odpuszczania

Opportunity assessment dla każdej większej inicjatywy:

Lean canvas lub business canvas (zależnie od preferencji organizacji)
Identyfikacja userów, problemów i metryk
Data analyst może natychmiast kwestionować metryki – „czy to mierzalne, czy dysponujemy danymi?”

Slicing board (Jurgen Apello, Startup Scaleup):

Dla każdego value incrementu: jakie pains użytkowników rozwiązuje
Jakie gains dostarcza naprawienie
Co można zmierzyć – jakie learningi wynikną
Decyzja: persevere, pivot or scrap – gotowość do porzucenia jeśli nie ma sensu

Cała filozofia sprowadza się do tego żeby po dostarczeniu incrementu móc zdecydować: kontynuujemy, pivotujemy w innym kierunku, czy scrappujemy i skupiamy na następnej okazji.

Praktyczne rytuały zespołu Muse

Discovery jako mindset, nie checkbox

Zuzana podkreśla fundamentalną różnicę: discovery nie jest polem do odznaczenia – to sposób myślenia. Porażka nauczyła zespół że wszyscy muszą być zaangażowani od momentu rozpoczęcia projektu. Nie tylko trio – całość zespołu włącznie z data analystami, QA i developerami.

Powód jest prosty. Wszyscy mają świetne pomysły. Gdy są częścią discovery, zmieniają sposób myślenia o produkcie. Pytają „czy faktycznie rozwiązaliśmy omawiany problem?” zamiast „zróbmy funkcjonalność i naprzód”. Autentycznie zaczynają dbać o klienta, nie tylko o feature.

Zespół korzysta z Discovery Board w Miro – szablon zawierający najczęściej używane elementy discovery powtarzane w projektach. Podczas rozpoczęcia dużego projektu następuje podział: Alder bierze tę część, Zuzana inną, data analyst kolejną. Wszyscy pracują asynchronicznie, wszyscy widzą postęp. Oszczędza to czas na meetingach i zachowuje transparentność.

Struktura wywiadów – zaangażowanie całego zespołu

Zuzana opisuje proces przygotowania. Przed pierwszym wywiadem tworzy scenariusz i przedstawia go Alderowi, Jakubowi, czasem całemu zespołowi. Najgorsza zmarnowana okazja? 15 wywiadów później QA engineer pyta „sprawdzałaś to?” – nie sprawdzała, jednak 15 wywiadów wcześniej to pytanie było by cenne.

Dlatego zawsze dzieli scenariusz z zespołem przed pierwszym wywiadem. Dostosowują pytania jeśli zachodzi potrzeba. Następnie zapraszają pozostałych członków zespołu kolejno na różne wywiady – nie muszą być na każdym, ale muszą uczestniczyć w procesie. Buduje to empatię. Ludzie zaczynają autentycznie rozumieć klienta.

Zasady podczas wywiadów:

Pozwalanie klientowi mówić maksymalnie dużo
Każdy wywiad przebiega inaczej, bo każdy klient działa odmiennie (pytanie o business model na początku jest kluczowe)
Unikanie sytuacji gdzie kilka osób chaotycznie zadaje pytania jednocześnie
Debrief po wywiadzie – trio + zespół dyskutuje co każdy wyciągnął, jakie wnioski

Szybka walidacja przy pilnych inicjatywach

Gdy pojawia się coś naprawdę pilnego wymagającego natychmiastowego działania, Zuzana opisuje metody szybkiej walidacji:

Techniki ekspresowej weryfikacji:

Demo videos z wariantami udostępniane klientom
Szybkie testy użyteczności
Gotowa pula klientów przyzwyczajonych do współpracy – brak potrzeby rekrutacji od zera
Weryfikacja czy rozwiązanie jest skalowalne dla wielu przypadków, nie tylko dla eskalującego klienta

Ten ostatni punkt jest kluczowy. Często jedna osoba eskaluje problem bardzo głośno. Łatwo jest zbudować rozwiązanie dla jednego przypadku. Trio musi jednak upewnić się że rozwiązanie ma sens w szerszym kontekście i pomoże większej grupie klientów, nie tylko najgłośniejszemu.

Weekly retrospectives mimo dwutygodniowych sprintów

Alder wyjaśnia decyzję o cotygodniowych retro mimo dwutygodniowych sprintów. Zapewnia to regularny punkt zborny, przegląd bieżącej sytuacji i spojrzenie w przyszłość. Dodatkowo pomaga w ustalaniu priorytetów i komunikacji z leadership.

W bieżącym roku wybrali motyw kosmiczny. Po łodziach żaglowych przez rok, następnie rakietach przez kolejny rok – dokąd teraz? Kosmos reprezentuje rozciągnięcie ambicji dla osiągnięcia większych celów.

Cztery stałe elementy cotygodniowego retro:

Co pomogło posunąć się naprzód w minionym tygodniu
Co powstrzymało (planowane ale niezrealizowane)
Przyszłe ryzyka na nadchodzący tydzień/sprint
Co wywołało dobre samopoczucie – podziękowania dla zespołu

Jak zaznacza Alder, budowanie produktu to team sport. Retro nie może ograniczać się do „zrobiliśmy to, naprawimy tamto”. Należy celebrować zespół, szczególnie niezauważonych bohaterów. Ludzie ciężko pracują i mają wartościowe pomysły – muszą to usłyszeć.

Transformacja Tesco: od kaskady do continuous discovery

Wpływ Teresy Torres na zmianę kultury

Tesco przeszło masywną transformację agile na początku 2023 roku w celu redukcji procesów przekazywania pracy. Jak wspomina John, Teresa Torres osobiście przyjechała do Tesco kilka lat wcześniej, przeprowadziła wszystkich przez continuous discovery, i organizacja to wdrożyła.

Widać to w codziennej praktyce. Discovery syncs 2x w tygodniu, przegląd wywiadów z klientami każdego tygodnia. Wykorzystują również Chattermill – narzędzie do agregowania feedbacku z rozmaitych źródeł. Cotygodniowo analizują te dane razem z wywiadami, budując Opportunity Solution Tree na podstawie tego co słyszą.

Amanda podkreśla znaczenie zanurzenia inżynierów w problem space, włącznie ze słuchaniem customer feedbacku. Daje im szerszy kontekst dla rozumienia całościowego opportunity, nie tylko gotowych rozwiązań. Często ludzie są zaskoczeni jak innowacyjne pomysły pochodzą od inżynierów gdy są zsynchronizowani z zespołem co do rozwiązywanego problemu.

Design jams – kolaboracja w czasie rzeczywistym

John szczegółowo opisuje proces „design jams” praktykowany w Tesco:

Anatomia design jam:

Wielu designerów jednocześnie (UI designers + UX designers + content designers)
Wszyscy pracują na żywo w Figmie na wspólnym canvasie
Bardzo szybka dywergencja pomysłów z różnych perspektyw i doświadczeń
Bardzo szybka konwergencja dzięki rozmowom na żywo w narzędziu
2-3 godziny = eksploracja obszernego problem space + zawężenie do konkretnego rozwiązania

Cotygodniowo prezentują postępy inżynierom podczas design review. Może to być bardzo wczesny etap, czasem tylko szkic. Zwykle jednak jest to prototyp Figma z fragmentem journey. Po otrzymaniu feedbacku od engineeringu wracają do design jam, iterują dalej i poprawiają.

Dwutygodniowe cykle prototyp-test-nauka

John opisuje „design sprint” który mieszczą dwukrotnie w ramach dwutygodniowego sprintu:

Jeden cykl design sprintu:

Czwartek-piątek: Design jam – wybór pomysłu z opportunity solution tree, ideation w Figmie, tworzenie prototypu, przygotowanie testu
Weekend: Uruchomienie testu niemoderowanego na platformie user testing
Poniedziałek rano: Przegląd danych i spostrzeżeń z testów
Wtorek: Dyskusja z inżynierami z pełnym obrazem sytuacji – działa czy nie działa

Pozwala to przejść przez 3-4 różne pomysły w ciągu dwóch tygodni z konkretnymi danymi dla każdego. John wspomina ciekawy przykład – podczas testowania meal planning napisali „three ingredients”. Wszyscy uczestnicy testu skupili się wyłącznie na tym fragmencie – „trzy składniki oznaczają szybkie i łatwe przygotowanie, to najważniejsze dla mnie”.

Amanda dodaje istotny element: w Tesco starają się włączać interesariuszy i design przez cały sprint, nie tylko na końcu. Inżynierowie mają możliwość naprawienia problemów wcześniej zanim coś dotrze do klientów. Design może dostosować się w trakcie. Przesuwają całą iterację na początek gdzie tylko to możliwe.

Backend engineer który zaoszczędził pół roku pracy

Jakub dzieli się przypadkiem idealnie ilustrującym wartość inżynierów w discovery. Niedawno byli z wizytą u high-profile klienta. Zabrali ze sobą dwóch backend engineerów. Podczas przechodzenia przez workflow klienta coś wydawało się dziwne w sposobie wykonywania pewnych operacji.

Jeden z backend engineerów słuchał przez kilka godzin. Nie przerywał, obserwował i słuchał. Następnie zaczął zadawać pytania o konkretny workflow. W ciągu pół godziny rozmowy wyperswaował klientowi kawałek pracy która zajęłaby Muse 6 miesięcy developmentu.

Pod stołem sekretne przybicia. Uratowali pół roku pracy wyłącznie dlatego że engineer był obecny, rozumiał głęboko co faktycznie wymaga zrobienia technicznie i przeciął wszystkie elementy które klient opisywał z nawyku „bo tak działał poprzedni system”. To były obejścia problemów które klient rozwinął wokół limitacji starego systemu.

Jak zauważa Jakub, jeśli masz takie historie i możesz je dzielić z innymi developerami w organizacji – zmienia to dynamikę. Developerzy z natury nie lubią budować dla samego budowania. Wolą siedzieć przy komputerze i stukać w mechaniczne klawiatury. Ale jeśli pokazujesz „możesz mieć takie spostrzeżenia, możesz zaoszczędzić miesiące pracy jedną rozmową” – nagle wszyscy chcą uczestniczyć w discovery.

Zestaw narzędzi wspierających trio

Muse wykorzystuje:

Miro – discovery boards, nieskończone płótno do asynchronicznej współpracy
Gainsight – dostęp w czasie rzeczywistym do danych ilościowych i jakościowych bez oczekiwania na data engineera
UserVoice – platforma feedbacku gdzie użytkownicy upvotują problemy, zespół ma bezpośredni kontakt do zainteresowanych
Figma – prototypowanie i design jams

Tesco stosuje:

Miro – collaborative boards dla całego zespołu
Figma – design jams gdzie wszyscy pracują na żywo na wspólnym canvasie
User Testing – platforma do testów niemoderowanych uruchamianych przez weekend
Chattermill – agregowanie feedbacku z rozmaitych źródeł, cotygodniowy przegląd
Confluence – zarządzanie wiedzą dla szybkiego wdrażania nowych osób

Dlaczego Gainsight stanowi przełom

Alder podkreśla kluczowy aspekt Gainsight: szybkość dostępu do danych. Wcześniej korzystali z Heap, jednak Gainsight oferuje lepszy balans danych ilościowych i jakościowych. Mogą zbierać informacje bez angażowania data engineera. Nikt nie musi grzebać w bazie danych.

We trójkę mogą rozmawiać i w trakcie tej rozmowy walidować hipotezy: „myślę że ludzie używają tego w taki sposób” – i mogą to sprawdzić natychmiast, bez oczekiwania. Po wypuszczeniu czegoś do beta-testerów tworzą szybką ankietę skierowaną wyłącznie do tej grupy.

Każdy kto wysyłał ankiety w B2B wie: wysyłasz do tysiąca osób, odpowiada pięć. Frustrujące. Z Gainsight średni wskaźnik odpowiedzi wynosi około 40-50%. Przeskok z typowego 1% zmienia wszystkie zasady gry.

Realne wyzwania w codziennej pracy trio

Nadmiar spotkań:

Discovery syncs zajmują cztery godziny tygodniowo w Tesco (2x po 2h)
Próba redukcji do dwóch godzin spowodowała natychmiastowy spadek continuous discovery, zespół przestał słuchać klientów
Rozwiązanie: commitment do czterech godzin z zasadą – brak tematu oznacza odwołanie
Identycznie z design reviews – brak materiału do prezentacji? Spotkanie odwołane, nie siedzimy dla samego siedzenia

Strefy czasowe w rozproszonym zespole:

Zespół inżynierski Tesco znajduje się w Bangalore
Większość spotkań musi odbywać się przed 13:00 czasu UK dla optymalnego pokrycia czasowego
Wymaga planowania i akceptacji że nie wszyscy mogą uczestniczyć we wszystkim

Synchronizacja między platformami:

Różne platformy (web, app) rozwijają się różnymi prędkościami
Poszczególne zespoły inżynierskie mają odmienne tempo
Jeden zespół może nie być gotowy przez miesiąc lub dwa po drugim
Konieczność akceptacji tej asynchroniczności i planowania z nią

Zarządzanie wiedzą:

Ludzie naturalnie przychodzą i odchodzą z zespołu
Uporządkowane tablice Miro są absolutnie kluczowe
Confluence musi być dobrze zorganizowany
Nowa osoba powinna móc wejść, przejrzeć materiały i szybko zrozumieć sytuację

Forming and norming jako największe wyzwanie wewnętrzne

John podkreśla istotny punkt: największym wyzwaniem wewnątrz trio jest osiągnięcie równowagi i zbudowanie autentycznych relacji. Wszyscy muszą czuć że mają głos. Wszyscy muszą rozumieć jak komunikować się z drugą osobą oraz rozumieć ich style pracy.

Jeśli istnieje brak równowagi – jedna cicha osoba która nie kontrybuuje – to nie działa. Trzeba to naprawić żeby każdy miał swój głos. To prawdopodobnie największy challenge – „forming and norming” relacji zespołowych dla faktycznego funkcjonowania.

Bezpośredni przełożeni jako zewnętrzne wyzwanie

Jakub bardzo uczciwie przyznaje: „Podczas gdy my byliśmy zaangażowani w pomysł, reszta organizacji potrzebowała trochę czasu na nadrobienie zaległości. Te wczesne dyskusje były bardzo skomplikowane, ponieważ każdy z nas był popychany w odmiennym kierunku przez swoich przełożonych. Uzyskanie ich zgodności wymagało sporej pracy.”

To pokazuje realny problem. Można mieć doskonałe trio na poziomie IC, lecz jeśli bezpośredni przełożeni ciągną w różne strony i mają odmienne priorytety – będzie trudno. Dlatego skalowanie trio w górę organizacji (directors, VPs) jest tak krytyczne dla sukcesu modelu.

Pierwsze kroki – praktyczny checklist

Przed rozpoczęciem budowania:

Wszyscy trzej (PM, design, engineering) rozumieją problem, nie tylko proponowane rozwiązanie
Engineering uczestniczył minimum w pierwszej, środkowej i ostatniej rozmowie z klientem
Jasno zdefiniowany rezultat – co próbujecie osiągnąć i jak to zmierzycie
Przeprowadzona 15-minutowa rozmowa trio oceniająca viability, value, usability i feasibility

W trakcie pracy:

Cotygodniowy punkt zborny (retro lub discovery sync) gdzie wszyscy znają status
Debrief po każdym wywiadzie z klientem – co każdy wyciągnął z rozmowy
Wykorzystanie modeli (Opportunity Solution Tree, value mapping, slicing) zamiast niekończących się dyskusji opartych na założeniach
Design review co tydzień (lub odwołanie jeśli nie ma materiału do prezentacji)

Po dostarczeniu:

Pokazanie zespołowi metryk i wymiernego wpływu ich pracy
Dzielenie się feedbackiem otrzymanym od klientów
Wyjaśnienie jak zmienili czyjeś codzienne doświadczenie
Zespół widzi że ich czas i wysiłek przyniósł rzeczywistą wartość

Na poziomie organizacji:

Akceptacja od bezpośrednich przełożonych dla każdej roli w trio
Rozważenie skalowania trio w górę hierarchii (director, VP levels) dla większych inicjatyw
Adresowanie braków równowagi w trio – każdy głos musi być słyszalny
Tworzenie przestrzeni dla naturalnego budowania relacji między członkami

Sygnały ostrzegawcze że trio nie funkcjonuje

PM pisze brief i przekazuje designerowi bez wcześniejszej rozmowy we trójkę
Designer przekazuje gotowy design „przez płot” do engineeringu
Engineering dowiaduje się o inicjatywie dopiero podczas taskowania w sprincie
Jedna osoba milczy na spotkaniach lub nie ma realnego głosu (brak równowagi)
Fraza „to już nie moja odpowiedzialność” – brak wspólnej odpowiedzialności za rezultat
Miesięczna praca nad czymś zanim ktoś w końcu zapyta „czy ktoś tego faktycznie potrzebuje?”
Bezpośredni przełożeni ciągną trio w różne strony przy braku zgodności celów

Jak przekonać zespół – wskazówki praktyków

Amanda zauważa że designerzy zazwyczaj chętnie przyjmują model trio. Często czują się „pod butem” i otrzymują polecenia od PMów. Każda okazja do zaangażowania w priorytetyzację i strategię spotyka się z entuzjazmem.

Alder podkreśla fundamentalny punkt: musisz zaprosić ludzi do stołu i zrozumieć co ich motywuje. Co ekscytuje Jakuba jako engineering managera? Co inspiruje Zuzanę jako designera? Co interesuje data engineerów?

Jasne wyjaśnienie rezultatu to początek. Jednak możliwość dania im kontekstu rozwiązywanego problemu całkowicie zmienia perspektywę. Możesz posadzić engineera, dać komputer i powiedzieć „zbuduj to” – jasne, wykona zadanie. Lecz zatrudniasz inteligentnych ludzi do rozwiązywania problemów, nie do bycia code monkeys.

Jeśli możesz powiedzieć „wierzę że jesteś wystarczająco inteligentny żeby rozwiązać ten problem, chcesz miejsce przy stole gdzie wspólnie to wymyślimy, ufam Twojemu osądowi i perspektywie” – to właśnie tego ludzie pragną usłyszeć. To zaproszenie którego nie odrzucą.

Równie ważna jest druga część: nie tylko angażuj zespół na początku w discovery. Pokazuj im później co osiągnęli. Bądź bardzo jasny co do metryk i wymiernego wpływu. Dziel się z zespołem feedbackiem od klientów. Pokazuj jak zmienili czyjeś codzienne doświadczenie – ma to ogromny wpływ na motywację.

Będziesz potrzebował ich czasu przy kolejnej inicjatywie. Jeśli chcesz żeby go poświęcili, musisz pokazać że cenisz ich czas i że poprzedni wysiłek przyniósł wymierny sens.

Refleksje końcowe z ProductTank

Zuzana podsumowuje: bycie w product trio to ćwiczenie w jasnej, uczciwej komunikacji i wymianie informacji. Rozmowa codzienna – z przełożonymi, z zespołem. Ustalenie wszystkich oczekiwań. Pełna jasność i uczciwość co do bieżącej pracy, dlaczego funkcjonuje dobrze lub napotyka przeszkody.

Oczywiście można się nie zgadzać – trio z definicji utrzymuje różne perspektywy i to stanowi jego siłę. Jednak na koniec dnia musi być konkluzja, rezultat musi być osiągnięty, konflikt rozwiązany. Zespół Muse preferuje demokratyczne podejście, lecz zawsze bazujące na twardych danych. Coś co można zweryfikować, zmierzyć, co stanowi podstawę merytorycznej dyskusji, nie tylko przeczucia.

Alder konkluduje: kiedy są dobrze zsynchronizowani – po poważnej porażce, miejmy nadzieję że możecie pominąć ten etap – poruszają się naprzód przez dzielenie wizji, dzielenie kierunku produktu, dzielenie wizji dla zespołu i dzielenie rezultatu. Nie „moja wizja, Twoja wizja” lecz nasza wspólna wizja dokąd zmierzamy i dlaczego to ma sens.

Kluczowy insight

Paradoks ekspertyzy technicznej w customer discovery

Powszechne przekonanie: Inżynierowie powinni koncentrować się na kodzie. Customer discovery należy do domeny PM i designerów. Chronimy developerów przed „szumem” rozmów z klientami dla zachowania ich produktywności.

Rzeczywistość w praktyce: Im głębsza ekspertyza techniczna, tym większa wartość w rozmowach z klientami. Backend engineer w Muse podczas półgodzinnej rozmowy z klientem „wyperswadował” 6 miesięcy developmentu. Nie kwestionował business value, lecz rozpoznał różnicę między realnym problemem technicznym a obejściem które klient rozwinął wokół limitacji poprzedniego systemu.

Dlaczego ma to znaczenie: Klient często opisuje rozwiązanie (bazujące na ograniczeniach znanego mu systemu), nie rzeczywisty problem. PM i designer słyszą „potrzebujemy X” i notują. Engineer słyszy „potrzebujemy X” i myśli „moment, X to obejście problemu Y, a problem Y już nie istnieje w naszym stacku technologicznym”. Ta techniczna perspektywa jest bezcenna – lecz tylko jeśli engineer uczestniczy w discovery od początku.

Praktyczny test: Następnym razem planując wywiad z klientem, zamiast „chronić” inżynierów przed spotkaniem, zaproś najbardziej techniczną osobę z zespołu. Daj jej jedno zadanie: słuchaj przez pierwsze 80% rozmowy, następnie zadaj pytania o workflow. Sprawdź czy zakwestionuje fragment zakresu który wszyscy inni uznali za oczywistą konieczność.

Ten wpis jest częścią mojej kolekcji notatek z podcastów, webinarów i innych materiałów które uznaję za wartościowe i do których sam chcę wracać. Źródło: ProductTank London – Collaboration in Product Trios/Duos (maj 2024, prezentacje zespołów Muse i Tesco)