“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
– Albert Einstein
Na pierwszy rzut oka Product Discovery oraz faza Delivery w agile to dwa różne modele pracy, jednak w obu z nich chodzi o jedno: chcemy zbudować najlepszy możliwy produkt, który będzie niósł za sobą wartość. Ważne jest, aby pomyśleć o nich jako o dwóch częściach jednego procesu. W tym artykule chcę poddać rozważaniom, kiedy Product Discovery przenika się z Delivery i jakie ma to korzyści wpływające na powstający produkt.
Przecież my wiemy, czego chcemy
Scrum, czyli jeden z frameworków Agile, jest najbardziej znaną praktyką stosowaną w procesie delivery, czyli wytwarzania i dostarczania produktów w zwinny sposób. Można więc przyjąć, że powołując zespół scrumowy mamy wszystkie kompetencje do tego, aby zbudować produkt. W Scrumie przyjmuje się, że Product Owner zwraca się do interesariuszy po wymagania biznesowe, a czasami zbiera także dane o użytkownikach, aby podjąć decyzje, jakie funkcjonalności wpłyną na maksymalizowanie wartości produktu. Z tymi danymi udaje się do zespołu, który z kolei dopracowuje zadania wynikające z tych danych, szacuje prędkość dostarczania i planuje swoją pracę w sprintach, a na koniec ją weryfikuje. Każda iteracja powinna skończyć się dostarczonym przyrostem, czyli kawałkiem wartości, który przybliży nas do celu produktu. Prace w tym procesie bazują na przewidywalności i jakości. Scrum pozwala w sposób transparentny wytworzyć przyrost gotowy do wydania, dając nam dane, które z iteracji na iterację staramy się usprawniać.
Brzmi dobrze, więc w czym problem?
Problem w tym procesie polega na tym, że odkrycie początkowych założeń (discovery), z których ma powstać backlog, wymaga wiele czasu, wysiłku i różnych kompetencji, których nie posiadają tylko Product Ownerowie. W rezultacie często przyjmują oni założenia, które są zbyt mało zweryfikowane. Nie jest to wina samych PO, często to organizacja przyjmuje taki model pracy. Bez dłuższego czasu na badania z użytkownikami, czyli bez poświęcenia czasu na proces discovery, ryzykujemy i zakładamy w ciemno, że nasze hipotezy są poprawne. Uważam, że głównym tego powodem jest brak myślenia nastawionego na klientocentryczność. Nie chodzi tutaj tylko o organizację, ale także o osoby budujące dane rozwiązanie. Cały zespół produktowy powinien być odpowiedzialny za sukces produktu, a nie tylko za tworzenie rzeczy z góry założonych.
W takim razie od czego zacząć?
Na początku warto wyjaśnić pojęcie Product Discovery. Jest to zwinny proces odkrywania produktów skoncentrowany na użytkownikach, który umożliwia głębokie zrozumienie ich problemów i potrzeb. Poprzez iteracyjne badania, weryfikowanie i testowanie postawionych hipotez pozwala walidować pomysły, zanim zostaną przekazane do finalnej realizacji. Product Discovery upewnia nas, że pracujemy nad rzeczami, których faktycznie chcą klienci i tym samym nie marnujemy czasu na wdrażanie zbędnych funkcjonalności. Najbardziej znanym narzędziem wspierającym ten proces jest Opportunity Solution Tree autorstwa Teresy Torres, które polega na określeniu celów biznesowych czy KPI i na tej podstawie dopasowaniu i szukaniu szans (opportunities). Szanse to problemy klientów, ich pains/gains oraz jobs-to-be-done, ale mogą to być także sygnały zmian z rynku. Szukanie szans to najważniejszy etap, ponieważ te informacje przyczynią się do rozwoju produktu. Na sam koniec, gdy szanse zostały potwierdzone w badaniach oraz powstały początkowe koncepty, można wybrać sposób walidacji, który szybko zweryfikuje nasze pomysły.
Pracując blisko zespołów produktowych, napotykałam wiele problemów z połączeniem Discovery i Delivery w jeden działający proces, który angażuje cały zespół. Chciałam spojrzeć holistycznie na budowanie produktów, więc zaczęłam interesować się zaproponowanym przez Jeffa Pattona oraz Marty’ego Cagana procesem o nazwie Dual Track, opisanym przez nich w 2012 roku.
“Dual Track” obejmuje dwie ścieżki: Discovery – nakierowuje nas na to, co należy zbudować oraz Delivery – określa, jak to zbudować. Taki proces pozwala na osiągnięcie równowagi i zaangażowanie wszystkich w jednym czasie. Oczywiście możemy na ten model spojrzeć także z perspektywy krzywego zwierciadła i stwierdzić, że na początku powołamy zespół UX designerów, którzy odkryją ciekawe rzeczy i na tej podstawie zostanie podjęta decyzja produktowa, czyli „gotowiec” do wdrożenia dla programistów. Jednak powstanie wtedy spora dysfunkcja o nazwie silos, która sprowadzi zespół programistów do osób „klepiących” kod, a zespół UX designerów do marzycieli oderwanych od technicznych aspektów. Nie będzie wspólnej wizji ani celu, do którego zmierza razem zespół. To najgorsza z opcji, ponieważ w zespole nie będzie pełnego zrozumienia, dlaczego budujemy akurat to, a nie coś zupełnie innego.
“If you’re just using your engineers to code, you’re only getting about half their value.”
– Marty Cagan
Dual Track pozwala na to, aby zespół programistów (delivery) pracował nad dostarczaniem zaplanowanych zadań, ale był także zaangażowany w fazę, w której zespół discovery odkrywa kolejne szanse i dostarcza nowe informacje.Obie ścieżki działają iteracyjnie, aby stale dostarczać wartość użytkownikom.
Ten model będzie miał sens, gdy weźmiesz pod uwagę parę aspektów:
- Aby podejmować wartościowe, użyteczne i wykonalne decyzje w procesie discovery potrzebujemy pełnego zaangażowania core teamu: Product Managera/Product Ownera, UX Designera i Tech Leada.
- Konieczne jest wyznaczenie na początku wizji produktu oraz mocnych celów biznesowych, które są mierzalne i skoncentrowane na tym, co faktycznie chcemy osiągnąć.
- Wszyscy pracują równolegle w tych samych sprintach i wyznaczonych timeboxach oraz uczestniczą we wspólnych spotkaniach planning, review, retro i daily.
- Cały zespół wspólnie weryfikuje hipotezy, sprawdza wyniki badań, wymyśla początkowe koncepty – ma wpływ na to, co zostanie wdrożone.
- Powinniśmy od początku angażować interesariuszy w pracę, ponieważ mają unikatową wiedzę, która wychodzi poza zakres wiedzy zespołu produktowego.
Z czym musimy się liczyć, wdrażając Dual Track?
- Proces Discovery jest ciągły
Ten proces się nie kończy. Zawsze będzie coś, co trzeba zbadać, zweryfikować, testować, szukać kolejnych szans, które dadzą nam kolejne wartości w produkcie. Nie można myśleć, że jeśli raz coś zbadamy, to już w kolejnej iteracji nie trzeba tego robić. Cały czas jest coś do odkrycia. - Elastyczność popłaca
Często kiedy coś odkrywamy, to zmieniamy nasze przekonania i decyzje. Może okazać się, że to, co zweryfikowaliśmy, zmienia nasze hipotezy i założenia, a więc musimy zmienić plan działania, poszukując najlepszych rozwiązań. - To, co chcemy zrobić, jest niepotrzebne
Może okazać się, że cały pomysł, który wydawał się innowacyjny, nie jest wcale potrzebny naszym użytkownikom. Jednak to niesie za sobą perspektywę sukcesu, ponieważ tym odkryciem zaoszczędzimy sporo pieniędzy. - Uważaj, bo popłyniesz
Proces Discovery lubi wyjść poza ramy i możemy zapętlić się w działaniach. Ważne jest, aby wyznaczyć konkretne timeboxy na testy i eksperymenty, żeby nie wyjść poza budżet oraz nie stworzyć takiej bazy danych, z której będzie ciężko wyciągnąć to, co faktycznie jest dla nas istotne. - Bez zmiany myślenia to się nie uda
Kultura organizacji musi być nastawiona na klientocentryczność. Bez poświęcania odpowiedniej ilości czasu na proces odkrywania, nie ma szans na sukces. Uważam, że największą blokadą dla organizacji jest obawa, że to, co zostanie odkryte, być może nie będzie zgodne z początkową wizją.
Podsumowanie
Dual Track to świetna baza do tego, aby spróbować pracować zwinnie w obszarach discovery i delivery. Firmy produktowe czy start-upy z pewnością łatwiej wdrożą ten model niż organizacje pracujące na co dzień z wieloma różnymi klientami, którzy mają również swoje własne sposoby pracy. Warto zastanowić się, co z Dual Track można zaimplementować do obecnego środowiska, a dodatkowo od czego zacząć, aby zmienić myślenie w kierunku pracy, która będzie skoncentrowana na wytwarzaniu produktów, których faktycznie chcą nasi użytkownicy.
Scrum Master, Trener, Facylitator IAF, a także założycielka firmy szkoleniowo-doradczej Flow Together. Kasia swój profil zawodowy budowała w środowiskach technologicznych, gdzie pracowała jako Project Manager, a później Scrum Master. Przez ostatnie lata była w środku transformacji największego bukmachera w Polsce. Obecnie wspiera organizacje i zespoły produktowe w zwinnym odkrywaniu i wytwarzaniu produktów. Z wykształcenia magister zarządzania, ukończyła także liczne kursy i certyfikacje z zakresu Agile, Design Thinking, Product Discovery czy facylitacji.