پرامپت 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.
درخواستهای قابلیت معمولاً به شکل یک سند محصول تمیز به دست تیم نمیرسند. بیشتر وقتها به صورت یک پیام اسلک، نقلقول مشتری، یادداشت صوتی بنیانگذار یا ایدهای نیمهکاره در سند برنامهریزی ظاهر میشوند. دقیقاً همینجا است که تیمها زمان از دست میدهند. قبل از اینکه طراحی یا مهندسی بتواند واکنش نشان دهد، کسی باید درخواست را به دامنه مشخص، نیاز کاربر و چیزهایی که هنوز نامعلوماند ترجمه کند.
این پرامپت برای سریعتر کردن همین مرحله ساخته شده است. کافی است درخواست خام را وارد کنید تا مدل آن را به یک PRD جمعوجور با خلاصه، هدفها و غیرهدفها، یوزر استوریها، نیازمندیهای عملکردی، حالتهای مرزی و چکلیست پذیرش تبدیل کند. قرار نیست خروجی جای قضاوت محصول را بگیرد. هدف این است که تیم در چند دقیقه یک پیشنویس اولیه بهتر داشته باشد، نه اینکه از صفحه خالی شروع کند.
- مناسب برای تحویل بین محصول و مهندسی: ساختار خروجی کمک میکند همه روی چیزی که واقعاً باید ساخته شود همنظر شوند.
- اسکوپبندی بهتر از ابتدا: کارهای داخل دامنه را از ایدههای خارج از دامنه جدا میکند، قبل از اینکه پروژه بیش از حد بزرگ شود.
- فرضیات پنهان کمتر: جزئیات نامشخص بهجای حدسزدن، صریحاً مشخص میشوند.
- آمادگی بیشتر برای اجرا: معیارهای پذیرش و ریسکها زودتر وارد گفتگو میشوند.
این پرامپت برای ابزارهای داخلی، قابلیتهای مرتبط با گردش کار، درخواستهای B2B، تغییرات پنل ادمین و هر پروژهای که ایده آن واقعی اما بریف آن هنوز نامرتب است، بسیار خوب عمل میکند. اگر تیم شما سریع حرکت میکند، چنین پرامپتی میتواند بدون کاهش کیفیت برنامهریزی، هم سرعت و هم وضوح را بهتر کند.