10.14 उत्पाद प्रबंधन और डिस्कवरी

अवलोकन और प्रेरणा

उत्पाद प्रबंधन यह तय करने का अनुशासन है कि क्या बनाया जाए और क्यों बनाया जाए, और इस बात के लिए जवाबदेह होना कि वह काम करता है या नहीं। एक प्रोडक्ट मैनेजर समस्या, ग्राहक और परिणाम का स्वामी होता है। वे शेड्यूल, टिकट कतार, या किसी हितधारक द्वारा सौंपी गई फीचर चेकलिस्ट के स्वामी नहीं होते। यही अंतर पूरे अध्याय को एक वाक्य में समेट देता है। जब उत्पाद प्रबंधन सिमटकर परियोजना समन्वय या आदेश लेने (order-taking) में बदल जाता है, तो टीम एक “फीचर फैक्ट्री” बन जाती है: वह लगातार शिप करती रहती है, अपनी वेलोसिटी के आंकड़े पूरे करती है, लेकिन किसी भी व्यावसायिक मेट्रिक को आगे नहीं बढ़ाती। यह भूमिका ठीक इसी को रोकने के लिए मौजूद है।

बड़ी टीमों के लिए, कमज़ोर उत्पाद प्रबंधन चुपचाप सबसे महंगी विफलता है। इंजीनियरिंग शानदार हो सकती है, डिलीवरी तेज़ हो सकती है, और फिर भी पूरी मशीन एक साल तक पूरी दक्षता के साथ गलत चीज़ बना सकती है। इसकी लागत किसी इंजीनियरिंग डैशबोर्ड पर कभी नहीं दिखती। यह सपाट राजस्व, ग्राहकों के जाने (churn), और ऐसी सुविधाओं के बैकलॉग के रूप में सामने आती है जिन्हें कोई इस्तेमाल नहीं करता लेकिन जिन्हें अब सभी को बनाए रखना पड़ता है। अच्छा उत्पाद प्रबंधन इस जोखिम को पैसा खर्च करने से पहले ही दृश्यमान बना देता है, इस बात पर ज़ोर देकर कि लक्ष्य स्पष्ट, मापने योग्य, और किसी वास्तविक ग्राहक समस्या से जुड़े हों।

एंटरप्राइज़ और सरकारी परिवेश दांव को और ऊंचा कर देते हैं और काम के स्वरूप को बदल देते हैं। एंटरप्राइज़ तेज़ी से परियोजना संचालन मॉडल (एक परियोजना को फंड करो, उसे शिप करो, टीम भंग कर दो) से उत्पाद संचालन मॉडल (टिकाऊ टीमों को फंड करो जो वर्षों तक परिणामों की स्वामी बनी रहें) की ओर बढ़ रहे हैं, और आंतरिक प्लेटफ़ॉर्मों को वास्तविक ग्राहकों वाले उत्पादों के रूप में देख रहे हैं। सरकारें भी उपयोगकर्ता-केंद्रित डिज़ाइन (user-centred design) के बैनर तले यही सबक सीख रही हैं: परियोजनाओं को नहीं, सेवाओं को फंड करो, और यह मापो कि नागरिकों की वास्तव में सेवा हो रही है या नहीं। यह अध्याय उसी मानसिकता और उन तंत्रों के बारे में है जो इस बदलाव को वास्तविक बनाते हैं। यह अध्याय 11.1 (डिस्कवरी पाइपलाइन) के साथ मिलकर काम करता है, जो पाइपलाइन तंत्र का विस्तार से वर्णन करता है; यहां हम भूमिका, रणनीति, और डिस्कवरी की दैनिक आदतों पर ध्यान केंद्रित करते हैं।

मुख्य सिद्धांत

• “क्या” और “क्यों” के स्वामी बनें। प्रोडक्ट मैनेजर परिणामों के लिए जवाबदेह होते हैं, कार्यों के समन्वय के लिए नहीं।
• आउटपुट पर आउटकम को प्राथमिकता दें। शिप करना एक लागत है, परिणाम नहीं। परिणाम एक बदला हुआ ग्राहक या व्यावसायिक मेट्रिक है।
• ग्राहक और समस्या को किसी से भी बेहतर जानें। ग्राहक संपर्क के बिना रणनीति केवल अटकल है।
• डिस्कवरी निरंतर चलती है, यह कोई चरण नहीं है। आप डिलीवरी के समानांतर हर हफ्ते ग्राहकों से बात करते हैं।
• प्राथमिकता निर्धारण ढांचे निर्णय-सहायक हैं, दैवज्ञ (oracle) नहीं। आंकड़े निर्णय को सूचित करते हैं; वे निर्णय नहीं लेते।
• रोडमैप इरादे के बयान हैं, तारीख़ वाले वादे नहीं। समस्याओं के प्रति दृढ़ता से प्रतिबद्ध रहें और समाधानों के प्रति ढीले ढंग से।
• त्रिगुट (trio) को सशक्त बनाएं। उत्पाद, डिज़ाइन, और इंजीनियरिंग मिलकर निर्णय लेते हैं; अकेला प्रोडक्ट मैनेजर बुरा निर्णय लेता है।

सिफारिशें

“क्या” और “क्यों” के स्वामी बनें, और टीम को “कैसे” का स्वामी बनने दें

यह जांचने का सबसे स्पष्ट तरीका कि उत्पाद प्रबंधन स्वस्थ है या नहीं, यह देखना है कि कौन सा प्रश्न किसका है। प्रोडक्ट मैनेजर हम किस समस्या को हल कर रहे हैं और अभी यह क्यों मायने रखती है का स्वामी होता है। डिज़ाइन इस बात का स्वामी है कि उपयोगकर्ता के लिए यह कैसा महसूस होना चाहिए। इंजीनियरिंग इस बात की स्वामी है कि हम इसे कैसे बनाएं। जब कोई प्रोडक्ट मैनेजर समाधान, समय-सीमाएं, और कार्यान्वयन तय करने लगता है, तो वे उत्पाद के शीर्षक वाले एक प्रोजेक्ट मैनेजर बन जाते हैं, और वे ठीक उसी स्वायत्तता को छीन लेते हैं जो एक सशक्त टीम को प्रभावी बनाती है (अध्याय 5.1 डिज़ाइन साझेदारी को कवर करता है, अध्याय 10.7 एजाइल डिलीवरी मॉडल को कवर करता है)।

एक सशक्त उत्पाद टीम, जिसे कभी-कभी प्रोडक्ट त्रिगुट (product trio) कहा जाता है, उत्पाद, डिज़ाइन, और इंजीनियरिंग को एक साथ लेकर काम करती है, जिसे एक फीचर बनाने के बजाय एक समस्या हल करने के लिए दिया जाता है। यही “नए उपयोगकर्ताओं के लिए 30-दिन की रिटेंशन बढ़ाएं” और “मार्च तक नोटिफिकेशन सेंटर बनाएं” के बीच का अंतर है। पहला टीम को सर्वोत्तम समाधान खोजने के लिए सशक्त बनाता है और उन्हें परिणाम के लिए जवाबदेह ठहराता है। दूसरा उन्हें एक डिलीवरी शाखा में घटा देता है और चुपचाप गलत होने का जोखिम उस व्यक्ति पर स्थानांतरित कर देता है जिसने आवश्यकता लिखी थी। यदि आप परिणामों के लिए जवाबदेही चाहते हैं, तो आपको आउटपुट पर नियंत्रण छोड़ना होगा।

ग्राहक पर आधारित उत्पाद विज़न और रणनीति निर्धारित करें

