AI intro 8 - AI के साथ प्रोडक्ट डॉक्यूमेंट्स

मनुष्य द्वारा बनाया गया दस्तावेज़

कॉल की मूल ट्रांसक्रिप्शन के आधार पर सामान्यीकृत गद्य। पाठ के लिए केवल प्रोडक्ट डॉक्यूमेंट्स, Markdown, Codex, ट्रांसक्रिप्शन और Neuronet के साथ काम करने से संबंधित प्रासंगिक अंश का उपयोग किया गया है।

ऐसे लोग हैं जो पहले से ही Markdown-फॉर्मेट में लिखते हैं, जो AI के लिए अधिक उपयुक्त है: ताकि अपने Codex या Claude Code में अपने प्रोडक्ट के प्रत्येक दिशा के लिए नॉलेज बेस बनाने की सुपर क्षमता हो, और ताकि AI मॉडल इस नॉलेज बेस को अच्छी तरह पढ़ सकें, डॉक्यूमेंट्स में खोज सकें और उन्हें संदर्भ के रूप में उपयोग कर सकें।

और एक अधिक प्रोडक्ट-केंद्रित दृष्टिकोण है: Confluence, जहाँ डॉक्यूमेंट्स सबसे पहले लोगों के लिए लिखे जाते हैं, ताकि लोग डॉक्यूमेंट्स पढ़ें। यानी Confluence लंबे समय से एक मानवीय नॉलेज बेस के रूप में इस्तेमाल होता रहा है, जबकि Markdown धीरे-धीरे AI Native काम के लिए सुविधाजनक फॉर्मेट बन रहा है।

यहाँ समझना महत्वपूर्ण है कि पहले हम प्रोडक्ट डॉक्यूमेंटेशन के लगभग सभी फॉर्मेट आज़मा चुके हैं: MS Office, BaseCamp, Notion, Google Docs, Confluence, तस्वीरों वाले डॉक्यूमेंट्स, स्क्रीनशॉट्स पर तीरों वाले डॉक्यूमेंट्स, वीडियो, Loom इत्यादि। एक समय पर Loom विकास का शिखर बन गया: आप केवल टेक्स्ट नहीं लिखते, बल्कि बताते भी हैं और साथ ही स्क्रीन पर दिखाते हैं कि क्या हो रहा है। Loom फॉर्मेट में प्रोडक्ट प्रेज़ेंटेशन बनाना, आइडिया रिकॉर्ड करना, टास्क समझाना और इंस्ट्रक्शंस बनाना सबसे सुविधाजनक है।

लेकिन Loom और Google Meet की एक समान समस्या है: लोगों ने बात की, किसी ने रिकॉर्डिंग देखी, किसी ने नहीं देखी, किसी ने कुछ समझा, किसी ने नहीं समझा या भूल गया, और सुखद समय बिताने के बाद सभी चले गए। प्रभावी प्रोडक्ट काम के लिए ऐसा दृष्टिकोण पर्याप्त नहीं है। बातचीत अपने-आप स्थायी ज्ञान में नहीं बदलती, जिसे टीम के सभी सदस्य किसी भी समय पुनः उपयोग कर सकें।

समानांतर रूप से AI आया, और लोगों ने डॉक्यूमेंट्स जनरेट करना सीख लिया। इससे एक दूसरी समस्या पैदा हुई: AI slop। किलोमीटरों लंबा टेक्स्ट जनरेट होता है, जिसे कोई पढ़ना नहीं चाहता। पहले भी लोगों को सामान्य, मनुष्यों द्वारा बनाए गए बड़े डॉक्यूमेंट्स पढ़ने के लिए प्रेरित करना मुश्किल था, लेकिन अब यह और खराब हो गया है: व्यक्ति AI slop टेक्स्ट देखता है, पहले पैराग्राफ से समझ जाता है कि इसे मॉडल ने जनरेट किया है और वह इसे पढ़ना या इस पर समय खर्च करना नहीं चाहता। नतीजा यह है कि AI टेक्स्ट बनाने में सक्षम है, लेकिन इससे प्रोडक्ट का काम अपने-आप बेहतर नहीं हो जाता।

असल सवाल कुछ और है: AI को डॉक्यूमेंट्स कैसे सही ढंग से खिलाएँ, ताकि वह वास्तव में प्रोडक्ट का काम चलाने में मदद करे। डॉक्यूमेंट्स फिर भी आवश्यक हैं। लेकिन उन्हें इस तरह व्यवस्थित होना चाहिए कि AI मॉडल उनमें खोज सके, जवाब दे सके, संदर्भ इकट्ठा कर सके और नए लोगों को जल्दी प्रोजेक्ट में शामिल होने में मदद कर सके।

मेरा सरल अनुभव यह है: प्रोडक्ट का काम Codex में Product नाम की फ़ोल्डर के रूप में रहता है। एक बहुत महत्वपूर्ण सिद्धांत: Codex में प्रोजेक्ट स्थानीय डिस्क पर वास्तविक फ़ोल्डर से जुड़ा होना चाहिए। यानी मैं अपने यहाँ Codex नाम की फ़ोल्डर बनाता हूँ, उसके अंदर Product फ़ोल्डर बनाता हूँ, और फिर Codex में existing folder के माध्यम से प्रोजेक्ट बनाकर यह स्थानीय फ़ोल्डर निर्दिष्ट करता हूँ। एक सरल संबंध बनता है: Codex में प्रोजेक्ट स्थानीय डिस्क पर फ़ोल्डर के बराबर है।

अगला कदम: टीम के भीतर अपने स्थानीय फ़ोल्डरों को एक-दूसरे के साथ सिंक्रनाइज़ करने के लिए, आप अपने Product प्रोजेक्ट में Git संरचना बनाते हैं और हर कार्य सत्र के बाद अपडेट्स को टीम के Github में अपलोड करते हैं। टीम के दूसरे सदस्य काम शुरू करने से पहले अपने स्थानीय फ़ोल्डर अपडेट करते हैं और अपडेट्स या नए डॉक्यूमेंट्स बनाते समय साझा Github में कमिट करते हैं। लगभग इसी तरह डेवलपर्स कोड अपडेट के साथ काम करते हैं।

