ज़ीरो से लॉन्च तक: Pathao Points कैसे बना

यह लेख सबसे पहले 28 अक्टूबर 2019 को Future Startup पर प्रकाशित हुआ था

इस महीने हमने Pathao Points लॉन्च किया – एक अनोखा रिवॉर्ड्स प्रोग्राम, जिसमें हमारे ग्राहक जब भी राइड या फ़ूड डिलीवरी के लिए Pathao इस्तेमाल करते हैं, उन्हें पॉइंट्स मिलते हैं। साथ ही, ये पॉइंट्स हमारे मेंबर्स के लिए ख़ास और दिलचस्प फ़ायदे अनलॉक करते हैं।

इस लॉन्च के बाद से हमसे पूछा गया है

ऐसा प्रोडक्ट (Pathao Points) लॉन्च करने के पीछे आपकी सोच क्या है? यह कैसे काम करता है? इसके लिए क्या रिसर्च की गई? इसमें कितना समय लगा? क्या हमने इसे लंबे समय को ध्यान में रखकर डिज़ाइन किया? हम किन मेट्रिक्स को देखते हैं?

ये सवाल सिर्फ़ Pathao Points के लिए ही नहीं, बल्कि प्रोडक्ट डेवलपमेंट के किसी भी संदर्भ में प्रासंगिक हैं – चाहे वो Pathao Points हो, Rides हो, Food हो – या फिर कोई भी दूसरा टेक प्रोडक्ट।

इस 3-भाग वाली सीरीज़ में, मैं Pathao Points को उदाहरण बनाकर इन सवालों के जवाब देना चाहता हूँ, लेकिन मुझे उम्मीद है कि ये बारीकियाँ बांग्लादेश और उसके बाहर टेक प्रोडक्ट्स बनाने वाले हर व्यक्ति के काम आएँगी।

शुरुआत 'क्यों' से करते हैं

आख़िर Pathao Points बनाया ही क्यों?

एक देसी स्टार्टअप होने के नाते, हमारी कम्युनिटी हमारे सफ़र का बड़ा हिस्सा रही है।

हम हमेशा से चाहते थे कि हमें चुनने के लिए इस कम्युनिटी को पहचान और इनाम दें। इस प्रोग्राम के साथ, हम उस दिशा में एक बड़ा कदम उठाने को लेकर उत्साहित हैं।

कस्टमर रिटेंशन हमारे लिए एक बड़ा फ़ोकस एरिया है। हम लगातार अपने यूज़र्स का पसंदीदा प्लेटफ़ॉर्म बने रहना चाहते हैं और इसके लिए मेहनत करने को तैयार हैं।

किसी मौजूदा यूज़र को बनाए रखने के मुक़ाबले नया यूज़र जोड़ना कहीं ज़्यादा महँगा पड़ता है।

इसलिए समझदारी यही है कि हम अपनी मेहनत उन ग्राहकों के लिए लगाएँ जो हमारे साथ हैं। Pathao Points ठीक यही है – हमारे यूज़र्स को पहचान और इनाम देने वाला एक प्रोग्राम।

ठीक है। यह काम कैसे करता है?

हमारे यूज़र्स जो पॉइंट्स कमाते हैं, उनसे उन्हें कई तरह के रिवॉर्ड्स और डिस्काउंट्स मिलते हैं, जिन्हें इस तरह डिज़ाइन किया गया है कि वे सच में उनके काम के हों।

चार मेंबरशिप लेवल हैं: ब्रॉन्ज़, सिल्वर, गोल्ड, प्लैटिनम, और यूज़र्स बिना किसी शुल्क के अपने-आप इसमें शामिल हो जाते हैं।

प्रोग्राम में आने के बाद, यूज़र्स को Pathao प्लेटफ़ॉर्म पर ख़र्च किए गए हर टका पर एक पॉइंट मिलने लगेगा। 200 पॉइंट्स कमाते ही यूज़र ब्रॉन्ज़ से सिल्वर में पहुँच जाएगा। 1,000 पॉइंट्स पर यूज़र्स गोल्ड टियर में प्रमोट हो जाएँगे। और 7,000 पॉइंट्स पर वे सबसे ऊँचे टियर, प्लैटिनम में पहुँच जाएँगे।

चूँकि यह प्रोजेक्ट रिवॉर्ड्स और ग्राहकों के साथ रिश्तों से जुड़ा था, हमें लगा कि भरोसा और विश्वसनीयता बहुत अहम हैं। इस प्रोजेक्ट का इंटरनल नाम 'Sancus' था – जो भरोसे और शपथ के ग्रीक देवता के नाम पर रखा गया था।

तेज़ी से बनाने का 'सीक्रेट सॉस' क्या था?

