ZBUDOWALI DOKŁADNIE TO, O CO PROSILI. I NIKT TEGO NIE UŻYWA.
Wyobraź sobie taką sytuację: zespół dostaje listę wymagań do zrealizowania. Doprecyzowuje je podczas kilku refinementów. Powstają user stories. Potem są one rozbijane na mniejsze części. Zespół układa je w logiczną, spójną całość w Product Backlogu. Zaczyna się development. Lecą sprinty. Po kilku z nich zespół dostarcza działające oprogramowanie. Biznes jest zadowolony, bo dostał to, o co prosił. Użytkownicy trochę mniej, bo korzystają z nowej funkcji rzadko albo wcale.
Widziałeś takie coś? Kto tu popełnił błąd?
Nikt. Każdy zrobił dokładnie to co miał wykonać. Tak ten system został zaprojektowany. Problem polega na tym, że taki proces – od wymagań do dostarczenia – nie zawiera odkrywania produktu. To nie jest product discovery. Choć w wielu organizacjach jest za taki uznawany.
TL;DR
Product discovery to ciągły proces odkrywania właściwych problemów i walidacji rozwiązań przed ich zbudowaniem. Nie jest techniką, etapem ani warsztatem. Potrzebujesz spełnić trzy warunki organizacyjne, żeby Ci zadziałało:
- autonomicznej roli;
- ciągłego dostępu do klientów;
- przyzwolenia na zmianę kierunku.
Większość dużych organizacji nie spełnia żadnego z tych warunków. I to nie jest przypadek, lecz logiczna konsekwencja tego, jak te organizacje są zbudowane.
CZYM JEST PRODUCT DISCOVERY
Product discovery to ciągły proces, w którym zespół produktowy odpowiada na dwa pytania zanim podejmie decyzję o zbudowaniu nowego ficzera. 1) Czy rozwiązujemy właściwy problem? 2) Czy proponowane rozwiązanie faktycznie ten problem rozwiązuje.
Kluczowe słowo to “ciągły”. Discovery nie jest “fazą” przed projektem, etapem przed Sprintem czy jednorazowym warsztatem z użytkownikami. To stała część pracy zespołu – równolegle do dostarczania, nie przed nim.
Drugi kluczowy element: pytania stawiane przed decyzją o budowaniu. Discovery ma sens tylko wtedy, gdy jego wynik może wpłynąć na to, co zespół zbuduje. Albo w ogóle zatrzymać budowanie. Jeśli decyzja została już podjęta, a badania mają ją tylko uzasadnić, to nie jest discovery. To jest coś innego. Polityka;)
Teresa Torres, autorka Continuous Discovery Habits, opisuje discovery jako ciągłą interakcję z klientami. Jej celem jest zbieranie, weryfikowanie, potwierdzanie i podejmowanie coraz lepszych decyzji produktowych. Discovery wymaga organizacji, która jest gotowa działać na podstawie tego, czego się nauczy – nawet jeśli to niewygodne.
CZYM PRODUCT DISCOVERY NIE JEST
Najczęstsze nieporozumienia, które widzę w praktyce:
Zbieranie wymagań. Zbieranie wymagań zakłada, że klient lub biznes wie, czego chce, i zadaniem zespołu jest to zrozumieć i dostarczyć. Discovery zakłada odwrotnie – że nie wiemy jeszcze, co jest problemem i co rozwiązuje problem. Musimy to odkryć. To fundamentalnie inna filozofia pracy.
Jednorazowy research UX. Badania z użytkownikami przeprowadzone raz na starcie projektu dają snapshot tego, co myślą dzisiaj. Discovery to ciągłe uczenie się, nie projekt badawczy z końcowym raportem.
Backlog refinement. Doprecyzowywanie historyjek, ich estymowanie i priorytetyzowanie do wykonania to praca z tym, co już wiesz, że jest do zrobienia. Discovery to praca z tym, czego jeszcze nie wiesz.
Demo z feedbackiem na końcu sprintu. Pokazywanie gotowego rozwiązania i zbieranie opinii to za późno. Discovery działa przed, nie po.
TRZY WARUNKI, KTÓRE DISCOVERY UMOŻLIWIAJĄ
Discovery nie jest kwestią metodyki. Jest kwestią projektu organizacji. Żeby działało, muszą być spełnione trzy warunki. Większość organizacji nie spełnia żadnego z nich.
Rola z realną autonomią decyzyjną
Ktoś musi mieć prawo powiedzieć “nie budujemy tego” na podstawie tego, czego się nauczył. Nie po konsultacji z komitetem sterującym, nie po zatwierdzeniu przez sponsora – samodzielnie, w ramach zdefiniowanego obszaru odpowiedzialności.
W tzw. “klasycznym polskim modelu produktowym”, u Product Owner/a Product Managera taka autonomia jest pozorna. PO formalnie “zarządza backlogiem”, ale decyzje o tym, co trafia do backlogu w praktyce podejmowane przez “biznes”. Może to być sprzedaż, marketing, szef management. Głównym zadniem PO ułożenie i wykonanie zadań. PO jest bardziej tłumaczem i buforem, niż właścicielem kierunku produktu. Z taką pozycją nie można trudno robić discovery, bo nie można działać na podstawie tego, co się odkryło. Zresztą często nie ma się czasu. Bo taki PO jest non stop zajęty “opieką nad zespołem”.
Ciągły dostęp do klientów i użytkowników
Discovery wymaga regularnego kontaktu z ludźmi, którzy używają produktu. Nie może się to odbywać raz na pół roku, przez pośredników czy tylko przez ankietę. Bezpośrednio oznacza często. W sposób pozwalający zobaczyć, jak naprawdę działają użytkownicy. Każde spotkanie to okazja by dowiedzieć się czegoś nowego, sprawdzić założenia, zebrać opinię.
W dużych organizacjach dostęp do klientów jest zazwyczaj “chroniony”. PO/PM musi wziąć pod uwagę różne działy. Dostać zgodę od obsługi klienta, sprzedaży lub compliance, account managerów czy regulacji. Zespół produktowy często nie wie, kto używa ich produktu, i nie ma jak się dowiedzieć. To nie jest problem do obejścia jednym warsztatem. To jest poważne ograniczenie strukturalne.
Przyzwolenie na zmianę kierunku
Discovery ma sens tylko wtedy, gdy możesz zmienić zdanie na podstawie tego, czego się nauczyłeś. Jeśli zakres, harmonogram i budżet jest zafixowany, to nie będziesz badać. Bo okaże się to sprzeczne z ograniczeniami.
W organizacjach, które planują rocznie lub kwartalnie z granularnym zakresem, discovery jest strukturalnie niemożliwe. Nie ma miejsca na to, żeby odkrycie zmieniło plan.
DLACZEGO WIĘKSZOŚĆ ORGANIZACJI TYCH WARUNKÓW NIE SPEŁNIA
To nie jest wynik złej woli ani ignorancji. To jest wynik tego, jak organizacje są zbudowane i co nagradzają.
Duże firmy nagradzają przewidywalność. Dostarczasz to, co obiecałeś, na czas i w budżecie – jesteś dobry. Discovery z natury generuje nieprzewidywalność: możesz odkryć, że trzeba zmienić kierunek, wyrzucić trzy miesiące pracy albo powiedzieć klientowi, że prosił o złe rozwiązanie. To jest wartościowe dla produktu i klienta, ale trudne do pogodzenia z kulturą zbudowaną wokół dotrzymywania obietnic.
Drugi powód: discovery wymaga autonomii, a duże organizacje mają tendencję do centralizowania decyzji. Szczególnie tam, gdzie stawki są wysokie. Bank, ubezpieczalnia, duży IT – to miejsca, gdzie decyzje o kierunku produktu rzadko należą do zespołu. Hierarchia jest głęboka, a komitety szybkie do “doradzenia”.
Trzeci powód: discovery jest niewidoczne dla osób zarządzających. Sprinty mają velocity. Discovery ma “rozmawialiśmy z kilkoma klientami”. W kulturze, która zarządza przez metryki wykonania pracy, praca niewidoczna w dashboardzie jest pracą o niskim statusie.
JAK ODRÓŻNIĆ PRAWDZIWE DISCOVERY OD TEATRU
Teatr discovery wygląda tak: organizacja ogłasza, że “robi product discovery”. Zatrudnia UX researchera, wprowadza Design Thinking warsztaty i dodaje do procesu etap “discovery” przed sprintem. Po roku okazuje się, że nic się nie zmieniło. Funkcje nadal wynikają z decyzji biznesu, terminy są nadal narzucane z góry, a badania są robione po to, żeby uzasadnić to, co i tak miało powstać.
Prawdziwe discovery ma konkretne przejawy:
- Zespół regularnie rozmawia z użytkownikami – nie przez pośrednika, nie raz na kwartał
- Wyniki tych rozmów zmieniają priorytety – regularnie, nie tylko przy dużych przeglądach
- Coś, co miało być zbudowane, nie zostało zbudowane, bo discovery pokazało, że to zły pomysł
- PO lub PM potrafi powiedzieć “zrezygnowaliśmy z X, bo odkryliśmy Y” – i nie musi tego tłumaczyć przed komitetem
Ten ostatni punkt jest najlepszym testem.
KRÓTKI TEST
Zapytaj cztery osoby z Twojej organizacji (product, biznes, delivery, management) osobno:
“Jaki był ostatni przypadek, gdy discovery zatrzymało lub zmieniło coś, co miało być zbudowane?”
Porównaj odpowiedzi. Jeśli nikt nie pamięta takiego przypadku – albo każdy wskazuje inny przykład sprzed roku – discovery nie działa w Twojej organizacji, niezależnie od tego, jak ten proces się nazywa.
FAQ
Scrum nie opisuje explicite, jak prowadzić discovery. Mówi o Product Backlogu i odpowiedzialności Product Ownera za wartość produktu wyrażoną poprzez ten backlog i jego zawartość, ale nie o samym procesie odkrywania. Discovery jest praktyką komplementarną do Scruma, nie jego elementem. Można robić Scrum bez discovery (jest duże ryzyko, że to będzie “słaby” Scrum) i discovery bez Scruma.
Odpowiedzialność leży zazwyczaj po stronie Product Ownera lub Product Managera, ale discovery nie jest pracą solo. Deweloperzy i UX są aktywnymi uczestnikami – ich wiedza techniczna i badawcza jest niezbędna do oceny, co jest możliwe i co faktycznie rozwiązuje problem.
Design thinking to framework myślenia o problemach, który dobrze pasuje do jednorazowych warsztatów lub projektów innowacyjnych. Product discovery to ciągła praktyka pracy zespołu produktowego. Jedno nie wyklucza drugiego – metody z design thinking można stosować w ramach discovery.
Nie, ale w cyfrowych produktach jest najszerzej stosowane i najlepiej opisane. Zasady – ciągłe uczenie się, walidacja przed budowaniem, dostęp do użytkowników – mają zastosowanie wszędzie tam, gdzie ktoś tworzy coś dla innych.
CO DALEJ
Product discovery jest możliwe w dużych organizacjach – ale wymaga świadomych decyzji o tym, jak zbudowane są role, procesy i struktury decyzyjne. Bez tego nawet najlepiej wyszkoleni Product Ownerzy będą robić zbieranie wymagań i nazywać to discovery.
Jeśli zastanawiasz się, czy w Twojej organizacji discovery faktycznie działa – lub chcesz zrozumieć, co je blokuje – zapraszam do rozmowy.
PRZYDATNE LINKI
Z tej serii:
- Dlaczego product discovery nie działa w Twojej organizacji – kolejny wpis z serii LINK
- Product Owner nie jest od odkrywania – i to jest problem – kolejny wpis z serii LINK
- Product Re-Discovery – jak pracuję z organizacjami
Inne warte sprawdzenia źródła:
- Teresa Torres, Product Talk – fundamenty ciągłego discovery, definicja i rola product trio LINK
- Teresa Torres, Product Talk – narzędzie do wizualizacji i planowania discovery LINK
- Marty Cagan, SVPG – perspektywa na discovery jako walidację przed pełnym zaangażowaniem inżynierów LINK
- Marty Cagan, SVPG – dlaczego discovery powinno być ciągłe, nie fazowe LINK