Jak sprawdzić pomysł na aplikację, zanim ją zbudujesz

Aby sprawdzić pomysł na aplikację, ustal, czy konkretna grupa ludzi ma ten problem, czy już próbuje go rozwiązać i czy oddałaby coś realnego, czas, adres e-mail albo pieniądze, za Twoje rozwiązanie. Zacznij od rozmów, przejdź do strony docelowej lub listy oczekujących, a za najmocniejszy dowód uznaj przedsprzedaż albo powracającego użytkownika. Każdy krok kosztuje nieco więcej i mówi nieco więcej.

Walidacja nie dowodzi, że pomysł odniesie sukces. Zmniejsza szansę, że spędzisz miesiące na czymś, czego nikt nie chce.

Co naprawdę testujesz

„Czy to dobry pomysł?” to pytanie zbyt ogólne, by je sprawdzić. Rozbij je na pytania, na które da się odpowiedzieć:

Ostatni punkt bywa pomijany. Prawdziwy problem, do którego nie możesz dotrzeć z klientami, to nadal trudny biznes.

Krok 1: Zapisz swoje najbardziej ryzykowne założenie

Przed jakimkolwiek researchem zapisz pomysł jednym zdaniem: „[Kto] zmaga się z [problemem] i użyłby [rozwiązania], ponieważ [powód]”. Następnie wypisz, co musi być prawdą, żeby to zadziałało, i zakreśl to, czego jesteś najmniej pewien. To testujesz najpierw.

Dla aplikacji do umawiania wizyt dla groomerów psów najbardziej ryzykowne założenie może nie brzmieć „groomerzy potrzebują terminarza” (oczywiście, że tak), ale „groomerzy są na tyle niezadowoleni z obecnego narzędzia, żeby przejść na inne”.

Krok 2: Wywiady o problemie

Wywiady to najtańsza i najbardziej wartościowa metoda, a jednocześnie najłatwiej zrobić je źle. Celem jest poznanie obecnego zachowania rozmówcy, a nie sprzedaż.

Z kim rozmawiać

Z osobami pasującymi do Twojego zdania opisującego grupę. Znajomi i rodzina nadają się do ćwiczeń, ale będą uprzejmi zamiast szczerzy. Szukaj prawdziwych potencjalnych klientów tam, gdzie już są: w grupach branżowych, subredditach, lokalnych stowarzyszeniach biznesowych, we własnej sieci kontaktów na LinkedIn.

O co pytać

Pytaj o przeszłość, a nie o hipotetyczną przyszłość:

• „Opowiedz o ostatnim razie, kiedy zmierzyłeś się z [problemem].”
• „Co wtedy zrobiłeś? Jakich narzędzi użyłeś?”
• „Co w tym było najbardziej irytujące?”
• „Czy za coś zapłaciłeś, żeby to naprawić? Dlaczego tak lub nie?”
• „Kto jeszcze jest zaangażowany, gdy to się dzieje?”

Czego unikać

• „Czy użyłbyś aplikacji, która…?” Prawie każdy powie „tak”, żeby być uprzejmym.
• Zbyt wczesne pokazywanie rozwiązania. Gdy je zobaczą, reagują na nie zamiast opowiadać o swoim problemie.
• Liczenie komplementów. „Świetny pomysł” nie jest dowodem. „Czy mogę to wypróbować, gdy będzie gotowe?” to trochę. „Oto moja karta” to bardzo dużo.

Rób notatki, a potem zapisz trzy rzeczy, których się dowiedziałeś. Gdy kilka osób opisuje ten sam ból podobnymi słowami, zapisz te słowa. Staną się nagłówkiem Twojej strony docelowej.

Krok 3: Sprawdź, co już istnieje

Szukaj problemu, a nie swojego rozwiązania. Przeglądaj istniejące produkty, ich strony cen i publiczne opinie. Konkurencja zwykle jest dobrym znakiem: oznacza, że ludzie płacą za rozwiązanie tego problemu. Szukasz luki: grupy, której istniejące narzędzia słabo obsługują, poziomu cenowego, którego nikt nie pokrywa, albo procesu, który wciąż odbywa się w arkuszach.

Jeśli nie istnieje nic, dowiedz się dlaczego. Czasem to szansa, a często oznacza, że problem nie jest na tyle dotkliwy, by za niego płacić.

Krok 4: Test typu smoke na stronie docelowej

Test smoke to strona opisująca produkt tak, jakby już istniał, z jasnym działaniem: dołącz do listy oczekujących, poproś o dostęp lub zamów z wyprzedzeniem. Następnie kierujesz na nią odpowiednie osoby i mierzysz, ile z nich podejmie działanie.

Strona potrzebuje:

1. Nagłówka, który nazywa problem słowami Twoich rozmówców.
2. Trzech lub czterech konkretnych korzyści, czyli tego, co się zmienia dla użytkownika.
3. Jednego wezwania do działania.
4. Uczciwej informacji, że produkt jest w trakcie tworzenia, żeby nikt nie czuł się oszukany.