एक उत्पाद रणनीति कठिन विकल्पों का एक छोटा समूह है , कि आप किन ग्राहकों की सेवा करते हैं, उनके लिए किन समस्याओं को हल करते हैं, और, उतना ही महत्वपूर्ण, किन्हें आप ठुकराते हैं। विज़न उस दुनिया की टिकाऊ तस्वीर है जिसे आप बनाने की कोशिश कर रहे हैं, आमतौर पर दो से पांच साल आगे की। रणनीति उन चालों का क्रम है जो आपको वहां तक पहुंचाता है। इन दोनों के बिना, प्राथमिकता निर्धारण इस बात में बदल जाता है कि सबसे ज़ोर से कौन बहस करता है, और रोडमैप हर किसी की पसंदीदा सुविधाओं की एक सूची बनकर रह जाता है।

रणनीति ग्राहक और समस्या के गहरे, प्रत्यक्ष ज्ञान के बिना असंभव है। एक प्रोडक्ट मैनेजर जो विशिष्ट विवरण में यह नहीं बता सकता कि ग्राहक कौन है, वे कौन सा काम पूरा करने की कोशिश कर रहे हैं, और वर्तमान में वे कहां संघर्ष कर रहे हैं, वह किसी भी चीज़ को प्राथमिकता देने के लिए तैयार नहीं है। यह कोई सर्वेक्षण नहीं है जिसे आप एक बार करवाते हैं। यह संपर्क की एक स्थायी आदत है। सबसे अच्छे उत्पाद नेता पिछले हफ्ते की ग्राहक बातचीत को याद से बता सकते हैं, न कि पिछली तिमाही के शोध दस्तावेज़ से। जब आप समस्या को गहराई से जानते हैं, तो अधिकांश प्राथमिकता संबंधी बहसें अपने आप समाप्त हो जाती हैं, क्योंकि टीम राय के बजाय प्रमाण से तर्क कर सकती है।

परिणामों के अनुसार प्रबंधन करें और फीचर फैक्ट्री से बचें

फीचर फैक्ट्री वह है जो तब बनती है जब सफलता को “हमने इसे शिप कर दिया” के रूप में परिभाषित किया जाता है। टीमें वेलोसिटी मापती हैं, रिलीज़ गिनती हैं, और लॉन्च का जश्न मनाती हैं, जबकि वे मेट्रिक्स जो वास्तव में बिल चुकाते हैं, सपाट बनी रहती हैं। इसका उपाय है सफलता को एक आउटकम (ग्राहक या व्यावसायिक व्यवहार में बदलाव) के रूप में परिभाषित करना और निर्माण से पहले उससे एक माप जोड़ना। यहीं पर उत्पाद प्रबंधन उद्देश्य और मुख्य परिणामों (objectives and key results, अध्याय 11.4) से मिलता है: उद्देश्य उस बदलाव का वर्णन करते हैं जो आप चाहते हैं, मुख्य परिणाम उसे मापते हैं, और “फीचर X लॉन्च करें” के रूप में लिखा गया मुख्य परिणाम असल में छिपा हुआ एक कार्य (task) है।

संकेतों पर नज़र रखें। यदि आपका रोडमैप बिना किसी बताए गए आउटकम वाली सुविधाओं की सूची है, यदि कोई यह नहीं बता सकता कि किसी शिप की गई सुविधा ने कौन सा मेट्रिक हिलाया, यदि रेट्रोस्पेक्टिव में कभी यह नहीं पूछा जाता कि “क्या यह काम किया” बल्कि केवल यह पूछा जाता है कि “क्या हमने शिप किया,” तो आप एक फीचर फैक्ट्री में हैं। इससे बचना ज़्यादातर अनुशासन का मामला है: उस काम को स्वीकार करने से इनकार करें जिसे समाधान के रूप में तैयार किया गया है जब तक कोई समस्या और माप न बताए। उत्पाद विश्लेषिकी (product analytics) और नियंत्रित प्रयोग (controlled experiments, अध्याय 7.4) आपको वास्तविक आउटकम को एक सुविधाजनक कहानी से अलग बताने के लिए उपकरण पैनल देते हैं।

डिलीवरी के साथ-साथ निरंतर डिस्कवरी चलाएं

निरंतर उत्पाद डिस्कवरी का अर्थ है कि डिलीवरी के समानांतर, हर हफ्ते, टीम ग्राहकों से सीख रही होती है और उन धारणाओं का परीक्षण कर रही होती है जो वह बनाने की योजना बना रही है। मॉडल दोहरे ट्रैक (dual-track) पर आधारित है: एक डिस्कवरी ट्रैक विचारों के जोखिम को कम करता है जबकि एक डिलीवरी ट्रैक मान्य किए गए विचारों को बनाता है, और ये दोनों क्रमिक चरणों के बजाय निरंतर चलते हैं (अध्याय 11.1 पाइपलाइन का विवरण देता है)। इसके पीछे का व्यावहारिक संकल्प छोटा और अथक है: हर एक हफ्ते ग्राहकों से बात करें, भले ही आप व्यस्त हों, विशेष रूप से जब आप व्यस्त हों।

इसके लिए एक उपयोगी ढांचा है अवसर-समाधान वृक्ष (opportunity-solution tree): आप एक वांछित आउटकम से शुरू करते हैं, फिर उन ग्राहक अवसरों (ज़रूरतें, दर्द बिंदु, इच्छाएं) में शाखाबद्ध होते हैं जो उसे आगे बढ़ा सकते हैं, फिर हर अवसर के लिए संभावित समाधानों में शाखाबद्ध होते हैं, और फिर उन धारणा परीक्षणों में जो यह बता सकें कि कोई समाधान काम करता है या नहीं। यह वृक्ष टीम को इस बारे में ईमानदार रखता है कि कोई दिया गया फीचर मेज़ पर क्यों है और आपको पहले समाधान से प्रेम करने के बजाय अवसरों की तुलना करने के लिए मजबूर करता है। इंजीनियरिंग को प्रतिबद्ध करने से पहले, आप सबसे जोखिम भरी धारणा का सबसे सस्ते प्रयोग से परीक्षण करते हैं: एक साक्षात्कार, एक प्रोटोटाइप, एक फ़ेक-डोर परीक्षण, एक A/B परीक्षण। डिस्कवरी का आउटपुट कोई फीचर सूची नहीं है। यह मान्य, मापने योग्य दांवों की एक धारा है जो डिलीवरी के लिए तैयार है।

प्राथमिकता निर्धारण ढांचों को निर्णय-सहायक के रूप में उपयोग करें, दैवज्ञ के रूप में नहीं

प्राथमिकता निर्धारण ढांचे एक अव्यवस्थित निर्णय में उपयोगी संरचना लाते हैं, और उनमें से हर एक गलत है यदि आप उसकी संख्या को सत्य मान लेते हैं। RICE प्रत्येक विचार को पहुंच (Reach, कितने उपयोगकर्ता), प्रभाव (Impact), विश्वास (Confidence), और प्रयास (Effort) के आधार पर अंक देता है, फिर (Reach x Impact x Confidence) / Effort के अनुसार क्रमबद्ध करता है। वेटेड स्कोरिंग (weighted scoring) विकल्पों को कई भारित मानदंडों के विरुद्ध रेट करती है। विलंब की लागत (cost of delay) पूछती है कि प्रतीक्षा का हर हफ्ता आपको कितना महंगा पड़ता है, जो अक्सर अनुक्रमण (sequencing) के लिए सबसे तीक्ष्ण दृष्टिकोण होता है। कानो मॉडल सुविधाओं को बुनियादी अपेक्षाओं, प्रदर्शन आवश्यकताओं, और प्रसन्नताप्रदायक (delighter) तत्वों में विभाजित करता है, यह याद दिलाते हुए कि सारी संतुष्टि रैखिक नहीं होती।

