बिल्ड को भटकाए बिना हितधारकों से प्रतिक्रिया लें

क्यों प्रतिक्रिया बिल्ड को भटका देती है

अधिकतर बिल्ड्स एक ही वजह से भटकते हैं: योजना बार-बार बदलती रहती है।

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

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

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

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

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

यह विशेष रूप से आम है जब गैर-तकनीकी टीम तेज़ी से काम कर रही हों। उदाहरण के लिए, एक संस्थापक जो Koder.ai में एक ऐप बना रहा है, उसे एक साथ sales, operations, और एक बिजनेस पार्टनर से इनपुट मिल सकता है। अगर हर टिप्पणी सीधे बिल्ड में चली जाती है, तो प्रोडक्ट पहला वर्ज़न पूरा होने से पहले भटक सकता है।

इसका खर्च सिर्फ अतिरिक्त काम नहीं है। यह उलझन, धीमी डिलीवरी, और एक ऐसी टीम है जिसे अब यह नहीं पता कि ‘डन’ का मतलब क्या है।

प्रतिक्रिया शुरू होने से पहले नियम तय करें

अगर आप उपयोगी प्रतिक्रिया चाहते हैं तो नियम जल्दी तय करें।

अधिकांश प्रोजेक्ट तब डगमगाने लगते हैं जब टिप्पणियाँ पाँच अलग जगहों पर, पाँच अलग शैलियों में, पाँच अलग समय पर आती हैं। समाधान सरल है: प्रतिक्रिया के लिए एक घर, एक फ़ॉर्मेट, और एक समीक्षा तालिका दें।

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

फिर हर किसी से वही बेसिक फ़ॉर्मेट इस्तेमाल करने को कहें। यह जटिल होने की ज़रूरत नहीं है। एक छोटा नोट यह बताना चाहिए कि क्या बदलना है, यह कहाँ दिखाई देता है, यह क्यों महत्वपूर्ण है, और कितनी प्राथमिकता है। इससे अस्पष्ट टिप्पणियाँ जैसे "इसे बेहतर बनाओ" या "मुझे यह स्क्रीन पसंद नहीं है" हट जाती हैं।

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

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

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

अनुरोधों को वर्कफ़्लो के अनुसार समूहित करें

जब प्रतिक्रिया आनी शुरू हो जाए, तो उसे उस उपयोगकर्ता यात्रा के हिस्से के अनुसार छाँटें जिसे वह प्रभावित करती है।

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

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

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

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

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

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

बग को विचारों से अलग रखें

एक गलती बहुत सी अनावश्यक उलझनों का कारण बनती है: हर टिप्पणी को एक ही तरह के अनुरोध की तरह ट्रीट करना।

जब कुछ टूट रहा हो और जब कोई बदलाव चाहता हो, वही बात नहीं है।

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

अगर एक कस्टमर फ़ॉर्म बंद हो गया है, वह बग है। अगर कोई कहता है कि फॉर्म छोटा होना चाहिए या बटन का रंग बदलना चाहिए, वह एक विचार है।

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

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

इन दोनों कतारों को अलग रखें। बग और विचार मिश्रित होने पर असली मुद्दे दब जाते हैं और प्राथमिकता की बहसें तात्कालिक दिखने लगती हैं।

यह अंतर समय बचाता है। अगर कोई कहता है, "डैशबोर्ड अनुपयोगी है," तो लेबल मानने से पहले जाँच करें। अगर पेज क्रैश हो रहा है तो वह बग है। अगर वे अलग चार्ट या लेआउट चाहते हैं तो वह विचार है। अगला कदम उसी पर निर्भर करेगा।

एक स्पष्ट निर्णयकर्ता रखें

जब बहुत सारे लोग हाँ कह सकते हैं, तो हर अनुरोध खुला रहता है।

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

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

एक मजबूत निर्णयकर्ता बिल्ड के लक्ष्य को समझता है, गति और स्कोप के बीच संतुलन कर सकता है, और तब निर्णय लेने के लिए भरोसेमंद होता है जब विचार विभाजित हों।

उस मालिक को दिन एक से ही दिखाएँ। उनके नाम को प्रोजेक्ट ब्रीफ, किकऑफ नोट्स, और फीडबैक चैनल में डालें। अगर कोई अनुरोध चैट में आता है, तो हर किसी को पता होना चाहिए कि निर्णय कौन लेता है।

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

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

लोग अभी भी सुने हुए महसूस करते हैं, लेकिन बिल्ड आगे बढ़ती रहती है।

हर बार एक सरल समीक्षा प्रक्रिया उपयोग करें

