एक सफल उत्पाद प्रबंधक के लिए 3 प्रमुख गुण: एंटोन स्टोझको

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

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

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

- और आप इन कौशल को कैसे विकसित कर सकते हैं? क्या यह कहना संभव है कि वे आपकी टीम और आपके व्यवसाय में क्या हो रहा है इसके लिए जिम्मेदारी की भावना से आते हैं?

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

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

- और इसे कैसे खोलना है?

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

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

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

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

तो सवाल का जवाब: "यह कैसे होता है?" - "अलग-अलग तरीकों से!"

ऐसा होता है कि आप एक शीर्ष प्रबंधक से एक विचार प्राप्त करते हैं और समझते हैं कि किसी प्रकार के प्रवाह में संभावित महान मूल्य है। मेरा कार्य इस मूल्य की पहचान करना है, यह समझना कि इसे वर्कफ़्लो में कैसे एकीकृत किया जाए और यह जांचा जाए कि क्या यह मौजूदा प्राथमिकता वाले कार्यों में हस्तक्षेप नहीं करता है।

ऐसा होता है कि एक बहुत विशिष्ट कार्य नीचे आता है, और इसे लेने और करने की आवश्यकता होती है।
वैसे, गहरे अर्थों में, एक विचार, अंतर्दृष्टि या रणनीति से सीधे निर्धारित कार्य केवल सन्निकटन और परिष्कार की डिग्री से अलग होता है।

- और मुझे बताओ, कृपया, एक उत्पाद और सहयोगी उत्पाद के बीच क्या अंतर है?

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

उसी समय, सुविधा कैसे कार्य करेगी और इसकी आवश्यकता क्यों है - हर कोई समझता है। इसलिए, इस स्तर पर आपको फ़ॉर्म में एक कार्य मिलता है: "चलो, इसे करो।" टीम का परिचालन प्रबंधन आपके साथ, बैकलॉग फिलिंग पर निर्भर करता है। यह उत्पाद का मुख्य घटक नहीं है, लेकिन प्रस्थान का एक उत्कृष्ट बिंदु है।

बैकलॉग भरें कई जानते हैं कि कैसे। यह लिखने में कुछ भी जटिल नहीं है कि जब आप इसे बनाते हैं तो एक फीचर कैसे काम करना चाहिए, और फिर डेवलपर्स के साथ इस पर बात करें। इसके बाद के सभी मूल्यांकन और नियोजन का विषय है।

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

इसके बाद निर्णय लेने का तीसरा स्तर आता है। यहाँ वे अब आपके लिए एक समस्या नहीं बताते हैं, लेकिन कहते हैं: "हमें लगता है कि शायद यहाँ कहीं समस्या है।" और आपका कार्य पहले से ही एक समस्या है।

- यानी, तीसरे स्तर पर, आप समस्या को स्वयं उजागर करके शुरू करते हैं, फिर आप स्वयं एक समाधान प्रस्तावित करते हैं और फिर इसे अंत तक लाते हैं?

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

- समझ गया। आपने कहा कि ब्लूप्रिंट स्तर पर, उन्होंने पहले से ही दूसरे निर्णय लेने के स्तर पर काम किया, और तीसरे पर ऑनबोर्डिंग समस्या को हल किया। क्या चौथा, पाँचवाँ स्तर है, इत्यादि? या अभी भी एक अंत है?

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

यही है, संक्षेप में, स्केलिंग आगे बढ़ता है: क्षितिज की संख्या जिसे गले लगाने की आवश्यकता होती है, बढ़ जाती है। प्रतिनिधिमंडल के लिए यह संभव है। और इस चौथे स्तर पर, आपको यह सुनिश्चित करने की आवश्यकता है कि जो लोग तीसरे पर हैं, वे आपके पास ऐसे प्रस्ताव और प्रस्तुतियाँ लेकर आते हैं, जिनके आधार पर आप निर्णय ले सकते हैं या सलाह दे सकते हैं ताकि पहिया घूमता रहे।

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

- जैसा कि मेरे गुरु कहना पसंद करते हैं: "केवल उत्पाद संसाधन अन्य लोगों के साथ संबंध है," यानी संचार।

- और संचार कौशल के हिस्से के रूप में, आपको दैनिक स्तर पर किन समस्याओं से जूझना पड़ता है?

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

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

- मैं कुछ सवाल पूछना चाहूंगा। कृपया मुझे बताएं, क्या आपकी पृष्ठभूमि शुरू में मूल है या नहीं?

- नहीं। मैंने अपने जीवन में कभी भी एक पंक्ति का कोड नहीं लिखा है। ठीक है, शायद 100 साल पहले 6 वीं कक्षा में कंप्यूटर विज्ञान के पाठ में बीएएसआईसी। मेरे काम में, यह एक महत्वपूर्ण कारक नहीं है।

- कई लोग इस मुद्दे पर असहमत हैं। क्या आपको लगता है कि तकनीकी पृष्ठभूमि होने से आपको बेहतर उत्पाद प्रबंधक बनने में मदद मिलेगी?

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

- यदि आप किसी विषय को पूरी तरह से नहीं समझते हैं, तो आप अपनी टीम से सवाल पूछते हैं और उनके उत्तरों के आधार पर निर्णय लेते हैं?

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

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

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

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

- और अगर वे समस्या के कई समाधान प्रस्तावित करते हैं, तो सबसे अच्छा अनुमान कौन लगाता है? टीम का नेतृत्व?

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

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

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