Wzmacnianie odpowiedzialności zespołu za produkt

Czym jest odpowiedzialność zespołu za produkt i dlaczego jest bardzo ważna? Co zrobić, aby zbudować odpowiedzialność za produkt w naszym zespole – poznaj 6 rad, które Ci w tym pomogą.

Chcesz zbudować lub wzmocnić odpowiedzialność za produkt w swoim zespole? Dowiedz się jak do tego podejść i na co zwrócić uwagę, aby wspólnie z zespołem tworzyć wartościowe z punktu widzenia użytkownika i biznesu produkty. 

Z kwestią wzmacniania odpowiedzialności zespołu za produkt bardzo często spotykamy się w naszej pracy. Klienci szukają wskazówek i sposobów, aby ta odpowiedzialność rosła, stąd też dziś podzielimy się z Tobą kilkoma radami, które naszym zdaniem warto zastosować.

Nasze porady są dosyć uniwersalne i mogą one być pomocne zarówno dla Scrum Mastera, jak i Product Ownera, czy też członka zespołu lub managera.

Czym jest odpowiedzialność za produkt?

Najprościej to przedstawić posługując się negatywnymi przykładami zespołów lub pojedynczych osób, które nie zważają na to, co i po co, coś robią, wykonują po prostu swoje zadania, ale bez zaangażowania i zrozumienia, co jest realnie potrzebne. Mogą one nawet bardzo dobrze wykonywać swoją pracę, jednak brakuje tego poczucia odpowiedzialności i zaangażowania.

Odpowiedzialność za produkt często jest potrzebna, gdy kreowane są zupełnie nowe rozwiązania lub gdy produkt jest przebudowywany, a bywa, że w toku dyskusji pojawia się problem, że zespół albo nie rozumie, po co coś robi, albo nie rozumie klienta. 

Dobrym przykładem braku odpowiedzialności za produkt jest sytuacja, w której Zespół Deweloperski stworzy kawałek produktu, jednak to rozwiązanie nie do końca odpowiada na potrzeby, mimo że technicznie trudno mu cokolwiek zarzucić. I jeśli wówczas w zespole słychać głosy, że wszystko jest zrobione, jak to było zdefiniowane, to łatwo tu rozpoznać ten brak odpowiedzialności za produkt. 

Dlaczego warto budować odpowiedzialność za produkt w zespole?

Przede wszystkim w zespole, w którym jest odpowiedzialność za produkt i faktycznie dba się o to, aby rozwiązywać problemy użytkowników, to pilnowanie jakości produktu nie spoczywa na barkach jednej osoby.

Ponadto, w takim zespole, który rozumie, po co coś robi i jakie problemy rozwiązuje, pojawiają się często trafne, kreatywne pomysły, które przychodzą od różnych osób w zespole. Jednocześnie inspirują one do kolejnych kreatywnych rozwiązań problemów, które mogą być często dużo lepsze, niż mogliśmy zakładać na początku pracy. To daje też dużo satysfakcji, która jeszcze bardziej angażuje w projekt i motywuje do dalszego dbania o wartość tworzonego produktu.

Gdy odpowiedzialność za produkt jest rozłożona na cały zespół, to jakość produktu może być potencjalnie wyższa. Przykładowo zespół wyprodukował produkt zgodnie z założeniami, działał on bez zarzutu, jednak widzi, że to nie jest dobre rozwiązanie i nie można go dać użytkownikom. Czyli nie ma tu myślenia: zrobić zgodnie z makietą i oddać, tylko faktycznie zastanowić się, czy nie lepiej dołożyć więcej pracy i zaproponować lepsze rozwiązanie.

6 porad jak wzmacniać odpowiedzialność zespołu za produkt

1. Zrozum i zdefiniuj produkt
Zrozumienie i właściwa definicja produktu jest to krokiem koniecznym do tego, aby zespół był w stanie połączyć codzienne działania (często bardzo techniczne i niskopoziomowe) z ostatecznym celem, który chcemy osiągnąć.
Ta definicja musi klarownie mówić, czym produkt jest dla nas, jakie ma cechy, jaki jest zakres tego produktu.

Ważne jest też pamiętanie o oczekiwanym rezultacie, gdyż definiując tylko punkty i funkcjonalności do zrealizowania, może powodować, że zespół jest traktowany jako taka “fabryka feature’ów” i zatraci on poczucie, że odpowiada za produkt.

Pamiętanie o celu nadrzędnym i tym, do czego produkt ma służyć, pomaga też uniknąć ryzyka zawężenia tej definicji tylko do konkretnego rozwiązania IT – np. aplikacji czy intranetu, zapominając zupełnie o tym, że to rozwiązanie czemuś służy, ma pomagać realizować jakiś cel biznesowy, ma służyć klientowi.

Taka redefinicja produktu i spojrzenie poza ramy techniczne, może bardzo rozszerzyć sposób postrzegania zespołu. Przykładowo zespół postrzegany jako zespół intranetowy, bo zajmuje się on intranetem, zamienia się w zespół, który zapewnia lepszą propagację informacji w firmie. To z kolei może pokazać, że w zespole mamy braki kompetencyjne, a dodatkowo zadamy sobie pytanie, czy dotychczas rozwijane rozwiązania, faktycznie rozwiązują ten problem, który sobie zdefiniowaliśmy na bardziej ogólnym poziomie.

Opisując to na przykładzie z naszej pracy, zespół zajmujący się komunikacją produktu na początku definiował swoją rolę, jako zespół, który po prostu raz w tygodniu nadaje komunikaty do całej firmy na temat tego, co się zmienia w naszej ofercie produktowej. I tak zawężona definicja produktu powodowała, że w zasadzie cały zespół zajmował się po prostu copywritingiem coraz lepszych maili wysyłanych do klientów co tydzień. Gdy zredefiniowali sobie to, czym się zajmują i zrozumieli, że ich rolą nie jest zwykłe nadawanie komunikatu, tylko skuteczne propagowanie informacji, to okazało się, że całkowicie zmieniło się podejście do tego, czym mają się zajmować. Zauważyli, że to, co dotychczas robili, czyli nadawanie komunikatu jest nieskuteczne, gdyż ta informacja nie docierała do odbiorców, więc zespół skupił się na faktycznym problemie: jak docierać do odbiorców, zamiast jak nadawać lepsze komunikaty.