फीडबैक को अच्छी तरह हैंडल करने का सबसे आसान तरीका है कि हर बार वही रास्ता अपनाएँ।

शुरू करें हर अनुरोध को एक साझा जगह भेजकर। फिर इसे एक तय क्रम में समीक्षा करें:

1. उसे उस वर्कफ़्लो के तहत रखें जिसे वह प्रभावित करता है।
2. उसे स्पष्ट लेबल दें: बग, विचार, फीचर अनुरोध, या प्रश्न।
3. अगर वह अस्पष्ट है, तो किसी के भी कार्रवाई से पहले फॉलो-अप माँगें।
4. दोगुने अनुरोधों को एक आइटम में मर्ज कर दें।
5. प्रभाव पर एक छोटा नोट जोड़ें।

अधिकतर टीमों के लिए यही काफी होता है।

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

एक बार फैसले हो जाने पर, उन्हें स्पष्ट भाषा में वापस साझा करें। लोगों को बताएं कि अभी क्या ठीक होगा, क्या पार्क किया गया है, और क्या इंकार किया गया। एक छोटा अपडेट काफी होता है।

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

एक स्पष्ट प्रक्रिया लोगों को सुना हुआ महसूस कराती है बिना हर राय को तुरंत काम में बदल दिए।

असल ज़िन्दगी में फीडबैक ट्रायज क्या दिखता है

कल्पना कीजिए एक छोटी टीम एक ग्राहक ऐप बना रही है।

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

तीनों अनुरोध महत्वपूर्ण लगते हैं, और हर किसी का एक ठोस कारण है। पर वे एक ही प्राथमिकता बकेट में नहीं आते।

टीम शुरुआत करती है उन्हें वर्कफ़्लो के अनुसार समूहित करके। अतिरिक्त फ़ील्ड साइनअप के हैं। रीसेट ईमेल का समस्या अकाउंट रिकवरी के है। चार्ट रिपोर्टिंग के तहत आता है।

यह त्वरित छंटनी ही मदद करती है। यह तीन बेतरतीब टिप्पणियाँ नहीं हैं। वे प्रोडक्ट के अलग हिस्सों को प्रभावित करते हैं और उनकी तात्कालिकता अलग है।

फिर मालिक हर एक को लेबल करता है। रीसेट ईमेल इशू बग है। अतिरिक्त फ़ील्ड एक फीचर अनुरोध है। चार्ट एक सुधार विचार है।

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

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

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

यही अच्छी ट्रायज दिखती है। एक व्यक्ति फैसला लेता है, टीम कारण देखती है, और बिल्ड आगे बढ़ती रहती है। तेज़ सेटअप में, जैसे कि Koder.ai पर बनते ऐप में, ऐसी छंटनी फीडबैक को उपयोगी बनाती है बजाय कि अराजक।

बचने के सामान्य गलतियाँ

बिल्ड का नियंत्रण खोने का सबसे तेज़ तरीका है हर फीडबैक को एक टास्क मान लेना।

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

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

झूठी सहमति एक और जाल है। लोग मीटिंग में सिर हिलाते हैं और कहते हैं, "हम सभी सहमत हैं," पर अगर कोई वास्तव में निर्णय का मालिक नहीं है, तो वही मुद्दा अगले दिन नए तर्क के साथ लौट आता है।

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

एक बेहतर आदत सरल है: रुकें, स्पष्ट करें, समूहित करें, और निर्णय लें।

काम शुरू होने से पहले एक त्वरित चेकलिस्ट

नए फीडबैक पर काम शुरू करने से पहले पाँच मिनट लें और कुछ बुनियादी चीज़ें जाँचें।

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

उसके बाद जाँचें कि निर्णयकर्ता ने इसे मंजूर किया है और क्या इसे अभी कार्रवाई की ज़रूरत है या अगले समीक्षा चक्र तक इंतज़ार कर सकता है।

यह छोटा फिल्टर बहुत सारा शोर काट देता है। उपयोगकर्ताओं को ब्लॉक करने वाला बग तेज़ी से जाना चाहिए। अनुभव को बेहतर करने वाला विचार योजना के लिए इंतज़ार कर सकता है।

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

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

व्यावहारिक अगले कदम

भारी प्रक्रिया से शुरू मत करें। सभी के लिए एक साझा टेम्प्लेट से शुरू करें।

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

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

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

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

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

यही लक्ष्य है। प्रतिक्रिया प्रोडक्ट को बेहतर बनानी चाहिए, उसे कोर्स से नहीं भटकाना चाहिए।