आगे जादू आपकी Product फ़ोल्डर को अलग-अलग चैट्स के अनुसार व्यवस्थित करने से शुरू होता है, जिन्हें एजेंट भी कहा जाता है। आप अपनी Product फ़ोल्डर में काम के लिए आवश्यक प्रत्येक प्रोडक्ट विषय पर अनेक चैट्स बनाते हैं। यहाँ कोई नियम नहीं हैं, आप विषय के रूप में स्टेकहोल्डर्स के साथ kickoffs, टीम के साथ syncs या अन्य टीमों के साथ syncs इस्तेमाल कर सकते हैं। उदाहरण के लिए, हमारे पास एक PRD डॉक्यूमेंट है। मैं PRD के लिए अलग चैट (एजेंट) बनाता हूँ और PRD से संबंधित प्रोडक्ट काम के सभी स्रोत उसमें रखना शुरू करता हूँ। इस प्रकार आप सारी स्रोत जानकारी इस चैट में अपलोड करते हैं, और AI Codex अब आपके PRD डॉक्यूमेंट्स पर काम के संदर्भ के बारे में आवश्यक सब कुछ जानता है।

और शुरुआत में हमारे पास अक्सर कौन-से स्रोत होते हैं? सबसे पहले Google Meet, यानी कार्य बैठकों की बातचीत। Shurick आया, kickoff किया, टास्क दिया। फिर हमने टीम के साथ टास्क पर चर्चा की, और हमारे पास प्राथमिक स्रोत के रूप में कई Google Meet होते हैं। बहुत उच्च-गुणवत्ता की जानकारी, क्योंकि यह सीधे स्रोत से आती है।

यदि कोई नया विषय उभरता है, उदाहरण के लिए PlayCanvas, मैं Product फ़ोल्डर में एक नई चैट (एजेंट) बनाता हूँ और सीधे लिखता हूँ: यहाँ हम PlayCanvas पर सारा प्रोडक्ट काम करेंगे। बनाने के बाद चैट का नाम सही और छोटा रखना अनिवार्य है, ताकि यह समझ में आए कि उसमें किस पर काम हो रहा है। केवल MD फ़ाइलें Codex में स्टोर करना नहीं, बल्कि एक सामान्य कार्यक्षेत्र बनाना महत्वपूर्ण है, जहाँ Codex समझता हो कि हम इस समय किस विषय पर काम कर रहे हैं।

Google Meet की ट्रांसक्रिप्शन के लिए मैं Command Center मिनी-ऐप का उपयोग करता हूँ। Xsolla में मिनी-ऐप्स और डिज़ाइन प्रोटोटाइप्स की संस्कृति है: आप Neuronet के माध्यम से अपने आंतरिक प्रोसेस के लिए ऑटोमेशन को vibe-code कर सकते हैं। मैं Command Center का उपयोग इसी लिए करता हूँ, ताकि Google Meet को मेरे लिए आवश्यक फॉर्मेट में ट्रांसक्रिप्शन में बदल सकूँ।

पहले काम अलग दिखता था: kickoff रिकॉर्ड करना होता था, फिर उसे स्वयं दोबारा देखना, गहराई से पढ़ना, महत्वपूर्ण बातें निकालना और डॉक्यूमेंट बनाना होता था। Shurick के महत्वपूर्ण kickoffs के साथ मैं आज भी मैन्युअली काम करता हूँ, क्योंकि प्राथमिकता ऊँची है, लेकिन हर हफ्ते दर्जनों कॉल्स के लिए प्रोसेसिंग की प्रक्रिया बदल गई है। अब आप एक घंटे की मीटिंग की ट्रांसक्रिप्शन MD फॉर्मेट में ले सकते हैं, उसे आवश्यक प्रोजेक्ट और Codex चैट में अपलोड कर सकते हैं, स्थानीय एजेंट को संदर्भ दे सकते हैं और कह सकते हैं: केवल उस विषय के संबंध में सारांश दो जिसकी मुझे आवश्यकता है। यदि मीटिंग में बहुत कुछ चर्चा हुआ था, लेकिन मेरे लिए केवल एक हिस्सा महत्वपूर्ण है, तो एजेंट तुरंत ठीक उसी प्रासंगिक भाग को निकालने में मदद करता है। इससे बहुत अधिक समय बचता है। सब कुछ तीन क्लिक में काम करता है: ट्रांसक्राइब किया, MD-file को Codex में जोड़ा, एक मिनट का संदर्भ और प्रोसेसिंग टास्क डिक्टेट किया, तैयार परिणाम MD फ़ाइल में या Skill के जरिए सीधे Confluence में मिला।

इसके लिए मेरे Command Center में Google Calendar जुड़ा हुआ है। मैं मीटिंग्स ले सकता हूँ, उन्हें ट्रांसक्राइब कर सकता हूँ, Markdown में बदल सकता हूँ और फिर Product प्रोजेक्ट की Codex फ़ोल्डर में प्रासंगिक एजेंट्स को बाँट सकता हूँ। ये MD-फ़ाइलें जानकारी की स्रोत परत बन जाती हैं: डॉक्यूमेंट के लिए सुंदर डॉक्यूमेंट नहीं, बल्कि ऐसी सामग्री जिसे Codex एजेंट की प्रासंगिक चैट में अपलोड किया जा सकता है, प्रोसेस की हुई MD-फ़ाइल प्राप्त की जा सकती है और उसे आगे काम में लगाया जा सकता है - Neuronet को भेजा जा सकता है, PRD, आर्किटेक्चरल निर्णयों, answers और अन्य प्रोडक्ट आर्टिफैक्ट्स बनाने में इस्तेमाल किया जा सकता है।

