Product Discovery, czyli jak odpowiedzieć na potrzeby użytkowników

O sztuce poznawania potrzeb użytkowników, narzędziach przydatnych w definiowaniu produktu i twórczym wpływie nieprzewidywalności na jego kształtowanie opowiada Tomasz Wykowski, autor książki „Scrum: jak osiągać cele, gdy wszystko się zmienia?”, jedyny polski Certified Scrum Trainer® oraz prowadzący warsztat Product Discovery podczas ABE Light 2020.

Czym jest i co umożliwia Product Discovery?
Product Discovery przede wszystkim warto traktować szerzej niż jako proces czy fazę pracy. To bardziej sposób działania organizacji – podobnie jak PR, Customer Relationship czy User Experience. Cała koncepcja bazuje na tym, aby dowiedzieć się, jakie potrzeby mają użytkownicy, a następnie tworzyć rozwiązania, które na te faktyczne oczekiwania odpowiedzą. Podstawą odkrywania produktu jest założenie, że wielu rzeczy o tym produkcie czy usłudze nie wiemy. Zaakceptowanie tej niewiedzy pozwala wpisać uzyskiwanie nowych informacji w cały proces wytwarzania produktu. Umożliwia ulepszanie go na bieżąco oraz dobre przygotowanie na wystąpienie nieprzewidzianych czynników i adaptację do nich.

Trzymanie się określonego planu może sprawić, że zespół nie będzie umiał poradzić sobie z nieoczekiwanymi zmianami – czy to tu kryje się wartość stosowania Product Discovery?
Wiele firm ulega złudzeniu, że wie, jakie są potrzeby użytkowników. Według tego przekonania definiują produkt i dostarczają go w drodze schematycznego, „sztywno” ustalonego procesu. Jednak w większości przypadków czekają nas zaskoczenia. Dowiadujemy się, że użytkownicy korzystają z naszego urządzenia inaczej, niż przewidywaliśmy lub że rynek czy konkurencja inaczej na niego zareagowały. Pojawia się frustracja, że coś przeoczyliśmy i nasz plan jest nieadekwatny, „sypie się”. Jeżeli jednak od początku założymy, że chcemy przez cały czas odkrywać tę wiedzę, będziemy mogli dostosowywać nasze plany na bieżąco, a nieprzewidywalność, zamiast być źródłem obaw, pozwoli wykorzystać nadarzające się możliwości.

Jak więc w praktyce zacząć budowanie kultury Product Discovery w swojej organizacji?
Efektywność Product Discovery jest możliwa, jeśli zespół, który poszukuje rozwiązań, zajmuje się też ich implementacją. Jeśli tego nie uwzględnimy, w organizacji wyszczególni się komórka, która będzie wiedzę o potrzebach użytkownika przekazywać do innych działów. W efekcie proces wypracowania i wdrożenia rozwiązań zostanie podzielony, a tego w Product Discovery staramy się unikać, w trosce o jakość produktu. W samy zespole ważne jest, by każdy z jego członków rozumiał, jaki problem rozwiązuje i jakiemu celowi służą określone działania. Warto zadać podstawowe pytania: Po co to robimy? Jak to chcemy osiągnąć? Dla kogo to robimy – kto jest użytkownikiem? Jakie funkcjonalności damy naszym klientom?

Jakie narzędzia mogą pomóc w odpowiedzi na te pytania? Jak je dobierać?
Przydatnych narzędzi jest obecnie wiele. Od technik tworzenia wizji produktu, przez praktyki do definiowania strategii i sposobów ich osiągania (jak Impact Mapping). Do dyspozycji mamy też techniki zrozumienia użytkownika (np. persony, Empathy Maps, czy historyjki użytkownika). W ostatniej dekadzie bardzo łatwe stało się szybkie testowanie hipotez (np. A/B testy).

To od zespołu zależy, jakie narzędzia uzna za najbardziej przydatne. Warto zastanowić się najpierw, w których obszarach czeka na nas najwięcej niewiadomych i które są najbardziej ryzykowne. Mogą to być przeszkody technologiczne (rzadko) lub niedopasowanie do rynku, niezrozumienie potrzeb użytkownika czy niemożność ich spełnienia. Wybierajmy te narzędzia, które pozwalają zaadresować dane problemy i przetestować określone hipotezy.

A jak wygląda Product Development w kontekście Product Discovery?
Oba elementy mają miejsce jednocześnie. Product Development to ciągły proces. Po każdej implementacji powinniśmy szybko ocenić produkt i w razie potrzeby – udoskonalić go. Liczy się czas reakcji. Zwlekając, zwiększamy ryzyko, że nie rozwiązujemy rzeczywistego problemu użytkownika. Jeżeli przez długi czas nie dostajemy feedbacku, to prawdopodobnie robimy to, co nie jest potrzebne. Dlatego tak ważny jest dialog między członkami zespołu deweloperskiego oraz z odbiorcą produktu – zespół na bieżąco tworzy hipotezy, ale musi jak najszybciej je walidować w kontekście zachowań użytkowników.

