PRD Drafting Assistant

1. Overview

The PRD Drafting Assistant takes a product backlog – a list of feature ideas, user stories, or improvement items – and turns it into a clear, structured Product Requirements Document (PRD). The result is a well‑organized set of goals, detailed requirements, and measurable success criteria that a product manager can review and share with the team.

2. Business Value

Clarity – Consolidates scattered backlog items into a single, readable document.
Alignment – Aligns product goals, requirements, and success metrics in one place.
Speed – Reduces time spent manually drafting PRDs, enabling faster planning and execution.
Consistency – Uses a repeatable format, improving communication across teams and stakeholders.

3. Operational Context

When to run:
- When a new product initiative begins or a major feature set is ready to be scoped.
- When the product team needs a formal document to communicate scope, goals, and metrics to designers, engineers, and leadership.
Who uses it: Product Managers, Product Owners, and Business Analysts who own the backlog and need a concise PRD.
Frequency: Typically once per product initiative or major feature release, but can be repeated for any new set of backlog items.

4. Inputs

4.1 Backlog Items (One‑time list)

Field	Type	Details
Title	Text	Short, descriptive name of the item (e.g., “Add search filter”).
Description	Text	Brief explanation of what the item does or why it is needed.
Item Type	Text	One of: Feature, Enhancement, Bug Fix, Research.
Priority	Text	One of: High, Medium, Low.
Acceptance Criteria	Text	Specific conditions that must be met for the item to be considered complete.
Business Value (optional)	Text	Short statement of the expected benefit (e.g., “Reduce checkout abandonment”).

Note: The list must contain at least one item. The order of items does not matter. All fields above are required unless marked “optional”.

5. Outputs

5.1 Product Requirements Document (PRD)

Section	Content
Product Overview	Brief statement of the product or feature set being documented.
Goals	Bullet‑point list of high‑level goals derived from the backlog (e.g., “Increase user retention by 5%”).
Requirements	Table of detailed requirements; each requirement includes:
• Requirement ID (auto‑generated sequential number, e.g., “REQ‑001”)
• Title (from Backlog Title)
• Description (from Backlog Description)
• Priority (mirrored from Backlog)
• Acceptance Criteria (mirrored from Backlog)
Success Metrics	Bullet‑point list of measurable outcomes tied to the goals (e.g., “5% increase in daily active users”).
Assumptions & Constraints	List of any assumptions made or constraints identified (e.g., “Feature will be released on iOS only”).
Risks & Mitigations	List of potential risks and suggested mitigation steps.

Formatting Rules

Use plain language, short sentences, and active voice.
Use bold for section headings within the document.
Use bullet points for lists.
Number requirements sequentially (e.g., REQ‑001, REQ‑002).
No generated system IDs beyond the sequential “REQ‑” number.

6. Detailed Plan & Execution Steps

Collect Backlog Items
- Ensure the list of items contains all required fields (Title, Description, Item Type, Priority, Acceptance Criteria).
- If any required field is missing, mark the item for manual review and skip to step 9.
Read and Verify Data
- Scan each item to confirm it matches the required field formats.
- Flag any duplicate titles for review.
Categorize Items
- Group items by Item Type (Feature, Enhancement, etc.) – this helps define the scope of the PRD.
Derive Goals
- Review all Business Value statements (if present).
- Summarize into 2‑5 high‑level goals that are measurable and aligned with the product’s vision.
- If no Business Value provided, infer goals from the Description and Item Type.
Create Requirements
- For each item, generate a Requirement entry:
  - Assign a sequential Requirement ID (starting with REQ‑001).
  - Copy the Title, Description, Priority, and Acceptance Criteria exactly.
- Preserve the order of items as they appear in the backlog (or sort by Priority if the team prefers).
Define Success Metrics
- Look at each Goal and identify at least one measurable metric (e.g., “increase sign‑up conversion from 2% to 3%”).
- Use data from the Description or Business Value when available; otherwise, propose a reasonable metric based on common industry expectations.
Identify Assumptions & Constraints
- Extract any explicit statements from the backlog (e.g., “must work on mobile browsers only”).
- Add any common assumptions (e.g., “user is logged in”).
Identify Risks & Mitigations
- Look for any items labeled “Risk” or “Dependency”.
- List a brief mitigation strategy for each identified risk.
Compile the PRD
- Assemble all sections in the order specified in Outputs.
- Apply the formatting rules (bold headings, bullet lists, sequential requirement IDs).
Review & Finalize
- Scan the complete PRD for spelling errors and consistency.
- Ensure every Goal has at least one related Requirement and at least one Success Metric.
Deliver Output
- Provide the final PRD as a structured set of text (no PDF file).
- Provide the Requirements table as a separate list if needed for downstream tools.