Dlatego właśnie dobre zdefiniowanie produktu z uwzględnieniem elementów biznesu, pozwala zespołowi wyjść poza ramy tworzenie aplikacji/kawałka procedury/rozwiązania i zacząć myśleć o rezultacie biznesowym, skuteczności i prawdziwej przydatności tworzonego rozwiązania. To z kolei pomaga poprawić poczucie odpowiedzialności za produkt.

2. Spędź czas z użytkownikiem
Nawiązując do przykładu z wysyłaniem komunikatów, warto zastanowić się, kto odbiera te komunikaty, a następnie upewnić się, że są dobre lub wymagają optymalizacji.

Wskazówka ta często wywołuje gęsią skórkę u osób, z którymi rozmawiamy, gdyż w przeciętnej firmie odległość zespołu wytwarzającego produkt do użytkownika, który faktycznie będzie z tego produktu korzystał, jest całkiem spora. Natomiast możliwość wejścia w interakcję z użytkownikiem i możliwość zobaczenia, jak on korzysta z produktu, jest niezwykle istotna.

Kilka lat temu Jacek przekonał się na własne oczy, jak jest to ważne. Wspierał on zespół, wytwarzający aplikację, z której użytkownicy korzystali na co dzień. W trakcie developmentu pojawiło się wiele niejasności, m.in. co do tego, jak pewne rzeczy powinny być rozwiązane. Postanowili oni (Product Owner i kilku reprezentantów zespołu, w tym osoba z UX-a) pojechać do fizycznego miejsca, gdzie użytkownicy korzystają z produktu i zobaczyć, jak oni wchodzą w interakcje z tym produktem. Taka jednodniowa wizytacja wprawiła ich w niemały szok, gdyż zobaczył, i jakie faktycznie problemy użytkownicy mają z produktem i dowiedzieli się zupełnie nowych rzeczy, np. co jest nieintuicyjne, co nie działa, co jest zbędne w procesie. Wrócili oni z głową pełną pomysłów na to, co można byłoby usprawnić w produkcie. Ponadto „zempatyzowali” się z tym użytkownikiem, czyli poczuli, jak to jest używać tego produktu, dzięki czemu rozmawiając później o produkcie, wracały do nich te historie i obrazy, które powstały w trakcie tej wizytacji.

Ten spędzony czas z użytkownikiem to też okazja do głębokiego zrozumienia, jaka jest potrzeba. Nie bazujemy tylko na tym, że ktoś nam coś zlecił, że komuś się coś wydaje, a autentyczne zgłębienie czego klient potrzebuje.

Stąd też, jeśli macie możliwość zaaranżować takie spotkanie z użytkownikami, to zdecydowanie zachęcamy, aby sięgnąć po to rozwiązanie.

3. Znaj wizję produktu
W sumie dla niektórych zespołów wskazówka ta powinna brzmieć “Zbuduj wizję produktów”, bo niestety spotykamy się z sytuacją, że tej wizji wcale nie ma.

Ogólnie “wizja produktu” to bardzo obszerny temat, jednak zazwyczaj możemy znaleźć w niej jakąś formę definicji kim jest klient i jakie ma potrzeby, a takżę taktyki, jak chcemy te potrzeby zaspokoić, jak chcemy pozycjonować się względem konkurencji, w czym chcemy być unikalni i jak będziemy zarabiać.

Jeśli te rzeczy zamienimy na konkretne historie, namacalne powody, dla których chcemy pewne rzeczy robić, to mamy po prostu łatwo dostępne uzasadnienia, po co to coś robimy.

Jeśli zespół nie posiada wizji to warto pochylić się nad tym tematem w pierwszym kroku współpracy, czy to jako Agile Coach, czy świeży członek zespołu. Oczywiście, zwykle to wygląda tak, że przedstawiciel biznesu czy klienta, ma jakąś wizję lub chociaż jej zarys i poddanie tego pod dyskusje z zespołem, zwykle generuje nowe pytania, czy wątpliwości, niejednokrotnie wpływają na kierunki dalszego rozwoju tego produktu. I jest to wręcz kamień węgielny pod budowanie odpowiedzialności.

Jeśli stworzenie wizji produktu jest dopiero przed Wami, to rekomendujemy wykorzystanie Product Vision Board od Romana Pichlera oraz książkę tego autora” “Strategize”. Oczywiście dopasujecie to narzędzie do własnych potrzeb. Polecamy też zapoznanie się z filozofią Simona Sinka, “Start with Why”, gdzie zaczynamy od zdefiniowania „dlaczego?”, dopiero potem idziemy w „jak?” i na końcu w „co?”, czyli co tak naprawdę ma być tym produktem.

4. Przypominaj sobie o powodach realizacji inicjatywy
Mimo że wydawać się to może za zbyt oczywiste, to wracanie do wcześniej wspomnianego “dlaczego” jest bardzo istotne, aby nie zniknęło nam sprzed oczu i aby mieć pewność, że nowi członkowie zespołu też się z tym zaznajomili. To czasem będzie cierpliwe pracowanie nad tym, aby wyjaśnić niezrozumienie, czy też sparafrazować, pewne rzeczy, które dotychczas nie były wystarczająco klarowne.

Warto, aby Product Owner lub interesariusz pracujący przy projekcie, miał bardzo krótką wersję wytłumaczenia, dlaczego coś robimy, ale i żeby był też otwarty i gotowy na to, żeby powyjaśniać szczegóły, przypominać pewne rzeczy, opowiedzieć o kontekście użycia danego rozwiązania i nie bać się, że ktoś zarzuci mu, że marnuje czas na zbędne wyjaśnienia. Póki w zespole nie ma jednoznacznego głosu, że dodatkowy kontekst biznesowy jest naprawdę zbędny i wszyscy mają to samo zrozumienie, to nie rezygnujmy z przypominania powodów realizacji danej inicjatywy.

5. Pracuj przyrostowo i wykorzystuj pętlę feedbacku
Mówiąc o pracy przyrostowej, mamy na myśli, żeby na koniec konkretnych iteracji lub co jakiś przedział czasu dostarczać przyrost produktu – trochę lepszy produkt niż był chwilę wcześniej.

Jest to istotne, ponieważ jeśli faktycznie przyrostowo budujemy produkt, to on rośnie w naszych oczach i od bardzo prostego produktu przechodzimy do coraz bardziej zaawansowanego rozwiązania. Dysponując czymś takim namacalnym, możemy to pokazać interesariuszom, czy użytkownikom i uruchomić pętle informacji zwrotnej. Często taki nawet niewielki przyrost wywołuje uśmiech na twarzy klienta lub użytkowników i takie nawet drobne pochwały od osób, dla których coś wytwarzamy, są bardzo silnym motywatorem do działania i także do poczucia odpowiedzialności za to, co robimy.