Jakie pułapki czekają na zespoły, które chcą tworzyć produkty w tak zmiennym otoczeniu oraz przy nieustannej potrzebie weryfikacji założeń i działań?
Po pierwsze to, o czym mówiliśmy powyżej. Firmy zakładają, że wiedzą czego chcą użytkownicy i nie weryfikują tych założeń wystarczająco często. Może być też odwrotnie, gdy zespoły „utykają” na etapie odkrywania, zdobywania wiedzy, testowania, bo wydaje im się, że potrzebują więcej informacji. Nie ma jednak postępów pracy. Kolejny problem to pseudoeksperymenty, które nie odpowiadają na nasze pytania i hipotezy – ich wynik jest oczywisty lub nieistotny statystycznie. Po trzecie – szczególnie w mniejszych firmach – zakłada się często, że właściciel, ktoś z marketingu albo deweloperzy są najlepszymi reprezentantami użytkowników. W efekcie tworzymy produkt według gustu szefa firmy, mimo że wcale niekoniecznie to on najlepiej rozumie potrzeby użytkownika.

Czy w swojej pracy spotkałeś się z sytuacją, w której zamawiany produkt nie zaspokoiłby potrzeb?
Kilka lat temu, w trakcie warsztatu Product Discovery w dużej firmie ubezpieczeniowej odkryliśmy, że istnieje grupa klientów, która tego produktu na pewno nie kupi. Od zespołu deweloperskiego taka konkluzja wymagała zaledwie kilku godzin dyskusji, a pozwoliła zaoszczędzić znaczące sumy, które firma przeznaczyłaby na rozwój funkcjonalności dla tej grupy, czy na kampanię marketingową. W innej firmie odkryliśmy (tworząc persony), że produkt najprawdopodobniej nie znajdzie klientów. W obu przypadkach mogliśmy zmienić kierunek rozwoju produktów. Jak pokazuje doświadczenie – czasem sukcesem nie jest dostarczenie oprogramowania, ale zaoszczędzenie czasu i pieniędzy.

W jaki więc sposób zdefiniować prawdziwe potrzeby użytkowników? Czy kluczem jest empatia?
Warstwa emocjonalna jest niezbędna w badaniu tych potrzeb, nie możemy więc wyłączyć empatii. Bardzo przyda się ona podczas wywiadów z użytkownikami – informacji mogą oni udzielać nie wprost, warto więc umieć czytać takie komunikaty. Sztuka zadawania pytań jest tu niezwykle ważna – nie mogą być one sugestywne, lecz obiektywne, co pozwala identyfikować prawdziwe informacje i oczekiwania. Zamiast tłumaczyć, jakie jest zastosowanie danej aplikacji, prosimy użytkownika, by sam spróbował to ustalić i opisać.

Kiedyś Henry Ford powiedział: „Gdybym na początku swojej kariery jako przedsiębiorcy zapytał klientów, czego chcą, wszyscy byliby zgodni: chcemy szybszych koni. Więc ich nie pytałem”. W Product Discovery nie chodzi o pytanie, jakie funkcjonalności chcą użytkownicy, tylko słuchanie co mówią i obserwowanie czego nie mówią, a także zrozumienie, jaki mają problem i jak go w tym momencie rozwiązują.

Jak odkrywa się produkty w czasie epidemii? Jak dostosowaliście się do nowej rzeczywistości?
Wylądowaliśmy w zupełnie wirtualnym świecie, nie umiejąc efektywne pracować w takim trybie. Dużo łatwiej jest dyskutować i generować pomysły, gdy widzimy wszystkich uczestników, możemy wspólnie pisać na flipchartach, przyklejać karteczki na tablicy. W komunikacji zdalnej tracimy gestykulację, mimikę, a nawet – szepty, czy dyskretne kopnięcia pod stołem.

Z drugiej strony, firmy bardzo szybko uczą się teraz być zwinne – ambitne plany na cały rok wylądowały w koszach. Na szczęście większość organizacji wyrzuciła swoje harmonogramy, reaguje na sytuację i robi to, co jest ważne w tym momencie. A o to przecież w Agile chodzi. Obecna sytuacja to ważny sprawdzian dla zwinności – zarówno w kontekście szybkości podejmowania decyzji, jak i efektywności zespołów. Te firmy, które już wcześniej sprawnie działały w Agile i Scrumie, są w stanie przejść na pracę zdalną bez znacznej straty produktywności.

Odbiegając trochę od PD – jak widzisz przyszłość Agile? Manifest ma już kilkanaście lat, może przyszedł czas na jego aktualizację?
Agile jako koncepcja zwinnego programowania cały czas się rozwija. Manifest powstał w 2001 r. jako podsumowanie dokonań lat 90., a rozwój produktów webowych otworzył przed nami nowe możliwości. Koszty testowania hipotez – czyli Product Discovery – są obecnie dużo niższe niż jeszcze dekadę temu. Oczywiście, zmienia się definicja pojęcia „Agile” – to już nie tylko projekty informatyczne, lecz produkty softwareowe. Zwinność wkroczyła też w inne obszary – marketing, sprzedaż czy HR-y.

To, co będzie bardzo ciekawą rewolucją, to wykorzystanie Agile w produkcji hardware’u (sprzętu) – tam koszty zmiany są wciąż bardzo duże, a procesy osadzone w tradycyjnym podejściu. Zresztą ta zmiana już się powoli dzieje w różnych firmach, również w polskich, ale to temat na osobną rozmowę (uśmiech).