La majoria de les roadmaps de producte es abandonen dins d'un trimestre de ser escrites. No perquè els equips siguin indisciplinats, sinó perquè la roadmap es va construir sobre fonaments equivocats: dates fixades, llistes de característiques i desitjos d'stakeholders empaquetats com a pla. Quan la realitat inevitablement divergeix — una característica tarda més, una necessitat del client canvia, un competidor es mou — la roadmap es converteix en ficció, i els equips deixen de mirar-la.
Una roadmap que la gent realment segueix no és un gràfic de Gantt disfressat d'estratègia de producte. És un document viu que representa el millor pensament actual de l'equip sobre l'ordre en què es deuen resoldre els problemes, estructurat per ser honest sobre el que es sap i el que no.
Abans de dissenyar una roadmap, val la pena ser clar sobre el seu propòsit. Una roadmap fa tres coses: comunica la direcció (on anem i per què), força la priorització (no podem fer-ho tot, així que què va primer) i crea una base per a l'alineació (perquè l'enginyeria, el disseny, les vendes i el suport treballin tots vers els mateixos objectius).
Una roadmap no garanteix dates de lliurament. No es compromet amb característiques específiques. I no reemplaça la necessitat de descobriment continu. Si els stakeholders tracten la roadmap com una promesa, això és un problema de procés — no una raó per construir precisió falsa al document.
El format de roadmap més durador per a la majoria d'equips és el model de tres horitzons. És honest sobre la incertesa: els elements en "Ara" es comprometen, els elements en "Següent" es planengen però no es bloquegen, i els elements en "Més tard" són direccionalment vertaders però subjectes a canvi mentre aprens més.
Noti que cada element inclou no només el que és, sinó per què hi és. Una roadmap sense raonament és només una llista. Quan els membres de l'equip entenen per què es va triar cada element, poden prendre millors decisions quan les coses canvien — i poden tenir converses més productives quan un client demana quelcom que no és a la llista.
Les roadmaps basades en característiques ("construir X, construir Y, construir Z") creen una dinàmica perillosa: l'equip envia característiques i ho anomena fet, fins i tot si les característiques no mouen les mètriques que se suposava que havien de moure. La característica es va lliurar; el problema no es va resoldre.
Les roadmaps basades en resultats reemmarquen cada element com un objectiu: "Reduir el temps fins al primer valor dels nous usuaris de 4 dies a menys de 24 hores." L'equip pot llavors decidir — i revisar — com aconseguir aquest resultat. Aquesta estructura també fa molt més fàcil desactivar una característica quan descobreixes una manera millor d'aconseguir el mateix resultat.
El gestor de producte és el propietari de la roadmap. Això significa que és responsable del seu contingut, les seves actualitzacions i la seva comunicació als stakeholders. Però la propietat no significa autoria en solitari — les millors roadmaps es construeixen col·laborativament, amb input de l'enginyeria (sobre viabilitat i esforç), el disseny (sobre implicacions de l'experiència de l'usuari) i els equips de cara al client (sobre senyal de mercat).
El que el PM hauria de resistir és dissenyar la roadmap per comitè. Els stakeholders poden proporcionar input; no haurien de tenir poder de veto sobre elements individuals. El PM sintetitza l'input i fa crides. Si el procés per arribar a aquestes crides és confiable, els resultats també ho seran.
La columna Ara hauria de ser revisada cada sprint. La columna Següent hauria de ser revisada al principi de cada trimestre, o sempre que arribi evidència significativa nova (un cliente principal es va perdre, un competidor llança quelcom relevant, una sprint de descobriment produeix un descobriment sorprenent). La columna Més tard necessita revisió una vegada per trimestre — no per refinar-la, sinó per confirmar que les apostes direccionals encara té sentit.
L'objectiu és una roadmap que mai no està tan passada de moda que sigui vergonyosa, però no actualitzada tan freqüentment que crei ansietat. La majoria d'equips erro cap a infra-actualització — la roadmap reflecteix decisions preses fa sis mesos i ningú tampoc sap quan va canviar per última vegada.
La roadmap serà seguida si — i només si — l'equip confía en ella. Aquesta confiança prové de tres coses: la raonament per a cada element és visible i sòlida, l'equip va estar implicat en construir-la més que rebre-la, i el PM la actualitza promptament quan les circumstàncies canvien en lloc de pretendre que el pla original encara es manté.
Una roadmap que es tracta com una eina de negociació, o com un document produit per satisfer executives, serà ignorada al nivell de l'equip i ressentida al nivell del stakeholder. Una roadmap que reflecteix pensament genuí, compromisos reals i incertesa honesta es convertirà en una eina a la qual la gent es dirigeix — perquè realment els ajuda a decidir.