ZBUDOWALI DOKŁADNIE TO, O CO PROSILI. I NIKT TEGO NIE UŻYWA.
Wyobraź sobie taką sytuację: zespół dostaje listę wymagań od biznesu, doprecyzowuje je na kilku refinementach, rozbija na user stories i układa w Product Backlogu. Zaczynają się Sprinty. Po kilku z nich, zespół dostarcza działające oprogramowanie. Biznes jest zadowolony, bo dostał to, o co prosił. Użytkownicy trochę gorzej, 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 ten 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. Wymaga trzech warunków organizacyjnych: autonomicznej roli, ciągłego dostępu do klientów i 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 ani jednorazowym warsztatem z użytkownikami. To trwał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 zmienić to, co zespół zbuduje – albo w ogóle zatrzymać budowanie. Jeśli decyzja jest już podjęta, a badania mają ją tylko uzasadnić, to nie jest discovery. To jest coś innego.
Teresa Torres, autorka „Continuous Discovery Habits, opisuje discovery jako cotygodniową interakcję z klientami w celu informowania decyzji produktowych. Dorzuciłbym jeden element: 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, estymowanie i priorytetyzowanie to praca z tym, co już wiadomo. Discovery to praca z tym, czego jeszcze nie wiadomo.
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. W większości organizacji nie ma ż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 na górę listy, są podejmowane przez biznes, architekturę lub management. PO jest tłumaczem i buforem, nie właścicielem kierunku produktu. Z taką pozycją nie można robić discovery, bo nie można działać na podstawie tego, co się odkryło. Zresztą nie ma czasu. Bo 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średnika z działu sprzedaży, czy tylko przez ankietę. Bezpośrednio, 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”. Trzeba wziąć pod uwagę dział obsługi, sprzedaży, compliance, account managerów czy regulacje. 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 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 możesz badać ile chcesz, ale to nic nie zmieni.
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 JEGO 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
ZBUDOWALI DOKŁADNIE TO, O CO PROSILI. I NIKT TEGO NIE UŻYWA.
Wyobraź sobie taką sytuację: zespół dostaje listę wymagań od biznesu, doprecyzowuje je na kilku refinementach, rozbija na user stories i układa w Product Backlogu. Zaczynają się Sprinty. Po kilku z nich, zespół dostarcza działające oprogramowanie. Biznes jest zadowolony, bo dostał to, o co prosił. Użytkownicy trochę gorzej, 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 ten 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. Wymaga trzech warunków organizacyjnych: autonomicznej roli, ciągłego dostępu do klientów i 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 przed każdą decyzją o budowaniu: czy rozwiązujemy właściwy problem, i czy proponowane rozwiązanie faktycznie ten problem rozwiązuje.
Kluczowe słowo to „ciągły”. Discovery nie jest fazą przed projektem. To nie Sprint 0 czy jednorazowy warsztat z użytkownikami. To trwał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 zmienić 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 cotygodniową interakcję z klientami w celu informowania decyzji produktowych. Dorzuciłbym do tego jeszcze jeden element: 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. Biznes wskazuje. A zadaniem zespołu jest to zrozumieć i dostarczyć. Szybko. Discovery zakłada inaczej. Nie wiemy jeszcze, co jest problemem i jak go rozwiązać. 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, estymowanie i priorytetyzowanie to praca z tym, co już wiadomo. Discovery to praca z tym, czego jeszcze nie wiadomo.
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. To decyzja organizacyjna. Żeby działało, muszą być spełnione trzy warunki. Niestety, w większości organizacji nie ma żadnego z nich.
Rola z realną autonomią decyzyjną
Ktoś musi mieć prawo powiedzieć „nie budujemy tego” na podstawie tego, czego się nauczył. Jeśli potrzebujesz „konsultacji” z komitetem sterującym, zgody sponsora, to będzie Ci bardzo ciężko. Organizacja („system”) będzie Cię wpychać w rolę wytwórcy.
W tzw. klasycznym polskim modelu produktowym, u Product Owner/a Product Managera autonomia jest pozorna. PO formalnie „zarządza backlogiem”, ale decyzje o tym, co trafia na górę listy, są podejmowane przez innych. Może to być tzw. biznes, architektura lub szeroko rozumiany management. PO jest tłumaczem i buforem, nie właścicielem kierunku produktu. Z taką pozycją nie można robić discovery, bo nie można działać na podstawie tego, co się odkryło. Zresztą nie ma czasu. Bo 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 raz na pół roku, nie przez pośrednika z działu sprzedaży, nie przez ankietę. Bezpośrednio, często, w sposób pozwalający zobaczyć, jak naprawdę działają.
W dużych organizacjach dostęp do klientów jest zazwyczaj „chroniony”. Po drodze do klienta jest dział sprzedaży, bok, compliance, account managerowie lub inni. 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 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 jednak: zakres i harmongoram jest zafixowany, a budżet przyznany na to masz dowieźć – możesz badać ile chcesz, ale to nic nie zmieni.
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ą.
Powód numer jeden: duże firmy nagradzają przewidywalność. Dostarczasz to, co obiecałeś, na czas i w budżecie – jesteś dobry. Discovery z kolei, ze swojej natury wiąże się z nieprzewidywalnością. Twoim zadaniem jest odkrywać. Może się zdażyć, ż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. Duże organizacje mają tendencję do centralizowania decyzji – szczególnie tam, gdzie stawki są wysokie. Bank, ubezpieczalnia, duże IT – to miejsca, gdzie decyzje o kierunku produktu rzadko należą do zespołu. Hierarchia jest wysoka, a komitety szybkie do „doradzenia” i „pomocy”.
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, praca niewidoczna w dashboardzie jest pracą o niskim statusie.
JAK ODRÓŻNIĆ PRAWDZIWE DISCOVERY OD JEGO 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. Lub 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 PO jako odpowiedzialności za Product Backlogu. Odpowiedzialność ta wyraża się poprzez zawartość i uporządkowanie backlogu, 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 tego procesu. 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 tworzysz coś dla innych.
CO DALEJ
Product discovery jest możliwe w dużych organizacjach. 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 pracujemy z organizacjami – LINK
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