7. Validation & Quality Checks

Mandatory Fields Check: Confirm each backlog item contains all required fields. Missing fields cause the item to be flagged for manual review.
Duplicate Title Check: Verify no duplicate titles exist; if found, flag for clarification.
Goal‑Requirement Alignment: Ensure each Goal has at least one requirement linked (by reading the titles). If not, highlight the missing link.
Success Metric Presence: Verify each Goal has a corresponding success metric. If a Goal lacks a metric, add a placeholder “Metric to be defined” and flag.
Consistency Check: Confirm that the numbering of Requirement IDs is sequential and without gaps.
Formatting Check: Verify bold headings, bullet‑point usage, and no extra system IDs are included.

If any validation fails, output a “Validation Failed” status with a list of issues; do not produce a PRD until the issues are resolved.

8. Special Rules / Edge Cases

Empty Backlog: If no items are supplied, stop immediately and return a “No Input Data” status.
Missing Optional Business Value: When absent, infer goals from descriptions; if still unclear, mark the goal as “To be defined”.
Multiple Priorities: If an item lists more than one priority, select the highest priority (High > Medium > Low) for the requirement entry.
Non‑Standard Item Types: If an item type is not in the allowed list, treat it as “Feature” and note the deviation in Assumptions & Constraints.
Too Many Items ( > 200 ): If the list exceeds 200 items, split the work into two separate PRDs (e.g., “Phase 1” and “Phase 2”). Indicate this split in the Assumptions & Constraints section.
Missing Acceptance Criteria: Flag the requirement for manual review; do not create a requirement entry until completed.

9. Example

Input (Backlog Items)

Title: “Add search filter” Description: “Allow users to filter search results by category.” Item Type: Feature Priority: High Acceptance Criteria: “User can select a category from a dropdown and results update within 1 second.” Business Value: “Increase conversion by allowing users to find items faster.”
Title: “Improve checkout speed” Description: “Reduce checkout processing time.” Item Type: Enhancement Priority: Medium Acceptance Criteria: “Checkout completes within 3 seconds for 95 % of transactions.” Business Value: “Reduce cart abandonment.”
Title: “Fix broken link on FAQ page” Description: “Link to pricing page returns a 404 error.” Item Type: Bug Fix Priority: Low Acceptance Criteria: “Link redirects correctly to the pricing page.” Business Value: (none)

Expected Output (PRD)

Product Overview A set of features to improve search, reduce checkout time, and fix a known issue on the FAQ page.

Goals

Increase conversion by improving search relevance.
Reduce cart abandonment by speeding up checkout.

Requirements

Requirement ID	Title	Description	Priority	Acceptance Criteria
REQ‑001	Add search filter	Allow users to filter search results by category.	High	User selects a category from a dropdown and results update within 1 second.
REQ‑002	Improve checkout speed	Reduce checkout processing time.	Medium	Checkout completes within 3 seconds for 95 % of transactions.
REQ‑003	Fix broken link on FAQ	Link to pricing page returns a 404 error.	Low	Link redirects correctly to the pricing page.

Success Metrics

5 % increase in conversion rate within 30 days of launching the search filter.
15 % reduction in cart abandonment rate within 60 days of implementing the faster checkout.

Assumptions & Constraints

Assumes users have JavaScript enabled.
Feature release will be limited to the web platform.

Risks & Mitigations

Risk: Search filter may impact page load time. Mitigation: Optimize query and use caching.

Validation All required fields present; no duplicate titles; each goal linked to at least one requirement; success metrics defined.

Appendix A – FAQ

