Product Discovery
Większość produktowych porażek nie wynika z błędów w implementacji — wynika z budowania złej rzeczy. Product Discovery to systematyczny proces walidacji problemów i rozwiązań zanim angażujesz Engineering.
5 kluczowych technik Product Discovery
Każda technika odpowiada na inne pytanie i ma inne koszty. Customer Interview to fundament — reszta weryfikuje to co słyszysz w rozmowach.
Customer Interview
Głębokie zrozumienie problemów, potrzeb i zachowań użytkowników
Przed definiowaniem rozwiązania, przy wchodzeniu na nowy segment
45-60 min 1:1, pytania o przeszłe zachowania, minimum 5-10 per segment
Prototype Testing
Walidacja rozwiązania zanim zaangażuje Engineering
Gdy masz hipotezę rozwiązania i chcesz ją przetestować tanio
Low-fidelity Figma mockup lub papierowy prototyp, obserwuj jak użytkownik próbuje go używać
Smoke Test / Fake Door
Ilościowa walidacja popytu bez budowania feature
Gdy chcesz zmierzyć zainteresowanie przed inwestycją w development
Button/link do nieistniejącej funkcji, mierzysz CTR i intent. Informujesz użytkownika po kliknięciu
Contextual Inquiry
Obserwacja jak użytkownicy naprawdę wykonują zadanie w ich środowisku
Gdy chcesz zobaczyć realne zachowania, nie deklarowane
Obserwujesz użytkownika podczas pracy. Pytasz 'dlaczego to robisz' w trakcie, nie po
Opportunity Solution Tree
Strukturalne mapowanie problemów, możliwości i potencjalnych rozwiązań
Do organizowania insightów z Discovery i priorytetyzacji eksperymentów
Drzewo: Outcome (cel) -> Opportunities (problemy) -> Solutions -> Experiments (Teresa Torres framework)
Discovery vs. Delivery
Discovery i Delivery to dwa równoległe tory, nie sekwencyjne fazy. PM i Designer prowadzą Discovery 2-4 tygodnie przed Engineering — tak że Engineering zawsze buduje rzeczy już zwalidowane.
Często zadawane pytania
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.
Powiązane artykuły
Skontaktuj się z nami
Porozmawiajmy o Twoim projekcie. Bezpłatna wycena w ciągu 24 godzin.
Wyślij zapytanie
Telefon
+48 790 814 814
Pon-Pt: 9:00 - 18:00
adam@fotz.pl
Odpowiadamy w ciągu 24h
Adres rejestrowy
Poznańska 117/11
62-023 Kamionki · obsługa zdalna