AI سے Product Requirements Doc کیسے لکھیں (مفت ٹیمپلیٹ)

پروڈکٹ ریکوائرمنٹ ڈاکیومنٹ (PRD) ایک مختصر، سادہ زبان میں لکھی گئی وضاحت ہے کہ آپ کیا بنا رہے ہیں، یہ کس کے لیے ہے، اسے کیا کرنا ہے، اور آپ کیسے جانیں گے کہ یہ کام کرتا ہے۔ AI اسے لکھنا کہیں تیز کر دیتا ہے: آپ اسے کچے نوٹس دیتے ہیں اور وہ انہیں ساختی حصوں، user stories اور ایج کیسز میں بدل دیتا ہے۔ آپ کا کام وہ فیصلے فراہم کرنا ہے جو AI نہیں کر سکتا — مقصد، دائرہ کار اور کیا چھوڑنا ہے — اور جو وہ شامل کرے اسے جانچنا۔

یہ گائیڈ بتاتی ہے کہ PRD میں کیا شامل ہونا چاہیے، AI کے ساتھ اسے ڈرافٹ کرنے کا مرحلہ وار طریقہ، ہر سیکشن کے پرامپٹس، اور ایک فل ان ہونے والا ٹیمپلیٹ جسے آپ کاپی کر سکتے ہیں۔

PRD کس کام کی ہے (اور کس کام کی نہیں)

PRD چار سوالوں کا جواب دیتی ہے:

1. کیوں ہم یہ بنا رہے ہیں؟ کون سا مسئلہ، اور کس کے لیے؟
2. کیا اس کے پہلے ورژن کو کرنا ہے؟
3. کیا نہیں کرنا ہے ابھی؟
4. کیسے ہم جانیں گے کہ یہ کام کر گیا؟

یہ کوئی تکنیکی ڈیزائن نہیں ہے۔ یہ نہیں بتاتی کہ کون سا ڈیٹابیس یا فریم ورک استعمال کرنا ہے — یہ اگر ضرورت ہو تو الگ تکنیکی spec میں ہوتا ہے۔ یہ مارکیٹنگ بریف یا کاروباری منصوبہ بھی نہیں ہے۔ PRD کو پروڈکٹ کے رویے تک محدود رکھنا ہی اسے ہر پڑھنے والے کے لیے کارآمد بناتا ہے: ڈیزائنر، ڈویلپر، منظوری دینے والا شخص، یا AI ایپ بلڈر جو اسے کوڈ میں بدلتا ہے۔

کس کو اس کی ضرورت ہے

• سولو فاؤنڈرز جو scope creep کو شروع ہونے سے پہلے روکنا چاہتے ہیں۔
• چھوٹی ٹیمیں جنہیں ایک ایسی جگہ چاہیے جہاں “جو طے ہوا” لکھا ہو۔
• فری لانسر یا ایجنسی کو ہائر کرنے والے، کیونکہ واضح PRD سے واضح کوٹیشن ملتے ہیں۔ دیکھیں ڈویلپر ہائر کریں یا AI سے بنائیں۔
• AI سے بنانے والے، کیونکہ PRD کی user stories اور ڈیٹا کی فہرست بے ترتیب خواہشات کی فہرست سے بہتر پرامپٹس بناتی ہیں۔

AI کس چیز میں اچھا ہے — اور کس میں نہیں

سب سے عام غلطی وہ ہے جو اوپر کی آخری سے پہلی قطار کو الٹا کر دیتی ہے: AI خالی جگہیں پُراعتماد انداز میں، صارفین کے بارے میں معقول اندازوں سے پُر کرتا ہے۔ صارفین، مارکیٹ کے سائز یا رویے کے بارے میں AI جو کچھ لکھے اسے حقیقت نہیں بلکہ تصدیق طلب سوال سمجھیں۔

مرحلہ 1: جو آپ جانتے ہیں وہ سب لکھیں

کوئی بھی پرامپٹ لکھنے سے پہلے کچے نوٹس لکھیں۔ بلٹ پوائنٹس کافی ہیں۔ اس میں یہ شامل کریں:

