De fleste produktroadmaps bliver opgivet inden for et kvartal efter, at de er skrevet. Ikke fordi teams mangler disciplin, men fordi roadmappen blev bygget på det forkerte grundlag: faste datoer, funktionslister og interessenters ønsker, pakket ind som en plan. Når virkeligheden uundgåeligt afviger – en funktion tager længere tid, et kundebehov skifter, en konkurrent rykker – bliver roadmappen fiktion, og teamet holder op med at kigge på den.
En roadmap, som folk rent faktisk følger, er ikke et Gantt-diagram udklædt som produktstrategi. Det er et levende dokument, der viser teamets aktuelt bedste tanker om, i hvilken rækkefølge problemerne skal løses, og som er bygget op, så det er ærligt om, hvad der er kendt, og hvad der ikke er.
Før du designer en roadmap, er det værd at gøre sig dens formål klart. En roadmap gør tre ting: Den kommunikerer retning (hvor vil vi hen, og hvorfor), den tvinger til prioritering (vi kan ikke gøre alt, så hvad kommer først), og den skaber et grundlag for enighed (så udvikling, design, salg og support alle arbejder mod de samme mål).
En roadmap garanterer ikke leveringsdatoer. Den forpligter sig ikke til bestemte funktioner. Og den erstatter ikke behovet for løbende udforskning af kundernes behov. Hvis interessenter behandler roadmappen som et løfte, er det et procesproblem – ikke en grund til at bygge falsk præcision ind i dokumentet.
Det mest holdbare roadmapformat for de fleste teams er modellen med tre horisonter. Den er ærlig om usikkerhed: Punkterne under »Nu« er bindende, punkterne under »Næste« er planlagt, men ikke låst fast, og punkterne under »Senere« peger i en retning, men kan ændre sig, efterhånden som du lærer mere.
Bemærk, at hvert punkt ikke blot angiver, hvad det er, men også hvorfor det er der. En roadmap uden begrundelse er bare en liste. Når teammedlemmer forstår, hvorfor hvert punkt blev valgt, kan de træffe bedre beslutninger, når tingene ændrer sig – og de kan have mere givende samtaler, når en kunde beder om noget, der ikke står på listen.
Funktionsbaserede roadmaps (»byg X, byg Y, byg Z«) skaber en farlig dynamik: Teamet leverer funktioner og betragter sig som færdigt, selv om funktionerne ikke flytter de målepunkter, de skulle flytte. Funktionen blev leveret; problemet blev ikke løst.
Resultatbaserede roadmaps omformulerer hvert punkt som et mål: »Reducér tiden til første værdi for nye brugere fra 4 dage til under 24 timer.« Teamet kan så beslutte – og tage op til fornyet overvejelse – hvordan resultatet nås. Den struktur gør det også langt lettere at nedprioritere en funktion, når du opdager en bedre måde at nå det samme resultat på.
Produktchefen ejer roadmappen. Det betyder, at vedkommende er ansvarlig for dens indhold, dens opdateringer og dens kommunikation til interessenterne. Men ejerskab betyder ikke, at man skriver den alene – de bedste roadmaps bygges i samarbejde med input fra udvikling (om gennemførlighed og indsats), design (om konsekvenser for brugeroplevelsen) og kundevendte teams (om signaler fra markedet).
Det, produktchefen bør modstå, er at lade roadmappen blive til i et udvalg. Interessenter kan give input; de bør ikke have vetoret over enkelte punkter. Produktchefen samler input og træffer beslutningerne. Hvis der er tillid til processen bag dem, er der også tillid til resultaterne.
Kolonnen Nu bør gennemgås hver sprint. Kolonnen Næste bør gennemgås ved starten af hvert kvartal eller hver gang, der kommer væsentlig ny dokumentation (en stor kunde forlader jer, en konkurrent lancerer noget relevant, en udforskningssprint giver et overraskende fund). Kolonnen Senere skal tages op én gang i kvartalet – ikke for at finpudse den, men for at bekræfte, at de retningsgivende satsninger stadig giver mening.
Målet er en roadmap, der aldrig er så forældet, at det er pinligt, men som heller ikke opdateres så ofte, at det skaber uro. De fleste teams hælder til at opdatere for sjældent – roadmappen afspejler beslutninger, der blev truffet for seks måneder siden, og ingen ved helt, hvornår den sidst blev ændret.
Roadmappen bliver fulgt, hvis – og kun hvis – teamet har tillid til den. Den tillid kommer af tre ting: Begrundelsen for hvert punkt er synlig og forsvarlig, teamet har været med til at bygge den og ikke bare fået den udleveret, og produktchefen opdaterer den hurtigt, når omstændighederne ændrer sig, i stedet for at lade som om, den oprindelige plan stadig holder.
En roadmap, der bruges som forhandlingsværktøj eller som et dokument, der er lavet for at tilfredsstille ledelsen, bliver ignoreret i teamet og skaber irritation hos interessenterne. En roadmap, der afspejler ægte overvejelser, reelle afvejninger og ærlig usikkerhed, bliver et redskab, folk rækker ud efter – fordi det faktisk hjælper dem med at beslutte.