वो Feature Request जो आपको सचमुच बनानी चाहिए (और कैसे पहचानें)

सारी feature requests बराबर नहीं होतीं। कुछ आपकी app को बेहतर बनाएंगी। कुछ आपको मशहूर कर देंगी। कुछ आपको हमेशा के लिए भटका देंगी। यहां बता रहे हैं कि असल में मायने रखने वालों को कैसे पहचानें।

आपको बुरी feature requests को ना कहना आता है। आपने scope creep को core features से अलग पहचानना सीख लिया है। आप अपने product की सीमाओं की हिफ़ाज़त कर रहे हैं।

पर अब आप एक अलग ही उलझन में हैं: आपके पास एक दर्जन requests हैं जो सब टेस्ट पास कर लेती हैं। वो सब आपकी app के लिए हैं। वो सब वाजिब हैं। वो सब ऐसी चीज़ें हैं जो आपके यूज़र्स सचमुच चाहते हैं। पर आप उनमें से सिर्फ़ तीन ही बना सकते हैं।

कौन सी तीन?

यहीं ज़्यादातर product फ़ैसले गलत होते हैं। Founders उन्हें चुन लेते हैं जो सबसे प्रभावशाली लगती हैं, या सबसे मुनाफ़े वाली, या जो उनके सबसे ज़रूरी customer से आई हों। कभी-कभी वो सही होते हैं। अमूमन वो गलत होते हैं।

वो संकेत जो मायने रखते हैं

संकेत 1: बिना कहे की दोहराई

अगर तीन अलग-अलग यूज़र्स आपस में बात किए बिना एक ही चीज़ मांगते हैं, तो वो एक संकेत है। उन्होंने तालमेल नहीं किया। उन सबको बस अलग-अलग यह सूझा। अगर पांच यूज़र्स इसे मांगें, तो वो इत्तेफ़ाक नहीं है — वो एक असली ज़रूरत है।

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

बनाने से पहले requests गिनें। सबसे शोर मचाने वाले customer या आपके सबसे बड़े client वाली नहीं — बिना कहे की दोहराई गिनें। एक ही चीज़ मांगने वाले दो या तीन स्वतंत्र यूज़र्स, पांच चीज़ें मांगने वाले एक ज़रूरी customer से कहीं ज़्यादा मज़बूत संकेत हैं।

संकेत 2: workaround मायने रखता है

अगर आपके पास यूज़र्स हैं और वो टिके हुए हैं इसके बावजूद कि feature नहीं है, तो उन्होंने कोई workaround ढूंढ लिया है। शायद वो इसे आपकी app के बाहर कर रहे हैं। शायद वो इसे हाथ से कर रहे हैं। शायद वो साथ-साथ कोई दूसरा tool इस्तेमाल कर रहे हैं।

पर वो टिके हुए हैं, यानी उन्हें आपकी app इस्तेमाल करने के लिए इस feature की ज़रूरत नहीं है। उन्हें यह आपकी app को बेहतर इस्तेमाल करने के लिए चाहिए। यह किसी रुकावट से अलग है।

सबसे ज़्यादा मायने रखने वाले features वो हैं जो लोगों को आपकी app इस्तेमाल करने से ही रोक देते हैं। जो nice-to-have होते हैं वो वो हैं जिनके इर्द-गिर्द लोग कोई रास्ता निकाल लेते हैं।

ध्यान दें कि कौन सी requests रुकावटें हैं। कोई कहता है “जब तक आप X नहीं करते मैं इसे इस्तेमाल नहीं कर सकता” बनाम कोई कहता है “बहुत अच्छा होता अगर आपके पास X होता।” यह फ़र्क सोना है।

संकेत 3: feature business model के साथ बंधता है

कुछ features कमाई के बिल्कुल नए तरीके खोल देते हैं। “मेरे customers को invoice भेजो” एक ऐसा business model खोलता है जहां आप invoicing के पैसे लेते हैं। “Salesforce में export करो” integration revenue खोलता है। “resellers के लिए white-label” एक partner channel खोलता है।

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

सबसे कामयाब feature जोड़ें वो होती हैं जहां feature शिप करना एक ऐसा बाज़ार उजागर कर देता है जिसके होने का आपको पता ही नहीं था। आपने export बनाया। पता चला कंपनियां आपके export को अपने workflow में embed करना चाहती हैं। अब आपके पास एक integration की कहानी है जिसकी आपने योजना नहीं बनाई थी।