• مسئلہ، ایک یا دو جملوں میں، صارف کے نقطۂ نظر سے۔
• یہ کس کو درپیش ہے۔ مخصوص رہیں: “10 تا 40 کلائنٹس والے فری لانس بک کیپرز”، نہ کہ “چھوٹے کاروبار”۔
• وہ آج اس کے بجائے کیا کرتے ہیں (اسپریڈشیٹ، ای میل، ایک ایسا ٹول جو انہیں پسند نہیں)۔
• وہ ایک نتیجہ جو ورژن ایک کو کامیاب بنائے۔
• وہ چیزیں جن کے بارے میں آپ پہلے سے جانتے ہیں کہ نہیں کریں گے۔
• سخت حدود: ڈیڈ لائن، بجٹ، فون پر لازماً کام کرنا، یا کسی ایسے ٹول کے ساتھ انٹیگریشن جو آپ پہلے سے استعمال کرتے ہیں۔

اگر آپ نے اس مسئلے والے کسی شخص سے بات نہیں کی تو پہلے یہ کریں۔ ایپ کے خیال کی تصدیق کیسے کریں میں اس کا عملی طریقہ ہے۔ اندازوں پر بنی PRD ایک خوبصورت فارمیٹ میں لکھا ہوا اندازہ ہی ہوتی ہے۔

مرحلہ 2: AI سے پہلا ڈرافٹ مانگیں

اپنے نوٹس پیسٹ کریں اور ایک طے شدہ ڈھانچے میں ڈرافٹ مانگیں۔ ایک کارآمد پرامپٹ:

یہ میرے ایک پروڈکٹ کے نوٹس ہیں۔ انہیں ایک product requirements document میں بدلیں جس میں بالکل یہ سیکشن ہوں: Summary, Problem, Users, Goals and success metrics, Scope (in / out), User stories with acceptance criteria, Data, Permissions, Edge cases, Open questions. دو صفحوں سے کم رکھیں۔ صارفین یا مارکیٹ کے بارے میں کوئی حقیقت من گھڑت نہ کریں — جہاں میرے نوٹس خاموش ہیں، وہاں سوال Open questions کے تحت لکھ دیں۔

آخری ہدایت اہم ہے۔ AI کو کہنا کہ نامعلوم باتیں Open questions میں ڈالے، انہیں بھرنے کے بجائے، زیادہ ایماندار ڈرافٹ دیتا ہے۔

مرحلہ 3: ہر سیکشن کو سخت کریں

ڈرافٹ کو ایک ایک سیکشن کر کے دیکھیں۔ یہ فالو اپ پرامپٹس مدد کرتے ہیں:

مسئلہ اور صارفین

مسئلے کا بیان صارف کے نقطۂ نظر سے ایک یا دو جملوں میں دوبارہ لکھیں۔ اس میں کوئی حل والے الفاظ نہ ہوں۔

اگر مسئلے کے بیان میں آپ کی پروڈکٹ کا ذکر ہے تو وہ مسئلہ نہیں، حل بیان کر رہا ہے۔

گول اور کامیابی کے میٹرکس

ورژن ایک کے لیے تین کامیابی کے میٹرکس تجویز کریں جنہیں میں پہلے مہینے میں چھوٹی تعداد کے صارفین کے ساتھ ناپ سکوں۔ ہر ایک کے لیے بتائیں کہ میں اسے کیسے ناپوں گا۔

ایک یا دو چنیں۔ “بیس بک کیپرز ایک مہینے تک ہفتہ وار اسے استعمال کرتے ہیں” قابلِ پیمائش ہے۔ “پیداواری صلاحیت بہتر بنانا” نہیں ہے۔

Scope

اس PRD کی ہر وہ چیز بتائیں جسے بنیادی فلو ٹوٹے بغیر بعد کے ورژن میں منتقل کیا جا سکتا ہے۔

AI ٹول عموماً فیچرز شامل کرتے ہیں۔ یہ پرامپٹ انہیں الٹا کرنے پر مجبور کرتا ہے۔ سخت رہیں: زیادہ تر ورژن ایک کی PRDs بہت بڑی ہوتی ہیں۔ MVP کیا ہے بتاتی ہے کہ چھوٹے پہلے ورژن آپ کو زیادہ کیوں سکھاتے ہیں۔

User stories اور acceptance criteria

ہر ضرورت کو user story کے طور پر لکھیں (“بطور [صارف]، میں [عمل] چاہتا ہوں تاکہ [نتیجہ]”) اور Given / When / Then شکل میں دو سے چار acceptance criteria شامل کریں۔

