Continuous discovery: Klucz do podejmowania lepszych decyzji #EN80

TL;DR

Notatka z webinaru Teresy Torres „The What and Why of Continuous Discovery” z maja 2025

Continuous Discovery to proces cotygodniowych rozmów z klientami prowadzonych przez zespół budujący produkt, realizujący małe aktywności badawcze w celu osiągnięcia zamierzonego rezultatu biznesowego
Cotygodniowe interakcje pomagają przezwyciężyć „klątwę wiedzy” i umożliwiają współtworzenie produktu z klientami zamiast tylko walidacji gotowych pomysłów
Product Trio (PM, designer, developer) to minimalny zespół decyzyjny, który można elastycznie rozszerzać w zależności od potrzeb
Opportunity Solution Tree pomaga utrzymać skupienie na rezultacie biznesowym przy jednoczesnym adresowaniu potrzeb klientów
Testowanie założeń (zamiast gotowych rozwiązań) przyspiesza proces decyzyjny i pozwala uniknąć błędów związanych z przywiązaniem do jednego pomysłu
Zespoły powinny testować wiele rozwiązań dla tej samej możliwości, stosując podejście „porównaj i skontrastuj” zamiast decyzji „tak czy nie”
Continuous Discovery można wdrażać iteracyjnie, krok po kroku, zaczynając od pojedynczych nawyków i stopniowo dodając kolejne

Co to jest Continuous Discovery i dlaczego jest ważne?

Continuous Discovery to odpowiedź na dwa kluczowe trendy w rozwoju produktów. Pierwszy to przejście od cyklicznych wydań produktu do ciągłego dostarczania (continuous delivery). Jeśli zespoły ciągle wdrażają kod, muszą też ciągle podejmować decyzje o tym, co budować. Drugi trend to rosnące zrozumienie, że dobre decyzje produktowe wymagają włączenia klienta w proces.

Discovery to praca, którą wykonujemy, gdy podejmujemy decyzje o tym, co budować, w przeciwieństwie do Delivery, które jest pracą związaną z budowaniem, dostarczaniem i utrzymywaniem produktu. Każdy zespół zarówno decyduje, co budować, jak i buduje to.

Continuous Discovery pozwala przejść od projektowego myślenia (najpierw discovery, potem delivery) do zintegrowanego, ciągłego procesu, w którym discovery i delivery dzieją się jednocześnie.

Definicja Continuous Discovery

Teresa Torres definiuje Continuous Discovery jako „minimum cotygodniowe rozmowy z klientami prowadzone przez zespół budujący produkt, realizujący małe aktywności badawcze w celu osiągnięcia zamierzonego rezultatu.” Ta definicja zawiera kilka kluczowych elementów, które warto szczegółowo omówić.

Cotygodniowe rozmowy z klientami

Podejmujemy decyzje produktowe każdego dnia. Niektóre to duże decyzje strategiczne, jak wybór celów czy klientów, których chcemy obsługiwać. Inne to codzienne decyzje: jak nazwać przycisk, jak zaprojektować przepływ pracy, jakie dane powinien obsługiwać model danych.

Dlaczego cotygodniowe rozmowy są kluczowe:

Pomagają przezwyciężyć „klątwę wiedzy” – przypominają nam, że mamy wiedzę, której klienci nie mają
Pokazują różnicę między tym, co my wiemy, a co wiedzą klienci
Uczą nas podejmować decyzje z perspektywy klienta, a nie eksperta
Umożliwiają wcześniejsze otrzymywanie feedbacku (na etapie szkiców, a nie gotowych rozwiązań)
Otwierają podejście współtworzenia zamiast tylko walidacji gotowych pomysłów

Klątwa wiedzy to błąd poznawczy, który mówi, że w miarę zdobywania ekspertyzy w jakimś temacie, zapominamy jak to jest nie mieć tej ekspertyzy. W przypadku zespołów produktowych oznacza to, że spędzając cały dzień pracując nad produktem, znamy każdy zakamarek interfejsu i dokładnie wiemy, jak wykonać zadania – podczas gdy klienci tej wiedzy nie mają.

Prowadzone przez zespół budujący produkt

Kto powinien prowadzić discovery? Dla wielu z nas zaczyna się to od Product Trio. Product Trio to zwykle produkt manager, design lead i tech lead.

Product Trio i jego elastyczność:

Podstawowy skład: product manager, designer, tech lead
Można dodać dodatkowe role na stałe (np. data scientist przy produktach opartych na danych)
Można tymczasowo rozszerzyć na potrzeby konkretnej decyzji (np. product marketing manager do strategii go-to-market)
Kluczowa jest równowaga między jakością decyzji a szybkością ich podejmowania