यहाँ महत्वपूर्ण लक्ष्य केवल फैशनेबल Markdown-फ़ाइलें बना लेना नहीं है। लक्ष्य यह है कि पूरी टीम एक ही जानकारी के साथ काम करे। और केवल टीम ही नहीं, बल्कि पूरी कंपनी भी, कंपनी के भीतर बहुत से लोग हैं जो Neuronet से Metasites के बारे में कुछ पूछ सकते हैं। यदि हम सर्वोत्तम answers, PRD, आर्किटेक्चरल निर्णय, ट्रांसक्रिप्शन, answers लेते हैं और Neuronet से कहते हैं: Metasites की सारी जानकारी लोड और अपडेट करो, तो वह इस परत को याद रखता है और आगे उसी के आधार पर जवाब दे सकता है।

नतीजतन, हमारे पास एक स्पष्ट सूचना नॉलेज बेस होता है: डॉक्यूमेंट्स, आर्किटेक्चरल निर्णय, PRD, प्रश्नावलियाँ, answers, अतिरिक्त PRD और अन्य सामग्री। यह महत्वपूर्ण है क्योंकि स्टेकहोल्डर्स, शीर्ष प्रबंधन, पार्टनर्स, गेम डेवलपर्स और प्रक्रिया के अन्य प्रतिभागी Neuronet से सवाल पूछते हैं। यदि किसी को कुछ जानना हो, तो उसे प्रोडक्ट लोगों में से किसी एक को निजी संदेश करने की आवश्यकता नहीं होती, वह कंपनी के साझा AI-बेस से Neuronet से पूछ सकता है।

इस तरह हम एक बड़े लक्ष्य को प्राप्त करते हैं: सभी 1600 लोगों को एक ही जानकारी तक पहुँच मिलती है। AI से पहले ऐसे प्रोसेस अक्सर टूटे हुए टेलीफोन की तरह काम करते थे: सात लोगों ने बात की, कुछ तय किया, और बाकी को पता नहीं। बड़ी टीमों में यह एक क्लासिक समस्या है। सूचना के प्रसारण की श्रृंखला जितनी आगे बढ़ती है, उतनी ही अधिक खाई उन लोगों के बीच पैदा होती है जिन्होंने प्रोडक्ट की कल्पना की थी और उन लोगों के बीच जिन्हें बाद में उसके साथ काम करना होता है।

Markdown-फ़ाइलें, Codex और Neuronet ऐसी स्रोत सूचना की परत बनाने में मदद करते हैं जो सभी के लिए उपलब्ध हो। इसके अलावा, कोई भी व्यक्ति इन MD-फ़ाइलों के सेट को Source of Truth के रूप में ले सकता है, उन्हें अपने Codex या Claude Code में अपलोड कर सकता है और मुख्य प्रोडक्ट टीम के समान संदर्भ में 100% आ सकता है। यह विशेष रूप से प्रोजेक्ट के नए प्रतिभागियों के लिए महत्वपूर्ण है: व्यक्ति Codex इंस्टॉल कर सकता है, प्रोजेक्ट बना सकता है, सामग्री उसमें अपलोड कर सकता है और पूछना शुरू कर सकता है: क्या हो रहा है, कौन-से निर्णय पहले ही लिए जा चुके हैं, North Star कहाँ है, कौन-से PRD हैं, kickoff में कौन-सी चर्चाएँ हुई थीं।

इसलिए मैं Metasites की सारी जानकारी Markdown में रखने की कोशिश करता हूँ। यह केवल प्रोडक्ट मैनेजर्स के लिए नहीं, बल्कि डेवलपर्स के लिए भी आवश्यक है। डेवलपर्स नई AI प्रक्रियाओं का अधिक विरोध करते हैं, लेकिन फिर भी यह महत्वपूर्ण है कि प्रोडक्ट से सबसे दूर का डेवलपर भी प्रोजेक्ट का North Star समझे और देखे कि हम कहाँ जा रहे हैं। केवल तीन प्रोडक्ट लोगों को ही यह नहीं जानना चाहिए कि हमारा टास्क क्या है और हमने कौन-से आइडिया सोचे हैं, बल्कि पूरी टीम को समग्र चित्र तक पहुँच होनी चाहिए।

मैं यही MD-फ़ाइलें अपलोड करता हूँ और Neuronet से उन्हें याद रखने को कहता हूँ। इस प्रकार हम अपनी प्रोडक्ट समस्याएँ हल करते हैं और साथ ही उनके समाधान को पूरी कंपनी में फैलाते हैं। हमारे पास केवल डॉक्यूमेंट्स का सेट नहीं, बल्कि एक साझा AI-readable परत होती है: इसे लोग पढ़ सकते हैं, इसे Codex में अपलोड किया जा सकता है, Neuronet में इसके आधार पर प्रश्न पूछे जा सकते हैं, इससे PRD और अन्य कार्य दस्तावेज़ बनाए जा सकते हैं।

AI intro 8 - Product docs - Goals & Answers

Source of Truth

अब महत्वपूर्ण ब्लॉक: आवश्यक Codex चैट या एजेंट में डॉक्यूमेंट का नाम जोड़ने और सभी स्रोत सामग्री अपलोड करने के बाद क्या करना है। स्रोत सामग्री Markdown-फ़ाइलें, Confluence-दस्तावेज़, पुराने PRD, ट्रांसक्रिप्शन, चर्चाओं के जवाब और इस विषय से संबंधित कोई भी अन्य डॉक्यूमेंट हो सकते हैं। केवल उन्हें अपलोड करना पर्याप्त नहीं है। इसके बाद लक्ष्य निर्धारित करना आवश्यक है।

Best Practice