Acceptance criteria وہ چیک لسٹ ہیں جن پر بعد میں آپ جانچیں گے۔ “ایک بک شدہ سلاٹ ہو، جب دوسرا کلائنٹ کیلنڈر دیکھے، تو وہ سلاٹ نظر نہ آئے” قابلِ جانچ ہے۔ “بکنگ اچھی طرح کام کرتی ہے” نہیں ہے۔

ایج کیسز اور اجازتیں

ہر user story کے لیے بتائیں کہ خالی ڈیٹا، غلط ان پٹ، سست یا ناکام نیٹ ورک درخواست، اور ایسے صارف کے ساتھ کیا ہوتا ہے جسے رسائی نہیں ہونی چاہیے۔

یہاں AI اپنی قیمت وصول کرتا ہے۔ خالی حالتوں اور اجازت کے خلا کو پہچاننے میں وہ تیز ہے، جنہیں لوگ اکثر بھول جاتے ہیں۔

مرحلہ 4: ایک شکی نقاد کی طرح جائزہ لیں

پوری دستاویز ایک بار پھر پڑھیں اور یہ جانچیں:

• صارفین کے بارے میں ہر دعویٰ آپ کی طرف سے یا تحقیق سے آیا ہو، AI سے نہیں۔
• Scope “out” کم از کم اتنا ہی لمبا ہو جتنا “in”۔
• ہر user story کے acceptance criteria ہوں جنہیں کوئی آپ سے پوچھے بغیر جانچ سکے۔
• ڈیٹا کا سیکشن ہر قسم کا ریکارڈ بتائے جو ایپ رکھتی ہے اور کون اسے دیکھ سکتا ہے۔
• Open questions کا ایک مالک اور ایک تاریخ ہو۔
• کوئی تکنیکی بات نہ گھسی ہو، جب تک وہ حقیقی حد نہ ہو (“آف لائن کام کرنا لازم ہے” ضرورت ہے؛ “Redis استعمال کریں” نہیں)۔

پھر یہ کسی ایک شخص کو دکھائیں جو پروڈکٹ استعمال کرے گا یا بنائے گا، اور پوچھیں کہ کیا واضح نہیں۔ ان کے سوال ہی وہ خلا ہیں جنہیں آپ کو پُر کرنا ہے۔

فل ان ہونے والا PRD ٹیمپلیٹ

اسے ایک ڈاکیومنٹ میں کاپی کریں اور بریکٹس کی جگہ لکھیں۔ جو سیکشن واقعی لاگو نہ ہو اسے حذف کریں۔

پروڈکٹ کا نام: [نام] مالک: [وہ شخص جو فیصلوں کا ذمہ دار ہے] حالت: [ڈرافٹ / جائزے میں / منظور شدہ] — آخری اپڈیٹ: [تاریخ]

1. خلاصہ

[دو یا تین جملے: یہ کیا ہے، کس کے لیے، اور اہم نتیجہ کیا ہے۔]

2. مسئلہ

[صارف کے نقطۂ نظر سے مسئلہ۔ وہ آج کیا کرتے ہیں اور یہ کیوں تکلیف دہ ہے۔]

3. صارفین

4. گول اور کامیابی کے میٹرکس

• گول: [وہ نتیجہ جو ورژن ایک کو حاصل کرنا ہے]
• میٹرک: [آپ اسے کیسے ناپیں گے، اور ہدف کیا ہے]
• غیر گول: [کوئی چیز جو لوگ فرض کر سکتے ہیں، مگر یہ ورژن اسے نہیں کر رہا]

5. Scope

ورژن ایک میں:

• [فیچر]
• [فیچر]

ورژن ایک میں نہیں:

• [فیچر، اور یہ کیوں انتظار کر سکتا ہے]
• [فیچر، اور یہ کیوں انتظار کر سکتا ہے]

6. User stories

Story 1: بطور [صارف]، میں [عمل] کرنا چاہتا ہوں تاکہ [نتیجہ]۔

• Given [سیاق و سباق]، when [عمل]، then [نتیجہ]۔
• Given [سیاق و سباق]، when [عمل]، then [نتیجہ]۔

Story 2: بطور [صارف]، میں [عمل] کرنا چاہتا ہوں تاکہ [نتیجہ]۔

