ज़्यादातर प्रोडक्ट टीमों में बैकलॉग वह जगह है जहाँ अर्जेंसी दम तोड़ देती है। इसमें आने वाली हर चीज़ जोड़े जाने के समय अर्जेंट थी — किसी ग्राहक की शिकायत, सेल्स की माँग, किसी प्रतिस्पर्धी का फ़ीचर, कोई आंतरिक आइडिया। छह महीने बाद भी वह सब वहीं पड़ा है, सब अब भी अर्जेंट लगता है, और कोई ठीक-ठीक नहीं जानता कि अगला काम कौन-सा करें।
समस्या टूल की कमी नहीं है। प्राथमिकता तय करने के दर्जनों फ़्रेमवर्क हैं: RICE, MoSCoW, Kano, ICE, वेटेड स्कोरिंग। समस्या यह है कि ज़्यादातर फ़्रेमवर्क एक तरह की झूठी सटीकता माँगते हैं — अनजानी चीज़ों को संख्याएँ देना — जिससे वे कठोर लगते हैं, जबकि असल में वे सिर्फ़ अंदाज़े को स्प्रेडशीट से गुज़ारकर "साफ़" कर देते हैं।
जो असल में काम करता है वह सरल है: दो आयाम, ईमानदारी से आँके गए, और नतीजे पर अमल करने का अनुशासन।
प्राथमिकता तय करना दो सवालों पर सिमट जाता है। पहला: यह उस नतीजे को कितना सुधारता है जिसकी हमें परवाह है? (प्रभाव।) दूसरा: इसे डिलीवर करने में हमारा कितना खर्च होगा? (प्रयास।) बाकी सब कुछ या तो इन्हीं दोनों का परिष्कार है या इनसे भटकाव।
कॉन्फ़िडेंस (भरोसा) को कभी-कभी तीसरे आयाम की तरह जोड़ा जाता है — "हम प्रभाव को लेकर कितने निश्चित हैं?" — और इसे ध्यान में रखना ठीक है। लेकिन व्यवहार में ज़्यादातर टीमें जानती हैं कि वे कब अंदाज़ा लगा रही हैं। अनुशासन इसमें है कि अंदाज़े को ईमानदारी से अंदाज़ा ही कहा जाए, न कि उसे 1–5 के पैमाने पर स्कोर करके किसी फ़ॉर्मूले में जोड़ दिया जाए।
मुश्किल हिस्सा ग्रिड को समझना नहीं है — मुश्किल हिस्सा इसे भरते समय ईमानदार रहना है। हर टीम के पास ऐसे फ़ीचर होते हैं जिन्हें वे बनाना चाहती हैं, जो असल में "टाइम सिंक" में आते हैं, लेकिन बार-बार "बड़े दाँव" में दोबारा वर्गीकृत हो जाते हैं। यह फ़्रेमवर्क तभी काम करता है जब टीम प्रभाव के बारे में ईमानदार रह सके।
प्रभाव वह आयाम है जिसका आकलन करना टीमों को सबसे कठिन लगता है, क्योंकि इसके लिए अक्सर भविष्य का अनुमान लगाना पड़ता है। लालच यह होता है कि उसे संख्या में स्कोर करके वैज्ञानिक महसूस किया जाए। बेहतर तरीका गुणात्मक है, लेकिन संरचित।
विचाराधीन हर फ़ीचर के लिए तीन सवाल पूछें:
टीमें प्रयास को व्यवस्थित रूप से कम आँकती हैं। यह अच्छी तरह दर्ज है — इसका संबंध प्लानिंग फ़ॉलेसी और आशावाद पूर्वाग्रह से है — और यह उन फ़ीचर के लिए खास तौर पर ज़्यादा दिखता है जो कई सिस्टम को छूते हैं, टीमों के बीच तालमेल माँगते हैं, या ऐसी क्षमताओं से जुड़े हैं जिन्हें टीम ने पहले नहीं बनाया।
दो आदतें मदद करती हैं। पहली, प्रयास को स्कोर करने से पहले हमेशा इंजीनियरिंग से पूछें, बाद में नहीं। जो PM अकेले प्रयास स्कोर करते हैं, वे लगभग हमेशा कम आँकते हैं। दूसरी, "अनजाने अनजान" (unknown unknowns) की धारणा को प्रयास के साफ़ गुणक की तरह इस्तेमाल करें। जो भी फ़ीचर कोडबेस के किसी नए हिस्से, किसी थर्ड-पार्टी API या हाल में टेस्ट न हुए यूज़र फ़्लो को छूता है, उसे साफ़ दिख रहे काम के मुकाबले 1.5 गुना ज़्यादा प्रयास स्कोर मिलना चाहिए।
प्रोडक्ट बैकलॉग की ज़्यादातर अर्जेंसी असली अर्जेंसी नहीं है — वह रीसेंसी (ताज़ा होना) है। किसी ग्राहक ने पिछले हफ़्ते शिकायत की, इसलिए उसकी माँग दबाव वाली लगती है। किसी प्रतिस्पर्धी ने पिछले महीने कुछ लॉन्च किया, इसलिए उसकी बराबरी करना ज़रूरी लगता है। लेकिन ताज़ा होना और अहम होना एक बात नहीं है, और रीसेंसी पर प्रतिक्रिया देना असल में ज़रूरी काम को फिसल जाने देने के सबसे भरोसेमंद तरीकों में से एक है।
एक व्यावहारिक कसौटी: खुद से पूछें कि अगर आपने इसके बारे में पिछले हफ़्ते के बजाय छह महीने पहले सुना होता, तो क्या आप अब भी इसे अर्जेंट मानते? अगर जवाब नहीं है, तो यह रीसेंसी बायस का असर है, रणनीतिक प्राथमिकता नहीं। इसे लॉग करें, ग्रिड के हिसाब से इसका शांति से मूल्यांकन करें, और सिर्फ़ इसलिए कि यह ताज़ा है, इसे फ़ास्ट-ट्रैक करने की खिंचावट का विरोध करें।
ग्रिड हर बार साफ़ जवाब नहीं देता। दो आइटम एक ही चतुर्थांश में, मिलते-जुलते स्कोर के साथ आते हैं, और फिर भी आपको एक चुनना है। ऐसे मामलों में दो टाई-ब्रेकर उपयोगी हैं: रणनीतिक तालमेल (कौन-सा आपको 18 महीने बाद जहाँ आप होना चाहते हैं, वहाँ के ज़्यादा करीब पहुँचाता है?) और प्रतिवर्तीता (अगर यह गलत निकला तो किसे पलटना ज़्यादा कठिन है?)। उस आइटम को प्राथमिकता दें जो रणनीतिक रूप से ज़्यादा मेल खाता हो और ज़्यादा आसानी से पलटा जा सके।