लक्ष्य बहुत सीधे तरीके से तैयार किया जाता है: कृपया Confluence में हमारे आवश्यक डॉक्यूमेंट के लिए best practice ढूँढो। उदाहरण के लिए, यदि हम PRD, आर्किटेक्चरल डॉक्यूमेंट, डेवलपमेंट के लिए टास्क स्पेसिफिकेशन या कोई दूसरा प्रोडक्ट आर्टिफैक्ट बनाना चाहते हैं, तो हम Codex से विशेष रूप से इस प्रकार के डॉक्यूमेंट के लिए कॉर्पोरेट best practice खोजने को कहते हैं। Codex खोजता है कि कौन-सी आवश्यकताएँ हैं, कंपनी में इस डॉक्यूमेंट को कैसे बनाना प्रचलित है, कौन-से सेक्शन अनिवार्य हैं, कौन-से गुणवत्ता मानदंड हैं, कौन-से उदाहरण पहले से मौजूद हैं।

इसके बाद Codex को हमें समझाना चाहिए कि कॉर्पोरेट आवश्यकताओं के अनुसार यह डॉक्यूमेंट सही ढंग से कैसे बनाया जाए। यह एक महत्वपूर्ण कदम है, क्योंकि हम नहीं चाहते कि AI केवल अपने मन से एक सुंदर संरचना बना दे। हमें चाहिए कि भविष्य का डॉक्यूमेंट वास्तविक कॉर्पोरेट फॉर्मेट, स्वीकृत best practice और कंपनी के भीतर ऐसे डॉक्यूमेंट्स पहले से लिखे जाने के तरीके पर आधारित हो।

Template

अगला कदम: हम AI के लिए लक्ष्य निर्धारित करते हैं और कहते हैं, कृपया आवश्यक डॉक्यूमेंट का ऐसा टेम्पलेट बनाओ जो best practice के अधिकतम अनुरूप हो। इस समय तक Codex जानता है कि हमें कौन-सा डॉक्यूमेंट चाहिए, उसने स्रोत सामग्री देखी है और कॉर्पोरेट आवश्यकताओं का अध्ययन कर लिया है। इसलिए वह कोई यादृच्छिक टेम्पलेट नहीं, बल्कि लक्ष्य डॉक्यूमेंट का सबसे सटीक और उच्च-गुणवत्ता वाला टेम्पलेट बना सकता है।

इस टेम्पलेट की मैन्युअल जाँच अनिवार्य है। देखना आवश्यक है कि क्या यह आपके टास्क के अनुकूल है: यह बड़ा है या छोटा, बहुत व्यापक है या बहुत संकीर्ण, इसमें पर्याप्त सेक्शन हैं या नहीं, क्या यह ओवरलोडेड तो नहीं है। यदि आपको छोटा डॉक्यूमेंट चाहिए, तो टेम्पलेट छोटा करना चाहिए। आप सीधे कह सकते हैं: इस टेम्पलेट को अधिक कॉम्पैक्ट बनाओ, हमें एक छोटा कार्य डॉक्यूमेंट चाहिए। यदि आपको अधिकतम विस्तृत डॉक्यूमेंट चाहिए, उदाहरण के लिए डेवलपमेंट के लिए टास्क स्पेसिफिकेशन हेतु, तो इसके विपरीत, टेम्पलेट विस्तृत करने को कहना चाहिए: अधिक सेक्शन, अधिक विवरण, अधिक readiness criteria, जोखिमों, निर्भरताओं और खुले प्रश्नों के लिए अधिक जगह जोड़ो।

इस चरण में आप लक्ष्य टेम्पलेट को अपने टास्क के अनुसार समायोजित करते हैं। यह कोई यांत्रिक ऑपरेशन नहीं है। यहाँ प्रोडक्ट व्यक्ति को देखना और महसूस करना चाहिए: क्या यह टेम्पलेट वास्तव में आवश्यक डॉक्यूमेंट बनाने में मदद करेगा या गलत दिशा में ले जाएगा। Codex एक अच्छा आधार प्रस्तावित कर सकता है, लेकिन आपको ही तय करना है कि किस स्तर का विवरण आवश्यक है।

Questionnaire

जब स्रोत जानकारी अपलोड हो गई हो, best practice और कॉर्पोरेट आवश्यकताओं का अध्ययन हो चुका हो, और टेम्पलेट बनाकर समायोजित कर दिया गया हो, तो Codex से सबसे महत्वपूर्ण वाक्य कहना चाहिए: अब कृपया इस टेम्पलेट और सारी स्रोत जानकारी की तुलना करो और जाँचो कि टेम्पलेट को पूरी तरह और अधिकतम गुणवत्ता के साथ भरने के लिए हमारे पास कौन-सी जानकारी की कमी है।

इसके बाद कहना चाहिए: अनुपस्थित जानकारी के लिए कृपया questionnaire बनाओ, यानी आवश्यक संख्या में प्रश्नों वाली प्रश्नावली। Codex को लक्ष्य टेम्पलेट लेना चाहिए, सभी स्रोत सामग्री लेनी चाहिए, एक की दूसरे से तुलना करनी चाहिए और समझना चाहिए कि कहाँ खाली जगह हैं। हम अभी कौन-से सेक्शन नहीं भर सकते? कौन-से निर्णय दर्ज नहीं हैं? कौन-से assumptions अस्पष्ट हैं? कहाँ बिज़नेस लक्ष्य, यूज़र सिनेरियो, तकनीकी प्रतिबंध, मेट्रिक्स, जोखिम, निर्भरताएँ, acceptance criteria की कमी है?

इस चरण में सावधान रहना चाहिए। Codex 200 प्रश्नों की प्रश्नावली बना सकता है, और ऐसे डॉक्यूमेंट के साथ काम करना बेहद कठिन होगा। मेरी राय में, किसी प्रोडक्ट या डॉक्यूमेंट की अच्छी तैयारी के लिए प्रश्नों की इष्टतम संख्या लगभग 40-80 है। यह अच्छी तरह सोचने और अनुपस्थित जानकारी निकालने के लिए पर्याप्त है, लेकिन प्रक्रिया को अंतहीन प्रश्नावली में नहीं बदलता।

