Requirement Doc Drafter – PRD Skeleton Creator
1. Overview
This process creates a structured Product Requirements Document (PRD) skeleton from a single feature request. The skeleton contains all standard PRD sections with placeholder text and prompts that the Product Owner can fill in later. It turns the raw request into a clear, reusable outline that drives downstream design and development work.
2. Business Value
- Speed – Generates a first‑draft PRD within minutes, shortening the planning phase.
- Consistency – Uses a standard set of sections and language, ensuring all PRDs follow the same format.
- Alignment – Provides a common starting point that aligns product, design, and engineering on what needs to be built and why.
3. Operational Context
-
When to run:
- Whenever a new feature request has been approved for analysis and needs a formal PRD outline.
- At the start of a feature’s discovery phase, before detailed design work begins.
-
Who uses it:
- Product Owners (the primary audience).
- Product Managers, designers, and engineers who will later flesh out the details.
-
Frequency:
- One time per feature request.
- Can be repeated whenever new feature ideas are captured.
4. Inputs
The process requires the following items for a single run.
| Input Name | Type | Details Provided |
|---|
| Feature Request Document | PDF | The full request from the stakeholder. It must contain: <ul><li>Feature title</li><li>Brief description</li><li>Problem statement or need</li><li>Target user persona(s)</li><li>Business goal(s) for the feature</li><li>Desired success metrics</li><li>Key acceptance criteria (if any)</li><li>Any constraints (e.g., compliance, technical limits)</li></ul> |
| Product Name | Text | The name of the product or service that the feature belongs to. |
| Requested By | Text | Name of the stakeholder or team that submitted the feature. |
| Requested Date | Date | The date the feature request was received. |
5. Outputs
The process produces a single, ready‑to‑edit PRD skeleton.
| Output Name | Contents | Formatting Rules |
|---|
| PRD Skeleton | A structured outline that includes the following sections: <ol><li>Title & Basic Info</li><li>Overview</li><li>Problem Statement</li><li>Goals & Success Metrics</li><li>Target Persona(s)</li><li>Feature Description</li><li>Assumptions & Constraints</li><li>User Stories</li><li>Acceptance Criteria</li><li>Open Questions & Risks</li></ol>Each section contains placeholder text and prompts where the Product Owner will insert details. | - Plain‑text bullet points and numbered lists as shown in the example below. |
- Section headings use Title Case and are bolded.
- Use a neutral and professional tone.
- Do not generate any new identifiers or codes. |
| Validation Checklist | A short list that verifies that each required field from the Feature Request was addressed in the draft. | - Presented as a checklist of “✔ ” items.
- Each item should reference the corresponding PRD section. |
6. Detailed Plan & Execution Steps
- Open the Feature Request Document.
- Read the document and locate each required element (title, description, etc.).
- Create the PRD Skeleton:
a. Write the Title & Basic Info section using the Product Name, Feature Title, Requested By, and Requested Date.
b. Insert an Overview paragraph that briefly summarises the feature’s purpose (use the description from the request).
c. Populate the Problem Statement using the problem description from the request.
d. Add Goals & Success Metrics by copying any goals and metrics listed in the request. If none are provided, insert the placeholder “<Enter goal>”.
e. Fill Target Persona(s) with the personas listed. If missing, add “<Specify user persona>”.
f. Write Feature Description using the request’s description verbatim.
g. List Assumptions & Constraints: copy any constraints; otherwise, insert “<Specify any assumptions or constraints>”.
h. Draft User Stories in the format “As a <persona>, I want <action> so that <benefit>”. If the request does not contain stories, write “<Add user story>”.
i. Insert Acceptance Criteria as bullet‑pointed criteria from the request. If none are listed, add “<Define acceptance criteria>”.
j. Add an Open Questions & Risks section with any unanswered items from the request; otherwise, write “<Identify open questions and risks>”.
- Create the Validation Checklist: list each of the sections above and place a “❓” next to any that still contain placeholder text.
- Review the Skeleton for completeness and clarity.
- Save the output as a plain‑text file (e.g., .txt or .md) named “PRD – [Feature Title] – Skeleton”.
7. Validation & Quality Checks
- All required sections present – Verify the skeleton contains all nine sections listed in the Output definition.
- No empty placeholders – Scan each placeholder (e.g., “<Enter goal>”) and confirm it has been filled with information from the request.
- Accurate transfer – Compare each field in the PRD skeleton with the corresponding content in the Feature Request Document; any mismatch must be corrected.
- Formatting – Ensure bolded headings, numbered lists, and bullet points follow the formatting rules.
- Checklist completeness – Ensure the Validation Checklist shows a checkmark next to every section that has been populated.
8. Special Rules / Edge Cases
-
Missing Section Information:
- If the request does not contain a specific element (e.g., no success metrics), leave the placeholder and flag it in the Validation Checklist for manual review. Do not skip the section entirely.
-
Multiple Personas:
- List each persona on a separate line under the “Target Persona(s)” section.
-
Conflicting Information:
- If the request contains contradictory statements (e.g., two different goals), record both in the “Open Questions & Risks” section and mark the item for clarification.
-
Unclear Language:
- When a paragraph is ambiguous, copy the text verbatim but add a “❓” note in the Validation Checklist indicating it needs clarification.
-
Failure Scenario:
- If the Feature Request Document is unreadable (e.g., corrupted PDF) or any required input is missing, stop the process and generate a Failure Notice that lists the missing or unreadable items. The Failure Notice replaces the PRD Skeleton output.
9. Example
Input
-
Feature Request Document (PDF) – contains:
- Title: “Smart Calendar Integration”
- Description: “Allow users to sync their personal calendar (Google/Outlook) with the app, so they can see their appointments within the app.”
- Problem Statement: “Users cannot see their external calendar events inside the product, causing missed appointments.”
- Target Persona: “Busy Professionals”
- Goal: “Increase daily active usage by 15% within 3 months.”
- Success Metric: “Number of calendar syncs per week.”
- Constraint: “Only read‑only access to external calendars; no write permission.”
- User Story: “As a busy professional, I want to view my Google Calendar events in the app so that I can avoid double‑booking.”
-
Product Name: “TaskMaster Pro”
-
Requested By: “Jane Smith – Marketing Lead”
-
Requested Date: 2025‑07‑01
Output (PRD Skeleton)
Title & Basic Info
- Product: TaskMaster Pro
- Feature: Smart Calendar Integration
- Requested By: Jane Smith – Marketing Lead
- Date Requested: 2025‑07‑01
Overview
- Enables users to view their external Google/Outlook calendar events inside TaskMaster Pro.
Problem Statement
- Users cannot see external calendar events inside the product, leading to missed appointments.
Goals & Success Metrics
- Goal: Increase daily active usage by 15% within 3 months.
- Success Metric: Number of calendar syncs per week.
Target Persona(s)
Feature Description
- Allow users to sync their personal calendar (Google/Outlook) with the app, so they can see their appointments within the app.
Assumptions & Constraints
- Constraint: Only read‑only access to external calendars; no write permission.
User Stories
- As a Busy Professional, I want to view my Google Calendar events in the app so that I can avoid double‑booking.
Acceptance Criteria
- ✅ Sync works for Google Calendar.
- ✅ Sync works for Outlook Calendar.
- ✅ Calendar data is refreshed at least every 15 minutes.
- ✅ No write access is granted to external calendars.
Open Questions & Risks
- ❓ Will users be able to sync multiple calendars simultaneously?
- ❓ Potential privacy concerns with calendar data access.
Validation Checklist
- [✔] Title & Basic Info filled
- [✔] Overview completed
- [✔] Problem Statement included
- [✔] Goals & Metrics defined
- [✔] Target Persona(s) listed
- [✔] Feature Description added
- [✔] Assumptions & Constraints documented
- [✔] User Stories created
- [✔] Acceptance Criteria defined
- [✔] Open Questions & Risks noted
Appendix A – FAQ
Q1: What if the Feature Request does not have a clear Goal?
A: Insert a placeholder “<Define goal>” and flag the item in the Validation Checklist for manual clarification.
Q2: Can I add additional sections?
A: The standard PRD skeleton uses nine sections. If more detail is needed, add a “Additional Information” section after “Open Questions & Risks.”
Q3: How should I handle multiple user personas?
A: List each persona on a separate line in the “Target Persona(s)” section.
Q4: What if the document is a Word file instead of a PDF?
A: Convert it to PDF before running this process, or treat the content as plain text if conversion is not possible.
Q5: Who should review the PRD Skeleton?
A: The Product Owner, with input from design and engineering leads.
Q6: How do I handle conflicting goals?
A: List each goal under “Goals & Success Metrics” and note the conflict in “Open Questions & Risks” for clarification.
Q7: What if the feature request contains proprietary or sensitive information?
A: Keep the PRD Skeleton internal to the product team; do not distribute outside the organization without proper clearance.
Q8: What if the request includes a timeline?
A: Add a “Timeline” bullet in “Assumptions & Constraints” with the provided dates, or create a separate “Timeline” subsection if needed.
Q9: How do I handle multiple constraints?
A: List each constraint as a separate bullet in “Assumptions & Constraints.”
Q10: How to ensure the PRD Skeleton is ready for development?
A: Ensure all placeholders are filled, the Validation Checklist is fully checked, and any open questions are addressed or documented as risks.
Appendix B – Glossary
- Product Requirements Document (PRD): A detailed outline that specifies what a product feature should accomplish and how it will be measured.
- Feature Request: A submission from a stakeholder describing a desired new capability or enhancement.
- Persona: A representative user type for whom the product is being built.
- Success Metric: A measurable outcome that indicates whether the feature meets its goal.
- Assumption: A condition presumed to be true for the purpose of planning.
- Constraint: A restriction that limits how a feature can be implemented.
- User Story: A short description of a user need in the form “As a <persona>, I want <action> so that <benefit>.”
- Acceptance Criteria: Specific conditions that must be met for the feature to be considered complete.
Appendix C – Reference Materials
C1 – Standard PRD Section Template
-
Title & Basic Information
- Product Name
- Feature Name
- Requested By
- Date Requested
-
Overview
- Brief, 2–3 sentence summary of the feature.
-
Problem Statement
- Description of the problem the feature solves.
-
Goals & Success Metrics
- Business goal(s) (e.g., increase usage, reduce churn).
- Specific metrics (e.g., % increase, number of users).
-
Target Persona(s)
- List of user types impacted.
-
Feature Description
- Detailed description of the feature.
-
Assumptions & Constraints
- Any known assumptions or constraints (technical, legal, etc.).
-
User Stories
- Format: “As a [Persona], I want [Action] so that [Benefit].”
-
Acceptance Criteria
- Bullet‑pointed list of conditions that must be met.
-
Open Questions & Risks
- Unresolved questions, potential risks, or dependencies.
C2 – Style Guide for PRD Skeleton
- Tone: Neutral, professional, and concise.
- Verb tense: Present tense for statements of fact; future tense for planned actions.
- Bullets: Use “-” for bullet points; numbers for ordered lists.
- Capitalization: Title case for headings, sentence case for normal text.
- Placeholder Text: Use angle brackets (e.g.,
<Enter goal>).
- Word Count: Keep each section 1–3 sentences, except “User Stories” (each story is one sentence).
C3 – Example of Completed PRD Skeleton (for reference)
**Title & Basic Info**
Product: TaskMaster Pro
Feature: Smart Calendar Integration
Requested By: Jane Smith – Marketing Lead
Date Requested: 2025-07-01
...
(Full example provided in Section 9 above.)
C4 – Prohibited Content
- Personal data that is not required for the PRD (e.g., personal phone numbers) should be omitted.
- Any content that violates company confidentiality policies must be removed before the PRD is shared.
C5 – FAQ for Formatting
- Bold headings – use bold for every section heading.
- Underline is not used.
- Lists – use hyphens for simple bullets; use numbers for ordered steps.
C6 – Common Edge Cases
- Multiple Feature Requests in one PDF – Process each request separately; do not combine into a single PRD skeleton.
- Missing Request Date – Use the date you receive the document as the “Date Requested.”
- No Existing User Stories – Add a placeholder and schedule a follow‑up interview with the stakeholder.
.*
