Co to jest product discovery - i dlaczego większość organizacji robi coś innego
Zbudowali dokładnie to, o co prosili. Nikt tego nie używa.
Lista wymagań, refinement, development, „działające oprogramowanie”. Biznes zadowolony, bo dostał scope. Użytkownicy mniej, bo problem nadal istnieje. Nikt nie zawinił; system nagradza dowóz, nie trafienie.
To nie jest product discovery. W wielu firmach właśnie to za discovery uchodzi - stąd seria o produkcie, strategii i decyzjach.
TL;DR
Discovery to ciągły proces: czy rozwiązujemy właściwy problem i czy rozwiązanie ma sens zanim zainwestujemy tygodnie buildu. Potrzebuje autonomii decyzyjnej, dostępu do klientów i prawa do zmiany kierunku. Duże organizacje rzadko spełniają te trzy warunki naraz.
Czym jest product discovery
Dwa pytania przed budowaniem:
- Czy to właściwy problem?
- Czy to rozwiązanie faktycznie pomaga?
Słowo klucz: ciągły. Nie „faza przed projektem”, nie jednorazowy warsztat UX. Równolegle do delivery - bo rynek, SEO i zachowania użytkowników też się zmieniają.
Teresa Torres (Continuous Discovery Habits) opisuje to jako regularny kontakt z klientami i coraz lepsze decyzje produktowe, nie jako raport raz na kwartał.
Czym discovery nie jest
- Zbieranie wymagań - zakłada, że klient wie, czego chce.
- Jednorazowy research - snapshot, nie pętla uczenia.
- Refinement backlogu - porządkuje to, co już „wiemy, że robimy”.
- Demo na końcu cyklu - feedback za późno; discovery działa przed pełnym zaangażowaniem zespołu.
Trzy warunki organizacyjne
Autonomia - ktoś musi móc powiedzieć „nie budujemy tego” na podstawie dowodów, bez trzymiesięcznego komitetu.
Dostęp do użytkowników - bezpośrednio, regularnie; nie tylko przez ankiety i pośredników.
Przyzwolenie na zmianę planu - roczny scope zamrożony z góry zabija sens badań.
Teatr discovery vs prawdziwe discovery
Teatr: zatrudniony researcher, design thinking na kick-offie, etap „discovery” w PowerPoincie - a priorytety nadal z sali zarządu.
Prawdziwe: rozmowy co tydzień, priorytety się zmieniają, coś wypada z planu, bo hipoteza padła. Ostatni test: kiedy discovery zatrzymało build?
Krótki test
Zapytaj osobno product, biznes, delivery i management:
Jaki był ostatni przypadek, gdy discovery zatrzymało lub zmieniło coś, co miało być zbudowane?
Brak wspólnej odpowiedzi oznacza, że discovery nie działa, niezależnie od nazwy procesu.
FAQ
Czy discovery to część Scruma?
Scrum opisuje backlog i odpowiedzialność za wartość, nie sam proces odkrywania. Discovery jest komplementarne - można robić jedno bez drugiego (choć ryzykownie).
Kto za to odpowiada?
Zwykle product owner / product manager, ale nie solo - w „product trio” dev i UX/design mają wkład w to, co możliwe i co sensowne.
A poza software?
Zasady działają wszędzie, gdzie tworzysz coś dla kogoś innego - także w contentcie i SEO, jeśli traktujesz artykuły jak hipotezy (temat, intencja, dane), a nie jak „2500 słów na frazę”.
Co dalej
- Backlog to plan czy założenia?
- Feature factory
- Discovery w dużych organizacjach
- Product Re-Discovery - jak pracujemy z firmami
Źródła: Product Talk, SVPG - product discovery.
Chcesz sprawdzić, co blokuje discovery u Ciebie? Porozmawiajmy.