6. Monitoruj rezultaty
Porada ta jest adekwatna zwłaszcza dla zespołów, które rozwijają swój produkt w dłuższym przedziale czasu i jest on albo na rynku, albo w użyciu przez odbiorców końcowych. Wspominaliśmy o tym trochę w odcinku podcastu o Przeglądzie Sprintu, że czasem brakuje tego momentu zastanowienia się, jak produkt działa, czy klienci są zadowoleni, jakie są rezultaty biznesowe. Analizować możemy bardzo różne rzeczy, np. oceny aplikacji w sklepie, czas na stronie, powracalność klientów lub liczba kupujących.

Nawet jak już teoretycznie wszystko, co mieliśmy do zrobienia, zrobiliśmy, to warto wiedzieć jak to się sprawdza w rzeczywistości i mieć takie domknięcie pewnego procesu. Jeśli okaże się, że produkt świetnie się sprawdza, to daje to nową energię do kolejnych działań. Jeśli natomiast okaże się, że są jakieś niedociągnięcia i problemy, możemy to naprawić lub w najgorszym wypadku wyciągnąć nauki na przyszłość.

Na przykładzie tego, co my robimy, czyli podcastu i artykułów, jakie tworzymy, Wasze polubienia, pozytywne komentarze i ogólnie interakcja z nami, stanowią bardzo mocne paliwo do dalszego działania i bycia w tym coraz lepszym.

Jesteśmy ciekawi jak w Twoim zespole, wygląda odpowiedzialność za produkt, czy temat ten jest  w ogóle podejmowany i jakie są Twoje przemyślenia lub doświadczenia w tej kwestii.

Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy.

Dodatkowe materiały

• Porządny Przegląd Sprintu
• Książka „Strategize” Romana Pichlera
• Książka „Start with Why” Simona Sinka (pol. „Zaczynaj od DLACZEGO”, wyd. Onepress)
• Product Vision Board Romana Pichlera

Transkrypcja podastu „Wzmacnianie odpowiedzialności zespołu za produkt”

Jacek: W dzisiejszym odcinku porozmawiamy o tym, jak budować odpowiedzialność zespołu za produkt. Bardzo często, kiedy pracuję z klientami, kiedy analizujemy sobie to, jak pracuje zespół, jak rozbudowuje konkretny produkt, prędzej czy później dochodzimy do zagadnienia odpowiedzialności zespołu za wykonywaną pracę w kontekście produktu i bardzo często wtedy słyszę pytanie: „To jak moglibyśmy sprawić, żeby ta odpowiedzialność za produkt w zespole rosła i żeby była większa?”.

Kuba: W ramach odcinka zdefiniujemy jeszcze ciutkę dokładniej, o co nam chodzi. Opowiemy, dlaczego warto taką odpowiedzialność mieć – mieć ją wysoką w zespole – i podzielimy się z Tobą sześcioma podpowiedziami, które naszym zdaniem warto zastosować. Warto albo spróbować, albo wzmocnić w swoim zespole, by tą większą odpowiedzialność za produkt uzyskać. Zaczniemy od definicji tego, o co nam chodzi, jeśli mówimy o odpowiedzialności za produkt. Najprościej, niestety, negatywnie to ująć, przypadkami, które też niestety od czasu do czasu w niektórych firmach spotykamy, że są zespoły – czy pojedyncze osoby w zespole – które trochę nie zważają na to, co robią, po co robią, po prostu wykonują swoje zadania – może nawet wykonują je dobrze technicznie czy dobrze jakościowo, ale nie składa się to w całość, nie uzyskujemy też takiego zaangażowania czy zrozumienia tego, co jest realnie potrzebne. Czasami też tej odpowiedzialności za produkt potrzeba, gdy kreowane są zupełnie nowe rozwiązania, gdy przebudowywany jest produkt – i w toku dyskusji pojawia się problem, że zespół albo nie rozumie, po co coś robimy, nie rozumie klienta. Albo niestety się okazuje, że te rozwiązania, które przychodzą od zespołu, one są już ze startu, z gruntu, w ogóle od samego początku nieadekwatne, niedopasowane, bo nagle się okazuje, że trochę zabrakło kontekstu i te pomysły są do poprawienia. Product Backlog nie jest wystarczająco dobry.

Jacek: Przykładem takiego braku odpowiedzialności za produkt jest sytuacja, w której Zespół Deweloperski wyprodukuje kawałek produktu i to rozwiązanie nie do końca odpowiada na potrzeby, pomimo tego, iż – tak jak wspominałeś – technicznie trudno cokolwiek zarzucić, no i rozpoznaję brak odpowiedzialności, kiedy słyszę w takiej sytuacji od strony osób, które wytwarzają ten produkt, że: „No przecież tak to było zdefiniowane, no przecież tak to mieliśmy zrobić. No, ja nie wiem, czy to jest dobre biznesowo, ja tu po prostu odpowiadam za to, żeby ten guzik był czerwony i jak się go nadusi, żeby się wygenerował raport. A reszta? Co mnie to tam… obchodzi?”.

Kuba: I, żeby nie być tylko takim negatywnym, bo świadomie chcieliśmy tego uniknąć i tak średnio nam chyba wyszło [śmiech], to powiedzmy sobie pozytywnie, jakie są korzyści, jeśli tą odpowiedzialność w produkcie mamy.

Jacek: Pierwsza myśl, która mi zawsze przychodzi, to jest taka, że Zespół Deweloperski wytwarzający produkt – w sensie, zespół, który jest odpowiedzialny – powoduje to, że ta odpowiedzialność za produkt – taka na wielu płaszczyznach, jakościowa, techniczna, taka, żeby faktycznie rozwiązywać problemy użytkowników – ona spoczywa i rozkłada się na cały zespół. Czyli nie jest na barkach tylko jednej osoby, która musi to szerokie zagadnienie opanować, tylko ma wsparcie w członkach Zespołu Deweloperskiego w tym, żeby ten produkt na koniec dnia dawał wartość użytkownikom. I zależy nam na tym, żeby zespół jako całość po prostu tą odpowiedzialność i tą taką chęć tworzenia dobrego produktu posiadał.

