प्रतिनिधि इंटरव्यू विषय

Product Manager इंटरव्यू: सफलता के मेट्रिक्स चुनने के लिए HEART और GSM का उपयोग कैसे करेंगे?

प्रोडक्टमध्यम
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

एक टीम एंटरप्राइज सर्च रिज़ल्ट पेज को फिर से डिज़ाइन कर रही है। आप HEART और GSM का उपयोग करके सफलता को कैसे परिभाषित करेंगे, और क्लिक्स को केवल यूज़र वैल्यू मानने से कैसे बचेंगे?

प्रॉम्प्ट और संदर्भ

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

यह एक प्रोडक्ट मेज़रमेंट डिज़ाइन का प्रश्न है। HEART पांच यूज़र-एक्सपीरियंस डाइमेंशन्स को दर्शाता है: Happiness, Engagement, Adoption, Retention, और Task Success। GSM का अर्थ है Goals, Signals, और Metrics। इन्हें एक निर्णय श्रृंखला (decision chain) बनानी चाहिए, न कि ऐसी चेकलिस्ट जो स्कोरकार्ड में हर डाइमेंशन को जबरन शामिल करे।

इंटरव्यूअर क्या मूल्यांकन कर रहा है

  • क्या आप संख्याएं तय करने से पहले यूज़र के काम (user job) को परिभाषित करते हैं।
  • क्या आप प्रोडक्ट लक्ष्य, देखने योग्य सिग्नल्स (observable signals) और ऑपरेशनल मेट्रिक्स को अलग-अलग रखते हैं।
  • क्या आप बदलाव के लिए केवल प्रासंगिक HEART डाइमेंशन्स चुनते हैं और जिन्हें छोड़ा गया है उनका कारण बताते हैं।
  • क्या आप न्यूमरेटर (अंश), डिनॉमिनेटर (हर), समय अवधि (window), कोहॉर्ट्स और गार्डरेल्स निर्दिष्ट करते हैं।
  • क्या आप किसी प्रयोग (experiment), चरणबद्ध रोलआउट (staged rollout) और डेटा की कमियों को ठीक करने के बीच सही चुनाव कर सकते हैं।

पहले स्पष्ट करने योग्य प्रश्न

  • क्या प्राथमिक यूज़र्स कर्मचारी हैं, ग्राहक हैं या आम जनता? इस केस के लिए कर्मचारी मान कर चलें।
  • क्या लक्ष्य तेज़ खोज (faster discovery), बेहतर उत्तर गुणवत्ता, या व्यापक सर्च कवरेज है? पहले टास्क की सफलता और खोजने में लगने वाले समय (time to find) पर ध्यान केंद्रित करें।
  • क्या स्थिर सर्च सेशन्स, रिज़ल्ट-ओपन इवेंट्स और डॉक्यूमेंट इवेंट्स मौजूद हैं? यदि नहीं, तो मेज़रमेंट के जोखिम का उल्लेख करें।
  • क्या अनुमतियां (permissions), संवेदनशील दस्तावेज़ या इंडेक्स का विलंब (index lag) शामिल हैं? ये कोहॉर्ट्स और गार्डरेल्स को प्रभावित करते हैं।
  • क्या ट्रैफ़िक को रैंडमाइज़ किया जा सकता है, या रोलआउट टीम के अनुसार होना चाहिए? सहयोगात्मक (collaborative) प्रोडक्ट्स में कंटैमिनेशन (डेटा प्रदूषण) की जांच आवश्यक होती है।

30-सेकंड का उत्तर ढांचा (Framework)

"मैं इस परिणाम को ऐसे परिभाषित करूंगा कि कर्मचारी कम भटकाव के साथ एक अधिकृत और उपयोगी दस्तावेज़ खोज सकें। मैं उस परिणाम को टास्क-सक्सेस सिग्नल्स में बदलने के लिए GSM का उपयोग करूंगा, फिर HEART का उपयोग करूंगा जिसमें Task Success प्राथमिक डाइमेंशन होगा और Happiness तथा Retention सहायक जांच के रूप में होंगे। प्राथमिक मेट्रिक की एक स्पष्ट इकाई (unit) और समय अवधि होगी; क्लिक्स केवल डायग्नोस्टिक रहेंगे। लॉन्च से पहले मैं गार्डरेल्स, इंस्ट्रूमेंटेशन जांच और चरणबद्ध रोलआउट के नियम तय करूंगा।"

