Product manager की भूमिका एक गलती है
(sollecitom.github.io)- अगर कोई software product company product-led को “ऐसी संरचना जिसमें PM सारे फैसले ले” के रूप में गलत समझती है, तो वह ऐसे मॉडल को, जो केवल असाधारण founder-जैसे leaders के लिए काम करता है, साधारण career PMs पर लागू कर देती है
- किसी एक leader को product का control देना अपने आप में मुद्दा नहीं है; असली बात यह है कि यह जिम्मेदारी किसे दी जा रही है, और यह मॉडल vision, charisma, technical skill और मजबूत conviction वाले दुर्लभ लोगों को मानकर चलता है
- जब साधारण PMs को जरूरत से ज्यादा authority दे दी जाती है, तो data, frameworks, approval processes, meetings और role structures निर्णय के tools नहीं रह जाते, बल्कि जवाबदेही से बचने और politics की ढाल बन जाते हैं
- इस तरह का रुझान बेहतरीन लोगों को बाहर कर देता है, और company कम-जोखिम वाले कामों और internal process में फँसकर vision और talent खो देती है
- इसका विकल्प PM title-केंद्रित संरचना नहीं, बल्कि हर क्षेत्र में technology और quality को लेकर जुनूनी लोगों को एक टीम में लाना है, ताकि वे product discovery, observability, engineering, design, business और domain knowledge को साथ में संभालें
product-led को PM-एकाधिकार संरचना मानने की समस्या
- कई software product companies में founder ऐसा व्यक्ति होता है जो software product बनाने के गहरे अनुभव से ज्यादा fundraising और target industry की समझ में मजबूत होता है
- ऐसे founders industry experience और relationships के आधार पर company शुरू करते हैं, लेकिन अगर वे हर निर्णय खुद चलाते हैं, तो domain expert के रूप में उनका confidence company के लिए नुकसानदेह हो सकता है
- कुछ founders मान लेते हैं कि वे खुद जोखिम बन सकते हैं, और निर्णय लेने के लिए किसी और को hire करते हैं
- यहीं यह गलतफहमी पैदा होती है कि “हमें service organization नहीं बल्कि product company होना चाहिए, और product company product-led होती है, इसलिए PM को जिम्मेदारी लेनी चाहिए”
- यहाँ product-led का मतलब यह नहीं है कि PM सारे फैसले ले
- जब कोई असहमति जताता है, तो अक्सर जवाब दिया जाता है कि Amazon, Apple, Tesla जैसी महान companies भी control एक व्यक्ति को सौंपती हैं
- कई बेहतरीन companies सचमुच किसी एक व्यक्ति को control देती हैं, लेकिन हर महान company यही model अपनाती हो, ऐसा नहीं है
एकल निर्णयकर्ता मॉडल की पूर्वशर्तें
- company का control एक व्यक्ति को देने वाला model अपने आप में गलत नहीं है; इसकी सफलता या विफलता काफी हद तक किसे control दिया गया है इस पर निर्भर करती है
- Picasso, Jeff Bezos, Mozart, Steve Jobs, Nikola Tesla, Elon Musk, Robert Oppenheimer, Peter Thiel, Leonardo जैसे लोगों को vision, charisma, confidence, resilience और excellence के कारण लगभग पूजा जैसा सम्मान मिला
- ऐसे लोग वैकल्पिक वास्तविकताओं की कल्पना करते हैं, अपने काम में पूरी तरह डूब जाते हैं, और अपनी इच्छाशक्ति से बड़े बदलाव ला देते हैं
- अगर ऐसा व्यक्ति वास्तव में मौजूद हो, तो single-control model बहुत शक्तिशाली ढंग से काम कर सकता है
असाधारण व्यक्ति सामान्य PM नहीं होता
- महान लोग product manager नहीं थे
- वे artist, mathematician, inventor, scientist, CEO थे, और कई बार एक साथ कई भूमिकाएँ निभाते थे
- वे OKR, KPI, data या दूसरों की राय से ज्यादा अपने vision और craft को लेकर जुनूनी थे
- असाधारण लोगों में प्रबल राय, बड़ा ego, अपना अलग तरीका, rough edges और सामान्यपन के प्रति तिरस्कार हो सकता है
- इन गुणों की वजह से उन्हें सामान्य company में hire करना मुश्किल होता है, और संभव है कि वे भी ज्यादातर companies में काम करना न चाहें
- अगर आप किसी महान व्यक्ति को ढूँढ सकें, उसे बाधित न करें, और उसकी तीव्रता को सह सकें, तो आप उसे product और company का control दे सकते हैं
- लेकिन व्यवहार में ऐसे लोगों को ढूँढना कठिन है; और अगर मिल भी जाएँ, तो हो सकता है वे साथ काम करना न चाहें, या company उनके ego और intensity को सह न पाए
जब साधारण PM पर महान व्यक्ति वाला ढाँचा लागू किया जाता है
- सबसे बड़ी गलती यह है कि असाधारण व्यक्ति के लिए बने operating model को असाधारण व्यक्ति के बिना लागू कर दिया जाए
- आलोचना यह है कि जिन career PMs को company आराम से hire कर सकती है, वे आम तौर पर उस स्तर के लोग नहीं होते
- उन्हें business minion, framework fanatic, subject-matter expert, corporate ladder चढ़े हुए ex-makers, metrics addict, MBA graduate जैसी श्रेणियों में रखा जाता है
- अगर product-led को “PM सारे फैसले ले” समझकर career PM hire किए जाएँ, तो यह विनाशकारी हो सकता है
- इन PMs में vision, charisma, expertise, मजबूत conviction और technical ability की कमी होती है, इसलिए वे safe खेलते हैं और political ढंग से काम करते हैं
- अपनी सीमाएँ जानने के कारण वे बार-बार ऐसा व्यवहार करते हैं जिसमें credit ले लिया जाए और blame से बचा जाए
जब data और process बचाव के हथियार बन जाते हैं
- पहला चरण है data-driven decision-making का weaponization
- यह मानने के बजाय कि लगभग किसी भी दावे के समर्थन में data मिल सकता है, वे अपने फैसले को ही data के नाम पर rational साबित करते हैं
- अगर चीजें गलत हो जाएँ, तो market, data quality या company की bad luck को दोष दिया जाता है, और कहा जाता है कि इसमें उनकी जिम्मेदारी नहीं थी
- अगला चरण है हर चीज में framework और role जोड़ देना
- 18-step career framework, quarterly performance review, PI planning, ADR, PRD, RACI, MOSCOW, OKR, KPI, DORA, SAFe जैसी चीजें सामने आती हैं
- “process follow नहीं किया”, “data-driven नहीं है”, “documentation कम है”, “docs up to date नहीं हैं” जैसी बातें दोषारोपण का आधार बनती हैं
- organization में Director of KPIs, Deputy Director of Product Operations, Global Head of Digital Whiteboard Solutions जैसे roles पैदा हो जाते हैं
- हर चीज के लिए approval चाहिए होने लगता है, और कोई भी व्यक्ति किसी process या domain पर पूरी तरह control नहीं रख पाता
- बड़ी committees में हर कोई “no” कह सकता है, लेकिन कोई भी पूरी तरह “yes” नहीं कह सकता
- meetings भी विस्फोटक रूप से बढ़ जाती हैं
- status reports, alignment meetings, 1:1s, staff meetings, strategy discussions, context-setting, release go/no-go, project reports सब बढ़ने लगते हैं
- अंतिम चरण है बहुत से गलत लोगों को hire करना
- hiring का मानदंड यह बन जाता है कि कोई व्यक्ति threatening तो नहीं है, और excellence के संकेत rejection का कारण बन जाते हैं
- आदर्श candidate वह माना जाता है जो बिना असहमति या quality की चिंता के, दिए गए काम को किसी तरह पूरा कर दे
- PMs की संख्या तेजी से बढ़ती है, और teams व domains में PM की परतें बन जाती हैं जो वही व्यवहार दोहराती हैं
organization क्या खो देती है
- जैसे ही साधारण लोगों के हाथ authority जाने लगती है, बेहतरीन लोग अंततः चले जाते हैं
- या तो उन्हें किसी साधारण तानाशाह द्वारा बाहर कर दिया जाता है, या माहौल सहन न होने पर वे खुद निकल जाते हैं
- काम की गति रुक जाती है, और कुछ भी execute करना पीड़ादायक, भारी commitment और जोखिमभरा प्रयास बन जाता है
- बड़े vision को अवास्तविक मानकर जल्दी छोड़ दिया जाता है
- company का काम low-hanging fruit और safe choices तक सीमित हो जाता है
- जो लोग अपने craft के प्रति बहुत passionate नहीं भी होते, वे भी पीड़ा महसूस करके चले जाते हैं; और जो लोग इतनी सुन्नता के साथ टिके रहते हैं, वे समस्या और बढ़ा देते हैं
- company अपने सर्वोत्तम talent को खो देती है, vision भूल जाती है, अंदरमुखी हो जाती है, और अर्थहीन बन जाती है
- सबसे अच्छे मामले में वह किसी बिंदु पर मर जाती है; सबसे बुरे मामले में वह आधे-अधूरे survival state में passionate लोगों को अपनी ही नौकरी से नफरत करने वाले zombies में बदल देती है
विकल्प है रोजमर्रा के असाधारण लोगों की टीम
- किसी असाधारण व्यक्ति को ढूँढना, hire करना, control देना और उसकी तीव्रता सहना ही सफल product company बनाने का एकमात्र तरीका नहीं है
- विकल्प है रोजमर्रा के असाधारण लोगों को hire करना
- हर व्यक्ति किसी न किसी क्षेत्र में उत्कृष्ट होना चाहिए
- उसे अपने craft के प्रति जुनूनी और quality से संचालित होना चाहिए
- team इस तरह बननी चाहिए कि एक-दूसरे के उत्कृष्टता वाले क्षेत्रों में न्यूनतम overlap हो
- व्यक्तिगत जिम्मेदारियों को बहुत छोटे हिस्सों में बाँटने के बजाय, ऐसे लोगों को वह काम आनंद से करने देना चाहिए जिसे वे पसंद करते हैं, ताकि वे company को अपना समय और skill दें
- ऐसे लोग भी challenging, जिद्दी, ego वाले, विचित्र और mood-driven हो सकते हैं
- लेकिन अगर उन्हें अच्छे problems दिए जाएँ और शानदार काम करने दिया जाए, तो वे company की सफलता के लिए पूरी तरह committed हो जाते हैं
leaders और PMs की सही जगह
- leaders को पूरी तरह छोड़ना जरूरी नहीं है; team leads को हटाकर domain leads को external-internal coordinators के रूप में रखा जा सकता है
- अगर हर domain में accountable leader रखना है, तो उस role में महान व्यक्ति के अधिक निकट लोगों को बैठाना चाहिए
- यानी ऐसे लोग जो vision, charisma, intensity, passion और extreme behavior के स्तर पर Jobs, Musk, Bezos के ज्यादा करीब हों
- अगर अल्पकालिक सुविधा के लिए ऐसे व्यक्ति को जिम्मेदारी दे दी जाए जो compliant हो, निर्देश अच्छे से माने और कम attention माँगे, तो ऊपर बताए गए हालात में फँसने का खतरा है
- पारंपरिक अर्थ में PM role के लिए, लेखक के अनुसार, अच्छी तरह चलने वाली company में कोई जगह नहीं है
- फिर भी product discovery, product observability जैसी वे चीजें जिनकी जिम्मेदारी परंपरागत रूप से PMs को दी जाती रही है, उनके प्रति जुनूनी लोग जरूरी हैं
- हो सकता है ऐसे लोगों के पास PM title रहा हो, और इसमें अपने आप में कोई समस्या नहीं है
- उन्हें hire करने का कारण उनका title नहीं, बल्कि उनका obsession और strength होना चाहिए
- उन्हें अलग PM function में रखने के बजाय engineering, design, performance, business और domain knowledge को लेकर जुनूनी लोगों के साथ एक ही team में रखना चाहिए
यह सिर्फ PMs की समस्या नहीं है
- अगर vision, charisma, passion, technical ability और willpower के बिना कोई भी व्यक्ति जिम्मेदार role में आ जाए, तो यही समस्याएँ पैदा होंगी
- PMs पर फोकस इसलिए है क्योंकि software product development में product manager title वाले लोगों को जिम्मेदारी देने की प्रवृत्ति ज्यादा दिखाई देती है
- कुछ PMs सचमुच असाधारण होते हैं, और दोनों models में बहुत अच्छा कर सकते हैं
- लेकिन यह जरूरी नहीं कि ऐसे PMs, अलग background वाले दूसरे महान लोगों से बेहतर ही हों
- ऐसे PMs बहुत ही छोटा अल्पसंख्यक समूह हैं, और अधिकांश career PMs excellence के बल पर lead करने की क्षमता के आसपास भी नहीं पहुँचते
1 टिप्पणियां
Hacker News की राय
मौजूदा कंपनी में बहुत सारे स्मार्ट लोग हैं, लेकिन कई वजहों से product manager नहीं हैं, और नतीजा यह है कि product manager को जो काम करने चाहिए, वे बस होते ही नहीं
ग्राहक संबंध बनाए रखना, user interviews करना, संभावित features ढूँढना, leadership को मनाना, resources के allocation के लिए राजनीति जैसी चीज़ें—ऐसे काम करना चाहने वाले engineers बहुत कम हैं
पिछली कंपनी में 3 product managers में से 2 अयोग्य थे और निकाल दिए गए, लेकिन 1 सचमुच बेहतरीन था, और उसके समय के सिर्फ़ एक हिस्से से ही उसने 1 साल में उतना कर दिखाया जितना मौजूदा कंपनी 2 साल से ज़्यादा में भी नहीं कर पाई
मैं इस बात से सहमत हूँ कि अच्छे product managers पर्याप्त नहीं हैं. मेरे हिसाब से अच्छे product manager बनने वालों की संख्या आबादी के साथ linear रूप से बढ़ती है, लेकिन software industry exponential रूप से फटकर बढ़ी है, इसलिए असल में बेहतरीन PMs की तुलना में 100 गुना ज़्यादा PM roles की ज़रूरत हो गई है
वे technical भी नहीं थे, इसलिए Jira tickets manage नहीं करते थे, और leadership management आम तौर पर managers ही संभालते थे
वे product managers मुख्य रूप से meetings करते, leadership से बात करते, engineers से बात करते, documents लिखते, और लंबे होते sprint planning meetings की अध्यक्षता करते लगते थे
अगर product manager ग्राहक, user और resource से जुड़े मुद्दे संभालता हो, तो वह कहीं ज़्यादा valuable हो सकता है
मुझे बार-बार कहा गया, “हम engineering-first company हैं”, लेकिन असल में इसका मतलब था कि engineering teams अपनी मर्ज़ी से सिर्फ़ latest technology के पीछे भागती रहीं
मुख्य products 3.5 हैं, असल में 4.5, और हर एक अलग tech stack पर बना है; legacy requirements के कारण करीब 8 और products को support भी करना पड़ता है. Products के बीच कोई standardization या interoperability नहीं है, knowledge transfer भी नहीं होता, इसलिए development cost आसमान छू रही है
इस साल दो बार, मुझे 20 साल से काम कर रहे engineers को समझाना पड़ा कि कोई API सिर्फ़ TLS 1.3 इस्तेमाल करे, दूसरा 1.x हो, और तीसरे में TLS तक की requirement न हो—यह बुरा क्यों है
ग्राहक हमसे नफ़रत करते हैं. मेरे product के लिए marketing material पहले लिख दिया गया और engineers से कहा गया कि वे अपने-आप बना लें. Oracle data को parquet में ले जाने के एक step को तीन languages और दो intermediate DBs (MySQL और PG) से बनाया गया था, और Redis भी डालने की कोशिश को मैंने मुश्किल से रोका
शुक्र है, 2 साल पहले private equity ने acquisition किया और अब ultimatum मिला है कि अगर पैसा नहीं कमाया तो खत्म. यह 20 साल पुरानी कंपनी एक cost center थी जिसने कभी पैसा नहीं कमाया, और अगर हम targets चूक भी जाएँ, तो हमारे बनाए हुए software design disaster के गायब हो जाने से ब्रह्मांड शायद बेहतर हो जाएगा
मूर्ख product manager एक pseudo project manager बन जाता है जो बस एक और work ledger track करता है, और समझदार व्यक्ति business को गहराई से समझकर या तो promote हो जाता है या चला जाता है
इस role को govern करना भी मुश्किल है. कभी-कभी दूसरे के काम का बड़ा credit मिल जाता है, और कभी कोई credit नहीं मिलता, जिससे career अटक जाता है
अगर इस role को engineering, engineering management या general management पर डाल दिया जाए, तो engineering capability कमजोर हो जाती है. अगर engineers hire करने हैं, तो उसी capability के आधार पर selection करना चाहिए और उन्हें बाहरी लोगों से protect करना चाहिए; लेकिन अगर team को interactions भी संभालने पड़ें, तो आप mixed capabilities वाले लोगों को hire करने लगते हैं और अंततः engineering वाला पक्ष dilute हो जाता है
Product manager की capacity को जानबूझकर tight रखना उच्च स्तर और vision पर focus कराने वाला हो सकता है, और बहुत गहराई में जाकर बेकार processes बनाने या features को ज़रूरत से ज़्यादा define करने से बचाने वाला forcing mechanism बन सकता है
10 साल से ज़्यादा समय तक low-interest-rate growth से फूली हुई tech industry में, बहुत से लोगों के लिए बस office आना भी सफल होने के लिए काफी था
यह लेख उलझा हुआ है। यह कहते हुए भी कि “PM भूमिका खत्म कर देनी चाहिए”, यह कहता है कि “PM जो काम करता था, उसके लिए समर्पित व्यक्ति की अब भी जरूरत है, लेकिन उसे PM न कहें, बस सामान्य रूप से असाधारण व्यक्ति कहें”
लगता है लेखक का PM के साथ खराब अनुभव रहा है, और MBA वाली बातों में उसकी झलक दिखती है; इसलिए वे शायद बच्चे को भी नहाने के पानी के साथ फेंक देना चाहते हैं
बिजनेस का आकार बढ़ने पर भूमिकाओं में specialization आता है और उसकी जरूरत पड़ती है। खराब PM भी होते हैं और यह मुश्किल काम है, लेकिन अगर हमारी टीम अपना PM खो दे, तो मुझे सच में निराशा होगी
हो सकता है मैंने PMs के साथ सिर्फ अच्छे अनुभव ही किए हों, लेकिन हमारी कंपनी के PMs यह समझते हैं कि ग्राहक क्या चाहते हैं और प्रोडक्ट को क्या देना चाहिए, और engineering manager के साथ मिलकर तकनीकी रूप से क्या संभव है और implementation की क्षमता कितनी है, इसका संतुलन बनाते हैं
जब engineering manager कहता है, “इस timeline में यह बिल्कुल नहीं हो सकता”, तो PM प्रोडक्ट के लिए वैकल्पिक योजना ढूंढ निकालता है
यह लेख बीच का चरण छोड़कर बस बिना वजह सिर्फ नाम बदलने की कोशिश जैसा दिखता है
टीम को किन problems को priority देनी चाहिए, यह ठीक-ठीक कौन तय करेगा? यही तो PM भूमिका की मुख्य जिम्मेदारी है
आखिरकार लगता है कि उनका किसी ऐसे PM के साथ खराब अनुभव रहा है जो priority तय नहीं कर पाया
हालांकि उसी व्यक्ति की वजह से मुझे अपनी सबसे अजीब बैठकों में से एक में शामिल होना पड़ा, जहां उसने पूरे एक घंटे, शुरू से आखिर तक, senior manager के सामने यह जाहिर कर दिया कि वह प्रोडक्ट को बिल्कुल नहीं समझता, जबकि वह senior manager प्रोडक्ट को समझता था
अच्छे PMs यह समझकर बहुत मदद करते हैं कि ग्राहक क्या चाहते हैं, हम क्या दे सकते हैं, realistic schedule क्या है, और legal व business stakeholders से कैसे निपटना है। जब उन्हें technical side verify करनी होती है, तो मैं उनकी मदद करता हूं
टीमों में बनाने के ideas या product/operations experience सुधारने के तरीकों की कमी कम ही होती है। product manager वह व्यक्ति है जो सही चीज बनवाने की कोशिश करता है
मैं IT में 20 साल के experience वाला PM हूं, और knowledge व formal business understanding पाने और आगे बढ़ने में मदद के लिए MBA पर विचार कर रहा हूं
मेरे जैसे PMs MBA लेते ही, सैन्य भाषा उधार लें तो, फालतू खेल शुरू नहीं कर देते
समस्या उन लोगों से है जो सीधे high school, college, MBA और management role में चले जाते हैं। undergraduate के बीच की छोटी internship को छोड़ दें तो अक्सर उनके पास field experience का एक दिन भी नहीं होता
अजीब लेख है। बहुत बातें की गई हैं, लेकिन आखिरकार बात शायद यही है कि “low performer को hire करना कंपनी के लिए नुकसानदेह है”
विकल्प भी कुछ ऐसा है कि “अच्छे लोगों को hire करो, लेकिन PM role के लिए मत hire करो”
यह किसी ऐसे व्यक्ति का लेख लगता है जिसका किसी ऐसे PM के साथ खराब अनुभव रहा जो खुद को Steve Jobs समझता था। PM भी बस आम इंसान ही होते हैं; समझ नहीं आता कि यह मानकर क्यों चला गया है कि इस title वाले सभी लोग entitlement वाले इंसान हैं
किसी organization में हजारों PM हो सकते हैं और हर एक का अपना boss होता है। बस अजीब लेख है
“product managers को hire मत करो, क्योंकि वे महान लोग नहीं होंगे। इसके बजाय महान लोगों को hire करो, वह भी सिर्फ एक नहीं बल्कि पूरी team!” कुछ ऐसा ही है
वे रोज low performers hire करते हैं और पता नहीं क्यों। resumes के ढेर के साथ कोई untrained chimpanzee शायद बेहतर hit rate दे दे
PM एक बहुत specific जरूरत पूरी करता है। उस जरूरत को quantify करना मुश्किल है, लेकिन अच्छे PM के बिना सब कुछ टूट सकता है
आम तौर पर वे users से यह जानकारी जुटाते हैं कि क्या काम करता है और क्या नहीं, executives से सुनते हैं कि company चलाने के लिए क्या चाहिए, industry leaders से समझते हैं कि industry किधर जा रही है, design के साथ काम करते हैं, और इन सबको ऐसे features में refine करते हैं जिन्हें सच में बनाना है
वे engineering के साथ मिलकर यह भी समझते हैं कि क्या practical है, लगभग कितना समय लगेगा, ज्यादा समय लेने वाले लेकिन कम value वाले features हटाते हैं, और estimates व team velocity को कुछ हद तक predictable बनाने में मदद करते हैं
यह अपने आप में 1.5 लोगों का काम बताने जैसा है। product organization हटाने पर यह सब काम engineering team में बंट जाता है, लेकिन team के सभी लोग इसमें अच्छे नहीं होते
भले ही संतुलन बन जाए, अगर एक व्यक्ति चला गया, तो hiring में जिस चीज को आप ढूंढ ही नहीं रहे थे, उसकी अदृश्य खाली जगह बन जाती है
लगता है कई teams dysfunctional product organization से जल चुकी हैं। ऐसे organizations customer, industry और organization side से कटे हुए या उसमें uninterested लगते हैं, और इसके बजाय mockups दोहराने वाली meetings में बेहिसाब समय जलाते हैं, designers को micromanage करके अच्छे लोगों को छोड़ने पर मजबूर करते हैं, और engineers को अनावश्यक product meetings में बांधे रखते हैं
PM team के साथ निकटता से काम करते हुए roadmap define करता है और उन कामों को prioritize करता है जिनका customers और business पर सबसे बड़ा impact होगा
अगर PM अपना काम अच्छी तरह करता है, तो engineers को बहुत साफ समझ आ जाता है कि आगे कौन-सी problem solve करनी है और क्यों करनी है
दूसरा, यह भी अहम है कि project के बारे में senior leadership से communicate करने के लिए संगठन में उसका stature है या नहीं। अगर दोनों attributes हैं, तो स्थिति अच्छी है
टेक इंडस्ट्री में 12 साल से ज़्यादा काम करके मैंने यह सीखा है कि भूमिकाएँ सिर्फ़ संगठन की इच्छाओं को व्यक्त करने का तरीका हैं
अगर आप चाहते हैं कि कोई product की तरह सोचे, तो आप PM position खोलते हैं; अगर team lead चाहिए, तो engineering manager position बनाते हैं
job title काल्पनिक तत्व हैं, जो हमें काम नाम के RPG को अलग-अलग कोणों से खेलने देते हैं। अंततः workplace पर हम अपनी प्रतिभा और अनुभवों का अनोखा संयोजन ही लेकर जाते हैं
कुछ लोग अक्सर इन role boundaries को पार कर जाते हैं, और यह ठीक है। उनके पास ideas होते हैं और वे अपना खुद का title भी गढ़ सकते हैं
संगठन इतने समझदार होने चाहिए कि ऐसे लोगों को बढ़ने और फलने-फूलने दें। इसका मतलब यह नहीं कि आप PM के रूप में सफल नहीं हो सकते या शानदार काम नहीं कर सकते; मतलब यह है कि आम तौर पर संगठन शामिल किए जा रहे व्यक्ति को गहराई से समझने में पर्याप्त समय नहीं लगाते, इसलिए वे पहले से पकी-पकाई भूमिका दे देते हैं
engineer भी PM की भूमिका निभा सकता है, लेकिन वह हर चीज़ को PM के नज़रिए से नहीं सोचेगा। क्योंकि उसकी मुख्य identity PM नहीं, engineer है
role boundaries पार करने के संदर्भ में एक और बात समझ आई कि अक्सर किसी व्यक्ति की भूमिका का सबसे मूल्यवान हिस्सा वे responsibilities होती हैं जो स्पष्ट रूप से define नहीं होतीं
समझाना मुश्किल है, लेकिन लोग अक्सर ऐसे तरीकों से value देते हैं जिन्हें बयान करना या quantify करना मुश्किल होता है
कुल मिलाकर यह काफ़ी harsh नज़रिया है, लेकिन इसमें कुछ बातें निश्चित रूप से सही हैं। कंपनी के अंदर product organization बनते ही, जैसा लेखक ने बताया है, यह committees, OKR, review cycles, planning और बहुत सारी bureaucracy की तरफ़ बहने लगता है
पहले मैं customer-facing sales engineering role में influence के ज़रिए product को बहुत सफलतापूर्वक आगे बढ़ा रहा था, और यह सोचकर कि मुझे formal control मिल जाएगा, भोलेपन में product manager की job ले ली
जब उस सीट पर बैठा, तो वह बेहद constrained office job निकली और मेरे लिए बिल्कुल fit नहीं थी। ज़्यादातर काम tickets और backlog manage करना, decisions लेने के बजाय coordination करना, और अंतहीन PowerPoint reports बनाना था; सबसे creative काम यह था कि कंपनी product roadmap को formalize करने के लिए process बनाए। 6 महीने में भाग निकला
यह function क्या बनाया जा रहा है इसकी visibility देने और बढ़ते product की टकराती priorities manage करने में काफ़ी उपयोगी है। लेकिन यह product किस दिशा में evolve होगा, उसे shape या control करने का काम नहीं है
यह sorting, filtering और किस्मत अच्छी हो तो data collection function है; साथ ही audit हो सकने वाली decision trail और mature decision-making का impression बनाता है, ताकि ऊपर बैठे MBA लोग थोड़ा चैन से सो सकें
आम तौर पर महीने में 4–12 नए feature proposals (PRD) बनाता था; संख्या company size और ज़रूरी process की मात्रा पर निर्भर करती थी
format हमेशा ऐसा होता था: “users को अभी X समस्या है, और इसे हल करने के लिए हमें Y बनाना चाहिए। Y ऐसा दिखता है…”
बेशक coordination और communication की कठिनाइयाँ होती हैं, लेकिन यह हमेशा यह पता लगाने के लिए था कि आगे क्या बनाना है
मैं समझता हूँ कि हर PM role ऐसा नहीं होता, लेकिन इस बात से सहमत नहीं कि PM “alignment/filtering/decision maturity का नाटक” से बेहतर नहीं हो सकता
अगर role सिर्फ़ existing backlog को क्रम में लगाने का था, तो मुझे जिज्ञासा है कि backlog में नए items कौन define करता था
मैं सहमत हूँ कि product organization supporter के बजाय political और bureaucratic entity बन सकता है
निजी तौर पर मेरा मानना है कि product roles को engineering team के भीतर embedded होना चाहिए और उसी leader को report करना चाहिए। level पर debate हो सकती है, लेकिन इससे bad PM को भी bad engineer की तरह handle किया जा सकता है
बेशक अगर company bad engineers को भी निकाल नहीं पाती, तो वह अलग समस्या है
लेखक इसके लिए कोई ख़ास framework नहीं देता
लेख के solution में great man theory की बू आती है
आख़िरी हिस्सा कि “अद्भुत लोग alternative realities की कल्पना करते हैं, काम के लिए पूरी तरह committed होते हैं, और willpower से पहाड़ हिला देते हैं” बहुत reductive है
पहाड़ willpower से नहीं हिलते, बल्कि नीचे के वे लोग हिलाते हैं जो vision को वास्तव में implement करते हैं। ज़्यादा से ज़्यादा वह “महान व्यक्ति” actual executors और experts को चलाने के लिए incentives align करता है
मैं अभी एक बड़ी tech company में काम करता हूँ जहाँ PM roles लगभग नहीं हैं, इसलिए सीधे अनुभव से बता सकता हूँ
अब तक अनुभव mixed है। मैंने PM-heavy organizations में भी काम किया है और सहमत हूँ कि वे अच्छे नहीं होते। लेकिन अंततः PM वाला काम फिर भी ज़रूरी रहता है
हमारे organization में यह responsibility formal रूप से software managers और senior या उससे ऊपर के developers पर आती है
उदाहरण के लिए, senior engineer के तौर पर अगर आप team initiative lead करते हैं, तो PM की सारी activities की responsibility आपको लेनी पड़ती है। बाकी activities manager या senior manager लेते हैं
developer के नज़रिए से यह काफ़ी कठिन है। individual contributor के रूप में अपना काम भी करना होता है, और दूसरों को coordinate करके यह सुनिश्चित भी करना होता है कि काम पूरा हो
यह सिर्फ़ extra work नहीं है; सच कहूँ तो बहुत से developers के पास effective PM बनने की skills नहीं होतीं। reporting chain अलग रखने वाले लोगों को coordinate करना पड़ता है, इसलिए cross-team collaboration भी मुश्किल हो जाता है
यह तरीका अक्सर ownership की कमी, accountability की कमी, duplicated effort, cracks में गिर जाने वाले काम, और overall disorder की ओर ले जाता है
हालांकि कुछ लोगों वाली छोटी team-internal initiatives में यह अच्छी तरह काम करता है। क्योंकि यह PM overhead हटाता है और control उन लोगों को देता है जो चीज़ें बना रहे हैं। लेकिन बड़े initiatives के लिए भी यह सही है या नहीं, मुझे यक़ीन नहीं
यह सही है कि बहुत से developers के पास effective PM skills नहीं होतीं, लेकिन fairness में कहें तो बहुत से PMs के पास भी effective PM skills नहीं होतीं
अलग reporting chain वाले लोगों के साथ coordinate करने की मुश्किल PMs के लिए भी वैसी ही है
मुख्य अंतर शायद इस judgement में है कि “क्या इस काम को dedicated role में अलग करना worthwhile है।” मेरा झुकाव है कि engineers के लिए यह लगभग हमेशा worthwhile नहीं होता
सिर्फ़ शीर्षक देखकर ही नापसंद करने के लिए तैयार हो गया था। लगा था कि यह वही टिपिकल “PM बेवकूफ़ होते हैं और कंपनी में बस दुनिया पर राज करने वाले स्मार्ट engineers ही होने चाहिए” वाला लेख होगा
लेकिन यह वैसा लेख नहीं था, और मुझे लगता है कि इसने समस्या को लगभग बिल्कुल सही पकड़ा है
हालांकि समाधान हाथ हिलाते ही गायब हो जाता है। कुछ इस तरह: “ऐसे सामान्य रूप से महान लोगों को hire करो जो अपने-अपने काम में अच्छे हों, अपनी craft को लेकर जुनूनी हों, quality से driven हों, उन्हें टीम में बाँधो और बिना व्यक्तिगत जवाबदेही के काम करने दो”
सुनने में अच्छा लगता है, लेकिन असल में 100+ लोगों वाली कंपनी में इस तरीके के सफल होने का उदाहरण कौन दे सकता है? समझ नहीं आता कि यह वास्तविक दुनिया में कैसे काम कर सकता है
Valve शायद बहुत मिलते-जुलते तरीके से काम करता है, या कम-से-कम करता था। उनका employee handbook[0] पहले HN पर अक्सर दिखता था, लेकिन आजकल ज़्यादा नहीं दिखता। जिज्ञासा है कि क्या यह उनके लिए अच्छे से काम कर रहा है
[0] https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployee...
लेखक ने सचमुच औसत product managers के साथ काम किया लगता है। मैं self-taught engineering background वाला PM हूँ, और कई क्षेत्रों में बहुत सारे औसत लोगों को देखा है
मैं अपने काम को मुख्य रूप से risk management मानता हूँ। बेहतरीन engineers और designers की टीम भी एक अच्छा product launch करने की प्रक्रिया में कई risks का सामना करती है
हो सकता है उनके पास vision समझाकर दूसरों को मनाने की skill न हो, और legal team क्या कर सकती है और क्या नहीं, इस पर requirements या constraints लगा सकती है
मेरा काम उन चीज़ों को manage करना है ताकि टीम की strengths सामने आएँ, और टीम वास्तव में महत्वपूर्ण काम—अच्छा product बनाना और launch करना—पर focus कर सके
सफलता को मैं इस बात से मापता हूँ कि मैं कितना गैर-ज़रूरी हो गया हूँ। लक्ष्य है कि मेरी ज़रूरत न रहे, टीम के पास मेरे बिना भी अच्छे decisions लेने के लिए context, confidence और support हो
मुझे engineers के साथ मिलकर उनमें यह क्षमता विकसित करने में मज़ा आता है, और engineering manager partners के साथ हर engineer की strengths, weaknesses और goals समझकर उनके growth के तरीके खोजता हूँ
मैं यह तर्क भी समझता हूँ कि किसी आदर्श utopia में शायद मेरी ज़रूरत न हो। लेकिन ज़्यादातर मामलों में सचमुच शानदार काम करने के लिए challenges और risks से टकराना पड़ता है, और अच्छा PM टीम के साथ collaborate करके उन्हें पार कराने वाला net value adder होता है
टीम के पास अपना best work करने के लिए ज़रूरी context, requirements, insights, metrics, goals वगैरह हों, और वे समझें कि कौन-सी समस्या किसके लिए और क्यों हल करनी है
अच्छा PM ऐसा environment बना देता है कि engineer सोचने लगे, “PM तो कुछ करता ही नहीं, इसलिए इसकी ज़रूरत नहीं।” ऐसा निष्कर्ष short-sighted है और सच कहूँ तो अपमानजनक भी