ज़्यादातर प्रोडक्ट रोडमैप लिखे जाने के एक तिमाही के भीतर ही छोड़ दिए जाते हैं। इसलिए नहीं कि टीमें अनुशासनहीन हैं, बल्कि इसलिए कि रोडमैप गलत बुनियाद पर बना था: तय तारीख़ें, फ़ीचर की सूचियाँ और स्टेकहोल्डर्स की इच्छाएँ, जिन्हें योजना बनाकर पेश कर दिया गया। जब हक़ीक़त अनिवार्य रूप से अलग राह पकड़ती है — कोई फ़ीचर ज़्यादा समय लेता है, ग्राहक की ज़रूरत बदल जाती है, कोई प्रतिस्पर्धी नई चाल चलता है — तो रोडमैप कल्पना बन जाता है, और टीमें उसे देखना बंद कर देती हैं।
जिस रोडमैप पर लोग सच में चलते हैं, वह प्रोडक्ट रणनीति का भेस धरे गैंट चार्ट नहीं होता। वह एक जीवंत दस्तावेज़ होता है, जो इस बारे में टीम की मौजूदा सबसे अच्छी सोच दर्शाता है कि समस्याएँ किस क्रम में हल की जाएँ, और इस तरह बना होता है कि जो पता है और जो नहीं पता, उसके बारे में ईमानदार रहे।
रोडमैप डिज़ाइन करने से पहले उसके मक़सद को साफ़ कर लेना ज़रूरी है। रोडमैप तीन काम करता है: दिशा बताता है (हम कहाँ जा रहे हैं और क्यों), प्राथमिकताएँ तय करने पर मजबूर करता है (हम सब कुछ नहीं कर सकते, तो सबसे पहले क्या), और तालमेल की बुनियाद बनाता है (ताकि इंजीनियरिंग, डिज़ाइन, सेल्स और सपोर्ट, सब एक ही लक्ष्यों की ओर काम करें)।
रोडमैप डिलीवरी की तारीख़ों की गारंटी नहीं देता। वह किन्हीं ख़ास फ़ीचर के लिए प्रतिबद्ध नहीं होता। और वह लगातार चलने वाली डिस्कवरी की ज़रूरत की जगह नहीं लेता। अगर स्टेकहोल्डर्स रोडमैप को वादा मान लेते हैं, तो यह प्रक्रिया की समस्या है — दस्तावेज़ में झूठी सटीकता डाल देने की वजह नहीं।
ज़्यादातर टीमों के लिए सबसे टिकाऊ रोडमैप फ़ॉर्मैट तीन-हॉराइज़न मॉडल है। यह अनिश्चितता के बारे में ईमानदार है: "अभी" के आइटम तय हैं, "अगला" के आइटम योजना में हैं पर पक्के नहीं, और "बाद में" के आइटम दिशा के लिहाज़ से सही हैं पर जैसे-जैसे आप ज़्यादा सीखेंगे, बदल सकते हैं।
ध्यान दें कि हर आइटम में सिर्फ़ यह नहीं बताया गया कि वह क्या है, बल्कि यह भी कि वह वहाँ क्यों है। तर्क के बिना रोडमैप बस एक सूची है। जब टीम के सदस्य समझते हैं कि हर आइटम क्यों चुना गया, तो हालात बदलने पर वे बेहतर फ़ैसले ले पाते हैं — और जब कोई ग्राहक ऐसी चीज़ माँगता है जो सूची में नहीं है, तब वे ज़्यादा काम की बातचीत कर पाते हैं।
फ़ीचर-आधारित रोडमैप ("X बनाओ, Y बनाओ, Z बनाओ") एक ख़तरनाक चलन पैदा करते हैं: टीम फ़ीचर शिप करती है और उसे पूरा मान लेती है, भले ही उन फ़ीचर ने वे मेट्रिक्स न हिलाए हों जिन्हें हिलाना उनका काम था। फ़ीचर डिलीवर हो गया; समस्या हल नहीं हुई।
आउटकम-आधारित रोडमैप हर आइटम को एक लक्ष्य के रूप में नए सिरे से गढ़ते हैं: "नए यूज़र्स के लिए पहली वैल्यू तक पहुँचने का समय 4 दिन से घटाकर 24 घंटे से कम करें।" फिर टीम तय कर सकती है — और दोबारा तय भी कर सकती है — कि उस नतीजे तक कैसे पहुँचना है। इस ढाँचे में किसी फ़ीचर की प्राथमिकता घटाना भी बहुत आसान हो जाता है, जब आपको उसी नतीजे तक पहुँचने का बेहतर तरीक़ा मिल जाए।
रोडमैप का मालिक प्रोडक्ट मैनेजर होता है। इसका मतलब है कि वह उसकी सामग्री, उसके अपडेट और स्टेकहोल्डर्स तक उसके संवाद के लिए जवाबदेह है। लेकिन मालिकाना हक़ का मतलब अकेले लिखना नहीं है — सबसे अच्छे रोडमैप मिलकर बनाए जाते हैं, जिनमें इंजीनियरिंग (व्यावहारिकता और मेहनत पर), डिज़ाइन (यूज़र एक्सपीरियंस पर असर पर) और ग्राहकों से सीधे जुड़ी टीमों (बाज़ार के संकेतों पर) का इनपुट शामिल हो।
PM को जिस चीज़ से बचना चाहिए, वह है कमेटी बनाकर रोडमैप डिज़ाइन करना। स्टेकहोल्डर्स इनपुट दे सकते हैं; अलग-अलग आइटम पर उनके पास वीटो का अधिकार नहीं होना चाहिए। PM इनपुट को समेटता है और फ़ैसले लेता है। अगर उन फ़ैसलों तक पहुँचने की प्रक्रिया पर भरोसा किया जाता है, तो नतीजों पर भी किया जाएगा।
"अभी" कॉलम की समीक्षा हर स्प्रिंट होनी चाहिए। "अगला" कॉलम की समीक्षा हर तिमाही की शुरुआत में, या जब भी कोई अहम नया सबूत आए (कोई बड़ा ग्राहक चर्न हो जाए, कोई प्रतिस्पर्धी कुछ प्रासंगिक लॉन्च करे, कोई डिस्कवरी स्प्रिंट चौंकाने वाला निष्कर्ष दे)। "बाद में" कॉलम को हर तिमाही एक बार देखना होगा — उसे और निखारने के लिए नहीं, बल्कि यह पक्का करने के लिए कि दिशा वाले दाँव अब भी सही लगते हैं।
लक्ष्य ऐसा रोडमैप है जो इतना पुराना कभी न पड़े कि शर्मिंदगी हो, पर इतनी बार भी अपडेट न हो कि बेचैनी पैदा करे। ज़्यादातर टीमें कम अपडेट करने की ओर झुकती हैं — रोडमैप छह महीने पहले लिए गए फ़ैसलों को दिखाता है और किसी को ठीक से पता नहीं कि वह आख़िरी बार कब बदला था।
रोडमैप का पालन तभी होगा — और सिर्फ़ तभी — जब टीम उस पर भरोसा करे। यह भरोसा तीन चीज़ों से आता है: हर आइटम का तर्क दिखाई देता हो और ठोस हो, टीम को रोडमैप थमाया न गया हो बल्कि बनाने में वह शामिल रही हो, और हालात बदलने पर PM उसे फ़ौरन अपडेट करे, यह दिखावा करने के बजाय कि मूल योजना अब भी लागू है।
जिस रोडमैप को मोलभाव का औज़ार माना जाए, या एग्ज़ीक्यूटिव्स को संतुष्ट करने के लिए बनाया गया दस्तावेज़, उसे टीम के स्तर पर अनदेखा किया जाएगा और स्टेकहोल्डर्स के स्तर पर नाराज़गी झेलनी पड़ेगी। जो रोडमैप सच्ची सोच, असली ट्रेड-ऑफ़ और ईमानदार अनिश्चितता को दर्शाता है, वह ऐसा औज़ार बन जाएगा जिसकी ओर लोग ख़ुद बढ़ते हैं — क्योंकि वह सच में उन्हें फ़ैसले लेने में मदद करता है।