Product discovery: za co płacę i co otrzymam?

Product discovery to płatna praca nad decyzją: jaki problem warto rozwiązać, dla kogo, w jaki sposób i od czego zacząć. Jej użytecznym wynikiem jest dokument, który pomaga wybrać następny krok. Rozmowy, warsztaty i prototypy są środkami do uzyskania tej odpowiedzi.

Discovery może zakończyć się rekomendacją budowy aplikacji, integracji obecnych systemów, zakupu gotowego narzędzia albo zmiany procesu. Może też wskazać, że inwestycję należy odłożyć do czasu sprawdzenia kluczowego założenia. Taki rezultat jest wartościowy, jeśli jasno pokazuje przyczyny i warunki powrotu do pomysłu.

#Kiedy discovery ma sens

Warto rozważyć osobny etap analizy, gdy firma zna odczuwany problem, lecz nie potrafi jeszcze opisać rozwiązania. Różne osoby mogą inaczej rozumieć cel, a lista funkcji może wynikać głównie z przypuszczeń. Zdarza się również, że powodzenie projektu zależy od danych lub możliwości systemu zewnętrznego, których nikt nie sprawdził.

Przykładowe sygnały to: „chcemy zautomatyzować obsługę”, „potrzebujemy aplikacji dla klientów” albo „wszystko jest w arkuszach, trzeba to przepisać”. Każde z tych zdań otwiera kilka możliwych dróg.

Przy prostej stronie z ustaloną ofertą i jasnym zakresem wystarczy często krótki brief i rozmowa doprecyzowująca. Nie ma potrzeby dokładać rozbudowanego procesu badawczego do każdego landing page. Osobne discovery powinno odpowiadać rzeczywistej niepewności.

#Czym różni się od bezpłatnej rozmowy

Rozmowa kwalifikacyjna służy ustaleniu, czy wykonawca może pomóc i jaki rodzaj pracy będzie potrzebny. Nie powinna być przedstawiana jako gotowa analiza biznesu.

W płatnym etapie zespół poświęca czas na zebranie informacji, porównanie opcji i przygotowanie wyniku do wykorzystania przez klienta. Zakres trzeba ustalić przed rozpoczęciem: jakie pytania badamy, z kim rozmawiamy, jakie materiały analizujemy i co zostanie przekazane.

W GKD discovery traktujemy jako osobne zlecenie. Zakup analizy nie zobowiązuje do zamówienia implementacji. To ważne, bo rekomendacja powinna pozostać użyteczna także wtedy, gdy firma wybierze gotowe narzędzie albo odłoży budowę.

#Co powinno znaleźć się w rezultacie

Poniższa lista jest standardem, o który warto zapytać przy zamawianiu discovery. Konkretne elementy i głębokość prac trzeba potwierdzić w ofercie.

Makiety albo prototyp mogą być częścią wyniku, jeśli pomagają rozstrzygnąć pytanie. Nie każdy problem wymaga rysowania całej aplikacji. Czasem ważniejsze jest sprawdzenie możliwości integracji albo obserwacja pracy osoby, która będzie używała systemu.

#Przykład fragmentu wyniku discovery

Poniższy zapis jest ilustracyjny; nie opisuje klienta ani wykonanej analizy.

Sytuacja: firma serwisowa chce skrócić obsługę zgłoszeń. Informacje przychodzą kilkoma kanałami, a koordynator uzupełnia braki przed przekazaniem sprawy.

Hipoteza: głównym problemem jest niekompletność danych na wejściu. Nie znamy jeszcze udziału spraw wymagających ponownego kontaktu.

Następna weryfikacja: sprawdzić próbkę kolejnych zgłoszeń, oznaczyć brakujące informacje i zanotować czas uzupełniania. Przeprowadzić typowy przypadek w istniejącym narzędziu oraz zebrać ograniczenia technika.

Wstępne opcje: wspólny formularz i zasady obsługi; gotowy system zgłoszeń; integracja; własna aplikacja, jeśli wcześniejsze warianty nie spełnią wymaganych warunków.

Proponowany pierwszy zakres: rejestr przyjęcia, identyfikator sprawy, przypisanie odpowiedzialnej osoby i czytelny status. Rozbudowane raporty i portal klienta pozostają poza pierwszym etapem.

Przykładowe kryterium odbioru: po wysłaniu poprawnego zgłoszenia powstaje jedna sprawa z identyfikatorem. Ponowienie tego samego żądania nie tworzy duplikatu. Błąd zapisu jest widoczny dla osoby zgłaszającej i obsługi.

Taki zapis nie przesądza z góry o aplikacji. Umożliwia sprawdzenie wariantu i wskazuje, czego jeszcze nie wiemy. Właśnie tę przejrzystość warto kupować.

#Od czego zależą cena i czas

Koszt zależy między innymi od liczby procesów i rozmówców, dostępności danych, potrzeby badań z użytkownikami, wymaganego prototypu oraz zakresu weryfikacji technicznej. Przegląd odziedziczonego kodu może wymagać osobnego technical discovery.

Przed zamówieniem poproś o cenę, granice analizy, harmonogram i listę materiałów. Ustal też zasady dodatkowych pytań po przekazaniu wyniku. Cena samej implementacji powinna mieć opis założeń; discovery zmniejsza niepewność, ale nie usuwa wszystkich ryzyk przyszłej pracy.

Jeśli w trakcie ujawni się kluczowy brak danych, wynikiem może być plan ich zebrania. To powinno być opisane wraz z konsekwencją dla dalszego oszacowania, zamiast ukrywane w pozornie precyzyjnej wycenie.

#Co przygotować jako klient

Wyznacz osobę mogącą podejmować decyzje i zapewnij udział ludzi wykonujących opisywaną pracę. Przygotuj przykłady spraw, obecne formularze, listę narzędzi i ograniczenia budżetu. Dokumenty można anonimizować; do analizy sposobu pracy nie zawsze są potrzebne dane identyfikujące klientów.

Powiedz również, czego nie możesz zmienić: obowiązującego systemu, urządzeń, umowy z dostawcą albo momentu największego obciążenia zespołu. Te ograniczenia wpływają na rekomendację bardziej niż preferowana technologia.

#Jak ocenić, czy etap się udał

Po przeczytaniu wyniku powinieneś umieć wyjaśnić, co robisz dalej, dlaczego i jakie warunki mogą zmienić decyzję. Dokument powinien być zrozumiały także po spotkaniu i wskazywać, które ustalenia są potwierdzone, a które wymagają testu.

Jeśli zastanawiasz się nad oprogramowaniem, zacznij od porównania gotowego narzędzia, integracji i aplikacji dedykowanej. Następnie możesz omówić z GKD, czy zakres jest już wystarczająco jasny do wyceny implementacji, czy najpierw potrzebna jest osobna analiza.