गहन विस्तृत उत्तर

पहले यूज़र के काम और परिणाम को परिभाषित करें

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

लक्ष्य को GSM श्रृंखला में बदलें

पहले Goal (लक्ष्य) लिखें: कर्मचारी अधिकृत, उपयोगी दस्तावेज़ तेज़ी से खोजें। फिर Signals (सिग्नल्स) की सूची बनाएं: रिज़ल्ट खोलना, सामग्री कॉपी करना, सर्च पर वापस लौटना, 'मदद नहीं मिली' रिपोर्ट करना, या उसके तुरंत बाद संबंधित कार्य पूरा करना। अंत में स्पष्ट डिनॉमिनेटर और समय अवधि के साथ Metrics चुनें। एक Goal किसी मेट्रिक का नाम नहीं होता, और एक Signal अपने आप में अंतिम सफलता नहीं होता।

HEART डाइमेंशन्स का एक छोटा सेट चुनें

Task Success को प्राथमिकता दें क्योंकि रीडिज़ाइन सीधे तौर पर खोजने के कार्य को बदलता है। महसूस की गई गुणवत्ता (perceived quality) की जांच के लिए एक छोटे सर्वे या फ़ीडबैक के माध्यम से Happiness का उपयोग करें, और यह देखने के लिए Retention का उपयोग करें कि क्या टीमें चार हफ्तों तक सर्च का उपयोग जारी रखती हैं। Adoption और Engagement खोज और उपयोग का विश्लेषण (diagnose) कर सकते हैं, लेकिन उन्हें डिफ़ॉल्ट रूप से सफलता का मानदंड नहीं बनाया जाना चाहिए। कम डाइमेंशन्स चुनने से ट्रेड-ऑफ़ स्पष्ट हो जाते हैं।

एक ऑडिट करने योग्य प्राथमिक मेट्रिक लिखें

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

डायग्नोस्टिक्स और गार्डरेल्स को अलग-अलग कार्य सौंपें

डायग्नोस्टिक्स में पहले रिज़ल्ट का क्लिक-थ्रू, फ़िल्टर का उपयोग, रीफ़ॉर्मूलेशन दर, शून्य-रिज़ल्ट दर और खोजने में लगने वाला p50/p90 समय शामिल हो सकता है। गार्डरेल्स में अनुमति त्रुटियां (permission errors), संवेदनशील दस्तावेज़ों का दिखना, इंडेक्स लेटेंसी, यूज़र रिपोर्ट्स और सपोर्ट अनुरोध शामिल हैं। यदि क्लिक्स बढ़ते हैं लेकिन साथ ही रीफ़ॉर्मूलेशन, रिपोर्ट्स या अनुमति त्रुटियां भी बढ़ती हैं, तो प्राथमिक मेट्रिक पूर्ण रोलआउट को सही नहीं ठहराता है।

हैप्पीनेस और रिटेंशन में पूर्वाग्रह (Bias) को संभालें

Happiness फ़ीडबैक रिस्पॉन्स के स्व-चयन (self-selection), प्रॉम्प्ट की टाइमिंग और भाषा से प्रभावित होता है। एक छोटे उच्च-स्कोर वाले सैंपल को पूरी आबादी मानने के बजाय रिस्पॉन्स रेट, सर्वे वर्ज़न और कोहॉर्ट्स की रिपोर्ट करें। रिटेंशन की समय अवधि को सर्च फ़्रीक्वेंसी से मिलाएं: दैनिक प्रोडक्ट्स 7 या 28 दिनों का उपयोग कर सकते हैं, जबकि कभी-कभार उपयोग होने वाले वर्कफ़्लो को लंबे अवलोकन की आवश्यकता होती है। अल्पकालिक टास्क सफलता को बार-बार होने वाले उपयोग से अलग रिपोर्ट करें।

वैलिडेशन और निर्णय नियमों को डिज़ाइन करें

