Zanim zaczniesz budować produkt, sprawdź, czy problem naprawdę istnieje. W tym odcinku Daniel C. Dul opowiada, jak zrozumiał ból rekruterów i z tego wyciągnął pomysł na narzędzie, które ma sens w codziennej pracy.
Posłuchaj odcinka DSS#1 na YouTube →Artykuły na blogu „Drugiej Strony Sukcesu” nie biorą się z teorii oderwanej od życia. Powstają z rozmów, w których padają konkretne decyzje, błędy, wnioski i liczby. Ten tekst jest właśnie taki: wyrasta z odcinka z Danielem C. Dułem, ale idzie o krok dalej i pokazuje, jak przejść od „mam pomysł” do „wiem, że rozwiązuję realny problem biznesowy”.
To ważne, bo większość produktów nie upada dlatego, że były źle zaprojektowane. Upadają dlatego, że ktoś za wcześnie zakochał się w rozwiązaniu, a za późno zadał sobie pytanie: czy ten problem jest na tyle bolesny, częsty i kosztowny, żeby ktoś chciał za niego płacić? W rozmowie z podcastu właśnie do tego wracaliśmy wielokrotnie. I tu jest najciekawsze: Daniel nie mówił o badaniu problemu jak o akademickiej metodzie. Mówił o nim jak o codziennej praktyce człowieka, który widzi rynek od środka i umie wyłapywać tarcie tam, gdzie inni widzą tylko „proces”.
Nie zaczynaj od produktu. Zaczynaj od tarcia w pracy ludzi
Daniel zbudował swój produkt reo nie dlatego, że chciał „zrobić coś z AI” albo „wejść w rekrutację”. Punktem wyjścia było to, co sam widział jako aktywny rekruter i product designer: za dużo przełączania się między narzędziami, za dużo notatek, za dużo ręcznej pracy i za mało kontroli nad całym procesem. To nie był problem wyobrażony. To była codzienna frustracja wynikająca z konkretnego workflow.
To jest pierwszy praktyczny wniosek dla przedsiębiorcy: jeśli chcesz znaleźć realny problem biznesowy, nie pytaj najpierw „jaką funkcję da się zbudować?”, tylko „gdzie ludzie tracą czas, energię albo pewność decyzji?”. W rozmowie padł bardzo ważny motyw: rekruter pracuje na wielu artefaktach jednocześnie — CV, job description, LinkedIn, notatki, wideorozmowa, raport dla klienta. Jeżeli jedno spotkanie wymaga lawirowania między kartami, ekranami i aplikacjami, to sam ból pojawia się naturalnie. Nie trzeba go wymyślać.
W praktyce warto szukać takich sygnałów:
- ludzie robią coś ręcznie, choć robią to często;
- przełączają się między wieloma narzędziami, żeby wykonać jedną prostą czynność;
- boją się, że o czymś zapomną albo coś pomieszają;
- muszą przygotowywać te same informacje w różnych formatach;
- narzekają na brak kontroli, a nie tylko na „wolność wyboru”.
To właśnie są dobre tropy. Nie „wow, można tu użyć technologii”, tylko „tu codziennie znika czas i jakość”.
Badanie problemu biznesowego polega na rozumieniu kontekstu, nie na zbieraniu ładnych deklaracji
W odcinku mocno wybrzmiało, że design i produkt to nie sztuka dla sztuki. Daniel powiedział wprost: biznes nie istnieje w próżni, a rolą product designera i founder’a jest zrozumieć nie tylko użytkownika, ale też model biznesowy, technologię i ograniczenia organizacji. To samo dotyczy badania problemu. Nie wystarczy usłyszeć: „tak, to byłoby fajne”. Trzeba zrozumieć, dlaczego byłoby fajne, kiedy byłoby używane i co dziś blokuje ludzi.
To ważne szczególnie w B2B. Tam problem nie jest zwykle pojedynczym „bolesnym” momentem. To raczej suma małych tarć, które robią się kosztowne: każdy dodatkowy klik, każda minuta przełączania, każde spotkanie, po którym trzeba jeszcze raz ręcznie spisać raport. Daniel bardzo dobrze opisał rekrutera jako „procesor informacji”: najpierw zbiera dane, potem je porządkuje, potem przekazuje dalej. Jeśli jedno ogniwo w tym łańcuchu jest słabe, cały proces zwalnia.
Dlatego w badaniu problemu warto pytać nie tylko o to, co ludzie robią, ale też:
- co muszą robić, choć tego nie lubią;
- co robią pod presją czasu;
- co odkładają, bo jest za żmudne;
- co powoduje błędy, wstyd albo napięcie w zespole;
- co muszą powtarzać, bo system nie pomaga.
Jeśli w odpowiedziach pojawia się chaos, ręczne obejścia i brak poczucia kontroli, to często masz już bardzo dobry materiał do walidacji problemu. Nie rozwiązania. Problemów.
Najlepszy sygnał, że problem jest prawdziwy? Ludzie już próbują go obejść
W rozmowie Daniel opowiadał o tym, że rekruterzy często pracują w jednym oknie na laptopie, z wieloma otwartymi zakładkami, a każde spotkanie oznacza przeciąganie uwagi między narzędziami. To nie jest sytuacja, w której użytkownik spokojnie „myśli nad ulepszeniem procesu”. To jest sytuacja, w której już dziś improwizuje. I właśnie takie miejsca są najciekawsze dla badania problemu biznesowego.
Dlaczego? Bo jeśli ludzie już kombinują, to znaczy, że potrzeba jest realna. Wtedy twoim zadaniem nie jest ich „przekonać do problemu”, tylko sprawdzić, czy twoje rozwiązanie faktycznie upraszcza życie bardziej niż obecne patche. Daniel zauważył, że część rekruterów radzi sobie lepiej, inni gorzej, ale wszyscy funkcjonują w tych samych ograniczeniach. To oznacza, że na rynku istnieje problem, tylko nie każdy ma go nazwany.
W praktyce szukaj takich sygnałów:
- użytkownik ma własny system notatek, folderów albo skrótów;
- łączy kilka narzędzi, bo jedno nie wystarcza;
- robi „obejście”, które zajmuje mu czas, ale uważa je za normalne;
- nie ufa obecnemu procesowi na tyle, by oddać mu pełną odpowiedzialność;
- sam mówi: „to powinno być prostsze”.
To ostatnie zdanie bywa jednym z najcenniejszych sygnałów. Nie dlatego, że jest efektowne, tylko dlatego, że pokazuje frustrację bez filtrów.
Walidacja problemu to nie ankieta. To rozmowa o kosztach, ryzyku i konsekwencjach
Daniel kilka razy wracał do tego, że na etapie walidacji nie wystarczy mówić o „zainteresowaniu”. Interesujące są dopiero konkretne sygnały: feedback od rekruterów, gotowość do użycia narzędzia, a finalnie także gotowość do płacenia. I tu jest ważna rzecz dla każdego przedsiębiorcy: badanie problemu kończy się dopiero wtedy, gdy rozumiesz, ile ten problem kosztuje.
Bo jeśli ktoś mówi, że coś jest uciążliwe, to jeszcze nie znaczy, że jest to problem biznesowy. Problem biznesowy zaczyna się wtedy, gdy uciążliwość przekłada się na realną stratę: czasu, pieniędzy, jakości decyzji, spokoju głowy albo wyniku całego procesu. W rekrutacji może to być spóźniony raport, pomylone zlecenie, niedopasowany kandydat albo godziny stracone na szukanie informacji w kilku miejscach.
Dlatego podczas rozmów walidacyjnych pytaj o:
- jak często problem występuje;
- ile czasu zajmuje dziś jego obejście;
- co się dzieje, jeśli ktoś go nie rozwiąże;
- jakie są konsekwencje błędu;
- co już było testowane i dlaczego nie zadziałało;
- czy problem dotyczy jednej osoby, czy całego procesu.
To właśnie daje ci wiedzę, czy masz przed sobą błahą niedogodność, czy coś, co może być podstawą produktu. I tu w odcinku pada też bardzo praktyczna myśl: nie chodzi o doskonałość rozwiązania na starcie, tylko o to, by dowieźć realną wartość. O tym Daniel mówił wprost, kiedy opisywał etap budowy reo i feedback z rynku. Więcej takich przykładów i sposób, w jaki przechodzą od rozmów do produktu, rozwinięty jest właśnie w odcinku.
Jeśli chcesz zobaczyć, jak wygląda badanie problemu od środka, posłuchaj fragmentów o tym, jak Daniel wyłapał tarcie w pracy rekrutera. To dobry przykład, jak z codziennej frustracji zrobić sensowny kierunek produktu.
Posłuchaj odcinka DSS#1 na YouTube →Nie buduj wszystkiego naraz. Najpierw sprawdź, czy użytkownik rozumie wartość w minutę
Jednym z ciekawszych wątków rozmowy była prostota wdrożenia reo. Daniel podkreślał, że użytkownik po wejściu do narzędzia ma bardzo szybko wiedzieć, co robić, a sama obsługa ma zająć chwilę. To niby detal produktowy, ale dla badania problemu ma ogromne znaczenie. Jeśli ktoś nie potrafi wejść w twój produkt bez instrukcji, to często znak, że jeszcze nie trafiłeś w sedno problemu albo zbyt wcześnie komplikujesz rozwiązanie.
Na etapie weryfikacji problemu testujesz nie tylko to, czy problem istnieje, ale też czy użytkownik natychmiast rozpoznaje w twojej propozycji swoją codzienność. Daniel zrobił to bardzo konkretnie: zamiast abstrakcyjnie opowiadać o „narzędziu dla rekruterów”, wsadzał rozmówcę w rolę rekrutera i pokazywał workflow. To świetna praktyka. Ludzie dużo lepiej reagują na sytuację, którą znają z własnej pracy, niż na opis funkcji.
Jeśli budujesz produkt i chcesz sprawdzić problem, zrób trzy rzeczy:
- pokazuj scenariusz, nie listę feature’ów;
- obserwuj, czy użytkownik sam mówi: „tak, dokładnie tak mam”;
- sprawdzaj, czy po minucie rozumie, co narzędzie ma mu dać.
To proste, ale bardzo skuteczne. Jeśli wartość trzeba tłumaczyć długo, to zwykle znaczy, że problem nie został jeszcze dobrze nazwany.
Najpierw problem, potem kanał, potem skala. Inaczej zrobisz ładny ruch bez rynku
Daniel bardzo uczciwie opisał też etap, na którym jest reo: walidacja już się wydarzyła, ale teraz chodzi o budowę i dalszy feedback. Do tego dochodzi temat finansowania, skali, inwestorów i tego, że zespół pracuje nad produktem po godzinach. To ważna lekcja dla przedsiębiorcy: nawet gdy problem jest realny, rynek nie zwalnia cię z odpowiedzi na pytanie kiedy i jak to dowieziesz.
W badaniu problemu łatwo wpaść w pułapkę myślenia: „skoro ludzie mówią, że chcą, to już jest sukces”. Nie do końca. Potrzebujesz jeszcze zrozumieć, czy problem ma dla nich na tyle wysoką wagę, by poświęcili czas na test, a później pieniądze na subskrypcję. Daniel mówił wprost, że finalnym miernikiem jest moment, w którym użytkownik faktycznie wyciąga co miesiąc określoną kwotę, bo widzi wartość. To już jest prawdziwy sygnał rynku.
Dlatego warto pamiętać o prostym porządku:
- problem — co dokładnie boli;
- walidacja — czy ludzie to potwierdzają w rozmowach i działaniach;
- prototyp / MVP — czy rozwiązanie naprawdę pomaga;
- płatność — czy wartość jest na tyle wyraźna, że ludzie chcą za nią płacić;
- skalowanie — dopiero później.
Odwrócenie tej kolejności kosztuje najwięcej. I właśnie tego typu błędów w startupach jest najwięcej: buduje się za wcześnie, za szeroko albo za „technologicznie”, zamiast najpierw upewnić się, że problem jest wart rozwiązania.
Podsumowanie: realny problem biznesowy poznasz po tym, że ludzie już dziś płacą za jego obejścia
Najważniejsza rzecz, jaką można wziąć z tej rozmowy, jest bardzo praktyczna: dobry pomysł na produkt nie zaczyna się od inspiracji, tylko od obserwacji tarcia. Daniel C. Dul nie wpadł na reo dlatego, że szukał modnego rynku. Widział z bliska, jak wygląda praca rekrutera, gdzie ginie czas, gdzie rośnie chaos i gdzie narzędzia nie domykają procesu. To właśnie jest dobry punkt startowy.
Jeśli sam szukasz problemu biznesowego, patrz na miejsca, w których ludzie robią coś ręcznie, powtarzalnie i pod presją. Szukaj obejść, nie tylko deklaracji. Pytaj o koszty błędów, o czas, o emocje i o to, co dziś jest „wystarczająco dobre”, choć powinno być lepsze. I nie myl zainteresowania z walidacją. Prawdziwa walidacja zaczyna się wtedy, gdy użytkownik rozumie wartość, chce sprawdzić rozwiązanie, a najlepiej także za nie płaci.
W odcinku podcastu „Druga Strona Sukcesu” jest jeszcze więcej kontekstu: o budowaniu produktu na przecięciu UX i rekrutacji, o błędach po drodze, o podejściu do porażek i o tym, jak zachować spokój, gdy tworzysz coś po godzinach, między pracą a życiem prywatnym. Jeśli temat badania problemu jest ci bliski, warto odsłuchać rozmowę do końca.
Chcesz zobaczyć, jak wygląda cały proces od zauważenia problemu do budowania rozwiązania, które ma szansę wejść na rynek? Obejrzyj pełny odcinek i sprawdź, jak Daniel myśli o badaniu potrzeb, walidacji i pierwszych krokach startupu.
Posłuchaj odcinka DSS#1 na YouTube →