Potem kieruj ruch tam, gdzie są Twoi odbiorcy. Mały test płatnej reklamy skierowanej na wąską grupę może zadziałać; może też zadziałać publikowanie w społecznościach, o ile przestrzegasz ich zasad. Jak zbudować stronę docelową, która konwertuje opisuje strukturę i treść.

Czytanie wyników

Nie ma uniwersalnie „dobrego” współczynnika konwersji, więc porównuj z samym sobą: uruchom dwa nagłówki albo dwie grupy odbiorców i zobacz, który działa lepiej. Najbardziej użyteczny wynik to nie procent, lecz lista osób, które się zapisały. Napisz do nich i poproś o rozmowę.

Krok 5: Zbuduj listę oczekujących i wykorzystaj ją

Lista oczekujących zbiera adresy e-mail zainteresowanych osób przed startem. Jest przydatna z dwóch powodów: daje ludzi do przeprowadzenia wywiadów i odbiorców w dniu premiery.

Jej słabością jest to, że zapisanie się jest prawie darmowe. Spraw, żeby lista pracowała bardziej:

• Zadaj jedno pytanie przy zapisie, np. „Czego używasz do tego dziś?”.
• Odpowiadaj osobiście pierwszym zapisanym i poproś o 15 minut.
• Wysyłaj krótką aktualizację co kilka tygodni, żeby lista nie wystygła.

Jak zbudować stronę listy oczekujących opisuje budowę, łącznie z tym, gdzie przechowywane są adresy e-mail.

Krok 6: Sprzedaj z wyprzedzeniem lub pobierz zaliczkę

Najsilniejszym wczesnym sygnałem są pieniądze. Zaoferuj wczesny dostęp ze zniżką, cenę dla członków założycieli albo zwrotną zaliczkę i zobacz, kto zapłaci. Użyj linku do płatności od swojego dostawcy płatności; gotowy produkt nie jest potrzebny.

Bądź bezpośredni: powiedz, kiedy spodziewasz się dostawy, i zwróć pieniądze każdemu, kto o to poprosi. Przedsprzedaż, której nikt nie kupi, to też wynik. Może oznaczać, że cena jest zła, grupa odbiorców jest zła albo ból nie jest tak ostry, jak brzmiał w wywiadach.

Krok 7: Testy concierge i Wizard of Oz

Czasem najszybszym „produktem” jesteś Ty.

• Test concierge: dostarcz wynik ręcznie. Jeśli aplikacja miałaby generować cotygodniowe raporty, przygotuj je sam w arkuszu i wyślij mailem. Dowiesz się dokładnie, co użytkownicy cenią, zanim to zautomatyzujesz.
• Test Wizard of Oz: użytkownicy widzą prosty interfejs, ale za nim pracujesz ręcznie. Użytkownik doświadcza produktu, a Ty dowiadujesz się, czy wraca.

Oba są powolne w skalowaniu i o to właśnie chodzi. Automatyzujesz dopiero to, co okazało się warte zrobienia.

Krok 8: Zbuduj mały MVP i obserwuj zachowanie

Minimalny produkt użytkowy to najmniejsza wersja, która wykonuje jedno kluczowe zadanie. Przy kreatorach aplikacji AI działający MVP z bazą danych i logowaniem może zająć dni zamiast miesięcy, więc rozsądnie jest włączyć go w walidację. Zobacz czym jest MVP.

Kluczową miarą nie jest liczba zapisów, lecz powrotne użycie. Czy ludzie wracają drugi i trzeci raz bez Twojego przypominania? Czy zapraszają kolegę? Czy narzekają, gdy coś się zepsuje? To oznaki, że aplikacja ma dla nich znaczenie.

Porównanie metod walidacji

Kiedy przestać, zmienić lub kontynuować

Ustal próg przed startem, na przykład: „dziesięć wywiadów, trzy osoby mówią, że zapłacą, jedna przedsprzedaż”. Potem bądź szczery:

• Kontynuuj, jeśli ludzie wciąż opisują ten sam ból, a niektórzy zobowiązują się do zapłaty lub czasu.
• Zmień, jeśli ból jest prawdziwy, ale dotyczy innej grupy albo innej ceny, niż zakładałeś. To częste i przydatne.
• Zatrzymaj się, jeśli nikt nie próbował rozwiązać problemu, nikt nie zapłaci i nie możesz dotrzeć do osób, które go mają.

Wczesne zatrzymanie to dobry wynik. Uwalnia czas na przetestowanie kolejnego pomysłu.

Walidacja z Mythex

Mythex pasuje do późniejszych etapów tego procesu. Możesz opisać stronę docelową z formularzem listy oczekujących i mieć ją na publicznym adresie tego samego dnia, a zapisy trafiają do bazy danych. Gdy sygnały są dobre, ten sam projekt możesz rozwinąć w mały MVP. Na start nie trzeba płacić, a przewodnik po liście oczekujących w dokumentacji pokazuje kroki. Jeśli rozważasz budżet, ile kosztuje zbudowanie aplikacji porównuje opcje.

Pytania