Nie buduj produktu, zanim nie sprawdzisz czy jest on potrzebny

Jedna z najcenniejszych rzeczy, do których dochodziłem trochę zbyt długo, brzmi bardzo prosto:

Nie warto budować pełnego rozwiązania, zanim nie sprawdzisz, czy ktokolwiek ma problem jaki ono rozwiązuje.

Brzmi banalnie, ale w praktyce bardzo łatwo zrobić dokładnie odwrotnie. Bo w sumie dla nas programistów, tak jest po prostu prościej.

Najpierw poświęcasz czas na tworzenie. Potem dopieszczenie. Układanie szczegółów. Dopracowywanie struktury. Co mają wspólnego ze sobą te czynności? A no już pewnie domyślasz się o co chodzi.

Nie trzeba gadać z ludźmi!

Jednak przez to wpadasz w klasyczną pułapkę. Nie testujesz rynku. A to on jest głównym interesantem.

Najpierw powinna być obietnica, nie pełny produkt

Przez długi czas wydawało mi się, że żeby zaproponować coś ludziom, trzeba najpierw tę wartość w pełni przygotować.

Że dopiero gotowy materiał, gotowa oferta albo gotowa inicjatywa daje prawo do wyjścia z nią na zewnątrz. Bo coś się ma fizycznego do zaprezentowania.

Dziś patrzę na to inaczej. Jeszcze nie tak, że mam to w 100% opanowane. Potwierdza to fakt, że nie mam jeszcze takiego produktu, który sam się sprzedaje.

Natomiast uczę się i wiem, że na początku dużo ważniejsze jest sprawdzenie, czy sama obietnica danego pomysłu trafia w realną potrzebę. Czy ktoś tego chce. Czy ktoś widzi w tym wartość. Czy temat w ogóle budzi zainteresowanie. I czy w ogóle ktoś jest w stanie za to zapłacić.

Bo jeśli nie, to pełna realizacja nie uratuje złego kierunku. Co najwyżej sprawi, że stracisz więcej czasu. A może i pieniędzy.

Ludzie nie kupują Twojej pracy. Najpierw kupują sens

Jak masz włączony telewizor to pewnie czasem uda Ci się obejrzeć jakiś program, który pojawia się w trakcie trwania reklam. Tak, mnie też to mega frustruje. Dlatego po prostu nie oglądam telewizji. Ale czasem jest on włączony, więc sobie zerknę. I zamiast gapić się tak beznamiętnie w to co widzę, to staram się uruchomić procesy myślowe. Na serio! Podczas oglądania reklam!

Jednej rzeczy nie można im odmówić. Są dobrze zaprojektowane. Głupie, ale przemyślane. Nie wskazują cech produktów. One adresują konkretny problem danej grupy odbiorców. I pokazują, że mają rozwiązanie tego problemu. Nie sprzedają tabletek na ból głowy, tylko obietnicę spokojnego wieczoru. Nie sprzedają samochodu, tylko obietnicę wygody, bezpieczeństwa i prestiżu.

Dobra, ale to taka dygresja do tego jak powinna wyglądać obietnica. Wracając do tematu.

Odbiorca nie jest zainteresowany ile Ty godzin włożyłeś w dany produkt. On ocenia, czy problem, który obiecujesz rozwiązać, jest dla niego istotny.

Jeśli tak, zaczyna się rozmowa.

Jeśli nie, nawet świetnie dopracowana forma niczego nie dopracuje.

Trochę jak machanie łopatą w miejscu, w którym nie ma nic do wykopania.

Dlatego dużo bardziej opłaca się pokazać szkic, zapowiedź, temat, abstract, listę problemów, które chcesz zaadresować, albo prostą obietnicę wartości, niż od razu budować wszystko od zera w ciemno.

Sam popełniłem ten błąd na własnym projekcie

Jednym z mocniejszych przykładów była dla mnie społeczność “Next-Level Dev”.

Pomysł sam w sobie wydawał się sensowny. Miał zrzeszać osoby na poziomie juniorskim i tych, którzy chcieli wejść do branży. Tylko że zamiast najpierw wypytać ludzi, czego dokładnie oczekują od takiego miejsca, od razu przeszedłem do budowania.

Powstał serwer Discord. Kanały. Uprawnienia. Konfiguracja. Struktura. Czyli cała masa pracy jeszcze przed prawdziwą weryfikacją, czy ludzie w ogóle chcą uczestniczyć w czymś zaprojektowanym właśnie w ten sposób.

Dopiero później przyszło promowanie inicjatywy.

I wtedy okazało się, że mój plan istniał głównie w mojej głowie.

Ludzie wchodzili, ale tak naprawdę nie było jasnego kontraktu dotyczącego tego, co dokładnie tam dostaną, jaką wartość ma ta przestrzeń i czego realnie oczekują.

Do tego doszedł jeszcze projekt open source, który miał wspierać rozwój uczestników. W teorii brzmiało to dobrze. W praktyce pochłaniało ogrom energii i angażowało aktywnie zaledwie kilka osób, zamiast wzmacniać całą społeczność.

Finalnie projekt został zamknięty. Nie dlatego, że włożyłem w niego za mało pracy. Właśnie odwrotnie. Dlatego, że zbyt szybko przeszedłem do budowania, a za późno do prawdziwej walidacji.

Szkoda, ale to cenna nauczka!

To samo dotyczy prezentacji

Dokładnie ten sam mechanizm działa przy tworzeniu prezentacji konferencyjnych.

Jeśli od razu siadasz do pełnej narracji, slajdów i całej konstrukcji wystąpienia, ryzykujesz, że napracujesz się nad czymś, co w ogóle nie chwyci.

Dużo rozsądniejsze wydaje mi się zbudowanie najpierw prostszego poziomu walidacji.

Na przykład abstractu.

Jeśli temat nie przejdzie przez Call for Papers, dostajesz sygnał. Być może temat nie jest wystarczająco ciekawy. Być może opis nie pokazuje wartości. Być może trzeba inaczej ustawić akcenty.

To nadal znacznie tańsza lekcja niż przygotowanie całej prezentacji, której nikt nie chce zobaczyć.

Waliduj nawet przez szacunek dla swojego czasu

Ktoś może powiedzieć, że takie podejście brzmi jak sprzedawanie czegoś, czego jeszcze nie ma. I w sumie… ma rację!

Ja wolę patrzeć na to inaczej.

To nie jest ściema, jeśli uczciwie komunikujesz, że jesteś na etapie sprawdzania pomysłu. To jest po prostu sposób na to, żeby nie marnować miesięcy pracy na kierunek, który od początku nie ma zapotrzebowania.

Walidacja nie służy tylko temu, żeby pomysł potwierdzić.

Chociaż nie, w sumie służy.

Ale za tym stoi też oszczędność czasu przez odrzucenie tego, co nie ma szansy się sprawdzić.

Pytanie tylko ile czasu na walidację jest niezbędne. Ale to myślę, że inny temat.

Co robiłbym teraz inaczej?

Dziś najchętniej robiłbym to tak:

najpierw obietnica,
potem reakcja rynku,
dopiero później pełna realizacja.

Jeśli ludzie widzą wartość, można iść dalej. Prosta sprawa.

Jeśli nie widzą, lepiej zmodyfikować kierunek albo zamknąć temat szybko, zanim zdążysz się do niego emocjonalnie przywiązać. A to jest cholerna pułapka.

I pamiętaj, Twój czas jest ograniczony. Dlatego nie warto machać łopatą, kiedy jeszcze nie wiesz, czy w ogóle kopiesz w dobrym miejscu. Bo jedynie co wykopiesz to frustrację i poczucie winy.