Product discovery

Jedno i drugie, zależnie od źródła. Instytucje, takie jak Nielsen Norman Group i brytyjski GOV.UK, opisują discovery jako etap na początku projektu, w którym bada się problem, a rozwiązań zwykle się jeszcze nie buduje. Praktycy produktowi, Marty Cagan i Teresa Torres, zaliczają do discovery także sprawdzanie rozwiązań i opisują je jako pracę, która trwa przez cały czas życia produktu.

Na ostaf.in słowo discovery występuje w znaczeniu wąskim: to droga dla sytuacji, w której problem nie jest jeszcze potwierdzony. Sprawdzanie rozwiązania na działającej wersji nazywa się tam walidacją na PoC. W znaczeniu szerokim oba kroki są częścią discovery.

W najstarszym tekście, jaki udało się znaleźć, Marty Cagan w 2007 r. proponuje tę nazwę w miejsce etapu, który branża nazywała wtedy wymaganiami i projektowaniem. Chciał podkreślić, że są dwie rzeczy do odkrycia: czy są klienci, którzy tego chcą, i jakie rozwiązanie będzie dla nich użyteczne i wykonalne. Pisał też, że tego procesu nie da się zaplanować jak budowy domu.

• 2012. Cagan opisuje dual-track agile: jedna ścieżka dostarcza sprawdzone pomysły, druga oprogramowanie. Kilka tygodni później proponuje discovery ciągłe zamiast osobnej fazy. Źródłem modelu dwóch ścieżek był według Jeffa Pattona artykuł Desirée Sy z 2007 r.
• 2016. Cagan opisuje discovery sprint, czyli tygodniowy blok pracy nad jednym dużym problemem albo ryzykiem, polecany zespołom, które uczą się discovery, i przy zastoju.
• 2017. Drugie wydanie książki "Inspired" z czterema ryzykami produktu.
• 2021. Teresa Torres wydaje "Continuous Discovery Habits" i opisuje discovery jako cotygodniowy kontakt z klientami prowadzony przez zespół, który buduje produkt.
• 2026. Cagan pisze, że koszt budowy spadł tak bardzo, że wąskim gardłem jest znalezienie rozwiązania wartego budowy.

Discovery odpowiada na pytanie, co warto zbudować, a delivery na pytanie, jak zbudować to tak, żeby klient mógł na tym polegać. Cagan, za Jeffem Pattonem, opisuje to jako budowanie po to, żeby się uczyć, i budowanie po to, żeby zarabiać. Obie rzeczy robi ten sam zespół, często w tym samym tygodniu.

Jeff Gothelf zwraca uwagę na pułapkę: discovery prowadzone dużo wcześniej niż budowa albo przez inny zespół to wodospad pod inną nazwą, bo wiedza zdąży się zestarzeć, zanim ktoś zacznie z niej korzystać.

Marty Cagan wymienia cztery ryzyka produktu. Discovery ma rozstrzygnąć każde z nich, zanim zespół zbuduje wersję produkcyjną. Ryzyko opłacalności obejmuje więcej niż rentowność: także kanał sprzedaży, umowy z partnerami, prawo, koszt pozyskania klienta i spójność z marką.

Teresa Torres dzieli założenia do sprawdzenia na pięć kategorii, podobnych do ryzyk Cagana, z dodatkową kategorią etyki, i porządkuje pracę w drzewo szans i rozwiązań: na górze wynik, który zespół chce osiągnąć, pod nim potrzeby i problemy klientów, pod nimi pomysły na rozwiązania i testy założeń.

Badania UX są jedną z metod discovery, a zbieranie wymagań zakłada, że ktoś już wie, co ma powstać. Discovery kończy się decyzją o produkcie i obejmuje też pytania, na które nie odpowie użytkownik: czy da się to zbudować i czy rozwiązanie działa dla firmy.

W ofertach firm budujących oprogramowanie "faza discovery" oznacza często zebranie wymagań, wycenę i harmonogram przed developmentem. To potrzebny etap, ale inny niż discovery w rozumieniu Cagana: kończy się planem budowy, a nie decyzją, czy budować. Zanim zamówisz taką fazę, zapytaj, czy jej wynikiem może być rekomendacja, żeby nie budować.

Jako osobny etap zwykle kilka tygodni: GOV.UK podaje około 4–8 tygodni i zaznacza, że krócej trwa, gdy o problemie dużo już wiadomo. Cagan opisuje też tygodniowy discovery sprint na jeden duży problem. W zespołach, które rozwijają działający produkt, discovery nie ma końca i polega na co najmniej cotygodniowym kontakcie z klientami.

Wynikiem jest decyzja poparta dowodami. Jeff Patton opisuje trzy możliwe zakończenia każdej pętli discovery: budujemy, porzucamy pomysł albo uczymy się dalej. Do decyzji dochodzą zwykle opis problemu i klienta, lista sprawdzonych i obalonych założeń oraz wskazanie, co sprawdzić w następnym kroku. Nielsen Norman Group zaznacza, że wynikiem może być też decyzja o zatrzymaniu projektu.

Po tym, że wnioski niczego nie mogą zmienić. Tim Herbig nazywa to alibi-discovery: zespół rozwija pomysł narzucony z góry, który i tak trafi do realizacji. Rozpoznaje się je po tym, że pracę zaczyna sesja wymyślania rozwiązań. Cagan pisał o tym już w 2007 r.: rozmowy z użytkownikami, prototypy i testy nic nie dają, jeśli zespół nie zmienia kursu na podstawie tego, czego się dowiedział.

Gdy problem jest dobrze znany z rozmów z klientami, a niepewne jest tylko rozwiązanie. Wtedy szybciej sprawdzi je działający prototyp w rękach pierwszych użytkowników. Warunek jest jeden: problem trzeba znać z rozmów, nie z własnych założeń. Od kiedy działający prototyp da się zbudować w tygodnie zamiast miesięcy (vibe coding), pokusa pominięcia tego kroku jest większa.