Używasz dat w Roadmapie produktu? Zrezygnuj z nich!

Sprzedawanie wizji rozwoju produktu nie jest proste. Aby zakomunikować zainteresowanym (sprzedaży, zespołowi, użytkownikom) “co nas czeka”, jako produktowcy, zwykle używamy roadmapy. Trzeba jednak pamiętać, że dla otoczenie roadmapa zwykle przyjmowana jest jako swego rodzaju kontrakt – umawiamy się konkretnie co i kiedy powstanie w produkcie.

Źle zrobiona i zakomunikowana roadmapa może niepotrzebnie usztywnić rozwój, przedstawiać obietnice zbyt dokładnie osadzone czasowo i zabijające możliwość zwinnego dostosowywania się do potrzeb rynku. Jedną ze strategii, którą w takich sytuacjach proponuję, jest zrezygnowanie z czegoś, co dla wielu produktowców jest podstawą każdej roadmpy, czyli… dat.

Dlaczego warto zrezygnować z dat w roadmapach?

Do rezygnacji z dat namawia Simon Cast (cofounder ProdPad) w artykule “Roadmapping Without Dates”, relacjonując dyskusje product managerów w ramach MindTheProduct. Zbyt duża szczegółowość w roadmapie sprawia że staje się ona bardziej planem projektu niż przedstawieniem wizji rozwoju produktu.

Zbytnia szczegółowość sprawia, że Roadmapy w zmiennym środowisku produktowym stają się trudne w zarządzaniu. Moment, w którym dokładna data zostanie dodana do roadmapy, to moment gdy wszyscy, (poza biednym product managerem) zaczynają wierzyć że jest to końcowa, nieprzesuwalna data dostarczenia rozwiązania.

I tu zaczynają się kłopoty. Niezależnie od tego jak wiele razy wspomnisz że priorytety mogą się zmienić – ustalona data stanie się świętym terminem, na który wszyscy czekają. Nagle, cały zespół produktowy zacznie być rozliczany na podstawie tego, czy dowiózł wstępne, bardzo szacunkowe terminów. Ocena ta oczywiście nie uwzględnia, że w pracy nad produktem zmienia się otoczenie i priorytety. Przecież data jest święta!

Jak tworzyć lepsze roadmapy?

Simon pokazał też jak wygląda tworzenie roadmapy w ProdPad-ie, bardzo mi się ta koncepcja podoba. Współgra ona z problemem z którym sam się mierzyłem: forma roadmapy która nie uwzględnia różnicy w pewności co do elementów najbliższych oraz przyszłych jest często odpowiedzialna za utratę zaufania i nieporozumienia pomiędzy zespołem developerskim, sprzedażą, marketingiem. A przecież najlepsze organizacje działają skutecznie dzięki zwinnej zmianie priorytetów, uzależnionej od otrzymywanego z rynku feedbacku. Dlaczego, więc nie pozostać elastycznym?

Opracowałem koncepcję szablonu takiej zwinnej roadmapy. Przy jej projektowaniu wziąłem pod uwagę kilka następujących założeń:

• wysoki stopień pewność co do planowanych prac w najbliższej perspektywie
• stopniowy spadek pewności dla przyszłych prac
• zachęcenie do luźnego odkrywania nowych funkcji/problemów przeznaczonych do dalszego rozwoju
• użycie właściwego języka skupiającego się na akcentowaniu stopnia pewności poszczególnych prac

Szablon roadmapy

Poniższy szablon powstał na podstawie tych założeń.

Zebrałem też kilka istotnych zasad, uwag i przemyśleń dotyczących tego szablonu:

1. Po pierwsze, jest to bardziej backlog prac niż szczegółowy plan realizacji. Podobieństwo z scrum backlogiem nie jest przypadkowa 🙂 Bardzo łatwo przesuwać elementy pomiędzy poszczególnymi sekcjami. Jest to szczególnie przydatne przy zarządzaniu portfelem produktów i zmianą pojemności zespołu.
2. Elementy ułożone są w kolejności malejącej pod względem priorytetu. Dzięki temu najważniejsze elementy zawsze najbardziej rzucają się w oczy. Jeśli element od dłuższego czasu nie przesuwa się w górę (mimo wykonywanych prac bardziej pilnych) to znaczy, że jego realny priorytet jest prawdopodobnie jeszcze niższy.
3. Elementy zaplanowane na najbliższy kwartał „Q+1” (oczywiście zespół może sobie przyjąć inne miary podziału roadmapy, np. miesięczne) są zaplanowane, zmierzone i ocenione. Priorytety w krótkim okresie nie powinny się drastycznie zmieniać. Używany język w roadmapie powinien odzwierciedlać nasza pewność co do wykonalności tego planu.
4. Elementy w kolejnym kwartale są przemyślane na dosyć dużym stopniu szczegółowości. Nie są jednak zmierzone i ocenione. Używany język dla tych elementów powinien odzwierciedlać prawdopodobieństwo, z zastrzeżeniem, że priorytety mogą ulec zmianie.
5. Wreszcie, elementy poza kolejnym kwartałem „Q+2” są zapisane z mniejszą szczegółowością i też nie są ani zmierzone, ani ocenione. Używany tutaj język powinien sugerować, że elementy te są dopiero pomysłem i skłaniać do przemyśleń, czy w ogóle są potrzebne. Sens ich spisywania jest taki, żeby prowokować do dyskusji nad nimi wcześniej, niż później.
6. Odpowiedź na pytanie „Kiedy?” dla elementów poniższej pierwszej linii jest zawsze otwartą kwestią do przedyskutowania. Jak ważny jest ten element w kontekście innych? – to będzie świetny start do dyskusji dla każdego product managera. Być może jest to ważniejszy element, niż zespół przewidywał? To powinien być punkt wyzwalający rozmowy, a nie moment kiedy wszyscy uciekają od odpowiedzi w popłochu.

Co o tym sądzisz?

Co sądzisz o takim przedstawianiu roadmapy? Czy takie narzędzie i zasady mogą ułątwić współpracę pomiędzy zespołem produktowym, product managerem sprzedażą i marketingiem? Czy coś byś dodał/odjął? Czekam na feedback 🙂

John Peltier – Dyrektor ds. produktu w The Network (NAVEX Global Company), utalentowany lider zarządzania produktami B2B SaaS, który odkrywa i opracowuje rozwiązania problemów biznesowych. Certyfikowany product manager (PMC, CPM, CPMM). Prowadzi bloga The PM Vision oraz organizuje ProductCamp Austin i Atlanta.