Useimmat tuotetiekartat hylätään neljänneksen sisällä niiden kirjoittamisesta. Ei siksi, että tiimit olisivat kurittomia, vaan koska tiekartta rakennettiin väärille perustuksille: kiinteille päivämäärille, ominaisuuslistoille ja suunnitelmaksi paketoiduille sidosryhmien toiveille. Kun todellisuus väistämättä poikkeaa suunnitelmasta – ominaisuus vie odotettua kauemmin, asiakastarve muuttuu, kilpailija tekee siirtonsa – tiekartta muuttuu fiktioksi, ja tiimit lakkaavat katsomasta sitä.
Tiekartta, jota ihmiset oikeasti seuraavat, ei ole tuotestrategiaksi puettu Gantt-kaavio. Se on elävä dokumentti, joka edustaa tiimin tämänhetkistä parasta ajattelua siitä, missä järjestyksessä ongelmat pitäisi ratkaista, ja se on jäsennelty rehelliseksi siitä, mitä tiedetään ja mitä ei.
Ennen tiekartan suunnittelua kannattaa olla selvillä sen tarkoituksesta. Tiekartta tekee kolme asiaa: se viestii suunnasta (minne olemme menossa ja miksi), pakottaa priorisoimaan (kaikkea ei voi tehdä, joten mikä tulee ensin) ja luo pohjan yhdenmukaistamiselle (jotta kehitys, suunnittelu, myynti ja tuki työskentelevät kaikki samojen tavoitteiden eteen).
Tiekartta ei takaa toimituspäivämääriä. Se ei sitoudu tiettyihin ominaisuuksiin. Eikä se korvaa jatkuvaa discovery-työtä. Jos sidosryhmät käsittelevät tiekarttaa lupauksena, kyse on prosessiongelmasta – ei syystä rakentaa dokumenttiin valheellista tarkkuutta.
Useimmille tiimeille kestävin tiekarttamuoto on kolmen horisontin malli. Se on rehellinen epävarmuudesta: ”Nyt”-kohdat on sitouduttu tekemään, ”Seuraavaksi”-kohdat on suunniteltu mutta ei lukittu, ja ”Myöhemmin”-kohdat ovat suuntaa antavia mutta muuttuvat oppiessasi lisää.
Huomaa, että jokaisessa kohdassa kerrotaan paitsi mitä se on, myös miksi se on siinä. Tiekartta ilman perusteluja on vain lista. Kun tiimin jäsenet ymmärtävät, miksi jokainen kohta on valittu, he voivat tehdä parempia päätöksiä asioiden muuttuessa – ja käydä tuottavampia keskusteluja, kun asiakas pyytää jotain, mikä ei ole listalla.
Ominaisuuspohjaiset tiekartat (”rakenna X, rakenna Y, rakenna Z”) luovat vaarallisen dynamiikan: tiimi toimittaa ominaisuuksia ja julistaa työn valmiiksi, vaikka ominaisuudet eivät liikuttaisi niitä mittareita, joita niiden piti liikuttaa. Ominaisuus toimitettiin; ongelmaa ei ratkaistu.
Tulospohjaiset tiekartat muotoilevat jokaisen kohdan uudelleen tavoitteeksi: ”Lyhennä uuden käyttäjän aika ensimmäiseen arvoon 4 päivästä alle 24 tuntiin.” Tiimi voi sitten päättää – ja tarkistaa uudelleen – miten tulos saavutetaan. Tämä rakenne tekee myös ominaisuuden alentamisesta prioriteettilistalla paljon helpompaa, kun löydät paremman tavan saavuttaa sama tulos.
Tuotepäällikkö omistaa tiekartan. Se tarkoittaa, että hän vastaa sen sisällöstä, päivityksistä ja viestinnästä sidosryhmille. Omistajuus ei kuitenkaan tarkoita yksin kirjoittamista – parhaat tiekartat rakennetaan yhteistyössä, ja panoksen antavat kehitys (toteutettavuus ja työmäärä), suunnittelu (käyttäjäkokemuksen vaikutukset) ja asiakasrajapinnan tiimit (markkinasignaali).
Tuotepäällikön pitäisi vastustaa tiekartan suunnittelua komiteassa. Sidosryhmät voivat antaa panosta, mutta heillä ei pitäisi olla veto-oikeutta yksittäisiin kohtiin. Tuotepäällikkö kokoaa panokset yhteen ja tekee ratkaisut. Jos näihin ratkaisuihin johtavaan prosessiin luotetaan, myös lopputulokseen luotetaan.
Nyt-sarake pitäisi käydä läpi joka sprintti. Seuraavaksi-sarake pitäisi käydä läpi jokaisen vuosineljänneksen alussa tai aina, kun saadaan merkittävää uutta näyttöä (suuri asiakas poistuu, kilpailija julkaisee jotain olennaista, discovery-sprintti tuottaa yllättävän löydön). Myöhemmin-sarake tarkistetaan kerran vuosineljänneksessä – ei hiottavaksi vaan sen varmistamiseksi, että suuntaa antavat veikkaukset ovat yhä järkeviä.
Tavoitteena on tiekartta, joka ei ole koskaan niin vanhentunut, että se olisi noloa, mutta jota ei päivitetä niin usein, että se aiheuttaa ahdistusta. Useimmat tiimit erehtyvät päivittämään liian harvoin – tiekartta heijastaa kuusi kuukautta sitten tehtyjä päätöksiä, eikä kukaan tiedä tarkalleen, milloin sitä on viimeksi muutettu.
Tiekarttaa noudatetaan, jos – ja vain jos – tiimi luottaa siihen. Luottamus syntyy kolmesta asiasta: jokaisen kohdan perustelu on näkyvillä ja järkevä, tiimi oli mukana rakentamassa sitä sen sijaan, että se olisi annettu valmiina, ja tuotepäällikkö päivittää sen nopeasti olosuhteiden muuttuessa eikä teeskentele alkuperäisen suunnitelman yhä pätevän.
Tiekartta, jota käsitellään neuvotteluvälineenä tai johtajien tyydyttämiseksi tuotettuna dokumenttina, sivuutetaan tiimitasolla ja siitä ärsyynnytään sidosryhmätasolla. Tiekartta, joka heijastaa aitoa ajattelua, todellisia kompromisseja ja rehellistä epävarmuutta, muuttuu työkaluksi, jonka pariin ihmiset palaavat – koska se todella auttaa heitä päättämään.