Prototyp a produkt: jak poznać, że Twoja aplikacja zbudowana z AI jest naprawdę gotowa

Kilka tygodni temu pewna founderka, którą znam, zbudowała aplikację do umawiania wizyt dla terapeutów. Całość zajęła jej cztery dni z kreatorem aplikacji z AI. Robi to, czego potrzebuje: terapeuci widzą swój kalendarz, klienci mogą rezerwować wizyty, potwierdzenia idą e-mailem. Działa.

Wpatruje się w nią od dwóch tygodni i nie wystartowała.

Kiedy zapytałem dlaczego, powiedziała: „Działa, ale… nie czuje się gotowa”.

Zapytałem, co by zmieniła. Powiedziała: „Nie wiem. I to jest problem”.

To najtrudniejszy moment w budowaniu z kreatorem aplikacji z AI. Rzecz jest funkcjonalna, ale istnieje luka między „funkcjonalne” a „czułbym się komfortowo, prosząc prawdziwych ludzi, by tego użyli”. Zrozumienie tej luki — i wiedza, po której jej stronie naprawdę jesteś — to różnica między wypuszczeniem a pozostaniem na zawsze w fazie głosu w głowie.

Co tak naprawdę oznacza „gotowe”

Oto rozróżnienie, które ma znaczenie: prototyp to coś, czego używasz, by przetestować pomysł. Produkt to coś, czego używasz, by rozwiązać problem.

Aplikacja do umawiania wizyt dla terapeutów to prototyp. Udowadnia, że koncept działa. Terapeuta mógłby z niej skorzystać. Ale jest siedemnaście drobiazgów, które sprawiają, że czuje się surowo:

Potwierdzenia e-mail są gołe. Bez logo, bez własnego brandingu, ogólny tekst.
Anulowania nie wysyłają powiadomień. Klienci po prostu się nie pojawiają.
Nie ma listy oczekujących, jeśli terapeuta ma pełny grafik.
Proces rejestracji nie zbiera specjalizacji terapeuty, więc nie da się filtrować po rodzaju praktyki.
Nie ma maila przypominającego wysyłanego 24 godziny przed wizytą.

Żadna z tych rzeczy nie psuje aplikacji. Wszystkie sprawiają, że prawdziwy terapeuta myśli: „To wygląda jak coś, co sklecono w weekend, a nie coś, za co ktoś mi każe płacić”.

To uczucie jest prawdziwe i ma znaczenie. Prototyp rozwiązuje problem w teorii. Produkt rozwiązuje go w praktyce, dla konkretnego człowieka, który go używa.

Trzy pytania, które oddzielają prototyp od produktu

Oto trudna część: nie możesz wiedzieć wszystkiego, czego brakuje. Twój kreator AI też nie może tego wiedzieć. Potrzebujesz więc trzech szybkich pytań, by ustalić, po której stronie linii jesteś.

1. Czy użyłbyś tego, by rozwiązać własny problem?

To pytanie jest uczciwe, bo musisz faktycznie żyć z własnym produktem.

Gdybyś był founderem tej aplikacji do umawiania wizyt dla terapeutów, czy użyłbyś jej, by umówić własną wizytę u terapeuty? Nie „czy mógłbyś” — czy faktycznie użyłbyś jej zamiast łańcucha maili albo wspólnego dokumentu Google?

Jeśli odpowiedź brzmi nie, nie jesteś gotowy. Dokładnie wiesz, co jest nie tak — czujesz to za każdym razem, gdy otwierasz aplikację. Jeśli odpowiedź brzmi tak, jesteś bliżej.

Founderka, o której wspomniałem, przeszła własną rejestrację jako terapeutka. Utknęła na formularzu (prosił o zbyt wiele informacji, zanim pozwolił zarezerwować). Zobaczyła maila potwierdzającego i pomyślała, że wygląda amatorsko. Zaczęła się zastanawiać, jak jej terapeutka odebrałaby maila i czy nie wyląduje w spamie.

Nie używała własnego produktu tak, jak zrobiłby to płacący klient. Kiedy zaczęła, znalazła dziesięć rzeczy do naprawienia.

