مطالبة AI لتحويل طلب ميزة إلى PRD
Why this prompt matters
Feature requests often start as scattered notes, not decision-ready documents. A strong prompt helps teams turn rough input into a shared draft faster, reduce back-and-forth, and expose missing assumptions before implementation starts.
What we use it for
Turning a messy feature request into a mini PRD with scope, user stories, requirements, risks, and acceptance criteria that product and engineering can work from quickly.
Prompt
Act as a senior product manager and product engineer. I will paste a rough feature request, customer ask, founder note, Slack message, or idea dump. Your job is to turn it into a compact product requirements document that is clear enough for design and engineering to discuss immediately. Return your answer in exactly these sections: 1. Feature Summary, 3 to 5 bullet points 2. Problem to Solve 3. Target User and Main User Need 4. Goals and Non-Goals 5. Assumptions and Open Questions 6. Scope, split into In Scope and Out of Scope 7. User Stories, 3 to 7 items in the format: As a [user], I want [capability], so that [outcome] 8. Functional Requirements, as a numbered list 9. Edge Cases and Risks 10. Acceptance Criteria, as a checklist 11. Suggested Success Metrics 12. Recommended Next Step Rules: - Do not invent company facts, deadlines, or technical constraints that were not provided. - If information is missing, call it out explicitly under Assumptions and Open Questions. - Prefer clear, implementation-ready language over strategy jargon. - Keep the PRD compact and high signal. - If the request is too vague, create the best draft possible and label assumptions clearly. - Preserve important product names, numbers, platforms, and regulatory constraints exactly as given. Feature request: [PASTE REQUEST HERE]
Result
Feature Summary: Add a shared team inbox for customer escalations inside the admin panel. Problem to Solve: support leads are tracking urgent cases in Slack and email, which causes missed handoffs and no clear audit trail. Goals: centralize escalations, assign owners, and track resolution status. Out of Scope: full ticketing replacement and public customer replies. User Story: As a support lead, I want to assign an escalation to a teammate so that ownership is visible immediately. Acceptance Criteria: agents can create, assign, change status, and filter escalations by priority and owner.
طلبات الميزات نادراً ما تصل إلى الفريق في صورة وثيقة منتج جاهزة. غالباً ما تظهر كرسالة Slack، أو اقتباس من عميل، أو ملاحظة صوتية من المؤسس، أو فكرة غير مكتملة داخل مستند تخطيط. وهنا بالضبط يضيع الوقت. قبل أن يتمكن التصميم أو الهندسة من التحرك، يحتاج أحدهم إلى تحويل الطلب إلى نطاق واضح، وحاجة مستخدم مفهومة، وما يزال غير معروف.
هذه المطالبة صُممت لتسريع هذه الخطوة. الصق الطلب الخام، وسيحوّله النموذج إلى PRD مختصر يتضمن ملخصاً قصيراً، والأهداف وغير الأهداف، وقصص المستخدم، والمتطلبات الوظيفية، والحالات الطرفية، وقائمة قبول عملية. الهدف ليس استبدال حكم مدير المنتج، بل إعطاء الفريق مسودة أولى أقوى خلال دقائق بدلاً من البدء من صفحة فارغة.
- مفيدة لتسليم العمل بين المنتج والهندسة: يساعد هذا الهيكل الجميع على الاتفاق على ما سيتم بناؤه فعلاً.
- تحديد نطاق أفضل مبكراً: تفصل ما هو داخل النطاق عن الأفكار خارجه قبل أن يكبر المشروع بلا داعٍ.
- افتراضات مخفية أقل: يتم كشف المعلومات الناقصة بدلاً من تخمينها بصمت.
- جاهزية تنفيذ أقوى: تظهر معايير القبول والمخاطر في وقت أبكر من النقاش.
تعمل هذه المطالبة بشكل ممتاز مع الأدوات الداخلية، وميزات سير العمل، وطلبات B2B، وتغييرات لوحات الإدارة، وأي مشروع تكون فكرته حقيقية لكن موجزه لا يزال فوضوياً. وإذا كان فريقك يعمل بسرعة، فيمكن لمطالبة كهذه أن تحسن السرعة والوضوح معاً من دون خفض جودة التخطيط.