Kuba: Drugim argumentem za tym, żeby mieć dużą odpowiedzialność za produkt, wydaje mi się taka możliwość u wszystkich członków zespołu w dokładaniu dobrych pomysłów, w zrozumieniu, po co coś robimy, zrozumieniu, jakie problemy rozwiązujemy, no i wtedy wraz z tą odpowiedzialnością idzie też dużo trafnych, kreatywnych pomysłów, te innowacje przychodzące od każdego możliwego członka zespołu, one są trochę lepsze, wszyscy się może tak troszkę bawią w takie kreatywne rozwiązywanie problemów, wzajemnie inspirując do tego, co powoduje, że rozwiązania są lepsze niż ktokolwiek zakładał, gdy w ogóle rozpoczynaliśmy pracę. I wszyscy też mają takie poczucie satysfakcji, że uczestniczymy w bardzo kreatywnym procesie, bo się zaangażowaliśmy, mamy spory kontekst, mamy swoją wiedzę techniczną, jak to robić, więc to się wszystko w sumie składa też w fajne rozwiązanie, jeśli chodzi o wartość biznesową, a przy okazji też satysfakcję i motywację do kontynuacji pracy w ten sposób. Bo tutaj, no, wydaje mi się, może to nawet jest osobny punkt, że to też jest takie samonakręcające się – „Wiem, po co to robię, więc robię to fajnie. Dostaję jakąś informację zwrotną, że to się sprawdza, więc dalej mi się chce” – i to takie jest podtrzymywanie również po prostu motywacji, już niezależnie od tego, jaka jest wartość biznesowa poszczególnych czy to iteracji, czy to poszczególnych przyrostów.

Jacek: Trzecia rzecz, która mi przychodzi do głowy, gdy myślę o tym, dlaczego dobrze, gdy jest duża odpowiedzialność rozłożona na cały zespół to to, że ostatecznie jakość produktu potencjalnie może być wyższa. I tu taki pamiętam przykład sprzed paru lat, kiedy pracowałem z zespołem i zespół zgodził się, że – co do zasady – to, co wyprodukowali, jest bez zarzutu. W sensie: działało, działało tak, jak miało działać, było zgodne z makietą i pamiętam jak jeden z deweloperów wstał i powiedział: „Słuchajcie, ale przecież my nie możemy tego puścić do użytkowników”. I to było mocne. To było dla części zespołu zaskakujące, natomiast to jest… tego rodzaju zachowania ja bym się spodziewał, czyli z jakiegoś powodu wszyscy przespali czy nie zauważyli, że coś nie do końca jest z rozwiązaniem, które chcemy dać użytkownikom, no i znalazł się po prostu ktoś, kto powiedział: „Słuchajcie, no nie, no… Tak nie możemy zrobić”. W sensie, że to „będzie wstyd”.

Kuba: Taka twoja wersja anegdoty o squirrel burgerze, po prostu wstyd przed dostarczeniem czegoś słabego, tak? Dobra, to przejdźmy do konkretnych rozwiązań – już wiemy po co taka odpowiedzialność w produkcie jest wartościowa. Zanim przejdziemy do tych sześciu konkretnych porad czy konkretnych sugestii praktycznych, co można zrobić, to chciałbym zacząć od takiego bardzo ważnego zastrzeżenia, do kogo się kierujemy w ramach tego nagrania, bo wiele z tych porad, jak sobie je przygotowaliśmy z Jackiem przed odcinkiem, będzie w liczbie mnogiej: „Zróbcie coś”, „Idźcie gdzieś”, „Posłuchajcie” czy „Przygotujcie”. Ja myślę, że te rady są dosyć uniwersalne – one mogą być dla Scrum Mastera i wtedy rozum je jako – jeśli jesteś Scrum Masterem lub Scrum Masterką – zrozum je jako sposób na wprowadzenie czy jakieś konkretne porady, praktyki – wprowadź je w swoim zespole, zainspiruj swój zespół, zaproponuj im te rzeczy. Jeśli jesteś Product Ownerem lub Product Ownerką, to zastanów się, które z tych praktyk możesz też przenieść do swojego zespołu. Jeśli jesteś członkiem Zespołu Deweloperskiego, to może zaproponuj na najbliższej Retrospektywie takie usprawnienie. A jeśli jesteś managerem, który obserwuje czy nadzoruje czy kieruje, jakąś grupą zespołów w swojej firmie, zobacz, czy czasami to nie jest jeden z tych elementów, który trochę brakuje w tym, jak zarządzane są zespoły produktowe, jak prowadzone są też prace w gronie Product Ownerów.

Jacek: Jak o tym mówiłeś, to w sumie zdałem sobie sprawę, że na metapoziomie to też jest przykłada tego, że ta odpowiedzialność za to, żeby było dobrze w zespole, spoczywa na wielu rolach, więc trudno też czekać na to, żeby ktoś zareagował, kiedy my widzimy, że możemy działać, tak więc…

Kuba: Można się tego dopomnieć, jako członek zespołu, można to zaproponować jako Product Owner, można jako Scrum Master czy Agile Coach w swoim zespole wnieść to, przynieść to jako propozycję praktyki czy sposób na pracę trochę inaczej.

Jacek: Pierwszą poradą, którą chcieliśmy się z Tobą podzielić, to jest porada, która brzmi: „Zrozum i zdefiniuj produkt”. Zrozumienie i właściwa definicja produktu jest to krok konieczny do tego, żeby zespół był w stanie połączyć to, co robi na co dzień – często bardzo takie techniczne, niskopoziomowe działania – z tym ostatecznym celem, który chcemy osiągnąć. I kiedy prowadzę konsultacje czy prowadzę szkolenia, ten temat: „A co tak naprawdę z naszym produktem?” – on wraca. W szczególności, jeżeli pracowaliśmy długo w sposób projektowy, gdzie tak nie do końca się zastanawialiśmy nad produktem, bardziej myśleliśmy o tym, żeby dostarczyć jakiś umówiony efekt projektowy – no, ten produkt bywa taką zagadką. W sensie, pierwsze skojarzenie to jest takie, że przecież produkt musi być fizyczny – nie do końca tak jest. Tak więc ta jasna definicja, co jest naszym produktem, jak my go definiujemy, jakie on ma cechy, jak szeroki jest zakres tego produktu, uważamy za kluczowy punkt startowy.

