ऐप की वास्तविक जरूरतों के लिए ग्राहक ईमेल

क्यों ग्राहक संदेश सबसे अच्छा स्थान हैं

गलत ऐप बनाने का सबसे तेज़ तरीका अनुमान से शुरू करना है। टीमें यह अक्सर करती हैं। वे मान लेते हैं कि उपयोगकर्ता क्या चाहते हैं, ऐसे फीचर चुनते हैं जो स्मार्ट लगते हैं, और हफ्तों तक कुछ बनाते हैं जिसकी वास्तव में ज़रूरत नहीं थी।

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

मूल्य भाषा में है। ग्राहक शायद ही कभी समस्या को प्रोडक्ट जार्गन में बताते हैं। वे कहते हैं, "मैं लगातार ऑर्डर खो देता/देती हूँ क्योंकि मुझे वही विवरण तीन जगह दर्ज करने पड़ते हैं।" वह एक वाक्य आपको काम, दर्द और समस्या की लागत बता देता है।

कुछ संकेत सामान्यतः सबसे ज़्यादा मायने रखते हैं:

• वही समस्या अलग शब्दों में बार-बार दिखना
• लोग पहले से इस्तेमाल किए जाने वाले वर्कअराउंड का वर्णन करें
• समस्या समय, पैसे, या रोज़मर्रा के ध्यान की लागत हो
• संदेश में इतना संदर्भ हो कि पता चले क्या गलत हुआ

एक ईमेल दिलचस्प हो सकता है। दस समान ईमेल सबूत होते हैं। बार-बार आने वाले अनुरोध आपको उस सबसे ज़ोरदार ग्राहक के इर्द-गिर्द नहीं बनाते जो असल में सबसे आम ज़रूरत है।

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

यही ग्राहक संदेश अच्छे ढंग से करते हैं। वे एक अस्पष्ट विचार को उस समस्या में बदल देते हैं जिस पर आप वास्तव में काम कर सकते हैं।

योजना से पहले क्या इकट्ठा करें

स्क्रीन स्केच करने या फीचर लिस्ट लिखने से पहले उन संदेशों को इकट्ठा करें जो असली दर्द दिखाते हैं। आपको सब कुछ चाहिए नहीं। आपको बस वे कुछ तरह के नोट्स चाहिए जो बताते हैं कि लोग क्या करने की कोशिश कर रहे हैं, वे कहाँ फंसते हैं, और समस्या उनकी क्या लागत उठाती है।

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

विशेष संदेश सामान्यतः अस्पष्ट शिकायतों से बेहतर होते हैं। "मैं एक्सपोर्ट के बाद इनवॉइस नहीं ढूंढ पा रहा/रही हूँ" उपयोगी है। "आपकी ऐप खराब है" उपयोगी नहीं है। जब संभव हो तो पूरा वाक्य रखें, क्योंकि सही वाक्य अक्सर असली काम को उजागर कर देता है।

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

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

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

यदि आप तेज़ी से बना रहे हैं, तो यह कदम बिखरी हुई प्रतिक्रिया को यादृच्छिक फीचर्स में बदलने से रोकता है। यहाँ तक कि Koder.ai जैसी तेज़ प्लेटफ़ॉर्म में भी बेहतर इनपुट पहले बिल्ड को काफी बेहतर बनाता है।

इनबॉक्स में पैटर्न कैसे पहचानें

ग्राहक संदेशों को एक ही लक्ष्य के साथ पढ़ें: दोहराव ढूँढना।

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

शुरू करें संदेशों को समस्या के हिसाब से ग्रुप करके, भले ही ग्राहक उसे अलग शब्दों में बताएं। एक व्यक्ति कह सकता है, "मैं अपने पुराने ऑर्डर नहीं ढूंढ पाता/पाती," और दूसरा कह सकता है, "मुझे पिछले महीने क्या खरीदा था दिखना चाहिए।" दोनों उसी मुद्दे की ओर इशारा करते हैं: ऑर्डर हिस्ट्री तक पहुंच मुश्किल है।

एक सरल टैग सेट मदद करता है:

• जानकारी नहीं मिलना
• बहुत सारे मैनुअल कदम
• एक्सेस या परमिशन गायब
• शेयर या एक्सपोर्ट करना कठिन
• मोबाइल उपयोग निराशाजनक

एक बार ऐसा करने पर, वन-ऑफ अनुरोध पहचानना आसान हो जाता है। अगर एक ग्राहक बहुत विशिष्ट रिपोर्ट फॉर्मेट चाहता है, तो उसे नोट करें। उसे उसी वज़न का अधिकार न दें जितना 12 उपयोगकर्ताओं द्वारा दो हफ्तों में बताई गई समस्या को।

