इस पेज पर
डेमो में डैशबोर्ड सुंदर दिखता है. इस उदाहरण में वह मासिक एक्सपोर्ट का फ़ॉर्मैट दोष ढूंढता है. उसे ठीक करने में दो मिनट लगते हैं और साल में दो बार होता है. सभी डेमो पसंद करते हैं, लेकिन परीक्षण के बाद कोई डैशबोर्ड नहीं खोलता.
समस्या सचमुच मौजूद है, पर उसके साथ रहने की लागत एक और टूल जोड़ने से कम हो सकती है. सुंदरता अपने आप तात्कालिकता नहीं बनाती.
संग्रहित प्रोडक्ट बातचीत दो अक्षों की जांच देती है: छोटी और दुर्लभ दोनों तरह की समस्या से सावधान रहें. बड़ी समस्या कम बार आए तो भी ध्यान मांग सकती है; छोटा दोहराया काम दैनिक आदत में जमा हो सकता है. प्रस्ताव के पीछे का असली काम देखें.
घटनाएं और असर अलग गिनें
“कितने लोगों को यह समस्या है?” पहला सवाल बहुत व्यापक है. विशेष टीम से पूछें पिछली बार कब हुई और उसके बाद क्या हुआ. किसी ने मिनट लगाए, बिक्री गंवाई, ऑर्डर देर हुआ, निजी डेटा खुला या बस चिढ़ हुई? ये असर समान नहीं.
फिर पूछें उसी तरह का इवेंट कितनी बार होता है. सप्ताह में पांच मिनट का सुधार बड़ी टीम में आश्चर्यजनक समय ले सकता है. साल में एक बार की विफलता महत्वपूर्ण स्थानांतरण रोकती हो तो मायने रखती है. साल में दो बार की दो मिनट की परेशानी को अलग प्रोडक्ट बेचना कठिन है.
दोनों अक्षों पर आधारित उदाहरण का चुनाव देखें:
समस्या कितना ध्यान कमा सकती है?
-
दुर्लभ और मामूली
फ़ीचर या मैनुअल सूची
नया प्रोडक्ट समस्या से अधिक ध्यान मांग सकता है.
-
दुर्लभ लेकिन महंगी
सुरक्षा उपाय या घटना से निपटने की प्रक्रिया
हर घटना तैयारी उचित बना सकती है.
-
बार-बार लेकिन छोटी
डिफ़ॉल्ट या हल्की आदत
दोहराए काम में लागत जमा होती है.
-
बार-बार और महंगी
समर्पित वर्कफ़्लो
दोहराया असर लगातार निवेश उचित बना सकता है.
ये श्रेणियां जांच के संकेत हैं, बाज़ार का फैसला नहीं. “अधिक” इस पर निर्भर है कि किसकी लागत गिनी. एडमिन को मामूली त्रुटि ग्राहक के लिए गंभीर हो सकती है. छोटी बातचीत में न आई विफलता मौसमी भीड़ में केंद्रीय हो सकती है.
डेमो में छोटी समस्या सिस्टम में बड़ी हो सकती है
इंटीग्रेशन में फर्क स्पष्ट है. एक संपर्क रिकॉर्ड में गलत फ़ील्ड छोटा लगता है. वही मैपिंग हज़ारों संपर्क पर चले तो दोहराए मैनुअल सुधार का स्रोत बनती है. इसके उलट एक बार के बाहरी रूप के अंतर पर जटिल चेतावनी बचाए समय से अधिक प्रशासन जोड़ सकती है.
बिज़नेस टूल इंटीग्रेशन गाइड वर्कफ़्लो और सत्य के स्रोत से शुरू होती है क्योंकि असली लागत रिकॉर्ड के चलने और उपयोग में है. मुफ़्त टूल से अपग्रेड तय करती टीम भी केवल फ़ीचर सूची नहीं, अस्थायी उपाय और छूटे कार्य गिने.
पिछली तीन वास्तविक घटनाएं मांगें. हर एक में किसने देखा, किसने सुधारा, कौन सा दूसरा काम रुका और किसी ने दखल न दिया तो क्या होता, दर्ज करें. आखिरी सवाल परेशानी को अदृश्य जोखिम से अलग करता है. किसी चौंकाने वाली कल्पना को मापा पैटर्न बनाने से भी रोकता है.
फिर मौजूदा अस्थायी उपाय की लागत पूछें. स्प्रेडशीट और पांच मिनट जांच पर्याप्त हो सकती है. हर सुबह विशेषज्ञ से रिकॉर्ड मिलवाने वाली मैनुअल प्रक्रिया शायद नहीं. विकल्प प्रोडक्ट मूल्य का हिस्सा है, छिपाने की शर्म नहीं.
समस्या लागत के साथ अपनाने की लागत जांचें
अर्थपूर्ण समस्या भी नया ऐप उचित नहीं बना सकती. किसी को उसे जोड़ना, सीखना, आउटपुट देखना और पहुंच संभालनी होगी. प्रोडक्ट काम से अधिक ध्यान मांगे तो खरीदार पुराने उपाय पर तर्कसंगत ढंग से टिक सकते हैं.
स्रोत बातचीत चेताती है कि हाथ से की सेटअप शुरुआती रुचि वास्तविक से बड़ी दिखा सकती है. टीम सॉफ़्टवेयर खरीदती दिखे, लेकिन असल में बिना कीमत वाली परामर्श सेवा पर निर्भर हो. छोटी समस्या और महंगी ऑनबोर्डिंग वाला रास्ता टिकाऊ ढंग से देना विशेष कठिन है. सेवा मना नहीं; उसे गिनें.
दो अक्षों के अपवाद हैं. अनुपालन दायित्व कम देखी घटनाओं के बावजूद कार्रवाई मांग सकते हैं. नए बाज़ार में मापने का इतिहास कम हो सकता है. व्यापक आबादी में समस्या कम हो लेकिन छोटे समूह को काफ़ी दर्द हो सकता है. वहां प्रमाण केवल आवृत्ति अनुमान नहीं, दायित्व, विश्वसनीय विफलता रास्ता या निश्चित बजट से आए.
अक्ष यह भी तय करने में मदद करते हैं कि ज़रूरत अपना प्रोडक्ट बने या पहले से उपयोग वाले टूल का छोटा फ़ीचर. दुर्लभ मामूली फ़ॉर्मैट समस्या एक्सपोर्ट प्रक्रिया का उपयोगी बटन हो सकती है, लेकिन अलग सेवा की सदस्यता कोई न खरीदे. बार-बार होने वाली छोटी समस्या का बेहतर हल एक और डैशबोर्ड बेचने के बजाय डिफ़ॉल्ट बदलना हो सकता है. प्रोडक्ट का दायरा उस ध्यान से मेल खाए जो काम पहले से पाता है. सवाल समस्या मौजूद है या नहीं नहीं, बल्कि उसे हल करने के लिए कितने नए व्यवहार की मांग की जा सकती है.
उपयोगी खोज सवाल “क्या आप यह इस्तेमाल करेंगे?” नहीं. “पिछली बार कब हुआ, क्या लागत थी और आपने बदले में क्या किया?” है. उत्तर लोग पहले से जिस काम को बदलना चाह रहे हैं, उसकी ओर इशारा करे तब प्रोडक्ट का कारण बनता है.
अक्सर पूछे जाने वाले प्रश्न
क्या दुर्लभ समस्या भी प्रोडक्ट का आधार हो सकती है?
हां, अगर हर बार उसकी लागत, तात्कालिकता या जोखिम समाधान खरीदने और संभालने के योग्य हो. केवल आवृत्ति से महत्व नहीं नपता.
समस्या बहुत छोटी है या नहीं कैसे जांचें?
पूछें आखिरी बार कब हुई, टीम ने क्या किया, कितना समय या पैसा लगा और बचने के लिए कोई बजट या वर्कफ़्लो बदलेगा या नहीं.
बड़ा संभावित बाज़ार कमज़ोर मांग ठीक कर देगा?
नहीं. संभावित उपयोगकर्ताओं की बड़ी संख्या यह नहीं बताती कि उनमें कोई एक अपनाने या भुगतान करने जितनी समस्या महसूस करता है. विशिष्ट वर्कफ़्लो में असर और आवृत्ति जांचें.