Kuba: Ja bym nawet dorzucił, bo powiedziałeś „efekt projektu” – w wielu przypadkach spotykam się wręcz z tym, że oczekiwany jest po prostu zakres. Zdefiniowaliśmy kilka punktów, kilka feature’ów, po prostu to zrobimy – i to może prowadzić w wielu zespołach do tego, że zespół jest traktowany jako taka „fabryka feature’ów”, a niekoniecznie zespół, który odpowiada za konkretny produkt. Natomiast idąc jeszcze głębiej – nawet jeśli zespół czuje, że jest zespołem od produktu i ma jakiś system albo jakąś aplikację, jakieś rozwiązanie IT pod swoją opieką, to często ta definicja produktu będzie zbyt zawężona – „My tu jesteśmy od tego, żeby utrzymać aplikacje wewnętrzne albo budować intranet, albo budować jakąś tam apkę”. I to często jest jednocześnie prawdą, ale czasami zbyt zawężające, że to jest zespół, który zajmuje się jakimś konkretnym rozwiązaniem IT, a nie tym czymś trochę czasami abstrakcyjnym, że to jest zespół, który pomaga rozwiązać problem jakiejś grupy klientów albo osiągać jakiś rezultat biznesowy, pomagać naszej firmie zarabiać, rozwiązywać jakieś konkretne działanie dla klienta. I czasami taka redefinicja w danym zespole może bardzo rozszerzyć sposób postrzegania zespołu i na przykład z zespołu, który zajmuje się intranetem, zespołem intranetowym, zamieniamy się w zespół, który zapewnia lepszą propagację informacji w firmie, co może oznaczać, że być może mamy brakujące kompetencje w zespole, a na pewno zakwestionujemy czy zadamy sobie pytanie, czy dotychczasowe rozwiązania, które dotychczas rozwijaliśmy, faktycznie rozwiązują ten problem, który sobie zdefiniowaliśmy na być może trochę bardziej ogólnym poziomie.  I mam takie doświadczenie z zespołem – użyłem tego przykładu intranetu – podobny zespół, zajmujący się komunikacją produktu, który na początku definiował swoją rolę czy swój sens istnienia, jako zespół, który po prostu raz w tygodniu nadaje komunikaty do całej firmy na temat tego, co się zmienia w naszej ofercie produktowej. I tak zawężona definicja produktu powodowała, że w zasadzie cały zespół zajmował się po prostu copywritingiem coraz lepszych maili, tydzień w tydzień wysyłanych do klientów. Gdy zredefiniowali sobie to, czym się zajmują, że nie chodzi o to, żeby nadać komunikat, tylko żeby skutecznie propagować informacje, raptem jeden krok bardziej abstrakcyjnie, to nagle się okazało, że zupełnie zmieniło się podejście do tego, czym mamy się zajmować, bo nadawanie okazało się nieskuteczne i ta informacja nie docierała, więc zespół nie zajmował się relatywnie prostym problemem, jak nadawać lepsze komunikaty, tylko jak docierać z rozwiązaniem. I to jest dosyć prosty przypadek – niekoniecznie adekwatny w każdej sytuacji – ale znajduję wiele analogii tego typu sytuacji. Wiele zespołów zbyt mocno widzi siebie jako zespół, który wytwarza apkę, system, kawałek jakiejś procedury, rozwiązania, zmiany w procesie, a  raptem dosłownie krok wyżej w abstrakcji jest rezultat biznesowy, efekt, skuteczność, taka prawdziwa przydatność – i czasami całkiem dobre odświeżenie całemu zespołowi i poprawienie odpowiedzialności za produkt, robi właśnie takie zdefiniowanie sobie tego naszego produktu. Być może trochę bardziej abstrakcyjnie, ale o wiele bardziej tak namacalnie biznesowo.

Jacek: To, co ja słyszę w tym, co opowiadasz, to zbliża nas do punktu drugiego, do drugiej porady, która brzmi: „Spędź czas z użytkownikiem”, bo jak mówiłeś o tej skuteczności nadania tego komunikatu, no to nieuchronnie tutaj zbliżamy się do tego, żeby się zastanowić, kto odbiera te komunikaty i może upewnijmy się, że one są dobre albo dowiedzmy się, że może nie do końca i zastanówmy się, co można usprawnić. Tak więc druga nasza porada brzmi: „Spędź czas z użytkownikiem” i to jest porada – czy taka wskazówka – która zwykle wywołuje gęsią skórkę u osób, z którymi rozmawiam na ten temat, ponieważ w przeciętnej firmie odległość zespołu wytwarzającego produkt do tego użytkownika, który faktycznie będzie z tego produktu korzystał, zwykle jest całkiem spora. W sensie, co najmniej kilka poziomów dzieli zespół od osoby, która ostatecznie z produktu korzysta. Natomiast ta możliwość wejścia w interakcję z użytkownikiem, możliwość zobaczenia, jak on korzysta z produktu, pewien czas, który mamy na to, żeby wysłuchać, co ten użytkownik chce nam powiedzieć, to, co chce nam zaprezentować, wyrazić – jest niezwykle istotne. Pamiętam, jak parę lat temu wspierałem zespół, który dostarczał produkt, aplikację do osób, które pracowały na tej aplikacji na co dzień i dosyć dużo niejasności pojawiło się w trakcie dewelopmentu, jak pewne rzeczy powinny być rozwiązane i reprezentacja, w osobie Product Ownera + paru reprezentantów zespołu (tam też się pojawiła osoba UXowa), podjęła decyzję, że może warto byłoby pojechać faktycznie do fizycznego miejsca, gdzie użytkownicy korzystają z produktu i zobaczyć, jak oni wchodzą w interakcje z tym produktem. I pamiętam, że jak wrócili z tej takiej jednodniowej wizytacji, no to byli mocno w szoku, w takim sensie, że zobaczyli, jakie problemy mają użytkownicy z produktem, dowiedzieli się zupełnie nowych rzeczy o tym produkcie, na zasadzie: to jest nieintuicyjne, a tu musimy niepotrzebnie pięć razy kliknąć, jakiś element procesu w tym produkcie w ogóle był pomijany i sobie jakieś takie robili użytkownicy obejścia na boku, w jakiejś innej aplikacji, tak więc wrócili z pełną głową pomysłów na to, co można byłoby usprawnić w produkcie – i to jest superfajna rzecz, ale dodatkowo to, co się zadziało, moim zdaniem, to oni „zempatyzowali” się z tym użytkownikiem, czyli poczuli, jak to jest używać tego produktu, co powodowało, że jak później rozmawiali o tym, jak ten produkt rozwijać, no to wracały te historie i te obrazy, które zbudowali sobie w trakcie tej wizytacji, tak więc jeżeli możesz się zbliżyć do klienta, jeżeli jesteś w stanie takie spotkanie zaaranżować – może z jakąś grupą zaprzyjaźnionych użytkowników na początku – to zdecydowanie warto po to rozwiązanie sięgnąć.