• Given [سیاق و سباق]، when [عمل]، then [نتیجہ]۔

7. ڈیٹا

8. اجازتیں

[کون لاگ ان کر سکتا ہے، کون سے کردار ہیں، اور ہر کردار کیا دیکھ اور بدل سکتا ہے۔]

9. ایج کیسز

• [خالی حالت: ابھی ڈیٹا نہ ہو تو کیا دکھائی دے]
• [غلط ان پٹ: غلط ای میل یا غائب فیلڈ ہو تو کیا ہو]
• [رسائی: کوئی ایسا صفحہ کھولے جو اس کا نہ ہو تو کیا ہو]

10. انٹیگریشنز اور حدود

[ادائیگیاں، ای میل، موجودہ ٹولز، ڈیڈ لائنز، بجٹ، وہ ڈیوائسز جن پر کام کرنا لازم ہے۔]

11. Open questions

PRD سے پرامپٹس تک

ایک اچھی PRD تقریباً براہِ راست AI ایپ بلڈر کے پرامپٹس میں بدل جاتی ہے:

• خلاصہ، صارفین اور ڈیٹا کی ٹیبل آپ کا پہلا پرامپٹ بن جاتے ہیں۔
• ہر user story ایک فالو اپ پرامپٹ بنتی ہے۔
• ہر acceptance criterion وہ چیز ہے جو آپ پریویو میں جانچتے ہیں۔
• “ورژن ایک میں نہیں” کی فہرست وہ ہے جو آپ ابھی مانگنے سے انکار کرتے ہیں۔

ایک وقت میں ایک story بنانا اور آگے بڑھنے سے پہلے اس کے acceptance criteria جانچنا، پوری PRD پیسٹ کر کے سب کچھ مانگنے سے کہیں زیادہ قابلِ اعتماد ہے۔ AI ایپ بلڈر کے لیے پرامپٹس کیسے لکھیں میں پرامپٹ والے حصے کی تفصیل ہے۔

عام غلطیاں

• حل کو مسئلہ بنا کر لکھنا۔ “صارفین کو ڈیش بورڈ چاہیے” حل ہے۔ “مالکان کو ہر انوائس کھولے بغیر پتا نہیں چلتا کہ کون سی مدت گزر چکی ہے” مسئلہ ہے۔
• “Out of scope” سیکشن نہ ہونا۔ اس کے بغیر ہر بات چیت میں scope دوبارہ کھل جاتا ہے۔
• AI کو صارفین گھڑنے دینا۔ AI کے بنائے ہوئے پرسونا اصلی لگتے ہیں مگر ہوتے نہیں۔
• ایسے میٹرکس جو ناپے نہ جا سکیں۔ اگر آپ اسے گن نہیں سکتے تو وہ میٹرک نہیں ہے۔
• کبھی اپڈیٹ نہ کرنا۔ وہ PRD جو آپ کی بنائی ہوئی چیز سے میل نہ کھائے، کسی بھی PRD سے بدتر ہے۔ “آخری اپڈیٹ” کی تاریخ رکھیں اور فیصلے بدلنے پر اسے بدلیں۔

Mythex کے ساتھ PRD استعمال کرنا

اگر آپ Mythex میں بناتے ہیں تو اپنی PRD سیدھی چیٹ میں پیسٹ کر سکتے ہیں۔ Plan موڈ PRD کے لیے اچھا ہے: ایجنٹ اسے پڑھتا ہے، ایک طریقہ اور مراحل کی چیک لسٹ تجویز کرتا ہے جسے آپ پلان ٹیب میں دیکھ سکتے ہیں، اور فائلیں صرف تب بدلتا ہے جب آپ Build دبائیں۔ آپ وہ حصے بھی پروجیکٹ نالج کے طور پر محفوظ کر سکتے ہیں جو ہمیشہ لاگو ہوں — سامعین، برانڈ، اصول — تاکہ ہر چیٹ میں انہیں دہرانا نہ پڑے۔ چیٹ ڈاکس Build، Plan اور Ask موڈز کی وضاحت کرتے ہیں، اور ٹیمپلیٹس سے آپ دیکھ سکتے ہیں کہ مکمل دستاویز لکھنے سے پہلے پہلا ورژن کیسا لگ سکتا ہے۔

سوالات