AI से PRD कैसे लिखें (मुफ़्त टेम्पलेट के साथ)

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

यह गाइड बताती है कि PRD में क्या होना चाहिए, किसी भी AI असिस्टेंट के साथ उसका ड्राफ़्ट बनाने का चरण-दर-चरण तरीका, हर सेक्शन के लिए prompts, और एक भरने योग्य टेम्पलेट जिसे आप कॉपी कर सकते हैं।

PRD क्या है और क्या नहीं

PRD चार सवालों का जवाब देता है:

1. क्यों बना रहे हैं? कौन सी समस्या, किसके लिए?
2. पहले संस्करण में क्या करना होगा?
3. अभी क्या नहीं करेगा?
4. कैसे पता चलेगा कि यह काम कर गया?

यह कोई तकनीकी डिज़ाइन नहीं है। इसमें यह नहीं लिखा जाता कि कौन सा डेटाबेस या फ़्रेमवर्क इस्तेमाल होगा; वह अलग तकनीकी स्पेक में आता है, अगर उसकी ज़रूरत हो। यह मार्केटिंग ब्रीफ़ या बिज़नेस प्लान भी नहीं है। PRD को प्रोडक्ट के व्यवहार तक सीमित रखना ही उसे हर पढ़ने वाले के लिए काम का बनाता है: डिज़ाइनर, डेवलपर, मंज़ूरी देने वाला स्टेकहोल्डर, या AI app builder जो उसे कोड में बदलता है।

किसे इसकी ज़रूरत है

• अकेले फ़ाउंडर जो scope creep को शुरू होने से पहले रोकना चाहते हैं।
• छोटी टीमें जिन्हें एक ऐसी जगह चाहिए जहाँ “जो तय हुआ” लिखा रहे।
• कोई फ़्रीलांसर या एजेंसी किराए पर लेने वाले, क्योंकि साफ़ PRD से साफ़ कोट मिलते हैं। देखें डेवलपर किराए पर लें या AI से बनाएं।
• AI से बनाने वाले लोग, क्योंकि PRD की यूज़र स्टोरी और डेटा सूची बिना ढाँचे की इच्छा-सूची से बेहतर prompts बनाती है।

AI क्या अच्छा करता है और क्या नहीं

सबसे आम गलती यह है कि AI यूज़र, बाज़ार के आकार या व्यवहार के बारे में भरोसे से संभावित अनुमान भर देता है। इसलिए यूज़र, बाज़ार या व्यवहार के बारे में उसने जो भी लिखा हो, उसे तथ्य नहीं, जाँचने योग्य सवाल मानें।

चरण 1: जो आप जानते हैं वह सब लिखें

कोई भी prompt देने से पहले कच्चे नोट्स लिखें। बुलेट पॉइंट चलेंगे। इनमें शामिल करें:

• समस्या, एक या दो वाक्य में, यूज़र के नज़रिए से।
• किसे यह समस्या है। सटीक रहें: “10–40 क्लाइंट वाले फ़्रीलांस बुककीपर”, न कि “छोटे बिज़नेस”।
• वे आज इसके बजाय क्या करते हैं (स्प्रेडशीट, ईमेल, कोई टूल जो उन्हें पसंद नहीं)।
• वह एक नतीजा जो पहले संस्करण को सफल बनाए।
• जो आप पहले से जानते हैं कि नहीं करेंगे।
• सख़्त शर्तें: डेडलाइन, बजट, फ़ोन पर चलना ज़रूरी है, या कोई टूल जो आप पहले से इस्तेमाल करते हैं उससे जुड़ना है।

अगर आपने उस समस्या वाले किसी व्यक्ति से बात नहीं की है, तो पहले वह करें। ऐप आइडिया कैसे परखें में इसका व्यावहारिक तरीका है। अंदाज़ों पर बना PRD एक अच्छे फ़ॉर्मेट वाला अंदाज़ा ही है।

चरण 2: AI से पहला ड्राफ़्ट माँगें

अपने नोट्स चिपकाएं और एक तय ढाँचे में ड्राफ़्ट माँगें। एक prompt जो अच्छा काम करता है:

मेरे एक प्रोडक्ट के नोट्स यहाँ हैं। इन्हें ठीक इन सेक्शनों वाले product requirements document में बदलें: सारांश, समस्या, यूज़र, लक्ष्य और सफलता के मेट्रिक, दायरा (in / out), acceptance criteria वाली यूज़र स्टोरी, डेटा, परमिशन, एज केस, Open questions। दो पेज से कम रखें। यूज़र या बाज़ार के बारे में तथ्य न गढ़ें; जहाँ मेरे नोट्स चुप हैं, वहाँ सवाल Open questions में लिखें।