Kuba: Mam bardzo podobną historię związaną z zespołami, które zajmowały się rozwojem systemu do call center – używam liczby mnogiej, bo w dwóch różnych firmach mieliśmy bardzo podobną historię, że zupełnie zmieniło się postrzeganie tego, z jakimi emocjami wiąże się obsługa systemu, gdy po prostu operator na słuchawce musi pracować i w jakim on jest stresie, jakie ma informacje dostępne, co mu pomaga, a co mu przeszkadza w tym, żeby realizować swoje zadania, no i zespoły wychodziły pełne pomysłów, ale też pełne dostrzeżenia takich drobnych niedoskonałości, bo ja tutaj zwrócę uwagę na jedną rzecz – co innego ludzie nam mogą zlecić, powiedzieć – może jakiś manager przyśle „10 pomysłów na usprawnienie”, a co innego my sami zauważymy, jak zaobserwujemy w naturalnym środowisku naszego klienta i zrozumiemy, w jakim kontekście on pracuje i co mu pomaga, co mu przeszkadza, co by może mu pomogło – ten klient może nawet nie umieć powiedzieć, że: „No, tak tu jakbym miał jakiś fajny podpowiadacz, ile jeszcze czasu zostało”, to my dopiero widząc go w praktyce i rozmawiając z nim, możemy odkryć, czego jemu faktycznie brakuje – on nawet może sam nam tego nie powiedzieć. I wszystkie te spotkania, ten spędzony czas z użytkownikiem, to jedna kwestia to jest właśnie to naturalne środowisko, ale też okazja  do głębokiego zrozumienia, jaka jest potrzeba. A nie bazowanie na tym, że ktoś nam zlecił, że komuś się coś wydaje, czy takie trochę zgadywanie, tylko autentyczne zgłębienie, czego klient potrzebuje. Nie nawet co zamówił, tylko czego potrzebuje. Kolejną poradą, którą chcielibyśmy przekazać w tym odcinku, to jest rada dla całego zespołu: „Znaj wizję produktu”. I dla niektórych zespołów to jest: „Zbuduj tą wizję, bo jej w ogóle nie masz”, a w wielu innych zespołach będzie to raczej: „Pamiętaj, przypominaj ją sobie, być może odświeżaj z jakąś regularnością wizję tego, co jest do zrobienia”. „Wizja produktu” to jest bardzo pojemny temat – być może nadający się na zupełnie osobny odcinek, ale w skrócie zazwyczaj wizje produktu zawierają jakąś formę definicji, kim jest klient i jakie ma potrzeby, co świetnie mapuje się z tą drugą poradą, ale też jakaś taktyka, jak chcemy zaspokoić te potrzeby, jak chcemy się pozycjonować względem konkurentów, w czym chcemy być unikalni, jakie mamy pomysły na realizację, jakie będziemy też czerpać korzyści, jak będziemy je realizować, na czym zarabiamy. Kilka takich elementów, które w różnych narzędziach różnie są sformułowane, ale szereg takich definicji, czym produkt jest, czym jest klient i jak dalej go chcemy rozwijać. I to może się wydawać trochę takim, powiedzmy, opowiadaniem biznesowym, niekoniecznie namacalnym, ale jeśli zamienimy to w konkretne historie, konkretne przykłady, konkretne też takie bardzo namacalne powody, dla których chcemy pewne rzeczy zrobić, to to są po prostu przypomnienia czy w ogóle zbudowania sobie uzasadnienia, po co coś robimy.

Jacek: Ja właściwie to, co powiedziałeś, skomentuję w ten sposób: „Nie zaczynam pracy z nowym zespołem inaczej niż od wywołania tematu wizji produktu – czy ona jest, jeśli tak, to ją sobie odświeżmy, jako cały zespół. Jeśli tej wizji produktu nie ma, to również zbudujmy ją, jako cały zespół”. Oczywiście to zwykle wygląda tak, że osoba biznesowa, jakiś reprezentant klienta czy klient, on zwykle ma jakąś wizję i jakiś pewien szkic czy zarys tej wizji, zwykle jest w stanie powiedzieć, natomiast włożenie tego, czy poddanie tego szkicu pod dyskusję z zespołem, zwykle generuje dodatkowe pytania, wątpliwości – dosyć mocno to może mieć wpływ na to, jakimi ścieżkami ten produkt będziemy rozwijać i dla mnie to jest taki absolutny kamień węgielny pod budowanie odpowiedzialności i właściwie bez tej wizji się nie ruszam, natomiast to, co warto dodać do tego, co powiedziałeś – bo wymieniłeś kilka różnych możliwości, co w tej wizji może być – to myślę, że warto tutaj dodać, że jest całkiem sporo różnych narzędzi dostępnych, z których można skorzystać, tak więc w zależności od Waszych potrzeb, można dobrać sensowne narzędzia z całkiem szerokiej palety dostępnej na rynku, w sensie: w internecie.

Kuba: Jeśli miałbym wymienić jedną konkretną rzecz, czy jedno konkretne narzędzie, to ja sam rekomenduję zazwyczaj wykorzystanie Product Vision Board od Romana Pichlera – jest to fajnie opisane też w książce „Strategize” właśnie tego autora, ale te materiały są też dostępne na jego stronie internetowej, gdzie można sobie pobrać szablon, gdzie jest trochę opisane, co to znaczy, jak to zrobić – oczywiście bierzcie takie rzeczy z dostosowaniem do swoich potrzeb, ale jeśli chcecie od czegoś zacząć wizję produktu, to to może być dobry pierwszy trop.

Jacek: To z kolei rekomendacja z mojej strony, ostatnio bardzo często używam podejścia czy filozofii „Start with Why” Simona Sinka, czyli zaczynam od zdefiniowania „dlaczego?”, dopiero potem sobie idziemy w „jak?” i na końcu w „co?”, czyli co tak naprawdę ma być tym produktem. I to jest trochę inny poziom abstrakcji niż to, co ty mówisz, powiedziałbym, że bardziej ogólny, natomiast w szczególności, jeśli produkt kompletnie jest niezdefiniowany, to jest coś supernowego, no to to jest fajna taka pierwsza iteracja wizji, którą można narzędziami takimi chociażby jak wymieniłeś, pogłębiać w kolejnych krokach.