नतीजतन Codex प्रश्नों के साथ एक अलग MD-फ़ाइल बनाता है। यह केवल दिलचस्प प्रश्नों की सूची नहीं है। यह उस जानकारी की सूची है जिसकी उसे लक्ष्य हासिल करने के लिए कमी है: विशिष्ट स्रोत जानकारी के आधार पर विशिष्ट टेम्पलेट भरने के लिए। ऐसा questionnaire कच्चे स्रोतों और गुणवत्तापूर्ण अंतिम डॉक्यूमेंट के बीच पुल बन जाता है।

Answers

अगला कदम: questionnaire वाली इस MD-फ़ाइल को हम Codex में डालते हैं और कहते हैं: अब मुझे इस प्रश्नावली के अनुसार पूछो, हर प्रश्न क्रम से, और परिणामों को answers फ़ाइल में लिखो। और यहाँ प्रोडक्ट काम का सबसे मूल्यवान हिस्सा शुरू होता है।

पहली बात, प्रोडक्ट काम वॉइस-आधारित हो जाता है। Codex प्रश्न 1 पूछता है, आप आवाज़ में जवाब देते हैं। फिर प्रश्न 2, आप जवाब देते हैं। फिर प्रश्न 3, आप जवाब देते हैं। आप अकेले जवाब दे सकते हैं, टीम के साथ मिलकर प्रश्नावली पूरी कर सकते हैं। तुरंत बैठकर आदर्श डॉक्यूमेंट लिखने की आवश्यकता नहीं है। आप बस प्रश्नावली द्वारा पूछे जा रहे प्रश्नों के बारे में जो सोचते हैं, उसका उत्तर देते हैं।

दूसरी बात, प्रोडक्ट काम बहुत अधिक सटीक हो जाता है। यह अब AI-slop, जनरेट किया गया टेक्स्ट का लंबा पुलिंदा नहीं है, बल्कि प्राथमिक स्रोत से आपकी प्रोडक्ट जानकारी है: प्रोडक्ट टीम से, दिशा के मालिक से, उन लोगों से जो वास्तव में समझते हैं कि क्या हो रहा है। Codex आपके लिए प्रोडक्ट नहीं गढ़ता। वह सही ढंग से पूछने, एकत्र करने और उस जानकारी को संरचित करने में मदद करता है जिसे आप जानते हैं।

यह प्रोडक्ट काम के लिए अधिकतम जीवन-परिवर्तन है, क्योंकि अब आपको "खाली पन्ने से" डॉक्यूमेंट्स लिखने की आवश्यकता नहीं है, जो हमेशा अविश्वसनीय रूप से कठिन और श्रमसाध्य था। और आपको अपने प्रोडक्ट के संदर्भ से असंबद्ध AI slop जनरेट करने की भी आवश्यकता नहीं है। आप स्वयं, सीधे स्रोत से, अपने ज्ञान, विचारों, आइडियाज़ के आधार पर अपनी आवाज़ से कंटेंट बनाते हैं।

जवाबों की प्रक्रिया में प्रश्नों की गुणवत्ता पर नज़र रखनी चाहिए। समय के साथ आप महसूस करना शुरू कर देंगे कि अच्छे प्रश्न आ रहे हैं या नहीं। यदि प्रश्न दोहराए जाते हैं, बहुत एकरूप, बहुत अमूर्त हैं या सोचने में मदद नहीं करते, तो कोई समस्या नहीं। आप तुरंत Codex से कह सकते हैं: ये प्रश्न बहुत एकरूप हैं, प्रश्नों को अधिक सटीक, अधिक प्रोडक्ट-केंद्रित, अधिक विविध, इस विषय या किसी दूसरे विषय के सार के अनुसार बनाओ। प्रश्नावली को चलते-चलते समायोजित किया जा सकता है, और उसके बाद अगले प्रश्न अधिक से अधिक सटीक होंगे।

नतीजतन आपको एक बहुत शक्तिशाली answers-फ़ाइल मिलती है। मूल रूप से, यह प्रोडक्ट के बारे में जानकारी का प्राथमिक स्रोत है। यह प्रोडक्ट टीम से सीधे स्रोत की जानकारी है। ऐसी फ़ाइल को प्रोजेक्ट के source of truth के रूप में उपयोग किया जा सकता है: Neuronet में अपलोड करना, नए लोगों को देना, Codex में जोड़ना, भविष्य के डॉक्यूमेंट्स के आधार के रूप में उपयोग करना।

इसके बाद ही हम अंतिम डॉक्यूमेंट की ओर बढ़ते हैं। अंतिम कमांड इस तरह है: हमारे answers और सारी स्रोत जानकारी के आधार पर टेम्पलेट भरो। अब Codex खालीपन में काम नहीं करता। उसके पास कॉर्पोरेट best practice, लक्ष्य टेम्पलेट, स्रोत सामग्री और प्रश्नों के प्रोडक्ट टीम के जवाब हैं, जो सूचना के अंतराल को भरते हैं।

इसीलिए अंतिम डॉक्यूमेंट AI-slop नहीं, बल्कि सार के आधार पर एक गुणवत्तापूर्ण डॉक्यूमेंट बनता है। यह वास्तविक जानकारी से संकलित है, प्रश्नों के माध्यम से जाँचा गया है, सही टेम्पलेट के अनुसार संरचित है और उस फॉर्मेट के अनुरूप है जिसकी कंपनी को आवश्यकता है। यह किसी खाली चैट में "PRD लिखो" कहने की तुलना में कार्य का मूलतः अलग स्तर है।

जनरेशन के बाद अंतिम डॉक्यूमेंट की जाँच करनी चाहिए। टाइपोज़ बदलने के लिए skill या अलग पास लागू करना चाहिए, विशेषकर टर्म्स में, क्योंकि प्रोडक्ट डॉक्यूमेंट्स में अक्सर नाम, आंतरिक टर्म्स, प्रोडक्ट्स के नाम और तकनीकी फॉर्म्युलेशन बिगड़ जाते हैं। फिर डॉक्यूमेंट स्वयं पढ़ना चाहिए।