Tradycyjne podejście, gdzie PM zbiera wymagania, designer projektuje, a programiści budują, wydaje się efektywne, ale w praktyce prowadzi do ciągłych rewizji i opóźnień. To, czego nauczyliśmy się, to że jest szybciej, skuteczniej, o wiele przyjemniej i budujemy lepsze rozwiązania, gdy te trzy role współpracują od samego początku.

Opportunity Solution Tree – kompleksowe narzędzie do zarządzania discovery

Opportunity Solution Tree to wizualizacja, która pomaga zespołom skupić się na rezultacie i utrzymać spójność podczas chaotycznej pracy odkrywania możliwości i rozwiązań.

Struktura Opportunity Solution Tree:

Na szczycie: rezultat (outcome) – reprezentuje potrzebę biznesową
W środku: możliwości (opportunities) – niezaspokojone potrzeby klientów, punkty bólu i pragnienia
Na dole: rozwiązania – propozycje adresujące wybrane możliwości

Outcomes vs Outputs – kluczowa zmiana perspektywy:

Output-focused: ustalony roadmap, konkretne funkcje w określonym terminie
Outcome-focused: metryka do poprawy lub cel do osiągnięcia, swoboda eksploracji najlepszego sposobu osiągnięcia rezultatu

Wizualizacja Opportunity Solution Tree utrzymuje zespół w skupieniu na zaspokajaniu potrzeby biznesowej (osiąganie rezultatu) i potrzeby klienta (adresowanie możliwości). To ważne rozróżnienie – rezultaty na szczycie drzewa reprezentują potrzeby biznesowe, zwykle wynikające z modelu przychodowego. Możliwości reprezentują potrzeby klienta.

Przestrzeń możliwości jest nieskończona – moglibyśmy spędzić resztę życia próbując adresować potrzeby klientów i nigdy nie skończylibyśmy. Dlatego filtrujemy przestrzeń możliwości, patrząc tylko na te, które mają potencjał napędzania naszego rezultatu. W ten sposób łączymy wartość dla klienta z wartością dla biznesu.

Rozwiązania i testowanie założeń

Wiele zespołów słyszy potrzebę klienta i przeskakuje do pierwszego pomysłu. Nawet jeśli wykonują właściwe aktywności discovery, formułują swoje discovery jako „czy mój pomysł jest dobry, czy nie?”

Problem z tym podejściem dotyczy podejmowania decyzji. Badacze decyzji nazywają to decyzją „czy tak, czy nie”. To podejście potęguje dwa główne błędy poznawcze:

Eskalacja zaangażowania – podobna do pułapki utopionych kosztów. Im więcej inwestujemy w pomysł, tym bardziej się z nim identyfikujemy i tym bardziej się w nim zakochujemy.
Confirmation bias – będziemy zauważać dowody sugerujące, że nasz pomysł jest niesamowity, i całkowicie przeoczymy dowody sugerujące, że nasz pomysł jest wadliwy.

Rozwiązaniem jest ustawienie decyzji „porównaj i skontrastuj”. Zamiast testować całe rozwiązania, rozbijamy je na leżące u ich podstaw założenia i testujemy te założenia. Jest to szybsze, ponieważ:

Niektóre założenia są wspólne dla wielu pomysłów – testując je, dowiadujemy się czegoś o wszystkich naszych pomysłach jednocześnie
Testowanie założeń jest szybsze niż testowanie całych rozwiązań – można je przeprowadzić w 1-2 dni
Możemy prowadzić wiele testów równolegle

Dzięki temu możemy rozpocząć tydzień w poniedziałek z docelową możliwością, wymyślić rozwiązania, zidentyfikować założenia, przeprowadzić serię testów założeń w ciągu tygodnia, a do piątku mieć pierwszy zestaw danych porównawczych. Jest to znacznie szybsze niż wykonanie całej pracy projektowej z góry, a następnie testowanie użyteczności na końcu.

Pięć kategorii założeń w rozwiązaniach produktowych

Zespoły produktowe zwykle robią założenia w pięciu kategoriach:

Założenia dotyczące atrakcyjności:
- Dlaczego myślimy, że nasi klienci chcą to rozwiązanie?
- Dlaczego sądzimy, że będą chcieli wykonać akcje niezbędne do uzyskania wartości?
Założenia dotyczące opłacalności:
- Czy powinniśmy to budować?
- Czy jest to dobre dla naszego biznesu?
- Dlaczego sądzimy, że zaadresuje możliwość w sposób, który napędzi nasz rezultat?
Założenia dotyczące wykonalności:
- Czy jest to możliwe?
- Czy możemy to zbudować?
- Czy mamy wymaganą wiedzę, umiejętności i zdolności?
- Czy wymagana technologia istnieje?
Założenia dotyczące użyteczności:
- Czy ludzie mogą to znaleźć?
- Czy rozumieją to?
- Czy są w stanie zrobić to, co muszą zrobić?
Założenia etyczne:
- Dane, które zbieramy – Czy przechowujemy je skutecznie? Czy jesteśmy transparentni?
- Docelowy klient – Kogo wybieramy do obsługi? Kogo możemy pomijać?
- Zrównoważony rozwój – Od jakich zasobów zależą nasze rozwiązania? Czy możemy ograniczyć nasz ślad?

