De flesta produktroadmaps överges inom ett kvartal efter att de skrivits. Inte för att teamen är odisciplinerade, utan för att roadmapen byggdes på fel grund: fasta datum, funktionslistor och intressenters önskemål förpackade som en plan. När verkligheten oundvikligen avviker, en funktion tar längre tid, ett kundbehov förskjuts eller en konkurrent gör ett drag, blir roadmapen fiktion och teamen slutar titta på den.
En roadmap som människor faktiskt följer är inte ett Gantt-schema förklätt till produktstrategi. Det är ett levande dokument som speglar teamets aktuella bästa bedömning av i vilken ordning problemen bör lösas, uppbyggt för att vara ärligt om vad som är känt och vad som inte är det.
Innan du utformar en roadmap är det värt att vara tydlig med syftet. En roadmap gör tre saker: den förmedlar riktning (vart är vi på väg och varför), den tvingar fram prioriteringar (vi kan inte göra allt, så vad kommer först) och den skapar underlag för samsyn (så att utveckling, design, sälj och support alla arbetar mot samma mål).
En roadmap garanterar inte leveransdatum. Den utlovar inte specifika funktioner. Och den ersätter inte behovet av löpande discovery. Om intressenter behandlar roadmapen som ett löfte är det ett processproblem, inte ett skäl att bygga in falsk precision i dokumentet.
Det mest hållbara roadmapformatet för de flesta team är modellen med tre horisonter. Den är ärlig om osäkerhet: punkterna under ”Nu” är beslutade, punkterna under ”Nästa” är planerade men inte låsta, och punkterna under ”Senare” är riktningsgivande men kan ändras allteftersom ni lär er mer.
Lägg märke till att varje punkt inte bara anger vad den är, utan också varför den finns med. En roadmap utan motivering är bara en lista. När teammedlemmar förstår varför varje punkt valdes kan de fatta bättre beslut när förutsättningarna ändras, och de kan föra mer givande samtal när en kund efterfrågar något som inte finns på listan.
Funktionsbaserade roadmaps (”bygg X, bygg Y, bygg Z”) skapar en farlig dynamik: teamet levererar funktioner och betraktar det som klart, även om funktionerna inte flyttar de mått de skulle flytta. Funktionen levererades, men problemet löstes inte.
Resultatbaserade roadmaps omformulerar varje punkt som ett mål: ”Minska tiden till första värde för nya användare från 4 dagar till under 24 timmar.” Teamet kan sedan avgöra, och ompröva, hur resultatet ska nås. Den strukturen gör det också mycket enklare att prioritera ned en funktion när ni hittar ett bättre sätt att nå samma resultat.
Produktchefen äger roadmapen. Det innebär att hen ansvarar för innehållet, uppdateringarna och kommunikationen till intressenterna. Men ägarskap betyder inte ensam författare: de bästa roadmaps byggs gemensamt, med input från utveckling (om genomförbarhet och insats), design (om konsekvenser för användarupplevelsen) och kundnära team (om marknadssignaler).
Det produktchefen bör motstå är att utforma roadmapen i kommitté. Intressenter kan bidra med input, men de ska inte ha vetorätt över enskilda punkter. Produktchefen sammanställer input och fattar besluten. Om processen bakom besluten är betrodd, blir resultaten det också.
Kolumnen Nu bör gås igenom varje sprint. Kolumnen Nästa bör gås igenom i början av varje kvartal, eller när betydande nya belägg dyker upp (en stor kund lämnar, en konkurrent lanserar något relevant, en discovery-sprint ger ett överraskande fynd). Kolumnen Senare behöver ses över en gång per kvartal, inte för att förfina den utan för att bekräfta att de riktningsgivande satsningarna fortfarande är rimliga.
Målet är en roadmap som aldrig är så inaktuell att det blir pinsamt, men som inte uppdateras så ofta att den skapar oro. De flesta team uppdaterar för sällan: roadmapen speglar beslut som fattades för sex månader sedan och ingen vet riktigt när den senast ändrades.
Roadmapen följs om, och bara om, teamet litar på den. Det förtroendet bygger på tre saker: motiveringen till varje punkt är synlig och hållbar, teamet var med och byggde den i stället för att få den serverad, och produktchefen uppdaterar den snabbt när omständigheterna ändras i stället för att låtsas att den ursprungliga planen fortfarande gäller.
En roadmap som behandlas som ett förhandlingsverktyg, eller som ett dokument som tas fram för att tillfredsställa ledningen, ignoreras på teamnivå och möts av förargelse hos intressenterna. En roadmap som speglar genuint tänkande, verkliga avvägningar och ärlig osäkerhet blir ett verktyg som människor tar till, eftersom den faktiskt hjälper dem att fatta beslut.