कैसे एक प्रोग्रामर एक उत्पाद प्रबंधक बन गया

जिम गोशी, न्यू रेलीक इंक।
11 सितंबर 2012

एक डेवलपर एक उत्पाद प्रबंधक लेख अनुवाद बन जाता है

अच्छे पुराने दिनों में, मैंने प्रोग्रामिंग करके जीवनयापन किया। यह मेरे कामकाजी जीवन में सबसे अच्छे और सबसे अधिक लापरवाह चरणों में से एक था। कोड लिखने के अलावा, मेरी कुछ अन्य जिम्मेदारियां थीं। मुझे नहीं पता था कि कंपनी ने मेरे वेतन के लिए पैसा कहां से लिया और मुझे इस बात का कोई पता नहीं था कि ग्राहक हमारे उत्पाद के बारे में कैसे पता लगाएंगे। मैंने इस बारे में नहीं सोचा कि मेरे बॉस ने मुझसे X / Y / Z के फीचर्स को प्रोग्राम करने के लिए क्यों कहा - मैंने अभी कोड लिखा है। मेरा समय दिलचस्प तकनीकी समस्याओं को हल करने पर बिताया गया था, और सामान्य तौर पर, मेरा जीवन प्रोग्रामिंग के आसपास घूमता था।

असली दुनिया

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



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

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

लक्ष्यों को परिभाषित करना

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

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

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

और यद्यपि मुझे कभी-कभी प्रोग्रामिंग याद आती है, मैं इसके लिए उत्पाद प्रबंधन का आदान-प्रदान करने के लिए तैयार नहीं हूं। मुझे NewRelic की सफलता में एक महत्वपूर्ण भूमिका निभाना पसंद है, और मुझे पसंद है कि NewRelic कितना सफल है!