TWÓJ ZESPÓŁ BYŁ NAGRADZANY. KLIENCI TEGO NIE CZULI.
Feature factory (fabryka ficzerów) – to określenie na organizację, która mierzy sukces produktowy liczbą dostarczonych funkcjonalności. Nie postępem klienta ani wartością biznesową. Lecz liczbą zamkniętych ticketów. To nie jest efekt złych nawyków Product Ownera. To system, który działa świetnie wewnątrz firmy. A dla produktu jest zabójczy.
TL;DR
Możesz mieć rekordowe velocity, zrealizowaną roadmapę i zadowolonych interesariuszy, i jednocześnie produkt, który nie zarabia. Feature thinking sprawia, że dostarczanie staje się celem samym w sobie. Postęp klienta zostaje gdzieś z boku.
KONIEC ROKU. NAGRODA. ZDJĘCIE DO INTRANETU.
Roadmapa zrealizowana w 94%, velocity rekordowe przez trzy kwartały, zero poślizgów. Zespół dostał wyróżnienie na corocznej konferencji. PO/PM na scenie.
Trzy miesiące później ktoś z finansów pokazuje slajd na spotkaniu zarządu. Koszty utrzymania produktu rosną trzeci rok z rzędu. Przychód z produktu stoi. Marża spada.
CFO zadaje w końcu to pytanie: jak długo jeszcze chcemy dokładać do tego produktu?
Cisza.
DWIE LICZBY, KTÓRE NIGDY NIE SPOTKAŁY SIĘ W JEDNYM ARKUSZU.
Organizacja miała dwa równolegle równolegle działające systemy pomiaru.
Jeden mierzył delivery. Był widoczny – w dashboardach, na sprintach, w wynikach oceny rocznej. Dawał jasne odpowiedzi: ile dostarczyliśmy, na czas, zgodnie z planem.
Drugi mierzył wartość. Żył w Excelu działu finansów, oderwany od cykli sprintowych i spotkań roadmapowych. Nikt z zespołu produktowego go nie śledził na co dzień.
Przez dwa lata nikt nie zestawił tych liczb obok siebie. Nikt tego nie ukrywał. Widziałem ten schemat w organizacjach z różnych branż – banki, ubezpieczenia, retail. Za każdym razem ta sama sytuacja: system mierzący delivery i system mierzący wartość żyją w różnych pokojach i spotykają się raz w roku przy budżecie. W fabryce ficzerów dostarczenie jest sukcesem samym w sobie. Pytanie „czy klient zrobił postęp?” nie pada, bo padać nie musi. Mamy dowód, że pracowaliśmy: zamknięte tickety.
Tyle, że zamknięte tickety to nie wartość. To potwierdzenie, że fabryka działa. Wagony z budżetem wjeżdżają do środka, wyjeżdżają feature’y. Nikt nie liczy ile z tych feature’ów klient w ogóle zauważył.
JEDNO ROZRÓŻNIENIE
Feature jest widoczny. Postęp klienta – nie.
Klient banku nie rozpoznaje transakcji na koncie. Jego zadanie: znaleźć ją, zrozumieć skąd pochodzi, zakwestionować, bez dzwonienia na infolinię.
Zespół dostarczył w tym kwartale: filtr dat w historii transakcji, eksport do PDF i nową ikonografię kategorii wydatków.
Trzy feature’y. Sprint zamknięty. Velocity bez zarzutu.
Klient nadal dzwoni. Feature gotowy a zadanie klienta niewykonane.
I nie chodzi o to, że te feature’y były głupie. Każdy z osobna miał sens w backlogu. Chodzi o to, że żaden nie odpowiadał na pytanie: co blokuje klienta w tym momencie, kiedy najbardziej potrzebuje produktu? Tego pytania nikt nie zadał, bo zadawanie go nie jest częścią procesu w fabryce ficzerów. Feature thinking nie pyta o postęp klienta. Pyta o następny item do zamknięcia.
CO FEATURE FACTORY ZMIENIA W ROLI PRODUCT OWNERA
Jeśli Twoja organizacja nagradza delivery, będziesz optymalizował delivery. To jest racjonalne zachowanie, i właśnie dlatego jest tak niebezpieczne.
Pytanie brzmi: kto w Twojej organizacji mierzy postęp klienta? I czy ta liczba trafia na te same spotkania co velocity i burn-down?
Jeśli nie, masz dwa równoległe systemy. Jeden z nich wpływa na decyzje i premie. Drugi wychodzi raz na rok przy okazji budżetu i powoduje konsternację.
Różnica między Product Ownerem, który dostarcza, a Product Ownerem, który buduje wartość, sprowadza się do jednego: co uznajesz za dowód, że feature działa.
Być nagrodzonym za pracę, która nic nie zmieniła dla klienta, to jedno z trudniejszych doświadczeń w tej roli. Szczególnie, kiedy wychodzi to przy budżecie, nie przy sprint review. Wtedy okazuje się, że sukces był mierzony w złej walucie.
Na następnym refinemencie, dla każdego item’a z backlogu, zadaj jedno pytanie. Jaki problem klienta to posuwa do przodu? Nie musisz zmieniać procesu ani narzędzi. Wystarczy to pytanie. Odpowiedź – albo jej brak – powie Ci więcej o kondycji product backlogu niż velocity za ostatni kwartał.
PYTANIE, KTÓRE WARTO ZABRAĆ ZE SOBĄ
Jaką ostatnią rzecz dostarczyłeś, po której klient przestał robić coś, co wcześniej było dla niego trudne?
Jeśli to pytanie jest trudne, to kolejne jest jeszcze trudniejsze. Skąd brać wiedzę, żeby budować lepiej? Tu zaczyna się rozmowa o discovery, i tam zaczyna się kolejny problem.
Jeśli chcesz zacząć mierzyć produkt przez postęp klienta, a nie przez liczbę zamkniętych ticketów. Porozmawiajmy.
FAQ
Feature factory to organizacja, która mierzy sukces produktu liczbą dostarczonych funkcjonalności. Feature thinking to mentalność, która ten system napędza. Sukces to zamknięty ticket, nie postęp klienta. Fabryka ficzerów działa sprawnie. Tylko nie wiadomo dla kogo produkuje.
Bo przez długi czas daje dobre wyniki wewnątrz organizacji. Roadmapa się realizuje, interesariusze są zadowoleni, zespół ma co pokazać. Rachunek przychodzi z opóźnieniem, kiedy okazuje się, że klienci nie używają połowy tego, co zbudowałeś, albo kiedy finanse nie spinają się z roadmapą.
Zadaj jedno pytanie: do jakiego zadania klienta ten feature się przyczynia i skąd będziemy wiedzieć, że pomógł? Jeśli nie ma konkretnej odpowiedzi, masz feature uzasadniony wewnętrzną logiką, nie potrzebą klienta.
Tak, ale wymaga zdefiniowania, co „postęp klienta” znaczy dla Twojego produktu, zanim zaczniesz cokolwiek budować. Większość organizacji tego nie zrobiła. Dlatego mierzy to, co łatwe.
Systemu oceny nie zmienisz od razu. Możesz zacząć od jednego pytania na każdym refinemencie: jakie zadanie klienta ten item posuwa do przodu? Nie wymaga zmiany procesu. Wymaga zmiany pytania. I odwagi, żeby nie mieć na nie odpowiedzi.