इनका उपयोग अपनी धारणाओं को उजागर करने और ट्रेड-ऑफ को चर्चा योग्य बनाने के लिए करें, निर्णय से हाथ धोने के लिए नहीं। RICE में विश्वास (Confidence) पद और वेटेड स्कोरिंग में अनुमान वास्तव में गणित के भेस में निर्णय-निर्णय हैं, और झूठी सटीकता एक बुरे दांव को एक क्रमबद्ध सूची में बदल सकती है जो वस्तुनिष्ठ दिखती है। आंकड़े निकालें, फिर पूछें कि क्या रैंकिंग आपकी रणनीति और आपके ग्राहक ज्ञान से मेल खाती है। यदि नहीं, तो निर्णय पर भरोसा करें और इनपुट की जांच करें। ढांचा एक सोच-सहायक है; सही होना अभी भी आपका ही काम है।

रोडमैप को इरादे के बयान के रूप में मानें

एक तारीख़ वाला रोडमैप जो विशिष्ट तिमाहियों पर विशिष्ट सुविधाओं का वादा करता है, एक कल्पित कथा है जिस पर सभी हस्ताक्षर करते हैं और जिसे कोई भी पूरा नहीं कर सकता, क्योंकि यह उस एक चीज़ (समाधान) को स्थिर कर देता है जिसके बारे में डिस्कवरी को निरंतर सीखना चाहिए। अभी / आगे / बाद में (now / next / later) रोडमैप को प्राथमिकता दें: हम अभी क्या कर रहे हैं, आगे क्या होने की संभावना है, और हम बाद में क्या सोच रहे हैं, जिसे तारीखों वाली प्रतिबद्ध सुविधाओं के बजाय समस्याओं और आउटकम के रूप में व्यक्त किया जाए। यह दिशा को ईमानदारी से संप्रेषित करता है जबकि जैसे-जैसे प्रमाण मिलते हैं, समाधान बदलने की स्वतंत्रता को बनाए रखता है।

अंतर्निहित कदम है समस्याओं और आउटकम के प्रति दृढ़ता से, और समाधानों के प्रति ढीले ढंग से प्रतिबद्ध होना। जो हितधारक तारीख़-निश्चित फीचर प्रतिबद्धताएं मांगते हैं वे आमतौर पर पूर्वानुमेयता (predictability) मांग रहे होते हैं, जो उचित है; उन्हें यह आउटकम और समय-सीमा के स्तर पर दें (“हम इस अर्ध-वर्ष में ऑनबोर्डिंग ड्रॉप-ऑफ को सार्थक रूप से कम करेंगे”) न कि उन विशिष्ट सुविधाओं के स्तर पर जिन्हें आपने अभी तक मान्य नहीं किया है। जब आपको कोई पक्की तारीख़ देनी ही हो, तो उसे एक मूल्यवान आउटकम से जोड़ें और समाधान के दायरे को लचीला रहने दें, ठीक वैसे ही जैसे अध्याय 10.6 परियोजना डिलीवरी के लिए सुझाता है।

वांछनीयता, व्यवहार्यता, संभाव्यता, और उपयोगिता को मान्य करें

वास्तविक निवेश करने से पहले, एक उत्पाद विचार को चार जोखिमों को पार करना होता है। वांछनीयता (desirability): क्या ग्राहक वास्तव में इसे चाहते हैं? व्यवहार्यता (viability): क्या यह व्यवसाय के लिए काम करता है (कानूनी, वित्तीय, ब्रांड, बिक्री)? संभाव्यता (feasibility): क्या इंजीनियरिंग उपलब्ध समय और तकनीक के साथ इसे बना सकती है? उपयोगिता (usability): क्या लोग वास्तव में इसका उपयोग कर सकते हैं? त्रिगुट इन्हीं को कवर करने के लिए बना है: उत्पाद व्यवहार्यता पर, डिज़ाइन उपयोगिता पर, और इंजीनियरिंग संभाव्यता पर अगुआई करती है, और वांछनीयता सबकी समस्या है। किसी एक को छोड़ दें और यह ऐसे लॉन्च के रूप में वापस आता है जिसे ग्राहक नज़रअंदाज़ कर देते हैं, कानूनी विभाग रोक देता है, इंजीनियरिंग शिप नहीं कर पाती, या उपयोगकर्ता समझ ही नहीं पाते।

यह बनाओ, खरीदो, या साझेदारी करो (build, buy, or partner) निर्णयों के लिए भी ढांचा है। यदि कोई क्षमता आपके भेदभेद (differentiation) के लिए केंद्रीय है, तो उसे बनाएं। यदि यह आवश्यक तो है पर अविभेदित (undifferentiated) है (बिलिंग, प्रमाणीकरण, ईमेल डिलीवरी), तो खरीदने या साझेदारी करने को दृढ़ता से प्राथमिकता दें, क्योंकि आप जो भी सुविधा बनाते हैं वह रखरखाव, सुरक्षा सतह, और संज्ञानात्मक भार की एक स्थायी पूंछ लेकर आती है। एक न्यूनतम व्यवहार्य उत्पाद (MVP) वह सबसे सस्ती चीज़ है जो आपकी सबसे जोखिम भरी धारणा का परीक्षण करती है, न कि कोई छीना-झपटी संस्करण 1.0 जिसे आप शिप करके भूल जाते हैं; इसे ईमानदार बनाए रखने के लिए यह पूछें कि आप क्या सीखेंगे, न कि सिर्फ़ यह कि आप क्या लॉन्च करेंगे।

उत्पाद-बाज़ार फिट को पहचानें और उत्पाद संचालन में निवेश करें

उत्पाद-बाज़ार फिट वह क्षण है जब कोई उत्पाद एक मज़बूत बाज़ार मांग को संतुष्ट करता है, और आप इसे सिद्ध करने से पहले ही आमतौर पर महसूस कर लेते हैं: रिटेंशन वक्र शून्य की ओर क्षीण होने के बजाय समतल हो जाते हैं, उपयोग मुंह-ज़बानी से बढ़ता है, ग्राहक उत्पाद खोने पर वास्तव में परेशान होंगे, और आप मांग बनाने के बजाय उसके साथ तालमेल बिठाने के लिए संघर्ष करते हैं। फिट मिलने से पहले, आपका काम इसे ढूंढना है, और लगभग कुछ और मायने नहीं रखता। फिट मिलने के बाद, आपका काम बदलकर इसे बढ़ाना और इसकी रक्षा करना हो जाता है। इन दोनों चरणों को भ्रमित करना (फिट मिलने से पहले स्केल करना, या फिट मिलने के बाद भी खोज जारी रखना) एक क्लासिक और महंगी गलती है।

जैसे-जैसे उत्पाद टीमों की संख्या बढ़ती है, उत्पाद संचालन (product operations) में निवेश करें: साझा शोध, डेटा, टूलिंग, और अभ्यास जो कई टीमों को हर बार नए सिरे से आविष्कार किए बिना डिस्कवरी अच्छी तरह करने देते हैं। प्रोडक्ट ऑप्स ग्राहक-साक्षात्कार की लय को स्टाफ़ से भरा रखता है, विश्लेषिकी को भरोसेमंद रखता है, रोडमैप प्रारूप को सुसंगत रखता है, और OKR की लय को चलता रखता है। एक एंटरप्राइज़ में जो उत्पाद संचालन मॉडल की ओर बढ़ रहा है, और एक प्लेटफ़ॉर्म-को-उत्पाद संगठन में जहां आंतरिक प्लेटफ़ॉर्मों के वास्तविक आंतरिक ग्राहक होते हैं, प्रोडक्ट ऑप्स ही है जो मॉडल को दर्जनों टीमों में सुसंगत बनाए रखता है, बजाय इसके कि यह स्थानीय आदतों में बिखर जाए।