जब आप यह प्रोसेस अच्छी तरह करना सीख जाएँगे, तो अंतिम डॉक्यूमेंट्स बहुत सटीक बनेंगे और उन्हें काफी जल्दी देखा जा सकेगा। लेकिन शुरुआती चरणों में ध्यान से प्रूफरीड करना बेहतर है। इस तरह आप महसूस करना शुरू करेंगे कि AI कहाँ आपके विचारों और आइडियाज़ को पर्याप्त गुणवत्ता से ट्रांसफर नहीं करता, कहाँ वह महत्वपूर्ण विवरण को चिकना कर देता है, कहाँ जवाब की गलत व्याख्या करता है, कहाँ टेम्पलेट बनाने या भरने के प्रॉम्प्ट को सुधारने की आवश्यकता है।

मैं इस मैकेनिज्म का उपयोग करने की दृढ़ता से अनुशंसा करता हूँ। यह सभी को एक ही पेज पर रहने में मदद करता है। और केवल उन तीन प्रोडक्ट लोगों को नहीं जिन्होंने मीटिंग में प्रोडक्ट पर चर्चा की थी, बल्कि पूरी प्रोजेक्ट टीम और पूरी कंपनी को। हमारे पास बातचीत और बिखरे स्रोतों को गुणवत्तापूर्ण डॉक्यूमेंट्स, answers, source of truth और प्रोडक्ट के बारे में ज्ञान की साझा परत में बदलने का एक साझा तरीका आता है।

AI intro 8 - Product docs - workflow

यदि व्यावहारिक workflow तैयार करें, तो यह ऐसा दिखता है।

पहले स्थानीय प्रोजेक्ट फ़ोल्डर बनाते हैं और उसे existing folder के माध्यम से Codex में जोड़ते हैं। महत्वपूर्ण है कि Codex-प्रोजेक्ट वास्तविक फ़ाइल संरचना से जुड़ा हो, न कि कहीं अमूर्त रूप से मौजूद हो।

फिर प्रोजेक्ट के भीतर विषयगत एजेंट्स - चैट्स बनाते हैं: PRD, आर्किटेक्चरल निर्णय, answers, स्रोत, kickoff, अलग-अलग प्रोडक्ट दिशाएँ। नाम स्पष्ट होने चाहिए, क्योंकि यह संरचना प्रोजेक्ट के नक्शे के रूप में काम करेगी।

इसके बाद प्राथमिक स्रोत एकत्र करते हैं: kicoffs. Google Meet ट्रांसक्रिप्शन, Loom, नोट्स, पुराने डॉक्यूमेंट्स, Confluence सामग्री, लिंक्स, चर्चाओं के जवाब। उन्हें विषयगत फ़ोल्डरों में रखा जा सकता है, या सही Codex चैट अथवा एजेंट में अटैचमेंट्स के रूप में जोड़ा जा सकता है। इस चरण में तुरंत आदर्श अंतिम डॉक्यूमेंट बनाने की कोशिश नहीं करनी चाहिए। पूरी स्रोत सूचना परत एकत्र करना महत्वपूर्ण है।

आगे कॉल्स और मीटिंग्स को Markdown में बदलते हैं। इसके लिए Command Center या ट्रांसक्रिप्शन के लिए कोई दूसरा मिनी-ऐप इस्तेमाल किया जा सकता है। मुख्य बात यह है कि परिणाम टेक्स्ट रूप में हो, प्रोजेक्ट फ़ोल्डर में रहे और Codex के लिए उपलब्ध हो।

फिर Codex से लक्ष्य डॉक्यूमेंट के लिए कॉर्पोरेट best practice खोजने को कहते हैं: PRD, आर्किटेक्चरल डॉक्यूमेंट, टास्क स्पेसिफिकेशन, स्ट्रैटेजी या कोई अन्य फॉर्मेट। Codex को समझना चाहिए कि कंपनी के भीतर ऐसा डॉक्यूमेंट कैसे बनाना प्रचलित है।

इसके बाद Codex से मिली हुई best practice के अनुसार लक्ष्य डॉक्यूमेंट का टेम्पलेट बनाने को कहते हैं। टेम्पलेट को मैन्युअली जाँचते और समायोजित करते हैं: यदि कॉम्पैक्ट डॉक्यूमेंट चाहिए तो छोटा करते हैं, या यदि गहरी टास्क स्पेसिफिकेशन चाहिए तो अधिक विस्तृत करते हैं।

फिर Codex से टेम्पलेट की सारी स्रोत जानकारी के साथ तुलना करने और यह निर्धारित करने को कहते हैं कि कौन-सी जानकारी की कमी है। इन अंतरालों के आधार पर Codex questionnaire बनाता है - प्रश्नों वाली अलग MD-फ़ाइल। प्रश्नावली को लगभग 40-80 प्रश्नों के दायरे में रखना इष्टतम है, ताकि वह पर्याप्त गहरी हो, लेकिन फिर भी उपयोगी बनी रहे।

आगे Codex से questionnaire के अनुसार एक-एक करके प्रश्न पूछने और जवाबों को answers में दर्ज करने को कहते हैं। इस चरण में हम आवाज़ या टेक्स्ट द्वारा प्राथमिक स्रोत से प्रोडक्ट जानकारी देते हैं, और Codex उसे सावधानी से संरचित फ़ाइल में एकत्र करता है।

इसके बाद Codex से answers और सारी स्रोत जानकारी के आधार पर टेम्पलेट भरने को कहते हैं। इस तरह अंतिम डॉक्यूमेंट बनता है, जो वास्तविक स्रोतों, कॉर्पोरेट आवश्यकताओं और टीम के जवाबों पर आधारित होता है, न कि खाली जनरेशन पर।

अंत में डॉक्यूमेंट की जाँच करते हैं: प्रूफरीड करते हैं, टाइपोज़ और टर्म्स के लिए पास लगाते हैं, देखते हैं कि आइडियाज़ सही तरह ट्रांसफर हुए हैं या नहीं। यदि दिखता है कि AI ने कहीं विचार को पर्याप्त सटीकता से नहीं समझा, तो प्रॉम्प्ट समायोजित करते हैं या answers पर लौटते हैं।

