बार-राइज़िंग प्रोडक्ट मैनेजमेंट: आरोन बोनको के साथ प्रोडक्ट लाइफ़ साइकल को नेविगेट करना

आरोन बोनको

हमारी बार-राइजिंग प्रोडक्ट मैनेजमेंट सीरीज़ में आपका स्वागत है. लेखों के इस कलेक्श में, हम इनसाइट, बेहतरीन तरीक़े और असल दुनिया के अनुभवों को शेयर करने के लिए टेक्निकल प्रोडक्ट मैनजमेंट की पेचीदगियों के बारे में गहराई से जानते हैं, जो टेक्निकल प्रोडक्ट मैनेजर (जिन्हें ‘प्रोडक्ट मैनेजमेंट-टेक’ या Amazon पर PMT कहा जाता है) को अपने स्किल को निखारने में मदद करते हैं. साथ ही, यह समझने में मदद करते हैं कि हम Amazon Ads पर किस तरह काम करते हैं और उस काम के बारे में ज़्यादा जान पाते हैं जो हमें उत्साहित करता है.

इस पहली कड़ी के लिए, हम मेजरमेंट और डेटा साइंस टीम के सीनियर प्रिंसिपल टेक्निकल प्रोग्राम मैनेजर (TPM) आरोन बोनको से सुनते हैं. Amazon में लगभग नौ सालों के अनुभव के साथ, आरोन की भूमिका उन्हें टेक्नोलॉजी और बिज़नेस रणनीति के संयोजन पर रखती है. यहाँ वह चर्चा करते हैं कि हम आम तौर पर Amazon पर प्रोडक्ट लाइफ़ साइकल को किस तरह मैनेज करते हैं.

Amazon Ads पर प्रोडक्ट लाइफ़ साइकल

