AI Prompt: Turn a Feature Request Into a 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.
Feature requests rarely arrive as clean product documents. More often they show up as a Slack message, a customer quote, a founder voice note, or a half-formed idea in a planning doc. That is exactly where teams lose time. Before design or engineering can react, someone has to translate the request into scope, clarify the user need, and surface what is still unknown.
This prompt is built to speed up that step. Paste in the rough request and the model turns it into a compact PRD with a short summary, goals and non-goals, user stories, functional requirements, edge cases, and a practical acceptance checklist. The output is not meant to replace product judgment. It is meant to give the team a stronger first draft in minutes instead of starting from a blank page.
- Useful for product and engineering handoff: the structure helps everyone align on what is actually being built.
- Better scoping early: it separates in-scope work from out-of-scope ideas before the project balloons.
- Fewer hidden assumptions: missing details are called out instead of quietly guessed.
- Stronger implementation readiness: acceptance criteria and risks appear earlier in the conversation.
This works especially well for internal tools, workflow features, B2B requests, admin-panel changes, and any project where the idea is real but the brief is still messy. If your team moves fast, a prompt like this can improve both speed and clarity without lowering the quality of planning.