- Najczęstszy błąd to rozwiązywanie problemu, którego nikt nie ma; zacznij od problemu, który znasz z własnego doświadczenia.
- AI skraca budowę, ale nie skraca potrzeby rozmowy z użytkownikami.
- Zbuduj najwęższą wersję, pokaż jej pięciu osobom i zmierz, czy wracają.
Dzięki AI zbudowanie działającej aplikacji zajmuje dziś godziny, a nie miesiące. Łatwiej więc niż kiedykolwiek zbudować coś, czego nikt nie potrzebuje. W eseju How to Get Startup Ideas Paul Graham pisze, że zdecydowanie najczęstszym błędem startupów jest rozwiązywanie problemów, których nikt nie ma. To spostrzeżenie z 2012 roku nic nie traci na aktualności, gdy budowa trwa wieczór. Poniżej plan, który przesuwa wysiłek z budowania na zrozumienie problemu.
Zacznij od problemu, który znasz
Graham radzi, by nie próbować wymyślać pomysłów, tylko szukać problemów, najlepiej własnych. Najlepsze pomysły mają jego zdaniem trzy wspólne cechy: są czymś, czego chcą sami założyciele, co sami potrafią zbudować i czego wartości mało kto jeszcze dostrzega. Opisuje też pułapkę „zmyślonych” pomysłów, które brzmią wiarygodnie, a w rzeczywistości są złe, bo powstają z wymyślania zamiast z obserwacji. Czasownik, którego powinieneś używać, to „zauważyć”, a nie „wymyślić”. Zapisuj więc przez dwa tygodnie rzeczy, które cię w pracy irytują, które robisz ręcznie i które inni robią źle, a potem wybierz jedną, która dotyka kilku osób.
| Wymyślony | Zauważony | |
|---|---|---|
| Źródło | Burza mózgów, trendy | Własny problem lub obserwacja |
| Dowód potrzeby | Brak, „pewnie ktoś by chciał” | Ty lub ktoś bliski już ma ten problem |
| Pierwsza rozmowa | Z kolegami, którzy mówią „fajne” | Z osobami, które mają problem i szukają rozwiązania |
| Ryzyko | Rozwiązanie problemu, którego nikt nie ma | Mniejsze, ale wciąż trzeba sprawdzić skalę |
Najwęższa wersja
Opracowanie Anthropic o skutecznych agentach zaleca szukanie najprostszego rozwiązania i dokładanie złożoności tylko wtedy, gdy jest potrzebna. Dla produktu oznacza to wersję tak wąską, że wydaje się nieprofesjonalna: jedna osoba, jedna czynność, jeden wynik. Jeśli problem to „ręczne przepisywanie danych z faktur”, najwęższa wersja przyjmuje jeden typ faktur i zwraca tabelę do sprawdzenia, bez kont, bez płatności i bez panelu. Zbuduj ją z pomocą AI w jeden wieczór, tak jak opisuje artykuł Prototyp w jeden wieczór. Cały przepływ zamień na proces, który możesz najpierw wykonywać ręcznie z udziałem AI: jeśli pierwszych pięć osób nie widzi wartości, kod niczego nie zmieni.
Pierwsi użytkownicy i pomiar
Pokaż najwęższą wersję pięciu osobom z grupy docelowej. Nie pytaj, czy by z tego korzystali, bo odpowiedź „tak” nic nie kosztuje. Obserwuj, jak używają, i patrz, czy wracają po tygodniu. Zapisuj, gdzie się zacinają, jakich słów używają i o co proszą. Jedyny sensowny pomiar na tym etapie to pytanie: czy ktoś użył tego drugi raz bez przypominania? Jeśli tak, masz coś, co warto rozwijać. Jeśli nie, zmień problem lub grupę, zamiast dodawać funkcje.
- 01ProblemZauważony, najlepiej własny.
- 02WersjaNajwęższa: jedna osoba, czynność, wynik.
- 03ProcesNajpierw ręcznie z AI, potem kod.
- 04UżytkownicyPięć osób, obserwacja, nie ankieta.
- 05PomiarCzy wracają bez przypominania?
- 06DecyzjaRozwijać, zmienić problem lub zakończyć.
Czego nie robić na początku
Nie zaczynaj od logo, nazwy i strony reklamowej. Nie buduj kont użytkowników, płatności ani panelu administratora, dopóki pięć osób nie powie, że chce za to płacić. Nie rozszerzaj zakresu po pierwszym pozytywnym sygnale: jedna osoba, która pochwaliła, to nie rynek. Nie ufaj ocenom znajomych, bo grzeczność jest łatwiejsza niż szczerość. I nie traktuj kosztów modeli jak zaniedbywalnych: oblicz koszt jednego użycia, zanim zaprosisz tysiąc osób, tak jak w artykule Koszt zadania w tokenach. Prosty produkt, który ktoś naprawdę potrzebuje, wygrywa z wyrafinowanym, którego nikt nie otworzył drugi raz.
Zanim ktoś obcy zacznie używać
Gdy produkt trafia do obcych ludzi, pojawiają się obowiązki. Przejrzyj bezpieczeństwo kodu, o czym piszę w tekście Bezpieczeństwo kodu z AI: pięć kontroli, a w repozytorium włącz skanowanie kodu. Ustal zasady dotyczące danych użytkowników: jakie zbierasz, po co i jak długo przechowujesz. Sprawdź przepisy: jeśli produkt zawiera czatbota, według Komisji Europejskiej użytkownik powinien wiedzieć, że rozmawia z maszyną, o czym piszę w artykule AI Act: przejrzystość treści. Zaplanuj utrzymanie: kto naprawi błąd w niedzielę, skąd weźmiesz pieniądze na koszty modeli i co zrobisz, gdy dostawca zmieni cennik lub model. Całość tematu opisuje hub Produkty AI.
Stan wiedzy: 20 października 2026. Esej Grahama jest z 2012 roku, a jego wnioski są zasadą ogólną; przepisy i narzędzia zmieniają się.