ट्रेड-ऑफ: फायदे और नुकसान

दृष्टिकोण	फायदे	नुकसान
सशक्त उत्पाद टीम (आउटकम)	परिणामों की स्वामी; बेहतर समाधान खोजती है; प्रेरित	वरिष्ठ प्रतिभा और वास्तविक विश्वास चाहिए; ऊपर से सीधे निर्देशित करना कठिन
फीचर-टीम / आदेश-ग्रहण मॉडल	पूर्वानुमेय आउटपुट; प्रबंधित और अनुबंधित करना आसान	गलत चीज़ें कुशलता से शिप करता है; कोई भी परिणाम का स्वामी नहीं
निरंतर डिस्कवरी	दांवों का जोखिम हर हफ्ते कम करती है; तेज़ सीख; कम बर्बादी	शोध क्षमता और अनुशासन चाहिए; शेड्यूल करना कठिन
भारी अग्रिम आवश्यकताएं	फंडरों के लिए आश्वस्तकारी; स्पष्ट दायरा	धारणाएं अपरीक्षित; देर से फ़ीडबैक; बड़ा-धमाका जोखिम
अभी/आगे/बाद में रोडमैप	अनिश्चितता के बारे में ईमानदार; सीख को संरक्षित रखता है	तारीख़ वाली फीचर प्रतिबद्धता चाहने वाले हितधारकों को निराश करता है
तारीख़ वाला फीचर रोडमैप	पूर्वानुमेय महसूस होता है; संप्रेषित करना आसान	ऐसा वादा करता है जो आप जान ही नहीं सकते; आउटकम पर आउटपुट को पुरस्कृत करता है
ढांचा स्कोर द्वारा प्राथमिकता निर्धारण	संरचित, चर्चा योग्य, राजनीति कम करता है	झूठी सटीकता; एक बुरे दांव को वस्तुनिष्ठ के रूप में पेश कर सकता है

केंद्रीय तनाव है प्रतिबद्धता बनाम सीख। बजट, अनुबंध, और अधिकारी दृढ़ प्रतिबद्धताएं चाहते हैं, जो तारीख़ वाले फीचर रोडमैप और अग्रिम आवश्यकताओं की ओर खींचता है। अच्छे उत्पादों को डिस्कवरी के लिए जगह चाहिए, जो आउटकम और निरंतर प्रयोगों की ओर खींचता है। इसे इस पूरी गाइड में जैसे हल किया गया है वैसे ही हल करें: समस्याओं, आउटकम, और समय-सीमाओं के प्रति दृढ़ता से प्रतिबद्ध रहें, और विशिष्ट समाधानों को ढीले ढंग से पकड़ें। यह नेतृत्व को वह पूर्वानुमेयता देता है जिसकी उन्हें वास्तव में ज़रूरत है (उन चीज़ों पर मापने योग्य प्रगति जो मायने रखती हैं) बिना टीम को उन सुविधाओं का वादा करने पर मजबूर किए जिन्हें उसने अभी तक मान्य नहीं किया है।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. क्या आपका प्रोडक्ट मैनेजर किसी आउटकम का स्वामी है, या बैकलॉग का? यह इस बारे में सबसे अधिक खुलासा करने वाला एकमात्र प्रश्न है कि आपकी टीम वास्तव में कैसे काम करती है। यदि प्रोडक्ट मैनेजर को रोडमैप शिप करने, हितधारकों के अनुरोधों के पीछे भागने, और स्प्रिंट को भरा रखने पर मापा जाता है, तो आपके पास एक उत्पाद शीर्षक वाला परियोजना समन्वयक है, और वास्तव में कोई भी इस बात के लिए जवाबदेह नहीं है कि काम किसी मेट्रिक को हिलाता है या नहीं। प्रमाण लाएं: अपने प्रोडक्ट मैनेजर की पिछली तीन डिलीवरेबल्स को देखें और पूछें कि प्रत्येक से कौन सा ग्राहक या व्यावसायिक आउटकम बदलना था, और क्या किसी ने जांचा। एक बड़े संगठन में दांव बढ़ जाते हैं, क्योंकि आउटपुट की ओर इशारा करने वाली एक भी टीम कई तिमाहियां ऐसी सुविधाएं बनाने में जला सकती है जो डेमो में अच्छी लगती हैं लेकिन उत्पादन में कुछ नहीं बदलतीं। उत्तर को यह पुनर्आकार देना चाहिए कि आप प्रोडक्ट मैनेजर को किस पर मापते हैं और टीम को समाधानों पर कितना नियंत्रण देने को तैयार हैं। यदि कोई भी किसी आउटकम का स्वामी नहीं है, तो रोडमैप पर बहस करने से पहले इसे ठीक करें।

2. इस टीम में किसी ने आखिरी बार किसी ग्राहक से कब बात की थी, और क्या वह इसी हफ्ते हुआ था? निरंतर डिस्कवरी इसी आदत पर जीती-मरती है, और डिलीवरी का दबाव बढ़ने पर यही सबसे पहले कटती है, ठीक उसी समय जब इसकी सबसे ज़्यादा ज़रूरत होती है। जो टीमें ग्राहकों से बात करना बंद कर देती हैं, उन्हें यह पता ही नहीं चलता कि वे अंधी हो चुकी हैं; वे बस आंतरिक राय और पुराने शोध से तर्क करना शुरू कर देती हैं, अधिक आत्मविश्वासी और कम सही होती जाती हैं। वास्तविक लॉग लाएं: गिनें कि आपकी पिछली दस सुविधाओं में से कितनी निर्माण से पहले एक दस्तावेज़ीकृत धारणा और सस्ते परीक्षण से गुज़रीं, बनाम कितनी सीधे किसी हितधारक के मुंह से बैकलॉग में चली गईं। एंटरप्राइज़ और सरकारी टीमों के लिए, जहां एक गलत दिशा वाली पहल कई टीम-तिमाहियां और, सार्वजनिक क्षेत्र में, वास्तविक जनविश्वास बर्बाद कर सकती है, यह नाम दें कि साप्ताहिक ग्राहक संपर्क को ज़िंदा रखने के लिए कौन जवाबदेह है। यदि ईमानदार उत्तर “इस हफ्ते नहीं” या “निश्चित नहीं” है, तो आप धारणाओं पर उड़ान भर रहे हैं और उसे रणनीति कह रहे हैं।