2. Czy pokazałeś to trzem osobom, które nie są Tobą?

Rozmowa z potencjalnymi użytkownikami jest trudniejsza niż budowanie i większość founderów ją pomija, bo chcą zaskoczyć ludzi przy starcie. To błąd.

Nie potrzebujesz grupy fokusowej. Potrzebujesz trzech osób podobnych do tego, kim — jak myślisz — jest Twój klient. Dla aplikacji dla terapeutów to trzech faktycznych terapeutów.

Oto, czego szukasz: gdzie się gubią? Gdzie się wahają? O co pytają? Nie „co o tym myślą?” (ludzie są zbyt mili). Poproś, by faktycznie wykonali to coś — zarezerwowali wizytę, wysłali maila potwierdzającego, coś anulowali.

Kiedy founderka pokazała swoją aplikację dla terapeutów trzem terapeutom, dwóch z nich zapytało: „Czy mogę ustawić zasady dostępności? Na przykład: nowych klientów przyjmuję tylko w czwartki i nie umawiam podwójnie przed 14:00”. Aplikacja miała kalendarz, ale nie miała zasad. Zbudowała prototyp według tego, jak ona myślała, że działa umawianie wizyt, a nie według tego, jak faktycznie pracują terapeuci.

To są informacje produktowe. Nie zgadłbyś tego ze specyfikacji.

3. Co by się zepsuło, gdybyś dał to dziesięciu prawdziwym użytkownikom?

To najtrudniejsze pytanie, bo wymaga, byś naprawdę przemyślał swoje przypadki brzegowe.

Dla aplikacji dla terapeutów:

Co się stanie, jeśli klient spróbuje zarezerwować dwie wizyty na ten sam czas? (Aplikacja tego nie sprawdza).
Co się stanie, jeśli terapeuta anuluje wizytę? Czy klienci dostają automatyczne powiadomienie? (Nie).
Co, jeśli adres e-mail klienta jest błędny? Czy da się go poprawić bez zaczynania od nowa? (Nie).
Co, jeśli terapeuta ma chorobowe i musi zamknąć kalendarz na tydzień? (Musiałby ręcznie usunąć każdą wizytę).

To nie są bugi. Aplikacja się nie zawiesza. Ale to drobne otarcia. Z dziesięcioma prawdziwymi użytkownikami i prawdziwymi przypadkami brzegowymi trafisz na wszystkie w pierwszym tygodniu.

Produkt obsługuje przypadki brzegowe. Nie wszystkie — niektóre rzeczy mogą poczekać. Ale te, które zdarzają się w pierwszych dwóch tygodniach z prawdziwymi użytkownikami, muszą działać.

Jak zdecydować: test trzech warstw

Użyj tego, by ustalić, gdzie jesteś:

Warstwa 1: Główny przepływ — Czy ścieżka szczęśliwa działa? Czy użytkownik może zrobić główną rzecz, do której Twoja aplikacja jest stworzona?

Dla aplikacji do umawiania wizyt: tak. Ktoś może się zarejestrować, zarezerwować wizytę, dostać potwierdzenie. Działa.

Warstwa 2: Przypadki brzegowe z prawdziwego użycia — Pokazałeś to trzem prawdziwym użytkownikom. Czy trafili na coś, czego nie zbudowałeś? Czy gdzieś się pogubili?

Dla aplikacji do umawiania wizyt: tak. Trzej terapeuci chcieli dostępności opartej na zasadach. Jeden się pogubił, bo mail potwierdzający wyglądał zbyt ogólnie. Jeden próbował usunąć wizyty hurtowo i nie mógł.

Warstwa 3: Dopracowanie i profesjonalizm — Czy czuje się, że Ci zależy? Czy raczej, że sklejone byle jak?

Dla aplikacji do umawiania wizyt: czuje się sklejona. Potwierdzenia e-mail są gołe. Nie ma własnego brandingu. Nie ma komunikatu o błędzie, gdy coś pójdzie nie tak, więc jeśli coś się zepsuje, użytkownik nie ma pojęcia, co się stało.

