Produkt odpowiada na pytanie użytkownika, nie na wizję twórcy.
Twórca definiuje 'problem' na swoim poziomie abstrakcji. Użytkownik myśli pytaniami - konkretnymi, osadzonymi w bólu. Produkt zbudowany wokół pytania użytkownika ma naturalny filtr. Produkt zbudowany wokół wizji twórcy - nie.
Każdy produkt zaczyna się od zdania “rozwiązujemy problem X”. Problem brzmi poważnie. Problem brzmi jak coś, na co warto wydać pieniądze. Problem jest w pitch decku, w PRD, w pierwszym slajdzie dla inwestora.
Tylko że użytkownik NIE myśli w kategoriach problemów.
Użytkownik myśli pytaniami. “Gdzie to zapisać, żeby nie zgubić?” “Dlaczego to trwa tak długo?” “Da się to zrobić prościej?” Pytanie jest konkretne, osadzone w kontekście i - co najważniejsze - sformułowane w języku osoby, która go doświadcza. Nie w języku osoby, która planuje na nim zarobić.
”Problem” to abstrakcja twórcy
“Rozwiązujemy problem zarządzania X” - to zdanie z perspektywy twórcy. Żaden użytkownik nie budzi się rano z myślą “mam problem z zarządzaniem”. Budzi się z myślą “znowu nie wiem, gdzie jest ten mail” albo “ile ja właściwie mam na to czasu”.
Twórca operuje na wyższym poziomie abstrakcji niż użytkownik. Agreguje pojedyncze bóle w kategorię, nazywa ją “problemem” i buduje pod nią rozwiązanie. To nie jest złe. Źle jest, gdy ta abstrakcja zastępuje kontakt z rzeczywistym doświadczeniem użytkownika.
“Problem” zdefiniowany przez twórcę ma nieprzyjemną właściwość: jest pojemny. Mieści w sobie dziesiątki funkcji, bo każda z nich “pasuje do problemu”. A skoro pasuje - to pewnie jest potrzebna.
Konkretne pytanie vs pojemna wizja
Twórca mówi: “system do zarządzania”. Użytkownik pyta: “gdzie to trzymać, żeby nic nie zgubić?”
To nie jest ta sama potrzeba ujęta inaczej. To fundamentalnie inne pytanie prowadzące do fundamentalnie innego produktu. Pierwsze pytanie generuje architekturę z modułami, dashboardami, rolami i uprawnieniami. Drugie generuje listę z wyszukiwarką.
Pytanie użytkownika jest filtrem. Definiuje co produkt musi robić - bo jeśli nie odpowiada na to pytanie, nie ma po co istnieć. Wizja twórcy definiuje co produkt może robić - a “może” nie ma naturalnej granicy.
Produkt zbudowany wokół pytania użytkownika jest z natury ograniczony. Produkt zbudowany wokół wizji twórcy jest z natury rozszerzalny. Jedno z tych podejść prowadzi do dyscypliny. Drugie do katalogu funkcji, z którego nikt nie korzysta.
Produkt, który odpowiada na własne pytanie
Gdy twórca sam formułuje pytanie i sam na nie odpowiada, znika mechanizm kontrolny. Nie ma weryfikacji, czy pytanie jest realne. Nie ma weryfikacji, czy odpowiedź jest trafna. Jest przekonanie i zapał.
To nie musi być błąd. Wielu udanych produktów zaczęło się od intuicji twórcy. Ale intuicja, która nie została skonfrontowana z pytaniem użytkownika, ma tendencję do rozrastania się. Każda kolejna funkcja wydaje się logiczna, bo wynika z wewnętrznej spójności wizji - nie z zewnętrznej potrzeby.
W notatce o granicy MVP drift wynikał z braku pytania. Tu jest odwrotnie - pytanie istnieje, ale zadał je twórca sam sobie. Efekt ten sam: zakres rośnie, bo brakuje zewnętrznego kryterium “czy to jest potrzebne”.
Złożoność nie bierze się z trudności problemu. Bierze się z odpowiadania na pytanie, którego nikt nie zadał.
Czego pytanie użytkownika nie powie
“Gdybym zapytał ludzi, czego chcą, powiedzieliby: szybszego konia.”
Cytat przypisywany Fordowi. Prawdopodobnie nigdy go nie powiedział - ale to nieistotne, bo powtarzany jest jako dowód na to, że użytkowników nie warto słuchać. A mówi coś zupełnie innego.
Ludzie nie powiedzieli “chcę silnik spalinowy”. Powiedzieli “chcę dotrzeć szybciej”. To jest prawdziwe pytanie. Ford - czy ktokolwiek, kto to wymyślił - nie zignorował pytania. Zignorował proponowane rozwiązanie. Pytanie użytkownika definiuje ból. Rozwiązanie to już robota twórcy.
Są dwie warstwy:
- Co boli - zna użytkownik. “Chcę dotrzeć szybciej”, “gubię maile”, “nie wiem ile mam czasu”.
- Jak to rozwiązać - robota twórcy. Silnik spalinowy, lista z wyszukiwarką, kalendarz z alertami.
Katastrofa zaczyna się wtedy, gdy twórca przeskakuje obie - sam definiuje ból, sam projektuje rozwiązanie, cały cykl zamknięty wewnątrz jednej głowy. Zero zewnętrznego tarcia. Zero weryfikacji.
Produkt nie musi robić tego, o co użytkownik prosi. Musi robić to, co wynika z jego pytania. To często coś zupełnie innego - i właśnie dlatego pytanie jest cenniejsze niż prośba.
Pytanie, które zostaje
Jak sprawdzić, czy pytanie które stoi za produktem pochodzi od użytkownika, a nie od wyobraźni twórcy? I co zrobić, gdy użytkownik doświadcza bólu, ale nie potrafi sformułować pytania?
W newsletterze rozwijam tego rodzaju tematy głębiej. Zapisz się.