उत्पाद बढ़ रहे हैं, लेकिन Product Managers घट रहे हैं
(kitemaker.co)- Product teams में कितने PM रखने चाहिए इस पर चर्चा Airbnb के product management संगठन के पुनर्गठन और बिना PM के बढ़ रहे startups के उदाहरणों के बाद और तेज़ हो गई है
- PM की संख्या बढ़ने पर ऐसी संरचना बन सकती है जिसमें समय product के business outcomes के बजाय project management और roadmap updates पर खर्च होने लगे
- अनुभवी designers और engineers वाली teams में PM का काम ज़रूरी नहीं कि full-time हो; प्रति team 1 PM वाला model भी स्थिति के हिसाब से फिर से देखना चाहिए
- पहला PM hire करने पर तब विचार किया जाता है जब founder के लिए सभी प्रमुख product decisions में शामिल रहना मुश्किल होने लगे—आम तौर पर 50–100 लोगों के आकार और 3–5 product teams के स्तर पर
- सिर्फ PM की संख्या बढ़ाने से संगठन product-led नहीं बनता; उल्टा, इससे designers और engineers में होनी चाहिए वाली product ownership कमजोर पड़ सकती है
PM घटाकर product responsibility को व्यापक करने वाली संरचना
- PM की ज़रूरत वाली headcount पर चर्चा Airbnb के product management संगठन के पुनर्गठन और बिना PM के भी बढ़ रहे startups के उदाहरणों पर लिखे लेखों के बाद और सक्रिय हुई
- कई कंपनियों में PM अक्सर product को business के हिसाब से optimize करने के बजाय अपना दिन project management, roadmap updates जैसे कामों में भर देते हैं
- सामान्य तौर पर product teams की संख्या से PM की संख्या कम होनी चाहिए, और हर team में 1 PM रखने वाली संरचना को product और team की स्थिति के हिसाब से फिर से देखना चाहिए
- अगर product work बहुत है और team junior है, तो एक team के लिए dedicated PM की ज़रूरत हो सकती है
- अनुभवी engineers और designers वाली team में PM role का full-time होना ज़रूरी नहीं, या कभी-कभी ऐसा होना ठीक नहीं हो सकता
- Startup में पहला PM hire करने का सही समय वह है जब founder के लिए सभी महत्वपूर्ण product decisions में शामिल रहना मुश्किल हो जाए
- आम तौर पर benchmark तब होता है जब संगठन का आकार 50–100 लोग और product teams 3–5 हों
- पूरी product strategy पहले से स्पष्ट होनी चाहिए, और PM को उसी strategy के आधार पर lower-level direction और decisions में भाग लेना चाहिए
- पहले PM के लिए junior PM या CPO की तुलना में senior PM अधिक उपयुक्त है
- candidate संगठन के बढ़ने के साथ CPO role ले सकता है, लेकिन founder को व्यवहार में product owner की भूमिका निभाते रहना चाहिए
Product-focused team बनाने के practical तरीके
- Product responsibility किसी एक PM पर केंद्रित नहीं होनी चाहिए; design और engineering को भी users और product context को सीधे समझना चाहिए
- Designers और engineers को product shaping में सक्रिय रूप से भाग लेना चाहिए और detailed product discussions को lead करना चाहिए
- PM को UX, wireframes, progress tracking, standups चलाने, PRD/specs का अकेला लेखक नहीं बनना चाहिए
- PM का focus product vision को व्यक्त करना, सही problems चुनना, product direction बनाए रखना और business needs के साथ alignment होना चाहिए
- Michael Seibel की “Guide to product development” Social Cam में इस तरीके को लागू करने के उदाहरण से जुड़ती है
- Team को context और निर्णय के आधार सक्रिय रूप से share करने चाहिए
- Design और engineering को भी user feedback तक access मिलना चाहिए
- Problem-solving PM-centric नहीं, बल्कि product, design और engineering का collaboration होना चाहिए
- Product-oriented team बनाने के practical तरीकों को चार बिंदुओं में समेटा जा सकता है
- साथ में शुरुआत करना: tickets या specs लिखने से पहले, solution तय करने से पहले, design·engineering·product/founder साथ चर्चा करके execution approach और plan को align करें
- सभी को users से expose करना: user research और usability testing में सीधे शामिल कराएं, या video streaming, Lookback जैसे tools से users को product इस्तेमाल करते हुए देखने दें
- Team management के तरीके पर ध्यान देना: अगर performance को बंद किए गए tickets की संख्या या story points से मापा जाए, तो team अच्छे product के बजाय ticket processing के हिसाब से चलने लगती है
- PM tools का इस्तेमाल न करना: अगर user feedback, insights, data, specs, roadmap अलग PM tools में बंद हो जाएं, तो पूरी team के लिए product context तक पहुंचना मुश्किल हो जाता है
- Product development स्वभाव से predict करना मुश्किल है, और deployment itself से अधिक महत्वपूर्ण है business पर असर डालने वाली सही चीज़ deploy करना
- बड़ी product-focused कंपनियों में PM बहुत महत्वपूर्ण होते हैं, लेकिन कितने PM चाहिए इसका आकलन आसानी से जरूरत से ज्यादा हो सकता है; PM की संख्या बढ़ना सीधे product focus बढ़ने में तब्दील नहीं होता
1 टिप्पणियां
Hacker News रायें
इंजीनियरिंग मैनेजर या functional organization head के रूप में product managers के साथ काफी लंबे समय तक काम किया है, और एक mid-sized tech company में internal product के interim PM की भूमिका भी निभाई है
मुझे लगता है कि product management कंपनी के कामों में सबसे अहम क्षेत्रों में से एक है। लेकिन यह काम सचमुच कठिन है, और जिन PMs में क्षमता कम होती है, वे इससे दूर हटकर engineering team को “lead” करने के नाम पर micromanagement या अंदरूनी राजनीति में बहक जाना आसान समझते हैं
जिन संगठनों में engineering और product organizations अलग-अलग command chains में बंटी होती हैं, वहाँ इस समस्या से निपटना मुश्किल होता है, और समस्या को ऊपर escalate करने पर भी उस तरफ की bandwidth स्वाभाविक रूप से बहुत सीमित होती है। EM के नज़रिए से, ऐसे PMs अक्सर बेहतरीन engineers को परेशान कर देते हैं, और आखिरकार वे छोड़कर चले जाते हैं
अभी मुझे सबसे अच्छा तरीका यह लगता है कि हर team में mini-CEO जैसे PM रखे जाएँ, और अगर वे तकनीकी रूप से पर्याप्त मजबूत नहीं हैं तो उन्हें mini-CTO के साथ pair किया जाए। इससे राजनीति के लिए जगह बहुत कम हो जाती है और teamwork की गुंजाइश बहुत बढ़ जाती है
जिन सबसे सफल teams में मैं रहा, उनमें dedicated product role नहीं था, और सारे फैसले developers लेते थे
अब मुझे लगता है कि developers को शांति से बनाने देने के लिए non-technical लोगों और आधे-अधूरे technical लोगों को भी developers के रास्ते से हटाना ही सबसे अच्छा है
मुझे तो लोग अपने विकल्पों के पक्ष में दलील देते और support जुटाते दिखते हैं। जिस राजनीति की लोग शिकायत करते हैं, वह मैंने नहीं देखी। शायद मैं भाग्यशाली हूँ
क्या राजनीति का मतलब वह व्यक्ति है जो तकनीकी रूप से गलत है लेकिन अपनी बात ज्यादा convincing तरीके से रखता है? “राजनीति” क्या है? या फिर क्या मैं अभी भी पर्याप्त ऊँचे पद पर नहीं हूँ, senior principal होने के बावजूद
इस लेख और इस विषय का विश्लेषण करने की कोशिश कर रहे बहुत से लोग एक मुख्य तत्व चूक रहे हैं। वह है incentives
कई developers technology itself—यानी coding, जटिल technical problems हल करने, और efficient solutions बनाने—के प्रति ज्यादा passionate होते हैं। promotion, bonus, recognition जैसे formal rewards भी अक्सर technical achievements से जुड़े होते हैं
अगर कोई developer customer research पर 40 घंटे लगाता है, तो हो सकता है कि उसे उतनी formal recognition या reward न मिले जितना पूरी team की मदद करने वाला नया authentication solution विकसित करने जैसे technical achievement पर मिलता
इस dynamic को बदलना सिर्फ developers को product management पर और समय लगाने की सलाह देने भर से नहीं होगा। इसके लिए organization क्या value करता है और reward कैसे देता है, इस पर systemic change चाहिए
incentives structure को technology-centric से user-centric में बदलने से middle और upper managers की roles पर बड़ा असर पड़ता है। ऐसा बदलाव उनकी roles और responsibilities की बुनियाद हिला देता है, और control व influence खोने तक ले जा सकता है
इसलिए ऐसे बदलाव को middle और upper managers की subtle लेकिन मजबूत resistance मिलने की संभावना ज्यादा है। इनके पास अक्सर organization के भीतर काफी political power और vested interests होते हैं
हर craft में सीखना तब होता है जब वह वास्तविकता से छूता है। film director editing room में film को हजार बार देख सकता है, लेकिन असली audience के साथ पहली बार देखना उन हजार घंटों से ज्यादा सिखा देता है
carpenter पूरे हफ्ते furniture बनाकर संतुष्ट हो सकता है, लेकिन असली पल तब आता है जब वह furniture customer के कमरे में रखा जाता है। software भी वैसा ही है
software engineer को users की परवाह करानी है तो उसे क्या अच्छा चल रहा है और क्या बेहद खराब है, इस पर direct feedback मिलना चाहिए, और हो सके तो अपनी आँखों से देखना चाहिए
ठीक-ठाक software engineer में काम अच्छी तरह करने पर कुछ न कुछ pride होती है। अगर वह pride सिर्फ code, commit history और दूसरी abstract concepts से जुड़ी हो और असल users के लिए चीज़ कितनी काम की है, उससे बिल्कुल न जुड़ती हो, तो शुरुआत में वह परवाह करना सीखेगा ही कैसे
लेख से लगभग संबंध नहीं है, लेकिन blog posts की hero image के रूप में AI image इस्तेमाल करने का आजकल का trend सच में पागल कर देता है
अगर लिखते समय तुम्हारे दिमाग में कोई स्पष्ट hero image नहीं आई, तो computer के बेतुके सपने download करवा कर मेरी bandwidth बर्बाद मत करो
AI images बेहद valuable tool हैं, इसलिए मैं इनके पक्ष में हूँ। लेकिन अगर page की अकेली image के रूप में AI image इस्तेमाल कर रहे हो, तो सच में उसका कोई ठोस कारण होना चाहिए, सिर्फ खाली जगह भरना नहीं
खासकर तब तो बिल्कुल नहीं, जब generated image में हर व्यक्ति की उंगलियों की संख्या तक ठीक से curate नहीं की गई हो
image का मकसद कोई feeling convey करना है। लेख के abstract concepts को थोड़ा ज्यादा tangible बनाना है
पहले इस उद्देश्य के लिए internet पर कोई suitable image खोजकर इस्तेमाल करता था। अब DALL-E से खुद बना सकता हूँ, और आम तौर पर यह काफी बेहतर होता है
यह image लेख को complement करनी चाहिए। जैसे लेख का text information, feeling, concepts convey करने की कोशिश करता है, image को भी उसका कुछ हिस्सा करना चाहिए
कोई भी ऐसा uncanny valley जैसा illustration नहीं देखना चाहता जिसमें सभी प्रमुख racial groups के लोग गोल घेरे में खड़े होकर एक-दूसरे पर अजीब तरह से मुस्कुरा रहे हों
इस तरह के अजीब, आत्माहीन corporate-style illustrations का trend AI generation के धमाकेदार लोकप्रिय होने से पहले ही शुरू हो चुका था
शायद search engine optimization को लेकर किसी तरह के विश्वास की वजह से
साथ ही उन्हें अच्छा दिखना भी होता है, बस
लेकिन इसमें एक मजेदार पहलू है। blog template image area मांगता है, तो बिना सोचे-समझे कुछ भर दिया जाता है। अगर वह बहुत मुश्किल हो तो कोई फीकी stock photo खोज ली जाती है, और वह भी मुश्किल हो तो जान-बूझकर फीकी stock photo generate कर ली जाती है
inspiration और taste से खाली AI garbage जल्द ही सब कुछ ढक देने वाला लगता है
ज़्यादातर PM समस्याओं की जड़ यह है कि वे मैदान में उतरकर काम नहीं करते। अच्छा PM इंजीनियरिंग और यूज़र के बीच की खाई को लगातार पाटता है
इस feedback loop को दोहराते रहना चाहिए
लेकिन ज़्यादातर लोग सोचते हैं कि वे सिर्फ़ documents की दुनिया में काम कर सकते हैं; roadmap documents बनाते हैं और अंतहीन check-ins व टोकाटाकी से stakeholders को aligned रखने की कोशिश करते हैं। अंत में वे दरअसल “project manager” वाला काम कर रहे होते हैं
requirements जुटाना, bugs से नाराज़ users को handle करना, weekly status meetings, priorities से जुड़ी बुरी खबरें देना—सबके लिए senior developer या tech lead को भेजता था। खुद को busy बताकर ज़्यादातर agile rituals भी छोड़ देता था। उसने कभी JIRA ticket लिखा या ठीक नहीं किया, और कहता था कि यह technical organization के manage करने की चीज़ है। दो और technical teams के साथ भी उसने ऐसा ही PM किया
tech leads और senior developers को पहले हफ्ते से ही पता था कि वह PM अच्छा नहीं है, लेकिन वह हम सब से ज़्यादा टिका रहा और 4 साल बाद ही layoffs में गया
agile पूजा में फंसी management ऐसे लोगों से आसानी से प्रभावित हो जाती है, और organization को सालों तक पटरी से उतार सकती है। सिद्धांततः PM का stakeholder user होता है, लेकिन व्यवहार में काम उसे hire करने वाले senior executives के अहंकार को सहलाना बन जाता है
senior executives, agile consultants और PMs के बीच एक self-reinforcing closed loop बन सकता है
दोनों ही मामलों में products competitive नहीं होते, और अक्सर बंद होने तक वैसे ही बने रहने की संभावना होती है। फिर भी company PM और PO रखती है, SCRUM जैसी structure बनाती है, और ऐसे व्यवहार करती है जैसे कोई revolutionary product बना रही हो। इसमें urgent work और outcomes का pressure भी शामिल होता है
ऐसे माहौल में PM और PO अक्सर अच्छे product या usable product में खास दिलचस्पी नहीं रखते; वे internal promotion ladder चढ़ने की politics में लगे रहते हैं
वे project को उस दिशा में धकेलते हैं जिसमें वे management या customers को अच्छे दिखें, भले ही इससे features और improvements के लिहाज़ से random walk जैसा fragmented product बने
मैं इतना उम्रदराज़ नहीं हूँ कि जानता होऊँ कि 60s, 70s और 80s में कैसे बनाया जाता था, लेकिन शायद तब SCRUM/PM/PO नहीं थे। पिछले दशकों की तुलना में productivity काफी धीमी हो गई है और आज हम ज्यादातर अतीत में बनी चीज़ों पर टिके हैं—यह pessimistic narrative मेरी समझ से काफी मेल खाता है
हाल में मैं दूसरे PMs को mentor कर रहा हूँ। widely shared roadmap भी है, लेकिन सचमुच बहुत सारे documents और spreadsheets बनते हैं जिन्हें मेरे अलावा कोई दोबारा नहीं देखता। लगता है वे सिर्फ़ यह दिखाने के लिए बनाए जाते हैं कि काम हो रहा है, और मैं ऐसी आदत तोड़ने की कोशिश कर रहा हूँ
technical product management का मैं इसलिए strongly समर्थन करता हूँ क्योंकि समस्या को सरल करके देखें तो कुछ PMs बहुत high abstraction level में फंसे रहते हैं। वे रोज़ team के साथ detailed technical issues पर बात नहीं कर पाते, और अंत में project management और product management के बीच के अजीब grey zone में अटक जाते हैं
यह अपने आप में ठीक है, लेकिन अगर product decisions लेना चाहने वाला HIPPO syndrome हो, तो ज़्यादातर समय अपनी पीठ बचाने और upward management में चला जाता है
PMs पर काफी मार पड़ती है, कभी-कभी जायज़ भी, लेकिन अंततः काम करवाने के लिए उन्हें अक्सर internal politics करनी पड़ती है
बेहतरीन PM सिर्फ़ vision या plan नहीं बनाता, बल्कि execution और iteration को भी lead करता है। plan कुल काम का 20% है
जिन product managers के साथ मैंने काम किया उनमें सबसे अच्छा व्यक्ति बस बेहद सक्षम इंसान था; वह implementation complexity समझता था और ज़रूरत पड़ने पर शायद खुद भी कर सकता था, साथ ही business needs भी समझता था
वह engineering manager नहीं था, फिर भी company में value जोड़ता था
अफसोस, ज़्यादातर product managers बस उस कुर्सी पर बैठे लोग होते हैं। वे gatekeeper होते हैं जो credit हो या responsibility, दोनों ले लेते हैं, और अक्सर उनका अपना stake बहुत कम होता है
कुल मिलाकर, मेरा मानना है कि अगर अलग product management organization है, तो आप गलत कर रहे हैं
जिन सबसे अच्छे और सबसे सफल products में मैं शामिल रहा, उनमें product ownership असली implementers के पास थी। जैसे engineers, designers, customer success team के लोग
एक engineer के तौर पर मुझे support rotation में रहना पसंद था, क्योंकि इससे मेरे काम और उसे हर सेकंड इस्तेमाल करने वाले वास्तविक लोगों के बीच का abstraction gap बंद हो जाता था
बहुत कम बार ऐसे PMs के साथ काम किया है जो net value जोड़ते थे, और उन सभी मामलों में वे ऐसे लोग थे जो अच्छे engineers भी बन सकते थे
मुख्य वजह यह है कि अगर PM, या team में वह role निभाने वाला व्यक्ति, उसी engineering management chain में report करता है, तो सब कुछ अंततः engineering needs की ओर झुक जाता है
business को आगे बढ़ाने की संभावना रखने वाला ज़रूरी feature work भी technical debt या infra work के कारण priority से नीचे चला जाता है, क्योंकि वे हमेशा किसी न किसी तरह लोगों को रोक रहे होते हैं। कभी-कभी यह सच में सही choice हो सकती है, लेकिन ऐसे decisions के लिए बराबरी की जगह रखने वाले दो organizations के बीच tension ज़रूरी है। जब यह engineering का हिस्सा बन जाता है, तो ऐसा अच्छी तरह नहीं होता
बेशक हमारी industry की दुखद सच्चाई यह है कि अलग PM organization “business के लिए अच्छा क्या है” का मालिक होने के कारण engineering organization से भी ज़्यादा authority हासिल कर लेता है। इसमें अगर ऐसे PMs जुड़ जाएँ जो processes या frameworks follow करना तो जानते हैं, लेकिन अपने product या users को सच में नहीं समझते, तो यह nightmare बन जाता है
मैं इसे अनुपात के रूप में सोचता/सोचती हूँ
frontend engineers और backend engineers का अनुपात क्या है? engineering managers और individual contributors का अनुपात? technical writers और कुल engineers का अनुपात? product managers और कुल engineers का अनुपात?
और इस अनुपात को बारीकी से adjust करके असर को अधिकतम और दखलअंदाजी व micromanagement को न्यूनतम करने की कोशिश करता/करती हूँ
इस अनुपात की वास्तविक संख्या हर संगठन में अलग होगी, लेकिन अगर दखलअंदाजी महसूस हो या “कैसे” पर्याप्त रूप से खुद engineers से नहीं आ रहा हो, तो अनुपात बदलना चाहिए
people manager या product manager प्रति engineers की संख्या बढ़ानी चाहिए ताकि वे इस तरह बीच में न घुस सकें, उन्हें अपनी भागीदारी वाली चीज़ों को prioritize करना पड़े, और micro-level से पीछे हटकर engineers को तरीके की autonomy वापस देनी चाहिए
QA, junior engineers, senior engineers, architects, HR staff, vice presidents, salespeople के साथ भी यही बात है
मैं 20 साल से ज़्यादा समय से product management कर रहा/रही हूँ, और यहाँ कही गई ज़्यादातर बातों से सहमत हूँ। अनुपात महत्वपूर्ण है
CPO के लिए PM की सेना लेकर साम्राज्य बनाना आसान होता है। संगठन ऐसी स्थिति में पहुँच जाता है जहाँ PM किसी single page जैसे customer experience के छोटे-छोटे टुकड़ों के मालिक होते हैं, button click-through rate optimize करते हैं, लेकिन product strategy या vision में meaningful योगदान नहीं देते
product का मालिकाना न रखते हुए product manager बनना मुश्किल है
PM को आज की तुलना में कहीं ज़्यादा business goals पर focus करना चाहिए। user problems हल करना ज़रूरी है, लेकिन पर्याप्त नहीं। उस problem solving से company value भी बननी चाहिए
इसे संभव बनाने के लिए मजबूत product sense वाले engineering और UX partners अनिवार्य हैं
इससे भी बुरा यह कि “आसानी से replace किए जा सकने वाले” developers outsourcing companies से आते हैं। अब development को customer से management की और परतों के जरिए isolate करना पड़ता है
GDP बढ़ाने का शानदार तरीका है
उदाहरण के लिए अगर ERP, Oracle Fusion Apps, WorkDay, SAP जैसी चीज़ों पर काम कर रहे हों, तो एक PM पूरे product का मालिक नहीं हो सकता। इसके बजाय उसे कई features संभालने पड़ते हैं, और हर feature खुद जटिल होता है; ERP की प्रकृति के कारण आम तौर पर कई दूसरे products के साथ integration भी शामिल होता है
फिर भी मैं इस बड़ी दिशा से सहमत हूँ कि PM के पास कुछ meaningful का मालिकाना होना चाहिए
developer और development manager के रूप में जिन बेहतरीन product managers के साथ मैंने काम किया, वे “कैसे” में लगभग दखल नहीं देते थे
बेशक backlog में epic-level tickets बना सकते हैं, लेकिन उससे नीचे के स्तर पर वे भरोसा करते हैं कि आप और project owners काम पूरा कर लेंगे
समस्या यह है कि organization को इसे support करना चाहिए। ज़्यादातर companies में सबसे ज़्यादा attention पाने वाला काम vision या growth-focused नहीं, बल्कि सबसे शोर मचाने वाला काम होता है
और ऐसा काम अक्सर product owners या managers जिस दिशा में जाना चाहते हैं, उससे सीधे टकराता है
“कैसे” को न समझने वाला PM, यानी जिसे पता ही नहीं कि उसका product कैसे काम करता है, सबसे खराब होता है
जिन बेहतरीन PMs के साथ मैंने काम किया, उनका technical background था
जब लोग दूसरों के क्षेत्र में पैर रखने की कोशिश करते हैं, तो हमेशा disaster होता है। दोनों दिशाओं में यही सच है। engineer “कैसे?” के नजरिए से बहुत ज़्यादा सोचते हैं, इसलिए वे “क्यों?” और “क्या?” में कमजोर होते हैं; और product managers को भी “कैसे?” से पीछे हटना चाहिए, जब तक कि वह “क्या?” या “क्यों?” को स्पष्ट करने के लिए न हो
balance होना चाहिए। PM/PO को भी basic understanding चाहिए। वे ऐसे लोग नहीं होने चाहिए जो मुश्किल से computer चला पाते हों
अच्छा PM भी अगर आसपास बहुत सारे mediocre PM हों, तो काफी बंध सकता है
कई Fortune 500 companies के साथ काम करते हुए मैंने बहुत सारी broken cultures देखी हैं
ऐसी जगहों पर PM अपने पास मौजूद एकमात्र tool, यानी meetings, से ज़्यादातर problems solve करते हैं। promotion incentives ऐसे बने होते हैं कि meeting जितनी बड़ी हो, व्यक्ति उतना ही महत्वपूर्ण दिखता है
मैं cross-functional team meetings के सैकड़ों घंटों में बैठा/बैठी हूँ, जहाँ असल में काम करने वाले 1–2 लोग होते हैं और आम तौर पर PM पूरे समय बोलता रहता है, जबकि 10–20 लोग mute पर रहते हैं और अंत में बस अपनी मौजूदगी साबित करने की तरह approval दे देते हैं
नतीजा यह होता है कि engineering team का motivation खत्म हो जाता है, actual technical work करने का समय नहीं बचता, और code की investigation या समझ के बिना वहीं estimates या commitments माँगे जाते हैं
मैंने यह भी देखा है कि PM technical design को सिर्फ इसलिए reject कर देते हैं क्योंकि उन्हें numbers या “points” पसंद नहीं आते, और engineers को उसी idea को किसी अज्ञात PM aesthetic को satisfy करने के लिए दूसरे “ticket” के रूप में reformat करना पड़ता है
समझ की कमी और meaningless status-display rituals की वजह से पूरे projects delay और derail हो जाते हैं
इसके उलट, मैंने शानदार PMs के साथ भी काम किया है; ऐसे लोग team को इस बकवास से बचाते हैं और सही goals पर focus कराते हैं। ऐसे लोग valuable होते हैं, और पहले वाले उतने ही harmful
PM की संख्या से अलग, यह उस तरह के PM के बारे में बात है जिसके साथ मैं काम करना चाहता/चाहती हूं
मैंने इंडस्ट्री में चार कंपनियों में काम किया है, 40 से कम लोगों वाले startup से लेकर JP Morgan Chase तक का अनुभव रहा है
मैं इस विचार को खारिज करता/करती हूं कि “technical” लोग “non-technical” लोगों से ज्यादा स्मार्ट होते हैं। सच तो यह है कि एक engineer होने के नाते मैं अक्सर details में उलझकर बड़ी तस्वीर चूक जाता/जाती हूं, और अक्सर PM को मुझे उससे बाहर खींचने की जरूरत पड़ती है
हालांकि मेरे अनुभव में, एक engineer के तौर पर जिन PMs के साथ काम करना सबसे आसान होता है, वे वे लोग हैं जिन्हें code से असल में थोड़ा भी exposure रहा हो
बहुत बड़ा कुछ होना जरूरी नहीं। बहुत पहले HTML और CSS से website बनाई हो, या कोई अस्थायी SQL query लिखी हो, या master’s के दौरान Python class ली हो — इतना भी काफी है
बस PM के पास कुछ ऐसा होना चाहिए जिससे उसे समझ आए कि code लिखना न तो कोई exact science है और न ही पूरी तरह magic
ऐसे PMs साथ काम करने वाले engineers की वकालत करते हैं, या कम से कम business requirements और engineering realities के बीच balance बनाने की कोशिश करते हैं
जिन लोगों ने बिना किसी technical exposure के PM बने हैं, वे ज्यादा “business-oriented” होने की प्रवृत्ति रखते हैं, और किसी खास समय पर business को शायद ठीक वही चाहिए भी हो सकता है, लेकिन हमेशा ऐसा नहीं होता। एक engineer के तौर पर मैं ऐसे व्यक्ति के साथ काम करना चाहूंगा/चाहूंगी जो मेरा perspective भी बेहतर समझता हो
बिल्कुल भी बुरा नहीं लगा है :p