3. परियोजना संचालन मॉडल से उत्पाद संचालन मॉडल में जाने के लिए क्या चाहिए, और आपको क्या रोक रहा है? कई एंटरप्राइज़ अभी भी अस्थायी परियोजनाओं को फंड करते हैं, उन्हें स्टाफ़ देते हैं, शिप करते हैं, और टीम भंग कर देते हैं, जो उस टिकाऊ स्वामित्व और ग्राहक ज्ञान को नष्ट कर देता है जिस पर अच्छा उत्पाद कार्य निर्भर करता है। उन टिकाऊ टीमों की ओर बदलना जो वर्षों तक आउटकम की स्वामी बनी रहती हैं, जिसमें आंतरिक प्लेटफ़ॉर्मों को वास्तविक ग्राहकों वाले उत्पादों के रूप में मानना शामिल है, फंडिंग, संगठन डिज़ाइन, और गवर्नेंस में बदलाव है, न कि केवल पदनामों में बदलाव। प्रमाण लाएं: पता लगाएं कि वर्तमान में कोई एक पहल कैसे फंड और स्टाफ़ की जाती है, और पूछें कि जब परियोजना समाप्त होती है और टीम बिखर जाती है तो संचित सीख का क्या होता है। प्रतिस्पर्धी विचार वास्तविक है, क्योंकि वार्षिक परियोजना बजट और खरीद नियम वैध जवाबदेही कारणों से मौजूद हैं, और आपको उन्हें संतुष्ट करना है, नज़रअंदाज़ नहीं। उत्तर को सबसे छोटा ठोस कदम पहचानना चाहिए (एक स्थिर बजट के साथ एक आउटकम की स्वामी एक स्थायी टीम) जो पूरे पोर्टफोलियो को बदलने की कोशिश करने से पहले मॉडल को साबित करे (अध्याय 10.1)।

4. जब हम कोई प्राथमिकता निर्धारण ढांचा चलाते हैं, तो क्या यह निर्णय को सूचित कर रहा है या पहले से लिए गए निर्णय की पुष्टि कर रहा है? RICE, वेटेड स्कोरिंग, और विलंब की लागत ठीक इसलिए उपयोगी हैं क्योंकि वे धारणाओं को खुले में लाने के लिए मजबूर करते हैं, और वे उसी क्षण हानिकारक हो जाते हैं जब कोई संख्या सोचना बंद करने का बहाना बन जाती है। प्रतिस्पर्धी विचार वास्तविक है: ढांचे राजनीति कम करते हैं और एक बचाव योग्य कागज़ी ट्रेल देते हैं, जिसकी बड़े संगठनों को वास्तव में ज़रूरत होती है, फिर भी विश्वास और प्रभाव पद गणित के भेस में निर्णय हैं और एक बुरे दांव को वस्तुनिष्ठ दिखने वाली रैंक में बदल सकते हैं। अपने पिछले कुछ प्राथमिकता निर्धारण निर्णय लाएं और दो चीज़ें जांचें: क्या जब रणनीति या ग्राहक ज्ञान असहमत हुआ तब कभी किसी ने स्कोर को पलटा, और क्या सबसे ज़्यादा वेतन पाने वाले व्यक्ति की पसंद ने चुपचाप वे इनपुट तय किए जिनसे रैंकिंग बनी। एंटरप्राइज़ और सरकारी परिवेश में, जहां एक स्कोर वाला बैकलॉग अक्सर वह कलाकृति बन जाता है जो संचालन समितियों और ऑडिटरों को दिखाई जाती है, यह नाम दें कि किन आधारों पर संख्या को कौन पलट सकता है, क्योंकि एक ऐसा ढांचा जिसे कोई भी पलट नहीं सकता, सोच-सहायक होना बंद करके एक रबर स्टांप बन गया है।

5. हमने हितधारकों से तारीख़ वाली सुविधाओं के रूप में क्या वादा किया है, और क्या हम उनका विश्वास खोए बिना उन प्रतिबद्धताओं को आउटकम के रूप में दोबारा बता सकते हैं? तारीख़ वाले फीचर रोडमैप पूर्वानुमेयता जैसे महसूस होते हैं और आमतौर पर कल्पित कथा होते हैं, क्योंकि वे उस समाधान को स्थिर कर देते हैं जिसके बारे में डिस्कवरी को निरंतर सीखना चाहिए, और एक बड़े संगठन में ऐसा हर वादा निर्भर टीमों, मार्केटिंग योजनाओं, और अधिकारियों की अपेक्षाओं में लहरों की तरह फैलता है। तनाव वैध है: फंडर और हितधारक बजट और जवाबदेही के कारणों से निश्चितता चाहते हैं, इसलिए आप बस प्रतिबद्ध होने से इनकार नहीं कर सकते; आपको अपरीक्षित सुविधाओं के बजाय आउटकम और समय-सीमाओं के स्तर पर पूर्वानुमेयता देनी होगी। वर्तमान रोडमैप लाएं और हर आइटम को या तो एक ऐसे आउटकम के रूप में चिह्नित करें जिसके लिए आप प्रतिबद्ध हो सकते हैं या एक विशिष्ट समाधान के रूप में जिसका आप केवल अनुमान लगा रहे हैं, फिर मसौदा तैयार करें कि आप अनुमानों को अभी/आगे/बाद में समस्याओं के रूप में कैसे दोबारा बताएंगे। वार्षिक बजट और खरीद मील के पत्थरों से बंधी एंटरप्राइज़ और सार्वजनिक-क्षेत्र की टीमों के लिए, पहचानें कि कौन सी प्रतिबद्धताएं वास्तव में अनुबंधित हैं बनाम केवल आदतन हैं, क्योंकि आदतन वाली वे हैं जहां आप झूठी सटीकता को ईमानदार दिशा से बदल सकते हैं, और अनुबंधित वाली वे हैं जहां आपको प्रतिबद्धता पर एक फीचर के बजाय एक आउटकम के लिए बातचीत करनी होगी।

6. हम कहां अविभेदित क्षमता बना रहे हैं जिसे हम खरीद सकते थे या जिसके लिए साझेदारी कर सकते थे, और यह फ़ैसला कौन लेता है? आप जो भी सुविधा बनाते हैं वह रखरखाव, सुरक्षा सतह, और सहायता भार की एक स्थायी पूंछ लेकर आती है, इसलिए बिलिंग, प्रमाणीकरण, या ईमेल डिलीवरी को हाथ से बनाना आपकी सबसे दुर्लभ क्षमता को उस काम पर खर्च करता है जो आपको अलग नहीं बनाता (अध्याय 10.4)। प्रतिस्पर्धी विचार यह है कि “खरीदना” नियंत्रण और फिट को गति और कम स्वामित्व लागत के बदले देता है, और कभी-कभी जिस क्षमता को आपने कमोडिटी माना था वह वास्तव में आपके लाभ के लिए केंद्रीय होती है, इसलिए वांछनीयता-व्यवहार्यता-संभाव्यता-उपयोगिता दृष्टिकोण को किसी पसंद के लिए बहाने के बजाय ईमानदारी से लागू करना होगा। अपनी टीमें वर्तमान में जो कुछ घर में बना रही हैं उसकी सूची लाएं, हर एक को मुख्य भेदभावकारी या अविभेदित प्लंबिंग के रूप में चिह्नित करें, और प्लंबिंग की चल रही स्वामित्व लागत का एक विक्रेता विकल्प के मुकाबले अनुमान लगाएं। एंटरप्राइज़ और सरकारी संदर्भों में, खरीद नियमों, डेटा-निवास (data-residency) और सुरक्षा आवश्यकताओं, और विक्रेता लॉक-इन और निकास शर्तों को शामिल करें, क्योंकि वहां बनाओ-खरीदो-साझेदारी करो का निर्णय केवल एक इंजीनियरिंग ट्रेड-ऑफ नहीं बल्कि एक अनुपालन और जवाबदेही का निर्णय है, और जो व्यक्ति इसका स्वामी है उसे ऑडिटर के सामने इस पसंद का बचाव करने में सक्षम होना चाहिए।

क्षेत्रीय दृष्टिकोण