संभव हो तो अपने नोट्स में ग्राहक के अपने शब्द रखें। असली भाषा बाद में फीचर के नाम रखने, स्क्रीन कॉपी लिखने, या टीम को समस्या समझाने में मदद करती है। यह आपको ईमानदार भी रखती है। "फ़ॉलो-अप रिमाइंडर चाहिए" स्पष्ट है, जबकि "वर्कफ़्लो ऑप्टिमाइज़ेशन" कम स्पष्ट है।

बारंबारता मायने रखती है, पर प्रासंगिकता भी मायने रखती है। सिर्फ यह मत गिनिए कि कितनी बार समस्या आई—यह भी देखें किसके पास यह समस्या है। रोज़ाना उपयोग करने वाले पाँच लोगों द्वारा बताई गई समस्या उस समय के दस ट्रायल उपयोगकर्ताओं द्वारा बताई गई समस्या से अधिक महत्वपूर्ण हो सकती है, जो कभी शुरू ही नहीं हुए।

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

पैटर्न को स्पष्ट आवश्यकताओं में बदलें

एक बार जब आपने संदेशों को समूहबद्ध कर लिया, तो हर क्लस्टर को एक साधारण वाक्य में बदलें जो समस्या को बताता हो, समाधान नहीं।

उदाहरण: "कस्टमर अपॉइंटमेंट मिस कर देते हैं क्योंकि उन्हें सही समय पर रिमाइंडर नहीं मिलता।"

अगर आप समस्या को एक वाक्य में स्पष्ट रूप से समझा नहीं पा रहे, तो यह जरूरत शायद अभी भी धुंधली है।

अगला कदम है उस काम का नाम करना जो यूज़र करना चाह रहा है। इसे व्यावहारिक रखें। ऊपर के उदाहरण में काम "नोटिफिकेशन मैनेज करना" नहीं है। असली काम है "क्लाइंट को उनकी बुकिंग याद दिलाना बिना स्टाफ के पीछे पड़े।"

यह फर्क मायने रखता है क्योंकि यह आपको पहले से ज्यादा फीचर्स बनाने से रोकता है। लक्ष्य यह पकड़ना है कि उपयोगकर्ता को क्या हासिल करना है, न कि हर वह समाधान जो वे सुझाते हैं।

अब पैटर्न को एक छोटे_REQUIREMENT (short requirement) के रूप में लिखें जिसे कोई गैर-टेक्निकल व्यक्ति समझ सके। रिमाइंडर उदाहरण के लिए, पहला वर्शन कुछ ऐसा हो सकता है:

• स्टाफ स्वचालित रिमाइंडर अपॉइंटमेंट से पहले भेज सके
• स्टाफ चुन सके कि रिमाइंडर कब भेजा जाए
• स्टाफ देख सके कि रिमाइंडर भेजा गया था या नहीं
• रिमाइंडर बुकिंग में पहले से सेव किए गए संपर्क विवरण का उपयोग करे

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

हर आवश्यकता लिखने के बाद उसे किसी असली संदेश से जोड़ें। पूछें कौन सा ईमेल, सपोर्ट थ्रेड, या intake नोट यह साबित करता है कि यह ज़रूरी है। अगर आप असली ग्राहक वाक्य नहीं बता पा रहे, तो उस आइटम को "शायद बाद में" सूची में डाल दें।

एक त्वरित टेस्ट मदद करता है:

• क्या कोई गैर-टेक्निकल साथी इसे समझ सकता है?
• क्या यह एक स्पष्ट परिणाम बताता है?
• क्या यह दोहराए गए ग्राहक भाषा पर आधारित है?
• क्या इसे हटा देने से वर्शन एक कम उपयोगी बन जाएगा?

अगर चारों सवालों के जवाब हाँ हैं, तो संभवतः आपके पास एक ठोस आवश्यकता है।

क्या वर्शन एक में क्या जाए, कैसे चुनें

एक बार जब आपके पास असली अनुरोधों का ढेर हो, अगला काम अधिकतर को न कहना है।

एक अच्छा पहला वर्शन पूरा प्रोडक्ट का छोटा रूप नहीं होता। यह वह सबसे छोटी चंगाई है जो स्पष्ट रूप से मुख्य दर्द को हल करती है जिसे लोग बार-बार बता रहे हैं।

एक सरल रैंकिंग तरीका यहाँ काम करता है। चार चीज़ें देखें:

• समस्या कितनी बार आती है
• उपयोगकर्ता के लिए यह कितनी तात्कालिक लगती है
• क्या यह उनके मुख्य काम को ब्लॉक करती है
• इसे बनाना कितनी मुश्किल है बनाम उससे मिलने वाला मूल्य

सर्वोत्तम वर्शन-वन आइटम आमतौर पर पहले तीन पर अच्छा स्कोर करते हैं और चौथे पर सहज रहते हैं।

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

एक फोकस्ड वर्शन-वन को एक वाक्य में समझाना भी आसान होना चाहिए। अगर आप इसे सरल रूप से नहीं बता पा रहे, तो यह शायद बहुत कुछ करने की कोशिश कर रहा है।

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