और अंततः, चयनित और सामान्यीकृत परत को Neuronet या किसी अन्य साझा AI नॉलेज बेस में अपलोड करते हैं, ताकि केवल डॉक्यूमेंट का लेखक ही नहीं, बल्कि पूरी टीम एक ही सत्य स्रोत से प्रश्न पूछ सके और जवाब प्राप्त कर सके।

AI intro 8 - Product docs - Markdowns

अब अलग से प्रोडक्ट डॉक्यूमेंट्स की स्टोरेज संरचना के बारे में। हम AI-first सिद्धांतों के अनुसार नई संरचना बनाते हैं। डॉक्यूमेंट्स के सभी स्रोत Markdown में होने चाहिए। यह महत्वपूर्ण है, क्योंकि Markdown को मनुष्य, Codex, Claude Code, Neuronet और अन्य AI-टूल्स समान रूप से अच्छी तरह पढ़ते हैं। Markdown को सुविधाजनक रूप से मैन्युअली पढ़ने के लिए self-hosted Obsidian या Sublime Text का उपयोग किया जा सकता है। मुख्य बात यह है कि डॉक्यूमेंट्स सरल टेक्स्ट फ़ाइलें बने रहें, जिन्हें रिपॉज़िटरी में रखा जा सकता है, कमिट किया जा सकता है, पढ़ा जा सकता है, खोजा जा सकता है और AI में अपलोड किया जा सकता है।

ऐसे डॉक्यूमेंट्स के साथ काम करने के लिए प्रत्येक प्रतिभागी अपने Codex या Claude Code में प्रोजेक्ट बना सकता है और इस रेपो के साथ सिंक कर सकता है। कमिट किया जा सकता है, लेकिन एक महत्वपूर्ण नियम है: पहले से बने डॉक्यूमेंट्स को अलग कारण और सहमति के बिना न बदलें। यदि नए प्रोडक्ट डॉक्यूमेंट की आवश्यकता है, तो हम पुराने को फिर से नहीं लिखते, बल्कि नई वर्ज़न के नोट के साथ नई फ़ाइल बनाते हैं। यह इतिहास को संरक्षित रखता है, यह समझने देता है कि जानकारी कहाँ से आई, और पहले से दर्ज आर्टिफैक्ट्स को नहीं तोड़ता।

फ़ोल्डरों की संरचना डॉक्यूमेंट्स की भूमिका के अनुसार बनाई गई है। ऊपरी स्तर सामग्री को source of truth, secondary documents, calls और उसके बाद उन विशिष्ट प्रोडक्ट डॉक्यूमेंट्स की फ़ोल्डरों में बाँटता है जो अभी प्रासंगिक हैं और तैयार किए जा रहे हैं। यानी सबसे मूल्यवान प्राथमिक जानकारी अलग रहती है, द्वितीयक सामग्री अलग, कॉल्स अलग, और विशिष्ट PRD, ADR, स्ट्रैटेजीज़, टास्क स्पेसिफिकेशंस और अन्य डॉक्यूमेंट्स के लिए कार्य फ़ोल्डर अलग रहते हैं।

कार्य फ़ोल्डरों के भीतर एक सरल भाषाई नियम लागू होता है: अंग्रेज़ी फ़ाइलें रूट में रहती हैं, रूसी फ़ाइलें RU फ़ोल्डर में रहती हैं। इससे वर्ज़न मिश्रित नहीं होते, आवश्यक फ़ाइल जल्दी मिलती है और नामों में अराजकता नहीं बढ़ती। यदि डॉक्यूमेंट दो भाषाओं में एक साथ तैयार हो रहा है, तो संरचना को शुरुआत से ही इस विभाजन का समर्थन करना चाहिए।

अब सभी डॉक्यूमेंट्स खाली पन्ने से नहीं लिखे जाते। हम उन्हें पहले वर्णित प्रक्रिया के माध्यम से तैयार करते हैं: Codex या Claude Code को अनुरोध और स्रोत डॉक्यूमेंट्स देते हैं, आवश्यक डॉक्यूमेंट के लिए best practice template पूछते हैं, सभी प्रासंगिक MD-फ़ाइलें लोड करते हैं, यह निर्धारित करने को कहते हैं कि कौन-सी जानकारी की कमी है, और questionnaire बनाने को कहते हैं। यदि questionnaire बहुत बड़ा बनता है, उदाहरण के लिए 100+ प्रश्नों का, तो उसे समायोजित करना चाहिए। आमतौर पर लगभग 50 प्रश्न पर्याप्त होते हैं, कभी-कभी डॉक्यूमेंट व्यापक होने पर 40-80।

आगे questionnaire को Claude Code या Codex में "पूछो - आवाज़ में जवाब स्वीकार करो" मोड में अपलोड किया जाता है। हम डॉक्यूमेंट के सभी प्रश्नों के जवाब देते हैं। यदि हमें स्वयं नहीं पता कि क्या जवाब देना है, तो प्रश्नावली को ज्ञान के मालिक या प्रोडक्ट टीम को भेजा जा सकता है। हमारे संदर्भ में, यह उदाहरण के लिए @d.dolgov हो सकता है: यह और भी बेहतर है, क्योंकि जवाब सीधे स्रोत से आते हैं, मॉडल द्वारा अनुमान से पूरे नहीं किए जाते।

जवाबों के बाद हम best practice template, समेकित डेटाबेस और answers के आधार पर आवश्यक डॉक्यूमेंट बनाने की कमांड देते हैं। यहाँ समेकित डेटा से आशय सारी एकत्रित जानकारी है: स्रोत MD, Confluence, ट्रांसक्रिप्शन, source of truth, secondary documents, answers और अतिरिक्त स्पष्टीकरण।

