Majoritatea roadmap-urilor de produs sunt abandonate în mai puțin de un trimestru de la redactare. Nu pentru că echipele ar fi indisciplinate, ci pentru că roadmap-ul a fost construit pe temelii greșite: date fixe, liste de funcționalități și dorințe ale părților interesate ambalate drept plan. Când realitatea se abate inevitabil — o funcționalitate durează mai mult, nevoia unui client se schimbă, un competitor face o mișcare — roadmap-ul devine ficțiune, iar echipele nu se mai uită la el.
Un roadmap pe care oamenii îl urmează cu adevărat nu este o diagramă Gantt deghizată în strategie de produs. Este un document viu, care reflectă cea mai bună gândire actuală a echipei despre ordinea în care ar trebui rezolvate problemele, structurat astfel încât să fie sincer cu privire la ce se știe și ce nu.
Înainte de a proiecta un roadmap, merită să fie clar scopul lui. Un roadmap face trei lucruri: comunică direcția (încotro mergem și de ce), impune prioritizarea (nu putem face totul, deci ce vine primul) și creează o bază pentru aliniere (astfel încât inginerii, designerii, vânzările și suportul să lucreze toți spre aceleași obiective).
Un roadmap nu garantează termene de livrare. Nu se angajează la funcționalități anume. Și nu înlocuiește nevoia de descoperire continuă (discovery). Dacă părțile interesate tratează roadmap-ul ca pe o promisiune, aceasta este o problemă de proces — nu un motiv pentru a introduce o precizie falsă în document.
Cel mai durabil format de roadmap pentru majoritatea echipelor este modelul cu trei orizonturi. Este sincer cu privire la incertitudine: elementele din „Acum” sunt asumate, cele din „Următorul” sunt planificate, dar nu blocate, iar cele din „Mai târziu” sunt corecte ca direcție, dar pot suferi modificări pe măsură ce afli mai multe.
Observă că fiecare element include nu doar ce este, ci și de ce se află acolo. Un roadmap fără motivare este doar o listă. Când membrii echipei înțeleg de ce a fost ales fiecare element, pot lua decizii mai bune atunci când lucrurile se schimbă — și pot purta discuții mai productive atunci când un client cere ceva ce nu se află pe listă.
Roadmap-urile bazate pe funcționalități („construim X, construim Y, construim Z”) creează o dinamică periculoasă: echipa livrează funcționalități și consideră treaba încheiată, chiar dacă acestea nu mișcă metricile pe care trebuiau să le mișce. Funcționalitatea a fost livrată; problema nu a fost rezolvată.
Roadmap-urile bazate pe rezultate reformulează fiecare element ca pe un obiectiv: „Reducem timpul până la prima valoare pentru utilizatorii noi de la 4 zile la sub 24 de ore.” Echipa poate apoi decide — și reevalua — cum atinge acel rezultat. Această structură face, de asemenea, mult mai ușor să retrogradezi o funcționalitate din priorități când descoperi o cale mai bună spre același rezultat.
Roadmap-ul aparține product manager-ului. Asta înseamnă că acesta răspunde de conținutul lui, de actualizări și de comunicarea către părțile interesate. Dar a-l deține nu înseamnă a-l scrie singur — cele mai bune roadmap-uri se construiesc în colaborare, cu aportul ingineriei (privind fezabilitatea și efortul), al designului (privind implicațiile pentru experiența utilizatorului) și al echipelor care lucrează cu clienții (privind semnalele din piață).
Ceea ce PM-ul trebuie să evite este proiectarea roadmap-ului prin comitet. Părțile interesate pot oferi feedback; nu ar trebui să aibă drept de veto asupra elementelor individuale. PM-ul sintetizează opiniile și ia deciziile. Dacă procesul prin care se ajunge la acele decizii este de încredere, rezultatele vor fi și ele.
Coloana Acum ar trebui revizuită la fiecare sprint. Coloana Următorul ar trebui revizuită la începutul fiecărui trimestru sau ori de câte ori apar dovezi noi semnificative (un client important pleacă, un competitor lansează ceva relevant, un sprint de discovery produce o constatare surprinzătoare). Coloana Mai târziu trebuie reluată o dată pe trimestru — nu pentru a o rafina, ci pentru a confirma că pariurile direcționale au încă sens.
Scopul este un roadmap care nu devine niciodată atât de depășit încât să fie jenant, dar nici nu este actualizat atât de des încât să creeze anxietate. Majoritatea echipelor greșesc prin actualizare insuficientă — roadmap-ul reflectă decizii luate acum șase luni și nimeni nu mai știe exact când s-a schimbat ultima dată.
Roadmap-ul va fi urmat dacă — și numai dacă — echipa are încredere în el. Această încredere vine din trei lucruri: motivarea fiecărui element este vizibilă și solidă, echipa a participat la construirea lui, în loc să îl primească de-a gata, iar PM-ul îl actualizează prompt când circumstanțele se schimbă, în loc să se prefacă că planul inițial încă se menține.
Un roadmap tratat ca instrument de negociere sau ca document produs pentru a mulțumi conducerea va fi ignorat la nivelul echipei și resimțit negativ la nivelul părților interesate. Un roadmap care reflectă o gândire autentică, compromisuri reale și incertitudine asumată va deveni un instrument la care oamenii apelează — pentru că îi ajută cu adevărat să decidă.