मेरे पास दो किताबें हैं जिन्होंने प्रोडक्ट में मुझे गढ़ा: मार्टी कैगन की Inspired, और जोका टोरेस की Gestão de Produtos, जिनसे मुझे मेंटरशिप का सौभाग्य भी मिला। सालों तक ये दोनों मेरा नक्शा रहीं: PM क्या है, प्रोडक्ट डिज़ाइनर क्या है, इंजीनियर क्या है, कौन क्या करता है। हर भूमिका की एक साफ़ रूपरेखा।
पिछले साल, Prolog में अपनी टीम को AI के साथ काम करते देखकर, मुझे लगने लगा कि ये रूपरेखाएँ खिसक रही हैं। ऐसा नहीं कि किताबें ग़लत हो गईं: बात यह है कि वह परत ऊपर चढ़ गई जहाँ हर भूमिका घटती है।
सीरीज़ के पहले लेख में मैंने वह बेचैनी बताई थी जिसने मुझे Prolog में टेक फिर से बनाने की ओर धकेला, और दूसरे में, harness क्या है, वह इन्फ़्रा जो AI को असल में काम करने लायक बनाती है। पहले के अंत में मैंने एक ख़ास हिस्सा खोलने का वादा किया था: जब AI ही बनाने वाला बन जाता है तो हर पद का काम कैसे बदलता है। यही यहाँ का विषय है।
काम ग़ायब नहीं होता, वह एक परत ऊपर चढ़ता है
AI हर पेशे की भूमिका मिटा नहीं रहा, वह उस परत को बदल रहा है जहाँ वह घटती है।
आसान पढ़त, जो डर बेचती है, वह है “AI फ़लाँ पद की जगह ले लेगा”, और मैंने ऐसा होते नहीं देखा। मैंने जो देखा वह यह था कि काम का सार अपनी जगह बदल गया: जो पहले करना था वह बन गया करने वाले को दिशा देना और उसकी आलोचना करना।
इंजीनियर, जो कोड लिखता था, अब एजेंट के लिखे को रिव्यू करता है। PM, जो स्पेक लिखता था, अब उससे घंटों में निकले प्रोटोटाइप को परखता है। इंसान वही है, बस उसके हाथ का औज़ार बदल गया है।
जब मैं इसी सोच के साथ कैगन और जोका पर लौटा, तो बात दूसरे ढंग से समझ आई। दोनों बड़े ध्यान से हर भूमिका का निष्पादन बताते हैं (ठोस काम, डिलिवरेबल, दिन के अंत में आपके हाथों से जो निकलता है), और ठीक यही AI अपने ज़िम्मे ले रहा है। इंसान के लिए जो बचता है वह दूसरा आधा है: यह तय करना कि क्या बनाने लायक है, बने हुए में छेद ढूँढना, यह जानने का taste रखना कि क्या अच्छा है। judgment, निष्पादन नहीं।
तो मैं वही करूँगा जो मैंने ख़ुद के साथ किया: किताबों से हर भूमिका की परिभाषा लेना, और पूछना कि उसमें से AI क्या खा जाता है और क्या बचता है (और महँगा हो जाता है)।
तीन का दल, किताबों के मुताबिक
भूमिका दर भूमिका अलग करने से पहले, याद कर लें कि किताबें टीम को कैसे जोड़ती हैं। जोका सीधे कहते हैं: एक सफल प्रोडक्ट को desirable, viable और बनने-योग्य होना चाहिए, और यही “एक सफल प्रोडक्ट बनाने के लिए तीन ज़रूरी कार्य” तय करता है (अध्याय 2): UX डिज़ाइनर, प्रोडक्ट मैनेजमेंट और डेवलपर, वह तिकड़ी जिसे वे core team कहते हैं। कैगन, Inspired में, इन्हीं भूमिकाओं को अपने पहले अध्याय “Key Roles and Responsibilities” में बताते हैं।
दोनों एक बात पर ज़ोर देते हैं जिसे मैं अंत में फिर उठाऊँगा: यह बॉस और मातहत का रिश्ता नहीं है। जोका के शब्दों में, “प्रोडक्ट इंजीनियरिंग, प्रोडक्ट मैनेजमेंट और UX एक टीम हैं, इनमें से किसी समूह के बीच अधीनता का रिश्ता नहीं है” (अध्याय 31), और कैगन में यही विचार इस रूप में आता है कि PM और इंजीनियरिंग “बराबरी के हैं, कोई भी पद दूसरे का मातहत नहीं” (अध्याय 5, मेरे अनुवाद में)। और जब AI इस तिकड़ी के बीच आता है, तो यही साझेदारी सबसे ज़्यादा रूप बदलती है।
तालिका: टेक में हर पेशा एक परत ऊपर जाता है। इंजीनियरिंग कोड उत्पादक से एजेंट के आलोचक तक, प्रोडक्ट स्पेक-राइटर से इटरेशन आर्किटेक्ट तक, डिज़ाइन स्क्रीन उत्पादक से प्रयोग के कंडक्टर तक, क्वालिटी टेस्टर से वैलिडेशन बनाने वाले तक।
टेक में हर पेशे की भूमिका
वही भूमिका, एक परत ऊपर
निष्पादन एजेंट का हो जाता है · judgment आपके पास रहता है: तय करना, आलोचना करना, taste रखना
इंजीनियर: कोड उत्पादक से एजेंट के आलोचक तक
इंजीनियरिंग के लिए, जो मायने रखता है वह अब यह नहीं रहा कि आप कितना कोड बनाते हैं: वह बन गया कि आप एजेंट के बनाए की कितनी अच्छी आलोचना करते हैं।
जोका की परिभाषा इतनी साफ़ है कि अब उसे दोबारा पढ़ना चुभता है: “प्रोडक्ट इंजीनियरिंग प्रोडक्ट को विकसित करने और उसे चलता रखने की ज़िम्मेदार है”, और आगे, इंजीनियरिंग “प्रोडक्ट बनाती है” (अध्याय 31)। बनाना ही क्रिया थी। कैगन दूसरे छोर से इसे पूरा करते हैं, प्रोडक्ट के साथ रिश्ते की बात करते हुए: “product manager समाधान तय करने का ज़िम्मेदार है, पर इंजीनियरिंग टीम बेहतर जानती है कि क्या मुमकिन है, और आख़िर में वही यह समाधान डिलिवर करती है” (अध्याय 5, मेरे अनुवाद में)। एक ओर तय करना, दूसरी ओर डिलिवर करना।
अब पहले वर्शन की डिलिवरी एजेंट की है। जो नहीं बदला, और महँगा हो गया, वह सब है जिसे कैगन नवाचार के स्रोत के रूप में इंजीनियर से जोड़ते थे: “इंजीनियर सबसे बेहतर जानते हैं कि क्या मुमकिन है” (अध्याय 5)। यह जानना कि क्या मुमकिन है, एजेंट के सुझाए प्लान में छेद ढूँढना, वह performance या security का trade-off देखना जो वह नहीं देख पाता, तय करना कि कब दख़ल देना है और कब चलने देना है। यह हर महीने और भारी पड़ता है। स्मृति से syntax, हाथ से boilerplate, Stack Overflow छानना, निजी ट्रॉफ़ी की तरह कोड का ढेर: यह कम भारी पड़ता है।
Prolog में मैंने टीम से खुलकर यही कहा: किसी को कोड की लाइनों से नहीं आँका जाएगा। जो हमेशा “छेद ढूँढने” में अच्छा था वह और मूल्यवान होता है, और जो ख़ुद को “तेज़ी से बहुत कोड बनाने” से जोड़ता था उसे यह फिर से तौलना होगा कि वह ऊर्जा कहाँ लगाए। और इससे इंजीनियरिंग घटती नहीं है। उसका मूल्य हमेशा तेज़ बनाने से ज़्यादा यह जानने में रहा है कि क्या टिकता है, और अब यह बस साफ़ दिखने लगता है।
PM: स्पेक-राइटर से इटरेशन आर्किटेक्ट तक
PM इसे तब महसूस करता है जब प्रोटोटाइप सस्ता हो जाता है: उसका काम अब दस्तावेज़ लिखना नहीं रहता, बल्कि यह चुनना बन जाता है कि कौन-सा आइडिया टीम के समय के लायक है।
कैगन काम के दिल के बारे में दो-टूक हैं: “किसी को यह खोजना होगा कि समाधान, प्रोडक्ट, आख़िर क्या है, जिसमें फ़ीचर, यूज़र एक्सपीरियंस और लॉन्च के मानदंड शामिल हैं। वह कोई और नहीं, product manager है, और यही काम उसके काम का दिल है” (अध्याय 1, मेरे अनुवाद में)। जोका चौड़ी रूपरेखा देते हैं: प्रोडक्ट मैनेजमेंट “वह कार्य है जो एक सॉफ़्टवेयर प्रोडक्ट के हर पहलू का ज़िम्मेदार है, उसके पूरे जीवन-चक्र में, कल्पना से लेकर उसके जीवन के अंत तक” (अध्याय 2)।
ग़ौर करें कि दोनों में मुख्य शब्द है खोजना, न कि तय करना। कैगन का एक पूरा अध्याय बस यही बचाने में लगा है कि काम discovery है, “requirements” नहीं: सॉफ़्टवेयर के दो चरण हैं, “क्या बनाना है यह खोजना (सही प्रोडक्ट) और बनाना (प्रोडक्ट को सही तरीके से)। पहले पर discovery का राज है, दूसरा निष्पादन है” (अध्याय 12, मेरे अनुवाद में)। यही हमेशा उनका संदेश रहा, और AI ने बस उसे अक्षरशः सच कर दिया।
क्योंकि जब build हफ़्तों से घंटों में सिकुड़ जाता है, तो अड़चन बनाना नहीं रह जाती, बल्कि यह तय करना बन जाती है कि बनाना किसके लायक है। कमेटी में रिव्यू किया लंबा स्पेक, बंद तिमाही planning, डिलिवरेबल के रूप में स्टेटस रिपोर्ट, इंजीनियरिंग और डिज़ाइन के बीच ट्रैफ़िक कंट्रोल: यह सब कम भारी पड़ता है। जो ज़्यादा भारी पड़ता है वह है तेज़ discovery (समझने के लिए प्रोटोटाइप बनाना, बनाने के लिए स्पेक नहीं), हाइपोथीसिस की क्यूरेशन (कौन-सा आइडिया टीम के समय के लायक है) और यह तय करना कि क्या नहीं करना है, और भी अक्सर। कुछ कंपनियाँ इस PM को अभी से “Editor” या “Architect” कह रही हैं। यह कम PM नहीं है: यह दूसरा PM है, जो क्यूरेट करता है, जो taste के साथ तय करता है, जो दिशा देता है। पुराने में जो केंद्रीय था, स्पेक लिखना, वही हल्का पड़ गया।
प्रोडक्ट डिज़ाइनर: स्क्रीन उत्पादक से प्रयोग के कंडक्टर तक
डिज़ाइन में, काम की इकाई स्क्रीन से निकलकर उस सिस्टम में चली जाती है जो स्क्रीन बनाता है, और प्रोडक्ट डिज़ाइनर यह चुनने लगता है कि कौन-सी वैरिएशन ज़िंदा रहती है।
जोका में, UX की परिभाषा है समझना ताकि डिज़ाइन कर सको: “UX यूज़र को और जिस समस्या को उसके लिए हल करना है उसे गहराई से समझने का ज़िम्मेदार है” (अध्याय 32)। और वे जो फ़्लो बताते हैं वह वही रस्म है जिसे सब जानते हैं: पेपर प्रोटोटाइप, फिर wireframe, फिर “UX का visual designer उन स्क्रीनों में रंग और रूप भरने लगता है”। कैगन इसी तर्क से भूमिका को दो हिस्सों में काटते हैं: interaction designer “यूज़र की गहरी समझ बनाता है और टास्क, नेविगेशन और फ़्लो रचता है”, इसे wireframe में उतारता है और visual designer को सौंपता है, जो “wireframe में मांस भरता है” (अध्याय 4, मेरे अनुवाद में)।
यह क्रम, समझना, स्केच करना, स्क्रीन दर स्क्रीन निखारना, ठीक वही है जिसे AI छोटा कर देता है। काम की इकाई “स्क्रीन” नहीं रह जाती, “स्क्रीन बनाने वाला सिस्टम” बन जाती है। Figma में वही वैरिएशन पाँच बार दोबारा बनाना, component दर component तय करना, रस्म की तरह pixel-perfect handoff: कम भारी पड़ता है। इटरेशन की रफ़्तार पर प्रोटोटाइप बनाना (कई विकल्प एक साथ, ख़राब को फेंक देना), हर अलग स्क्रीन के बजाय visual सिस्टम तय करना, और तेज़ visual आलोचना (AI को कुछ प्रस्ताव करते देखना और यूज़र के भाँपने से पहले भाँप लेना कि वह ग़लत है): ज़्यादा भारी पड़ता है।
और यहाँ कैगन, 2008 में ही, एक बात कहते हैं जो प्रोडक्ट डिज़ाइनर को यह सोचने से बचाती है कि वह बटन दबाने वाला बन गया: उसका काम कभी सिर्फ़ सुंदर बनाना नहीं था। “एक अच्छा प्रोडक्ट एक अच्छा यूज़र एक्सपीरियंस माँगता है। और एक अच्छा एक्सपीरियंस प्रोडक्ट और डिज़ाइन के बीच नज़दीकी सहयोग माँगता है” (अध्याय 4, मेरे अनुवाद में)। AI वैरिएशन बनाता है, और उनमें से कौन-सी यूज़र तक पहुँचने लायक है यह तय करने वाला अब भी taste वाला इंसान ही है।
QA: टेस्टर से वैलिडेशन बनाने वाले तक
QA सबसे दिलचस्प मामला है, क्योंकि यही वह भूमिका है जिसे किताबों ने लगभग अलग नहीं किया, और यही वह है जिसे AI सबसे ज़्यादा हिलाता है।
ग़ौर करें: जोका की तिकड़ी (डिज़ाइनर, PM, डेवलपर) और कैगन की भूमिकाओं में, गुणवत्ता घुली-मिली दिखती है, टीम की ज़िम्मेदारी के रूप में, अपने अलग तरीके वाली अपनी कुर्सी के रूप में नहीं। लंबे समय तक इसका तुक बनता था, पर अब नहीं बनता, और वजह सीधी है: अगर एजेंट तेज़ बनाता है और वैलिडेशन हाथ से ही चलती रहती है, तो आपने बस तेज़ रफ़्तार पर तकनीकी क़र्ज़ बना दिया।
तो QA अब हाथ से टेस्ट केस चलाने वाला नहीं रहता, वह testing harness डिज़ाइन करने वाला बन जाता है, वह सिस्टम जो सिस्टम को टेस्ट करता है: AI को इस तरह सेट करना कि वह उस कोड के लिए टेस्ट लिखे जो किसी और AI ने लिखा, यूज़र से पहले regression पकड़ना, यह सोचना कि defect कहाँ उभरने की प्रवृत्ति रखता है। व्यवहार में, यह एक ऑपरेशनल सवाल बन गया जिसे हमने अपनाया: हर बग जो निकल भागता है वह बन जाता है “अगली बार हम इसे अपने-आप कैसे पकड़ें?”। जाने-पहचाने फ़्लो का थकाऊ मैनुअल टेस्ट, हर रिलीज़ पर हाथ से चलाई regression, शिप करने से पहले अकेले फाटक के रूप में QA: कम भारी पड़ता है। वैलिडेशन एक सिस्टम के रूप में, न कि लाइन के अंत में एक पास के रूप में।
यही वह भूमिका है जो सबसे ज़्यादा परत ऊपर चढ़ती है, ठीक इसलिए क्योंकि वह सबसे कम परिभाषित थी। जहाँ किताबों ने कोई रूपरेखा नहीं गढ़ी, वहाँ AI एक नई गढ़ रहा है।
स्थिरांक: किताबें जो पहले से कहती थीं कि सबसे ज़्यादा मायने रखता है
एक बात है जो नहीं बदलती, और वह दोनों किताबों में सबकी आँखों के सामने छिपी थी: जिसे वे सबसे अहम बताती हैं वही ठीक वह है जो AI नहीं करता।
जोका एक अच्छे PM के गुणों वाला अध्याय बिना लाग-लपेट खोलते हैं: “सबसे अहम, बेशक, empathy है” (अध्याय 4)। यह कोई कार्य-तालिका या डिलिवरेबल नहीं: यह उपयोग करने वाले की जगह ख़ुद को रखने की क्षमता है। कैगन, अपनी ओर से, पूरी किताब में process से ऊपर discovery, taste और judgment का पक्ष लेते हैं, और दोनों, हर एक अपने ढंग से, एक ही बात कह रहे थे: अच्छे को औसत से अलग करने वाली चीज़ कभी काम का यांत्रिक हिस्सा नहीं थी।
और यांत्रिक हिस्सा ठीक वही है जो एजेंट के पास चला गया। स्पेक लिखना, स्क्रीन डिज़ाइन करना, कोड लिखना, टेस्ट चलाना। जो बचा, और महँगा हो गया, वह है आलोचनात्मक सोच, taste (यह जानना कि क्या अच्छा है), अस्पष्टता में judgment, जिज्ञासा, इसकी परवाह कि आपके बनाए को कौन उपयोग करता है। टीम के साथ जो वाक्य मैंने इस्तेमाल किया उसमें कहूँ तो: काम का सार बदलता है, करने वाला इंसान नहीं।
दो परतों का डायग्राम। ऊपर, वह जो हमारे पास रहा और महँगा हो गया: taste (यह जानना कि क्या अच्छा है), अस्पष्टता में judgment, empathy जो इसे इस्तेमाल करते हैं उनके लिए, यह तय करना कि क्या नहीं करना है, किताबें जो पहले से कहती थीं कि सबसे ज़्यादा मायने रखता है। काम एक परत ऊपर चढ़ा। नीचे, वह जो एजेंट के पास चला गया: स्पेक लिखना, स्क्रीन डिज़ाइन करना, कोड लिखना, मैनुअल टेस्ट चलाना।
हमारे पास रहा · और महँगा हो गया
किताबें जो पहले से कहती थीं कि सबसे ज़्यादा मायने रखता है
काम एक परत ऊपर चढ़ा
एजेंट के पास चला गया
इससे क्या क़ीमत चुकानी होगी (बिना घिसे-पिटे)
मैं इसे बहुत सुंदर ढंग से नहीं समेटना चाहता, क्योंकि यह है नहीं। यह बदलाव ठोस चीज़ें माँगता है, और कोई भी आरामदेह नहीं।
पहली है एक दशक की आदत को पीछे छोड़ना। जो पाँच, दस साल से पुराने ढर्रे में है वह ऐसे पैटर्न ढोता है जिन्होंने उसे यहाँ तक पहुँचाया, और ठीक वही पैटर्न बदलने में भारी पड़ते हैं। कोई शॉर्टकट नहीं, और बेचैनी अपेक्षित है।
फिर, AI के साथ रचने जितना ही उसकी आलोचना करना: जो सुझाव आया उसे स्वीकार कर लेना काम नहीं है; उसके सुझाए प्लान में छेद ढूँढना, है। जो हमेशा महँगा था (आलोचनात्मक सोच, taste, judgment) और महँगा हो जाता है।
एक और है टीम के रूप में ग़लती करना, व्यक्ति के रूप में नहीं। हम प्रोडक्शन में बग के लिए इंजीनियर को नहीं निकालते, हम review सुधारते हैं, और जब AI ग़लती करता है तो हम harness को मज़बूत करते हैं। एजेंट का बग process है, व्यक्ति नहीं: एक वचन, नारा नहीं।
और सबसे असहज: यह स्वीकार करना कि कुछ भूमिकाएँ दूसरों से ज़्यादा बदलती हैं। यह उनमें बेचैनी पैदा करता है जो अब तक कम बदले, और यह दिखावा नहीं किया जा सकता कि सब कुछ एक जैसा है। जो किया जा सकता है वह है इसे खुली बातचीत में लाना।
और ताकि मैं ऐसा न लगूँ जैसे मंज़िल पर पहुँच गया: Prolog अभी इसमें शुरुआत में है। हम अब भी AI-assisted पर हैं, 10 से 20% के फ़ायदे के साथ, 5x या 10x वाले AI-first पर नहीं। मैं एक दिशा बता रहा हूँ जिसे हम बना रहे हैं, सही और ग़लत दोनों के साथ, कोई जीत नहीं।
इससे मैं क्या लेकर जाता हूँ
किताबें ग़लत नहीं हुईं। वे हर भूमिका के निष्पादन को इतनी सटीकता से बताती थीं जिसे मैं सच में अभी समझ पाया (स्पेक लिखना, स्क्रीन डिज़ाइन करना, प्रोडक्ट बनाना, टेस्ट चलाना), और वह निष्पादन अब एजेंट का है। और इंसान के लिए जो बचा वह दूसरा हिस्सा है, परखना, आलोचना करना, taste रखना, उपयोग करने वाले की परवाह करना, जो, कैगन और जोका पर लौटें तो, वही है जिसे वे पहले पन्ने से कहते थे कि सबसे ज़्यादा मायने रखता है।
शायद यही अच्छा हिस्सा है: जो काम AI ने हमारे हाथ से लिया वह सबसे दोहरावदार था, और जो उसने छोड़ा वह हमेशा सबसे कठिन, और सबसे दिलचस्प था। मैं बताता रहूँगा कि यह कैसे आगे बढ़ता है।
स्रोत
- Marty Cagan, Inspired: How to Create Products Customers Love (पहला संस्करण, 2008)। भूमिकाओं की परिभाषाएँ अध्याय 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) और 12 (Product Discovery) से हैं। अंशों के अनुवाद मेरे हैं।
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código)। परिभाषाएँ अध्याय 2 (सॉफ़्टवेयर प्रोडक्ट मैनेजमेंट क्या है?), 4 (एक प्रोडक्ट मैनेजर के मुख्य गुण), 31 (प्रोडक्ट इंजीनियरिंग और प्रोडक्ट मैनेजमेंट) और 32 (UX और प्रोडक्ट मैनेजमेंट) से हैं।
- भूमिका के एक परत ऊपर चढ़ने वाली पढ़त सीरीज़ को सहारा देती है: OpenAI, Harness Engineering, और Peter Pang, CREAO के CTO।