Trzy pytania, które warto zadać, zanim zacznie się projekt produktowy

Po roku pracy, kilkuset godzinach warsztatów, dziesiątkach iteracji i sporym budżecie ktoś w końcu pyta: ale czy to w ogóle był właściwy projekt? To pytanie dotyczy czegoś głębokiego: czy cały wysiłek był skierowany we właściwym kierunku.

Przez ponad 20 lat obserwuję organizacje. Widzę projekty, które technicznie są zrealizowane bez zarzutu – dostarczają na czas, mieszczą się w budżecie, spełniają przyjęty scope. I nie rozwiązują problemu, dla którego zostały uruchomione. Jakość wykonania rzadko jest tu winna. Przed startem po prostu nie padły trzy kluczowe pytania.

Problem pojawia się przed projektem

Organizacje poważnie inwestują w kompetencje: metody badawcze, design thinking, product management, narzędzia do zarządzania sprintem. To wszystko ma sens. Ale narzędzia i metodyki działają dopiero wtedy, kiedy wiemy, co próbujemy osiągnąć. Moja obserwacja z lat prowadzenia szkoleń UX-PM: gdy pytam uczestników o definicję sukcesu ich projektu, odpowiedź najczęściej dotyczy zakresu, nie efektu. „Wdrożymy nową aplikację”, „przeprojektujemy ścieżkę zakupową”, „zmienimy onboarding”. To opisy tego, co zostanie zbudowane, a nie tego, dlaczego i po co. Trudno mi uwierzyć, żeby większość nieudanych projektów IT była efektem złego wykonania. Myślę, że znaczna część z nich była po prostu źle zdefiniowana na starcie.

Dlatego trzy pytania, które opisuję poniżej, stawiam – w różnych formach – przed każdym projektem, którego tematem mam przyjemność się zajmować. Dotyczą produktów cyfrowych, ale równie dobrze sprawdzają się w transformacji Customer Experience (CX), projektach Employee Experience czy wdrożeniu AI w organizacji.

Pytanie pierwsze: jaki problem naprawdę chcemy rozwiązać?

Właściwe pytanie zaczyna się od problemu. Organizacje bardzo sprawnie definiują projekty przez pryzmat rozwiązania. „Potrzebujemy nowej aplikacji”, „trzeba przeprojektować panel klienta”, „chcemy wdrożyć chatbota”. Rozwiązanie jest konkretne, daje poczucie kontroli, łatwo je wycenić i zaplanować. Problem jest trudniejszy. Wymaga cofnięcia się o krok i zadania pytania: co tak naprawdę nie działa i dlaczego? Różnica jest ogromna. Jeśli klienci nie wracają po pierwszym zakupie, można zaprojektować lepszy ekran potwierdzenia zamówienia. Albo można zapytać, dlaczego w ogóle nie wracają – i odkryć, że problem leży nie w interfejsie, ale w doświadczeniu dostawy, komunikacji posprzedażowej lub cenie. Lepszy ekran niczego tu nie zmieni.

Symptom i przyczyna wyglądają z pozoru podobnie – oba opisują coś, co nie gra. Różnią się tym, że interwencja na poziomie symptomu daje efekty tymczasowe lub żadne. Interwencja na poziomie przyczyny zmienia sytuację trwale. To pytanie bywa niekomfortowe, bo często okazuje się, że „projekt produktowy” powinien być „projektem procesowym” albo „projektem organizacyjnym”. Zdefiniowanie właściwego problemu czasem zmienia zakres, a nawet charakter całego przedsięwzięcia. Ale to lepiej wiedzieć przed startem niż po roku pracy.

Pytanie drugie: kto jest właścicielem tej decyzji?

To pytanie o decydentkę lub decydenta. Pytanie, które organizacje konsekwentnie omijają. Projektom towarzyszą interesariusze (stakeholderzy), komitety sterujące, właściciele procesów. Ale właściciel decyzji – ta jedna osoba, która mówi „tak, robimy to” lub „nie, zmieniamy kierunek” – często nie jest jasno określona. Efekt jest przewidywalny. Projekt wraca do punktu wyjścia po każdej zmianie składu komisji albo po tym, jak ktoś wyżej w hierarchii zrewiduje wcześniejsze ustalenia. Każdy „komentarz z zewnątrz” może otworzyć już zamknięty temat – i każde spotkanie stakeholderów może zakwestionować poprzednie wyniki.