यदि प्राप्त डॉक्यूमेंट पसंद नहीं आता, तो यह सामान्य है। उदाहरण के लिए, डेवलपमेंट टीम ADR देख सकती है और कह सकती है कि डॉक्यूमेंट का फॉर्मेट या संरचना उपयुक्त नहीं है। इस स्थिति में शून्य से शुरू करने की आवश्यकता नहीं है। Narrative Leader या किसी अन्य प्राथमिक स्रोत के पहले से तैयार answers.md का उपयोग करके डॉक्यूमेंट का फॉर्मेट या संरचना फिर से लिखी जा सकती है। Answers एक मूल्यवान आधार है, उसे केवल इसलिए नहीं फेंकना चाहिए कि अंतिम डॉक्यूमेंट का पहला संस्करण असफल रहा।

यदि दोबारा लिखने की प्रक्रिया में नई जानकारी, स्पष्टीकरण या निर्णय जुड़ते हैं, तो उनके लिए Markdown में अलग आर्टिफैक्ट या handoff रहना चाहिए। इस फ़ाइल को GitHub में इस डॉक्यूमेंट की फ़ोल्डर में कमिट करना चाहिए। उदाहरण के लिए, यदि बात ADR की है, तो ऐसा handoff ADR फ़ोल्डर में होना चाहिए। यह नियम हमें संदर्भ खोने से बचाता है: कोई भी नया इनपुट स्रोतों में रहना चाहिए, केवल अंतिम टेक्स्ट में घुलकर समाप्त नहीं होना चाहिए।

यदि प्रोडक्ट टीम से स्पष्टीकरण वाले प्रश्न चाहिए, तो उन्हें तुरंत Markdown में एक और प्रश्नावली के रूप में तैयार किया जा सकता है। इस दृष्टिकोण के साथ जवाब तेज़ होंगे, क्योंकि लोगों के लिए बड़े डॉक्यूमेंट को पढ़ने और स्वयं ढूँढने की तुलना में विशिष्ट प्रश्नों का जवाब देना आसान होता है कि कहाँ स्पष्टीकरण चाहिए।

साझा Source of Truth फ़ोल्डर में देखना भी उपयोगी है, जहाँ प्रोडक्ट की सबसे मूल्यवान जानकारी रहती है। नया डॉक्यूमेंट बनाने से पहले Codex या Claude Code में केवल वर्तमान सामग्री ही नहीं, बल्कि पूर्ववर्ती प्रश्नावलियाँ और answers भी लोड किए जा सकते हैं। यदि Source of Truth में पहले से सीधे स्रोत की अधिकतम सटीक जानकारी वाले 80, 120 या 200 प्रश्न और जवाब हैं, तो यह एक विशाल संदर्भ है जिसे नज़रअंदाज़ नहीं किया जा सकता।

Source of Truth के सभी डॉक्यूमेंट्स को अतिरिक्त रूप से Confluence में, Metas/Metasdev स्पेस में डुप्लिकेट किया जाता है, और फिर Neuronet और Slack में अपलोड किया जाता है। अभी यह मैन्युअली किया जा सकता है, बाद में ऐसे सिंक्रनाइज़ेशन को ऑटोमेट किया जा सकता है। अर्थ यह है कि Markdown-रिपॉज़िटरी AI-readable स्रोत और कार्य आधार बनती है, जबकि Confluence लोगों के लिए पढ़ने और नेविगेशन की परिचित जगह बना रहता है।

यदि इस क्रम को कई प्रोडक्ट इटरेशंस तक लगातार किया जाए, तो हमारे पास प्राथमिक स्रोत में हमेशा उपलब्ध प्रोडक्ट जानकारी की एक गंभीर परत होगी। यह टूटे हुए टेलीफोन के बिना जानकारी है, जो सभी दिशाओं में पूरी टीम के लिए उपलब्ध है। और यह अपने-आप में पहले से ही बहुत मजबूत परिणाम है: हम केवल डॉक्यूमेंट्स नहीं लिखते, बल्कि प्रोडक्ट मेमोरी बनाते हैं जिसे पढ़ा, विस्तृत, पुनः उपयोग और AI में अपलोड किया जा सकता है।

मुख्य सिद्धांत: Markdown-डॉक्यूमेंट्स Markdown के लिए नहीं बनाए जाते। इनकी आवश्यकता बातचीत, मीटिंग्स और बिखरे निर्णयों को ज्ञान की एक साझा परत में बदलने के लिए है, जिसके साथ लोग और AI काम कर सकें। इस प्रक्रिया में Codex स्थानीय प्रोडक्ट काम का कार्य उपकरण है: वह फ़ोल्डर पढ़ता है, स्रोतों को संरचित करने, डॉक्यूमेंट्स एकत्र करने, चर्चा का प्रासंगिक हिस्सा निकालने और प्रोजेक्ट संदर्भ बनाए रखने में मदद करता है।

इस स्कीम में Neuronet पहले से तैयार की गई जानकारी को अधिक व्यापक रूप से फैलाने का तरीका बनता है: कंपनी, पार्टनर्स, डेवलपर्स, मैनेजर्स और उन सभी तक जिन्हें समझना चाहिए कि क्या हो रहा है। यदि इस प्रोसेस को सही ढंग से बनाया जाए, तो हम उन लोगों के बीच की दूरी कम करते हैं जिन्होंने प्रोडक्ट की कल्पना की और उन लोगों के बीच जिन्हें बाद में उसे बनाना, बेचना, सपोर्ट करना या समझाना है।

इसीलिए हम MD-फ़ाइलों, Codex और Neuronet के साथ किसी फैशनेबल खिलौने की तरह नहीं, बल्कि प्रोडक्ट मेमोरी के इन्फ्रास्ट्रक्चर की तरह काम करते हैं। बातचीत स्वयं गायब हो जाती है। Loom स्वयं सभी नहीं देखेंगे। बड़ा AI-डॉक्यूमेंट स्वयं कोई नहीं पढ़ेगा। लेकिन Markdown में स्रोत जानकारी की सुव्यवस्थित परत को पढ़ा, खोजा, Codex में अपलोड किया, Neuronet में अपडेट किया और प्रोडक्ट काम के लिए एक जीवित आधार के रूप में उपयोग किया जा सकता है।