स्टार्टअप। कम रनवे के साथ, डिस्कवरी अस्तित्व की लड़ाई है, कोई प्रक्रिया नहीं। एक संस्थापक उत्पाद की टोपी पहनता है, बिना किसी औपचारिकता के हर हफ्ते ग्राहकों से बात करता है, और किसी भी इंजीनियर को निर्माण में लगाने से पहले सबसे सस्ते संभव परीक्षण चलाता है (एक फ़ेक-डोर बटन, पांच साक्षात्कार)। भारी ढांचों और तारीख़ वाले रोडमैप को छोड़ें; पूरी कंपनी रणनीति को अपने दिमाग़ में रख सकती है, इसलिए अनुशासन को इस पर खर्च करें कि जब तक कोई समस्या और मेट्रिक न बताए, तब तक सबसे ज़ोरदार अनुरोध बनाने से इनकार करें।

छोटा व्यवसाय। आपके पास कोई समर्पित प्रोडक्ट मैनेजर नहीं है, इसलिए उत्पाद-सोच एक ऐसी आदत है जिसे मालिक या एक लीड इंजीनियर अन्य कर्तव्यों के साथ निभाता है। अधिकांश बनाओ-बनाम-खरीदो निर्णयों को खरीदने की ओर झुकाएं: बुकिंग, भुगतान, या ईमेल जैसी अविभेदित क्षमता किसी विक्रेता की है, और आपका दुर्लभ ध्यान उन एक या दो चीज़ों पर जाना चाहिए जो वास्तव में ग्राहक जीतती हैं। एक औपचारिक रोडमैप के बजाय एक हल्की अभी/आगे/बाद में सूची रखें, और एक पूर्ण OKR तंत्र के बजाय एक ही अग्रणी मेट्रिक (दोहराई गई खरीदारी, नो-शो) को अपना आउटकम मानें।

एंटरप्राइज़। काम है मॉडल को बिखरने दिए बिना कई उत्पाद टीमों का समन्वय करना: टिकाऊ त्रिगुट जो आउटकम के स्वामी हैं, एक सुसंगत रोडमैप प्रारूप, और उत्पाद संचालन जो दर्जनों टीमों में साक्षात्कार की लय, विश्लेषिकी, और OKR की लय को सुसंगत रखता है। गवर्नेंस और ऑडिट ट्रेसेबिलिटी चाहते हैं, इसलिए आउटकम, प्राथमिकता निर्धारण तर्क, और समाप्ति (kill) निर्णयों को पठनीय बनाएं, बजाय तारीख़ वाले फीचर वादों की ओर लौटने के जो किसी समिति को तो संतुष्ट करते हैं लेकिन प्रभाव पर आउटपुट को पुरस्कृत करते हैं। परियोजना फंडिंग से उत्पाद संचालन मॉडल की ओर बदलाव को जानबूझकर प्रबंधित करें, क्योंकि संगठन डिज़ाइन और बजट पदनामों से धीमे बदलते हैं।

सरकार। खरीद नियम, पारदर्शिता, और सार्वजनिक जवाबदेही हर विकल्प को आकार देते हैं। निश्चित-दायरे वाली परियोजनाओं के बजाय टिकाऊ सेवा टीमों को फंड करें, सफलता को एक नागरिक आउटकम (आवेदन में लगने वाला समय, स्व-सेवा पूर्णता) के रूप में परिभाषित करें जिसे निगरानी निकाय सत्यापित कर सकें, और उपयोगकर्ता-केंद्रित डिज़ाइन और एक्सेसिबिलिटी मानकों को कठोर आवश्यकताएं मानें जिनका वास्तविक आवेदकों, जिसमें सहायक-तकनीक उपयोगकर्ता शामिल हैं, के साथ परीक्षण किया जाए। आउटकम और प्रगति को स्पष्ट रूप से प्रकाशित करें ताकि जांच सार्वजनिक मूल्य देख सके, और बनाओ-बनाम-खरीदो और विक्रेता अनुबंधों को डेटा पोर्टेबिलिटी और निकास के आसपास संरचित करें ताकि आज का एक विक्रेता चुनाव एक दशक के लॉक-इन में न बदल जाए।

उदाहरण

स्टार्टअप। स्वतंत्र क्लीनिकों के लिए एक शेड्यूलिंग टूल बनाने वाला छह-व्यक्तियों का एक स्टार्टअप उस बड़े “ऑनलाइन बुकिंग” फीचर को बनाने के प्रलोभन का विरोध करता है जिसकी तीन ज़ोरदार ग्राहक लगातार मांग कर रहे हैं। संस्थापक-प्रोडक्ट मैनेजर इसके बजाय एक हफ्ते की डिस्कवरी चलाता है: पांच क्लीनिक-मालिक साक्षात्कार, मार्केटिंग साइट पर एक फ़ेक-डोर बटन, और एक अग्रणी मेट्रिक (नो-शो में समाप्त होने वाली अपॉइंटमेंट का प्रतिशत)। प्रमाण कहता है कि असली दर्द नो-शो है, बुकिंग नहीं, इसलिए टीम एक ही आउटकम तैयार करती है (इस तिमाही में पायलट क्लीनिकों के लिए नो-शो को 10% से नीचे लाना), सबसे जोखिम भरी धारणा का परीक्षण करने के लिए एक छोटा डिपॉज़िट-और-रिमाइंडर MVP शिप करती है, और बुकिंग फीचर की एक पंक्ति लिखने से पहले ही उसे समाप्त कर देती है। रोडमैप एक अभी/आगे/बाद में सूची है, कोई तारीख़ वाली योजना नहीं, और पूरी टीम पिछले हफ्ते की ग्राहक कॉल को याद से बता सकती है।

एंटरप्राइज़। एक खुदरा बैंक अपने भुगतान समूह को परियोजना मॉडल से उत्पाद मॉडल में ले जाता है: एक टिकाऊ त्रिगुट (उत्पाद, डिज़ाइन, इंजीनियरिंग) चार्टर्ड परियोजनाओं की एक श्रृंखला के बजाय एक स्थिर वार्षिक बजट के साथ “हर रोज़ का भुगतान तुरंत महसूस हो” को एक स्थायी आउटकम के रूप में अपनाता है। टीम साप्ताहिक ग्राहक साक्षात्कार चलाती है और एक अवसर-समाधान वृक्ष बनाए रखती है, संभावित समाधानों को अनुक्रमित करने के लिए RICE का उपयोग करती है लेकिन जब विलंब-लागत विश्लेषण दिखाता है कि एक विलंबता (latency) फिक्स ज़्यादा मायने रखता है तो रैंकिंग को पलट देती है, और हितधारकों को तारीख़ वाले फीचर वादों के बजाय एक अभी/आगे/बाद में रोडमैप प्रकाशित करती है। दो प्रस्तावित सुविधाएं अग्रणी संकेतकों को न हिलाने के कारण डिस्कवरी में ही समाप्त हो जाती हैं, जिससे अनुमानित दो तिमाहियों का निर्माण प्रयास बचता है, और उत्पाद संचालन बैंक की पंद्रह उत्पाद टीमों में साक्षात्कार की लय और विश्लेषिकी को भरोसेमंद रखता है।