आगे बढ़ने से पहले, मुझे ज़ोर देकर कहना होगा कि हमारा लक्ष्य ऐसी चीज़ें बनाना है जो काम करें, न कि बस तेज़ी से शिप करना...हालाँकि यह भी हम अच्छी तरह करते हैं। तरीक़ा कुछ यूँ है:

1. वेब-व्यू पर दाँव

चित्र: MVP लॉन्च से पहले हमने जो एक्सप्लोरेशन और सुधार किए।

चित्र: MVP लॉन्च से पहले हमने जो एक्सप्लोरेशन और सुधार किए।

रिलीज़ के बाद, हमें उम्मीद थी कि इस प्रोडक्ट का पहला वर्ज़न मार्केट से मिले फ़ीडबैक के आधार पर कई इटरेशन से गुज़रेगा।

तेज़ी से बदलाव करने और आसानी से अपडेट पुश करने के लिए – नेटिव Android/iOS के बजाय वेब पर फ़्रंटएंड बनाना समझदारी थी।

एक ओर, Android/iOS प्लेटफ़ॉर्म पर फ़्रंटएंड बदलावों के लिए पूरा अपडेट चाहिए होता है, और यह इस पर निर्भर करता है कि यूज़र वह अपडेट स्वीकार करे।

दूसरी ओर, वेब-व्यू वाले तरीक़े में हर बार अपडेटेड UI लोड होता है।

लेकिन वेब-व्यू पर आधारित तरीक़े को लेकर कुछ चिंताएँ थीं।

हमने इससे पहले ऐप एक्सपीरियंस के किसी बड़े हिस्से के लिए वेब-व्यू का इस्तेमाल नहीं किया था। ज़ाहिर है, यह अनजाना इलाक़ा था।

क्या एक्सपीरियंस में कोई समझौता करना पड़ेगा? क्या लैग होगा? क्या यह बाक़ी ऐप की तुलना में बेमेल दिख सकता है? क्या फ़्रंटएंड लोड संभाल पाएगा?

हमने प्रयोग करने का फ़ैसला किया और एक POC (प्रूफ़-ऑफ़-कॉन्सेप्ट) बनाया। हमारी वेब फ़्रंटएंड टीम ने कुछ HTML/CSS पेज बनाए। हमने उन्हें ऐप से जोड़ा और फिर परफ़ॉर्मेंस टेस्ट की। नतीजा हमारी उम्मीद से कहीं बेहतर रहा।

यह परफ़ेक्ट नहीं था, लेकिन इसे निखारकर और बार-बार सुधारकर कुछ शानदार बनाया जा सकता था। यूज़ेबिलिटी की कुछ दिक़्क़तें थीं, डिज़ाइन से जुड़ी कुछ बातें थीं। कहें तो, एक अनगढ़ हीरा।

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

2. Lego, हमारी UI लाइब्रेरी

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

यह लाइब्रेरी हमारा सोर्स ऑफ़ ट्रुथ है। नए प्रोजेक्ट्स शुरू करने के लिए यह बॉयलरप्लेट का काम करती है। इससे भी अहम बात, Lego हमारे ऐप, वेबसाइट और दूसरे टचपॉइंट्स में एकरूपता पक्की करती है।

संक्षेप में, Lego किसी भी UI पर काम करते समय वक़्त बचाती है और हमें बिजली की रफ़्तार से नए यूज़र एक्सपीरियंस बनाने में मदद करती है।

3. माइक्रोसर्विस-आधारित आर्किटेक्चर

पहले हमारी Payments सर्विस जैसे मज़बूत सिस्टम बनाने से मिले पैटर्न और सबक़ों का इस्तेमाल करते हुए, हमारी इंजीनियरिंग टीम ने माइक्रोसर्विस-आधारित आर्किटेक्चर चुनने का फ़ैसला किया। मोटे तौर पर, इसमें चार मुख्य सर्विसेज़ होनी थीं।

1. POCKETS – पॉइंट्स से जुड़ा सब कुछ संभालेगी।

2. SQUARE – डील्स से जुड़े सारे काम इसकी ज़िम्मेदारी।

3. NIGHTWING– डील्स मैनेज करने का एडमिन टूल।

4. QUICKSILVER- वेब-व्यू रेंडर करने की ज़िम्मेदारी।

इन सबको सपोर्ट करने के लिए कुछ और माइक्रोसर्विसेज़ की ज़रूरत होती, लेकिन कुल मिलाकर यही चार वो खंभे थे जिन पर हम यह सिस्टम खड़ा करने वाले थे।

4. प्रयोग करने और असर मापने के लिए डिज़ाइन

