Pierwszy użytkownik jest ważniejszy niż pierwszy feature
Każdy feature przed pierwszym użytkownikiem to zakład - nie inwestycja. Im więcej zakładów piętrzysz, tym mocniej bronisz tego czego nikt nie potwierdził.
Ile feature’ów ma Twój produkt? A ilu użytkowników? Jeśli pierwsza liczba jest większa od drugiej - nie budujesz produktu. Budujesz zakłady.
Feature przed użytkownikiem to zakład
Każdy feature zbudowany przed pierwszym użytkownikiem to zakład. Nie inwestycja - bo inwestycja zakłada znany zwrot. Tu nie wiadomo nawet czy problem istnieje poza głową twórcy.
To nie znaczy, że zakład jest zły. Każdy produkt zaczyna się od zakładu. Problem zaczyna się, gdy zakładów jest dwadzieścia i żaden nie został sprawdzony.
Granica MVP dryfuje bo każdy kolejny feature “brzmi sensownie”. Produkt odpowiada na wizję twórcy bo twórca sam formułuje pytanie i sam na nie odpowiada. Za każdym razem ten sam mechanizm: budowanie bez zewnętrznej weryfikacji.
Kumulacja zakładów
Jeden zakład to ryzyko. Dziesięć zakładów to architektura której nikt nie zamówił.
Im więcej zbudujesz przed pierwszym użytkownikiem, tym trudniej cokolwiek wyrzucić. Nie dlatego że kod jest zły - dlatego że się do niego przywiązałeś. Sunk cost nie jest finansowy. Jest emocjonalny. Dwa tygodnie pracy nad systemem dynamicznych pól sprawiają, że zaczynasz go uzasadniać zamiast pytać czy jest potrzebny.
Bronisz to co masz, zamiast zapytać czy ktoś tego potrzebuje.
”Jeszcze tylko to jedno i pokażę”
Jest taki moment w budowaniu, gdy wiesz że powinieneś pokazać produkt komuś z zewnątrz. I dokładnie wtedy pojawia się myśl: “jeszcze tylko ten jeden feature”.
“Gotowy” nie istnieje dopóki ktoś nie zobaczy produktu. Ale żeby poczuć się gotowym - budujesz dalej. Kolejny feature, kolejne poprawki, kolejny tydzień. Moment konfrontacji się oddala, lista zakładów rośnie - a twórca nie wychodzi ze strefy komfortu. Budowanie jest bezpieczne. Konfrontacja - nie.
Kodowanie daje widoczny postęp - commity, endpointy, strony. Rozmowa z użytkownikiem daje niepewność. Więc domyślnie wybierasz kod i nazywasz to przygotowaniem.
Jeden użytkownik zamienia zakłady w dane
Jeden użytkownik to nie sukces. To zderzenie z rzeczywistością.
“Nie potrzebuję.” “Bardzo pomocne.” “Widziałem już coś takiego u konkurencji.” “Wow, zrobiłeś to lepiej niż…” Obojętnie co usłyszysz - każda reakcja wypłaca zakłady. Jedne wygrywasz, inne przegrywasz. Ale dopóki nie postawisz produktu przed kimś z zewnątrz, kupony leżą niesprawdzone.
Pytanie użytkownika jest filtrem - definiuje co produkt musi robić. Ale żeby usłyszeć to pytanie, trzeba najpierw postawić coś przed użytkownikiem. Nie “gotowy produkt”. Coś. Cokolwiek co pozwoli mu zareagować.
Architektura “na wyrost” zjada czas który miał iść w dotarcie do tego pierwszego użytkownika. Każdy dzień budowania bez konfrontacji to kolejny zakład na stosie.
Ile zakładów jesteś gotów postawić?
- Feature’y da się dobudować.
- Architekturę da się zmienić.
- Stack da się przepisać.
Ale czasu spędzonego na budowaniu czegoś, czego nikt nie potrzebuje, nie da się odzyskać.
Pytanie nie brzmi “czy mój produkt jest gotowy”. Pytanie brzmi: ile zakładów chcę jeszcze postawić zanim sprawdzę, czy ktokolwiek gra?
W newsletterze rozwijam tego rodzaju tematy głębiej. Zapisz się.