Widzę projekty, które przechodziły przez ten cykl kilkakrotnie – wyniki były poprawne, ale nikt nie miał jasnego mandatu do powiedzenia „wystarczy, idziemy dalej”. Brak właściciela decyzji to projekt, który można zatrzymać na każdym etapie przez każdego, kto ma odpowiednio głośny głos. Dobre projekty mają jednego właściciela decyzji – niekoniecznie najwyżej postawioną osobę, ale tę, która ma mandat i odwagę do zamknięcia tematu. Chodzi o klarowność odpowiedzialności, a pozycja w hierarchii jest tu sprawą drugorzędną.

Pytanie trzecie: jak będziemy wiedzieć, że nam wyszło?

To pytanie o zmianę, którą projekt ma wywołać. Kiedy na szkoleniu UX-PM pytamy uczestników o to trzecie pytanie, większość z nich milknie. W ich organizacjach tego pytania po prostu się nie zadaje. Sukces projektu mierzy się oddaniem deliverables, a nie zmianą, którą te deliverables miały wywołać. To przekłada się na dwa problemy. Pierwszy: projekt nigdy się nie kończy, bo zawsze można dodać kolejną funkcję, poprawić kolejny element, przeprowadzić jeszcze jedną rundę warsztatów. Drugi: po zamknięciu projektu nikt nie wraca, żeby sprawdzić, czy problem, który miał zostać rozwiązany, faktycznie został rozwiązany.

Definiowanie sukcesu przed projektem oznacza konkretność: co się zmieni, kto to zmierzy, w jakim horyzoncie czasowym. Retencja klientów po pierwszym zakupie wzrośnie o X punktów procentowych w ciągu sześciu miesięcy. Czas obsługi zgłoszenia spadnie poniżej Y minut. Wynik badania satysfakcji pracowników wzrośnie o Z punktów. Takie metryki nie są wygodne. Eksponują projekt na weryfikację. Ale właśnie dlatego są wartościowe: zmuszają do precyzji na etapie, kiedy można jeszcze coś zmienić, a nie po tym, jak środki zostały wydane.

Dlaczego te pytania są trudne, choć wydają się łatwe

Mogłoby się wydawać, że trzy pytania brzmią prosto. W praktyce każde z nich wymaga czegoś, co organizacje traktują jako zagrożenie: odsłonięcia niepewności, redefinicji zakresu, przyznania, że poprzednie założenie było błędne, albo nazwania wprost, kto za co odpowiada. To napięcie jest realne. Ale jest też dowodem na to, że pytania są właściwe. Pytania, które nie budzą oporu, zazwyczaj dotyczą spraw już rozstrzygniętych. Pytania trudne dotykają tego, co naprawdę decyduje o sukcesie projektu. Te trzy pytania sprawdzają się niezależnie od kontekstu: projekt produktowy, transformacja Customer Experience, zmiana kultury organizacyjnej, wdrożenie AI. Wszędzie mechanizm jest ten sam – inwestujemy zasoby w rozwiązanie zanim upewnimy się, że rozumiemy problem.

Zadawanie pytań to kompetencja, którą można rozwijać

Zadawanie właściwych pytań przed projektem to umiejętność. Wymaga świadomości wagi tych pytań, narzędzi do ich przeprowadzenia i odwagi, by podjąć je w organizacji nastawionej na działanie. W ramach programu UX-PM pracujemy z ludźmi nad tą konkretną kompetencją – nie jako abstrakcyjną filozofią, ale jako praktyką prowadzenia rozmów o definicji problemu, odpowiedzialności za decyzje i miarach sukcesu. Uczestnicy wychodzą z narzędziami, ale też z językiem, który pozwala im zadawać te pytania w swoich organizacjach. Czasem to ważniejsze niż metodologia. Metod projektowych jest wiele i większość z nich działa. Warunkiem jest jednak zrozumienie, do czego mają doprowadzić. Trzy pytania, o których piszę, są tym warunkiem wstępnym. Postawione przed projektem, mogą go uratować. Postawione po – co najwyżej dokumentują, dlaczego się nie udał.