Budujemy dużo funkcji, ale trudno powiedzieć czy cokolwiek zmieniają

Seria o zarządzaniu produktami (1/4). Kolejny tekst: nie wiemy, czego naprawdę potrzebują klienci.

Pełny sprint, puste pytanie

Zespół zamyka sprint. Demo poszło gładko. Interesariusze kiwają głowami. W backlogu kolejne trzy epiki czekają na refinement. Wszystko wygląda zdrowo - aż ktoś zapyta: która z ostatnich dziesięciu funkcji faktycznie coś zmieniła dla klienta albo dla biznesu?

Cisza. Albo lista anegdot: „sprzedaż chwaliła”, „było w roadmapie”, „klient X o to prosił”. Sygnały mogą być prawdziwe, ale nie mówią nic o efekcie.

Widzieliśmy ten schemat w wielu organizacjach: delivery działa sprawniej, a niepewność o sens inwestycji i tak rośnie. Wytwarzanie przestało być wąskim gardłem. Wybór inwestycji zajmuje jego miejsce, tylko że nikt nie zbudował wokół niego procesu.

Fabryka, która raportuje zajętość

Gdy sukces mierzycie liczbą zamkniętych ticketów, roadmapą „zrealizowaną w 90%” albo velocity, organizacja uczy się optymalizować zajętość. Ludzie są zajęci. Kalendarze pełne. Produkt rośnie w szerz.

To klasyczny mechanizm feature factory: system nagradza dowóz, a postęp klienta żyje w innym arkuszu (często w finansach albo supportcie) i wraca dopiero przy budżecie.

Różnica między outputem a outcome’em nie jest akademicka. Opisujemy ją szerzej w output czy outcome. Tu wystarczy jedno rozróżnienie: dostarczyliście funkcję vs klient zrobił coś, czego wcześniej nie robił, albo zrobił to taniej / szybciej / rzadziej dzwoniąc na infolinię.

Bez drugiej części roadmapa to plan pracy zespołu, nie plan zmiany w świecie użytkownika.

Skąd bierze się iluzja postępu

Kilka typowych źródeł, które widzimy u klientów:

• Scope zastępuje cel. „Dowieźliśmy epik X” brzmi jak sukces, bo da się to policzyć. Wpływ na retencję, konwersję albo czas obsługi - już mniej.
• Opinie głośnych interesariuszy lądują w backlogu szybciej niż obserwacje z rozmów z użytkownikami. O tym, jak łatwo pomylić życzenia z potrzebami, piszemy w potrzeby klienta.
• Brak hipotezy przed buildem. Jeśli nie wiecie, czego się spodziewacie, po wdrożeniu nie macie czego sprawdzić - zostaje tylko „działa / nie działa technicznie”.
• Metryki procesu zamiast produktu. Czas cyklu i throughput mówią, jak szybko pracujecie. Nie mówią, czy warto było.

Gdy te cztery rzeczy działają naraz, kwartał wygląda zajęty, a zarząd nadal pyta: „dlaczego produkt nie rośnie?”.

Co sprawdzić w najbliższym miesiącu

Nie potrzebujecie od razu pełnego systemu OKR ani nowego narzędzia analitycznego. Zacznijcie od trzech ruchów na realnych rzeczach z backlogu.

1. Jedna metryka wyniku na inicjatywę. Przed startem epiku zapiszcie: jaki sygnał po 4-8 tygodniach od wdrożenia powie wam, że było warto? Użycie, czas zadania, spadek ticketów, konwersja w ścieżce - cokolwiek mierzalnego w waszym kontekście. Jeśli nie potraficie wskazać sygnału, to sygnał sam w sobie: budujecie w ciemno.

2. Przegląd „co zmieniło” zamiast samego „co dowieźliśmy”. Raz na miesiąc weźcie 5-7 ostatnich wdrożeń i odpowiedzcie szczerze: używane / ignorowane / szkodzące / nie wiadomo. „Nie wiadomo” też jest wynikiem - oznacza dziurę w obserwacji.

3. Prawo do niebudowania. Discovery ma sens dopiero wtedy, gdy ktoś może powiedzieć „tego nie robimy” na podstawie dowodów. Product discovery nie jest fazą przed projektem ani warsztatem kick-offowym. To ciągłe sprawdzanie problemu i rozwiązania zanim zaangażujecie pełny zespół na tygodnie.

Jeśli w organizacji discovery kończy się slajdem, a priorytety i tak wracają z sali zarządu, macie teatr - nie proces wyboru inwestycji.

Gdzie zwykle utkniecie

Najczęstszy opór nie brzmi „nie chcemy mierzyć efektu”. Brzmi „nie mamy danych”, „klientów trudno złapać”, „biznes już zdecydował”. Część z tego jest prawdziwa. Część to wygodna osłona przed odpowiedzialnością za wybór.

Wtedy pomaga zejść z poziomu całego portfolio na jeden konkretny problem klienta i sprawdzić go w małej skali - rozmowy, prototyp, eksperyment - zanim kolejny epik zajmie trzy sprinty. Na tym polega praca, którą ćwiczymy m.in. na Professional Product Discovery & Validation i w Product Re-Discovery.

Co dalej w serii

Dużo funkcji bez efektu rzadko jest wyłącznie problemem metryk. Często zaczyna się wcześniej: od tego, skąd bierzecie wiedzę o kliencie, jak powstaje roadmapa i kiedy (za późno) uczycie się, że rozwiązanie było nietrafione.

Dalej w serii: Nie wiemy, czego naprawdę potrzebują klienci · Roadmapa zmienia się co kilka tygodni · Za późno dowiadujemy się, że zbudowaliśmy niewłaściwe rozwiązanie