10 obowiązkowych pytań każdego Product Managera

Dobrze sformułowane pytania podczas rozmowy z użytkownikami czy interesariuszami to must-have każdego Product Managera. Zadawanie właściwych pytań wcale nie jest tak proste, jak mogłoby się wydawać. Jak zapewne się domyślasz, różne osoby wymagają różnego podejścia. W dodatku, ilu interesariuszy, tyle problemów. Istnieją jednak pytania, które nagminnie powtarzam podczas tworzenia produktowych rozwiązań. Przedstawiam Ci listę dziesięciu, które sprawdzają się u mnie praktycznie zawsze.

Dlaczego? / Why?

Nieważne czy jesteś ekspertem w tworzeniu produktów czy dopiero rozpoczynasz swoją karierę. Jest to pytanie, które koniecznie powinno znaleźć się w Twoim arsenale. Pytanie, które towarzyszy na każdym kroku. Jeżeli próbujesz podjąć jakąkolwiek decyzję, czy przeprowadzić kolejny eksperyment, ale nie jesteś w stanie odpowiedzieć „dlaczego”, nie rób tego. Wróć do początku i zadaj to pytanie. Użytkownicy/Interesariusze bardzo rzadko opowiadają o swoich problemach. W większości przypadków skupiają się na rozwiązaniach. Czasami proste „dlaczego” wystarczy, aby stwierdzić, że tak naprawdę dana propozycja rozwiązania nie jest słuszna. Rozejrzyj się dookoła. Jestem pewien, że przez większość czasu słyszysz: „potrzebujemy X, potrzebujemy Y, potrzebujemy…”, ale dlaczego? Równie rzadko zdarza się, aby pierwsza odpowiedź na to pytanie była wystarczająca. Jest to jednak dobry start, aby wyodrębnić bardziej szczegółowe hipotezy i dotrzeć do źródła problemu.

Słyszałeś o Five Whys?

Jak to robisz dzisiaj?

Tego pytania nie powinno zabraknąć niezależnie od cyklu życia produktu. Nieważne czy masz ekscytujący pomysł na nową aplikację, czy użytkownik prosi o określoną funkcję w dojrzałym produkcie. Dowiedz się najpierw, w jaki sposób problemy użytkowników rozwiązywane (o ile) są dzisiaj. To pytanie jest również pomocne podczas tworzenia roadmapy, priorytetyzacji zadań czy chociażby próby usprawnienia UX w produkcie.

Czy możesz podać mi przykład?

Mogłoby się wydawać, iż pytanie samo w sobie nie jest wartościowe. Wręcz przeciwnie. W wielu przypadkach, opowiadanie danej sytuacji posługując się konkretnymi przykładami powoduje lepsze i często szybsze zrozumienie problemu. Pytanie to zadaję często nawet w przypadku, gdy jestem pewien, że już dobrze rozumiem drugą stronę.

A Ty? Jak uważasz?

Umiejętność słuchania jest niezwykle ważna. Jako PO/PM jesteś odpowiedzialny za podejmowanie ostatecznych decyzji (o ile nie jesteś Proxy PM). Nie oznacza to jednak, że nie powinieneś pytać interesariuszy czy użytkowników o zdanie. W wielu przypadkach może okazać się, że ktoś ma lepszy pomysł od Ciebie na rozwiązanie danego problemu. Oczywiście, nie powinieneś unikać brania odpowiedzialności za podjęte decyzje, nawet jeżeli idea nie wyszła od Ciebie. 

Czasami możesz posłużyć się tym pytaniem, jeżeli ktoś oczekuje od Ciebie natychmiastowej odpowiedzi na kluczowe i trudne pytanie, a Ty nie jesteś jeszcze zdecydowany. Kupisz w ten sposób sobie czas, przeanalizujesz inną opinię i być może łatwiej Ci będzie wyrazić swoje zdanie.

Jak Twoja praca/zadanie by wyglądała/o gdybyś to miał?

Generalnie używam odmiany tego pytania w zależności od okoliczności, ale cel jest ten sam: zrozumienie w jaki sposób funkcja czy idea rozwiązuje problem i jaką wartość stanowi dla użytkownika. Jeżeli priorytetyzujesz swój rejestr produktu w oparciu o np. „Model Kano”, to pytanie może Ci pomóc również w przyporządkowaniu funkcji do jednej z czterech kategorii.

