- एक startup ने engineers को सीधे sales calls में शामिल कराया, और इससे product development का तरीका बुनियादी रूप से बदल गया
- sales calls के दौरान उन्होंने जाना कि competitor products non-technical users के लिए बहुत जटिल हैं, और customers logs/metrics से ज़्यादा यह दिखाने वाला confirmation mark (green check) चाहते हैं कि monitoring काम कर रही है, साथ ही वे बस यह पूछते हैं: “क्या कोई इसे हमारे लिए कर नहीं सकता?”
- इससे backend-केंद्रित team ने user perspective को समझना शुरू किया, और PM के हस्तक्षेप के बिना ही नई architecture की कल्पना करने लगी
- सिर्फ 2 हफ़्तों में platform की 60% functionality घटाई गई, progress दिखाने के लिए progress bar जोड़ा गया, Slack integration बनाया गया, और done-for-you workflow feature तैयार किया गया; नतीजतन support tickets 70% कम हो गए
- इस अनुभव से मिला सबक यह था कि users सिर्फ अपनी समस्या का समाधान चाहते हैं, elegant code में उनकी रुचि नहीं होती, और features code की मात्रा नहीं बल्कि user confusion की लागत पैदा करते हैं
पृष्ठभूमि और प्रयोग
- एक senior DevOps engineer sales calls में शामिल होने के ख़िलाफ़ था, लेकिन कम-से-कम 5 calls आज़माने की शर्त पर मान गया
- founder का मानना था कि जब तक engineers सीधे customers की भाषा और समस्याएँ नहीं सुनेंगे, product design नहीं बदलेगा
sales calls से मिले insights
- लोगों ने कहा कि competitor products non-technical users के लिए बहुत जटिल हैं
- customers जटिल metrics से ज़्यादा एक सरल green checkmark जैसी सहज पुष्टि चाहते थे
- कई customers ने “managed service” की माँग की, यानी वे सिर्फ tool इस्तेमाल नहीं करना चाहते थे बल्कि समस्या-समाधान को outsource करना चाहते थे
product rewrite का परिणाम
- team ने मौजूदा features का 60% हटा दिया और essential functionality पर फ़ोकस किया
- एक सरल progress bar जोड़कर user experience बेहतर किया गया
- Slack integration के ज़रिए inquiry flow को आसान बनाया गया
- Done-for-you workflow देकर customer की माँग को सीधे product में शामिल किया गया
- अंततः support tickets 70% कम हुए, और product usability व satisfaction में बड़ा सुधार हुआ
मुख्य सीख
- users elegant technical solution नहीं, बल्कि अपनी समस्या का समाधान चाहते हैं
- technical accuracy से ज़्यादा user understanding महत्वपूर्ण है
- हर feature code नहीं, बल्कि user confusion की लागत भी साथ लाता है
team culture में बदलाव
- इसके बाद company ने हर engineer के लिए हर quarter में 5 sales calls में भाग लेना अनिवार्य कर दिया
- engineers सीधे customers की थकान और “बस यह ठीक से काम करे” जैसी माँगें सुनकर बेहतर product instinct विकसित करें—यह company culture का हिस्सा बन गया
Reddit टिप्पणियों का मुख्य सार
- PM role पर बहस
- कुछ लोगों ने कहा कि असली समस्या अच्छे Product Manager की कमी थी, और engineers से customer calls करवाना अप्रभावी है
- वहीं जवाब में यह भी कहा गया कि “PM अक्सर सिर्फ translator बनकर रह जाता है, जबकि सबसे अच्छे नतीजे तब आते हैं जब engineers खुद customer problem की ownership लेते हैं”
- customer touchpoint की अहमियत
- कई टिप्पणियों में ज़ोर दिया गया कि engineers के लिए सीधे users की आवाज़ सुनने का अनुभव बहुत शक्तिशाली insight देता है
- यह राय भी आई कि शुरुआती-stage startups या छोटी teams में engineers अक्सर PM की भूमिका का कुछ हिस्सा निभाते हैं
- आलोचनात्मक नज़रिया
- कुछ ने आलोचना की कि “यह बस leadership/culture की विफलता engineers पर थोपने जैसा है”
- यह सवाल भी उठा कि “क्या features हटाकर और चीज़ों को सरल बनाकर ही वास्तविक सुधार हो जाता है?”, और लंबी अवधि में power users तथा advanced feature demands की अनदेखी के ख़तरे की चेतावनी दी गई
- सकारात्मक अनुभव साझा किए गए
- banking, medical devices जैसे कई industries से लोगों ने बताया कि वहाँ भी सभी कर्मचारियों को customer support या sales का अनुभव कराया जाता था
- “Dogfooding” या “सीधे customer के सामने खड़े होने” का अनुभव product quality और culture दोनों के लिए फ़ायदेमंद माना गया
- समग्र निष्कर्ष
- customer problems को सीधे महसूस कराना सीखने का एक बेहद शक्तिशाली साधन है,
- लेकिन लंबी अवधि में इसे professional PM, UX, और design capabilities के साथ जोड़ना ज़रूरी है, ताकि संतुलित product strategy बन सके
अभी कोई टिप्पणी नहीं है.