आख़िरी निर्देश सबसे ज़रूरी है। AI से कहना कि अज्ञात बातों को भरने के बजाय Open questions में डाले, कहीं ज़्यादा ईमानदार ड्राफ़्ट देता है।

चरण 3: हर सेक्शन को कसें

ड्राफ़्ट को सेक्शन-दर-सेक्शन देखें। ये फ़ॉलो-अप prompts मदद करते हैं:

समस्या और यूज़र

समस्या का बयान एक या दो वाक्यों में फिर से लिखें, यूज़र के नज़रिए से। कोई समाधान वाले शब्द नहीं।

अगर समस्या के बयान में आपके प्रोडक्ट का ज़िक्र है, तो वह समस्या नहीं बल्कि समाधान बता रहा है।

लक्ष्य और सफलता के मेट्रिक

पहले संस्करण के लिए तीन सफलता मेट्रिक सुझाएँ जिन्हें मैं पहले महीने में कुछ यूज़र के साथ माप सकूँ। हर एक के लिए बताएँ कि मैं उसे कैसे मापूँगा।

एक या दो चुनें। “बीस बुककीपर एक महीने तक हफ़्ते में एक बार इसे इस्तेमाल करें” मापने योग्य है। “उत्पादकता बेहतर करें” नहीं है।

दायरा

इस PRD में वह सब बताएँ जिसे बिना मुख्य फ़्लो तोड़े बाद के संस्करण में ले जाया जा सकता है।

AI टूल अक्सर फ़ीचर जोड़ते हैं। यह prompt उल्टा करवाता है। बेरहम रहें: ज़्यादातर पहले संस्करण के PRD बहुत बड़े होते हैं। MVP क्या है बताता है कि छोटे पहले संस्करण आपको ज़्यादा क्यों सिखाते हैं।

यूज़र स्टोरी और acceptance criteria

हर ज़रूरत को यूज़र स्टोरी के रूप में लिखें (“[यूज़र] के रूप में, मैं [कार्य] चाहता हूँ ताकि [नतीजा]”) और हर एक के साथ दो से चार acceptance criteria Given / When / Then रूप में।

Acceptance criteria वह चेकलिस्ट है जिस पर बाद में टेस्ट करेंगे। “दिया गया स्लॉट बुक है, जब कोई दूसरा क्लाइंट कैलेंडर देखे, तब वह स्लॉट न दिखे” परखने योग्य है। “बुकिंग अच्छे से काम करे” नहीं है।

एज केस और परमिशन

हर यूज़र स्टोरी के लिए बताएँ कि खाली डेटा, गलत इनपुट, धीमे या विफल नेटवर्क अनुरोध, और ऐसे यूज़र के साथ क्या होता है जिसे एक्सेस नहीं होना चाहिए।

यहीं AI काम आता है। खाली स्क्रीन और परमिशन की वे खामियाँ जो लोग भूल जाते हैं, उन्हें वह जल्दी पकड़ लेता है।

चरण 4: संदेह भरी नज़र से जाँचें

पूरा दस्तावेज़ एक बार फिर पढ़ें और देखें:

• यूज़र के बारे में हर दावा आपसे या रिसर्च से आया है, AI से नहीं।
• Scope “out” कम से कम “in” जितना लंबा है।
• हर यूज़र स्टोरी की acceptance criteria ऐसी हैं कि कोई आपसे पूछे बिना उन्हें टेस्ट कर सके।
• डेटा सेक्शन में ऐप द्वारा रखे जाने वाले हर तरह के रिकॉर्ड और उन्हें कौन देख सकता है, यह लिखा है।
• Open questions में हर सवाल का एक ज़िम्मेदार व्यक्ति और तारीख है।
• कोई तकनीकी बात तभी है जब वह असली शर्त हो (“ऑफ़लाइन चलना चाहिए” एक ज़रूरत है; “Redis इस्तेमाल करें” नहीं)।

फिर इसे एक ऐसे व्यक्ति के साथ साझा करें जो प्रोडक्ट इस्तेमाल करेगा या बनाएगा, और पूछें कि क्या अस्पष्ट है। उनके सवाल ही कमियाँ हैं।

भरने योग्य PRD टेम्पलेट

इसे एक डॉक में कॉपी करें और कोष्ठकों की जगह भरें। जो सेक्शन सच में लागू न हो, उसे हटा दें।

प्रोडक्ट का नाम: [नाम] ज़िम्मेदार: [फ़ैसलों के लिए ज़िम्मेदार व्यक्ति] स्थिति: [ड्राफ़्ट / समीक्षा में / सहमत] — आख़िरी अपडेट: [तारीख]

1. सारांश

[दो या तीन वाक्य: यह क्या है, किसके लिए है, और मुख्य नतीजा।]

2. समस्या

[यूज़र के नज़रिए से समस्या। वे आज क्या करते हैं और क्यों तकलीफ़ होती है।]