Amazon Ads में हमारा प्रोडक्ट लाइफ़ साइकल अन्य टेक कंपनियों से बहुत अलग नहीं है. लेकिन, पिछले कुछ सालों में हमने Amazon की मालिक होने वाली और कस्टमर जुनून की संस्कृति के साथ तालमेल बिठाने के अपने तरीक़े को बेहतर किया है. हम आम तौर पर इसे पाँच स्टेज में बाँटते हैं:

  • विकास से पहले: यहीं से यह सब शुरू होता है. Amazon पर हम हमेशा “पीछे की ओर काम करने” के बारे में बात करते हैं. साथ ही, हम अपने कस्टमर और उनकी ज़रूरतों को गहराई से समझते हुए शुरुआत करते हैं. Amazonian की प्रक्रिया हमारे व्यापक पोर्टफ़ोलियो के भीतर प्रोडक्ट को सम्बंधित बनाने और डेटा से चलने वालेPR/FAQ (प्रेस रिलीज़/अक्सर पूछे जाने वाले सवाल) विकसित करना है, जो लॉन्च की तारीख़ पर प्रोडक्ट की कल्पना करता है. साथ ही, इससे कस्टमर को मिलने वाले फ़ायदों के बारे में सोचा जाता है. यह विज़न स्टेटमेंट प्रोडक्ट पर किए जाने वाले सभी कामों का आधार है; हम तब तक बनाना शुरू नहीं करते जब तक कि हर कोई PR/FAQ से ख़ुश ना हो जाए.
  • विकसित और टेस्ट करना: यहाँ हम आइडिया को जीवन में लाना शुरू करते हैं - डिज़ाइन तैयार करना, प्रोटोटाइप बनाना और गहराई से टेस्टिंग करना. पारंपरिक झरने वाले तरीक़े के विपरीत, हम सभी, व्यापक ज़रूरतों के लिए डॉक्यूमेंट का इंतज़ार नहीं करते हैं. इसके बजाय, हम हाई-लेवल ओवरव्यू के साथ शुरुआत करते हैं और अपनी टेक्निकल टीमों को इसमें जल्दी एंगेज करते हैं. इससे हम शुरुआत से ही जटिलता और संभावित रूप से इसे आसान बनाने पर बहुमूल्य फ़ीडबैक हासिल कर सकते हैं.

    Amazon पर, हम हमेशा न्यूनतम पसंदीदा प्रोडक्ट बनाम न्यूनतम बेहतर प्रोडक्ट बनाने के लिए काम करते हैं. “कस्टमर जुनून” हमारा पहला लीडरशिप सिद्धांत है और यहाँ तक कि हमारे द्वारा जारी किए जाने वाले प्रोडक्ट के सबसे आसान वर्शन भी ख़ुश करने वाला होना चाहिए. टेस्टिंग हमारी विकसित की प्रक्रिया के आख़िर में नहीं, बल्कि पूरी प्रक्रिया में शामिल होत है. हम यूनिट, इंटीग्रेशन और यूज़र की स्वीकृति टेस्टिंग के कॉम्बिनेशन का इस्तेमाल करते हैं. ऐसा तरीक़ा जिसने हमारी अच्छी मदद की है, वह है जब भी संभव हो, हमारी टेस्टिंग के फ़ेज में असल कस्टमर को शामिल करना. हम अक्सर बीटा प्रोग्राम चलाते हैं जिसमें चुनिंदा कस्टमर नए फ़ीचर आज़मा सकते हैं और फ़ीडबैक दे सकते हैं. यह असल टेस्टिंग इस्तेमाल से जुड़ी समस्याओं की पहचान करने और पूरे लॉन्च से पहले हमारे प्रोडक्ट को बेहतर करने के लिए शानदार साबित होता है. हम इस फ़ेज के दौरान इस्तेमाल में नहीं आने वाली ज़रूरतों पर भी पूरा ध्यान देते हैं. परफ़ॉर्मेंस, स्केल करने की योग्यता और सुरक्षा बाद के विचार नहीं हैं, बल्कि हमारे विकास और टेस्टिंग प्रक्रिया में पूरी तरह शामिल हिस्से हैं. हम यह पक्का करने के लिए लोड टेस्टिंग करते हैं कि प्रोडक्ट ट्रैफ़िक और सुरक्षा ऑडिट के संभावित वोल्यूम को संभाल सकें, ताकि यह पक्का हो सके कि हमारे कस्टमर का डेटा सुरक्षित रहे जो हमारे लिए प्राथमिकता है.
  • लॉन्च: इस फ़ेज के दौरान एक्ज़ीक्यूशन अहम है. जब हम प्रोडक्ट या सेवाओं को बाज़ार में लॉन्च करने से जुड़ी रणनीति को लागू करते हैं, तो यह सोचना अहम है कि हमारे रिलीज़ के तरीक़े को क्या प्रभावित करने वाला है और यह हमारे टेक्निकल दायरे पर किस तरह असर डाल सकता है. लॉन्च फ़ेज के दौरान, हम मार्केटिंग और सेल्स टीमों के साथ मिलकर काम करते हैं और अक्सर रियल टाइम में लॉन्च मेट्रिक की सख़्ती से निगरानी करते हैं. इससे यह पक्का होता है कि हम अपने लक्ष्यों को पूरा कर रहे हैं और उस समस्या को तुरंत पहचान रहे हैं जिसे ठीक करना ज़रूरी है. एक बड़ा सबक जो मैंने पिछले कुछ सालों में सीखा है, वह है इस फ़ेज के दौरान फ़्लेक्सिबिलिट की अहमियत. इससे कोई फ़र्क़ नहीं पड़ता कि आप कितना अच्छा प्लान बनाते हैं, हैरानी तो हमेशा ही होगी. असल दुनिया के डेटा और फ़ीडबैक के आधार पर तेज़ी से बदलाव लाने की क्षमता अहम है.
  • लॉन्च के बाद: लॉन्च के बाद काम बंद नहीं होता है. हम लंबी अवधि की सफलता मेट्रिक की निगरानी करना जारी रखते हैं और “दूसरे दिन” सिग्नल की तलाश करते हैं, जो यह बता सकते हैं कि वास्तव में हम अपने प्रोडक्ट के लिए ज़रूरी चीज़ों को याद नहीं रख पा रहे हैं. इन सिग्नल में यह शामिल हो सकता है कि टीमें कस्टमर या बिज़नेस के लिए वास्तव में अहम चीज़ों की क़ीमत पर ख़ास मेट्रिक या लक्ष्यों को पूरा करने पर बहुत ज़्यादा फ़ोकस कर रही हैं. एक और उदाहरण यह है जब कोई टीम प्रक्रियाएँ और मैकेनिज्म बनाने पर बहुत ज़्यादा जोर देती है, तो इससे क्रिएटिविटी और कुशलता प्रभावित होती है. हालाँकि, मैकेनिज्म अहम हैं और Amazon पर हमारे काम करने के तरीक़े का ज़रूरी हिस्सा हैं, लेकिन उन्हें प्रगति में बाधा डालने के बजाए कुशल होना चाहिए.
  • इटरेशन और विकास: इस आख़िरी स्टेज में, हम अपनी असल परिकल्पना को वेलिडेट करने के लिए लॉन्च के बाद के डेटा का इस्तेमाल करते हैं या यह आकलन करने के लिए कि क्या हमें अपने विज़न को बदलने और एडजस्ट करने की ज़रूरत है. जैसे, हो सकता है कि हमारे प्रोडक्ट के लिए कस्टमर की माँग वह नहीं है जो हमने सोची थी या वे इसके वैल्यू प्रपोज़िशन को नहीं समझते हैं. हम इन सीखों को प्रोडक्ट के आगे आने वाले वर्शन के साथ-साथ उन अन्य प्रोडक्ट में शामिल करते हैं जिन्हें हम अपने पोर्टफ़ोलियो में बना रहे हैं. हम कस्टमर से जुड़ते हैं और प्रोडक्ट पर फ़ीडबैक पाने के लिए इस्तेमाल से जुड़े डेटा का विश्लेषण करते हैं. साथ ही, यह पक्का करते हैं कि हम आगे आने वाले दिनों में सुधार का प्लान बनाते समय उनकी चिंताओं और प्रोडक्ट की कमियों को दूर कर रहे हैं

