Scope creep का जाल: उन features को 'ना' कैसे कहें जो सुनने में अच्छे लगते हैं पर हैं नहीं

आपने एक app शिप की। Users आए। और अब आपका inbox ऐसे feature requests से भरा है जो सब अच्छे आइडिया लगते हैं।

“क्या हम Excel में export जोड़ सकते हैं?” वाज़िब है। “क्या invoices अपने-आप भेजी जा सकती हैं?” समझ में आता है। “क्या हम Stripe से integrate कर सकते हैं?” वहीं तो असली पैसा है। “क्या आप एक mobile app जोड़ सकते हैं?” यह तो हर कोई माँगता है। “क्या हम इसे अपने खुद के customers के लिए white-label कर सकते हैं?” अरे, अब तो एक business model आ गया।

हर request अकेले-अकेले समझदारी भरी लगती है। पर मिलाकर देखें तो लगता है मानो आप पांच अलग-अलग products बना रहे हैं।

यही है scope creep, और यह छोटी AI से बनी apps को technical समस्याओं से कहीं ज़्यादा मारता है। इसलिए नहीं कि आप वो features बना लेते हैं — बल्कि इसलिए कि उन्हें बनाने की कोशिश में आपका वक़्त, पैसा या दिमाग़ी सुकून खत्म हो जाता है।

Scope creep एक चलती हुई app को कैसे मारता है

यह जो होता है। आप पहली तीन requests को “हां” कह देते हैं क्योंकि वो वाज़िब लगती हैं। आप अपने AI builder से उन्हें जोड़ने को कहते हैं। यह एक के बजाय दो हफ़्ते लेता है क्योंकि हर नई feature मौजूदा code से टकराती है। अब आपके पास एक ऐसी app है जो पांच काम करती है, और उनमें से तीन अच्छे से और दो ठीक-ठाक करती है।

फिर चौथी request आती है: “क्या हमारे पास अलग-अलग permission levels हो सकती हैं?” अचानक आपको हर स्क्रीन में यह दोबारा सोचना पड़ता है कि कौन क्या देख सकता है। यह कोई feature नहीं है; यह एक architecture बदलाव है। आप अपने AI builder से इसे करने को कहते हैं। यह हर चीज़ को छूता है। दो हफ़्ते तीन हो जाते हैं। App धीमी हो जाती है क्योंकि आपने हर view में logic जोड़ दिया है।

आठवीं request तक आपने अपने मूल users के लिए नई चीज़ें शिप करना बंद कर दिया है क्योंकि आप feature-request की मशीन को चलाते रखने में बहुत व्यस्त हैं। जिन लोगों को तीन महीने पहले यह app पसंद थी, वो खीझे हुए हैं क्योंकि उनका माँगा कुछ भी पूरा नहीं हुआ। और जो नई requests कर रहे हैं वो खीझे हुए हैं क्योंकि features बनने में अनंत वक़्त लग रहा है।

आपने कुछ ऐसा बनाया जो चलता था। और हर चीज़ बनने की कोशिश में आपने उसे तोड़ दिया।

फ़ैसले का ढांचा

आपको एक छलनी चाहिए। हर feature request तीन सवालों से गुज़रती है:

सवाल 1: क्या यह इसी app में बैठती है, या यह कोई अलग app है?

आपकी पहली app एक काम वाक़ई बढ़िया करती है। एक scheduling app चीज़ें schedule करती है। एक invoicing app invoice बनाती है। ये अलग-अलग apps हैं। अगर कोई आपकी scheduling app से invoice बनाने को कहता है, तो आप कोई feature नहीं जोड़ रहे — आप एक scheduling app से accounting करवाने को कह रहे हैं। यह एक अलग product है।

एक अच्छी कसौटी: “अगर मैं इस feature को लेकर इसे standalone शिप कर दूं, तो क्या लोग इसे खरीदना चाहेंगे?” अगर हां, तो यह शायद किसी अलग app में बैठती है। अगर जवाब है “नहीं, यह सिर्फ़ बड़ी चीज़ के हिस्से के तौर पर ही समझ आती है,” तो आप सही scope बना रहे हैं।

आपको “हमारे CRM से integrate करो” जैसी requests मिलेंगी। इसका असल मतलब है “खुद ही एक CRM बन जाओ।” यह एक अलग app है। आप किसी CRM से बाद में integrate कर सकते हैं। आप एक CRM जितने features खुद CRM बने बिना नहीं जोड़ सकते।

सवाल 2: क्या यह आपके ज़्यादातर users की समस्या हल करती है, या सिर्फ़ इस एक की?

एक customer को आपकी app पसंद है और उसके पास एक feature का आइडिया है। यह उसकी एक असली समस्या है। और यह एक ऐसी असली समस्या भी है जो सिर्फ़ उसी की है।

अगर आपके बीस users हैं और एक कुछ माँग रहा है, तो जांचिए: क्या बाक़ी उन्नीस भी इसका इंतज़ार कर रहे हैं, या यह बस इसी इंसान के दिमाग़ में आया? आप उनसे सीधे पूछ सकते हैं: “आपसे पहले, क्या आपने किसी और से पूछने का सोचा कि उसे यह चाहिए या नहीं?” आम तौर पर जवाब होता है नहीं।

