Nie wiemy, czego naprawdę potrzebują nasi klienci

Seria o zarządzaniu produktami (2/4). Poprzedni tekst: dużo funkcji, mało efektu. Kolejny: roadmapa zmienia się co kilka tygodni.

„Klient o to prosił” to jeszcze nie potrzeba

W backlogu leży funkcja z komentarzem: „prośba od klienta premium”. Albo z ticketu supportu. Albo z warsztatu sprzedażowego. Brzmi wiarygodnie. Często jest nawet pilna politycznie.

Problem zaczyna się, gdy źródło prośby zastępuje zrozumienie problemu. Nikt nie sprawdził, w jakiej sytuacji klient to mówi, co próbuje zrobić, czego już próbował i jak często ten ból wraca. Zespół dostaje rozwiązanie w przebraniu wymagania i zaczyna je szacować.

Widzieliśmy to wielokrotnie: organizacje mają kanały feedbacku (ankiety, NPS, ticketystem, „voice of customer”), a jednocześnie Product Ownerzy przyznają wprost, że nie potrafią opisać trzech najważniejszych zadań klienta w produkcie. Kanały zbierają hałas. Potrzeby wymagają interpretacji.

O tym, jak łatwo pomylić życzenie z potrzebą, piszemy w potrzeby klienta. Tu skupiamy się na skutku: decyzje produktowe oparte na opiniach, zgłoszeniach i przeczućiach zamiast na systematycznym poznawaniu.

Skąd naprawdę bierzecie decyzje

Zróbcie mały audit na ostatnich 10 rzeczach, które weszły do developmentu. Przy każdej zapiszcie główne źródło:

• opinia interesariusza / sprzedaż / zarząd,
• zgłoszenie supportu lub jedno spotkanie z klientem,
• przeczucie zespołu („wydaje nam się, że…”),
• obserwacja zachowania (analityka, sesje, testy),
• seria rozmów z użytkownikami wokół jednego problemu.

Jeśli większość wpisów ląduje w pierwszych trzech wierszach, nie macie luki w „empatii”. Macie lukę w procesie uczenia się. Delivery może być świetny. Wejście do backlogu jest zgadywaniem z dobrymi intencjami.

To też wyjaśnia, dlaczego po kwartale trudno powiedzieć, czy funkcje cokolwiek zmieniły - o czym w pierwszym tekście serii. Bez jasnego problemu nie ma jasnego wyniku do sprawdzenia.

Discovery to nie faza przed projektem

W wielu firmach „discovery” oznacza kick-off, warsztat persona, czasem research na start inicjatywy. Potem zespół znika w delivery na miesiące. Feedback wraca przy demo albo po release.

Product discovery w praktycznym sensie wygląda inaczej: regularne sprawdzanie, czy rozwiązujecie właściwy problem i czy proponowane rozwiązanie ma sens, zanim pełny build pochłonie tygodnie. Teresa Torres opisuje to jako nawyk: kontakt z klientami i coraz lepsze decyzje, nie raport raz na kwartał.

Warunki organizacyjne są proste do wypisania i trudne do utrzymania:

1. Dostęp do użytkowników - bezpośrednio, nie tylko przez pośredników i ankiety.
2. Autonomia - ktoś może zatrzymać lub zmienić kierunek na podstawie dowodów.
3. Prawo do zmiany planu - zamrożony roczny scope zabija sens badań.

Bez tych trzech discovery staje się teatrem: ładne artefakty, te same priorytety co przed warsztatem.

Co robić zamiast kolejnej ankiety

Nie musicie nagle zatrudniać działu researchu. Potrzebujecie rytmu, który da się utrzymać przy normalnym obciążeniu.

Rozmowy wokół jednego problemu. Zamiast „porozmawiajmy o produkcie”, wybierzcie jedną sytuację klienta (np. rozliczenie, onboarding, reklamacja) i zróbcie 5-8 krótkich rozmów w dwa tygodnie. Szukacie wzorca w zachowaniu i kontekście, nie głosowania na funkcje.

Obserwacja obok opinii. Co ludzie robią w produkcie i w procesach wokół niego? Gdzie omijają UI? Gdzie dzwonią, zamiast kliknąć? Opinia bez obserwacji łatwo myli.

Hipoteza przed rozwiązaniem. Zanim refinement zamieni pomysł w story, zapiszcie: jaki problem, dla kogo, skąd wiemy, jak sprawdzimy. Jeśli nie umiecie tego w trzech zdaniach, refinement porządkuje zgadywanie.

Mały test rozwiązania. Szkic, prototyp, fake door, ręczny proces „za kulisami” - cokolwiek tańszego niż pełny epik. Szukacie wczesnego sygnału, że kierunek wymaga korekty, zanim refinement zamieni domysł w trzy sprinty.

Te praktyki ćwiczysz m.in. na Professional Product Discovery & Validation. Gdy produkt już „jest”, a wiedza o kliencie rozjechała się z rynkiem, sens ma też Product Re-Discovery.

Co się dzieje, gdy tego nie robicie

Backlog puchnie od życzeń. Roadmapa staje się listą interesariuszy. Zespół buduje szybko i późno dowiaduje się, że rozwiązał zły problem. Chaos decyzyjny, który opisujemy w gdy decyzje produktowe zamieniają się w chaos, często zaczyna się właśnie tu: od braku wspólnej, aktualnej wiedzy o potrzebach.

Następny tekst w serii idzie o krok dalej: co się dzieje z roadmapą, gdy nie jest narzędziem strategii, tylko skrzynką na życzenia.

Dalej w serii: Roadmapa zmienia się co kilka tygodni · Za późno dowiadujemy się, że zbudowaliśmy niewłaściwe rozwiązanie · Budujemy dużo funkcji, mało efektu