Odcinek 90. Kto by słuchał użytkownika w czasach AI? User Needs Mapping
W dzisiejszych czasach każdy czuje się „productowcem”. Deweloperzy, wspierani przez AI, potrafią dowozić funkcjonalności w tempie, o jakim nam się nie śniło. Product Managerowie, dzięki „vibe-codingowi”, sami tworzą prototypy i wrzucają je na produkcję. Na LinkedInie huczy od postów o nowych funkcjach, ale w tym całym pędzie łatwo zapomnieć o najważniejszym pytaniu: Dla kogo my to właściwie robimy?
Kto by słuchał użytkownika w czasach AI?
W najnowszym odcinku podcastu mpoim gościem jest Rich Allen, autor koncepcji User Needs Mapping. Rozmawiamy o tym, dlaczego w dobie sztucznej inteligencji zrozumienie realnych potrzeb człowieka jest ważniejsze niż kiedykolwiek i jak nie wpaść w pułapkę budowania „szybszych koni”.
Pułapka „szybszych koni” i ewolucja potrzeb
Rich przypomina słynny (choć prawdopodobnie legendarny) cytat Henry’ego Forda: „Gdybym pytał użytkowników, czego chcą, powiedzieliby, że szybszych koni”. To idealna metafora problemu, z którym mierzymy się dziś. Użytkownicy często definiują swoje „chcenia” przez pryzmat obecnych ograniczeń.
Innowacja nie polega na daniu im tego, o co proszą (szybszego konia), ale na zrozumieniu ich ukrytej potrzeby (szybkiego i czystego przemieszczenia się z punktu A do punktu B). W erze AI, gdzie technologia zmienia się z dnia na dzień, mapowanie potrzeb pozwala nam zakotwiczyć się w tym, co stałe – w ludzkich problemach, które AI ma jedynie pomóc rozwiązać.
Metafora słonia, czyli jak nie zgubić systemu
Często w organizacjach zespoły działają jak niewidomi z przypowieści o słoniu: jeden trzyma za trąbę i myśli, że słoń to wąż, inny trzyma za nogę i twierdzi, że to drzewo. Zespół backendowy widzi bazę danych, frontendowy widzi interfejs, a użytkownik… po prostu chce załatwić swoją sprawę.
User Needs Mapping to technika, która wywodzi się z mapowania Wardleya, ale upraszcza je, by skupić się na perspektywie „outside-in”. Pozwala ona zdjąć klapki z oczu i zobaczyć cały system przez pryzmat wartości dla klienta, a nie tylko struktury organizacyjnej.
Jak zacząć mapowanie potrzeb użytkownika? (Kluczowe kroki)
Rich Allen sugeruje, aby proces mapowania nie był jednorazowym ćwiczeniem, ale żywym dialogiem w zespole. Oto jak możecie to ugryźć:
- Zidentyfikuj Użytkownika: To brzmi banalnie, ale spróbujcie odpowiedzieć na to pytanie w zespole platformowym. Kto jest Waszym klientem? Deweloper z innego działu? Administrator? Doprecyzowanie roli to podstawa.
- Rozróżnij „Chcenia” od „Potrzeb”: * Wants (Chcenia): Powierzchniowe życzenia (np. „chcę aplikację mobilną”).
- Expected Needs (Potrzeby oczekiwane): Rzeczy oczywiste, jak bezpieczeństwo czy stabilność.
- Jobs to be Done (JTBD): Jaki postęp próbuje wykonać użytkownik? Co chce osiągnąć?.
- Zmapuj Możliwości (Capabilities): Co Wasza organizacja musi potrafić zrobić (procesy, ludzie, umiejętności), aby zaspokoić te potrzeby?.
- Nałóż na to Zespoły (Team Topologies): Sprawdź, czy granice Twoich zespołów odpowiadają potrzebom użytkownika. Czy jeden zespół musi „przełączać kontekst” między pięcioma różnymi typami użytkowników? Jeśli tak, to tu leży źródło Twojej nieefektywności.
- Weryfikuj przez „Łańcuch Wpływu”: Potrzeba kształtuje pracę, praca ujawnia potrzebne umiejętności, a te determinują obciążenie poznawcze zespołu (Cognitive Load). Jeśli słoń jest za duży, zespół go nie udźwignie.
Podsumowanie
Zamiast kłócić się o priorytety w backlogu, stańcie przed mapą. Gdy dyskusja przenosi się z „mojej opinii” na „węzeł na mapie potrzeb”, emocje opadają, a pojawia się zrozumienie. W czasach, gdy AI może wygenerować kod w sekundy, to my musimy być strażnikami sensu tego, co powstaje.
Chcesz dowiedzieć się więcej? Więcej materiałów, szablonów do Miro oraz link do książki Richa znajdziesz na stronie userneedsmapping.com.
A Ty? Kiedy ostatnio zapytał_ś swój zespół, jaką potrzebę użytkownika rozwiązuje ten konkretny commit?