FEATURE THINKING. DOSTARCZYLIŚCIE WSZYSTKO. ALE PRODUKT DALEJ NIE ZARABIA.
TWÓJ ZESPÓŁ BYŁ NAGRADZANY. KLIENCI TEGO NIE CZULI.
Feature factory (fabryka ficzerów) to organizacja, która mierzy sukces produktowy liczbą dostarczonych funkcjonalności. Nie postępem klienta ani wartością biznesową, tylko liczbą zamkniętych ticketów. To rzadko wynika ze złych nawyków Product Ownera. To system, który wewnątrz firmy działa świetnie, a dla produktu jest zabójczy.
TL;DR
Możesz mieć rekordowe velocity, zrealizowaną roadmapę i zadowolonych interesariuszy, a jednocześnie produkt, który nie zarabia. Feature thinking sprawia, że dostarczanie staje się celem samym w sobie. Postęp klienta zostaje 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 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 nie śledził go 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 to samo: 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ść, tylko 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 zwykle 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.
Nie chodzi o to, że te feature'y były głupie. Każdy z osobna miał sens w backlogu. Żaden nie odpowiadał jednak na pytanie: co blokuje klienta w momencie, kiedy najbardziej potrzebuje produktu? Tego pytania nikt nie zadał, bo w fabryce ficzerów zadawanie go nie należy do procesu. 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 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 wpływa na decyzje i premie. Drugi wychodzi raz na rok przy budżecie 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 gdy wychodzi to przy budżecie, nie przy sprint review. Wtedy okazuje się, że sukces mierzono w złej walucie.
Na następnym refinemencie, dla każdego itema 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, 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
Czym jest feature factory i feature thinking?
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.
Dlaczego feature thinking jest trudny do zauważenia od środka?
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ą.
Jak odróżnić feature od rozwiązania problemu klienta?
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.
Czy mierzenie przez postęp klienta jest możliwe w dużej organizacji?
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.
Co zrobić jeśli mój system oceny premiuje delivery?
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.