Pracując z zespołami Scrumowymi od ponad piętnastu lat, wielokrotnie obserwowałem ten sam scenariusz: świetnie zorganizowany zespół, sprawnie realizujący Sprint za Sprintem, dostarczający zgodnie z Definition of Done — a mimo to produkt nie odnosi sukcesu rynkowego. Dlaczego? Odpowiedź często sprowadza się do jednego fundamentalnego problemu: zespół budował “rzecz właściwie”, ale nie budował “właściwej rzeczy”.
To właśnie tutaj wkracza Product Discovery — proces, który moim zdaniem jest absolutnie kluczowy dla każdego zespołu Scrumowego. Proces, który niestety zbyt często jest pomijany lub przeprowadzany pobieżnie.
Czym właściwie jest Product Discovery?
Product Discovery to systematyczny proces zmniejszania niepewności związanej z tym, co powinniśmy budować. Proces Discovery zapewnia to, że wysiłki deweloperskie koncentrują się na tworzeniu rozwiązań, które są wartościowe dla użytkowników, opłacalne dla biznesu i technologicznie wykonalne.
Product Discovery to “znajdowanie i walidowanie szans produktowych” poprzez głębokie zrozumienie potrzeb użytkowników, aktualnych trendów rynkowych i identyfikację potencjalnych obszarów rozwoju.
Cały proces Product Discovery można podzielić na 4 fazy:
1. Poznanie i zrozumienie (Learn & Understand)
W tej fazie zespół bada potrzeby i problemy użytkowników, nie zakładając z góry żadnych rozwiązań. Stosuje się takie techniki jak wywiady z klientami, analiza konkurencji i analiza danych produktowych. Celem jest głębokie zrozumienie rzeczywistych wyzwań użytkowników.
2. Definiowanie i decydowanie (Define & Decide)
W tej fazie zespół analizuje zebrane informacje, identyfikuje powtarzające się problemy i formułuje hipotezy dotyczące potencjalnych rozwiązań. Technika 5 Whys pomaga w dotarciu do źródła problemów i ich lepszym zrozumieniu.
3. Wymyślanie rozwiązań i priorytetyzacja (Ideate & Prioritize)
Na tym etapie zespół tworzy różne pomysły na rozwiązania zidentyfikowanych problemów, wykorzystując burze mózgów i inne techniki kreatywne. Następnie zbiera oczekiwania użytkowników i na tej podstawie ocenia i priorytetyzuje te pomysły, aby wybrać najbardziej obiecujące do dalszego rozwoju.
4. Prototypowanie i testowanie (Prototype & Test)
W tej ostatniej fazie zespół tworzy prototypy wybranych rozwiązań i testuje je z użytkownikami, aby zebrać ich opinie. Na podstawie wyników tych testów zespół dalej ulepsza produkt lub wraca do wcześniejszej fazy, jeśli zaproponowane rozwiązanie się nie sprawdziło.
Każda z tych faz ma na celu zapewnienie, że rozwijany produkt rzeczywiście odpowiada na potrzeby użytkowników i rozwiązuje ich problemy, minimalizując ryzyko niepowodzenia na rynku.
Istotą Discovery jest odpowiedź na pytania:
- Jaki problem rozwiązujemy?
- Czego chcą nasi użytkownicy?
- Kim są nasi użytkownicy?
- Co dostarczy największą wartość?
- Czy problem wart jest rozwiązania?
- Czy nasze rozwiązanie zadziała?
- Czy jest lepsze niż inne dostępne rozwiązania?
Pamiętam sytuację z jednego z banków, gdzie zespół zbudował zaawansowany system promocji dla kart kredytowych. Spędzili sześć miesięcy na rozwoju tego systemu, tylko po to, by odkryć, że klienci w ogóle nie byli zainteresowani takimi promocjami — interesowało ich coś zupełnie innego. Sześć miesięcy pracy poszło do kosza — wszystko dlatego, że zabrakło solidnego procesu Discovery.
Dlaczego Product Discovery jest niezbędne w Scrumie?
Scrum dostarcza solidne “jak” do efektywnego i adaptowalnego budowania produktów, ale to Product Discovery dostarcza kluczowe “co” i “dlaczego”. Bez silnej i ciągłej praktyki Discovery zespoły Scrumowe ryzykują, że staną się wysoce efektywne w budowaniu niewłaściwego produktu — produktu, który nie spełnia potrzeb użytkowników ani nie osiąga celów biznesowych.
Statystyki są bezlitosne: 42% startupów upada, ponieważ zbudowały produkt bez popytu rynkowego. A to właśnie solidne Discovery ma na celu uniknięcie tej pułapki.
W Scrumie skupiamy się na inkrementalnym dostarczaniu wartości i adaptacji do zmian. Ale skąd wiemy, co faktycznie stanowi wartość? Tutaj właśnie Product Discovery jest niezbędne — to dyscyplina dedykowana odkrywaniu prawdziwych potrzeb i walidowaniu, czy proponowane rozwiązania faktycznie je adresują.
Refinement i czas poświęcany na Product Discovery
Jedna rzecz, która często wywołuje kontrowersje, to kwestia czasu poświęcanego na refinement i discovery. Scrum Guide wspomina o tym, że refinement zazwyczaj zajmuje nie więcej niż 10% czasu zespołu. Jednak jest tu pewne nieporozumienie, które warto wyjaśnić.
Te 10% odnosi się do zespołów, które dobrze współpracują i znają swój produkt. W rzeczywistości na początku pracy nad nowym produktem lub w nowym zespole refinement (włączając w to elementy discovery) może zajmować znacznie więcej czasu. Początkowo wydajność będzie niska, ale z czasem powinna rosnąć, w miarę jak zespół lepiej poznaje produkt i domeny biznesowe.
Pojawia się też pytanie: jak możemy mieć gotowe elementy Product Backlogu przed pierwszym Sprintem? Odpowiedź brzmi — nie musisz ich mieć. Ustalasz je w trakcie Sprintu. To jest częścią adaptacyjnego charakteru Scruma — zaczynasz od tego, co wiesz, i iteracyjnie budujesz na tej wiedzy.
Jak wpleść Product Discovery w rytm Scruma?
To pytanie słyszę najczęściej. Gdy pracuję z organizacjami, które chcą wprowadzić Product Discovery, często panuje przekonanie, że to dodatkowy, oddzielny proces — coś, co trzeba wykonać “przed Scrumem”. Nic bardziej mylnego!
Product Discovery nie jest jedynie wstępną fazą, która kończy się przed rozpoczęciem Sprintów deweloperskich. Jest to ciągły i iteracyjny proces, który działa równolegle i przecina się z działaniami deweloperskimi. Relację tę najlepiej opisać jako “cykle odkrywania i rozwoju, które przecinają się i wzajemnie się zasilają”.
W praktyce wygląda to tak:
1. Wplecenie Discovery w formalne wydarzenia Scrumowe
Każde z formalnych wydarzeń Scrumowych dostarcza cennych możliwości do przeprowadzenia Product Discovery:
- Sprint Planning: To wydarzenie może obejmować planowanie zadań związanych z discovery lub eksperymentów, jeśli są one częścią Sprintu.
- Daily Scrum: Choć głównie dla Developerów, jeśli zadania związane z discovery są częścią Sprint Backlogu, można omawiać postępy i przeszkody związane z tymi zadaniami.
- Sprint Review: To wydarzenie jest doskonałą okazją do Product Discovery. Zespół Scrumowy i interesariusze sprawdzają Przyrost, co dostarcza namacalnych dowodów na potwierdzenie lub zanegowanie hipotez postawionych podczas discovery. Feedback zebrany od użytkowników i interesariuszy podczas Sprint Review jest bezpośrednim wkładem dla przyszłych cykli discovery.
- Sprint Retrospective: Zespół sprawdza własne procesy i praktyki, w tym to, jak efektywnie przeprowadzali działania discovery podczas Sprintu oraz jak dobrze zintegrowali zdobytą wiedzę.
2. Continuous Refinement jako kluczowy moment integracji
Refinement, choć nie jest formalnym, timeboxowym wydarzeniem Scrumowym, okazuje się absolutnie kluczowy dla integracji Discovery ze Scrumem. Podczas gdy inne wydarzenia oferują punkty styku, refinement jest miejscem, w którym ciągły strumień odkryć z discovery — surowe potrzeby użytkowników, potencjalne rozwiązania, zwalidowane wnioski — jest systematycznie przetwarzany i przekładany na wykonalne zadania dla Developerów.
Backlog Produktu jest jedynym źródłem prawdy (ang. single source of truth) dla pracy Zespołu Scrumowego. Aby spostrzeżenia z discovery zmaterializowały się jako rozwinięte funkcje lub zwalidowane wnioski, muszą najpierw stać się dobrze zrozumianymi, oszacowanymi i spriorytetyzowanymi elementami Product Backlogu.
Co ważne, walidacja w kontekście dopasowania rynkowego czy zrozumienia potrzeb użytkowników służy zrozumieniu, co powinno znaleźć się w Product Backlogu, więc to de facto refinement Backlogu lub konkretnych PBI. Jak wspomniał Paul Kuijten, budowanie i wydawanie produktu również jest formą walidacji. Kiedy otrzymasz feedback, może to wpłynąć na twój Product Backlog.
3. Dual-Track Agile
Jednym z bardziej zaawansowanych podejść jest Dual-Track Agile, które zostało zaprojektowane specjalnie do prowadzenia dwóch odrębnych, ale powiązanych strumieni pracy równolegle: ścieżki Discovery i ścieżki Delivery.
- Ścieżka Discovery koncentruje się głównie na wymyślaniu, testowaniu i walidowaniu pomysłów na produkt. Jej głównym celem jest określenie “co budować” poprzez prowadzenie badań użytkowników, tworzenie i testowanie prototypów oraz rygorystyczne walidowanie założeń dotyczących potrzeb użytkowników i potencjalnych rozwiązań.
- Ścieżka Delivery odpowiada za przekształcenie tych zwalidowanych pomysłów w namacalny, działający produkt. Koncentruje się na “jak to zbudować” i działa tak samo jak standardowe Sprinty w Scrumie.
W praktyce oznacza to, że gdy zespół delivery jest zaangażowany w budowanie i testowanie jednego zestawu funkcji w ramach Sprintu, zespół discovery (lub dedykowana część Zespołu Scrumowego koncentrująca się na discovery) jednocześnie eksploruje i waliduje kolejny zestaw potencjalnych możliwości i rozwiązań.
Role i odpowiedzialności w Product Discovery
Efektywne Product Discovery w ramach Scruma opiera się na jasno określonych rolach i współpracy całego zespołu oraz odpowiednich interesariuszy:
- Product Owner (PO): PO zazwyczaj prowadzi i promuje proces Product Discovery. Jest odpowiedzialny za Product Backlog, który jest ciągle kształtowany i priorytetyzowany przez spostrzeżenia z discovery. PO również definiuje i komunikuje wizję i strategię produktu.
- Developerzy: Aktywne zaangażowanie Developerów w Product Discovery jest kluczowe. Wnoszą oni niezbędną wiedzę techniczną do oceny wykonalności proponowanych rozwiązań, przyczyniają się do innowacyjnego projektowania rozwiązań i mogą zyskać głębsze zrozumienie potrzeb klientów poprzez bezpośrednią interakcję podczas badań.
- Scrum Master ℠: Scrum Master ułatwia działania discovery w ramach frameworku Scrum. Pracuje nad usunięciem wszelkich przeszkód, które utrudniają efektywne discovery i coachuje zespół w zakresie najlepszej integracji praktyk discovery z jego przepływem pracy i wydarzeniami Scrumowymi.
W praktyce często obserwuję wyłanianie się tzw. “Product Trio” — zwykle składającego się z Product Managera (lub PO), Designera i Tech Leada. Ta kluczowa grupa współpracuje ściśle na bieżąco, aby prowadzić działania discovery, przeprowadzać badania użytkowników, tworzyć pomysły na rozwiązania i walidować założenia.
Techniki Product Discovery w kontekście Scruma
Z mojego doświadczenia najbardziej efektywne techniki Discovery w zespołach Scrumowych to:
- Wywiady z klientami: Głównie wykorzystywane w fazie Learn & Understand, aby uzyskać głębokie jakościowe informacje o motywacjach, problemach i kontekstach użytkowników.
- Analityka produktu: Stosowana na wszystkich etapach do przeglądania ilościowych danych użytkowników, informowania procesu decyzyjnego, walidacji ustaleń jakościowych i identyfikacji obszarów do poprawy lub rozwoju nowych funkcji.
- Technika Pięciu Dlaczego (5 Whys): Stosowana w fazie Define & Decide, aby dotrzeć do pierwotnej przyczyny zidentyfikowanych problemów.
- Burza mózgów: Stosowana podczas fazy Ideate & Prioritize, aby generować szeroką gamę potencjalnych rozwiązań i pomysłów na funkcje w sposób kolaboratywny.
- Techniki priorytetyzacji: Wykorzystywane w fazie Ideate & Prioritize, aby systematycznie określić, które pomysły lub funkcje realizować jako pierwsze, na podstawie kryteriów takich jak wartość, wysiłek, ryzyko i wpływ.
- Prototypowanie: Kluczowe dla etapów Ideate & Prioritize oraz Prototype & Test, umożliwiając wizualizację i testowanie koncepcji przed pełnym rozwojem.
- Testy użyteczności: Przeprowadzane podczas Prototype & Test, aby ocenić, jak łatwo użytkownicy mogą wchodzić w interakcję i rozumieć prototyp lub produkt.
- Testy A/B: Metoda ilościowa stosowana w fazie Prototype & Test, aby porównać dwie lub więcej wersji funkcji lub designu, aby określić, która działa lepiej w odniesieniu do określonych metryk.
Balansowanie walidacji i szybkości działania
Możesz zastosować różne formy walidacji, ale w pewnym momencie koszt będzie wyższy niż faktyczne zbudowanie i dostarczenie przyrostu. Zdecydowanie nie ma sensu poświęcać zbyt dużo czasu i budżetu na walidację. Kluczowe pytania, które należy zadać, to: “Jaki jest koszt?” i “Jakie jest ryzyko?”. Karta eksperymentów może pomóc w podjęciu decyzji, czy potrzebujemy walidować pomysł, czy nie.
Jeśli jednak utkniesz przy podejmowaniu decyzji, lepiej jest zwalidować pomysł i dopiero wtedy podjąć tę decyzję.
Czy powinieneś walidować wszystko przed pracą w Sprincie? Zdecydowanie nie. Nie chcemy sześciomiesięcznego okresu “Inception” przed wykonaniem właściwej pracy. Nie chcemy też drugiego Product Backlogu do inkubacji pomysłów. Time to Market i Cost of Delay ucierpiałyby na tym.
Wyzwania związane z Product Discovery w Scrumie
Wdrażanie Product Discovery w Scrumie nie jest pozbawione wyzwań. Oto najczęstsze problemy, z którymi spotykam się w praktyce:
- Brak informacji i analizy przed planowaniem: Rozpoczęcie rozwoju bez wystarczającego zrozumienia potrzeb użytkowników lub kontekstu rynku prowadzi do niepewności i potencjalnie wadliwych produktów.
- Przytłaczający Product Backlog i słaba priorytetyzacja: Niewykonalny backlog wypełniony niezwalidowanymi pomysłami może prowadzić do niedopasowania celów, frustracji zespołu i opóźnień projektu.
- Zarządzanie wieloma interesariuszami i sprzecznymi żądaniami: Różni interesariusze często mają różne, czasem sprzeczne, oczekiwania i priorytety.
- Zmęczenie decyzyjne: Ciągła potrzeba podejmowania szybko licznych decyzji, nieodłączna w środowiskach Agile z ciągłym discovery, może prowadzić do wypalenia i zmniejszonej jakości decyzji.
Warto zauważyć, że wiele wyzwań postrzeganych jako “problemy Scruma” — takich jak niewykonalne backlogi, niedopasowanie interesariuszy czy trudności w priorytetyzacji — często są symptomatyczne dla podstawowych niedociągnięć w praktykach Product Discovery. Gdy discovery jest słabe lub nieobecne, zespołom brakuje niezbędnej jasności co do tego, które problemy użytkowników są najbardziej krytyczne do rozwiązania i które potencjalne rozwiązania dają największe nadzieje.
Realne korzyści z Product Discovery w Scrumie
Efektywna integracja praktyk Product Discovery z frameworkiem Scrum przynosi znaczące korzyści, które rozciągają się poza samo budowanie lepszych funkcji:
- Budowanie produktów o dużym wpływie, zgodnych z potrzebami klientów: Product Discovery zapewnia, że wizja produktu i wynikający z niej Product Backlog są głęboko zakorzenione w zwalidowanym zrozumieniu potrzeb i problemów klientów.
- Minimalizowanie ryzyka, redukcja marnotrawstwa i oszczędzanie zasobów: Product Discovery systematycznie zmniejsza ryzyko związane z pomysłami i elementami Product Backlogu, zanim pochłoną one cenną pojemność Sprintu.
- Wzmacnianie spójności zespołu, innowacyjności i zdolności adaptacyjnych: Wspólne zrozumienie problemów użytkowników i celów produktu, kultywowane poprzez współpracę w discovery, napędza spójność Zespołu Scrumowego, zaangażowanie i wspólną odpowiedzialność.
- Zwiększona przejrzystość i wspólne zrozumienie: Efekty Product Discovery — takie jak persony, roadmapy, zwalidowane stwierdzenia problemów i prototypy — czynią “co” i “dlaczego” produktu przejrzystym i dostępnym dla całego zespołu i kluczowych interesariuszy.
Podsumowanie: Jak zacząć z Product Discovery w Scrumie?
Jeśli dopiero zaczynasz swoją przygodę z Product Discovery w kontekście Scruma, oto kilka praktycznych kroków na początek:
- Zacznij od małych eksperymentów — nie trzeba od razu wdrażać pełnego Dual-Track Agile. Zacznij od dodania kilku konkretnych zadań discovery do Sprint Backlogu.
- Zaangażuj cały zespół — Discovery to nie tylko zadanie dla Product Ownera. Developerzy powinni aktywnie uczestniczyć w zrozumieniu problemów użytkowników.
- Wykorzystaj istniejące wydarzenia Scrumowe — nie musisz tworzyć nowych spotkań. Sprint Review jest doskonałą okazją do zbierania feedbacku, a Refinement do przekładania wniosków na konkretne PBI.
- Zbuduj “Discovery mindset” — najważniejsza jest zmiana myślenia z “budujmy funkcje” na “rozwiązujmy problemy”.
- Mierz i adaptuj — śledź, czy twoje działania discovery faktycznie prowadzą do lepszych decyzji produktowych i większej wartości dla użytkowników.
Pamiętaj, że droga do doskonałego połączenia Product Discovery ze Scrumem jest iteracyjna i wymaga ciągłego doskonalenia — zupełnie jak procesy, które promuje. Przyjmując podejście odkrywania, czego potrzebuje użytkownik, tak szybko i tanio, jak to możliwe i stosując strategie omówione w tym poście, zespoły mogą wyjść poza samo budowanie funkcji i konsekwentnie tworzyć produkty, które dostarczają realną wartość, rezonują z użytkownikami i osiągają trwały sukces na dynamicznym rynku.
