Za późno dowiadujemy się, że zbudowaliśmy niewłaściwe rozwiązanie

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

Feedback w najdroższym momencie

Projekt trwał dwa kwartały. Scope „prawie domknięty”. UAT, poprawki, go-live. Potem pierwsze tygodnie u klientów: niska adopcja, obejścia, eskalacje, zdanie „to nie tak miało działać”. Zespół nie jest zły. Proces też wyglądał porządnie. Uczycie się dopiero wtedy, gdy koszt zmiany jest najwyższy.

Widzieliśmy warianty tej historii przy redesignach, integracjach i „strategicznym” module, który miał odblokować sprzedaż. Wspólny wzorzec: decyzje o problemie i rozwiązaniu zapadły wcześnie, a kontakt z rzeczywistością użytkownika - późno. Im dalej w projekt, tym droższa poprawka: więcej kodu, więcej zależności, więcej obietnic złożonych na zewnątrz.

Dlaczego uczenie się spóźnia

Kilka mechanizmów regularnie się składa:

• Założenia traktowane jak fakty. „Wiemy, czego chce klient”, bo ktoś z biznesu tak powiedział na kick-offie. Bez sprawdzenia w potrzebach klienta założenie żyje do premiery.
• Big bang zamiast przyrostów uczących. Duży release ma sens techniczny czasem. Jako jedyny moment walidacji wartości - prawie nigdy.
• Demo interesariuszom ≠ test z użytkownikami. Kiwnięcie głową na sali nie mówi, czy ktoś w codziennej pracy wybierze to rozwiązanie.
• Roadmapa obiecuje datę przed hipotezą. O niestabilnej liście życzeń pisaliśmy w trzecim tekście. Tu skutek jest inny: data blokuje eksperyment, bo „nie ma czasu na discovery, bo commit do klienta”.

W tle często działa też feature factory: sukcesem jest dowiezienie zakresu. Pytanie, czy zakres rozwiązuje właściwy problem, wraca po fakcie - albo przy budżecie.

Koszt opóźnionego „nie”

W discovery najcenniejszy wynik bywa negatywny: tego nie budujemy albo budujemy inaczej. Im wcześniej padnie, tym taniej.

Porównajcie dwa scenariusze na tym samym pomyśle:

1. Dwa tygodnie rozmów, szkic przepływu, test z kilkoma użytkownikami, decyzja „to nie trafia w ich zadanie” - koszt: czas kilku osób, zero (albo prawie zero) produkcji.
2. Cztery miesiące developmentu, integracje, migracja, szkolenia - i ta sama decyzja po go-live.

Różnica nie leży w inteligencji zespołu. Leży w momencie kontaktu z dowodem. Product discovery istnieje po to, żeby scenariusz 1 był domyślny, a nie luksusem „gdy jest czas”.

Output bez outcome’u, o którym piszemy w output czy outcome, to często właśnie skutek spóźnionego uczenia: dowieźliście dużo, a zmiana u klienta = zero.

Jak przesunąć uczenie się w lewo

Nie musicie zamieniać firmy w laboratorium. Wystarczy kilka praktyk, które da się włożyć w istniejący rytm.

Zatrzymajcie się na problemie. Zanim refinement rozbije rozwiązanie na story, zapiszcie: kto, w jakiej sytuacji, jaki ból, skąd wiecie. Jeśli źródłem jest wyłącznie „prośba z dealu”, wróćcie do drugiego tekstu serii.

Tanio sprawdźcie rozwiązanie. Prototyp klikany, makieta w narzędziu, ręczny proces obsługiwany przez zespół, ograniczenie do jednego segmentu klientów. Pytanie brzmi: co musimy zobaczyć, żeby iść dalej / zatrzymać się? - nie „jak dowieźć MVP w pełnym stacku”.

Wczesny dostęp zamiast wielkiego dnia D. Jeśli da się wypuścić cienki pion wartości do małej grupy, zróbcie to. Feedback z tygodnia u prawdziwych użytkowników bije trzy miesiące spekulacji na syncach.

Metryka wyniku ustalona z góry. Jak w pierwszym tekście: wiecie, czego szukacie po wdrożeniu. Wtedy „niewłaściwe rozwiązanie” da się zauważyć po tygodniach, nie po roku plotek z rynku.

Prawo do stopu. Discovery bez możliwości zmiany kierunku to research do szuflady. Ktoś musi móc powiedzieć „nie idziemy w to” bez trzymiesięcznego komitetu - inaczej i tak dobijecie do drogiego końca.

Chaos, w którym nikt nie wie, na jakiej podstawie padają decyzje, opisujemy w gdy decyzje produktowe zamieniają się w chaos. Spóźnione uczenie jest jedną z jego droższych odmian.

Gdy produkt już „jest”, a kierunek się rozjechał

Czasem nie chodzi o jeden epik, tylko o lata dokładania funkcji bez powrotu do problemu klienta. Wtedy pojedynczy eksperyment nie wystarczy - potrzebujecie świadomego zejścia do założeń produktu. Temu służą m.in. Product Re-Discovery i praktyka z Professional Product Discovery & Validation.

Domknięcie serii

Cztery objawy, jeden wspólny rdzeń:

1. Dużo funkcji, słaby dowód efektu.
2. Słaba wiedza o potrzebach.
3. Roadmapa jako skrzynka życzeń.
4. Uczenie się po wdrożeniu.

„Więcej agile” albo kolejne narzędzie do roadmapy same z siebie tego nie domkną. Pomaga wcześniejszy kontakt z problemem i wynikiem, zanim zespół spędzi miesiące na kierunku, którego nie da się już tanio odkręcić.

Cała seria: Budujemy dużo funkcji, mało efektu · Nie wiemy, czego potrzebują klienci · Roadmapa zmienia się co kilka tygodni