जब सभी engineers को sales calls करने के लिए मजबूर किया गया, तो 2 हफ़्तों में platform पूरी तरह दोबारा लिखा गया

 (old.reddit.com)
22 पॉइंट द्वारा GN⁺ 2025-08-23 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • एक 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 बन सके

संबंधित पढ़ाई

5 टिप्पणियां

 
meteorizer 2025-08-25

आखिरकार यह efficiency का ही मुद्दा है।
ग्राहकों के साथ सीधे समन्वय करने के सच में कई फायदे हैं, लेकिन
मीटिंग और फोन जैसी बार-बार होने वाली बातचीत की वजह से काम की continuity अक्सर टूट जाती है और development में लगाने के लिए समय कम हो जाता है।
ऐसी स्थिति में कंपनी को घटी हुई productivity से निपटने के लिए hiring plan बनाना चाहिए।
समस्या यह है कि आम तौर पर ऐसा करने का इरादा नहीं होता।
आखिरकार समय की कमी के कारण, जैसे-जैसे वक्त बीतेगा, quality गिरने की संभावना बढ़ती जाएगी।
मुझे लगता है कि इसके फायदे और नुकसान, दोनों पर अच्छी तरह विचार करना चाहिए।
 
laeyoung 2025-08-24

मुझे ठीक से समझ नहीं आया कि इसे Hacker News पर old reddit लिंक के रूप में क्यों छोड़ा गया, लेकिन मौजूदा reddit UI का रास्ता यहाँ है।
 
xguru 2025-08-24

लगता है Hacker News पर Reddit URL पोस्ट करते समय ज़्यादातर लोग old reddit का इस्तेमाल करते हैं। शायद इसलिए, क्योंकि यह हल्का भी है।
 
cnaa97 2025-08-23

अगर किसी संगठन का लक्ष्य न्यूनतम स्तर को ऊपर उठाना है, तो यह मानना ठीक है कि केवल web frontend developers वाली टीम या app developers टीम जैसी role-based organization उपयुक्त है.

लेकिन जिन टीमों या संगठनों का लक्ष्य उच्चतम स्तर हासिल करना है, उनके लिए role-based organization में बनना अनिवार्य रूप से सीमित होता है.
जैसा कि मूल लेख में कहा गया है, क्या सचमुच planner, designer, PM और engineer को अपने-अपने अलग काम लेकर, किसी फैक्टरी की conveyor belt की तरह काम करना चाहिए? यही सवाल उठता है. कुछ तयशुदा जिम्मेदारियां लेकर काम करने वाली पारंपरिक "in-charge" शैली के बजाय, अलग-अलग क्षेत्रों में specialty रखने वाले सदस्य इकट्ठा हों, साझा लक्ष्य साथ मिलकर तय करें, और पूरी टीम एक-दूसरे को support करे — यही आदर्श है.

कई कंपनियों में spin-off, team composition आदि के लिए task force के रूप में संगठन बनाए जाते हैं, लेकिन वहां भी सिर्फ लोगों (roles) को एक साथ बांध देने से नकारात्मक reinforcement पैदा हो सकती है — जैसे, "मैं कुछ करने की कोशिश कर रहा हूं, लेकिन कंपनी मदद नहीं कर रही, तो छोड़ देता हूं" जैसी प्रवृत्ति. इससे key members जैसे महत्वपूर्ण प्रतिभाशाली लोग ही खो सकते हैं. इसलिए purpose-based organization को भी role-based organization के सक्रिय support की जरूर जरूरत होती है.
 
