Product Discovery

Co to jest Product Discovery?

Product Discovery to proces badania i walidacji problemów użytkowników, przed tym zanim zaczniesz budować rozwiązanie. Celem jest odpowiedź na pytania: Czy problem jest realny i powszechny? Czy użytkownicy naprawdę go doświadczają? Czy nasze proponowane rozwiązanie rozwiązuje problem? Czy użytkownicy za to zapłacą? Product Discovery jest przeciwieństwem 'build it and they will come' — firmy które pomijają discovery, budują produkty których nikt nie używa. Termin spopularyzowany przez Marty'ego Cagana (SVPG) i Teresa Torres. Dobry Discovery zmniejsza ryzyko budowania złego produktu.

Jakie techniki stosuje się w Product Discovery?

Techniki Product Discovery: Customer Interviews — rozmowy z użytkownikami o ich problemach, nie o Twoim produkcie. Pytaj o przeszłe zachowania, nie hipotetyczne. Observation / Contextual Inquiry — obserwacja jak użytkownicy naprawdę wykonują zadanie (nie jak myślą że je wykonują). Survey — ilościowe badanie skali problemu. Lepsze do walidacji niż do discovery. Prototype Testing — low-fidelity prototype (Figma, papier) pokazywany użytkownikom przed budowaniem. Smoke Test / Fake Door Test — landing page proponowanego feature z możliwością 'zapisania się'. Mierzysz zainteresowanie bez budowania. Opportunity Solution Tree (Teresa Torres) — strukturalny sposób łączenia problemów użytkowników z potencjalnymi rozwiązaniami.

Czym różni się Discovery od Delivery?

Discovery vs. Delivery: Discovery to faza eksploracji — rozumiesz problem, generujesz i testujesz rozwiązania zanim je zbudujesz. Delivery to faza produkcji — budujesz, testujesz technicznie i releasujesz. Marty Cagan (SVPG) wyróżnia dwa równoległe track'i: Discovery Track — PM i Designer ciągle pracują 2-4 tygodnie przed Delivery. Delivery Track — Engineering buduje i releasuje co zostało zwalidowane w Discovery. Najczęstszy błąd: firmy robią tylko Delivery — przeskakują od feature request do implementacji bez Discovery. Efekt: wysoka velocity, ale budują złe rzeczy. Good Discovery nie wymaga miesięcy — ciągłe małe eksperymenty są lepsze niż wielki upfront research.

Jak przeprowadzić dobry wywiad z klientem w Discovery?

Discovery Interview — best practices: Cel: zrozumieć problem, nie walidować swoje rozwiązanie. Pytaj o przeszłość: 'Opowiedz mi o ostatnim razie gdy robiłeś X' zamiast 'Czy chciałbyś feature Y?'. Nie zadawaj leading questions: 'Czy zirytowałoby cię gdyby...' sugeruje odpowiedź. Szukaj behawiorów, nie opinii: co ludzie robią jest ważniejsze niż co mówią że chcą. 5 Whys — drąż w głąb: gdy klient powie 'chcę X', pytaj 'dlaczego X jest ważne?' aż dotrzesz do prawdziwego problemu. Nagrywaj za zgodą — jest ciężko notować i aktywnie słuchać jednocześnie. Minimum 5-10 wywiadów per segment — szukaj wzorców, nie anegdot. Unikaj: pytań o funkcjonalności, pytań o cenę, grupy fokusowej (social dynamics zniekształcają odpowiedzi).

Co to jest Continuous Discovery?

Continuous Discovery (Teresa Torres) to podejście w którym Product Team przeprowadza regularne rozmowy z użytkownikami co tydzień — zamiast dużego jednorazowego badania co kwartał. Zasady Continuous Discovery: Co najmniej jeden wywiad tygodniowo z użytkownikami/klientami. PM, Designer i Engineer rozmawiają z klientami razem. Opportunity Solution Tree jako narzędzie do strukturyzowania insightów. Małe, szybkie eksperymenty zamiast dużych badań. Ciągłe testowanie assumption zamiast czekania na 'wystarczająco dużo danych'. Korzyści: szybszy feedback loop, lepszy product intuition całego teamu, mniejsze ryzyko dużych błędnych decyzji, kultura budowana na dowodach a nie opiniach.

Wyślij zapytanie