- product roadmap पर चर्चा में sales, marketing, R&D और business head सभी ग्राहक की बात करते हैं, लेकिन अगर वे उस काम (job) को चूक जाएँ जिसके लिए ग्राहक ने product को “hire” किया है, तो निर्णय का आधार धुंधला हो जाता है
- Intuit survey में आए 150 feature requests के पीछे भागते-भागते feature chase में फँस गया, और उसके पास यह तय करने का कोई compass नहीं था कि कौन-सा feature सच में महत्वपूर्ण है
- milkshake के उदाहरण में taste, price और texture से जुड़े सवालों से sales नहीं बढ़ी, लेकिन खरीदारी की स्थिति को observe करने पर सुबह commute करने वालों की लंबी यात्रा और भूख core job के रूप में सामने आई
- वही milkshake सुबह bagel, protein bar और juice से, जबकि दोपहर में बच्चे को दिए जाने वाले snack options से compete करता है, इसलिए evaluation criteria और competing products बदल जाते हैं
- Job to be done खोजने के लिए पास की समस्याएँ, कुछ न करने का विकल्प, workaround behavior, वे काम जिनसे लोग बचना चाहते हैं, और असामान्य use observe करने चाहिए
ग्राहक requests roadmap का compass क्यों नहीं बन पातीं
- roadmap meeting में हर department से अलग-अलग customer input आता है
- sales लगातार ग्राहकों से बात करता है, इसलिए उसे लगता है कि वह सबसे urgent मांगों को जानता है
- marketing मानता है कि existing brand का उपयोग करके नया version, नया flavor, नया color या special offer बनाया जा सकता है
- R&D नई technology या applications से निकले features और benefits पर focus करता है
- business head साल के अंत तक P&L में मदद करने वाला launch चाहता है
- हर approach कुछ हद तक सही है, लेकिन वे अपनी view को support करने वाली information ही देखने वाले confirmation bias में फँस सकते हैं
- बड़ी समस्या यह है कि कोई भी model सीधे customer के job को reflect नहीं करता
Intuit का feature chase में फँसना
- Intuit ने customers से desired new features पूछने के लिए व्यापक survey किया, और customers ने desired features की लंबी list दी
- Intuit के CEO रहे Cook के अनुसार, customers ने “150 features” मांगे, और development team ने कई हफ्तों तक बहस की कि कौन-सा feature ज्यादा important है
- team members सभी मानते थे कि वे customer के लिए सही choice कर रहे हैं, लेकिन असल में उनके पास judgement criteria नहीं था
- अगर यह पता न हो कि customer product को किस काम के लिए “hire” करना चाहता है, तो सही feature को अलग करना मुश्किल है, और Cook ने इसे बिना compass के navigation जैसी स्थिति बताया
milkshake sales क्यों नहीं बढ़ीं
- fast-food chain ने अधिक milkshake बेचने के लिए ideal consumer profile में fit बैठने वाले customers को बुलाकर सवाल पूछे
- क्या यह सस्ता होना चाहिए
- क्या इसमें ज्यादा chunks होने चाहिए
- क्या इसमें ज्यादा chewiness होनी चाहिए
- क्या chocolate flavor ज्यादा strong होना चाहिए
- customers ने बताया कि वे क्या चाहते हैं, लेकिन इसके आधार पर क्या करना चाहिए, यह स्पष्ट नहीं था
- chain ने customer feedback के मुताबिक कई experiments किए, लेकिन कुछ महीनों बाद milkshake category की sales में कोई बदलाव नहीं हुआ
observation से सामने आया morning milkshake का job
- सवाल को बदलकर यह किया गया: “लोग कौन-सा काम हल करने के लिए इस restaurant में आकर milkshake को hire करते हैं”
- team ने एक दिन में 18 घंटे store में customers को observe किया
- वे milkshake कब खरीदते हैं
- उन्होंने कैसे कपड़े पहने हैं
- क्या वे अकेले आए हैं
- क्या उन्होंने साथ में कोई और food भी खरीदा है
- क्या वे store में पीते हैं या car लेकर निकल जाते हैं
- सुबह 9 बजे से पहले milkshake बहुत बिकते थे, और buyers आमतौर पर अकेले आते, सिर्फ milkshake खरीदते और car लेकर निकल जाते थे
- morning customers का common job था लंबे और boring commute को सहना और mid-morning hunger से बचना
- competing alternatives थे, लेकिन perfect नहीं थे
- banana बहुत जल्दी खा लिया जाता था, इसलिए mid-morning में फिर भूख लगती थी
- donut से crumbs गिरते थे और fingers sticky हो जाती थीं, जिससे कपड़े और steering wheel गंदे होते थे
- bagel अक्सर dry और बेस्वाद होता था, और cream cheese या jam लगाते हुए drive करना पड़ता था
- milkshake को पतले straw से गाढ़ा drink होने के कारण देर तक पीना पड़ता था, जिससे समय कटता था, वह पूरे morning भर पेट रखता था, और cup holder में fit हो जाता था
वही product अलग-अलग समय पर अलग competition करता है
- लोग दिन में दो अलग situations में milkshake को अलग-अलग jobs के लिए hire करते हैं
- morning milkshake bagel, protein bar और fresh juice bottle से compete करता है
- afternoon milkshake बच्चे के लिए toy store जाना, या जल्दी घर जाकर basketball खेलने के विकल्प से compete करता है
- same product भी अगर job अलग हो, तो competing products और evaluation criteria भी बदल जाते हैं
Job to be done खोजने के पाँच संकेत
-
1. पास की जगहों में job खोजें
- data-driven दुनिया में भी कुछ बड़े innovations Job to be done के intuition से शुरू हुए
- Khan Academy की शुरुआत Sal Khan की इस इच्छा से हुई कि वे अपने cousin को stress के बिना math सीखने में मदद करें, और वैसी ही तकलीफ महसूस करने वाले लोग बहुत थे
-
2. कुछ न करने के विकल्प से compete करें
- अगर consumer अपने job को satisfy करने वाला solution नहीं पाता, तो वह कुछ न करने का विकल्प चुन सकता है
- companies को सिर्फ existing competitors का market share छीनने का तरीका नहीं देखना चाहिए, बल्कि यह भी देखना चाहिए कि invisible demand कहाँ है
- Airbnb के global hospitality और strategy head Chip Conley के अनुसार, Airbnb “guests” में से 40% ने कहा कि अगर Airbnb न होता तो वे travel नहीं करते या family के साथ रहते
-
3. workaround और compensating behavior देखें
- OpenTable restaurants reservation के आसपास मौजूद पुराने workaround behavior से निकला
- दोस्तों के साथ possible time मिलाने के बाद restaurant को call किया जाता था, लेकिन अगर table available न हो, तो फिर दोस्तों से संपर्क करना और दूसरा restaurant ढूँढना बार-बार करना पड़ता था
- OpenTable ने इस reservation job को solve किया
-
4. वे काम खोजें जिन्हें लोग करना नहीं चाहते
- Clayton Christensen ने इन्हें negative jobs कहा, और negative jobs अच्छे innovation opportunities बन सकते हैं
- Harvard Business School alumni Rick Krieger और उनके partners ने बेटे के sore throat test के लिए emergency room में कई घंटे इंतजार करने के बाद QuickMedx शुरू किया, जो CVS MinuteClinics का predecessor बना
- CVS MinuteClinic बिना appointment वाले patients को तुरंत देखता है, और nurse practitioners conjunctivitis, ear infection, sore throat जैसी routine illnesses के लिए medicines prescribe कर सकते हैं
- अगर doctor के पास जाना जरूरी न हो तो बहुत से लोग जाना नहीं चाहते, इसलिए MinuteClinic CVS pharmacy stores के अंदर 33 states में 1,000 से ज्यादा locations पर खुला
-
5. असामान्य use देखें
- अगर लोग कोई काम पूरा करने के लिए खुद workaround या compensating behavior बनाते हैं, तो यह संकेत हो सकता है कि वह job important है और existing solutions को लेकर frustration भी बड़ी है
- ऐसी situation high-potential innovation opportunity में बदल सकती है
बेहतर सवाल
- W. Edwards Deming ने कहा था, “अगर आप सही सवाल पूछना नहीं जानते, तो आप कुछ भी discover नहीं कर पाएँगे”
- बेहतर सवाल customer से यह पूछना नहीं है कि वह क्या चाहता है, बल्कि यह पूछना है: “उस product को किस काम के लिए hire किया गया था”
1 टिप्पणियां
Hacker News की राय
प्रोडक्ट मैनेजमेंट की क्लासिक गलतियाँ अक्सर इस मान्यता से शुरू होती हैं कि यूज़र अपनी ज़रूरत खुद जानते हैं। असल में ऐसा कम ही होता है, और असली ज़रूरत समझना प्रोडक्ट टीम का काम है
जब तक लोग उसे वास्तव में इस्तेमाल नहीं करते, तब तक इस बात का कोई सबूत नहीं होता कि जो अभी बनाया जा रहा है वही यूज़र चाहते हैं, और यूज़र ने जो माँगा है उसे ही उनकी ज़रूरत मान लेना भी ठीक नहीं है
भले ही सेल्स टीम कहे कि “अगर X नहीं बनाया तो डील क्लोज़ नहीं होगी”, X बनाने के बाद भी कुछ न बदले ऐसा हो सकता है। वजह यह है कि सेल्स वाला विश्लेषण गलत था
खासकर नए प्रोडक्ट में यूज़र पहले से माँग नहीं करते, इसलिए उन्हें समझाना और दिखाना पड़ता है; “जब कार पहली बार आई होती तो ग्राहक तेज़ घोड़ा माँगते” वाला उदाहरण इसी पर लागू होता है
अगर कोई कुछ माँगे, तो उसके पीछे की वजह खोदनी चाहिए। अगर कोई गैराज में जाकर कहे कि अल्टरनेटर बदल दो और आप वही बदल दें, तो असंतोष रह सकता है; लेकिन “क्यों बदलना है?” पूछने पर पता चले कि समस्या solenoid में थी, और उसे ठीक करने से चल पाने का असली लक्ष्य पूरा हो जाता है
इसलिए कई बार सीनियर डेवलपर प्रोडक्ट मैनेजर से बेहतर प्रोडक्ट समझ दिखाते हैं। 1-2 साल डेवलपमेंट करने के बाद सर्टिफिकेट लेकर प्रोडक्ट रोल में गया व्यक्ति अनुभवी लोगों की गहराई की बराबरी मुश्किल से कर पाता है
मान्यता जो भी हो, बातचीत और गहराई से जाँच के बिना फैसले दूसरे दर्जे के ही बनते हैं
मैं यूज़र रिसर्च के ज़रिए problem domain और feature space समझने के पूरी तरह पक्ष में हूँ, लेकिन व्यवहार में मैंने कार के आविष्कारकों से कहीं ज़्यादा Segway बनाने वाले देखे हैं
अक्सर संस्थापक की अंतर्दृष्टि या खराब यूज़र रिसर्च के आधार पर कुछ बना दिया जाता है, फिर ग्राहक की माँग को “तेज़ घोड़ा” कहकर हल्के में खारिज कर दिया जाता है। मेरे पास इस अतिरिक्त custom workflow के अनुसार ढलने का समय, ऊर्जा या इच्छा नहीं है, जो इस मान्यता पर जोड़ा गया हो कि मुझे अपने काम का क्षेत्र पता नहीं है
B2C और B2B में फर्क होगा, लेकिन यह सलाह जहाँ लागू की जाती है वहाँ यह भेद लगभग कभी नहीं दिखता। मेरा मतलब यह नहीं कि यूज़र फीडबैक को नज़रअंदाज़ करना चाहिए, लेकिन मैंने इसे इसी तरह समझते हुए बहुत बार देखा है, इसलिए अब नई उपमा चाहिए
बेशक इसे ज्यों का त्यों नहीं मानना चाहिए, लेकिन यूज़र से यह पूछने की बजाय कि वे क्या चाहते हैं, उनके व्यवहार को देखना कई बार ज़्यादा गहरी समझ देता है। बस अवलोकन का माहौल इस तरह डिज़ाइन होना चाहिए कि पता चल सके आप क्या सीखना चाहते हैं
जैसे “स्पेसशिप के अंदर चल-फिर सकना चाहिए, और micro-meteor टकराने के बाद hull ठीक करने के लिए spacewalk भी कर सकें”
दूसरी ओर, कंपनियाँ या डेवलपर भी कभी-कभी इस तर्क को ज़रूरत से ज़्यादा लागू करके उन खिलाड़ियों को ही गलत ठहराते हैं जिन्हें उनका गेम पसंद नहीं आता
क्योंकि सेल्स की यूज़र से सबसे ज़्यादा बातचीत होती है, इसलिए प्रोडक्ट मैनेजर आम तौर पर उनकी बात आसानी से मान लेते हैं
ईमेल सपोर्ट बहुत करने पर अक्सर ऐसे मामले दिखते हैं जहाँ XY problem किसी feature request के रूप में छिपा होता है। https://en.m.wikipedia.org/wiki/XY_problem
कोई एक फीचर माँगता है, और आम तौर पर उसे जोड़ना आसान भी होता है, लेकिन पहले मैं मूल समस्या समझने की कोशिश करता हूँ। ग्राहक अक्सर समस्या नहीं बताते, अपना हल बताते हैं, और वह हल खराब तरीका हो सकता है या पूरी तरह गलत भी
किसी फीचर को अच्छे ढंग से जोड़कर डॉक्यूमेंट करना हो ताकि वह दूसरों के भी काम आए, तो यह समझना ज़रूरी है कि वह किस असली पीड़ा को हल कर रहा है
“पीड़ा खोजो और उसे हटाओ” एक ताकतवर सेल्स तकनीक भी है। कभी-कभी फीचर ग्राहक की नहीं बल्कि सेल्स टीम के अंदर की पीड़ा के कारण जोड़ा जाता है, और सिर्फ इसलिए शामिल हो जाता है कि निर्णय लेने वालों को वह महत्वपूर्ण लगता है और demo में अच्छा दिखता है, जबकि असली ग्राहक उसे इस्तेमाल भी नहीं करेंगे
खासकर legacy software replacement के समय हमेशा दबाव होता है कि वह सब कबाड़ भी माइग्रेट किया जाए जिसका अब उपयोग न होने का भरोसा काफ़ी है और जिसे बनाने की लागत उसकी कीमत से ज़्यादा है
उदाहरण के लिए, कुछ बिज़नेस लोग उन रिपोर्टों का generation छोड़ नहीं पाते जिन्हें वास्तव में कोई पढ़ता ही नहीं
लेख अच्छा है, लेकिन शीर्षक सच में पसंद नहीं आया। ग्राहकों से बहुत कुछ पूछना चाहिए, लेकिन उनकी बात को सतही रूप में सच मान लेना बहुत कम करना चाहिए
ग्राहक ने जो फीचर माँगा है उसे जैसा का तैसा बना देना असफलता का सबसे तेज़ रास्ता है, और “मुझे X करने दो” से आगे बढ़कर लगातार सवाल पूछने और गहराई में जाने की ज़रूरत है
निष्पक्ष रूप से देखें तो लेख भी मूलतः यही कह रहा है, लेकिन ऐसे घिसे-पिटे शीर्षक से थक चुका हूँ
Christensen और Deming की सिफारिश से सहमत हूँ, और Sidney Dekker को भी जोड़ना चाहूँगा। खासकर "Field Guide to Human Error" अच्छी है, और उनकी दूसरी किताबें भी शायद अच्छी होंगी
यह जाँचने का सबसे अच्छा तरीका कि समाधान वास्तविक है और ग्राहक को बेचा जा सकता है या नहीं, अक्सर यह पूछना है: “क्या आप इसे अभी खरीदेंगे?” अगर जवाब हो “हाँ, invoice भेजिए और order आगे बढ़ाते हैं”, तो कुछ न कुछ सत्यापित हुआ है
इसके उलट अगर प्रतिक्रिया हो “हम्म, शायद, मैं purchase committee से बात करूँगा”, तो आप अभी भी भटक रहे हैं
भले ही प्रोडक्ट अभी इतना तैयार न हो कि सचमुच बेचा जा सके, Steve Blank के कहे अनुसार आगे यह पूछा जा सकता है: “क्या आप इसके लिए अभी दस लाख डॉलर देंगे?”, “तो कितना देंगे?”, “अगर मुफ़्त दें तो क्या आप इसे तुरंत अपनाएँगे?” ऐसे जवाब बताते हैं कि ग्राहक की नज़र में इसकी असली जगह क्या है
https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
अनुभव से कहूँ तो ग्राहक अक्सर नहीं जानते कि उन्हें क्या चाहिए। इसलिए संस्थापक का यह चाहना स्वाभाविक है कि वह उस समस्या का बेहतर समाधान बनाने वाली कोई चीज़ बनाए
“वैलिडेट करने से पहले मत बनाओ” वाली सलाह मुझे सच में पसंद नहीं है। मेरे लिए यह शाब्दिक रूप से एक बार भी काम नहीं आई, और यह ऐसा है जैसे लीडिंग questions पूछते हुए साथ ही खुद अपने पैर पर कुल्हाड़ी मारना
यह काम आप क्यों कर रहे हैं, इस बारे में विश्वास होना चाहिए। अगर आप ऐसे व्यक्ति हैं जो बिल्कुल अनजान industry में कूद पड़ते हैं, तो असफल होने की संभावना 99% है। अगर आपको पता है कि आप क्या कर रहे हैं, तो सफलता की संभावना 60% से ऊपर होनी चाहिए
ऐसे products बेचना आसान होता है जिनके बारे में लोग पहली नज़र में समझ जाएँ कि वे समस्या हल करते हैं। क्योंकि आपने वही समस्या खुद झेली है और उसे हल करने निकले हैं
इसलिए मुझे लगता है कि कई validation-first sites जानबूझकर समाधान की व्याख्या को अस्पष्ट रखती हैं
मतलब आप खुद ही prototype customer थे
“अगर Henry Ford ने लोगों से पूछा होता कि उन्हें क्या चाहिए, तो वे तेज़ घोड़े माँगते” वाला घिसा-पिटा quote यूँ ही घिसा-पिटा नहीं हुआ। ज़्यादातर लोग नहीं जानते कि उन्हें क्या चाहिए, और इसी वजह से अच्छे product designers को बहुत पैसा मिलता है
फर्क यह समझना है कि product vision क्या है और feedback सुनने का तरीका क्या है
लोगों की समस्याएँ हल करने वाला नया product design करने के लिए कोई जादुई तरकीब नहीं है; यह अनुभव, instinct, तकनीकी समझ, मौजूदा alternatives का अवलोकन, और तकनीकी/आर्थिक/सामाजिक बदलावों का अनुमान—इन सबका मिश्रण है
दूसरी ओर, feedback सुनना इस बात की जाँच है कि जो आपने design किया वह इरादे के मुताबिक काम कर रहा है या नहीं, क्या चीज़ users को confuse कर रही है, और रुकावटें क्या हैं। यहाँ user observation, testing, surveys जैसी पारंपरिक विधियाँ काम आती हैं
यह आसान दिखता है, लेकिन बिल्कुल आसान नहीं है। मैंने बहुत से ऐसे designers देखे हैं जो वास्तविकता उनके ideology से टकराने पर भी अपने principles नहीं मोड़ते, और ऐसी कंपनियाँ भी देखी हैं जो ऐसे bugs को inexplicably ठीक नहीं करतीं जिनसे ज़्यादातर users जूझते हैं और support forums व social media पर गुस्सा निकालते हैं
ये दोनों skills बहुत अलग हैं, और एक में अच्छा होना ही कठिन है, दोनों में अच्छा होना तो और भी मुश्किल। लेख Intuit को उदाहरण बनाता है, लेकिन सरकार पर लॉबिंग करके ज़हर को बनाए रखना और फिर उसका antidote बेचने वाले व्यवसाय में वास्तव में शानदार काम करने की dynamics पाठक पर छोड़ दी जाती है
ग्राहक tax filing की पीड़ा कम करना चाहते हैं, लेकिन Intuit सरकार पर लॉबिंग करता है ताकि वह पीड़ा बनी रहे और तीखी ही रहे
हमारे product का इतिहास इस पूरे spectrum से होकर गुज़रा है
शुरुआत में हमें सिर्फ़ इस बात की चिंता थी कि हमारे ग्राहक banks अपने business को कैसे देखते हैं, और हमारा product उसमें कैसे सुधार ला सकता है। बिना ठीक से जाने कि हम क्या कर रहे हैं, हम ideas जल्दी-जल्दी जोड़ते गए और ग्राहकों की छोटी-छोटी सनकों तक को पूरा करने में लगे रहे। हमें लगता था कि हम उनके business के लायक ही नहीं हैं
बीच के चरण में results आने लगे, और हमें समझ आया कि अगर product को 10 से ज़्यादा ग्राहकों में हर एक की अलग-अलग पसंद के हिसाब से ढालने लगो, तो अंत में कुछ नहीं बचता
अब हमारा product किसी खास software या technology से ज़्यादा एक turnkey consulting package जैसा है। ग्राहक अब हमसे यह guidance माँगते हैं कि अपना business कैसे चलाएँ। जब आप इस तरह बस चलाने लगते हैं, तो software stack को standardize करना कहीं ज़्यादा आत्मविश्वास से कर सकते हैं। हाल में “boring” शब्द भी हमारी vocabulary में आ गया है
हमारे customer base की दिलचस्प बात यह है कि उनमें झुंड की तरह चलने की प्रवृत्ति बहुत मज़बूत है। अगर आप कुछ संस्थानों को किसी खास दिशा में बढ़ा दें, तो बाकी लगभग बिना मेहनत के पीछे आ जाते हैं। मुझे नहीं लगता कि यह सिर्फ़ risk-averse bankers पर लागू होता है
लेख में छूटा हुआ एक आम जाल है आवाज़ ऊँची रखने वाले अल्पसंख्यक ग्राहकों की बात सुनना
अगर आपने सिर्फ़ Hacker News या दूसरे tech-friendly platforms पढ़े होते, तो यह मान लेना असामान्य नहीं होता कि छोटे screen size और अच्छी performance वाले iPhone की बहुत भारी माँग है
हक़ीक़त में iPhone mini की sales निराशाजनक रहीं। इसका मतलब है कि tech hardware पर लंबे समय तक ऑनलाइन लिखने वाले लोग पूरे iPhone customer base का प्रतिनिधित्व नहीं करते
अनुपात कम होने का मतलब यह नहीं कि shipment volume कम था
वास्तविकता में, आप चाहे जो भी company बनाएँ, उसके iPhone Mini से कहीं कम units बेचने की संभावना है। तो क्या Apple के मानक से बिक्री निराशाजनक होने पर कंपनी को कर्मचारियों को निकालकर दिवालिया हो जाना चाहिए? क्या 2 करोड़ से कम बेचने वाली हर company बंद कर देनी चाहिए? क्या छोटे iPhone के shipment से छोटे customer base को target करने वाली कंपनियाँ अस्तित्व में ही न रहें और उनकी जगह औसत लोगों के लिए औसत products ले लें? क्या Mac Studio, XDR display, और 15-inch 4,000-dollar MacBook भी गायब हो जाने चाहिए?
मैं कुछ ऐसे लोगों को जानता हूँ जो iPhone mini से बहुत संतुष्ट हैं, और अब उनके पास upgrade करने के लिए कुछ नहीं है। फिर भी यह वाला विकल्प सस्ता है
अगर लोग अपनी समस्याएँ खुद हल करना जानते, तो वे पैसे नहीं देते
computer पर कुछ काम करने के लिए थोड़ी बहुत technical ability ज़रूर चाहिए, लेकिन ज़्यादातर चीज़ें rules follow करके और Excel का रचनात्मक उपयोग करके हल की जा सकती हैं
असली value इस बात में है कि आप लोगों को समस्या सुलझाने के लिए एक framework दें, उन edge cases के बारे में भी उनके लिए सोचें जिनके बारे में उन्होंने सोचा नहीं, और फिर उस rule system को program में compile कर दें
मज़ेदार बात यह है कि ग्राहकों से यह पूछना कि वे क्या नहीं चाहते, वास्तव में अच्छी तरह काम करता है
ग्राहकों से यह पूछना कि वे क्या चाहते हैं, committee-based design जैसा है। लोग असल में जो चाहते हैं, वह किसी एक कलाकार की बनाई हुई, अच्छी तरह व्यवस्थित और internally consistent vision होती है, बस उसमें से कुछ चीज़ें हटा दी गई हों