What if a backlog item has no Business Value?
- Use the description to infer a goal or add a placeholder “To be defined” and flag for review.
Can I add more than three goals?
- Yes, but keep the list concise; avoid exceeding five major goals for clarity.
What should I do if the Acceptance Criteria are vague?
- Flag the item for clarification and do not create a requirement until the criteria are clarified.
How do I handle items that are not features (e.g., research tasks)?
- Include them as “Research” type items, note them in Assumptions & Constraints and ensure they have a clear outcome or decision point.
What if there are duplicate titles?
- Add a differentiator in the title (e.g., “Add search filter – Mobile”) or ask the product manager for clarification.
Can I skip the “Risks & Mitigations” section?
- No. Every PRD must contain a risks section, even if it just states “No known risks”.
How many items can be processed in one run?
- Up to 200 items; beyond that split into separate PRDs.
If a requirement’s priority changes, what should I do?
- Update the Priority field in the requirements table and re‑run the SOP for the updated backlog.
Can I add a new field to the backlog (e.g., “Owner”)?
- The SOP does not use that field. It will be ignored unless added to the Assumptions & Constraints section manually.

Appendix B – Glossary

Backlog – A list of product ideas, features, enhancements, and bugs awaiting implementation.
Feature – A new capability or functionality to be added.
Enhancement – Improvement to an existing feature.
Bug Fix – Correction of an error or defect.
User Story – A short narrative describing a feature from the user's perspective.
Acceptance Criteria – Conditions that must be met for a feature to be considered complete.
Goal – A high‑level business objective the product seeks to achieve.
Success Metric – Quantifiable measure used to evaluate if a goal has been met.
PRD (Product Requirements Document) – A structured document outlining what a product will do, why it is needed, and how success will be measured.

Appendix C – Reference Materials

C.1 – PRD Structure Guide

Title Page – Include product name, version, and date.
Product Overview – Two‑sentence description of the product or feature set.
Business Goals – List of 2–5 high‑level objectives (use “Increase/Decrease” language).
Scope – What is included and excluded (list of items).
User Personas – Brief description of target users (optional).

C.2 – Goal Writing Guidelines

Start with a verb (e.g., “Increase”, “Reduce”, “Enable”).
Use measurable language (“by 10%”, “within 30 days”).
Align each goal with at least one requirement.

C.3 – Requirements Formatting Rules

Requirement ID: Sequential “REQ‑” number (e.g., REQ‑001).
Title: Same as backlog title, capitalized.
Description: One‑sentence summary; avoid jargon.
Priority: Use the exact word from the backlog.
Acceptance Criteria: Write as “Given [condition], when [action], then [expected outcome]”.

C.4 – Success Metric Examples

User Retention: “Increase 30‑day retention from 45% to 55%.”
Conversion Rate: “Improve checkout conversion from 2.5% to 3.2%.”
Performance: “Reduce page load time from 5 seconds to 2 seconds for 95% of visits.”
Adoption: “Achieve 10,000 active users within the first month.”

C.5 – Common Pitfalls

Issue	Impact	Mitigation
Vague acceptance criteria	Inability to verify completion	Ask for clear, measurable criteria.
Missing priority	Unclear prioritisation	Default to Medium if missing.
Duplicate titles	Confusion in tracking	Append a qualifier (e.g., “(Mobile)”).
Over‑broad goals	Hard to measure success	Break into sub‑goals or metrics.
Too many items in one PRD	Over‑complexity	Split into separate PRDs after 200 items.

C.6 – Prohibited Content

Subjective Language – Avoid words like “awesome” or “best”.
Unverified Claims – Do not include statements that cannot be validated with data.
Sensitive Personal Data – Never include personal identifiers (e.g., user email) in the PRD.

C.7 – Review Checklist

All required fields present in each backlog item?
No duplicate titles?
Each Goal has at least one Requirement?
Each Goal has a measurable Success Metric?
Requirement IDs are sequential?
Formatting follows the guidelines?

These detailed reference sections can be expanded or customized as the organization’s standards evolve.

Aspect	Manual Process	With the Assistant
Drafting time	Hours of back and forth revisions	Minutes of automated generation
Consistency	Varies by author and iteration	Uniform format for every PRD
Alignment	Goals and requirements can drift apart	Goals tied directly to backlog items
Risk of omission	High – missing acceptance criteria are common	Low – validation catches gaps early

Transform Your Backlog into a Structured PRD