Oto heurystyka:

Wszystkie trzy warstwy działają? Jesteś produktem. Wypuszczaj.
Warstwy 1 i 2, ale nie 3? Jesteś w 80% gotowy. Spędź dzień na dopracowaniu.
Warstwa 1 działa, warstwy 2 i 3 nie? Jesteś prototypem. Jeszcze nie wypuszczaj.
Warstwa 1 nie jest solidna? Nie jesteś gotowy. Buduj dalej.

Aplikacja dla terapeutów utknęła na granicy między warstwą 1 a warstwą 2. Główny przepływ działał, ale prawdziwi terapeuci znaleźli brakujące elementy. Founderka miała więc wybór: spędzić kolejny tydzień z kreatorem AI, dodając funkcje, których terapeuci naprawdę potrzebują, albo wystartować z tym, co miała, i dodać je później.

(Dodała je. Zajęło to trzy dni. Teraz to produkt).

To, co czyni to trudnym

Powód, dla którego tak wielu founderów tu utyka, jest taki, że budowanie jest przyjemne, a wypuszczanie straszne.

Budowanie to rozmowa z Twoim narzędziem AI. Masz pomysł, opisujesz go, narzędzie go wykonuje. Jest pętla zwrotna trwająca minuty. Wypuszczanie jest inne. Klikasz „publikuj” i jeśli coś jest nie tak, dowiadują się o tym prawdziwi ludzie. Nie ma powtórki.

Więc szukamy powodów, żeby nie wypuszczać. „Nie jest wystarczająco dopracowane”. „Powinienem dodać jeszcze jedną funkcję”. „A co, jeśli czcionki są złe?”. I sześć tygodni później wciąż siedzisz na czymś, co działa, ale nie czuje się gotowe, i wmówiłeś sobie, że to przez czcionki.

To nie czcionki.

Zwykle chodzi o to, że nie spędziłeś czasu z prawdziwym użytkownikiem albo zbudowałeś coś, co miało sens w Twojej głowie, ale niezupełnie pasuje do tego, jak pracują prawdziwi ludzie. To da się naprawić. Wymaga tylko przyznania, że nie wiesz, czego nie wiesz, a potem pójścia na rozmowę z kimś, kto wie.

Lista kontrolna gotowości do startu

Użyj jej. Jest krótka i uczciwa.

Użyłem tego sam, by wykonać prawdziwe zadanie, i zadziałało (nie w trybie demo, ale naprawdę).
Pokazałem to trzem osobom, które faktycznie by tego używały, i naprawiłem rzeczy, które ich myliły.
Każdy błąd, który może się zdarzyć, ma komunikat mówiący użytkownikowi, co z tym zrobić (nie „błąd”, ale konkretną wskazówkę).
Byłoby mi okej, gdyby to była ostatnia wersja przez sześć miesięcy (czyli: jest na tyle kompletna, by być użyteczna, nawet gdybym nigdy więcej jej nie tknął).
Bardziej ekscytuje mnie to, czego nauczę się od prawdziwych użytkowników, niż dodawanie kolejnych funkcji w próżni.

Jeśli możesz zaznaczyć wszystkie pięć pól, jesteś gotowy. Wypuszczaj.

Jeśli nie możesz, nie wypuszczaj. Ale bądź konkretny co do tego, dlaczego. „Nie czuje się gotowe” to nie powód. „Prawdziwi terapeuci potrzebują zasad dostępności, a jeszcze tego nie zbudowałem” to powód. To jest do zrobienia. To da się naprawić. To różnica między byciem w impasie a byciem na ścieżce.

Founderka aplikacji dla terapeutów wypuściła ją wczoraj. Ma swojego pierwszego płacącego klienta. Produkt nie jest idealny, ale jest prawdziwy, a jej klient już mówi jej, co budować dalej. Wtedy właśnie wiesz, że jesteś gotowy: nie wtedy, gdy aplikacja jest idealna, ale wtedy, gdy jesteś gotów dowiedzieć się, co „idealne” naprawdę znaczy dla ludzi, którzy z niej korzystają.