De fleste produktroadmaps blir forlatt innen et kvartal av det de skrives. Ikke fordi team er udisiplinert, men fordi roadmapen ble bygget på feil grunnlag: faste datoer, featurelister og interessentkrav pakket som en plan. Når virkeligheten uunngåelig avviker —en feature tar lengre tid, et kundeunnslipp endrer seg, en konkurrent beveger seg— blir roadmapen fiksjon, og team slutter å se på den.
En roadmap som folk faktisk følger er ikke et Gantt-diagram kledd som produktstrategi. Det er et levende dokument som representerer teamets nåværende beste tenking om rekkefølgen som problemer burde løses, strukturert for å være ærlig om hva som er kjent og hva som ikke er det.
Før du designet en roadmap, er det verdt å være klar på dens formål. En roadmap gjør tre ting: den kommuniserer retning (hvor går vi og hvorfor), den tvinger priorisering (vi kan ikke gjøre alt, så hva kommer først), og den skaper et grunnlag for justering (slik at ingeniør, design, salg og support alle jobber mot samme mål).
En roadmap garanterer ikke leveringsdatoer. Den forplikter seg ikke til spesifikke features. Og den erstatter ikke behovet for løpende oppdagelse. Hvis interessenter behandler roadmapen som et løfte, er det et prosessprøblem —ikke en grunn til å bygge falsk presisjon inn i dokumentet.
Det mest holdbare roadmap-formatet for de fleste team er tre-horisont-modellen. Det er ærlig om usikkerhet: elementer i "Nå" er forpliktet, elementer i "Neste" er planlagt men ikke låst, og elementer i "Senere" er retningsgivende sant men underlagt endring når du lærer mer.
Legg merke til at hvert element inkluderer ikke bare hva det er, men hvorfor det er der. En roadmap uten begrunnelse er bare en liste. Når teammedlemmer forstår hvorfor hver element ble valgt, kan de ta bedre avgjørelser når ting endrer seg —og de kan ha mer produktive samtaler når en kunde ber om noe som ikke er på listen.
Feature-baserte roadmaps ("bygg X, bygg Y, bygg Z") skaper en farlig dynamikk: teamet leverer features og kaller det ferdig, selv om features ikke beveger metrikken de skulle bevege. Featureen ble levert; problemet ble ikke løst.
Outcome-baserte roadmaps omrammer hver element som et mål: "Reduser tid-til-første-verdi for nye brukere fra 4 dager til under 24 timer." Teamet kan så avgjøre —og gjenbesøke— hvordan oppnå det resultatet. Denne strukturen gjør det også mye lettere å deprioritere en feature når du oppdager en bedre måte å nå samme resultat.
Produktsjef eier roadmapen. Det betyr de er ansvarlig for innholdet, oppdateringene og kommunikasjonen til interessenter. Men eierskap betyr ikke solo-forfatting —de beste roadmaps bygges samarbeidende, med innspill fra ingeniørvetenskap (på mulig og innsats), design (på brukergrensesnitt implikasjoner), og kundevendt team (på markedssignal).
Hva PM burde motvirke er å utforme roadmapen ved komité. Interessenter kan gi innspill; de burde ikke ha vetorett over individuelle elementer. PM syntetiserer innspill og gjør samtal. Hvis prosessen for å nå de samtalene er pålitelig, vil utgangene også være det.
Nå-kolonnen burde gjennomgås hver sprint. Neste-kolonnen burde gjennomgås ved starten av hvert kvartal, eller når betydelig ny bevis ankommer (en stor kunde churner, en konkurrent lanserer noe relevant, en oppdagelsessprint produserer en overraskende funn). Senere-kolonnen trenger gjennomgang en gang per kvartal —ikke for å raffinere den, men for å bekrefte at de retningsgivende veddemålene fortsatt gir mening.
Målet er en roadmap som aldri er flat nok til å være flau, men ikke oppdatert så hyppig at den skaper angst. De fleste team feiler mot under-oppdatering —roadmapen gjenspeiler avgjørelser gjort seks måneder siden og ingen er helt sikker på når den sist endret.
Roadmapen blir fulgt hvis —og bare hvis— teamet stoler på den. Den tilliten kommer fra tre ting: begrunnelsen for hvert element er synlig og solid, teamet var involvert i byggingen snarere enn overlevert det, og PM oppdaterer det raskt når omstendighetene endrer snarere enn å late som den originale planen fortsatt holder.
En roadmap som behandles som et forhandlingsverktøy, eller som et dokument produsert for å tilfredsstille sjefene, blir ignorert på teamnivå og resent på interessentnivå. En roadmap som gjenspeiler genuint tenking, virkelig avveiinger og ærlig usikkerhet blir et verktøy folk når for —fordi det faktisk hjelper dem å avgjøre.