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)

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)

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

1. 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.

2. Read and Verify Data

   • Scan each item to confirm it matches the required field formats.
   • Flag any duplicate titles for review.

3. Categorize Items

   • Group items by Item Type (Feature, Enhancement, etc.) – this helps define the scope of the PRD.

4. 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.

5. 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).

6. 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.

7. 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”).

8. Identify Risks & Mitigations

   • Look for any items labeled “Risk” or “Dependency”.
   • List a brief mitigation strategy for each identified risk.

9. Compile the PRD

   • Assemble all sections in the order specified in Outputs.
   • Apply the formatting rules (bold headings, bullet lists, sequential requirement IDs).

10. 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.

11. 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

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

1. 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.

2. Can I add more than three goals?

   • Yes, but keep the list concise; avoid exceeding five major goals for clarity.

3. 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.

4. 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.

5. 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.

6. Can I skip the “Risks & Mitigations” section?

   • No. Every PRD must contain a risks section, even if it just states “No known risks”.

7. How many items can be processed in one run?

   • Up to 200 items; beyond that split into separate PRDs.

8. 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.

9. 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

1. Title Page – Include product name, version, and date.
2. Product Overview – Two‑sentence description of the product or feature set.
3. Business Goals – List of 2–5 high‑level objectives (use “Increase/Decrease” language).
4. Scope – What is included and excluded (list of items).
5. 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

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.