De fleste produktveikart blir forlatt innen et kvartal etter at de er skrevet. Ikke fordi teamene er udisiplinerte, men fordi veikartet ble bygget på feil grunnlag: faste datoer, funksjonslister og ønsker fra interessenter pakket inn som en plan. Når virkeligheten uunngåelig avviker — en funksjon tar lengre tid, et kundebehov endrer seg, en konkurrent gjør et trekk — blir veikartet fiksjon, og teamene slutter å se på det.
Et veikart som folk faktisk følger, er ikke et Gantt-diagram utkledd som produktstrategi. Det er et levende dokument som viser teamets beste tenkning akkurat nå om rekkefølgen problemene bør løses i, og som er bygget for å være ærlig om hva som er kjent og hva som ikke er det.
Før du designer et veikart, er det verdt å være tydelig på formålet. Et veikart gjør tre ting: det kommuniserer retning (hvor skal vi, og hvorfor), det tvinger fram prioritering (vi kan ikke gjøre alt, så hva kommer først), og det skaper grunnlag for samkjøring (slik at utvikling, design, salg og support jobber mot de samme målene).
Et veikart garanterer ikke leveringsdatoer. Det forplikter seg ikke til bestemte funksjoner. Og det erstatter ikke behovet for løpende innsiktsarbeid. Hvis interessentene behandler veikartet som et løfte, er det et prosessproblem — ikke en grunn til å bygge falsk presisjon inn i dokumentet.
Det mest holdbare veikartformatet for de fleste team er tre-horisont-modellen. Den er ærlig om usikkerhet: elementene under «Nå» er forpliktet, elementene under «Neste» er planlagt, men ikke låst, og elementene under «Senere» er retningsgivende riktige, men kan endres etter hvert som du lærer mer.
Legg merke til at hvert element ikke bare sier hva det er, men også hvorfor det står der. Et veikart uten begrunnelse er bare en liste. Når teammedlemmene forstår hvorfor hvert element ble valgt, kan de ta bedre beslutninger når ting endrer seg — og de kan ha mer produktive samtaler når en kunde ber om noe som ikke står på listen.
Funksjonsbaserte veikart («bygg X, bygg Y, bygg Z») skaper en farlig dynamikk: teamet leverer funksjoner og regner jobben som gjort, selv om funksjonene ikke flytter metrikkene de skulle flytte. Funksjonen ble levert; problemet ble ikke løst.
Resultatbaserte veikart omformulerer hvert element som et mål: «Reduser tiden til første verdi for nye brukere fra 4 dager til under 24 timer.» Teamet kan deretter bestemme — og ta opp igjen — hvordan resultatet skal nås. Denne strukturen gjør det også mye enklere å nedprioritere en funksjon når du finner en bedre måte å nå samme resultat på.
Produktsjefen eier veikartet. Det betyr at vedkommende er ansvarlig for innholdet, oppdateringene og kommunikasjonen til interessentene. Men eierskap betyr ikke at man skriver det alene — de beste veikartene bygges i samarbeid, med innspill fra utvikling (om gjennomførbarhet og innsats), design (om konsekvenser for brukeropplevelsen) og kundevendte team (om signaler fra markedet).
Det produktsjefen bør motstå, er å utforme veikartet i komité. Interessenter kan gi innspill; de bør ikke ha vetorett over enkeltelementer. Produktsjefen samler innspillene og tar avgjørelsene. Hvis det er tillit til prosessen som fører fram til avgjørelsene, vil det også være tillit til resultatet.
Nå-kolonnen bør gjennomgås hver sprint. Neste-kolonnen bør gjennomgås ved starten av hvert kvartal, eller når det kommer betydelige nye bevis (en stor kunde slutter, en konkurrent lanserer noe relevant, en innsiktssprint gir et overraskende funn). Senere-kolonnen må gjennomgås én gang i kvartalet — ikke for å finpusse den, men for å bekrefte at de retningsgivende satsingene fortsatt gir mening.
Målet er et veikart som aldri er så utdatert at det er pinlig, men heller ikke oppdateres så ofte at det skaper uro. De fleste team feiler ved å oppdatere for sjelden — veikartet gjenspeiler beslutninger tatt for seks måneder siden, og ingen er helt sikre på når det sist ble endret.
Veikartet blir fulgt hvis — og bare hvis — teamet stoler på det. Den tilliten kommer fra tre ting: begrunnelsen for hvert element er synlig og solid, teamet var med på å bygge det i stedet for å få det utlevert, og produktsjefen oppdaterer det raskt når forholdene endrer seg, i stedet for å late som om den opprinnelige planen fortsatt gjelder.
Et veikart som behandles som et forhandlingsverktøy, eller som et dokument laget for å tilfredsstille ledelsen, blir ignorert på teamnivå og tatt dårlig imot hos interessentene. Et veikart som gjenspeiler ekte tenkning, reelle avveininger og ærlig usikkerhet, blir et verktøy folk griper til — fordi det faktisk hjelper dem å bestemme seg.