Kuba: Czwarta rada, którą chcemy się podzielić, to: „Przypominaj sobie o powodach realizacji inicjatywy”. Brzmi to trochę może oczywiście, no przecież wiemy, po co coś robimy, ile razy można o tym wspominać? Ale to jest takie wracanie do „dlaczego?”, wspomniałeś właśnie „Start with Why”. Przypominaj sobie, po co chcesz coś zrobić, to może być na każdym pojedynczym elemencie w backlogu, przypomnienie, po co, co chcemy osiągnąć, jaki problem rozwiązujemy, ale to też może być praca – czy to właściciela produktu czy przedstawiciela klienta, może interesariusza – w zależności od tego, kto to jest, kto nam ten kontekst dostarcza – przypominanie, dlaczego coś jest ważne, przypominanie, po co chcemy to zrobić, cierpliwe wyjaśnianie – bo to też czasami jest po prostu potrzebne, ta odpowiedzialność produktowa to nie jest przełącznik, który: „kiedyś jej nie było, a teraz zrobiliśmy trzy magiczne kroki i już to mamy”. To będzie też cierpliwe pracowanie, żeby wyjaśnić niezrozumienie, być może przypomnieć, być może trochę sparafrazować pewne rzeczy, które nie dotarły do tej pory dodanego członka zespołu, no i tutaj jest to raczej cierpliwa, organiczna, długofalowa praca, członkowie zespołu też się zmieniają – czasem ktoś o czymś zapomina, ktoś czegoś nie zrozumiał – te kropki regularnie trzeba łączyć.

Jacek: Ja nie zapomnę, jak kiedyś Product Owner, z którym pracowałem z klientem, zwrócił mi uwagę na to, jak reprezentant klienta rozpoczyna każde zdanie. I ta osoba, która była konsultantem z Wielkiej Brytanii, ona faktycznie, kiedykolwiek padało pytanie, jakiekolwiek były wątpliwości, zawsze startowała z takiego bardzo ogólnego poziomu, upewniając się, że zanim przejdziemy do dochodzenia do konkretnej odpowiedzi, czyli do jakiegoś rozwiązania, to wszyscy w pokoju mają takie samo zrozumienie, jaki jest problem, dlaczego w ogóle tutaj jesteśmy – i malował bardzo, bardzo szeroki obrazek. I ktoś mógłby powiedzieć, patrząc z boku: „Po co ta historia? Po co takie rozwlekanie?”. Z mojej perspektywy to jest konieczne, jeżeli chcemy dojść do sytuacji, w której – tak jak powiedziałeś – na początku zespół jest doradcą produktowym i, jakby, mamy w każdej osobie w zespole wsparcie w tym, żeby ten produkt, który powstaje, był jak najlepszej jakości, żeby te rozwiązania, które przekazujemy do użytkowników, były po prostu jak najlepsze.

Kuba: Co oznacza, że taki na przykład Product Owner scrumowy, czy klient, czy interesariusz pracujący przy projekcie, powinien mieć i bardzo krótką wersję, nazwę to, najwyższego poziomu mantrę, po co coś robimy, ale też był bardzo otwarty i gotowy na to, żeby powyjaśniać szczegóły, poprzypominać pewne rzeczy, opowiedzieć też o kontekście użycia danego rozwiązania – i nie bać się o tym wspominać, nie bać się, nie przejmować się ewentualnym zarzutem o stratę czasu, no, w najgorszym razie po prostu sobie to w zespole dopracujemy, że może jest tego za dużo, ale chętnie raczej rekomendowałbym, dobrnijmy do tego momentu, w którym cały zespół stwierdza: „Nie, za dużo już tego kontekstu biznesowego, za dużo tego wyjaśnienia powodów, mamy tego wystarczająco” – póki nie ma takich głosów, to ja uważam, że zawsze warto przypomnieć, po co.

Jacek: Kolejną radą, którą chcieliśmy się z Tobą podzielić, to jest rada: „Pracuj przyrostowo i wykorzystuj pętlę feedbacku”. Co mamy tutaj na myśli? „Pracuj przyrostowo”, czyli na koniec konkretnych iteracji, czy co jakiś okres czasu, dostarczaj przyrost produktu, czyli trochę lepszy produkt niż mieliśmy go chwilę temu. I dlaczego to jest istotne? Dlatego, że jeżeli faktycznie przyrostowo budujemy produkt i on rośnie w naszych oczach – i od superprostego produktu przechodzimy do coraz bardziej zaawansowanego rozwiązania. Jeżeli my czymś takim dysponujemy, to my możemy pokazać ten produkt interesariuszom, klientowi czy naszym użytkownikom. I to jest o tyle ważne, że pokazując coś takiego namacalnego, jesteśmy w stanie wywołać dyskusję i uruchomić pętlę informacji zwrotnej. I bardzo dobrze wspominam wszystkie momenty podczas Przeglądów Sprintu czy jakichś takich Przeglądów Produktu, gdzie Zespół Deweloperski pokazując taki namacalny przyrost, wywoływał uśmiech na twarzy interesariuszy czy uśmiech na twarzy użytkowników, którzy werbalnie wyrażali to, że podoba im się to, co zobaczyli – często wręcz dziękując zespołowi za to, że jakiś tam konkretny problem, który zgłaszali na przykład dwa czy trzy miesiące temu, został w końcu rozwiązany. I to jest takie, można powiedzieć, błahe, ale wielokrotnie przekonałem się, słuchając echa tych rozmów, czy w trakcie Retrospektyw, czy w trakcie trwania Sprintów czy iteracji, że te drobne pochwały, te drobne takie… wzmocnienia płynące od tych osób, dla których wytwarzamy produkt – są dla zespołu superważnym paliwem, dlatego nie rezygnowałbym z tego, natomiast, no, nie mając tych przyrostów, to no tak naprawdę nie mamy tego czegoś, co może wywołać dyskusję, która – jak tu przed chwilą powiedziałem – jest wartościowa z perspektywy teamu.

