Pomysł na aplikację sprawdzisz, zanim napiszesz kod: porozmawiaj z kilkoma osobami, które mają ten problem, zapytaj, jak rozwiązały go ostatnim razem, i zaproponuj konkretny krok — zapis, próbę albo płatny pilotaż. Liczą się zachowania, nie komplementy.
Opowiadasz znajomemu o aplikacji. Słyszysz: „Super, sam bym używał”. Budujesz przez kilka tygodni, wysyłasz link, a znajomy nie ma czasu nawet założyć konta.
Nikt Cię nie okłamał. Pochwalić pomysł jest łatwo. Zmienić swój sposób pracy — trudno. To jak z nową knajpą na osiedlu: wszyscy mówią „przyjdę”, ale liczy się, kto w sobotę usiądzie przy stoliku i zapłaci rachunek.
Dlatego zanim postawisz lokal, wyjedź z food truckiem. Sprawdź, kto ma problem, jak go dziś rozwiązuje i czy zrobi konkretny krok. Pewności nie dostaniesz. Dostaniesz wiedzę, czy budować, zawęzić pomysł, czy go odłożyć.
- 5. Wraca do produktunajmocniejszy sygnał
- 4. Płatny pilotażpłaci, zanim wszystko jest gotowe
- 3. Próba na własnym przykładziedaje swój czas i dane
- 2. Zapis na listęzostawia e-mail
- 1. „Fajny pomysł”nic nie kosztuje
Jeden klient, jedna sytuacja — wtedy wiesz, o co pytać
Weźmy wymyślony przykład: narzędzie do ofert dla firm remontowych. „Każdy, kto robi wyceny” to za szeroko. Duża firma z kosztorysantem i jednoosobowy wykonawca to dwa różne światy.
Zawęź: mała firma, w której właściciel sam robi oferty po oględzinach mieszkań. Zamiast myśleć o całym rynku, poznajesz jedną konkretną pracę.
Zapisz, co Twoim zdaniem jest w niej trudne. Przepisywanie notatek? Pilnowanie stawek? Poprawki po rozmowie z klientem? To na razie przypuszczenia. Nie wpisuj ich do opisu produktu, zanim ich nie sprawdzisz.
Pytaj o ostatni raz, nie o „kiedyś”
Na rozmowę odłóż prezentację aplikacji. Najpierw słuchasz. Najlepsze pytania dotyczą przeszłości, bo o niej ludzie mówią prawdę:
- Kiedy ostatnio robiłeś taką ofertę?
- Jak to szło, od pierwszej notatki do wysłania?
- Co trzeba było poprawiać albo przepisywać?
- Jakich narzędzi używałeś?
- Próbowałeś to już usprawnić? Co z tego wyszło?
- Kto zdecydowałby o zakupie programu i z jakich pieniędzy?
Poproś, żeby pokazał, jak pracuje, na wymyślonych danych. Nie potrzebujesz dokumentów jego klientów. Wystarczy układ arkusza i kolejne kroki.
Pytania o „ostatni raz” to w praktyce metoda opisana przez Roba Fitzpatricka w książce The Mom Test: pytaj o fakty z życia rozmówcy, a nie o jego opinię o Twoim pomyśle.
Obserwacja pokazuje rzeczy, o których trudno opowiedzieć z pamięci. Y Combinator opisuje ją jako sposób poznania prawdziwej pracy użytkownika: Practical Design: User Observation.
Notatka w trzech kolumnach chroni przed myśleniem życzeniowym
Po rozmowie pamiętasz głównie zdania, które pasują do Twojego marzenia. Pomaga prosta tabelka: osobno to, co zobaczyłeś, osobno to, co sobie dopowiadasz.
| Co usłyszałeś lub zobaczyłeś | Twoja interpretacja | Co jeszcze sprawdzić |
|---|---|---|
| Rozmówca pokazał kilka wersji jednej oferty | Poprawki mogą być uciążliwe | Co je wywołało i jak często się zdarzają? |
| Używa własnego arkusza od kilku lat | Zmiana wymaga przeniesienia cennika | Czy chciałby przetestować import? |
| Poprosił o info, kiedy aplikacja będzie | Interesuje go temat | Czy umówi konkretną próbę? |
To wymyślone przykłady, nie wyniki naszych badań. Pokazują, że jeden fakt ma kilka wyjaśnień. Kilka wersji oferty może znaczyć problem — albo zwykłe ustalanie zakresu, z którym arkusz radzi sobie świetnie.
Twoim konkurentem jest często zwykły arkusz
Konkurencją nie musi być inna aplikacja. Bywa nią arkusz, pracownik, stary szablon albo decyzja „nie robię tego wcale”. Zapytaj, co rozmówca lubi w obecnym sposobie. Zobaczysz wtedy, ile kosztuje go zmiana.
Jeśli Twój program oszczędza kilka kliknięć, ale wymaga wpisania setek pozycji cennika, ludzie zostaną przy arkuszu. Jeśli potrafi wykorzystać to, co firma już ma, start jest łatwiejszy. Sprawdzisz to w próbie, nie w głowie.
Poszukaj też momentu, w którym potrzeba robi się pilna: więcej zleceń, nowy pracownik, kosztowna pomyłka. To wtedy ludzie kupują.
Szybkie testy zza biurka — i czego nie dowodzą
Zanim umówisz rozmowy, możesz zrobić kilka prostych testów bez wychodzenia z domu. Każdy coś mówi, ale żaden nie zastąpi rozmowy.
- Czy ludzie tego szukają? Wpisz problem w wyszukiwarkę, poczytaj fora i grupy branżowe na Facebooku. Widzisz, że temat istnieje. Nie widzisz, czy ktoś za rozwiązanie zapłaci.
- Co mówią o konkurencji? Przeczytaj opinie o istniejących narzędziach. Skargi podpowiadają, czego brakuje. Nie mówią, czy ktoś przejdzie na nowe narzędzie.
- Strona z zapisem na listę. Opisz rezultat i poproś o e-mail. Zapis to zgoda na kontakt, a nie zakup.
- Przedsprzedaż. Zaproponuj wcześniejszy zakup na uczciwych warunkach. To najmocniejszy test, ale wymaga jasnego zakresu i zasad zwrotu.
Najmniejszy test największej niewiadomej
Nie wiesz, czy problem w ogóle istnieje? Rób kolejne rozmowy, nie ekran logowania. Problem jest jasny, ale nie wiesz, czy Twój pomysł pomaga? Przygotuj przykładową ofertę ręcznie i pokaż efekt.
To jest właśnie food truck. Mówisz wprost, co robisz ręcznie i czego jeszcze nie ma. Prosisz o zanonimizowane pozycje, robisz dokument i patrzysz, czy ktoś chce go użyć w prawdziwej pracy. Automatyzujesz dopiero to, co się sprawdziło.
Paul Graham opisuje taką ręczną pracę na starcie w eseju Do Things that Don't Scale. To sposób uczenia się, czego ludzie potrzebują, a nie dowód, że Twoja aplikacja zarobi.
Trzy sygnały, które ważą więcej niż komplement
Gdy znasz problem, możesz pokazać propozycję: rezultat, ograniczenia, cenę i sposób korzystania. Zamiast „czy kiedyś byś kupił?” zaproponuj konkretny krok:
- Zapis na listę — zgoda na dalszy kontakt.
- Umówiona próba na własnym przykładzie — gotowość, żeby poświęcić czas.
- Płatny pilotaż z jasnym zakresem — akceptacja konkretnej oferty.
Żaden z tych sygnałów osobno nie potwierdza trwałego biznesu. Razem z powrotami do produktu pokazują, czy idziesz w dobrą stronę.
Ktoś chce obejrzeć pokaz, ale nie chce użyć własnego przykładu? Zapytaj dlaczego. Może nie trafiasz w potrzebę. Może próba wymaga za dużo przygotowań. Odpowiedź podpowie, co zmienić.
Zasady decyzji spisz, zanim zaczniesz rozmawiać
Przed rozmowami zapisz, czego chcesz się dowiedzieć i ile pracy na to dajesz. Na przykład:
Porozmawiam z sześcioma właścicielami małych firm z jednej branży. Sprawdzę, jak robią oferty i co ostatnio poszło trudno. Jeśli problem się powtarza, zaproponuję próbę na ich przykładach. Potem zdecyduję: dalszy test, zmiana zakresu albo odłożenie pomysłu.
Sześć rozmów to przykład organizacji pracy, nie naukowy próg. Przy tak małej grupie szukasz powtarzających się zachowań, a nie procentów całego rynku.
Sami zaliczyliśmy ten błąd: przy code2saas panel powstał, zanim odbyły się rozmowy z odbiorcami. Opisujemy to w teście naszej własnej metody.
Zapisz też z góry, co podważy pomysł: problem zdarza się rzadko, obecne rozwiązanie wystarcza, nie dotrzesz do osoby decydującej albo zakres przerasta budżet.
Po rozmowach: jedna decyzja, zapisana na papierze
Możesz zbudować mały fragment, zmienić odbiorcę, uprościć próbę albo zamknąć temat. Zapisz, dlaczego. Za tydzień nie będziesz wracać do tych samych założeń bez nowego dowodu.
Idziesz w budowę? Policz koszt pierwszej wersji i utrzymania, a potem przejdź przewodnik po tworzeniu aplikacji z AI. Zachowaj kontakt z osobami, które zgodziły się na próbę. To do nich wrócisz z pierwszym działającym fragmentem.
Chcesz przejść taki proces przy własnej aplikacji? Wyślij zgłoszenie do Buildera i opisz w nim swój pomysł. Builder to program z prowadzeniem w małej grupie: łączy pracę z AI ze sprawdzaniem pomysłu i przygotowaniem produktu do sprzedaży. Warunki udziału omawiamy na rozmowie.
Jeszcze nie teraz? Zostaw e-mail na liście — napiszemy, gdy ruszy kolejny nabór.