अपने ग्राहकों से पूछना कि वे क्या चाहते हैं, काम नहीं करता
Product builders argue that directly implementing customer feature requests often backfires, because users typically describe their own imagined solutions rather than the underlying problems they need solved. Instead, commenters advocate approaches like “jobs to be done,” observing real behavior, probing for root pains, and validating willingness to pay, while warning against over-indexing on loud minorities, internal politics, or sales-driven one-off demands. The core tension is between respecting user input and exercising strong product vision to create solutions customers will actually adopt and pay for.
“ग्राहकों से पूछो कि वे क्या चाहते हैं” की सीमाएँ
- कई लोग तर्क देते हैं कि ग्राहक अक्सर वही समाधान बताते हैं जो उनके पास पहले से होता है, न कि वह जो वास्तव में मदद करेगा।
- अनुरोध अक्सर परस्पर विरोधी या एक-दूसरे को नकारने वाले होते हैं; लोग समझौतों को तभी समझते हैं जब उनसे विस्तार से पूछा जाए।
- मुखर अल्पसंख्यक कथित मांग को विकृत कर सकते हैं (जैसे, छोटे फोन, जेब वाली ड्रेसेज़)।
- कुछ लोगों के अनुसार, यह शीर्षक-धारणा वैध उपयोगकर्ता आवश्यकताओं को अनदेखा करने के बहाने के रूप में अत्यधिक इस्तेमाल की जाती है।
समस्याओं / Jobs-to-be-Done पर ध्यान
- यह पूछने के लिए मजबूत समर्थन है: “आप कौन-सी समस्या हल कर रहे हैं?” या “इस प्रोडक्ट को आप किस काम के लिए hire कर रहे हैं?”
- मिल्कशेक और commute की कहानियाँ: “प्रोडक्ट” में सुधार तभी समझ में आया जब असली काम (ड्राइव करते समय आसान नाश्ता, कम यात्रा समय) समझा गया।
- यही नजरिया AirPods, Segway बनाम scooters, कारें बनाम “तेज़ घोड़े” पर भी लागू किया गया।
अवलोकन बनाम सीधे सवाल पूछना
- उपयोगकर्ताओं को काम करते हुए देखना (screen recordings, shadowing, support standups) self-reported इच्छाओं की तुलना में अधिक खुलासा करने वाला माना जाता है।
- XY problem: उपयोगकर्ता अपना सुझाया हुआ समाधान बताते हैं; आपको अंदर तक जाकर मूल दर्द खोजना होता है।
- हालांकि, कुछ लोग शिकायत करते हैं कि अत्यधिक उत्साही “आपको वास्तव में X नहीं चाहिए” वाले जवाब तब बहुत चिढ़ा सकते हैं जब X वास्तव में अच्छी तरह सोचा गया हो।
Product Vision बनाम Feedback
- यह अंतर खींचा गया कि:
- Visionary product creation (intuition, prior research, timing).
- Iterative refinement (usability tests, bug fixes, confused flows).
- touchscreen phones जैसे उदाहरण दिखाते हैं कि बताई गई पसंदों के खिलाफ जाना सफल हो सकता है यदि समग्र अनुभव बेहतर हो, हालांकि गलतियाँ (no apps/3G/copy-paste) दिखाती हैं कि vision भी त्रुटिपूर्ण होती है।
Validation, MVPs, और Experiments
- कुछ लोग जोर देते हैं: “validate किए बिना build मत करो”; दूसरे कहते हैं कि उनका सबसे अच्छा काम पहले अपनी known problem के लिए build करने से आया।
- Validation का मतलब हो सकता है: दर्दनाक समस्या की मौजूदगी, जोड़े-तोड़कर बनाए गए user solutions, paid commitments, या full implementation से पहले तेज़ low-cost experiments (manual workflows, quick toggles)।
Enterprise/B2B जटिलताएँ
- Buyer ≠ user: features केवल procurement, compliance, या checklists (जैसे, SAML/SSO) को संतुष्ट करने के लिए मौजूद हो सकती हैं, भले ही वे शायद ही कभी इस्तेमाल होती हों।
- Sales-driven feature demands (“X के बिना deal close नहीं होगा”) आम हैं; कभी-कभी उचित, अक्सर गलत, और लंबे समय की maintenance में महँगे।
सामान्य निष्कर्ष
- व्यापक रूप से सुनें, लेकिन बात को ज्यों का त्यों सच न मानें; literal implementation के बजाय synthesis करें।
- पूछें कि उपयोगकर्ता क्या करना चाहते हैं, वे क्या नहीं चाहते, और वे वास्तव में किसके लिए भुगतान करेंगे।
- अपने खुद के product के वास्तविक user होना बार-बार एक शक्तिशाली compass के रूप में cited किया जाता है।