प्रोडक्ट लाइफ़ साइकल के लिए सीख

जैसा कि हमने पिछले कुछ सालों में इन पाँच स्टेज के लिए अपने तरीक़े को बेहतर किया है, हमने व्यापक प्रोडक्ट लाइफ़ साइकल के बारे में कुछ काम की इनसाइट हासिल की है:

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

इन इनसाइट ने ना सिर्फ़ यह तय किया है कि Amazon प्रोडक्ट लाइफ़ साइकल के हर स्टेज में किस तरह काम करता है, बल्कि पूरी प्रक्रिया के दौरान क्रॉस-फ़ंक्शनल सहयोग की अहमियत को भी मज़बूत किया है. सहयोग की यह भावना सिर्फ़ अच्छी सोच नहीं है; यह इस बात का आधार है कि हम किस तरह काम करते हैं और इनोवेट करते हैं. Amazon Ads में, हम औपचारिक RACI (ज़िम्मेदार, जवाबदेह, विचार-विमर्श किया गया और बेहतर किया गया) मॉडल का पालन नहीं करते हैं. इसके बजाय हमारे पास ऐसी गाइडलाइन हैं जो मालिक होने और जवाबदेही को प्रमोट करती हैं:

  • प्रोडक्ट मैनेजर "क्या" के मालिक हैं.
  • इंजीनियर "किस तरह" के मालिक हैं.
  • TPM "कब" के मालिक हैं.

हालाँकि, इन नियमों को लागू करना ज़रूरी नहीं है. हमारी संस्कृति सभी को अपनी प्राथमिक ज़िम्मेदारियों से परे सहयोग करने, इनोवेशन को बढ़ावा देने और तेज़ी से समस्या ठीक करने के लिए प्रोत्साहित करती है.

बदलाव जारी है

Amazon Ads पर प्रोडक्ट बनाना लगातार चलने वाली प्रक्रिया है, क्योंकि हम अपने कस्टमर और उनकी उम्मीदों से सीखते रहते हैं. हम ख़ुद को लगातार इनोवेट करने के लिए प्रेरित कर रहे हैं और इस प्रक्रिया का अनुभव हमें आनंद देता है.

अगले बार-राइज़िंग प्रोडक्ट मैनेजमेंट लेख में, हम अपने PMT डायरेक्टर में से एक से बिना अधिकार के प्रभावित करने के बारे में सुनेंगे.