Pomysł na aplikację potrafi dawać dużo energii. Nagle widać nazwę, ekran startowy i listę funkcji. Najtrudniejsze pytanie pojawia się jednak wcześniej: czy problem jest na tyle ważny, żeby ktoś zmienił dla niego swoje zachowanie?

Tego nie da się rozstrzygnąć samym entuzjazmem ani pytaniem znajomych, czy „używaliby takiej aplikacji”. Da się natomiast zebrać dowody, zanim powstanie kod.

Walidacja pomysłu nie służy temu, żeby przekonać siebie i innych, że warto budować. Służy temu, żeby ograniczyć ryzyko niewłaściwej decyzji. Czasem prowadzi do pierwszej wersji produktu. Czasem pokazuje, że problem jest zbyt rzadki, za mało dotkliwy albo już dobrze rozwiązany. Oba wyniki są wartościowe.

Najpierw sprawdź problem, nie rozwiązanie

Zdanie „chcę stworzyć aplikację do zarządzania firmą” opisuje rozwiązanie. Nie mówi jeszcze, co konkretnie nie działa.

Lepszy punkt wyjścia to obserwacja: „po spotkaniu z klientem decyzje trafiają do trzech miejsc, a tydzień później nikt nie pamięta ich uzasadnienia”. Taki opis wskazuje sytuację, zachowanie i skutek. Można go sprawdzić w rozmowie lub obserwacji.

Zanim pokażesz komuś swój pomysł, zapisz:

  • kto doświadcza problemu,
  • w jakim momencie problem się pojawia,
  • jak często wraca,
  • jak człowiek radzi sobie dzisiaj,
  • co traci, gdy niczego nie zmieni.

    • Jeśli nie potrafisz podać konkretnego ostatniego przypadku, prawdopodobnie masz jeszcze hipotezę, a nie rozpoznany problem.

    Nie pytaj: „czy używałbyś takiej aplikacji?”

    Ludzie chcą być pomocni. Kiedy słyszą pomysł, często odpowiadają pozytywnie, nawet jeśli nigdy nie zmieniliby dotychczasowego sposobu pracy. Deklaracja o przyszłości jest słabym dowodem.

    W rozmowie pytaj o przeszłość:

    1. Kiedy ostatnio pojawił się ten problem? 2. Co dokładnie wtedy zrobiłeś? 3. Z jakich narzędzi lub osób skorzystałeś? 4. Co było najbardziej uciążliwe? 5. Czy próbowałeś już to zmienić? 6. Co sprawiło, że poprzednie rozwiązanie zostało albo odpadło?

    Nie przedstawiaj aplikacji w pierwszych minutach. Najpierw poznaj rzeczywisty proces. To w nim kryją się ograniczenia, których nie widać na makiecie.

    Szukaj zachowania, które już istnieje

    Najsilniejszym sygnałem nie jest pochwała pomysłu. Jest nim wysiłek, który człowiek już podejmuje, żeby poradzić sobie bez Twojego produktu.

    Może to być rozbudowany arkusz, ręczne przepisywanie danych, przypomnienia w kalendarzu, zatrudnienie dodatkowej osoby albo regularne godzenie się ze stratą czasu. Taki prowizoryczny sposób pokazuje, że problem ma wystarczającą wagę, by wywołać działanie.

    Brak obejścia nie zawsze oznacza brak problemu. Powinien jednak uruchomić dodatkowe pytanie: dlaczego użytkownik dotąd niczego z nim nie zrobił? Być może ból jest mały, występuje rzadko albo decyzja należy do kogoś innego.

    Przetestuj rezultat bez budowania aplikacji

    Pierwszy test nie musi być produktem. Powinien sprawdzać najważniejszą niewiadomą.

    Jeżeli zakładasz, że właściciel potrzebuje cotygodniowego podsumowania decyzji, przygotuj je ręcznie dla kilku osób. Jeżeli pomysł dotyczy uporządkowania zgłoszeń, przyjmij je prostym formularzem i obsłuż proces ręcznie. Jeżeli nie wiesz, czy użytkownik rozumie obieg, pokaż klikalny prototyp bez zapisu danych.

    Taki test pozwala zobaczyć:

  • czy użytkownik w ogóle rozpoczyna proces,
  • gdzie się zatrzymuje,
  • jakich informacji potrzebuje,
  • czy wraca po rezultat,
  • czy chce wykonać kolejny krok.

    • Nie automatyzuj zbyt wcześnie. Ręczna obsługa na początku bywa zaletą, bo odsłania pytania i wyjątki, które później powinien uwzględnić produkt.

    Ustal dowód przed rozpoczęciem testu

    Bez kryterium wyniku każdy sygnał można uznać za potwierdzenie pomysłu. Dlatego jeszcze przed rozmowami zapisz, co zmieni Twoją decyzję.

    Przykładowy kontrakt walidacji może brzmieć:

  • porozmawiam z ośmioma osobami należącymi do jednej grupy,
  • co najmniej połowa opisze świeży, konkretny przypadek,
  • kilka osób pokaże obecne obejście lub realny koszt problemu,
  • co najmniej dwie osoby przejdą ręczny test od początku do końca,
  • po teście będę umiał opisać jeden wspólny obieg.

    • To nie jest uniwersalna matematyka sukcesu. To ochrona przed przesuwaniem bramki wtedy, gdy wyniki nie pasują do oczekiwań.

    Jak przeprowadzić walidację w siedem dni

    Dzień 1: zapisz użytkownika, sytuację i najważniejszą niewiadomą.

    Dzień 2: znajdź osoby, które naprawdę wykonują dany proces — nie przypadkowych znajomych.

    Dni 3–4: przeprowadź krótkie rozmowy o ostatnich zdarzeniach i obecnych sposobach działania.

    Dzień 5: przygotuj najprostszy ręczny test rezultatu.

    Dzień 6: obserwuj użycie. Nie tłumacz każdego kroku i zapisuj miejsca zatrzymania.

    Dzień 7: porównaj dowody z kryterium. Podejmij jedną z trzech decyzji: budujemy mały obieg, zmieniamy hipotezę albo zatrzymujemy temat.

    Kiedy przejść do pierwszej wersji

    Możesz zacząć opisywać pierwszą wersję, gdy widzisz powtarzalny problem, konkretną grupę użytkowników, istniejące zachowanie i jeden rezultat, za którym ludzie chcą wrócić.

    Wtedy przydaje się prosty brief aplikacji oraz decyzja, co naprawdę powinno znaleźć się w MVP.

    Nie musisz mieć pewności, że produkt odniesie sukces. Takiej pewności nie daje żadna metoda. Potrzebujesz wystarczająco dobrego dowodu, że następny mały krok nauczy Cię więcej niż kolejny tydzień myślenia.

    Walidacja nie odbiera pomysłowi energii. Zamienia energię w decyzję.