यदि यूज़र्स लिंक साझा करते हैं या क्वेरीज़ पर सहयोग करते हैं, तो वर्ज़न के बीच हस्तक्षेप (cross-version interference) को कम करने के लिए टीम या वर्कस्पेस के आधार पर रैंडमाइज़ करें; अन्यथा यूज़र-स्तरीय रैंडमाइज़ेशन पर्याप्त हो सकता है। लॉन्च से पहले, प्राथमिक मेट्रिक, गार्डरेल सीमाएं, न्यूनतम व्यावहारिक लिफ्ट (minimum practical lift) और अवलोकन अवधि को पूर्व-पंजीकृत (pre-register) करें। सबसे पहले सैंपल अनुपात, इवेंट लॉस और अनुमति वैलिडेशन की जांच करें। रोलआउट तभी बढ़ाएं जब प्राथमिक थ्रेशोल्ड, गार्डरेल्स और डेटा-गुणवत्ता जांच सभी पास हो जाएं; जब कोई महत्वपूर्ण गार्डरेल पार हो जाए तो रोक दें।

मॉडल उच्च-गुणवत्ता वाला उत्तर

"मैं सफलता को इस रूप में परिभाषित करूंगा कि कर्मचारी खोजने का कार्य तेज़ी से पूरा कर रहे हैं, न कि इस रूप में कि वे अधिक रिज़ल्ट्स पर क्लिक कर रहे हैं। Goal एंटरप्राइज नॉलेज बेस में एक अधिकृत, उपयोगी उत्तर पाना है। Signals में रिज़ल्ट खोलना, सर्च पर तेज़ी से लौटना, 'मदद नहीं मिली' रिपोर्ट करना और संबंधित कार्य पूरा करना शामिल है। HEART में, Task Success प्राथमिक है, Happiness महसूस की गई गुणवत्ता की जांच करता है, और Retention चार-सप्ताह के पुन: उपयोग को देखता है; Adoption और Engagement केवल डायग्नोस्टिक्स हैं।

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

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

आम गलतियां

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

फ़ॉलो-अप प्रश्न और उत्तर

फ़ॉलो-अप 1: Adoption को प्राथमिक क्यों नहीं बनाया गया?

Adoption यह दर्शाता है कि यूज़र्स ने नए डिज़ाइन का उपयोग करना शुरू कर दिया है, यह नहीं कि सर्च टास्क सफल रहे। यह खोज (discovery) और माइग्रेशन डायग्नोस्टिक्स के लिए उपयोगी है; प्राथमिक डाइमेंशन एक उपयोगी उत्तर खोजने के करीब होना चाहिए।

फ़ॉलो-अप 2: क्या 30-सेकंड का ड्वेल नियम मनमाना है?

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

फ़ॉलो-अप 3: क्या होगा यदि कोई हैप्पीनेस सर्वे न हो?

कहें कि Happiness को अभी सीधे नहीं मापा जा सकता है। कम-रुकावट वाले फ़ीडबैक (low-friction feedback), मदद न मिलने के कारणों, रिपोर्ट्स और सपोर्ट टेक्स्ट को प्रॉक्सी के रूप में उपयोग करें, और उनके पूर्वाग्रह को रिकॉर्ड करें। व्यवहार संबंधी प्रॉक्सीज़ को व्यक्तिपरक संतुष्टि (subjective satisfaction) का नाम न दें।

फ़ॉलो-अप 4: कम बार होने वाली सर्च के लिए रिटेंशन को कब तक मापा जाना चाहिए?

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

फ़ॉलो-अप 5: क्लिक्स और टास्क की सफलता बढ़ती है, लेकिन खोजने का समय लंबा हो जाता है। अब क्या करें?

परिणाम को रैंक स्थिति, फ़िल्टर, दस्तावेज़ प्रकार और यूज़र अनुभव के आधार पर विभाजित (break down) करें। यदि टास्क की सफलता में सुधार होता है लेकिन समय की गार्डरेल पार हो जाती है, तो विस्तार करने से पहले रैंकिंग या इंटरैक्शन को ऑप्टिमाइज़ करें; केवल अनुकूल मेट्रिक का चयन न करें।

फ़ॉलो-अप 6: जब इंस्ट्रूमेंटेशन गायब हो तो आप कैसे उत्तर देंगे?

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

सार्वजनिक स्रोत

संबंधित प्रश्न