Checklist: Jak prowadzić efektywne Continuous Discovery

1. Przygotowanie do Continuous Discovery

Zdefiniuj jasny biznesowy rezultat (outcome) dla zespołu
Ustal, kto tworzy twoje Product Trio (minimum: PM, designer, tech lead)
Zaplanuj regularne, cotygodniowe rozmowy z klientami
Przygotuj system automatyzacji rekrutacji klientów do wywiadów
Stwórz wizualną reprezentację Opportunity Solution Tree

2. Prowadzenie wywiadów z klientami

Zaplanuj minimum jeden wywiad tygodniowo
Koncentruj się na zbieraniu historii, a nie na testowaniu rozwiązań
Słuchaj potrzeb, punktów bólu i pragnień
Dokumentuj każdy wywiad w formie interview snapshot
Aktualizuj mapę przestrzeni możliwości po każdym wywiadzie

3. Prace nad rozwiązaniami

Wybierz docelową możliwość (target opportunity) do rozwiązania
Wygeneruj multiple rozwiązania dla tej samej możliwości
Rozbij każde rozwiązanie na leżące u jego podstaw założenia
Zidentyfikuj założenia wspólne dla wszystkich rozwiązań
Zidentyfikuj założenia unikalne dla każdego rozwiązania

4. Testowanie założeń

Zidentyfikuj założenia w pięciu kategoriach (atrakcyjność, opłacalność, wykonalność, użyteczność, etyka)
Zaprojektuj szybkie testy dla najważniejszych założeń
Przeprowadź testy w ciągu 1-2 dni
Zbierz dane porównawcze dla wszystkich rozwiązań
Zidentyfikuj faworyta na podstawie wyników testów

5. Iteracyjne wdrażanie Continuous Discovery

Zacznij od jednego nawyku discovery
Jeśli pracujesz w fabryce funkcji, zacznij od identyfikowania założeń
Jeśli możesz rozmawiać z klientami, zacznij od cotygodniowych wywiadów
Stopniowo zwiększaj częstotliwość interakcji z klientami
Dokumentuj i dziel się wnioskami z zespołem i interesariuszami

Jak zacząć stosować Continuous Discovery?

Dla tych, dla których ta metoda pracy wygląda zupełnie obco, Teresa Torres zaleca myślenie o tym jako o zbiorze nawyków i pracę nad jednym nawykiem naraz.

Porady dla różnych sytuacji wyjściowych:

Jeśli pracujesz w fabryce funkcji:

Zacznij od identyfikowania założeń – nawet bez testowania to poprawi jakość pomysłów
Gdy ten nawyk będzie silny, zacznij testować założenia
Następnie zacznij ustawiać decyzje „porównaj i skontrastuj” i rozważać więcej rozwiązań

Jeśli już rozmawiasz z klientami:

Pracuj nad nawykiem przeprowadzania wywiadów zorientowanych na historie
Rozwijaj umiejętność identyfikowania możliwości i mapowania przestrzeni możliwości
Zacznij budować Opportunity Solution Tree

Jeśli nigdy nie rozmawiałeś z klientami:

Znajdź pierwszego klienta do rozmowy
Z kwartalnych spotkań przejdź do miesięcznych
Z miesięcznych do dwutygodniowych
Z dwutygodniowych do cotygodniowych

Praktyczne wskazówki

Jak weryfikować, czy rozwiązanie jest gotowe do wdrożenia?

Jesteś gotowy do budowy pierwszej iteracji, gdy:

Jesteś pewien, że zidentyfikowałeś prawdziwą możliwość – słyszysz o niej w wywiadach wielokrotnie
Twoje testy założeń znajdują wyraźnego faworyta – jedno rozwiązanie jest znacznie lepsze od pozostałych
Masz wystarczające dane porównawcze, by podjąć decyzję

Główne czynniki, które bierzesz pod uwagę, to:

Czy masz więcej czasu na testowanie?
Czy masz wyraźnego faworyta?
Czy nadal uważasz, że możliwość jest ważna?
Jaka jest presja czasowa w organizacji?

Ten artykuł jest częścią serii notatek z wartościowych webinarów. Wszystkie koncepcje, definicje i porady pochodzą bezpośrednio z prezentacji Teresy Torres podczas webinaru „The What and Why of Continuous Discovery” w maju 2025 roku. To opracowanie służy jako notatka dla tych, którzy chcą przypomnieć sobie kluczowe elementy jej metodologii.