सरकार। लाभ आवेदनों का आधुनिकीकरण करने वाली एक राष्ट्रीय एजेंसी डिजिटल सेवा टीमों द्वारा समर्थित सार्वजनिक-क्षेत्र उत्पाद मानसिकता अपनाती है: यह एक निश्चित-दायरे वाली परियोजना के बजाय एक टिकाऊ सेवा टीम को फंड करती है, और सफलता को डिलीवर किए गए मॉड्यूल के बजाय एक नागरिक आउटकम (औसत आवेदन समय को 40 से 15 मिनट तक कम करना और सफल स्व-सेवा पूर्णता को 55% से 85% तक बढ़ाना) के रूप में परिभाषित करती है। उपयोगकर्ता-केंद्रित डिज़ाइन अपरक्राम्य (non-negotiable) है: टीम हर रिलीज़ से पहले सहायक-तकनीक उपयोगकर्ताओं सहित वास्तविक आवेदकों के साथ नियंत्रित उपयोगिता परीक्षण चलाती है, और एक्सेसिबिलिटी मानकों को कठोर आवश्यकताएं मानती है। क्योंकि रोडमैप को आउटकम के रूप में तैयार किया गया है और टीम वर्षों तक सेवा की स्वामी बनी रहती है, निगरानी निकाय एक खर्च रिपोर्ट के बजाय मापने योग्य सार्वजनिक मूल्य देखते हैं, और एजेंसी एक दूर के गो-लाइव पर सब कुछ दांव पर लगाने के बजाय जल्दी उपयोगी क्षमता शिप कर सकती है (अध्याय 11.1, 5.1)।

व्यावसायिक मामला: प्रेरणाएं, ROI, और TCO

वास्तविक उत्पाद प्रबंधन पर रिटर्न बचाई गई बर्बादी से हावी होता है। बड़ी प्रौद्योगिकी कंपनियों में नियंत्रित-प्रयोग कार्यक्रम बार-बार पाते हैं कि बनाई गई सुविधाओं का एक बड़ा हिस्सा, जिसे अक्सर लगभग आधे के रूप में उद्धृत किया जाता है, कोई मापने योग्य सुधार नहीं देता या लक्ष्य मेट्रिक को सक्रिय रूप से नुकसान पहुंचाता है। यदि किसी टीम की एक चौथाई क्षमता भी उन विचारों पर जाती है जिन्हें निरंतर डिस्कवरी सस्ते में समाप्त कर देती, तो यह अनुशासन अपनी कई गुना लागत वसूल कर लेता है: ग्राहक साक्षात्कार का एक हफ्ता और एक फ़ेक-डोर परीक्षण एक तिमाही की इंजीनियरिंग के मुकाबले लगभग कुछ भी खर्च नहीं करता, साथ ही उस सुविधा का स्थायी रखरखाव भी नहीं जिसे कोई इस्तेमाल नहीं करता। फीचर फैक्ट्री की प्राथमिक लागत वे सुविधाएं नहीं हैं जो वह शिप करती है। यह उन आउटकम का अवसर लागत है जिन्हें वह कभी नहीं हिला पाई।

स्वामित्व की कुल लागत (total cost of ownership) पर, हर शिप की गई सुविधा एक स्थायी देयता है: रखरखाव, टेस्टिंग, सुरक्षा सतह, सहायता भार, और उत्पाद में नेविगेट करने वाले हर व्यक्ति पर संज्ञानात्मक वज़न (अध्याय 10.4)। उत्पाद प्रबंधन इस लागत को दो तरीकों से कम करता है। यह डिस्कवरी में ही बुरे विचारों को समाप्त कर देता है, जिससे न केवल निर्माण बल्कि स्वामित्व की पूरी पूंछ भी बच जाती है। और यह बनाओ-खरीदो-साझेदारी करो निर्णयों को अविभेदित क्षमता खरीदने की ओर निर्देशित करता है, ताकि आपकी टीम की सीमित क्षमता उस चीज़ पर जाए जो वास्तव में आपको अलग बनाती है। परियोजना संचालन मॉडल से उत्पाद संचालन मॉडल की ओर बदलाव एक और सूक्ष्म रिटर्न जोड़ता है: टिकाऊ टीमें ग्राहक ज्ञान और कोडबेस संदर्भ बनाए रखती हैं जिसे परियोजना टीमें हर बार भंग होने और फिर से बनने पर फेंक देती हैं।

नेतृत्व के सामने मामला बनाने के लिए, बातचीत को “हम कितना शिप कर रहे हैं” से “हम उन मेट्रिक्स को कितना हिला रहे हैं जो मायने रखते हैं” में बदलें, और महंगी सुविधाओं के दो या तीन ठोस उदाहरण दिखाएं जिन्होंने कुछ भी नहीं हिलाया। अपनाने की लागत मामूली है: शोध क्षमता, एक डिस्कवरी लय, एक आउटकम-आधारित रोडमैप, और निर्माण से पहले सफलता को परिभाषित करने का अनुशासन। निवेश न करने का जोखिम मूक, बिना गिना, और चक्रवृद्धि वाला है, क्योंकि एक फीचर फैक्ट्री तब तक उत्पादक दिखती है जब तक आप यह न देख लें कि व्यवसाय हिला ही नहीं है।

एंटी-पैटर्न और नुकसान

• फीचर फैक्ट्री: सफलता को “हमने इसे शिप कर दिया” के रूप में परिभाषित किया जाता है, जबकि व्यावसायिक मेट्रिक्स सपाट रहते हैं और वेलोसिटी का जश्न मनाया जाता है।
• प्रोजेक्ट मैनेजर के रूप में प्रोडक्ट मैनेजर: समस्या और आउटकम के बजाय शेड्यूल और टिकट कतार का स्वामी बनना।
• फीचर सचिव के रूप में प्रोडक्ट मैनेजर: बिना किसी समस्या या माप के हितधारक अनुरोधों को बैकलॉग में प्रतिलिपि करना।
• तारीख़ वाले फीचर वादे के रूप में रोडमैप: ऐसे विशिष्ट समाधानों के लिए प्रतिबद्ध होना जिन्हें आप अभी तक विशिष्ट तिमाहियों पर मान्य नहीं कर सकते।
• एक बार के चरण के रूप में डिस्कवरी: शुरुआत में एक डिस्कवरी स्प्रिंट, फिर बिना किसी आगे के ग्राहक संपर्क के महीनों का निर्माण।
• HiPPO-संचालित प्राथमिकता निर्धारण: सबसे ज़्यादा वेतन पाने वाले व्यक्ति की राय प्रमाण पर हावी हो जाती है, और ढांचे इसे प्रमाणित करने का नाटक बन जाते हैं।
• ढांचा-पूजा: एक RICE या वेटेड स्कोर को सत्य मानना, झूठी सटीकता को एक बुरे दांव को साफ़ करने देना।
• अविभेदित इन्फ्रास्ट्रक्चर बनाना: बिलिंग या प्रमाणीकरण को हाथ से बनाना जो कोई विक्रेता बेहतर और सस्ते में दे सकता है।
• उत्पाद-बाज़ार फिट से पहले स्केल करना: ऐसे उत्पाद पर विकास के लिए पैसा डालना जिसे बाज़ार अभी तक दृढ़ता से नहीं चाहता।
• बिना उत्पाद स्वामी वाला आंतरिक प्लेटफ़ॉर्म: एक प्लेटफ़ॉर्म टीम वह बना रही है जो उसे दिलचस्प लगता है, न कि वह जो उसके आंतरिक ग्राहकों को चाहिए।

परिपक्वता मॉडल