परंपरागत रूप से, प्रोडक्ट रिलीज़ का असर मापने के बारे में बाद में ही सोचा जाता रहा है। इससे किसी का भला नहीं होता। अब हम कोड की एक लाइन लिखने से पहले ही इसकी योजना बना लेते हैं।

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

बेशक, यूज़र्स के इंटरव्यू जैसे क्वालिटेटिव तरीक़े इस्तेमाल किए जा सकते हैं – लेकिन उनकी अपनी दिक़्क़तें हैं। Pathao जिस पैमाने पर काम करता है, वहाँ FGD और इंटरव्यू शायद ही कभी सबका सही प्रतिनिधित्व करते हैं। ख़ासकर ऐसे प्रोडक्ट के लिए जो पूरे प्लेटफ़ॉर्म पर चलता है। इसलिए क्वांटिटेटिव तरीक़े, यानी A/B टेस्टिंग, ही हमारा रास्ता है।

बेशक, कहना आसान है, करना मुश्किल।

एक सही प्रयोग और A/B टेस्ट चलाने के लिए डेवलपमेंट, सेटअप और जानकारी चाहिए। बिना अनुभव के ऐसी विशेषज्ञता मिलना मुश्किल है।

Sancus (इंटरनल नाम) को लेकर हमारे ज़्यादातर सवालों में – यानी वो चीज़ें जिन्हें हम टेस्ट करना और इटरेट करना चाहते हैं – A/B टेस्टिंग का मैकेनिज़्म पहले से बना हुआ है।

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

फिर हम दोनों ग्रुप्स के डेटा पर नज़र रखते हैं, इनसाइट्स निकालने के लिए डेटा का विश्लेषण करते हैं, और ज़रूरी कदम उठाते हैं।

जैसा कि पीटर ड्रकर ने ठीक ही कहा था,

"जो मापा जाता है, वही मैनेज होता है"

5. प्रोजेक्ट मैनेजमेंट, रास्ते की रुकावट बने बिना

हमने पाया है कि आमने-सामने की बातचीत बेहद ज़रूरी है। लेकिन हम बनाने वालों को मीटिंग्स के बोझ तले दबाना नहीं चाहते। दूसरी ओर, ईमेल और टेक्स्ट मैसेज कभी-कभी तालमेल बिठाने का धीमा ज़रिया साबित होते हैं। हमें संतुलन बनाना था।

1. हमारा Capstone प्रोजेक्ट मैनेजमेंट ट्रैकर – प्रोडक्ट और इंजीनियरिंग लीड्स इसे मेंटेन करते हैं, और इससे हमारी प्रगति और प्राथमिकताओं की पूरी तस्वीर एक नज़र में मिल जाती है।

2. स्टैंडअप और आमने-सामने की मीटिंग्स – हम 6/7 कोर टीम मेंबर्स के साथ हफ़्ते में लगभग दो बार स्टैंडअप करते थे। आमतौर पर सोमवार और गुरुवार को। इस लय से हम अटकी हुई चीज़ें सुलझा पाते थे और प्रगति पर नज़र रख पाते थे – और साथ ही ऐसी मीटिंग्स में कम से कम समय लगता था।

3. हमने पाया है कि आमने-सामने की बातचीत बेहद ज़रूरी है। लेकिन फिर, हम बनाने वालों को मीटिंग्स के बोझ तले दबाना नहीं चाहते। दूसरी ओर, ईमेल और टेक्स्ट मैसेज कभी-कभी तालमेल बिठाने का धीमा ज़रिया साबित होते हैं। हमें संतुलन बनाना था।

4. रेट्रोस्पेक्टिव के दौरान, हम जानबूझकर कमियों पर ज़्यादा समय लगाते हैं। चर्चा के लिए कुछ भी, बिल्कुल कुछ भी वर्जित नहीं है, लेकिन हर एक चीज़ का नतीजा किसी कदम के रूप में निकलना चाहिए।

5. जो बातें मायने रखती हैं, उन्हें दर्ज कीजिए:

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

यह रही उस टीम की तस्वीर, जो यह सब मुमकिन बनाती है…

कहने की ज़रूरत नहीं कि कुछ लोग ऐसे भी हैं जिन्होंने योगदान दिया लेकिन तस्वीर में नहीं हैं, और हम उनके आभारी हैं। उनमें से, मैं इस प्रोडक्ट के शुरुआती दौर में योगदान के लिए जीतू भाई का ज़िक्र करना चाहूँगा।

कहने की ज़रूरत नहीं कि कुछ लोग ऐसे भी हैं जिन्होंने योगदान दिया लेकिन तस्वीर में नहीं हैं, और हम उनके आभारी हैं। उनमें से, मैं इस प्रोडक्ट के शुरुआती दौर में योगदान के लिए जीतू भाई का ज़िक्र करना चाहूँगा।