GN⁺ 2025-08-23
Hacker News राय
  • अंत में, उन्होंने मेरे “PMing” के बिना ही पूरी तरह नई architecture की कल्पना कर ली। वजह यह थी कि उन्हें आखिरकार ठीक से समझ आ गया कि हमारे product को वास्तव में इस्तेमाल कौन करता है। इस पूरे अनुभव को देखें तो निष्कर्ष यह है: “जब engineers को sales calls पर लगाया गया, तो असल समस्या यह निकली कि PMs customers और engineering के बीच ठीक से communication नहीं करा रहे थे, और DevOps engineer ही वह व्यक्ति निकला जो customer needs को जल्दी से काम करने वाले solution में बदल पा रहा था”
    • कभी-कभी engineer इतना आत्मविश्वास से भरा होता है कि उसे लगता है user ही product का गलत इस्तेमाल कर रहा है। यानी समस्या “user बेवकूफी कर रहा है” वाली है, मेरे बनाए जटिल design में कोई कमी नहीं। Desktop Linux समुदाय के लोग तो user complaints को नज़रअंदाज़ करने के अनुभव पर पूरी किताब लिख सकते हैं। अगर ज़िद्दी engineer को लगता है कि वह PM और users दोनों से बेहतर जानता है, तो कुछ आगे नहीं बढ़ता। लेकिन ऐसे engineer को सीधे users के सामने बैठा दो, तो आम तौर पर दोस्ताना PM की जगह, सच में चिढ़े हुए users इस “शानदार रचना” की ऐसी आलोचना करते हैं जैसे यह कोई समस्याग्रस्त hamster हो। यह प्रक्रिया डरावनी भी होती है और engineer का ego भी तोड़ देती है। मेरी नज़र में यह PM को बेवकूफ साबित करने की बात नहीं, बल्कि engineer को विनम्र बनाने की बात है। समय के साथ engineers का घमंड फिर लौट आता है, इसलिए यह प्रक्रिया बार-बार ज़रूरी होती है
    • मैं एक बड़ी कंपनी की mechanical engineering team में अकेला ऐसा व्यक्ति हूँ जो code लिख सकता है। इन-house IT team कई तरह का software खुद बनाती है, लेकिन हमारी team के ज़्यादातर लोगों को वह खास पसंद नहीं आता। इसलिए मैं या तो उसे फिर से बनाता हूँ, या ऐसे “कमज़ोर” program को सहारा देने वाले tools खुद बना लेता हूँ जिनका सीधा replacement संभव नहीं। मेरा मानना यह नहीं कि मैं in-house IT team से बेहतर developer हूँ, बल्कि यह कि actual user होने के कारण मुझे बेहतर समझ है कि मुझे, यानी हमारी team को, सच में क्या चाहिए। और क्योंकि यह software मैं खुद इस्तेमाल करता हूँ, इसलिए motivation भी स्वाभाविक रूप से ज़्यादा है। इसीलिए इस पोस्ट का title मुझे relatable लगा। हाँ, post में कही गई बात भी real world में आसानी से हो सकती है। मैं formal software development/project management processes से बहुत परिचित नहीं हूँ
    • मैं 2 million dollar annual revenue वाला एक छोटा tech startup चला रहा हूँ। कभी-कभी जब support staff कम पड़ता है, तो मैं खुद कुछ दिनों के लिए customer support संभालता हूँ। हर बार मुझे हैरानी होती है कि customer complaints की ढेर सारी बातें मिलती हैं जो आम तौर पर engineering team तक पहुँचती ही नहीं। Support staff अक्सर problems को अपने स्तर पर “solve” करने पर ज़्यादा ध्यान देता है, इसलिए मूल सुधार engineering तक पहुँच ही नहीं पाता
    • यह ध्यान देने लायक है कि software शुरू से इतना बुरा क्यों था, इसमें किसी ने दिलचस्पी नहीं ली। मेरे हिसाब से सारा दोष एक PM पर नहीं डाला जा सकता। असल में यह system की समस्या है, जहाँ Agile/Scrum जैसी चीज़ों में जवाबदेही धुंधली हो जाती है और developers जल्दी-जल्दी poorly defined tickets निपटाते रहते हैं, जिसके कारण ऐसा अधपका software बनता है। “Modern” software organizations के फूले हुए ढाँचे का यह आम नतीजा है
    • यह पढ़कर मेरा पहला विचार था, “PMs के हर चीज़ में दखल देने से पहले software ऐसे ही बनता था।” अगर engineer को actual operator के पास बैठा दिया जाए, तो अक्सर PM की ज़रूरत ही नहीं पड़ती और सब लोग ज़्यादा खुश होते हैं। हाँ, कुछ PM वाकई शानदार होते हैं, लेकिन मेरे अनुभव में PMs अक्सर territory battle में फँसे रहते हैं, और हैरानी की बात यह है कि कई बार उन्हें engineering या customers, दोनों में से किसी की भी गहरी समझ नहीं होती
  • मैंने कई जगह engineers को product से out of sync होते देखा है। कोई teammate चुपके से कुछ जोड़ देता है, फिर UI confusing हो जाता है, या website की content actual product से मेल नहीं खाती। और [product -> PM -> bug tracking system -> engineer -> fix -> QA -> product] जैसे लंबे loop की वजह से ज़रूरी चीज़ें तो ठीक हो जाती हैं, लेकिन छोटी-छोटी परेशानियाँ बहुत लंबे समय तक बनी रहती हैं। अगर सिर्फ [product <-> engineer] रह जाए, तो productivity हैरान करने वाले स्तर तक बढ़ सकती है। बहुत से engineers ने वास्तव में पूरे product experience को खुद कभी end-to-end इस्तेमाल भी नहीं किया होता, और उन्हें यह भी ठीक से पता नहीं होता कि इस साल और पिछले साल में क्या बदला है
    • मेरा अनुभव भी ऐसा ही रहा है, और दिलचस्प बात यह है कि जहाँ PMs ज़्यादा थे, वहाँ यह समस्या और ज़्यादा दिखी। मेरा सबसे खराब अनुभव एक ऐसी कंपनी में था जहाँ PM और “Product Designer” की headcount engineers के अनुपात में ज़बरदस्ती तय करने की कोशिश की गई। Designers, product, project, और program roles को जोड़ दें तो वे engineers से भी ज़्यादा थे। नतीजा सिर्फ और बदतर निकला। PMs की bureaucracy और इस डर से बचते रहना भी एक काम था कि वे मेरी भूमिका में दखल न दें। शानदार PMs सचमुच क़ीमती होते हैं, लेकिन आजकल Product Management का title ऐसे लोगों से भर गया लगता है जो bureaucracy और process के प्रति ज़रूरत से ज़्यादा आसक्त हैं। Product Management influencers भी समस्या को और बढ़ा रहे हैं
    • फिर भी, मैं यह नहीं मानता कि engineers को ज़बरदस्ती sales calls पर भेजना सही जवाब है। एक call को सफलतापूर्वक चलाने के लिए कई तरह की soft skills चाहिए होती हैं, और engineers न तो उस दिशा में trained होते हैं, न hiring में यह प्राथमिकता होती है। (यहाँ ‘sales call’ से मतलब demo या PoC से पहले की शुरुआती consultation call है। जटिल pre-sales demos में engineer साथ जा सकता है, लेकिन सिद्धांततः वह भूमिका product side को निभानी चाहिए)
    • चीज़ें गलत जाने के बहुत सारे तरीके हैं, और मैंने लगभग सब देखे हैं। जैसे, PM या PO का customer communication पर पूरा कब्ज़ा कर लेना; या customer का developer से बात करने से बचना और सिर्फ user manager की requirements की व्याख्या करके आगे भेजना; या developer का खुद केवल code ही लिखना चाहना; या हर communication को PM और bug tracker के माध्यम से ही करना अनिवार्य बना देना। Commercial software platforms इस्तेमाल करने पर technical limitations की वजह से workflow बहुत खराब भी हो सकता है। कहीं-न-कहीं communication को रोकने वाला कोई factor हमेशा होता है, और customer, middle manager, या developer—कोई भी उसमें रुकावट बन सकता है। कई बार तो गलत solution पहले ही तय कर दिया जाता है, और developers या users को details का पता भी नहीं होता। ऐसा बहुत कम नहीं है। users के लिए सच में अच्छा system न बना पाने के रास्ते बहुत हैं
    • मुझे लगता है कि engineers का product को गहराई से समझना बेहद ज़रूरी है। बुनियादी engineering से भी ज़्यादा कठिन चीज़ product fit को सही बैठाना है। मेरे अनुभव में ज़्यादातर products अंततः product-related कारणों से fail हुए हैं, इसलिए team की ताकत उसी दिशा में लगाना ज़्यादा तार्किक लगता है
  • दूसरी तरफ, कई बार engineer धीरे-धीरे technical support team की भूमिका में गिर जाता है। अगर आप हर customer account को सीधे support करने लगें, तो hotfixes और bespoke solutions का ढेर लग जाता है। इन सबका ठीक से testing भी नहीं हो पाता, technical debt बढ़ता जाता है, और जैसे ही कोई बड़ी, अच्छी funding वाली competitor कंपनी बेहतर product बना देती है, आप जल्दी पीछे छूट जाते हैं। मेरे हिसाब से यह classic product management failure है। यानी PM customer needs को engineers तक ठीक से नहीं पहुँचा पा रहा, या उल्टा pushback भी नहीं दे पा रहा। engineers को sales calls में डालना एक ऐसा तरीका है जो customer base के बढ़ने और mature होने पर scale नहीं करता। अगर कोई product manager सच में चाहता है कि engineer sales calls करे, तो fairness के लिए उस engineer को account commission का हिस्सा भी मिलना चाहिए। मैं commission के बिना sales calls कभी नहीं करूँगा
  • Startup जैसी जगहों पर, जहाँ हर team member के लिए customer needs के प्रति गहरी empathy ज़रूरी होती है, यह बहुत शानदार strategy है। जब मैं product requirements को वास्तव में define करने की प्रक्रिया में शामिल होता था और day-to-day कामकाज की वास्तविकता को अच्छे से समझता था, तब project success rate बहुत ऊँचा होता था। इसके मुकाबले जब requirements सिर्फ “मुझे सौंप” दी जाती थीं और मैं उन्हें वैसा ही implement करता था, तो परिणाम उतने अच्छे नहीं होते थे
    • क्या आपका मतलब यह है कि क्योंकि आपने खुद guidelines लिखी थीं, इसलिए उन्हें follow करना आसान था, या यह कि सीधे शामिल होने से बेहतर UX निकला? यह जानने की जिज्ञासा है
  • “2 हफ्तों में rewrite पूरा, 60% features हटाए, एक simple progress bar जोड़ा, Slack integration बनाया, ‘done-for-you’ workflow दिया → support tickets 70% घट गए” अगर यह सच है, तो कहीं न कहीं बहुत गंभीर गड़बड़ी थी
    • Reddit अपने creative writing की बाढ़ के लिए मशहूर है, और यह कहानी भी—चाहे किसी real घटना से प्रेरित हो या पूरी तरह गढ़ी हुई हो—पूरी तरह typical Reddit writing और LinkedIn-style business storytelling जैसी लगती है
    • यह मुझे ऐसा B2B SaaS product लगता है जिसने कई pivots देखे, लेकिन product guidance बहुत कमज़ोर रही। वैसे, इस तरह चीज़ों का उलझ जाना जितना लोग सोचते हैं उससे कहीं ज़्यादा आम है
    • LinkedIn-style छोटे वाक्य और हर बार dramatic ending वाला टोन देखकर आसानी से समझा जा सकता है कि यह fiction है
    • Reddit है, तो जाहिर है fiction ही होगा। समझ नहीं आता कि ऐसी पोस्ट कभी-कभी इतना traction क्यों पा लेती हैं
  • अगर नतीजा ऐसा निकला, तो PM, PO, और marketing team—सबको तुरंत निकाल देना चाहिए। दो बातें साफ़ हैं: पहली, या तो उन्हें पता ही नहीं था कि customers वास्तव में क्या चाहते हैं, या वे वह ज़रूरत development team तक ठीक से पहुँचा नहीं पाए, या दोनों। दूसरी, उनका दिमाग इतना systems-oriented हो चुका था कि शायद customer और development team के बीच के सारे intermediate layers हटा देना बेहतर रहता
  • मेरी पिछली नौकरी में भी engineers नियमित रूप से sales calls में शामिल होते थे। यह देखना दिलचस्प था कि अलग-अलग customers क्या चाहते हैं और हमारा product कैसे बेचा जाता है, लेकिन यह कोई game changer नहीं था। जिस feature की customers को ज़रूरत थी, वह पहले से roadmap में था, और एक confusing feature भी था, लेकिन वह हमारे सबसे बड़े customer की specific requirement की वजह से वैसा design किया गया था। Development team उसे और simple बनाना चाहती थी, लेकिन ऐसा करने पर बड़े customer की ज़रूरत पूरी नहीं होती। आख़िरकार एक अलग, इस्तेमाल में आसान “lite” version बनाया गया, जिसे बड़े customer को छोड़कर बाकी सभी इस्तेमाल कर सकते थे। लेकिन यह बदलाव भी sales calls में engineers के जाने की वजह से नहीं हुआ; सबको शुरू से पता था कि चीज़ें मुश्किल हैं, बस roadmap में आने तक उन्हें बदला नहीं जा सकता था
  • “उन्हें आखिरकार यह समझ आ गया कि actual users कौन हैं”—इस हिस्से से मैं गहराई से सहमत हूँ। लोग कहते हैं, “ज़्यादातर engineers की सबसे बड़ी समस्या overengineering है,” लेकिन असल में बहुत बार overengineering इसलिए होती है क्योंकि customer use case को ठीक से समझा ही नहीं गया होता। यही अधिक मूल समस्या है। एक engineer के रूप में मेरी सबसे आम निराशा यह रही है कि दूसरे engineers यह समझने की कोशिश ही नहीं करते कि वास्तव में बिकने वाला product क्या है। कारण job fit हो सकता है, ego हो सकता है, लेकिन अक्सर उसके पीछे organizational culture या incentive structure होता है
  • मैं पहले एक ऐसी कंपनी में था जो CRM के लिए robocall solution बनाती थी। एक offsite event में उन्होंने सबको खुद cold calls करने और script के मुताबिक बोलने को कहा। non-sales staff पर इसका क्या anxiety effect होगा, इसकी उन्हें न समझ थी न परवाह। उसी घटना के बाद मैंने नौकरी बदलने के बारे में गंभीरता से सोचना शुरू किया
  • मैंने पहले एक बहुत मिलती-जुलती स्थिति देखी है। Monitoring team ज़िद कर रही थी कि “हर alert को frontline engineer खुद ticket के रूप में दर्ज करे।” लेकिन alerts की संख्या 10,000 प्रति घंटा से भी ज़्यादा थी। अहम issues इस ‘noise’ में दब जाते थे, management थक गया था, और आखिर एक बार monitoring team को मजबूर किया गया कि “तुम खुद सारे tickets खोलो और solve करके दिखाओ।” अगले ही दिन low-priority alarms हटाने के बाद unique alerts घटकर प्रति घंटा सिर्फ़ दर्जन भर रह गए, और बाकी भी क्रम से बंद होने लगे। तभी पहली बार “board पूरा green” वास्तव में सच हुआ (उससे पहले तो media और Gartner Group को दिखाने के लिए बस ऊपर-ऊपर green paint किया जाता था)