यह ख़तरनाक सवाल है क्योंकि जो एक customer माँग रहा है वो शायद आपका सबसे ज़रूरी customer हो। शायद आपको उसे खुश रखने की ज़रूरत हो। यह एक business फ़ैसला है, product फ़ैसला नहीं। पर आंखें खुली रखकर आगे बढ़िए: अगर आप एक customer के लिए कुछ बनाते हैं, तो आप अपनी app नहीं बढ़ा रहे, आप एक consulting practice खड़ी कर रहे हैं।

सवाल 3: इसकी क़ीमत क्या है और मूल आइडिया पर इसकी क़ीमत क्या है?

हर चीज़ की कोई न कोई क़ीमत होती है। Excel में export आपका engineering का वक़्त खर्च करता है। यह आपकी app की जटिलता खर्च करता है। यह आपका ध्यान खर्च करता है। इसे उस performance optimization के बजाय बनाइए जिसकी शिकायत आपके users रोज़ करते हैं, और आपने एक चुनाव कर लिया।

ठोस होकर पूछिए: “अगर मैं यह बनाता हूं, तो मैं क्या नहीं बनाऊंगा?” अगर जवाब है “कुछ नहीं, हमारे पास अनंत वक़्त है,” तो आप ईमानदार नहीं हैं। हमारे पास नहीं है। वक़्त सीमित है।

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

एक असली उदाहरण: intake form

किसी ने एक आसान-सा client intake form बनाया। Clients इसे भरते हैं, coach इसे देखता है, वो schedule कर लेते हैं। बस यही है app।

Request एक: “क्या मैं ज़रूरी intakes को mark कर सकता हूं?” हां, यह मूल workflow का ही एक रूप है। बना दीजिए।

Request दो: “क्या मैं अपने रिकॉर्ड के लिए intakes को Excel में export कर सकता हूं?” यह एक document feature है। यह app का काम नहीं है। Intakes app में रहते हैं। अगर उन्हें Excel चाहिए, तो वो copy-paste कर सकते हैं। पर ठीक है, export शायद एक सुविधा के तौर पर समझ आता है। बना दीजिए।

Request तीन: “क्या intakes अपने-आप calendar events बना सकते हैं?” अब आप scheduling कर रहे हैं। App intake के लिए थी, scheduling के लिए नहीं। अगर किसी को दोनों चाहिए, तो उसे शायद एक असली scheduling सिस्टम चाहिए, न कि एक ऐसा जुगाड़ जो एक को दूसरे पर चिपका दे। विनम्रता से ठुकरा दीजिए।

Request चार: “क्या coaches SMS के ज़रिए intake follow-ups भेज सकते हैं?” अब आप एक communication सिस्टम हैं। ना।

Request तीन तक आप सीमा से टकरा चुके हैं। App का काम है intake। बाक़ी सब कुछ एक अलग app है। आप उन apps से बाद में integrate कर सकते हैं। आप उन्हें खुद वो apps बने बिना नहीं जोड़ सकते।

ना कैसे कहें

सबसे मुश्किल हिस्सा है इसे असल में कह पाना। आप अपने users को खीझाना नहीं चाहते।

ईमानदार रहिए: “यह बढ़िया आइडिया है, पर यह उससे एक अलग product है जो हम यहां बना रहे हैं। हम जो बना रहे हैं वो है [आपका एक काम]। अगर हम scheduling या invoicing या CRM वाली चीज़ें करने की कोशिश करते हैं, तो हम इन सब में ठीक-ठाक होंगे और किसी में भी बढ़िया नहीं।”

अक्सर customer समझ जाएगा। उसने इसलिए पूछा क्योंकि आइडिया उसके मन में आया, इसलिए नहीं कि वो आपको परख रहा है।

कभी-कभी वो पीछे नहीं हटेंगे। “पर मुझे दोनों चाहिए।” तभी आप सुझाव दीजिए: असली scheduling app इस्तेमाल कीजिए। असली invoicing app इस्तेमाल कीजिए। असली CRM इस्तेमाल कीजिए। फिर इस app को उसके लिए इस्तेमाल कीजिए जो यह अच्छे से करती है। यही ईमानदार जवाब है।

हर चीज़ बनने का लालच

एक छोटा product बनाने का सबसे मुश्किल हिस्सा है ना कहना। ना ऐसा लगता है मानो आप मेज़ पर पैसा छोड़ रहे हों। क्या होगा अगर वो customer सचमुच दोनों के लिए पैसे देता? क्या होगा अगर वो feature आपको दस गुना बड़ा बना देती?

शायद। पर अगर आप इसे शिप ही नहीं करते तो आप दस-गुना-बड़ा product नहीं हैं। आप एक अधूरा product हैं जो पांच काम बुरी तरह करता है। जिन्हें मूल चीज़ पसंद थी वो खीझे हुए हैं। जिन्हें नए features चाहिए थे वो खीझे हुए हैं। और आपने खुद को एक ऐसे कोने में धकेल दिया है जहां कोई भी नई चीज़ जोड़ने का मतलब है पहले पांच पुरानी चीज़ों को दोबारा गढ़ना।

जो products बढ़ते हैं वो वही हैं जो एक काम वाक़ई अच्छे से करते हैं, और फिर सोच-समझकर जोड़ते हैं। वो पहले ही दिन से Salesforce बनने की कोशिश नहीं करते। वो वो app हैं जिसकी ओर आप तब हाथ बढ़ाते हैं जब आपको वो एक काम करना हो, और वो app जिस पर आप भरोसा करते हैं कि जब आप वो काम करें तो यह तेज़ और भरोसेमंद रहेगी।

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