बनाने से पहले यूज़रों से बात करना सबका समय बर्बाद करना है

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

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

वह चीज़ जो इंटरव्यू पैदा नहीं कर सकते

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

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

इसके बजाय मैं क्या करता हूं

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

यह पारंपरिक रिसर्च फ़नल को उलट देता है, और यह स्पष्ट करना जरूरी है कि क्या बदलता है:

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

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

जहाँ आलोचक सही हैं

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

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