Nasza roadmapa zmienia się co kilka tygodni

Seria o zarządzaniu produktami (3/4). Poprzedni tekst: nie wiemy, czego potrzebują klienci. Kolejny: za późno dowiadujemy się, że zbudowaliśmy niewłaściwe rozwiązanie.

Plan, który nie przeżywa miesiąca

Q2 zaczęło się od trzech priorytetów. Po dwóch tygodniach doszedł „pilny” temat z zarządu. Potem sprzedaż wciągnęła integrację dla dużego dealu. Support wypchnął poprawki z eskalacji. Na review roadmapy ktoś pyta, co zostało z pierwotnego planu, i lista wygląda jak inny produkt.

Zmiana kierunku sama w sobie nie jest błędem. Rynek się rusza, uczycie się, hipotezy padają. Problem zaczyna się, gdy roadmapa zmienia się, bo wygrywa najgłośniejszy interesariusz, a nie dlatego, że pojawił się lepszy dowód albo nowy cel.

Wtedy dokument przestaje być narzędziem strategii. Staje się skrzynką na życzenia z datami.

Lista życzeń w przebraniu strategii

W strategii produktowej a roadmapie rozróżniamy to wprost: strategia mówi, gdzie gramy i jak wygrywamy; roadmapa pokazuje, w jakiej kolejności inwestujecie, żeby tę strategię realizować.

Gdy strategii brakuje albo żyje tylko w głowie zarządu, roadmapa przejmuje rolę politycznego kompromisu:

• każdy obszar dostaje „swój” kawałek, żeby było sprawiedliwie,
• daty są obiecywane wcześniej niż zrozumiany problem,
• nowe prośby wchodzą bokiem, bo „to tylko mała zmiana”,
• nikt nie wie, kosztem czego coś wskakuje na górę.

Efekt: zespół ciągle przestawia się, delivery wygląda zajęty, a po kwartale trudno wskazać spójny wątek inwestycji. To blisko feature factory - tylko zamiast spokojnej taśmy produkcyjnej macie taśmę, którą co dwa tygodnie przestawiają inni operatorzy.

Dlaczego „zwinność” nie jest alibi

Często słyszymy: „jesteśmy agile, więc roadmapa musi się zmieniać”. Zwinność zakłada zmianę na podstawie uczenia się, nie na podstawie kolejnego maila z tematem URGENT.

Sensowna niestabilność wygląda tak: odkryliście, że hipoteza o potrzebie nie trzyma się (patrz drugi tekst serii), więc przestawiacie inwestycję. Albo metryka wyniku po wdrożeniu mówi, że funkcja nic nie dała (pierwszy tekst), więc nie dokładacie kolejnej warstwy na ten sam pomysł.

Niesensowna niestabilność: ten sam typ próśb wraca co sprint, cele się nie zmieniają, a kolejność prac tak. Brakuje filtra decyzji, więc wygrywa głośność.

Gdy decyzje produktowe zamieniają się w ciągłe negocjacje bez kryteriów, lądujecie w stanie, który opisujemy w gdy decyzje produktowe zamieniają się w chaos.

Jak odróżnić strategię od kolejki

Na najbliższym przeglądzie roadmapy zadajcie trzy pytania przy każdym większym temacie:

1. Jakiego celu strategicznego to służy? Jeśli odpowiedź brzmi „klient X prosił” albo „sprzedaż potrzebuje”, to jeszcze nie cel - to źródło. Doprecyzujcie, jaki wynik biznesowy lub kliencki ma się zmienić.
2. Czego nie robimy, żeby to zrobić? Brak odpowiedzi oznacza, że roadmapa tylko rośnie. Priorytet bez kosztu alternatywnego to pobożne życzenie.
3. Jaką niepewność redukujemy najpierw? Duży epik z datą i zerowym discovery to plan wytwarzania, nie plan uczenia. Product discovery powinno wpływać na kolejność - inaczej daty są fikcją z dobrym formatowaniem.

Jeśli na te pytania nie da się odpowiedzieć bez slajdu z 40 wierszami, problem nie leży w narzędziu (Jira, Productboard, Excel). Leży w tym, że nie ma wspólnego filtra decyzji.

Co zwykle pomaga w praktyce

Kilka ruchów, które widzimy jako pierwsze, zanim ktoś narysuje „nową strategię na warsztacie”:

• Oddzielcie nowości od zobowiązań. Osobna lista: eksperymenty / discovery vs rzeczy już sprzedane klientowi. Mieszanie ich w jednej kolumnie „Q2” zabija wiarygodność planu.
• Limit równoległych inicjatyw na poziomie produktu lub obszaru. Roadmapa z piętnastoma „P0” to nie roadmapa.
• Stałe okna na zmianę planu (np. co 4-6 tygodni) zamiast wpuszczania tematów w środku sprintu „poza procesem”. Zmiana zostaje możliwa - tylko ma miejsce i właściciela.
• Język outcome przy przeglądzie. „Dowieźliśmy A, B, C” zamieńcie na „A miało podnieść X - wynik po N tygodniach: …”. Bez tego wracacie do zajętości.

Gdy produkt jest dojrzały, a roadmapa od lat jest listą feature’ów „bo zawsze tak robiliśmy”, warto zejść głębiej - stąd Product Re-Discovery i praktyka z Professional Product Discovery & Validation.

Most do ostatniego tekstu

Niestabilna roadmapa i słabe poznanie potrzeb mają wspólny skutek: budujecie długo, a uczycie się późno. O tym, jak drogo wychodzi odkrycie „niewłaściwego rozwiązania” dopiero po wdrożeniu - w ostatnim tekście serii.

Dalej w serii: Za późno dowiadujemy się, że zbudowaliśmy niewłaściwe rozwiązanie · Budujemy dużo funkcji, mało efektu · Nie wiemy, czego potrzebują klienci