3. यूज़र

4. लक्ष्य और सफलता के मेट्रिक

• लक्ष्य: [वह नतीजा जो पहला संस्करण हासिल करे]
• मेट्रिक: [उसे कैसे मापेंगे, और लक्ष्य]
• गैर-लक्ष्य: [कुछ जो लोग मान सकते हैं, पर यह संस्करण उसे नहीं कर रहा]

5. दायरा

पहले संस्करण में:

• [फ़ीचर]
• [फ़ीचर]

पहले संस्करण में नहीं:

• [फ़ीचर, और यह क्यों रुक सकता है]
• [फ़ीचर, और यह क्यों रुक सकता है]

6. यूज़र स्टोरी

स्टोरी 1: [यूज़र] के रूप में, मैं [कार्य] चाहता हूँ ताकि [नतीजा]।

• दिया गया [संदर्भ], जब [कार्य], तब [परिणाम]।
• दिया गया [संदर्भ], जब [कार्य], तब [परिणाम]।

स्टोरी 2: [यूज़र] के रूप में, मैं [कार्य] चाहता हूँ ताकि [नतीजा]।

• दिया गया [संदर्भ], जब [कार्य], तब [परिणाम]।

7. डेटा

8. परमिशन

[कौन लॉगिन कर सकता है, कौन सी भूमिकाएँ हैं, और हर भूमिका क्या देख और बदल सकती है।]

9. एज केस

• [खाली स्थिति: जब अभी कोई डेटा न हो तो क्या दिखे]
• [गलत इनपुट: गलत ईमेल या छूटे फ़ील्ड पर क्या हो]
• [एक्सेस: कोई ऐसा पेज खोले जिसे नहीं खोलना चाहिए तो क्या हो]

10. इंटीग्रेशन और शर्तें

[पेमेंट, ईमेल, मौजूदा टूल, डेडलाइन, बजट, वे डिवाइस जिन पर चलना ज़रूरी है।]

11. Open questions

PRD से prompts तक

एक अच्छा PRD लगभग सीधे AI app builder के लिए prompts में बदल जाता है:

• सारांश, यूज़र और डेटा टेबल आपका पहला prompt बनते हैं।
• हर यूज़र स्टोरी एक फ़ॉलो-अप prompt बनती है।
• हर acceptance criterion वह चीज़ है जिसे आप प्रिव्यू में टेस्ट करते हैं।
• “पहले संस्करण में नहीं” वाली सूची वह है जिसे आप अभी माँगने से मना करते हैं।

पूरा PRD चिपकाकर सब कुछ माँगने के बजाय, एक-एक स्टोरी बनाना और आगे बढ़ने से पहले उसकी acceptance criteria जाँचना कहीं ज़्यादा भरोसेमंद है। AI ऐप बिल्डर के लिए prompt कैसे लिखें में prompt वाले हिस्से की और जानकारी है।

आम गलतियाँ

• समाधान को समस्या बना देना। “यूज़र को डैशबोर्ड चाहिए” एक समाधान है। “मालिक बिना हर इनवॉइस खोले नहीं देख पाते कि कौन से इनवॉइस की तारीख निकल गई” समस्या है।
• “Out of scope” सेक्शन न होना। उसके बिना हर बातचीत में दायरा फिर खुल जाता है।
• AI को यूज़र गढ़ने देना। AI के बनाए पर्सोना असली लगते हैं, पर होते नहीं।
• ऐसे मेट्रिक जिन्हें आप माप नहीं सकते। अगर उसे गिनने का तरीका नहीं, तो वह मेट्रिक नहीं है।
• कभी अपडेट न करना। जो PRD वह नहीं बताता जो आप बना रहे हैं, वह कुछ न होने से भी बुरा है। “आख़िरी अपडेट” की तारीख रखें और फ़ैसले बदलने पर उसे बदलें।

Mythex में PRD का इस्तेमाल

अगर आप Mythex में बनाते हैं, तो अपना PRD सीधे चैट में चिपका सकते हैं। PRD के लिए Plan मोड अच्छा फ़िट है: एजेंट उसे पढ़ता है, एक तरीका और चरणों की चेकलिस्ट प्रस्तावित करता है जिसे आप प्लान टैब में देख सकते हैं, और फ़ाइलें तभी बदलता है जब आप Build दबाते हैं। आप वे हिस्से, जैसे ऑडियंस, ब्रांड और नियम, प्रोजेक्ट नॉलेज के रूप में भी सहेज सकते हैं ताकि हर चैट में दोहराना न पड़े। चैट डॉक्स में Build, Plan और Ask मोड समझाए गए हैं, और टेम्पलेट देखकर आप पूरा दस्तावेज़ लिखने से पहले एक पहले संस्करण की झलक ले सकते हैं।

सवाल