Z tego podcastu dowiesz się:
- Czym jest roadmapa produktu, a czym na pewno nie jest
- Kiedy po nią sięgamy
- Co znajdziesz w perfekcyjnie przygotowanej roadmapie
- Czy product manager może funkcjonować bez roadmapy
- Kto, poza product managerem, tworzy roadmapę produktu
- Jakie są rodzaje roadmap
- Kto w organizacji może pomóc nam w budowaniu strategii
- Dlaczego ty i twoja firma potrzebujecie roadmapy
- Co to znaczy „przemyślana strategia”
- Jak w 10 krokach stworzyć skuteczną roadmapę
Podcast wysłuchasz także na:
Jeśli mój podcast wydał Ci się interesujący, ale szukasz dodatkowego wsparcia w rozwoju zawodowym, to zapraszam na moje konsultacje managerskie.
Transkrypcja podcastu
„ Być jak menadżer” podcast, epizod 22. Dzień dobry. Trzy tygodnie, mniej więcej tyle, pomijając oczywiście inne pasje, hobby, czy zainteresowania, które posiadam, zajęło mi przygotowanie skryptu do dzisiejszego epizodu. Nie dlatego, że temat okazał się dla mnie za trudny lub mnie przerósł, ale dlatego, że jest to mój ulubiony temat. I tak, jak zazwyczaj skrypty do epizodów zajmują mi 3-4 kartki formatu A4, tak ten posiada 13 lub bodajże 14 kartek A4. To będzie nieco dłuższy epizod, ale postaram się, żeby obwarowany był zawsze mocną, merytoryczną warstwą tego, jak zarządzać produktem. A jeżeli drogi słuchaczu, jesteś tutaj przypadkiem, albo po raz pierwszy, to ja tylko przypomnę, że podcast „Być jak menadżer” kierowany jest przeze mnie do szeroko pojętej branży menadżerskiej, ale z naciskiem na zarządzanie produktem. Więc jeśli jesteś lub będziesz dopiero Product managerem, Project managerem, analitykiem biznesowym, Product Ownerem, a może nawet Scrum Masterem, to liczę, że znajdziesz tutaj wartościowe treści właśnie dla siebie.
Zanim wejdę jeszcze w mięcho dzisiejszego podcastu, to serdecznie dziękuję za wszystkie komentarze, opinie, którymi Ty lub inni pozostali słuchacze dzielą się ze mną na moich mediach społecznościowych. Dostaję też dużo wiadomości na prywatną skrzynkę, na Instagramie, Facebook’u, na LinkedIn’ie. Zachęcam też do śledzenia w szczególności mojego profilu na LinkedIn. I dziękuję wszystkim, którzy zapisali się na mój newsletter, i Ciebie też, drogi słuchaczu zachęcam do zapisania się na stronie bycjakmanager.pl na newsletter. Ja zawszę dotrzymuję słowa i nie handluję Twoimi danymi, czyli imieniem i adresem mailowym, nikomu tych danych nie udostępniam. A wykorzystuję tylko i wyłącznie mój newsletter do tego, żeby poinformować o nowych epizodach, albo podzielić się jakimiś pro trikami i praktycznymi poradami, na które nie znalazłem miejsca w epizodach audio. Więc zachęcam, bo warto.
Jak tworzyć roadmapę produktu? To jest bardzo szeroki temat, bardzo szerokie pole do popisu dla wszystkich produktowców. Ja tylko słowem wstępu powiem, i oczywiście mówię to jak zawsze z takim subiektywnym filtrem, ja nie wierzę w obiektywizm, natomiast subiektywnie ujmując po swojej stronie, Product Manager bez roadmapy jest trochę jak żołnierz bez karabinu, jak zawodowy kierowca bez prawa jazdy, jak turysta bez mapy, jak pielgrzym bez obranego celu, jak chomik w klatce bez ukochanego kołowrotka, jak kosmonauta zbliżający się do stratosfery bez obranej trajektorii lotu. I mógłbym tak jeszcze bardzo, bardzo długo wymieniać.
Roadmapa, drogi słuchaczu, to jest nieodłączny element zarządzania produktem, ale także projektem. Chociaż dzisiaj bardziej skupimy się na tej części produktowej. Jak rozumieć roadmapę? I to jest istotne pytanie, które też chcę na początku postawić. Jeśli jesteś w trasie, wyobraź sobie, że jedziesz samochodem na przykład i chcesz się dostać do wybranego celu na czas, ale również bez marnowania hektolitrów benzyny, potrzebujesz siłą rzeczy jakiejś mapy drogowe. W dzisiejszych czasach taką mapę zastępuje nam najczęściej nawigacja w aucie lub smartfonie. I podobnie jest z Twoim produktem, z tą jednak różnicą, że nie nawigujesz swojej samotnej podróży samochodem, a przewodzisz grupie rowerów, motocykli, łodzi, czy nawet ciężarówek w dodatku, które nadjeżdżają z różnych kierunków na mapie. Tutaj rzecz robi się bardzo challange’ująca. Dlatego roadmapa to jest swego rodzaju kręgosłup każdego wybitnego zespołu deweloperskiego.
I roadmapa to powinna być, przynajmniej w teorii, jedyne źródło prawdy, które powie interesariuszom, ale też inżynierom, w którą stronę zmierzacie oraz odpowie roadmapa na pytanie, dlaczego właśnie w tym kierunku. I w przeciwieństwie do tradycyjnej mapy roadmapa produktowa ciągle się zmienia. W sumie tradycyjne mapy też się zmieniają, jak wybudowane zostaną na przykład nowe drogi i skróty pojawią się na trasie. W zależności od czynników oraz warunków, które pojawią się w biznesie, te zmiany zachodzą w roadmapie, tudzież w zależności od zmian, jakie występują w konkretnej organizacji.
Czym jest roadmapa produktu? Ja wiem, że już chwilę rozmawiamy o tej roadmapie, ale jakbyśmy zatrzymali się na sekundę i pouprawiali taką żonglerkę, czy tam szermierkę, taką żonglerkę definicjami. Dla mnie roadmapy są najczęściej wykorzystywane w firmach programistycznych i organizacjach, które wytwarzają szeroko pojęte technologie. Być może patrzę na to mocno subiektywnie, bo nigdy nie pracowałem w przemyśle produkcyjnym, dlatego zakładam, że w większości roadmapy wykorzystywane są jednak w firmach technologicznych, głównie skupionych wokół oprogramowania i aplikacji. I definicji roadmapy jest co najmniej kilka. Aczkolwiek z moich obserwacji wynika, że wszystkie te definicje wybrzmiewają zawsze w podobnym, a przynajmniej najczęściej, w podobnym tonie. W największym skrócie, roadmapa jest swego rodzaju dokumentem, który daje pewien całościowy pogląd na różne aspekty nadchodzącego produktu. Pogląd na cele, funkcjonalności, zasoby, czy nawet ramy czasowe, tudzież deadline’y, jeżeli na roadmapie umieścimy deadline’y.
Idę o zakład, że ktoś inny jeszcze bardziej uprościłby te definicje, mówiąc, że roadmapa to tak naprawdę narzędzie, które służy do komunikowania Twojej wizji produktowej i przekuwania planów produktowych w konkretne akcje. A gdybym miał poszukać definicji jeszcze bliższej praktyce dnia codziennego, to dodałbym nawet, że roadmapa to nic innego, jak wizualna reprezentacja krótko, albo długoterminowych priorytetów w projekcie lub firmie. I właśnie ta wizualna reprezentacja priorytetów pomaga wszystkim wokół w budowaniu spójnej komunikacji wokół produktów, no ale też pomaga podejmować decyzje strategiczne, przede wszystkim top managementowi.
Istnieje co najmniej kilka typów roadmap, zaraz sobie o nich powiemy. Nie chcę się bawić w żonglerkę definicjami zbyt długo, bo pamiętaj, że punkt widzenia zależy często od punktu siedzenia. Z mojego punktu widzenia, pomimo że większość osób kojarzy roadmapy z planowaniem, dla mnie osobiście od zawsze było to narzędzie do komunikacji. Powiemy sobie później nieco więcej o tym, co warto umieścić na roadmapie, a teraz chcę tylko wrzucić do Twojej głowy, wbić Ci tak troszkę na dłużej taką generalną konstatację, gdy ktoś mnie zapyta, do czego służy roadmapa, to w jednym zdaniu odpowiem, że roadmapa produktowa wyjaśnia co oraz dlaczego to budujemy. To jest takie trochę wysokopoziomowe podsumowanie wizji oraz kierunku rozwoju Twojego produktu.
I powiedzmy sobie od razu, czym na pewno roadmapa nie jest, to też jest ciekawe. Roadmapa to nie jest żaden dekret, nawet jeżeli ktoś na nią tak patrzy. To jest raczej dyskusja, narzędzie, które upoważnia wszystkich do stawiania właściwych pytań i dzielenia się przede wszystkim swoimi obawami. Roadmapą na pewno nie będzie też lista funkcjonalności. Oczywiście istnieje pewien typ roadmapy, gdzie wykazujesz funkcjonalności, ale nawet one są wspomniane jedynie na wysokim, takim ogólnym poziomie, a już na pewno bez szczegółów technicznych. Tutaj bardziej portretujemy strategiczne cele i nieco większe inicjatywy razem z kamieniami milowymi, które pomogą nam osiągnąć sukces. Roadmapą nie będzie również backlog produktu z listą tasków. Planując długo, albo średnioterminowy rozwój produktu bardziej skupimy się na strategicznych komponentach, aniżeli konkretnych zadaniach do wykonania.
Kto tak naprawdę, tu stawiam kolejne pytanie, tworzy roadmapę produktu? Tutaj odpowiedzi nie musiałem długo szukać. Product management lub inny produktowiec, w sensie Product Manager, albo jakikolwiek inny produktowiec, który odpowiada za cykl życia produktu w organizacji. I to może być Product Owner. Często stworzenie średnioterminowej roadmapy pomaga Product Ownerowi w komunikacji z inżynierami. To może być też jakiś dyrektor strategiczny, albo tak zwany head of product, czyli głowa produktu w dosłownym tłumaczeniu powiedzielibyśmy. I tutaj tylko wysokopoziomowe kamienie milowe i komunikowanie wizji należałoby do takiego dyrektora strategicznego. W niektórych przypadkach, to może być również CPO, czyli Chief Product Officer. Ale pomimo, że roadmapa produktowa w pewnych aspektach wpływa na całą organizację, to jednak roadmapa wymaga, i tu nie zapominajmy o tym, centralnego punktu dowodzenia. I mam na myśli to, że każda roadmapa powinna mieć swojego konkretnego właściciela, albo właścicieli kilku, którzy będą nią nie tylko zarządzać, w sensie nie tylko zbudują ją od zera, ale będą nią zarządzać i ją aktualizować. Też będziemy jeszcze o tym wspominać. Właściciel roadmapy, to swego rodzaju gwarancja spójności i pewnej przejrzystości tego narzędzia. To tyle w kwestii tego, kto tworzy roadmapę.
A teraz niezależnie od tego, jaką rolę piastujesz lub będziesz piastować, rzucimy trochę światła na realne potrzeby, bo o nich mowa, nie tyle potrzeby firm, co Twoje, czyli speca. Potrzeby speca, który już wkrótce, mam nadzieję, złoży do kupy najlepszą roadmapę produktową, jaką widziała ludzkość. Tego Ci życzę bez ironii, trzymam kciuki. Ale odpowiedz sobie na pytanie, a ja pomogę Ci odpowiedzieć na to pytanie razem z Tobą, dlaczego potrzebujesz roadmapę? Ja być może powtórzę po sobie kilka faktów teraz, o których wspomniałem wcześniej, ale robię to w dobrej wierze. Żeby wiedza, jaką wyniesiesz z dzisiejszego podcastu nie była ulotna, jak ulotka, mówiąc językiem Paktofoniki.
Roadmapa produktowa ma co najmniej kilka konkretnych celów, które pomogą Ci zaspokoić potrzeby biznesowe. Cel pierwszy, dzięki niej przedstawisz innym pewną wizję oraz strategię, na której będzie opierać się dalsza praca całego zespołu inżynieryjno-produktowego. Kolejnym celem jest to, że dobrze skrojona roadmapa podpowie Ci, jak te strategie wcielić w życie, oczywiście za sprawą na przykład kamieni milowych. Kolejnym celem jest to, że na pewno takie narzędzie pomoże Tobie w komunikacji z interesariuszami wewnątrz, ale też na zewnątrz firmy, jak też w komunikacji z samymi klientami. W niektórych przypadkach klienci są także interesariuszami, tak bywa. Roadmapa bywa też silnym bodźcem do przeprowadzenia zazwyczaj ciekawych rozmów z zespołem o strategii, o planach na przyszłość. Ja osobiście uważam ten moment, gdy opowiadam współpracownikom o strategii, a oni następnie hejtują całe plany. Żartuję sobie, nie hejtują, ale zazwyczaj pokazanie pierwszej wersji roadmapy deweloperom prowokuje powiedziałbym naprawdę fajne, konstruktywne dyskusje, ale też głosy sprzeciwu. Ja mogę dzięki temu później balansować to, co usłyszałem, a to co pierwotnie planowałem, i dzięki temu, że mamy roadmapę, to mamy też niezły temat do dyskusji. I takie dyskusje o roadmapie naprawdę bywają ciekawe i inspirujące.
Ale dlaczego jeszcze możesz potrzebować roadmapy? Otóż dobrze zbudowana roadmapa, a co za tym idzie przemyślana strategia pomoże Twojemu zespołowi pozostać skupionym na najważniejszych rzeczach, tak bym to ujął. Jako że najczęściej wszyscy w firmie od developmentu przez marketing, aż po wyższy management zobaczą Twoją roadmapę, to mogą Ci później pomóc też przekonać sceptycznie nastawionych interesariuszy, albo inwestorów, którzy de facto często wykładają pieniądze na Wasz produkt. I jeszcze kolejnym powodem, dla którego potrzebowałbyś roadmapy, to to że Ty i Twój zespół potrzebujecie jednego, oficjalnego źródła prawdy, prawdy o wizji i o kierunku rozwoju produktu. I kolejnym powodem, dla którego byś potrzebował roadmapy, to to, że tak, czy inaczej potrzebujesz też rozbić, mówiąc najogólniej, rozbić bardzo wysokopoziomową wizję na nieco mniejsze etapy. I właśnie tutaj przychodzi z pomocą roadmapa.
Warto też zauważyć, że zespoły, które rozumieją misję firmy i czują, że dążą do tego samego celu, i to wychodzi z badań, ale też z obserwacji to zauważysz, że takie zespoły, które widzą ten cel, wiedzą, gdzie idziemy, są po pierwsze bardziej produktywne i po drugie, wnoszą większą wartość do organizacji, do Waszej pracy codziennej nad projektem. I kończę już ten wątek realnych potrzeb posiadania roadmapy. Pamiętaj proszę, że musi ona zawierać pewne szczegóły, ale jednocześnie być na tyle wysokopoziomowa, żeby wszyscy wokół mogli ją jednakowo rozumieć i także rozczytać.
Jeśli chcemy budować świetne roadmapy, które będą spełniać swoje role, to warto w ogóle rozróżniać, jakie mamy rodzaje roadmap. Także zanim wskoczymy do najbardziej mięsistego akapitu dzisiejszego epizodu, opowiem drogi słuchaczu jeszcze o tym, czym może być nasza roadmapa. Nie wiem, jakie znasz rodzaje lub typy roadmap. Ja wypunktowałem kilka. Wydaje mi się, tych najbardziej popularnych, najczęściej spotykanych. Oczywiście typ roadmapy, którą będziesz eksplorować zależy od natury produktu, jaki rozwijacie, od Waszych celów biznesowych, od rodzaju interesariuszy, z którymi współpracujesz. Roadmapą może być więc na przykład roadmapa funkcjonalności z osią czasową. Z angielskiego mówimy o tym Features Timeline Roadmap. Istnieje wiele produktów, przy których wdrażanie nowych funkcjonalności bezpośrednio przekłada się na zaangażowanie użytkowników, na przychód firmy, na walkę o rynek z konkurencją. I właśnie w takich przypadkach warto granulować naszą roadmapę, z uwzględnieniem kluczowych dat, ale także rodzajów zasobów i powiedziałbym kompetencji, których będziemy wkrótce potrzebować, żeby osiągnąć nasze kamienie milowe.
Kolejnym typem byłaby roadmapa releasów, z angielskiego wydawać, czyli release roadmap. Wiele produktów, zwłaszcza jeśli mówimy o aplikacjach i oprogramowaniu nie są wydawane tylko jednorazowo i kropka. A już w szczególności oprogramowanie budowane w modelu SaaS, czyli Software as a Service. Takie oprogramowanie musi być usprawniane na bieżąco. Także ułożenie planu kolejnych wersji aplikacji w schludnie wyglądającą, czytelną roadmapę, to także dobry sposób na narysowanie pewnej ścieżki dla kamieni milowych produktu. Oczywiście bez sztywnego ustalania ram czasowych dla kolejnych wydań, ale taka mapa, że dziś jesteśmy tu, a za pięć wydań na przykład naszych releasów chcemy być tam, w takim miejscu. To jest tak zwana mapa releasów.
Istnieje też roadmapa sprintów, nieco rzadziej widywana, ale warto wiedzieć, że takowa istnieje. Może być przydatna w projektach opartych na Scrumie. Być może kojarzysz takie jednogodzinne sesje planningowe, gdzie zespół scrumowy przechodzi przez backlog produktu i zgadza się, albo nie zgadza, co do rzeczy, które może dowieść w najbliższym sprincie. Stworzenie roadmapy z nadchodzącymi sprintami może właśnie pomóc zespołowi zrozumieć krótkoterminowe cele, ale też upewnić się, że tą najbliższą przyszłość dewelopmentu wszyscy widzimy podobnie. Oczywiście pamiętajmy, że tutaj operujemy już na niższym poziomie, czyli na celach każdego ze sprintu. Oczywiście nie musisz wypisywać wszystkich user stories i task’ów na przyszłe sprinty, ale wystarczy, że zastanowisz się, jakie cele każdy ze sprintów miałby realizować, a następnie pokażesz to na swojej roadmapie.
Kolejny typ roadmapy, to roadmapa o nazwie „teraz, następnie, później”, znana pod angielską nazwą „now, next, later”. Nie ukrywam, że to jest jedna z moich ulubionych, wysokopoziomowych roadmap. Także w obecnej firmie pracuję na tej roadmapie wspólnie z moimi amerykańskimi kolegami i koleżankami produktowcami oraz z top managementem. To jest bardzo dobry sposób na zarządzanie potrzebami większej grupy interesariuszy, włączając w to całą firmę, a nawet klientów. W skrócie, próbujesz na bardzo wysokim poziomie zwizualizować strategię firmy na najbliższe lata w podziale na 3 etapy. Na to, czym zajmujecie się teraz obecnie, na to, czym chcecie zająć się w dalszej kolejności oraz na to, czym chcecie zająć się jeszcze później. I rzeczywiście polecam zgoogle’ować roadmapę „now, next, later” i przyjrzeć się jej z bliska, bo może okazać się przydatna. Ale inne typy też mogą okazać się przydatne.
Ostatni typ roadmapy, o którym chcę wspomnieć, i który przychodzi mi na myśl, to nasze cele na osi czasu. I to jest tak zwana Objectives Timeline Roadmap. Wiadomo, że firmy są znane głównie z produktów, które oferują, ale przecież za każdym produktem stoi pewna całościowa strategia. I ten typ roadmapy ładnie to wyraża, bo przyglądamy się temu, co praca zespołów produktowych znaczy dla klientów, partnerów, ale też pozostałych interesariuszy. Rzadko spotykany typ roadmapy, ale z pewnością warty rozważenia.
Przeszliśmy już przez typy roadmap, opowiedzieliśmy o potrzebach, które zaspokaja to narzędzie, pobawiliśmy się nawet definicją roadmapy, czas teraz na sedno naszego dzisiejszego spotkania, czyli jak tworzyć roadmapę. Ja zbudowałem dla Ciebie, drogi słuchaczu, listę moich subiektywnych wskazówek i praktycznych porad w kontekście budowania roadmapy. Od Ciebie zależy, ile z tego wykorzystasz w swoim projekcie. Ja tylko dodam, że tak, jak moje podejście uważam za w miarę słuszne, bo mi się sprawdzało wiele razy, tak pamiętaj, że inni produktowcy mogą mieć i kultywować inne metody, które także bywają skuteczne. Wiele zależy od organizacji, w której się znajdujesz lub znajdziesz, i jak bardzo Twoja organizacja będzie otwarta na średnio lub długoterminowe planowanie. Z doświadczenia wiem, że im większa firma, tym większy wysiłek kładzie się na planowanie strategii.
Jak tworzyć roadmapę?Ten krótki miniporadnik rozbiłem na dziesięć etapów. Natomiast taka praktyczna uwaga – nie musisz nic notować ani zapamiętywać – znaczy fajnie jakbyś zapamiętał słuchaczu, ale nie musisz nic notować, natomiast jeżeli zgubisz kontekst, albo będziesz chciał wracać do tych treści, to też nie musisz drugi raz odsłuchiwać podcastu. Pamiętaj, że pod wpisem na moim blogu byćjakmanager.pl, gdzie opublikowałem ten odcinek, kilka dni po publikacji znajdziesz od razu transkrypcję, czyli jednolity tekst całej tej treści, o której mówię. Zachęcam, żeby do tego wracać używając Ctrl+F, czy tam jabłuszko+F, jeżeli pracujesz na Macu możesz wyszukać konkretną frazę. Jest także wyszukajka na stronie, więc polecam doszukiwać się tam treści, które być może Ci wypadły, nie wiesz jak je znaleźć, a nie chcesz jeszcze raz przesłuchiwać całości. Jak tworzyć roadmapę?
Etap I. Zrozum szerszy kontekst. Tak zwany big picture. I o co chodzi z tym szerszym kontekstem? Zanim w ogóle siądziesz do roadmapy i zdecydujesz o tym, nad czym Twój zespół będzie pracował, zrób krok w tył na moment, żeby zrozumieć strategię organizacji i tak naprawdę całą wizję produktową. Spróbuj odpowiedzieć sobie na pytanie dlaczego rozwijacie właśnie ten produkt właśnie teraz. Co tak naprawdę Wasz sukces w dewelopmencie będzie oznaczał dla wszystkich klientów, ale też dla firmy, ale również jak wpłynie na rynek ogólnie? Jeśli sam nie zrozumiesz szerszego kontekstu, to później indywidualne decyzje zespołu nie będą spójne z ogólną strategią firmy. Będziecie się rozjeżdżać, jeżeli nie będziesz w stanie do kupy utrzymać tego kontekstu, tej wspólnej wizji. Wszystko, co znajdzie się na Twojej roadmapie powinno wspierać ogólną strategię organizacji. I to, co warto zaznaczyć to to, że roadmapa zawsze leży gdzieś pośrodku. Pomiędzy wizją firmy, a działaniami operacyjnymi i codziennym developmentem. Czyli gdzieś z jednej strony mamy wizję firmy taką górnolotną. Czasem CSO jest takim wizjonerem, który mówi: „My chcemy być TOP5 firm, które robią to albo tamto”. A po drugiej stronie są działania operacyjne na co dzień i codzienny development. I roadmapa leży gdzieś pośrodku. Ja w ostatnim czasie tworzyłem dwie roadmapy – długo oraz średnioterminową. I w organizacji, z którą obecnie współpracuję, Top management przedstawił nam ogólną wizję rozwoju firmy w postaci takich sześciu, jak to nazywamy, motywów strategicznych. Ja nie będę wnikał oczywiście w szczegóły tej strategii, bo nie chciałbym naruszyć tajemnicy handlowej swojej firmy. I Ty też nigdy tego nie rób. W sensie nie opowiadaj publicznie nawet znajomym przy piwie – polecam nie opowiadać o tym, gdzie Twoja firma chciałaby się znaleźć za X miesięcy, bo nigdy nie wiesz, kto jest czyim znajomym, a jednak trzymanie tajemnicy produktowej powinno być zawsze przestrzegane. Niemniej jednak ja wspominam o tym, bo to było super pomocne dla mnie i pozostałych produktowców, że mogliśmy każdą naszą wewnętrzną inicjatywę na roadmapie jakoby przypasować do wybranego motywu strategicznego, dzięki czemu mieliśmy pewność, że wspólnie realizujemy ogólną strategię firmy.
Etap II. Gdy już pojmiesz big picture i szerszy kontekst, zacznij od researchu. Żeby ruszyć z czymkolwiek, warto najpierw zbudować sobie po pierwsze kontekst, ale też pamiętać, że roadmapa spełnia dwa główne cele. Po pierwsze pomaga komunikować właśnie cele i priorytety, a następnie wspiera ciebie i całą organizację w zbudowaniu sensownego planu działania. Także pomyśl o tym, kim będą odbiorcy twojej roadmapy. Czy to będzie Top management? A może to będzie zespół inżynieryjny? Musisz to wiedzieć już na etapie researchu i tworzenia kontekstu, bo od odbiorców twojej roadmapy zależeć będzie co na niej przedstawisz. Kiedy masz już w głowie poskładany profil osoby, która będzie patrzeć na roadmapę, zastanów się teraz na spokojnie nad tym, w jakim miejscu znajduje się wasza organizacja. Czy to jest dojrzała firma ze stabilną pozycją na rynku? A może to jest start-up, który bardzo ostrożnie liczy pieniążki od inwestorów. A może opieracie działalność na jednym, głównym produkcie lub posiadacie tak naprawdę wiele różnych produktów sprzedawanych na różnych rynkach. Zupełnie inaczej będzie wyglądać roadmapa tworzona z myślą o niewielkim, dynamicznym start-up’ie, a zupełnie inaczej roadmapa skrojona dla jednego produktu z portfolio ogromnej korporacji, z długoletnią historią na rynku globalnym. I jako część researchu zrób koniecznie analizę rynku i konkurencji. I to jest super ważna rzecz, zwłaszcza gdy działacie lub zamierzacie działać na nowym dla siebie obszarze geograficznym. Swego czasu, podaję to, jako ciekawostkę, współpracowałem ze start-up’em, który usilnie pchał się na bardzo konkurencyjny rynek i jednocześnie oferował użytkownikom o wiele gorszą aplikację niż jego konkurent. Efekt mógł być oczywiście tylko jeden. Frustracjom zarządu nie było końca. Firma przepalała setki tysięcy złotych każdego miesiąca, a nie przynosiło to większych efektów. Jeśli masz na rynku konkurenta z lepszym produktem i o wiele większym zapleczem finansowym lub technologicznym, to jak cholera chciałbyś wygrać tę walkę o rynek? Ślepa wiara w to, że wygrywa się dobrymi pomysłami, to jest mit. Dlatego mierz siły na zamiary, bo każdy nawet najlepszy pomysł trzeba jeszcze zrealizować. Czyli mieć ludzi, pieniądze i konkretny plan działania. Idźmy dalej. Pamiętaj w każdym razie o przeanalizowanie konkurencji w czasie robienia researchu.
Etap III – budowania najlepszej roadmapy, a przynajmniej najbardziej skutecznej. Zdecyduj, jaki chcesz osiągnąć efekt, bazując na potrzebach biznesowych. Przypomnę raz jeszcze, że roadmapa to jest drogowskaz zmian. Zmian, które ty i twój zespół musicie poczynić, dzięki czemu zbliżycie się do założonej strategii. Tymi zmianami będą najczęściej nowe funkcjonalności, jakie warto wdrożyć, żeby usprawniać i zmieniać wasz obecny produkt. Ale odpowiedzenie sobie na pytanie: „Jakie rezultaty w rzeczywistości chcemy osiągnąć?” nie jest takie łatwe. Mnie pomaga w tym zawsze kilka prostych ćwiczeń. Przede wszystkim zadaję sobie pytanie: „Jaka jest nasza potrzeba biznesowa, którą jako organizacja, chcemy zaspokoić?”. Niech to będzie – wymyślmy sobie – następująca potrzeba biznesowa. W najbliższych latach chcemy zostać najpopularniejszą aplikacją w Europie do zamawiania usług porządkowych. Mamy taką hipotezę, mamy taki cel. Następnie zastanawiam się, jakie metryki powiedzą mi w przyszłości, czy ja osiągam ten cel, czy nie. Innymi słowy – jak chcielibyśmy zmierzyć nasz sukces albo brak sukcesu, i które liczby nam o tym powiedzą? Metryki to jest temat rzeka. Ja przypomnę tylko, że w dziewiątym epizodzie mojego podcastu z listopada 2021 roku, poświęciłem tam naprawdę sporo czasu właśnie metrykom produktowym. Zachęcam więc do odsłuchu. Myślę, że warto, bo opowiadałem wtedy, jakie są podstawowe metryki, a także na jakie kategorie możemy je podzielić i przede wszystkim, czemu służą. W przypadku naszej wymyślonej aplikacji do zamawiania usług sprzątających, niech taką gwiazdą północy, czyli najważniejszą metryką będzie liczba transakcji, Czyli to, ile razy użytkownicy zamówili usługę porządkową lub mówiąc inaczej – usługę sprzątania. I gdy mam już przemyślaną potrzebę biznesową oraz określone metryki, którymi będę mierzył sukces, to robię jeszcze jedno ćwiczenie. Mianowicie zastanawiam się, w jaki sposób powinno się zmienić zachowanie naszych użytkowników, żeby pomogło nam to w osiągnięciu naszego celu. Oczywiście w przypadku naszej aplikacji, użytkownicy musieliby po prostu zamawiać częściej usługi sprzątania. Ale rodzi się też pytanie jak ich do tego zachęcić. Być może programy lojalnościowe wewnątrz aplikacji? Być może jakiś system gwarantowanej satysfakcji albo zwrot kosztów w przypadku, gdy nie jesteśmy zadowoleni z wykonanej usługi. Pomysłów może być sporo, ale nie wymyślę ich sam. To, co ważne, to zaproś do burzy mózgów klientów, interesariuszy, członków zespołu. Dużo rozmawiaj, pytaj. W wolnej chwili rób dodatkowy research, szukaj odpowiedzi wszędzie tam, gdzie tylko możesz. Doprecyzowanie jakie rezultaty chcesz osiągnąć, jaką potrzebę biznesową zaspokoić, jakimi metrykami to zmierzysz i jak to wpłynie na zachowanie waszych użytkowników spowoduje, że twoja roadmapa zyska odpowiednią narrację do tego, żeby wybrzmieć w całej organizacji.
Dojechaliśmy do IV etapu. To, czego nie słyszysz w podcaście, to to, jak popijam sobie kawę, bo w czasie edycji zawsze wycinam te przerwy, ale już prawie kubeczek kawy mi zszedł. Za chwilę poczuję przypływ energii. Lećmy dalej. IV kolejny etap na drodze do zbudowania skutecznej roadmapy, to ustalenie ram czasowych. Niezwykle fajnie i lekko wszystko się planuje, jeśli tylko mówimy jedynie o jakiejś tam przyszłości oraz o tym, co kiedyś chcielibyśmy osiągnąć. To jest bardzo proste planowanie. Ale już bardziej challange’ujące jest narzucenie sobie pewnych ram czasowych. Nie mówimy tutaj o konkretnej dacie z kalendarza. Roadmapa potrzebuje jakiegoś miejsca docelowego, jakiejś destynacji. Zastanów się nad jakimś realnym okresem czasu, w którym cele z roadmapy powinny zostać zrealizowane. Pamiętaj, to tylko ćwiczenie. To nie jest dekret. Przewidzenie dokładnej daty realizacji tematów z roadmapy graniczy z cudem. Nie ma w co wierzyć, ale mimo wszystko warto zrobić to ćwiczenie. Chodzi o to, aby przyjąć jedynie pewne założenie, a następnie robić wszystko, żeby te założenia okazały się właściwe i wykonalne. Ale nie bawmy się w tworzenie precyzyjnych estymacji. Chodzi tylko o wysokopoziomowy plan. Zapytaj też siebie na głos, czy zrealizowanie rzeczy, jakie chcesz umieścić na roadmapie, to kwestia kilku czy kilkunastu miesięcy. A może kilku lat. Ja jestem fanem prowadzenia luźnych dyskusji i konsultacji z inżynierami już na tym etapie, chociażby po to, żeby zorientować się górnolotnie, czy planowane tematy zjedzą miesiące czy lata pracy. Teoretycznie – podkreślam – teoretycznie.
V etap na drodze do budowania skutecznej roadmapy, to zgrupuj problemy lub nadchodzące funkcjonalności w jakieś motywy strategiczne. Wspominałem wcześniej o motywach. Rozwińmy ten wątek. W zależności od tego, jak rozbudowana ma być twoja roadmapa, czasem warto pomyśleć nad jakimiś motywami, do których możesz potem przypisać kamienie milowe. Przykładowo, jeśli planujesz wspólnie z zespołem kilka funkcjonalności, które dotyczą przebudowy interfejsu waszej aplikacji, to być może da się je zgrupować pod jednym motywem strategicznym, który mówiąc ogólnie, poprawi tak zwany user experience, czyli doświadczenia użytkownika. I już, „pyk”. Masz motyw strategiczny plus user experience. A jeśli macie kila funkcjonalności, które mają za zadanie poprawić bezpieczeństwo waszej aplikacji, to być może warto je przypisać do wspólnego motywu o nazwie security albo po prostu bezpieczeństwo. Taka roadmapa wyposażona w motywy strategiczne może być naprawdę dużo bardziej czytelna, bo od razu komunikuje większe obszary, na których zamierzacie się skupić.
VI krok. Czyli dojechaliśmy już za półmetek do skutecznej roadmapy, to uchwycenie kamieni milowych, zdefiniowanie tak naprawdę kamieni milowych. Wiadomo, że niektóre kamienie milowe adresują problemy, z którymi się mierzymy. Takie jak niska retencja wśród użytkowników albo wysoki [ns 00:32:45] z angielskiego odpływ naszych użytkowników, którzy nie wiedzieć czemu porzucają naszą aplikacje i już nigdy do niej nie wracają. Inne kamienie milowe z kolei nie mówią tyle o problemach, co o naszych możliwościach, żeby wejść na nowe rynki lub w ogóle o odpaleniu nowych produktów, które mają pewną wartość strategiczną dla naszej firmy. Jeszcze inne kamienie milowe pozwolą naszym użytkownikom korzystać z naszego produktu w jakiś inny, nowy sposób. Ale nie byłbym sobą, gdybym nie dodał, że bywają też takie kamienie milowe, które nie przekładają się bezpośrednio na wartość dla klientów, ale na przykład pomagają nam w osiągnięciu pozostałych celów strategicznych. Jeśli chcesz uchwycić najważniejsze kamienie milowe, to koniecznie spotkaj się z interesariuszami produktu, poświęć każdemu z nich odpowiednią ilość czasu, nie organizuj grupowego spotkania, ale zamiast tego spotkaj się jeszcze na tym wczesnym etapie indywidualnie z każdym interesariuszem. Wymieńcie się opiniami na temat długofalowej wizji produktu, pogadajcie o strategii, zbieraj i zapisuj ten feedback, omawiajcie wspólnie rzeczy na roadmapie, a następnie zaproponuj swoją listę priorytetów na takim spotkaniu ze stakeholderem, z interesariuszem. Praca nad roadmapą, o czym zawsze wspominam, to nie jest praca indywidualna, a grupowa. Nawet jeżeli tylko ty jesteś właścicielem roadmapy. Złóż ten feedback zebrany od interesariuszy w jakiś jeden dokument – może to być Excel z celami do osiągnięcia, może to być jakakolwiek inna templatka, jakikolwiek inny szablon i tym sposobem już masz wstępnie rozpisane kamienie milowe, które później powinny znaleźć się gdzieś na roadmapie, jeśli oczywiście nie ma ku temu żadnych przeciwwskazań. Tyle jeśli chodzi o uchwycenie, a nawet bardziej zdefiniowanie kamieni milowych, o czym mówił nam etap VI.
Natomiast w etapie VII, to tutaj już tworzysz pierwszy mockup, pierwszy draft, pierwszą wersję roadmapy. Nazywaj to jak chcesz. Nie chcę ci doradzać, jak dokładnie ma wyglądać twoja roadmapa. Mam teraz na myśli layout, kolorki, wygląd samego dokumentu albo prezentacji. Jedni lubią Excela, inni prezentacje w PowerPoint, a inni prezentacje w Keynote. Chyba tylko raz w życiu zbudowałem roadmapę od zera. Tutaj muszę się przyznać bez bicia, nie korzystając z żadnego szablonu. Ja jestem ogromnym fanem szablonów niezależnie od narzędzia, z którego korzystam. Ostatnio przesiadłem się na prezentacje w Keynote, ponieważ pracuję w środowisku mocno skupionym wokół urządzeń Apple, MacBook’ów, Maców i tak dalej. To, co polecam ci zrobić, to wpisz po prostu w Google roadmapa appliance, albo szablony roadmap i tyle. Jedno kliknięcie i masz kilkadziesiąt, a nawet kilkaset świetnie wyglądających szablonów na wyciągnięcie ręki. Poukładaj kamienie milowe w kolejności od największej do najmniejszej wartości biznesowej oczywiście w kontekście strategii, którą powinniście wspierać. Pamiętaj tylko, że pierwsza wersja roadmapy nigdy nie będzie idealna. Spodziewaj się zmian, ale właśnie na tym polega tworzenie roadmapy – na ciągłej zmianie, gdy pojawia się nowa wiedza, okoliczności, gdy pojawiają się nowe argumenty z różnych stron. I kiedy masz już ten mockup, kiedy przejdziesz przez etap VII, wskakuj do etapu VIII. Zorganizuj review ze stakeholderami. Review, czyli nie wiem, recenzję. Przyjęło się mówienie review po prostu. Kiedy dojdziesz już do momentu, w którym masz skrojoną pierwszą wersję roadmapy, zorganizuj właśnie takie spotkanie ze wszystkimi interesariuszami. Ja zawsze nazywam takie spotkania Roadmap Final Review. Chodzi o to, żeby w jednym miejscu i czasie zebrać wszystkie zainteresowane strony, żeby te strony spojrzały na roadmapę i wyraziły swoje ostateczne zdanie, co do kształtu i co do charakteru samej roadmapy. Na początku takiego spotkania – tutaj dokładnie przejdę przez proponowaną agendę, bo to też jest istotne. Na początku takiego spotkania nadaj kontekst. Bez kontekstu nie wchodź w ogóle w szczegóły. No i jak taki kontekst nadać? Przede wszystkim przypomnij najpierw wszystkim wysokopoziomową wizję waszej firmy. A następnie opowiedz kolejno o celach strategicznych, jakie sobie wyznaczyliście, żeby zbliżyć się do realizacji tej wizji. Pamiętaj, że jeśli pracujesz w dużej organizacji, możesz się wcześniej umówić z którymś na przykład z dyrektorów albo nawet członków zarządu, żeby to on lub ona w ramach wstępu opowiedział lub opowiedziała o wizji i celach strategicznych firmy. Najważniejsze, żeby wyjaśnić interesariuszom jakie są podstawy do tego, że obraliście właśnie takie cele strategiczne. Drugim punktem na agendzie według mnie powinno być objaśnienie jakie posiadacie zasoby. Czyli ile zespołów będzie pracować nad rzeczami z roadmapy. Warto zaznaczyć, ile procentowo czasu zespoły inżynieryjne zamierzają spędzić na tworzeniu nowych funkcjonalności, ile czasu na łataniu błędów, a ile czasu na utrzymaniu systemu i zmniejszaniu długu technicznego, na przykład refaktorując kod.
Zrecenzowanie waszych zasobów na takim spotkaniu ma też inny plus – pokazujesz interesariuszom, że jesteś transparentny, że nie chcesz przed nimi nic ukrywać, nawet jeżeli borykacie się z rotacją w zespołach i te zasoby często się zmieniają. Jeżeli [ns 00:38:29] po polsku powiedzielibyśmy chyba wyporność zespołu okaże się za mała, to wtedy też warto poszukać w budżecie środków na otwarcie wakatów i na pozyskanie nowych, dodatkowych kompetencji, których potrzebujecie. Następnie opowiedz zebranym osobom o każdym z kamieni milowych. Nie wchodź w szczegóły techniczne, broń Boże – wyjaśniaj tylko, co kryje się za kamieniem milowym, i jak on ogólnie wpływa na strategię. Pamiętaj o tym, żeby przypominać interesariuszom, że każda estymacja, każda wycena robocizny dla kamienia milowego, została obliczona w oparciu o ograniczone zasoby, które posiadacie. Kiedy już przeprowadzisz wszystkich przez kamienie milowe, zapytaj interesariuszy o to, co chcieliby ewentualnie zmienić w twoim drafcie roadmapy. Spróbuj aktualizować roadmapy na bieżąco w czasie takiego spotkania. Wtedy inni mogą widzieć te nanoszone poprawki i odnosić się do poprawek, które nanosisz na bieżąco, ponieważ oni są świadomi tych zmian, które wprowadzasz. Kiedy przenosisz jeden z kamieni milowych na wcześniejszy termin – co jest logiczne – to oczywistym jest, że inny kamień milowy zostanie dowieziony przez to później, bo macie ograniczone zasoby.
I taki manewr pomaga prowokować jakoby dyskusję o priorytetach w czasie takiego spotkania. I to, co pomaga, to przypominać interesariuszom na każdym kroku, żeby patrzyli na roadmapę w kontekście całościowego sukcesu waszej firmy, a nie tylko ich indywidualnych interesów. Jakby musimy wkuwać do głów interesariuszom, że wszyscy gramy do jednej bramki.
Po takim spotkaniu przechodzimy do etapu IX. Organizujesz kolejne spotkanie z interesariuszami, żeby przedstawić im ostateczną wersję roadmapy, już po tej dyskusji, po naniesionych poprawkach, i tak dalej, i tak dalej. Kiedy wszyscy się przespali ze swoimi pomysłami, rzeczami, które usłyszeli, widzieli. Jeśli czujesz wewnętrznie, że ostateczna wersja roadmapy została już wystarczająco dopieszczona, to możesz na to samo spotkanie tak naprawdę zaprosić również pozostałych członków zespołu, żeby oczywiście zakomunikować wszystkim naraz strategię na najbliższą przyszłość. Pamiętaj tylko, żeby na końcu takiego spotkania zostawić kilka minut na sesję Q&A, czyli na ewentualne pytania z sali. Nie musisz na nie odpowiadać od razu, jeśli nie znasz odpowiedzi, ale zapisz je sobie i obiecaj każdej osobie, która zadaje pytania, że wrócisz do tej osoby z odpowiedzią już offline w ciągu kolejnych kilku dni. Tym sposobem dobrnęliśmy do końca. Ale ktoś by powiedział: „no dobra Mariusz, ale roadmapa jest gotowa, wszyscy klepnęli, punktów 9, temat zamknięty. Co kryje się w etapie X?”
Ja wiem, że dobrnęliśmy do końca, natomiast ostatni X krok do zbudowania skutecznej roadmapy, to to, co powinieneś zrobić z taką gotową roadmapą dalej. Otóż, drogi słuchaczu, utrzymuj ją i aktualizuj ją. Każdego tygodnia inżynierowie oraz biznes uczą się czegoś nowego. Często już w trakcie realizacji kamieni milowych z roadmapy dowiesz się rzeczy i twój zespół dowie się rzeczy, których nie wiedzieliście jeszcze miesiące wcześniej w czasie, gdy budowaliście ten plan. Należy wtedy skonsultować ewentualną zmianę priorytetów właśnie z interesariuszami, nanieść poprawki na roadmapę i zakomunikować korektę w tej strategii, na jaką się zgodziliście. I oczywiście zakomunikować te zmiany nie tylko interesariuszom, ale też zespołom inżynieryjnym. To tyle, jeśli chodzi o budowanie skutecznej roadmapy w dziesięciu prostych, w teorii tylko prostych krokach.
W ramach bonusu jeszcze tylko dodam, co powinno na pewno znaleźć się na idealnej roadmapie. Perfekcyjnie skrojona roadmapa powinna zawierać: strategię produktową, cele i metryki, funkcjonalności razem z hipotezami biznesowymi, stack technologiczny, czyli w jakich technologiach pracujecie, kamienie milowe z deadline’ami oraz opis rezultatów, jakie chcecie osiągnąć po każdym z etapów.
A teraz jedno zdanie turbo szczerości, osobiście nigdy, ale to nigdy w życiu nie spotkałem tak idealnie wysmażonej roadmapy, ale także samemu mnie nie udało się takiej roadmapy zbudować. Ale to nie znaczy, że przestałem próbować, wciąż próbuję, to jest proces. Dziękuję słuchaczu, jeżeli dotrwałeś aż do tego momentu. Serdecznie dziękuję, jeżeli zasubskrybowałeś w międzyczasie mój newsletter. Na pewno będę podsyłał protipy, ale też informacje o przyszłych podcastach. Jeżeli tematy z dzisiejszego epizodu okazały się niewystarczające, to zachęcam też do wbicia do mnie na konsultacje 1:1, zakładka „konsultacje”, strona bycjakmanager.pl. Możesz śmiało zabookować godzinkę ze mną, jeżeli masz taką wewnętrzną potrzebę przegadania czegoś istotnego, z czym borykasz się w swojej obecnej pracy lub gdy chcesz wejść do tej szeroko pojętej branży IT, jako menadżer. Jestem zawsze chętny do tego, żeby pomagać. Wszystkiego dobrego, dbaj o siebie i innych, cześć.
KONIEC
Źródła
https://plan.io/blog/build-a-product-roadmap/#what-is-a-product-roadmap
https://www.aha.io/roadmapping/guide/product-roadmap
https://theproductmanager.com/topics/how-to-create-a-product-roadmap/
https://fellow.app/blog/management/how-to-build-a-roadmap-a-guide-of-examples-and-tips/
https://www.productplan.com/learn/what-is-a-product-roadmap/
https://medium.com/agile-adapt/brainstorming-product-roadmaps-de0c77db99bc
https://www.eleken.co/blog-posts/how-to-build-a-product-roadmap-and-what-tools-to-use-to-build-it
https://www.smartsheet.com/best-practices-and-expert-tips-creating-product-roadmaps
