उत्पाद प्रबंधन अवधारणाओं को समझाने में मदद करने के लिए छह योजनाएं

उत्पाद प्रबंधन में प्रमुख विचारों को समझने और समझाने के लिए उपयोगी कुछ चित्र

वे कहते हैं कि एक तस्वीर एक हजार शब्दों के लायक है, लेकिन ईमानदार होने के लिए, मुझे लगता है कि यह एक समझ भी है: विज़ुअलाइज़ेशन विचार की एक सामान्य समझ सुनिश्चित करने, संचार को सरल बनाने और लिखित और बोली जाने वाली भाषा में निहित अधिकांश बारीकियों को खत्म करने में मदद करता है।

मैं आपको उन छह योजनाओं को दिखाना चाहता हूं, जिनका उपयोग मैं अक्सर उत्पाद प्रबंधन से संबंधित विचारों पर चर्चा करते समय करता हूं। वे दर्शकों द्वारा अच्छी तरह से प्राप्त होते हैं और सार को पूरी तरह से व्यक्त करते हैं। ये योजनाएं हैं:

• "उत्पाद प्रबंधक एक अड़चन के रूप में।"
  
• "उत्पाद वितरण कीप।"
  
• "क्लासिक गतिरोध झरना - फुर्तीली।"
  
• "पहल का आकार, जोखिम, और नेतृत्व की भागीदारी।"
  
• "ज्ञान के बंकर।"
  
• सेगमेंटेशन का महत्व।
  

आप उन्हें अपने काम में किसी भी तरह से उपयोग कर सकते हैं।

Alconost में अनुवादित

"उत्पाद प्रबंधक एक अड़चन के रूप में"

सबसे आम गलतियों में से एक है कि मैं उत्पाद प्रबंधकों के साथ नोटिस सभी चर्चाओं में भाग लेने की इच्छा है। हां, यह सही इरादा है: आपको उत्पाद के बारे में किसी भी प्रश्न का उत्तर देने में सक्षम होने के लिए सब कुछ समझने की आवश्यकता है।

दुर्भाग्य से, इस दृष्टिकोण में कई कमियां हैं। सबसे पहले, यह अव्यवहारिक है: आपको जल्दी से जानकारी से अतिभारित किया जाएगा, जो न केवल टीम की प्रभावशीलता को प्रभावित करेगा, बल्कि आपकी भलाई भी होगा। मेरा विश्वास करो - मैंने खुद पर यह अनुभव किया। दूसरे, आप इस प्रकार टीम की स्वायत्तता को नष्ट कर रहे हैं।

एक अच्छा उत्पाद प्रबंधक जानता है कि कब हस्तक्षेप करना है, और जब एक तरफ कदम बढ़ाना बेहतर है - वे बात करेंगे और इसे अपने लिए समझेंगे। एक स्वायत्त टीम बनाने का लक्ष्य अधिक से अधिक निर्भरता को खत्म करना है।

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

उदाहरण के साथ इसकी तुलना करें: वेब डेवलपर सीधे विश्लेषक को पहले संबोधित करता है (जो बताता है कि क्या आवश्यक है), और फिर आईओएस विशेषज्ञ (जो आवश्यक जानकारी प्रदान करता है)। ध्यान दें कि इस मामले (लाल तीर) में कितनी कम बातचीत होती है।



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



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

"उत्पाद वितरण कीप"

यह मेरे पसंदीदा पैटर्न में से एक है: यह मुझे उन परियोजनाओं के आकार के बारे में एक टीम उत्पादकता फ़नल की अवधारणा को समझाने की अनुमति देता है, जिन पर काम किया जा रहा है। उत्पाद के बाजार में प्रवेश करने में लगने वाले समय के बारे में अक्सर मुझे दोनों व्यापार भागीदारों और डेवलपर्स की निराशा का सामना करना पड़ता है: ऐसा लगता है कि काम बहुत धीरे चल रहा है।



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

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

योजना कैसे लागू करें याद रखें कि आपको हाल के महीनों में क्या काम करना पड़ा था (क्या गिरा था सहित)। क्या सभी कार्य बड़े पैमाने पर और जटिलता में थे, या यह विभिन्न वर्तमान कार्यों (दोनों एक विषय पर और अलग-अलग) का संयोजन था? प्रत्येक कार्य को एक आकार दें (उदाहरण के लिए, S, M, L स्केल पर) और कल्पना करें कि फ़नल कैसा दिखेगा।

"क्लासिक गतिरोध झरना - चंचल"

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

