Jak zweryfikować pomysł na aplikację, zanim zaczniesz ją budować (nawet gdy budowanie jest tanie)

Zweryfikuj pomysł na aplikację w trzech tanich krokach, zanim zaczniesz ją budować — strona z listą oczekujących, przedsprzedaż za 200–500 dolarów dla kilku zapisanych osób i jedna szczera rozmowa z klientem. Jeśli żaden z nich nie potwierdzi problemu, oszczędzisz sobie miesięcy pracy.

Budowa aplikacji kiedyś wymagała miesięcy pracy i tysięcy dolarów. To naturalnie odsiewało słabe pomysły — zanim skończyłeś, albo miałeś płacących klientów, albo wiedziałeś już, dlaczego nikt tego nie chciał.

A dziś? Budowanie jest tanie. Możesz zweryfikować pomysł, zbudować MVP i pokazać je użytkownikom w jeden weekend. Co brzmi świetnie, dopóki nie zdasz sobie sprawy z nowego problemu: każdy pomysł możesz zacząć w weekend, ale i tak spędzisz miesiące na tych, które nie mają znaczenia.

Najrzadszym zasobem nie są pieniądze ani czas potrzebny na zbudowanie czegoś. Jest nim twoja uwaga. Na czym skupisz się przez najbliższe trzy miesiące?

Oto jak zweryfikować pomysł, zanim zakochasz się w kodzie.

Jak zweryfikować pomysł na aplikację, zanim zaczniesz ją budować?

Zweryfikuj pomysł na aplikację za pomocą trzech tanich, następujących po sobie testów: strony z listą oczekujących, żeby sprawdzić, czy komukolwiek na tym zależy; małej przedsprzedaży, żeby sprawdzić, czy ktoś za to zapłaci; i jednej szczerej rozmowy, żeby sprawdzić, czy rozumiesz problem. Każdy krok kosztuje godziny, nie miesiące, a każdy z nich może uchronić cię przed zbudowaniem czegoś niewłaściwego.

Czy warto zbudować stronę z listą oczekujących, żeby przetestować pomysł na aplikację?

Tak — strona z listą oczekujących to najprostszy krok weryfikacji: czy komuś zależy na tyle, by odpowiedzieć „tak” na zapis do newslettera?

Zbuduj jednostronicową stronę lądowania dla swojego pomysłu. Bez konieczności zakładania konta. Po prostu opisz, co aplikacja będzie robić, dla kogo jest i dlaczego to ważne. Używaj prawdziwego, ludzkiego języka. Nie przesadzaj ze sprzedażą. Potem dodaj przycisk: „Uzyskaj wczesny dostęp — napiszemy do ciebie, gdy będzie gotowe”.

Zostaw to na tydzień. Jeśli dostaniesz zero zapisów, to też jest informacja. Jeśli dostaniesz pięć, to informacja. Jeśli dostaniesz sto, coś w tym jest.

Nie szukasz wiralowego sukcesu. Szukasz odpowiedzi na podstawowe pytanie: „Czy to rozwiązuje problem, który ktoś rzeczywiście ma?”. Jeśli odpowiedź brzmi „nie”, dowiedziałeś się tego kosztem dwóch godzin i odrobiny zawstydzenia, a nie trzech miesięcy pracy programistycznej.

Znamy założycielkę, która zbudowała aplikację do planowania wizyt osoby wyprowadzającej psy. Dzień spędziła na opisaniu pomysłu, kolejne pół dnia na prostej stronie lądowania, po czym opublikowała ją na kilku forach społecznościowych. W tydzień dostała jeden zapis. Nie zbudowała tej aplikacji. Swój czas przeznaczyła na inny pomysł, który w dwa tygodnie zebrał 400 zapisów. To była właściwa odpowiedź.

Czy warto sprzedać aplikację przed jej zbudowaniem?

Tak, jeśli twoja strona z listą oczekujących zadziałała — przedsprzedaż to kolejny krok i weryfikuje od razu dwie rzeczy: czy ludzie naprawdę zapłacą oraz czy twoje rozumienie problemu odpowiada rzeczywistości.

Napisz e-mail do pięciu osób z listy oczekujących. Powiedz im prawdę: „Buduję to. Jeszcze nie jest gotowe. Czy chcesz zapłacić mi z góry 200 dolarów, żebym mieć pewność, że zbuduję dokładnie to, czego potrzebujesz?”. Nie zakładasz firmy. Sprawdzasz, czy twoje rozumienie problemu pokrywa się z rzeczywistością.

Pewna księgowa wpadła kiedyś na pomysł aplikacji, która automatycznie kategoryzowałaby wydatki małych firm. Zbudowała stronę lądowania. Dostała 30 zapisów. Potem napisała do pięciu z nich: „Buduję to. Czy zapłacisz 500 dolarów, żeby zostać pierwszym klientem i pomóc mi upewnić się, że robię to dobrze?”.

