Product Requirements Structured Output

Product Requirements Assistant

Turn a rough feature idea into a structured requirement: problem statement, acceptance criteria, and what's explicitly out of scope.

Overview

Feature requests usually arrive as solutions: 'we should add X.' This workflow forces a problem-first structure — what is the user actually unable to do, and how would we know when that's fixed? The output is a scoped requirement with testable acceptance criteria, not a wish list item.

Workflow

  1. Describe the feature idea

    Paste the feature request, Slack message, or call notes. Include who requested it and why if known.

  2. Review the problem statement

    The problem statement is the most important output. If it describes a solution instead of a problem, correct it before proceeding.

  3. Validate acceptance criteria

    Each criterion should be testable by a QA engineer or user. Replace subjective criteria ('easy', 'fast') with measurable ones.

  4. Resolve open questions before handoff

    Open questions left unanswered become mid-sprint surprises. Assign each one to a person or decision point.

Why This Workflow Works

  • Problem-first structure prevents a solution from hiding what the actual requirement is
  • Testable acceptance criteria make 'done' unambiguous — important for QA and for preventing scope creep
  • Explicit out-of-scope section stops related features from being assumed as included
  • Open questions surfaced early are cheap; the same questions surfaced during development are expensive

Best for

  • Feature ideas arriving as informal requests or solution descriptions
  • Teams where the same person handles discovery and writing requirements
  • Requirements that need to survive a design and engineering handoff
  • Backlog grooming sessions where ticket quality needs to improve quickly

Not for

  • Highly technical infrastructure or architecture decisions
  • Requirements that depend entirely on user research that hasn't happened yet
  • Regulatory compliance specifications requiring legal review

Use cases

  • Structuring a feature request from a sales or customer call before it enters the backlog
  • Clarifying scope before a design or engineering kickoff
  • Reviewing an existing ticket to identify missing acceptance criteria
  • Preparing requirements for stakeholder review before sprint planning