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.

How to use this resource

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

FAQ

How does this system prompt stop a feature request from smuggling in the solution?

It forces a problem-first shape. The Problem Statement section demands the format "[User type] cannot [do X] because [constraint]. This causes [impact]" and explicitly says do not describe the solution. The whole prompt also bars implementation details and technology choices, so a request that arrives as "add feature X" gets reframed into the user problem underneath it.

What makes the acceptance criteria from this prompt actually testable?

The Acceptance Criteria section requires a numbered list of verifiable conditions and explicitly bans subjective phrasing like "users can easily..." or "the system is fast...". Paired with the Out of Scope and Open Questions sections, it produces criteria a QA engineer can check pass or fail. The system-prompt-generator outputs this prompt; you run it and still validate each criterion yourself.

When is this requirements prompt the wrong tool to reach for?

When there's no user problem to structure yet. notFor rules out highly technical infrastructure or architecture decisions, requirements that depend entirely on user research that hasn't happened, and regulatory compliance specs needing legal review. Its Non-Functional Requirements section touches compliance constraints, but that's a placeholder for review — not a substitute for legal sign-off.

More resources from System Prompt Generator

Resources that pair well

Related tools

Projects that use this resource

Workflows that use this resource

Tip: Save time by exploring related resources and tools that integrate with this resource.