अधिक उत्पाद, कम उत्पाद प्रबंधक

प्रोडक्ट मैनेजर्स बनाम अन्य भूमिकाओं की भूमिका

• “प्रोडक्ट” और “प्रोजेक्ट” मैनेजमेंट के बीच लगातार भ्रम; कई संगठन इन्हें एक ही मान लेते हैं।
• कुछ लोग PM को “अतिरिक्त कदमों के साथ प्रोजेक्ट मैनेजमेंट” (बाज़ार, ग्राहक, रणनीति) मानते हैं।
• अन्य एक साफ़ विभाजन करते हैं: PM क्यों/क्या का मालिक, प्रोजेक्ट मैनेजर कब, इंजीनियरिंग कैसे/कौन।
• व्यावहारिक रूप से, कई PMs को प्रोजेक्ट समन्वय और Jira प्रशासन में धकेल दिया जाता है।

अच्छे PMs क्या करते हैं (थ्रेड के अनुसार)

• “मिनी-CEO” की तरह काम करते हैं: ग्राहकों, बाज़ार और व्यावसायिक लक्ष्यों को समझते हैं; विज़न और रणनीति को आकार देते हैं।
• उपयोगकर्ताओं, बिक्री, सपोर्ट के साथ पर्याप्त समय बिताते हैं; फ़ीडबैक को स्पष्ट समस्याओं और प्राथमिकताओं में संक्षेपित करते हैं।
• हितधारकों और इंजीनियरों के बीच सेतु बनाते हैं, संदर्भ देते हैं, समझौते सँभालते हैं, और फोकस की रक्षा करते हैं।
• तकनीकी/आर्किटेक्चर की पर्याप्त समझ रखते हैं ताकि सीमाएँ समझ सकें और काम को बुद्धिमानी से क्रमबद्ध कर सकें।

PMs की सामान्य आलोचनाएँ

• कई PMs को टिकट इधर-उधर करने वाले, मीटिंग बनाने वाले, या बहुत कम वास्तविक स्वामित्व वाले “bullshit jobs” के रूप में देखा जाता है।
• CPO संगठनों में साम्राज्य-निर्माण PMs को रणनीति से दूर, बेहद छोटे हिस्सों (एकल पेज, बटन CTRs) का मालिक बना देता है।
• PMs अक्सर तकनीकी जटिलता समझे बिना “कैसे” पर माइक्रोमैनेज करते हैं, या उपयोगकर्ताओं से पूरी तरह बचते हैं।
• इंजीनियर PM-प्रेरित राजनीति, स्टेटस थिएटर, और स्पष्ट प्रोडक्ट दिशा के बिना शेड्यूल दबाव की शिकायत करते हैं।

क्या इंजीनियर प्रोडक्ट ओनर हो सकते हैं?

• कुछ लोगों का तर्क है कि सबसे अच्छी टीमों में PMs नहीं थे: इंजीनियर और बिज़नेस हितधारक सीधे ग्राहकों से बात करते थे।
• प्रतितर्क: प्रोत्साहन और समय के बिना अधिकांश इंजीनियर प्रोडक्ट और प्रोजेक्ट मैनेजमेंट में अच्छे नहीं होते; PM का काम फिर भी किसी को करना पड़ता है।
• PMs के बिना दिखने वाले उदाहरण: अस्पष्ट लक्ष्य, कमज़ोर उपयोगकर्ता शोध, आंतरिक “कैंप्स,” अत्यधिक इंजीनियर किया गया लेकिन असंगत फीचर्स।

अनुपात, स्केल, और संगठन डिज़ाइन

• इस बात पर सहमति कि “ज़्यादा PMs ≠ बेहतर”; अनुपात ऐसा होना चाहिए कि दखल कम हो और स्वायत्तता अधिकतम।
• PMs तब सबसे अधिक मूल्य जोड़ते हैं जब वे महत्वपूर्ण सतह क्षेत्र (पूरा उत्पाद या बड़ा मॉड्यूल) संभालते हैं, न कि केवल एकल स्क्रीन।
• स्टार्टअप्स में, कई लोगों का मानना है कि संस्थापकों को तब तक PM का काम करना चाहिए जब तक वे वास्तव में न कर सकें; बहुत जल्दी अतिरिक्त PMs नौकरशाही बन जाते हैं।

तकनीकी बनाम गैर-तकनीकी / डोमेन विशेषज्ञता

• कई लोग ऐसे PMs पसंद करते हैं जिनके पास कम से कम कुछ कोडिंग या सिस्टम समझ हो, खासकर तकनीकी उत्पादों या विनियमित डोमेन्स के लिए।
• अन्य लोग गहरी टेक समझ से अधिक डोमेन और उपयोगकर्ता विशेषज्ञता (फाइनेंस, HR, मेडिकल, रिटेल) पर ज़ोर देते हैं।
• सबसे अच्छे PMs कथित तौर पर उपयोगकर्ता-समझ, व्यापारिक समझ, और समझौतों पर चर्चा के लिए पर्याप्त तकनीकी अंतर्ज्ञान को जोड़ते हैं।

प्रोत्साहन, राजनीति, और संस्कृति

• प्रोत्साहन संरचनाएँ अक्सर उपयोगकर्ता प्रभाव की तुलना में तकनीकी आउटपुट को पुरस्कृत करती हैं, जिससे इंजीनियर PM-जैसे काम से हतोत्साहित होते हैं।
• PM व्यवहार संगठनात्मक प्रोत्साहनों से आकार लेता है: यदि प्रमोशन स्लाइडवेयर और बड़ी मीटिंग्स से जुड़ा है, तो वही मिलेगा।
• कई लोग नोट करते हैं कि PMs पर दोष डाली जाने वाली dysfunction अक्सर नेतृत्व और संस्कृति की समस्या होती है, न कि भूमिका की अंतर्निहित।

विविध साइड थ्रेड्स

• AI/स्टॉक “हीरो” इमेजरी और उनके कम-गुणवत्ता, सामान्य-से महसूस होने पर संक्षिप्त लेकिन तीखी बहस।
• “बहुत सारी भूमिकाओं” (PM, scrum master, QA, आदि) वाले बड़े टेक पर व्यापक विचार और अधिक lean, flatter teams की अपील।