एक साधारण उदाहरण

मान लीजिए एक छोटी सेल्स टीम बार-बार एक ही तरह का सपोर्ट ईमेल भेजती है। संदेश यह नहीं है, "हमें बेहतर CRM चाहिए।" यह बहुत सरल है: "मैंने एक लीड को फॉलो-अप करना भूल गया, और अब डील ठंडी हो गई।"

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

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

Intake नोट्स भी इसे सपोर्ट करते हैं। उपयोगकर्ता पहले से ही नाम, छोटे नोट्स और अगले कदम गंदे जगहों पर रखते हैं। उन्हें जो नहीं मिल रहा, वह एक साधारण रिमाइंडर फ्लो है।

तो वर्शन-वन छोटा रहता है:

• एक संपर्क सूची
• नोट्स सेव करने की जगह
• अगले फॉलो-अप के लिए रिमाइंडर

यही कोर समस्या टेस्ट करने के लिए काफी है।

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

यह पहले रिलीज़ को उस दोहराए गए दर्द पर केंद्रित रखता है जो असल संदेशों में दिखा था।

ऐसी गलतियाँ जो पहले बिल्ड को धुंधला कर देती हैं

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

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

बेहतर प्रश्न यह है: यह माँग करने से पहले क्या मुश्किल था? अगर असली समस्या "मैं अहम ऑर्डर मिस कर देता/देती हूँ" है, तो अलर्ट मदद कर सकते हैं, पर डेली सारांश या स्पष्ट कतार भी मदद कर सकता है। दर्द के इर्द-गिर्द बनाएं, पहले फीचर आइडिया के चारों ओर नहीं।

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

पहले एक मुख्य उपयोगकर्ता चुनें। फिर उनके मुख्य रोके हुए काम को एक वाक्य में परिभाषित करें। केवल वही फीचर्स रखें जो उस काम को तेज़, साफ़ या कम गलतियों के साथ होने में मदद करें।

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

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

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

बनाने से पहले एक आखिरी जांच चलाएँ

बिल्ड शुरू करने से पहले रुकिए और अपने प्लान को उन सबूतों के खिलाफ टेस्ट करें जो आपके पास हैं।

दोहराव के सबूत ढूँढिए। एक मजबूत ईमेल रोचक है। तीन या अधिक संदेशों में एक ही निराशा पैटर्न है।

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

हर फीचर को एक दर्द बिंदु से मेल कराइए। अगर कोई फीचर सिर्फ़ प्रभावशाली लगने के कारण है, उसे काट दें।

उत्पाद को एक संक्षिप्त वाक्य में समझाने की कोशिश करें। अगर वाक्य बढ़ता जा रहा है, तो स्कोप संभवतः बहुत चौड़ा है।

फिर जो बाद में हो सकता है उसे हटा दें। वर्शन-वन आपका अंतिम उत्पाद नहीं है। वे पार्ट्स रखें जो अभी मुख्य दर्द को हल करते हैं और बाकी को बाद की सूची में रखें।

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

पैटर्न मिलने के बाद क्या करें

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

यह उतना ही सरल हो सकता है: "नए ग्राहक बार-बार पूछ रहे हैं कि इनवॉइस कहाँ रखे जाते हैं, और सपोर्ट वही सवाल बार-बार जवाब देने में बहुत समय लगा रहा है।"

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

बिल्ड करने से पहले उस ड्राफ्ट को कुछ वास्तविक उपयोगकर्ताओं के सामने रखें। आपको पूरा डेमो चाहिए नहीं। एक मोटा मॉकअप, छोटा वॉकथ्रू, या यहां तक कि एक छोटा संदेश भी अक्सर पर्याप्त होता है—"क्या यह उस समस्या को हल करेगा जिसके बारे में आपने हमें लिखा था?"

उनका जवाब आम तौर पर बताएगा कि क्या गायब है, क्या गैरज़रूरी है, और क्या कागज़ पर अच्छा लगने पर असल उपयोग में मदद नहीं करता।

पहला बिल्ड इतना छोटा रखें कि आप तेज़ी से टेस्ट कर सकें। यह फर्क नहीं पड़ता कि आप डेवलपमेंट टीम के साथ काम कर रहे हैं या Koder.ai जैसी प्लेटफ़ॉर्म का उपयोग करके साधारण भाषा से ऐप बना रहे हैं—पहले वर्शन की गुणवत्ता अब भी इस पर निर्भर करती है कि आपने असली समस्या कितनी स्पष्ट रूप से परिभाषित की थी।

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

लॉञ्च को एक अगले राउंड के शोध की तरह ट्रीट करें। नए अनुरोध सेव करें, रिपीट टैग करें, और उपयोगकर्ताओं के अगले कदमों के आधार पर समायोजित करें। इस तरह छोटा, केंद्रित पहला वर्शन उस चीज़ में बदलता है जिसे लोग लगातार उपयोग करते हैं।