जब एक टीम बड़े टुकड़ों में काम देती है, तो हम तत्काल प्रभाव पाने की उम्मीद करते हैं। लेकिन यहां तक ​​कि अगर हम मानते हैं कि हम तुरंत तकनीकी समस्याओं के बिना सही समाधान जारी करते हैं (मैं आपको एक रहस्य बताऊंगा: यह बहुत संभावना नहीं है), यह पता चला है कि हमारी टीम (यदि आप समयरेखा देखें) ने बड़े निवेश किए जो काम नहीं किए (बाईं ओर चार्ट)।

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



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

"पहल का आकार, जोखिम और नेतृत्व की भागीदारी"

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



दाईं ओर प्रबंधन की भागीदारी का एक संकेतक है। यह जितना व्यापक होता है, कार्य में प्रबंधन की भागीदारी की उतनी ही अधिक आवश्यकता या अपेक्षा होती है - अर्थात, उच्चतर श्रेणी के प्रबंधकों की अधिक संख्या के साथ यह परामर्श करना आवश्यक है। सूचक जितना संकीर्ण होगा, "उच्चतर" को संदर्भित करने की कम आवश्यकता होगी।

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

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

काम में प्रबंधकों की भागीदारी का विषय बल्कि जटिल है। मैंने लेख में इसकी और अधिक विस्तार से समीक्षा की कि "मॉडल का निर्धारण क्यों करें" सभी समस्याओं का समाधान नहीं करता है ।

"ज्ञान बंकर"

यह चार्ट उस टीम की स्थिति की त्रैमासिक जाँच का परिणाम है जहाँ मेरे सहयोगी ने काम किया। ज्ञान बंटवारे के संबंध में विभागों और टीमों के अलगाव के प्रभाव की कल्पना करने का यह एक शानदार तरीका है। उत्पाद से प्रभावित सभी क्षेत्रों में 100% जानकार होना असंभव है, लेकिन अगर आपको ज्ञान की कमी का एहसास है, तो इससे विभागों के बीच संचार पर ध्यान केंद्रित करने में मदद मिलेगी।

एक व्यक्तिगत कर्मचारी आमतौर पर अच्छी तरह से वाकिफ होता है कि वह क्या काम कर रहा है। लेकिन आप दूसरों से जितने दूर हैं, उतने ही कम वे "आपके" विषय के हैं।



योजना कैसे लागू करें अपने आप को और दूसरों को याद दिलाएं कि संगठन में काम इस तथ्य के कारण धीमा हो जाएगा कि कोई भी सब कुछ नहीं जान सकता है, और इससे भी महत्वपूर्ण बात यह है कि अगर कोई संघर्ष होता है, तो सबसे संभावित कारणों में से एक जानकारी की कमी होगी, और दुर्भावनापूर्ण इरादे नहीं ( लेख को गलत समझें, दुर्भावनापूर्ण इरादे नहीं )।

सेगमेंटेशन का महत्व

आम गलतियों में से एक है जो मैं तब सामना करता हूं जब कोई कंपनी पहल पर विचार करती है और प्रयोगों का औसत मूल्यों द्वारा अनुकूलन होता है, न कि खंडों द्वारा। मेरा पसंदीदा उदाहरण औसत धारणा से विकृत है: "औसतन, एक व्यक्ति के दो पैर कम होते हैं।"

यदि परिकल्पना और कवरेज के क्षेत्र बहुत व्यापक हो जाते हैं, तो वे स्वाभाविक रूप से परीक्षण के संभावित प्रभाव को सीमित करते हैं। वास्तव में, आप एक ही समय में कई लोगों को संतुष्ट करने की कोशिश कर रहे हैं - और यह काम करने की संभावना नहीं है। नीचे दिए गए आरेख में, सबसे आम तीसरा मामला है (दाईं ओर), जिसमें कोई महत्वपूर्ण परिवर्तन नहीं हैं।

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

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

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

निष्कर्ष

वह सब है। मुझे उम्मीद है कि उपरोक्त आरेख और चित्र कुछ अवधारणाओं की कल्पना करने और उन्हें दूसरों को समझाने में मदद करते हैं!

अनुवादक के बारे में

लेख का अनुवाद अल्कोनोस्ट ने किया था।

Alconost 70 भाषाओं में खेल , एप्लिकेशन और साइटों को स्थानीय करता है। मूल भाषा के अनुवादक, भाषाई परीक्षण, एपीआई के साथ क्लाउड प्लेटफ़ॉर्म, निरंतर स्थानीयकरण, परियोजना प्रबंधक 24/7, स्ट्रिंग संसाधनों का कोई भी प्रारूप।

हम विज्ञापन और प्रशिक्षण वीडियो भी बनाते हैं - Google Play और ऐप स्टोर के लिए बिक्री, छवि, विज्ञापन, प्रशिक्षण, टीज़र, खोजकर्ता, ट्रेलरों के लिए।

→ और पढ़ें