पहले सिद्धांत और प्रोडक्ट मनोविज्ञान
हर PM निर्णय के पीछे की कार्यशील मानसिकता, मानसिक मॉडल और पूर्वाग्रह-सजग निर्णय-क्षमता विकसित करें।
Explainer
प्रोडक्ट मैनेजमेंट देखने के एक तरीके से शुरू होता है। फ्रेमवर्क, रोडमैप या मेट्रिक्स से पहले, PM का काम है अस्पष्टता को ऐसे निर्णयों में अनुवाद करना जो समय के साथ बढ़ते जाएँ। इसका मतलब है उपयोगकर्ता की वास्तविकता, व्यवसाय की अर्थव्यवस्था और सिस्टम की बाधाओं को एक ही समय एक ही दिमाग में रखना, और यह चुनना कि अगला क्या सीखना है — बिना यह जानने और यह मानने के बीच की खाई से कतराए।
PM एक अनुवादक है, मिनी-CEO नहीं
'PM = मिनी-CEO' का ढाँचा भ्रामक है। PMs के पास शायद ही कभी टीम पर नियुक्ति/निष्कासन का अधिकार होता है, और अकेले इंजीनियरिंग क्षमता पर मालिकाना हक तो कभी नहीं। अधिक उपयोगी ढाँचा है अनुवादक का: उपयोगकर्ता की सच्चाई और व्यावसायिक परिणामों के बीच, रणनीति और टिकट के बीच, आज जो संभव है और अगली शर्त सफल होने के बाद जो संभव होगा उसके बीच। प्रभाव अनुवाद की गुणवत्ता से आता है, पद से नहीं।
- उपयोगकर्ता की पीड़ा को उस सबसे छोटे समस्या-कथन में अनुवाद करें जिसे सीखा जा सके।
- व्यावसायिक लक्ष्यों को अवलोकन योग्य व्यवहार-परिवर्तनों में अनुवाद करें जिन पर टीम लक्ष्य साध सके।
- तकनीकी बाधाओं को ऐसे प्रोडक्ट ट्रेड-ऑफ़ में अनुवाद करें जिन पर टीम बहस कर सके।
उपयोगकर्ता बनाम ग्राहक बनाम खरीदार बनाम चैंपियन
अधिकांश PM गलतियाँ चार अलग-अलग हितधारकों को एक शब्द में समेटने से शुरू होती हैं। उपयोगकर्ता प्रोडक्ट का अनुभव करता है; ग्राहक भुगतान करता है; खरीदार अनुमोदन देता है; चैंपियन भीतर से वकालत करता है। B2C और prosumer में, ये अक्सर एक ही व्यक्ति में सिमट जाते हैं। B2B, स्वास्थ्य, सरकार और मार्केटप्लेस में ये अलग-अलग हितधारक हैं — टकराते हुए प्रोत्साहनों और कार्य करने की बहुत अलग तत्परता के साथ।
- उपयोगकर्ता: रोज़मर्रा के उपयोग से मूल्य या घर्षण पाता है; स्विचिंग की लागत वहन करता है।
- ग्राहक: बिल भरता है; ROI, गवर्नेंस, सुरक्षा की परवाह करता है।
- खरीदार: अनुबंध पर हस्ताक्षर या रोलआउट को मंज़ूरी देता है; जोखिम और राजनीति की परवाह करता है।
- चैंपियन: संगठन के भीतर adoption को आगे बढ़ाता है; विश्वसनीयता और दिखाई देने वाली जीत की परवाह करता है।
- फ़ीचर मैप करने से पहले प्रत्येक वर्कफ़्लो पर इन्हें मैप करें।
प्रोडक्ट त्रिभुज: व्यवहार्यता, उपयोगिता, साध्यता
हर प्रोडक्ट निर्णय एक त्रिभुज के भीतर बैठता है: व्यावसायिक व्यवहार्यता (क्या इससे पैसे आते हैं या बचते हैं?), उपयोगकर्ता मूल्य और उपयोगिता (क्या यह सच में किसी असली समस्या को विकल्पों से बेहतर हल करता है?), और तकनीकी साध्यता (क्या हम इसे अपनी टीम और स्टैक के साथ बना सकते हैं, चला सकते हैं और विकसित कर सकते हैं?)। मज़बूत PMs तीनों लेंसों के बीच स्वच्छंद होकर चलते हैं; कमज़ोर PMs एक को डिफ़ॉल्ट रूप से हावी होने देते हैं — आमतौर पर वही जिसमें वे सबसे सहज हैं।
- व्यवहार्यता: राजस्व, लागत, रिटेंशन की अर्थव्यवस्था, नियामक और संविदात्मक एक्सपोज़र।
- मूल्य और उपयोगिता: सिद्ध माँग, स्विच करने की इच्छा, सीखने की सरलता, सुलभता।
- साध्यता: लेटेंसी, विश्वसनीयता, सुरक्षा, ऑब्ज़र्वेबिलिटी, रखरखाव, टीम की क्षमता।
- जब हितधारक असहमत हों, तो नाम लेकर बताएँ कि कौन त्रिभुज के किस कोने का बचाव कर रहा है — अधिकांश असहमतियाँ कोनों की टकराहट हैं, तथ्यों की नहीं।
परिणाम बनाम आउटपुट बनाम गतिविधियाँ
Marty Cagan का यह विभेद प्रोडक्ट में सबसे उपयोगी में से एक है। आउटपुट वह है जो आप शिप करते हैं; गतिविधियाँ वह हैं जो आप करते हैं; परिणाम वह व्यवहार-या-व्यापार-प्रदर्शन परिवर्तन हैं जो आप उत्पन्न करते हैं। अधिकांश टीमें गतिविधियाँ मापती हैं ('इस हफ़्ते हमने डिस्कवरी इंटरव्यू किए'), कुछ टीमें आउटपुट मापती हैं ('हमने 8 फ़ीचर शिप किए'), और केवल बेहतरीन टीमें परिणाम मापती हैं ('नए कोहोर्ट में साप्ताहिक सक्रिय एडिटर 41% से 49% हो गए')। आउटपुट-संचालित रोडमैप उत्पादक लगते हैं पर व्यवसाय शायद ही हिलाते हैं।
- गतिविधियाँ नकली बनाना सबसे आसान हैं और स्टेटस रिपोर्ट में सबसे आम भी।
- आउटपुट प्रगति-सा लगता है, पर तभी मायने रखता है जब उपयोगकर्ता का कोई व्यवहार बदले।
- परिणाम टीम को यह स्वीकार करने पर मजबूर करते हैं कि कब काम ने मेट्रिक नहीं हिलाई।
- किसी भी आउटपुट कथन को इस सवाल से दोहराएँ: 'इसके कारण कौन-सा उपयोगकर्ता-व्यवहार बदलेगा, और हमें कैसे पता चलेगा?'
टाइप-1 बनाम टाइप-2 निर्णय
Jeff Bezos का विभेद: टाइप-1 निर्णय एकतरफ़ा दरवाज़े हैं — पलटना मुश्किल या असंभव (आर्किटेक्चर के विकल्प, सार्वजनिक मूल्य परिवर्तन, M&A)। टाइप-2 निर्णय दोतरफ़ा दरवाज़े हैं — पलटना आसान (अधिकांश फ़ीचर लॉन्च, कॉपी बदलाव, एकल कोहोर्ट पर मूल्य प्रयोग)। टाइप-2 को टाइप-1 की तरह बरतना गति को सबसे अधिक धीमा करता है। टाइप-1 को टाइप-2 की तरह बरतना सबसे आम आपदा-स्रोत है।
- टाइप-2 निर्णयों पर डिफ़ॉल्ट रूप से कार्रवाई करें; जल्दी शिप करें, जल्दी सीखें, गलत होने पर पलटें।
- टाइप-1 निर्णयों पर धीमे चलें; सबसे मज़बूत आवाज़ें बुलाएँ, pre-mortem करें।
- अनिश्चित होने पर साफ़-साफ़ पूछें: 'अगर यह गलत है तो हम 7 दिन में इसे कैसे पलटेंगे?'
पहले-सिद्धांत वाली सोच
उपमा से सोचना तेज़ है पर ज्ञान खोता है ('चलिए वही करते हैं जो Stripe करता है')। पहले सिद्धांतों से सोचना धीमा है पर अधिक टिकाऊ: समस्या को ऐसे तथ्यों तक तोड़ें जिन पर बहस संभव नहीं, फिर ऊपर निर्माण करें। PMs इसका उपयोग विरासत में मिली धारणाओं को चुनौती देने ('हम हमेशा प्रति-सीट चार्ज करते रहे हैं'), जब कोई बेंचमार्क न हो तब शून्य से अनुमान लगाने, और टीम की वास्तविक बाधाओं से मेल न खाने वाली कॉपी-पेस्ट रणनीतियों को पहचानने के लिए करते हैं।
मानसिक मॉडल जिन्हें PMs को आत्मसात करना चाहिए
मानसिक मॉडल पुनःप्रयोग्य सोच-शॉर्टकट हैं जो अनुभव को संकुचित करते हैं। उद्देश्य उन्हें रटना नहीं है, बल्कि आधा दर्जन को जीभ की नोक पर रखना है ताकि बातचीत के बीचो-बीच सही चुना जा सके।
- उलट सोच: 'हम सफल कैसे हों?' पूछने के बजाय, पूछें 'विफलता की गारंटी कैसे दी जाए?' और उन रास्तों से बचें।
- Pre-mortem: मान लें कि लॉन्च विफल हो गया, और शिप करने से पहले ही post-mortem लिख डालें।
- द्वितीय-क्रम सोच: 'और फिर क्या?' परिणामों के परिणामों का नक्शा बनाएँ।
- Steel-manning: असहमति से पहले, विरोधी पक्ष को विरोधी से भी मज़बूत बनाकर प्रस्तुत करें।
- मिथ्याकरणीयता: एक ऐसी मान्यता जिसे कभी ग़लत साबित नहीं किया जा सकता, उपयोगी मान्यता नहीं।
- Hanlon's Razor: जो बात प्रसंग की कमी से पर्याप्त रूप से समझाई जा सकती है, उसे कभी द्वेष पर मत थोपें।
- Chesterton's Fence: कोई बाधा हटाने से पहले समझें कि उसे क्यों लगाया गया था।
PM आर्केटाइप्स (और वे क्यों मायने रखते हैं)
PM टेक की सबसे विस्तृत भूमिकाओं में से एक है। Growth PM का दैनिक जीवन Platform PM से नाटकीय रूप से अलग है। यह जानना कि आपकी भूमिका किस आर्केटाइप के सबसे क़रीब है, यह तय करने में मदद करता है कि किन मेट्रिक्स, साझेदारों और कौशलों में निवेश करना है।
- Product Lead PM: अंत-उपयोगकर्ता-उन्मुख सतहें; डिज़ाइन के साथ गहरी साझेदारी; एक्टिवेशन और रिटेंशन मेट्रिक्स।
- Growth PM: प्रयोग-गहन; फ़नल पर फ़ोकस; मार्केटिंग और डेटा के साथ साझेदारी; AARRR मेट्रिक्स।
- Platform / Infra PM: आंतरिक या डेवलपर-उन्मुख; एर्गोनॉमिक्स, विश्वसनीयता, adoption; क्षमताओं के रोडमैप पर इंजीनियरिंग के साथ साझेदारी।
- Technical PM: गहन तकनीकी सतहें (APIs, SDKs, डेटा प्रोडक्ट, ML सिस्टम); प्रायः लगभग प्रोटोकॉल-शैली में स्पेक लिखता है।
- Data / ML PM: ground truth, मूल्यांकन, मॉडल व्यवहार, डेटासेट अधिकार; अनुसंधान के साथ साझेदारी।
- Internal Tools PM: कर्मचारी ही उपयोगकर्ता हैं; ROI = बचाए गए घंटे और टाली गईं ग़लतियाँ; राजनीति सबसे कठिन हिस्सा है।
निर्णय-फ्रेमवर्क: DACI, RAPID, RACI
प्रोडक्ट में गति मुख्यतः इस बात की स्पष्टता है कि कौन क्या तय करता है। DACI (Driver, Approver, Contributors, Informed) और RAPID (Recommend, Agree, Perform, Input, Decide) प्रोडक्ट निर्णयों के लिए सबसे उपयोगी हैं। RACI ऑपरेशनल रोलआउट के लिए अधिक प्रचलित है। एक चुनें और लगातार उपयोग करें — स्वरूप उतना मायने नहीं रखता जितनी एक ही Approver / Decide नामांकित करने की अनुशासन।
- Driver / Recommend: प्रस्ताव लिखता है; आमतौर पर PM।
- Approver / Decide: निर्णय करता है; केवल एक व्यक्ति, स्पष्ट रूप से नामित।
- Contributors / Input: विशेषज्ञता देते हैं; उनका काम सुना जाना है, वीटो नहीं।
- Informed: सूचित रखे जाते हैं; उन्हें राय देने की ज़रूरत नहीं।
हितधारक मानचित्रण
हितधारक मानचित्र सबसे कम उपयोग किया जाने वाला PM कलात्मक उपकरण है। हितधारकों को शक्ति × रुचि की 2x2 मैट्रिक्स पर रखें। उच्च-शक्ति / उच्च-रुचि वाले योजना के सह-लेखक होने चाहिए। उच्च-शक्ति / कम-रुचि वाले को सूचित रखना चाहिए, हर विवरण पर परामर्श नहीं। कम-शक्ति / उच्च-रुचि वाले आमतौर पर आपके प्रचारक होते हैं। कम-शक्ति / कम-रुचि वाले शोर हैं।
- हर तिमाही की शुरुआत में मानचित्र को ताज़ा करें।
- प्रत्येक हितधारक का व्यक्तिगत दाँव नाम लेकर बताएँ — करियर का जोखिम, टीम का बोझ, ब्रांड पर असर।
- जान-बूझकर संपर्क-बिंदु तय करें, गलियारे की संयोगवश अपडेट नहीं।
PM का ऑपरेटिंग सिस्टम
बेहतरीन PMs साप्ताहिक लय पर चलते हैं — हीरोगिरी पर नहीं। एक सरल लय: सोमवार को परिणामों की समीक्षा (मेट्रिक्स योजना के सापेक्ष कहाँ हैं?), हफ़्ते के बीच में डिस्कवरी और एसिंक लिखित कार्य, बुधवार या गुरुवार को क्रॉस-फ़ंक्शनल वर्किंग सेशन, शुक्रवार को साप्ताहिक नोट। स्टेटस मीटिंग्स को एक-पन्ने के साप्ताहिक नोट से बदलें; तदर्थ अनुरोधों को ट्रायाज क्यू से बदलें।
- डिफ़ॉल्ट रूप से एसिंक लिखित संचार; sync केवल निर्णयों और असहमतियों के लिए सुरक्षित रखें।
- एक सार्वजनिक 'now / next / later' बनाए रखें ताकि हितधारक स्वयं जवाब पा सकें।
- एक निजी 'अज्ञात' लॉग रखें: हर वह धारणा जिसे आपने अभी तक परीक्षित नहीं किया।
- गहन कार्य के लिए समय ब्लॉक करें; कैलेंडर-टेट्रिस स्टेटस का खेल है, उत्पादकता की रणनीति नहीं।
Framework atlas
Reference cards for each method in this mission
Expand a card for when to deploy it, misuse patterns, sequencing guidance, and (where relevant) shorthand formulas.
Decision-making · Atlassian / IntuitDACI(DACI)
एक चार-भूमिका निर्णय फ्रेमवर्क जो हर सार्थक निर्णय के लिए ठीक एक Driver, ठीक एक Approver, Contributors का एक छोटा समूह, और Informed पक्षों की सूची नामित करता है।
When to use
- 3+ टीमों को शामिल करने वाले क्रॉस-फ़ंक्शनल निर्णय।
- ऐसे निर्णय जहाँ आपने पहले महसूस किया हो कि 'कोई प्रभारी नहीं है'।
- आवर्ती तिमाही योजना या रोडमैप कॉल।
When not to
- एक ही टीम के भीतर वास्तव में तुच्छ टाइप-2 निर्णय।
- जब टीम इतनी छोटी हो कि तदर्थ निर्णय फ्रेमवर्क ओवरहेड से सस्ते हों।
How to apply
- निर्णय को एक वाक्य में डेडलाइन के साथ नाम दें।
- एक Driver नियुक्त करें जो निर्णय को हाँ/नहीं तक ले जाने के लिए जिम्मेदार हो।
- एक Approver नियुक्त करें — वह व्यक्ति जो अंतिम निर्णय लेगा।
- Contributors को सूचीबद्ध करें और उनकी विशेषज्ञता की सीमा स्पष्ट रूप से नोट करें।
- Informed पक्षों को सूचीबद्ध करें और बताएँ कि उन्हें कैसे सूचित किया जाएगा।
- Approver को लोगों की सूची बनने देना: वह एक समिति है, approver नहीं।
- Contributors को वीटो-धारक मानना।
- Informed सूची को छोड़ना — आमतौर पर अंतिम-समय के नाटक का स्रोत।
Decision-making · Bain & CompanyRAPID(RAPID)
Recommend, Agree, Perform, Input, Decide। DACI से भारी लेकिन तब उपयोगी जब निर्णय कानूनी/नियामक सीमाओं को पार करते हैं या महत्वपूर्ण वित्तीय परिणाम होते हैं।
When to use
- नियामक या संविदात्मक एक्सपोज़र वाले निर्णय।
- ऐसे निर्णय जहाँ 'Agree' (एक सॉफ्ट वीटो, अक्सर कानूनी/सुरक्षा) 'Input' से सार्थक रूप से अलग है।
When not to
- दिन-प्रतिदिन के प्रोडक्ट ट्रेड-ऑफ़।
- जहाँ DACI की सरल संरचना पर्याप्त है।
How to apply
- Recommend: कौन प्रस्ताव तैयार करता है।
- Agree: किसे साइन-ऑफ़ करना होगा (कानूनी, सुरक्षा, वित्त)।
- Perform: निर्णय लेने के बाद कौन निष्पादित करता है।
- Input: कौन विशेषज्ञता प्रदान करता है।
- Decide: कौन अंतिम निर्णय लेता है।
- Agree को Decide के साथ भ्रमित करना; Agree एक विशिष्ट आयाम पर वीटो है, निर्णय नहीं।
- बहुत सारे निर्णयों को RAPID के माध्यम से रूट करना — ओवरहेड उद्देश्य को विफल कर देता है।
Risk surfacing · Gary KleinPre-Mortem
कल्पना करें कि लॉन्च विफल हो गया, फिर पहले से ही post-mortem लिखें। उन जोखिमों को सामने लाता है जिन्हें लोग सामान्य योजना के दौरान उठाने में बहुत विनम्र या बहुत लंगर डाले हुए हैं।
When to use
- कोई भी टाइप-1 निर्णय।
- प्रतिष्ठा, नियामक, या वित्तीय एक्सपोज़र वाले लॉन्च।
- जब टीम असामान्य रूप से आशावादी हो — 'यह विफल नहीं हो सकता' अलार्म है।
When not to
- प्रतिवर्ती सूक्ष्म-प्रयोग जहाँ विफलता की लागत एक कोहोर्ट और एक सप्ताह है।
How to apply
- दृश्य सेट करें: 'अब से छह महीने बाद है और परियोजना स्पष्ट रूप से विफल हो गई है।'
- प्रत्येक व्यक्ति 5 मिनट के लिए चुपचाप लिखता है: यह क्यों विफल हुआ?
- विफलता के तरीकों को क्लस्टर करें; संभावना और प्रभाव के अनुसार रैंक करें।
- शीर्ष 3-5 को अपनी डिस्कवरी और निष्पादन योजनाओं में जोखिमों के रूप में जोड़ें जिन्हें सेवानिवृत्त करना है।
Personal prioritization · Dwight D. EisenhowerEisenhower Matrix
तत्काल बनाम महत्वपूर्ण का 2x2। तत्काल + महत्वपूर्ण: अभी करें। महत्वपूर्ण लेकिन तत्काल नहीं: शेड्यूल करें। तत्काल लेकिन महत्वपूर्ण नहीं: सौंपें। न तो: छोड़ें। फ़ीचर ट्रायाज जितना व्यक्तिगत ट्रायाज के लिए उपयोगी।
When to use
- ओवरफ़्लो इनबॉक्स या बैकलॉग का ट्रायाज।
- अपने सप्ताह में प्रतिक्रियाशील सहायता कार्य को रणनीतिक कार्य से अलग करना।
When not to
- वास्तविक प्रोडक्ट रोडमैप प्राथमिकता — इसके बजाय RICE/ICE/Kano का उपयोग करें, क्योंकि 'महत्वपूर्ण' पैमाने पर बहुत अस्पष्ट है।
How to apply
- हर खुली माँग या प्रतिबद्धता को सूचीबद्ध करें।
- प्रत्येक को तत्काल या गैर-तत्काल, महत्वपूर्ण या गैर-महत्वपूर्ण के रूप में टैग करें।
- ट्रायाज: करें, शेड्यूल करें, सौंपें, छोड़ें।
- 'तत्काल क्योंकि किसी ने जोर से पूछा' को 'तत्काल क्योंकि डेडलाइन' मानना।
- 'शेड्यूल' बकेट को टालमटोल कब्रिस्तान बनने देना।
Team alignment · Andy Grove / Jeff BezosDisagree and Commit
एक बार निर्णय हो जाने के बाद, जो असहमत थे उन्हें भी पूरी तरह से प्रतिबद्ध होना चाहिए। निर्णय से पहले असहमति को सामने लाता है; बाद में एकता उत्पन्न करता है। 'दुर्भावनापूर्ण अनुपालन' के विपरीत।
When to use
- टाइप-2 निर्णय के बाद जहाँ आपने असहमति सुनी है और निर्णय लिया है।
- जब टीम में साइड चैनलों में निर्णयों को फिर से खोलने की संस्कृति हो।
When not to
- जब असहमति सुरक्षा, नैतिकता, या नियामक अनुपालन के बारे में हो — उन्हें चुप नहीं कराया जाना चाहिए।
How to apply
- निर्णय लेने की प्रक्रिया को पहले से स्पष्ट करें (DACI)।
- निर्णय से पहले स्पष्ट रूप से असहमति को आमंत्रित करें।
- एक बार हो जाने पर, पूछें: 'क्या आप प्रतिबद्ध हो सकते हैं?' — हाँ या 'मैं असहमत हूँ लेकिन प्रतिबद्ध रहूँगा' स्वीकार करें।
- एक समीक्षा तिथि निर्धारित करें ताकि असहमति का भविष्य में दर्शक हो।
Mental model · G.K. ChestertonChesterton's Fence
किसी बाधा, प्रक्रिया, या फ़ीचर को तब तक न हटाएँ जब तक आप यह न समझ लें कि इसे वहाँ क्यों रखा गया था। कई 'स्पष्ट रूप से मूर्ख' सिस्टम पिछली विफलताओं से निशान ऊतक हैं।
When to use
- एक कोडबेस, प्रोडक्ट, या प्रक्रिया को विरासत में लेना जिसे 'स्पष्ट रूप से सरल बनाया जाना चाहिए'।
- हितधारक पुशबैक जो तर्कहीन लगता है — मूल घटना खोजें।
When not to
- जब मूल कारण प्रलेखित हो और स्पष्ट रूप से अब लागू न हो।
How to apply
- बाड़ (नियम, फ़ीचर, समारोह) की पहचान करें।
- सबसे लंबे समय तक कार्यरत व्यक्ति से बात करें जो इसे याद करता है।
- post-mortems और घटना रिपोर्ट खोजें।
- यदि मूल कारण चला गया है, तो स्पष्ट माइग्रेशन योजना के साथ हटाएँ।
Product Psychology
Cognitive biases that distort product decisions
Confirmation Bias
मौजूदा विश्वासों का समर्थन करने वाली जानकारी को खोजने, व्याख्या करने और याद रखने की प्रवृत्ति, जबकि विरोधाभासी साक्ष्य को छूट देना।
Product Risk
टीमें सहायक साक्षात्कार उद्धरणों को चुनती हैं और उस डेटा को अनदेखा करती हैं जो पसंदीदा समाधान को अमान्य कर देगा।
Research Countermove
डिस्कवरी से पहले, लिखें कि कौन सा साक्ष्य परिकल्पना को मिथ्या साबित करेगा। परिकल्पना के लिए जीत और हार को समान कठोरता से ट्रैक करें।
Survivorship Bias
दृश्यमान सफलताओं को अधिक वजन देना जबकि उन उपयोगकर्ताओं, उत्पादों, या कंपनियों को अनदेखा करना जो विफल हुईं और डेटासेट से बाहर हो गईं।
Product Risk
एक टीम ब्रेकआउट उत्पादों से प्रथाओं की नकल करती है बिना उन दर्जनों विफल उत्पादों को देखे जिन्होंने समान रणनीति का उपयोग किया।
Research Countermove
चर्न किए गए उपयोगकर्ताओं, विफल प्रयोगों, खोए सौदों, और परित्यक्त वर्कफ़्लो का अध्ययन पावर उपयोगकर्ताओं और केस स्टडीज के समान कठोरता से करें।
Anchoring
पहली संख्या, फ्रेमिंग, या उदाहरण सुना गया बाद के निर्णयों पर असमान प्रभाव डालता है।
Product Risk
एक जोर से हितधारक की संख्या अंतर्निहित पूर्वानुमान बन जाती है, और हर अनुमान तथ्यों के बजाय इसके सापेक्ष समायोजित हो जाता है।
Research Countermove
चर्चा से पहले अनुमानकर्ताओं को निजी तौर पर संख्याएँ लिखने दें; आधार दरों और ऐतिहासिक संदर्भ वर्गों का उपयोग करें; बैठक में लंगर को स्पष्ट रूप से बुलाएँ।
Sunk Cost Fallacy
पहले से खर्च किए गए संसाधनों के कारण कार्रवाई के एक पाठ्यक्रम में निवेश जारी रखना, बजाय अपेक्षित भविष्य रिटर्न के।
Product Risk
बहु-तिमाही पहलों को वित्त पोषित किया जाता रहता है क्योंकि उन्हें मारना पूर्व कार्य को 'बर्बाद' कर देगा, भले ही आगे की अपेक्षित मूल्य नकारात्मक हो।
Research Countermove
हर तिमाही 'ताज़ी-आँखों' की समीक्षा चलाएँ: 'यदि हम आज जो जानते हैं उसके साथ शुरू कर रहे होते, तो क्या हम इसे फंड करते?' यदि नहीं, तो पुनर्निर्देशित करें।
IKEA Effect
लोग उन चीजों को असमान रूप से महत्व देते हैं जो उन्होंने स्वयं बनाई हैं। आंतरिक टीमें व्यवस्थित रूप से अपने स्वयं के उत्पादों और प्रक्रियाओं को अधिक रेट करती हैं।
Product Risk
PM और इंजीनियरिंग इन-हाउस टूल, डैशबोर्ड, या फ़ीचर को बेहतर-फिटिंग तृतीय-पक्ष विकल्पों पर पसंद करते हैं क्योंकि वे निर्माण की लागत याद करते हैं।
Research Countermove
मूल्यांकन में अंधे तुलनाओं का उपयोग करें। टीम के बाहर किसी को कलाकृति को रेट करने दें। केवल निर्माण लागत नहीं, रखरखाव लागत पूर्वानुमान शामिल करें।
Curse of Knowledge
एक बार जब आप कुछ समझ जाते हैं, तो इसे न समझने की कल्पना करना कठिन हो जाता है; विशेषज्ञ व्यवस्थित रूप से अधिक अनुमान लगाते हैं कि उनकी व्याख्याएँ कितनी स्पष्ट हैं।
Product Risk
PMs मान लेते हैं कि उपयोगकर्ता एक वर्कफ़्लो को 'समझ' जाएँगे क्योंकि टीम समझती है; कॉपी और ऑनबोर्डिंग टीम को धाराप्रवाह और पहली बार उपयोगकर्ताओं को अबोधगम्य रूप से पढ़ते हैं।
Research Countermove
उन उपयोगकर्ताओं के साथ अनमॉडरेटेड परीक्षण चलाएँ जिन्होंने कभी प्रोडक्ट नहीं देखा। 'मुझे नहीं पता कि यहाँ क्या करना है' को सप्ताह का सबसे मूल्यवान डेटा मानें।
Loss Aversion
हानियाँ समतुल्य लाभों की तुलना में लगभग दोगुनी दर्दनाक महसूस होती हैं। उपयोगकर्ता जो उनके पास है उसे खोने से बचने के लिए तर्कहीन काम करेंगे।
Product Risk
टीमें फ़ीचर को सूर्यास्त करते समय हटाने की लागत को कम आंकती हैं; उपयोगकर्ता एक छोटी हटाई गई क्षमता पर चर्न करते हैं जिसका उन्होंने मुश्किल से उपयोग किया।
Research Countermove
हटाते या माइग्रेट करते समय, परिवर्तन को एक लाभ के रूप में फ्रेम करें जो उपयोगकर्ता अर्जित करते हैं (अधिक विश्वसनीय, तेज़, कम बगी)। संक्रमण अवधि प्रदान करें। परिवर्तन से पहले संवाद करें, बाद में नहीं।
Availability Heuristic
हाल के या जीवंत उदाहरण निर्णय पर हावी हो जाते हैं चाहे वे प्रतिनिधि हों या नहीं।
Product Risk
एक क्रोधित कार्यकारी वृद्धि रोडमैप को फिर से आकार देती है क्योंकि यह भावनात्मक रूप से ताज़ा है, भले ही सैकड़ों उपयोगकर्ताओं को एक अलग समस्या थी।
Research Countermove
आवर्ती दृश्य में साक्ष्य एकत्रित करें (समर्थन थीम, NPS वर्बेटिम, चर्न कारण)। प्रश्न को बाध्य करें: 'डेटासेट में यह समस्या कितनी बड़ी है, मेरे इनबॉक्स में नहीं?'
Planning Fallacy
कार्यों में कितना समय लगेगा और वे कितना खर्च करेंगे इसका व्यवस्थित रूप से कम अनुमान, भले ही अनुमानकर्ता ने पहले समान प्रकार के कार्य को कम चलते हुए अनुभव किया हो।
Product Risk
स्प्रिंट प्रतिबद्धताएँ, तिमाही OKRs, और लॉन्च योजनाएँ नियमित रूप से फिसलती हैं; टीम के शब्द में विश्वास समय के साथ घटता है।
Research Countermove
संदर्भ-वर्ग पूर्वानुमान का उपयोग करें: पिछले 3 समान परियोजनाओं में वास्तव में कितना समय लगा? आशावादी अनुमानों को ऐतिहासिक स्लिप कारक से गुणा करें। अज्ञात अज्ञातों के लिए स्पष्ट रूप से योजना बनाएँ।
Action Bias
निष्क्रियता पर कार्रवाई के लिए प्राथमिकता, भले ही उपलब्ध कार्रवाइयों का नकारात्मक अपेक्षित मूल्य हो।
Product Risk
टीमें मेट्रिक गिरावट के बाद 'कुछ करते हुए दिखने' के लिए फ़ीचर शिप करती हैं, कारण समझे जाने से पहले; फ़ीचर स्वयं डीबग करने के लिए नया चर बन जाता है।
Research Countermove
जब मेट्रिक्स गिरें, तो फिक्स शिप करने से पहले कारण को अलग करें। ट्रैक करें कि कौन से 'फिक्स' ने वास्तव में मेट्रिक को हिलाया बनाम कौन से गतिविधि के लिए गतिविधि थे।
Authority Bias
अंतर्निहित साक्ष्य की परवाह किए बिना प्राधिकरण आंकड़ों की राय को असमान वजन दिया जाता है।
Product Risk
एक कार्यकारी की आकस्मिक टिप्पणी तिमाही लक्ष्य बन जाती है क्योंकि कोई इस पर पुशबैक नहीं करता।
Research Countermove
संदेश को संदेशवाहक से अलग करें। कार्यकारी के विचार को एक परिकल्पना के रूप में पुनः बताएँ, फिर इसे किसी अन्य परिकल्पना की तरह साक्ष्य पर मूल्यांकन करें।
Bandwagon Effect
विश्वास और प्रथाएँ फैलती हैं क्योंकि अन्य उन्हें अपना रहे हैं, चाहे वे स्थानीय संदर्भ में फिट हों या नहीं।
Product Risk
टीमें फ्रेमवर्क (OKRs, Shape Up, ICE) अपनाती हैं क्योंकि सहकर्मी कंपनियाँ करती हैं, फिर संदर्भ-बेमेल विफलता का कारण बनने पर फ्रेमवर्क को दोष देती हैं।
Research Countermove
किसी भी प्रथा को अपनाने से पहले, विशिष्ट समस्या को स्पष्ट करें जो यह *आपके लिए* हल करती है। यदि आप नहीं कर सकते, तो आप कार्गो-कल्टिंग कर रहे हैं।
Status Quo Bias
मामलों की वर्तमान स्थिति के लिए प्राथमिकता; विकल्पों को यथास्थिति के सापेक्ष हानियों के रूप में देखा जाता है।
Product Risk
विरासत प्रोडक्ट व्यवहार संरक्षित हैं भले ही डेटा दिखाता है कि वे नए उपयोगकर्ताओं को नुकसान पहुँचाते हैं; 'हम मौजूदा उपयोगकर्ताओं को तोड़ नहीं सकते' बिना शर्त वीटो बन जाता है।
Research Countermove
यथास्थिति की लागत को मापें। अक्सर परिवर्तन का कथित जोखिम ठहराव की चल रही लागत से बौना हो जाता है।
Dunning-Kruger Effect
किसी डोमेन में कम क्षमता अक्सर अति आत्मविश्वास के साथ सहसंबंधित होती है; सक्षम अभ्यासकर्ता विरोधाभासी रूप से अधिक जागरूक होते हैं कि वे क्या नहीं जानते।
Product Risk
जूनियर PMs उन डोमेन में आत्मविश्वास से भरे रोडमैप शिप करते हैं जिन्हें वे मुश्किल से समझते हैं; सीनियर PMs इतना हेज करते हैं कि वे अनिर्णायक दिखते हैं।
Research Countermove
आत्मविश्वास-महसूस करने वाले दावों के लिए, पूछें: 'इसके खिलाफ सबसे मजबूत तर्क क्या है?' यदि आप एक नहीं बना सकते, तो आप अभी तक क्षेत्र को नहीं समझते।
Rhyme-as-Reason Effect
आकर्षक या तुकबंदी वाले कथन समान रूप से सटीक लेकिन कम सुरुचिपूर्ण कथनों की तुलना में अधिक सत्य महसूस होते हैं।
Product Risk
यादगार अनुसंधान सारांश रोडमैप-चालक सत्य के रूप में दोहराए जाते हैं भले ही अंतर्निहित साक्ष्य कमजोर हो।
Research Countermove
किसी भी आकर्षक वाक्यांश को देखे गए व्यवहार या डेटा से जुड़ी मिथ्याकरणीय धारणा में अनुवाद करें।
Organizational anti-patterns
When ceremonies look like rigor but aren't
The Feature Factory
रोडमैप प्रगति को प्रति तिमाही शिप किए गए फ़ीचर में मापा जाता है। परिणाम केवल तभी रिपोर्ट किए जाते हैं जब सुविधाजनक हो। डिस्कवरी स्प्रिंट का सप्ताह 1 जो भी हो।
आउटपुट गिनना आसान है; परिणामों में समय और ईमानदारी लगती है। गतिविधि प्रदर्शन समीक्षाओं में प्रभाव के लिए प्रॉक्सी बन जाती है।
हर रोडमैप आइटम को लक्ष्य मेट्रिक आंदोलन पर फिर से आधारित करें। समीक्षाओं में फ़ीचर गिनती मेट्रिक को मारें। मारे गए बुरे दांवों को शिप किए गए अच्छे दांवों के समान मनाएँ।
Stakeholder Ventriloquism
PM 'CEO चाहता है' या 'बिक्री ने कहा' के साथ निर्णयों को उचित ठहराता है; कोई प्रथम-हाथ उपयोगकर्ता साक्ष्य प्रस्तुत नहीं किया जाता; टीम डिलीवरी सेवा की तरह महसूस करती है।
PM संघर्ष-विरोधी या कम-सूचित है और आइटम को धक्का देने के लिए प्राधिकरण लॉन्ड्रिंग का उपयोग करता है।
हर हितधारक माँग को इंजीनियरिंग में लाने से पहले एक उपयोगकर्ता समस्या और एक साक्ष्य सूची में अनुवाद करें। यदि साक्ष्य कमजोर है, तो ऊपर की ओर पुशबैक करें।
Solutioneering
स्पेक सीधे UI मॉक पर कूदते हैं। पहली स्लाइड एक स्क्रीन है, समस्या नहीं। डिस्कवरी, यदि कोई हो, डिज़ाइन शुरू होने के बाद होती है।
समाधान ठोस और रोमांचक हैं; समस्याएँ अमूर्त और असहज हैं।
किसी भी UI से पहले, हर स्पेक के पृष्ठ 1 पर समस्या कथन, उपयोगकर्ता, वर्तमान विकल्प, और सफलता मेट्रिक लिखें।
The Roadmap as Wishlist
रोडमैप में 40 आइटम हैं, सभी H2 प्राथमिकताएँ, कोई अनुक्रमण तर्क नहीं। हर तिमाही, टीम इस सब के लिए प्रतिबद्ध होती है और एक तिहाई समाप्त करती है।
PM हितधारकों को शांत करने के लिए रोडमैप का उपयोग करता है बजाय दांव लगाने के।
रोडमैप को 'अभी / अगला / बाद में' तक सीमित करें जिसमें प्रति तिमाही 3-5 से अधिक थीम न हों। ट्रेड-ऑफ़ बातचीत को अंत में नहीं, शुरुआत में बाध्य करें।
Discovery Theater
टीम 'डिस्कवरी' चलाती है जिसमें स्पेक लिखे जाने के बाद कुछ उपयोगकर्ता साक्षात्कार शामिल होते हैं। निष्कर्षों को मौजूदा योजना की पुष्टि करने के लिए सारांशित किया जाता है।
डिस्कवरी को सीखने के लूप के बजाय एक अनुष्ठान के रूप में अपनाया गया है।
साक्षात्कार से *पहले* सबसे जोखिम भरी धारणा और मिथ्याकरण मानदंड को परिभाषित करें। निष्कर्षों के आधार पर स्पेक को बदलने या परियोजना को मारने का अधिकार सुरक्षित रखें।
Outcome Theater
हर परियोजना अचानक एक अस्पष्ट परिणाम ('उपयोगकर्ता अनुभव में सुधार') से जुड़ी है; कोई भी इस बात पर सहमत नहीं हो सकता कि कौन सा मेट्रिक, बेसलाइन, या थ्रेशोल्ड सफलता के रूप में गिना जाता है।
टीमों ने 'परिणाम-केंद्रित रहें' सुना है लेकिन परिणामों को परिभाषित करने और मापने में कठोरता की कमी है।
तिकड़ी को बाध्य करें: मेट्रिक, बेसलाइन, लक्ष्य, कब-तक। यदि आप किसी पहल के लिए सभी चार नहीं लिख सकते, तो यह एक परिणाम के रूप में तैयार आउटपुट है।
Worked examples
Walkthroughs translated from real trade-off rooms
'साइनअप को आसान बनाएँ' को फिर से फ्रेम करना
एक B2B SaaS PM को बिक्री से एक अनुरोध मिलता है: 'हम ट्रायल उपयोगकर्ताओं को साइनअप पर खो रहे हैं। साइनअप को आसान बनाएँ।'
- समाधान का विरोध करें: 'आसान' मिथ्याकरणीय नहीं है।
- उपयोगकर्ता व्यवहार को परिभाषित करें: 'ईमेल क्लिक के 10 मिनट के भीतर पहली मूल्यवान क्रिया तक पहुँचें।'
- डेटा खींचें: 38% ट्रायल ईमेल पुष्टि और टीम आमंत्रण चरण के बीच गिर जाते हैं।
- मौजूदा प्रवाह पर 5 अनमॉडरेटेड परीक्षण चलाएँ; घर्षण बिंदुओं का निरीक्षण करें।
- दो स्कोप्ड प्रयोगों का प्रस्ताव करें: आलसी टीम आमंत्रण या सरलीकृत ईमेल पुष्टि।
Takeawayफ़ीचर अनुरोध 'साइनअप को आसान बनाएँ' एक मापने योग्य व्यवहार से जुड़े दो मिथ्याकरणीय दांव बन गया, टाइप-1 प्रतिबद्धता से पहले सीखने के लिए एक तेज़ टाइप-2 प्रयोग के साथ।
प्रोडक्ट त्रिभुज का उपयोग करके एक कार्यकारी माँग को ना कहना
CEO इस तिमाही में मार्केटिंग साइट पर एक चैट विजेट जोड़ना चाहता है ताकि 'संभावनाओं को संलग्न' किया जा सके।
- लक्ष्य को स्वीकार करें: अधिक योग्य पाइपलाइन।
- त्रिभुज पर चलें: व्यवहार्यता — योग्य पाइपलाइन पर अपेक्षित वृद्धि क्या है? उपयोगिता — क्या संभावना वास्तव में अभी एक समकालिक चैट चाहती है? साध्यता — लॉन्च तिमाही के दौरान तीन समय क्षेत्रों में चैट को स्टाफ करना।
- दो विकल्प प्रस्तुत करें: उत्तर SLA के साथ एक छोटा एसिंक्रोनस फॉर्म, या केवल योग्य खातों के लिए गेटेड चैट विजेट।
- DACI के साथ निर्णय को फ्रेम करें: Driver: PM; Approver: CEO; Contributors: Sales, CS, Design, Eng।
Takeawayशाब्दिक माँग को ना कहा, अंतर्निहित लक्ष्य को हाँ कहा, और CEO को विनम्र इनकार के बजाय एक वास्तविक निर्णय दिया।
डिस्कवरी स्प्रिंट में पुष्टिकरण पूर्वाग्रह को पकड़ना
टीम को विश्वास है कि अगला बड़ा दांव सहयोगी संपादन है। 8 साक्षात्कारों के बाद, उद्धरणों का डेक अत्यधिक सहायक है।
- रुकें और मिथ्याकरण मानदंड लिखें: 'यदि 30% से कम उपयोगकर्ता स्वतः स्फूर्त रूप से हाल के सहयोगी-संपादन दर्द का वर्णन करते हैं, तो माँग हमारे विचार से कमजोर है।'
- साक्षात्कार कॉर्पस को स्वतःस्फूर्तता द्वारा फिर से टैग करें: कितने उद्धरण बिना प्रेरित बनाम प्रेरित थे?
- पाएँ कि अधिकांश सहायक उद्धरण प्रेरित थे; केवल 18% बिना प्रेरित थे।
- दांव को फिर से फ्रेम करें: सहयोगी संपादन अवधारणा में वांछित है लेकिन अभी तक शीर्ष-दिमाग का दर्द नहीं है। इसे Q1 से Q3 में ले जाएँ और एक वास्तविक शीर्ष-दिमाग के दर्द के साथ बैक-फिल करें।
Takeawayपुष्टिकरण पूर्वाग्रह ने चुपचाप कथित माँग को बढ़ा दिया। एक सरल मिथ्याकरण जाँच ने रोडमैप को पुनर्संतुलित किया।
Resources / Case Studies
Curated reading for this mission
Ben Horowitz
मजबूत उत्पाद प्रबंधकों बनाम कमजोर लोगों की विफलता मोड पर अपेक्षित ऑपरेटिंग मानकों पर 1996 का मेमो।
गतिविधि या प्रक्रिया थिएटर के बजाय परिणामों के लिए जिम्मेदारी के आसपास उत्पाद मानसिकता को लंगर डालता है।
Marty Cagan (SVPG)
आधुनिक उत्पाद प्रबंधन पर विहित पाठ। उत्पाद खोज, उत्पाद तिकड़ी, परिणाम बनाम आउटपुट, और सशक्त उत्पाद टीम की भूमिका को कवर करता है।
शब्दावली को परिभाषित करता है जो बाकी उद्योग उपयोग करता है। आवश्यक पठन।
Marty Cagan & Chris Jones (SVPG)
INSPIRED का साथी खंड। उत्पाद नेताओं को सशक्त उत्पाद टीमों को वास्तविक समस्याओं को खोजने और हल करने में सक्षम बनाने के लिए क्या करना चाहिए, इस पर ध्यान केंद्रित करता है।
PM शिल्प और संगठनात्मक प्रणाली के बीच की खाई को बंद करता है जो उस शिल्प को चक्रवृद्धि करने देती है।
Lenny Rachitsky
PM के सप्ताह का ठोस विघटन, खोज, वितरण, संरेखण और प्रबंधन के लिए समय आवंटन के साथ।
नए PMs के लिए नौकरी को रहस्यमुक्त करता है और अनुभवी PMs को एक बेंचमार्क देता है जहाँ वे अधिक या कम निवेश कर रहे हैं।
Shreyas Doshi
उच्च-एजेंसी PMs कैसे संचालित होते हैं: झूठी बाधाओं को अस्वीकार करना, लीवरेज खोजना, और अस्पष्टता को कार्रवाई में अनुवाद करना।
ऑपरेटिंग मानसिकता पर सबसे केंद्रित बात जो महान PMs को सक्षम लोगों से अलग करती है।
Julie Zhuo
प्रबंधन के शुरुआती वर्षों के लिए व्यावहारिक, स्पष्ट मार्गदर्शिका — वरिष्ठ PMs पर लागू जिनका काम तेजी से अन्य लोगों के माध्यम से है।
सामान्य MBA फ्लफ के बिना IC PM और Lead PM संक्रमण को पाटता है।
Annie Duke
अनिश्चितता के तहत निर्णय लेना, पोकर से लिया गया। परिणाम गुणवत्ता को निर्णय गुणवत्ता से अलग करता है।
PMs को उस समय उपलब्ध इनपुट पर निर्णयों का मूल्यांकन करना सिखाता है, पश्चदृष्टि पर नहीं, जो ईमानदार postmortems की नींव है।
Daniel Kahneman
संज्ञानात्मक पूर्वाग्रहों, दोहरी-प्रणाली सोच, और संभावना सिद्धांत का निश्चित लोकप्रिय उपचार।
इस पाठ्यक्रम में हर पूर्वाग्रह अनुभाग और उत्पाद में व्यवहार अर्थशास्त्र के अधिकांश को रेखांकित करता है।
Teresa Torres
खोज को एक चरण के बजाय साप्ताहिक आदत के रूप में संचालित करता है। अवसर समाधान वृक्ष का परिचय देता है।
PM-डिज़ाइन-इंजीनियरिंग तिकड़ी के लिए एक व्यावहारिक आधार रेखा सेट करता है जो फ़ीचर अनुरोधों से माँग-नेतृत्व वाले उत्पाद निर्णयों की ओर बढ़ना चाहती है।
Marty Cagan (SVPG)
Cagan का स्पष्टीकरण कि उत्पाद टीमों को कैसे संरचित और जवाबदेह ठहराया जाना चाहिए: सशक्त टीमें, परिणाम, और निरंतर अभ्यास के रूप में खोज।
पाठ्यक्रम के बाकी हिस्सों में मान ली गई ऑपरेटिंग मॉडल को क्रिस्टलाइज़ करता है।
Jeff Bezos (1997 Shareholder Letter)
टाइप-1 / टाइप-2 भेद, Bezos के अपने शब्दों में, उनके 2015 शेयरधारक पत्र में एम्बेडेड।
निर्णय गति को प्रतिवर्तीता से मिलान करने के लिए पुनः प्रयोज्य फ्रेम प्रदान करता है — एक दैनिक PM उपकरण।
Lenny Rachitsky
वरिष्ठ PMs और संस्थापकों के साथ लंबे-रूप साक्षात्कार जो खोज, विकास, मुद्रीकरण और नेतृत्व को कवर करते हैं।
कंपनियों और चरणों में वर्तमान PM अभ्यास के लिए सबसे अच्छा चल रहा ऑडियो स्रोत।