• स्तर 1, आरंभ करें (Initiate): उत्पाद प्रबंधन आदेश-ग्रहण और प्रतिक्रियाशील है। एक तारीख़ वाला फीचर रोडमैप सौंपा जाता है; सफलता है उसे शिप करना। कोई बताए गए आउटकम नहीं, कोई नियमित ग्राहक संपर्क नहीं, और कोई भी इस बात के लिए जवाबदेह नहीं कि काम ने कोई मेट्रिक हिलाया या नहीं।
• स्तर 2, विकसित करें (Develop): बुनियादी उत्पाद अभ्यास दिखाई देते हैं लेकिन टीमों में असंगत हैं। कुछ टीमों के लिए आउटकम और OKR मौजूद हैं, फिर भी लक्ष्य अक्सर आउटपुट-आकार के होते हैं और रोडमैप अभी भी फीचर सूचियां हैं। डिस्कवरी कभी-कभार होती है, आमतौर पर एक अग्रिम चरण के रूप में, और प्राथमिकता निर्धारण एक ढांचे का उपयोग करता है, कभी-कभी सबसे ज़ोरदार आवाज़ को ढकने के लिए।
• स्तर 3, मानकीकृत करें (Standardize): सशक्त त्रिगुट आउटकम के स्वामी हैं, और यह अभ्यास दस्तावेज़ीकृत और पूरे संगठन में अपेक्षित है। रोडमैप अब अभी/आगे/बाद में इरादे के बयान हैं; निरंतर डिस्कवरी एक स्टाफ़ वाली, साप्ताहिक आदत है जिसमें दस्तावेज़ीकृत धारणा परीक्षण होते हैं; प्राथमिकता निर्धारण ढांचे निर्णय को प्रतिस्थापित करने के बजाय सूचित करते हैं; और उत्पाद-बाज़ार फिट को एक स्थानीय आदत के बजाय एक साझा मानक के रूप में समझा और ट्रैक किया जाता है।
• स्तर 4, प्रबंधित करें (Manage): अभ्यास को आधार रेखाओं (baselines) के विरुद्ध मापा और नियंत्रित किया जाता है। हर टीम एक बताई गई आधार रेखा के विरुद्ध अग्रणी और पिछड़े आउटकम मेट्रिक्स को ट्रैक करती है, और लॉन्च के बाद हर सुविधा की जांच एक पूर्व-पंजीकृत सफलता मेट्रिक के विरुद्ध होती है जिसमें एक kill थ्रेशोल्ड को राय पर नहीं, प्रमाण पर लागू किया जाता है। डिस्कवरी स्वास्थ्य को भी मापा जाता है (साक्षात्कार लय पूरी हुई, निर्माण से पहले धारणाओं का परीक्षण, डिस्कवरी में समाप्त किए गए बनाम शिप किए गए विचार), उत्पाद-बाज़ार-फिट संकेत जैसे रिटेंशन वक्र और “निराश होंगे” स्कोर को मापा जाता है, और RICE Confidence जैसे ढांचा इनपुट को इस बात के अनुसार कैलिब्रेट किया जाता है कि दांव वास्तव में कैसे परिणत हुए।
• स्तर 5, समन्वित करें (Orchestrate): एक उत्पाद संचालन मॉडल पूरे पोर्टफोलियो में चलता है और निरंतर सुधारा जाता है और फंडिंग और रणनीति के साथ एकीकृत होता है। टिकाऊ टीमें वर्षों तक आउटकम की स्वामी होती हैं और आंतरिक प्लेटफ़ॉर्मों को उत्पादों के रूप में प्रबंधित किया जाता है; डिस्कवरी और डिलीवरी निरंतर लूप करते हैं; आउटकम डेटा निवेश को निर्देशित करता है और पोर्टफोलियो को अनुकूली रूप से पुनर्संतुलित करता है; उत्पाद संचालन इस अभ्यास को बड़े पैमाने पर सुसंगत रखता है; और नेतृत्व आउटकम के एक पोर्टफोलियो का प्रबंधन करता है, जैसे-जैसे प्रमाण और बाज़ार बदलते हैं, नियमित रूप से दांवों को रिटायर, पुनर्दायरा, और पुनर्प्राथमिकता देता है।

चर्चा के लिए विचार

1. अपने वर्तमान रोडमैप को देखें: कितने आइटम केवल एक फीचर और तारीख़ के बजाय एक मापने योग्य आउटकम बताते हैं?
2. आपकी टीम में कौन ग्राहक संबंध का इतना अच्छा स्वामी है कि पिछले हफ्ते की बातचीत को याद से बता सके?
3. आपकी हाल की कौन सी सुविधाओं को आप समाप्त कर देते यदि आपने पहले सबसे जोखिम भरी धारणा पर एक सस्ता प्रयोग चलाया होता?
4. आप कहां अविभेदित क्षमता बना रहे हैं जिसे आप खरीद सकते थे या जिसके लिए साझेदारी कर सकते थे, और इसकी आपको क्या कीमत चुकानी पड़ रही है?
5. क्या आपके पास उत्पाद-बाज़ार फिट है, और आपको इसका वास्तव में कैसे पता चलेगा, न कि केवल अनुमान से?
6. उत्पाद संचालन मॉडल की ओर आप सबसे छोटा कौन सा कदम उठा सकते हैं, और रास्ते में कौन सी गवर्नेंस बाधा खड़ी है?

मुख्य बातें

• उत्पाद प्रबंधन क्या और क्यों का स्वामी है, और कार्यों के समन्वय या अनुरोधों की प्रतिलिपि बनाने के बजाय आउटकम के लिए जवाबदेह है।
• निर्माण से पहले सफलता को ग्राहक या व्यावसायिक व्यवहार में एक मापे गए बदलाव के रूप में परिभाषित करके फीचर फैक्ट्री से बचें।
• डिलीवरी के साथ-साथ निरंतर डिस्कवरी चलाएं: हर हफ्ते ग्राहकों से बात करें और सबसे सस्ते प्रयोग से सबसे जोखिम भरी धारणा का परीक्षण करें (अध्याय 11.1)।
• प्राथमिकता निर्धारण ढांचों (RICE, वेटेड स्कोरिंग, विलंब की लागत, कानो) को निर्णय-सहायक के रूप में उपयोग करें, कभी दैवज्ञ के रूप में नहीं।
• रोडमैप को इरादे के बयान (अभी/आगे/बाद में) के रूप में मानें: समस्याओं और आउटकम के प्रति दृढ़ता से, समाधानों के प्रति ढीले ढंग से प्रतिबद्ध रहें।
• त्रिगुट को सशक्त बनाएं और निवेश करने से पहले वांछनीयता, व्यवहार्यता, संभाव्यता, और उपयोगिता को मान्य करें (अध्याय 5.1)।
• एंटरप्राइज़ और सरकार में, परियोजना संचालन मॉडल से उत्पाद संचालन मॉडल की ओर बदलें, परियोजनाओं को नहीं सेवाओं को फंड करें, और उत्पाद संचालन में निवेश करें (अध्याय 10.1, 11.4)।

संदर्भ और आगे का पठन

• Marty Cagan, Inspired and Empowered (empowered product teams, the product operating model).
• Marty Cagan and Chris Jones, Transformed (moving to a product operating model).
• Teresa Torres, Continuous Discovery Habits (opportunity-solution trees, weekly customer contact).
• Melissa Perri, Escaping the Build Trap (outcomes over outputs, product operations).
• Roman Pichler, Strategize (product vision, strategy, and roadmaps).
• C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors, Product Roadmaps Relaunched (now/next/later roadmaps).
• Dan Olsen, The Lean Product Playbook (product-market fit).
• Eric Ries, The Lean Startup (minimum viable product, build-measure-learn).
• Noriaki Kano et al., “Attractive Quality and Must-Be Quality” (Journal of the Japanese Society for Quality Control, 1984): कानो मॉडल की उत्पत्ति।
• Melissa Perri and Denise Tilles, Product Operations (scaling product practice).
• U.S. Digital Service, Digital Services Playbook; UK Government Digital Service, Government Design Principles and Service Standard (सार्वजनिक-क्षेत्र, उपयोगकर्ता-केंद्रित उत्पाद डिलीवरी)।