Features इसलिए बनाएं क्योंकि आपके यूज़र्स को उनकी ज़रूरत है। फिर देखें कि क्या आपके यूज़र्स उन्हें ऐसे तरीके से ज़रूरतमंद हैं जो नया business बनाता है। पहले से business model की भविष्यवाणी न करें।

संकेत 4: मदद की पेशकश

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

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

जो लोग सिर्फ़ request करते हैं वो वो लोग हैं जो उम्मीद कर रहे हैं कि आप जादुई ढंग से वो बना देंगे जो वो कल्पना में देख रहे हैं। कभी-कभी आप बना देंगे। अक्सर नहीं।

पहले testers के साथ बनाएं। बाकी सब गौण है।

prestige feature बनाने का लालच

हर product में एक feature ऐसा होता है जिसे अगर आप शिप कर दें, तो आप ज़्यादा प्रभावशाली सुनाई देते हैं। scheduling apps के लिए, वो Calendly से integrate करना है। task apps के लिए, वो Slack से integrate करना है। हर कोई जानता है कि वो क्या हैं। हर कोई उन्हें चाहता है।

बात यह है: हर कोई उन्हें किसी और से भी पा रहा है। अगर आपका feature Slack के साथ सबसे अच्छा, सबसे आसान integration नहीं है, तो वो बस आपकी app में पेचीदगी जोड़ता है बिना आपको मशहूर किए।

जो features आपको मशहूर करते हैं वो वो हैं जिन्हें बनाने के लिए आप बेजोड़ ढंग से तैयार हैं क्योंकि आप अपने ख़ास यूज़र्स की समस्याएं किसी और से बेहतर समझते हैं। वो prestige features नहीं हैं। वो उबाऊ features हैं जो असली लोगों की असली समस्याएं हल करते हैं।

Slack integration प्रभावशाली है। एक ऐसा tool जो आपके यूज़र्स को एक ख़ास काम Slack के सोचने से कहीं तेज़ करने देता है, बेशकीमती है।

असल में फ़ैसला कैसे करें

जब आपके पास feature requests का एक बैच हो जो सब “क्या यह scope में है?” टेस्ट पास कर लेता है, तो उन्हें इस आधार पर rank करें:

  1. कितने यूज़र्स ने मांगा (स्वतंत्र रूप से)? ज़्यादा बेहतर है।
  2. क्या यह रुकावट है या nice-to-have? रुकावटें ज़्यादा ज़रूरी हैं।
  3. क्या आपके यूज़र्स आज इसके इर्द-गिर्द कोई रास्ता निकाल सकते हैं? अगर नहीं, तो यह ज़्यादा ज़रूरी है।
  4. क्या कोई इसे टेस्ट करने में आपकी मदद करेगा? अगर हां, तो इसे पहले बनाएं।
  5. क्या यह कोई नया बाज़ार उजागर करेगा? अगर शायद, तो वो एक बोनस है, वजह नहीं।

फिर उसी क्रम में बनाएं। प्रभावशाली-सुनाई-देने के क्रम में नहीं। अपने सबसे बड़े customer के क्रम में नहीं। आपकी app इस्तेमाल करने वाले लोगों के असली संकेत के क्रम में।

वो feature जो आप (अभी) नहीं बनाएंगे

आपके पास ऐसी requests होंगी जो कट में नहीं आतीं। यह दिखावा न करें कि आप उन्हें किसी दिन बनाएंगे। यूज़र को बता दें: “हम अभी वो नहीं बना रहे। यह रही वजह। यह रहा जो हम बना रहे हैं। यह रहा एक विकल्प जो आपके लिए शायद काम करे।”

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

और कभी-कभी, जब आप ना कह देते हैं, तो यूज़र कोई workaround, या कोई दूसरा tool, या समस्या को किसी अलग तरीके से हल कर लेता है। यह ठीक है। आप हर किसी के लिए सब कुछ नहीं हो सकते।

जीतने वाले products वो हैं जो अपना काम अच्छे से करते हैं और ध्यान से सुनते हैं कि यूज़र्स को असल में क्या चाहिए, न कि वो जो सब कुछ बनने की कोशिश करते हैं और आख़िर में कुछ भी नहीं रहते।