Kuba: Mam dokładnie świeże takie przemyślenie i podsumowanie pewnego etapu z zespołem, z którym aktualnie pracuję, że właśnie coś, co ja już nawet sobie nie uświadamiałem, jak bardzo motywuje ich wszystkich w zespole fakt, że uzyskujemy przyrosty. Ty mówisz: „Klient podziękuje”, ale to też jest ta perspektywa – zespół, mając już częściowo zbudowaną odpowiedzialność, sam nakręca się dalej, widząc, że: „Tak, każdy kolejny Sprint przynosi nam dobrą pracą wykonaną, widzimy różnicę” – to są takie małe kroki, które prowadzą nas we właściwą stronę. Ostatnią poradą, którą chcemy się podzielić w tym odcinku, to rada: „Monitoruj rezultaty”. Ona jest pewnie adekwatna zwłaszcza do zespołów, które rozwijają swój produkt już w dłuższym okresie czasu i mają ten produkt na rynku czy w użyciu przez użytkowników – wspominaliśmy o tym trochę ostatnio w odcinku o Przeglądzie Sprintu, że czasami brakuje niektórych elementów – tutaj, z perspektywy budowania odpowiedzialności za pracę i za efekty produktowe – czasami brakuje takiego elementu zastanowienia się, jak ten nasz produkt działa, jakie są rezultaty biznesowe, jakie jest użycie tego produktu, jakie są czasy użycia, jak zadowoleni są klienci – i to w zależności od tego, jaki jest nasz produkt, to mogą być bardzo różne rzeczy, bo jeśli mamy apkę, to jakie są oceny w sklepie, jeśli mamy produkt, który jest na rynku, to ile osób to zamawia, ile osób kupuje, jak idzie nam sprzedaż, czy klienci wracają – jeśli to jest rozwiązanie bardziej fizyczne, taki Scrum użyty do rzeczy poza IT, no to może możemy wprowadzić jakiś cykliczny monitoring – czy to wykorzystania, czy to zadowolenia z naszych rozwiązań – w każdym razie, to jest pewnie pewien wysiłek, pewna kreatywność, żeby to zrobić, ale jeśli mamy domkniętą tę pętlę informacji zwrotnej, nie tylko, że w czasie rozwoju produktu, w czasie rozwoju czy nawet projektu, sprawdzamy jak nam idzie, ale też po prostu, jak już teoretycznie zrobiliśmy wszystko, co chcieliśmy, w takim jakimś obszarze, to warto też wiedzieć, jak to się sprawdza – żeby mieć takie po prostu, takie domknięcie, takie podziękowanie – „Tak, idzie świetnie” – i to naprawdę super daje paliwo na przyszłość, że zrobiliśmy świetną pracę i ona w dodatku dała sukces. A gdyby miało się okazać w drugą stronę – że niestety są jakieś niedociągnięcia, no to wracamy do tego, co zrobiliśmy, możemy to poprawić, możemy poszukać – w najgorszym razie po prostu możemy się nauczyć, dlaczego nam nie wyszło, zastanowić się nad tym, a nie bezrefleksyjnie po prostu klepać kolejne kawałki, kolejne feature’y czy kolejne rozwiązania biznesowe.

Jacek: Tu robiąc tę poradę, gotową do praktycznego użycia, no to co najmniej takie dwa przykłady mi przychodzą do głowy. Pierwszy przykład to jest użycie dostępnych radiatorów informacyjnych – czy to w postaci jakichś tablic offline, czy w postaci narzędzi online, jakichś monitorów – i na bieżąco komunikowanie tych rezultatów do zespołu – w formie jakichś dashboardów, czy nawet po prostu zwykłych takich… chociażby kartek z jakimiś danymi, które przyklejane są w przestrzeni zespołu. Po co? Po to, żeby te dane gdzieś były, żeby można było w prosty sposób zrobić do nich referencje, albo żeby można było powiedzieć: „Zobaczcie, dzisiaj pobiliśmy jakiś tam rekord”. Znów, ktoś powie, że to są błahe rzeczy, że to są drobiazgi, natomiast nie ma magicznej różdżki, za dotknięciem której zespół stanie się odpowiedzialny za produkt, natomiast możemy robić takie małe, drobne rzeczy, które sumarycznie tą odpowiedzialność będą wzbudzać. Z drugiej strony – inny przykład jest taki, że kiedy rozmawiamy z zespołem o dalszych kierunkach rozwoju produktu czy o jakichś konkretnych funkcjach, atrybutach, które chcielibyśmy do produktu dodać, to też warto pamiętać, żeby posilić się jakimiś konkretnymi rezultatami, jakimiś konkretnymi danymi, żeby te nasze pomysły, czyli często też rzeczy, które są przedstawiane jako wymagania, żeby one miały jakieś osadzenie w rzeczywistości. Znów, żeby łączyć to, że na końcu jest jakiś użytkownik, jest jakiś klient, który ma jakiś problem, a my – co do zasady – naszym produktem chcemy mu pomóc ten problem rozwiązać.

Kuba:  I zamknę przykładem bardzo mocno z naszego własnego świata, czyli podcastu, bardzo sami jesteśmy zainteresowani tym, ilu z Was nas słucha, co sądzicie o tych odcinkach w komentarzach, jakie dajecie oceny w tych miejscach, gdzie te recenzje można zrobić, czy nawet, jak dzielicie nasze odcinki – czy podsyłacie, czy lajkujecie, czy gdzieś jeszcze komentujecie w sieci społecznościowej – no i to po prostu daje nam kolejne paliwo, wiemy, że jest cenione, ale też wsłuchujemy się w te głosy, gdzie ktoś podpowiada, co jeszcze można by nam prowadzić, co jeszcze możemy robić lepiej w naszych nagraniach. Więc jeśli jest jeszcze coś, co możemy zrobić, to koniecznie się tym z nami podziel.

Jacek: To tylko dodam, że w styczniu pobiliśmy razem rekord słuchalności – od początku, jak podcast publikujemy z Kubą, no to styczeń 2020 był rekordowy, no i mogę powiedzieć za siebie – jak się ogląda takie statystyki, no to chce się jeszcze bardziej, w sensie: dostarczyć więcej wartości, zrobić jeszcze lepszy materiał, docierać do jeszcze większej grupy osób, tak że… dziękuję Ci za to, słuchaczu.

Kuba: Podsumowując cały odcinek, jakie rady dajemy na to, żeby zbudować odpowiedzialność za produkt – zrozum o zdefiniuj produkt, spędź czas z użytkownikiem, znaj wizję produktu, przypominaj sobie o powodach realizacji inicjatywy, pracuj przyrostowo i wykorzystuj pętlę feedbacku i monitoruj rezultaty wykonanej pracy w swoim produkcie. I to by było wszystko na dzisiaj. Dzięki, Jacek.

Jacek: Dzięki, Kuba.

Kuba: I do usłyszenia…

Jacek i Kuba: …wkrótce!