Skąd wiesz, że miałeś udany (rok, miesiąc, dzień)?

Pytanie, które towarzyszy mi zawsze podczas rozwijania produktu dla klienta biznesowego. Przez ostatnie lata miałem okazję obserwować rozwój wielu produktów. Niemal w każdym występował ten sam problem: kompletny chaos w przypadku strategii lub wskaźników. Pytanie to jednak zazwyczaj pomaga w odkryciu kilku istotnych statystyk czy celów klienta. Z kolei te ostatnie są bardzo istotne, jeżeli chcemy, aby tworzone rozwiązanie rzeczywiście było wartościowe.

Jeżeli mógłbyś zmienić jedną rzecz w produkcie, co by to było?

Pytanie poniekąd jest równoznaczne z: „Co najmniej lubisz w naszym rozwiązaniu?” czy „Co najbardziej Cię frustruje?”. Niemniej jednak, jest to bardzo dobre otwarte pytanie, aby rozpocząć dyskusję i odkryć ból interesariuszy/użytkowników.

Jaki Twój problem rozwiązuje nasz produkt?

Musisz być świadomy nie tylko słabych stron Twojego produktu, ale również i tych mocnych (o ile są). To, w co Ty wierzysz, niekoniecznie może okazać się tym, w co wierzą Twoi interesariusze. Potwierdzaj wszystkie postawione hipotezy. Dowiedz się, jakie główne problemy rozwiązuje Twój produkt u użytkowników (nawet, jeżeli wydaje Ci się, że wiesz). Odpowiedz na pytanie, dlaczego użytkownicy tak naprawdę wybrali Twoje rozwiązanie i dlaczego je „kochają”. 

W jednym z produktów, który miałem okazję współtworzyć, zaobserwowaliśmy, że klienci wcale nie kupowali naszej usługi ze względu na to, co nam się wydawało istotne, a zupełnie z innych powodów. Taka informacja jest bardzo cenna.

Co konkurencja robi lepiej od nas?

Bądź świadomy mocnych stron u konkurencji i różnic pomiędzy Twoim produktem, a konkurencyjnym. Nie oznacza to oczywiście, że powinieneś implementować wszystkie funkcje, które posiada konkurencja. Musisz jednak zadawać to pytanie głośno, aby dowiedzieć się dlaczego użytkownicy rezygnują z wyboru Twojego produktu, a sięgają po inny.

Dlaczego poleciłbyś nasze rozwiązanie innym?

Pytanie to można zadać w wielu wariantach. O ile z powyższym przykładem powinieneś być ostrożny (musisz być pewien, że nie otrzymasz odpowiedzi w stylu:(„Nikt nie powiedział, że poleciłbym Wasze rozwiązanie komukolwiek”), o tyle odpowiedź może zawierać wiele cennych informacji. Nie tylko jest to dobra droga, aby poznać zadowolenie czy lojalność klienta wobec produktu, ale możesz dowiedzieć się o mocnych stronach tworzonego rozwiązania. Ktoś mądry kiedyś powiedział: „Not why you think you’re different. Why your customers believe you’re different.”. Pamiętaj, aby pytania nie zadawać na samym początku drogi użytkownika z produktem, a np. dopiero po 20 logowaniach do aplikacji. Innym wariantem jest: „Dlaczego nie poleciłbyś naszego rozwiązania innym?”.

Podsumowanie

Nie istnieje jeden zestaw pytań, który będzie właściwy dla każdego produktu i sytuacji. W zależności od problemu, będziesz potrzebował użyć innych wariantów. Niektóre pytania jak np. „dlaczego?” są zazwyczaj tylko wstępem. Aby być dobrym Product Managerem, musisz efektywnie „czytać” pomiędzy wierszami, a następnie zadawać coraz to bardziej szczegółowe pytania, dopóki nie uzyskasz satysfakcjonującej odpowiedzi. Niewątpliwie, dobrze zadane pytania mogą wywrócić Twój produktowy harmonogram do góry nogami. Powodzenia!