Dwie osoby się zgodziły. Spędziła z nimi trzy tygodnie i odkryła, że prawdziwym problemem wcale nie była kategoryzacja — była nim uzgadnianie danych. Chciały, żeby aplikacja pomagała im udowodnić księgowemu, że ich księgi zgadzają się z wyciągiem bankowym. Niemal zbudowała niewłaściwą aplikację.

Jeśli ludzie nie chcą zapłacić z góry, to też w porządku — dowiedziałeś się tego, zanim cokolwiek zbudowałeś. Ale jeśli zapłacą, a ich potrzeby okażą się inne, niż zakładałeś — to jest złoto. To dokładnie ta rozmowa, którą chcesz przeprowadzić, zanim napiszesz choć jedną linijkę kodu.

O co zapytać potencjalnego klienta, zanim zbudujesz dla niego aplikację?

Zadaj pięć pytań podczas jednej szczerej rozmowy: jak dziś rozwiązuje ten problem, co jest w tym najgorsze, czy wąskie rozwiązanie skłoniłoby go do korzystania z twojej aplikacji, ile obecnie wydaje na powiązane narzędzia i czy zgodziłby się na konkretną cenę. To jego odpowiedzi, a nie twoje założenia, powinny kształtować to, co budujesz.

Czasem ludzie nie chcą zapłacić z góry. Nie są skąpi — są ostrożni. Najpierw chcą coś zobaczyć.

W takim wypadku umów się na rozmowę. Nie typu „hej, chcesz pogadać o moim pomyśle na aplikację?”. Raczej „myślałem o twoim problemie i chcę się upewnić, że dobrze go rozumiem”.

Zadaj mu pięć pytań:

  1. Jak rozwiązujesz to dzisiaj?
  2. Co jest najgorsze w tym, jak robisz to teraz?
  3. Gdybym zbudował coś, co naprawia tę jedną rzecz, korzystałbyś z tego?
  4. Ile wydajesz na narzędzia, które w jakiś sposób rozwiązują ten problem?
  5. Gdybym policzył sobie X dolarów miesięcznie, powiedziałbyś tak czy nie?

Większość ludzi udzieli ci szczerych odpowiedzi. Niektórzy cię zbędą. Ci, którzy odpowiedzą szczerze — zwłaszcza ci, którzy opowiedzą o swoim doraźnym rozwiązaniu albo aktualnie używanym narzędziu — to są ludzie, dla których budujesz.

Pewna założycielka budowała aplikację do zarządzania projektami. Porozmawiała z trzema freelancerami. Zadała im te pytania. Wszyscy troje powiedzieli to samo: „Nie używam do tego żadnego narzędzia. Po prostu trzymam to w głowie. I ciągle mi to umyka”.

Ta odpowiedź zmieniła wszystko. Nie zbudowała narzędzia do zarządzania projektami. Zbudowała coś, co wysyła przypomnienia. Inny produkt, lepszy produkt — oparty na zrozumieniu prawdziwego problemu.

Kiedy pomysł na aplikację przechodzi weryfikację pozytywnie?

Twój pomysł na aplikację przeszedł weryfikację, gdy przynajmniej jeden z trzech testów potwierdza realny popyt: twoja lista oczekujących rośnie, ludzie są gotowi zapłacić z góry albo twoje rozmowy opowiadają spójną historię o problemie. Wtedy właśnie zaczynasz budować.

I budujesz z pewnością siebie, bo nie zgadujesz. Budujesz dla konkretnych ludzi, którzy już powiedzieli ci, czego potrzebują.

Prawdopodobnie i tak coś przeoczysz. Budowanie zmusza cię do podejmowania konkretnych decyzji, których żadna rozmowa nie ujawni. Ale mylisz się co do szczegółów, nie co do tego, czy aplikacja w ogóle ma sens.

Jedna szczera uwaga

Czasem weryfikacja wypada negatywnie. Lista oczekujących się nie zapełniła. Ludzie nie chcą zapłacić z góry. Rozmowy są uprzejme, ale bez entuzjazmu.

I o to właśnie chodzi. To jest wygrana. Dowiedziałeś się tego, zanim spędziłeś tygodnie na budowaniu czegoś, czego nikt nie chce.

Aplikacje, które odnoszą sukces, to nie te, w których założyciel miał idealny pomysł niewymagający weryfikacji. To te, w których założyciel zweryfikował pomysł wcześnie, dwukrotnie zmienił zdanie i za trzecim razem zbudował właściwą rzecz.

Spędź tydzień na weryfikacji. Potem spędź trzy miesiące na budowaniu. Ta proporcja odmieni twoją karierę.