Product Requirements Prompts for Evidence and Clear Scope

Useful product requirements prompts turn verified user needs into specific behavior, clear boundaries, and observable acceptance checks. Give the assistant source evidence and approved decisions, then require it to label every assumption and unanswered question. The output is a proposal for people to review, not permission to expand the product.

Tools like fenbs retain approved product decisions and reusable review prompts across connected assistants. That helps the next draft distinguish what someone chose from what an earlier model merely suggested.

What evidence should you supply before drafting?

Start with the problem and the evidence that it exists. Supply research excerpts, support observations, or measured behavior with clear source labels. Do not ask an assistant to invent interview quotes or fill an empty evidence section with plausible users. An absent source should remain an explicit gap.

• User and situation: who encounters the problem, and during which task.
• Observed difficulty: what happened, described without assuming the cause.
• Evidence: labeled excerpts or measurements, including their limits.
• Desired outcome: what should become possible or improve.
• Approved boundaries: supported users, platforms, permissions, and exclusions.
• Decision status: who has approved what, and what remains open.

A hypothetical service business might know that dispatchers repeatedly open individual visits to check their completion state. That observation supports investigating visibility. It does not establish that the solution needs predictive scheduling, automated messages, or a redesigned customer portal. Keep those ideas outside the requirement until someone evaluates them.

What prompt produces a bounded first draft?

Ask for one small requirement set rather than an impressive document. Require each proposed behavior to identify its supporting need and its approval status. The NASA guidance on writing requirements↗ (opens in a new tab) offers useful checks for precise, verifiable statements. You can apply those checks to ordinary software without adopting a space-program document structure.

Draft a bounded requirement proposal for [product change].
User and situation: [description]
Validated problem and labeled evidence: [sources]
Approved scope and decisions: [list]
Explicit exclusions: [list]
For each requirement, provide an ID, actor, trigger, expected behavior, source label, acceptance check, and status: proposed or approved by [person, only if supplied].
Do not invent research, business rules, thresholds, dates, or approvals. Put unsupported assumptions and missing decisions in a separate question list. Suggest no implementation architecture unless I supplied a binding constraint.

Read the source column before the wording. If a requirement has no supporting need or explicit decision, decide whether it belongs at all. A source label is useful only when a reviewer can open the source and confirm that it supports the specific behavior being proposed.

Keep approved boundaries in fenbs Decisions and rules, so later drafts can read them instead of reopening settled scope.

How can you make acceptance checks observable?

An acceptance check describes what someone can observe when the requirement is satisfied. “The screen is intuitive” is too open to interpretation on its own. Ask for the starting condition, action, and expected result, including what must remain unchanged. Choose measurable thresholds through review rather than letting the assistant supply attractive numbers.

Review these proposed requirements: [requirements].
For each one, write acceptance examples as: starting state; actor action; expected observable result. Include a normal case, a boundary case, and a failure or denied-access case where relevant.
Identify vague words and replace them only when supplied evidence or an approved decision supports the replacement. Otherwise ask a question. Do not invent a speed target, supported-device promise, or permission rule. Distinguish checking the implementation from validating that the requirement solves the original problem.

The open question is part of a useful result. Hiding it behind a smooth default creates a product choice without review. The implementation team should not need to infer whether persistence was intentional or simply omitted from the document.

How do you catch scope that slipped into the draft?

Compare each requirement with the stated outcome and exclusions. A simple filter can quietly acquire exports, saved views, notifications, and organization-wide preferences because those features sound related. Ask the assistant to identify additions separately, with the new decisions and dependencies each would require.

Compare the proposed requirements [text] with the approved problem, scope, exclusions, and decisions [text].
Return a table: requirement ID; supported by; possible scope addition; dependency; question for a person.
Flag implied new screens, roles, stored preferences, notifications, data collection, and external services. Do not remove approved behavior or approve additions yourself. End with the smallest coherent requirement set that satisfies the supplied outcome, with any tradeoffs plainly stated.

Check that the smaller set still forms a complete usable behavior. Removing every edge case can make a document shorter while leaving the work impossible to finish. Include the errors and empty states necessary for the chosen task, and distinguish them from adjacent features that could wait.

For broader discovery and prioritization tasks, use the product-manager prompt guide. Here, keep the question narrow: does this requirement set describe the approved change well enough to review and verify?

How should a prompt expose contradictions?

Give the assistant the current decisions together, including their dates and scopes. Ask it to identify conflicting statements rather than choosing whichever sounds most recent or convenient. Two instructions may apply to different users or situations, so the review should explain the conditions under which the conflict occurs.

For example, one draft might say “retain the filter for every user” while an approved privacy rule says not to store user preferences. The assistant should point out the conflict and list options for a person. It should not quietly add a storage service or declare that one instruction overrides the other.

The NASA requirements-management guidance↗ (opens in a new tab) describes connecting requirements with their sources and managing changes through review. For a small team, the practical habit is straightforward: know why a requirement exists, what checks it, and who approved a change. Keep the links readable enough that a teammate can follow them.

What should stay with the reusable prompt?

Save the required inputs, output structure, and review checklist with the prompt. Keep actual decisions in their own current record rather than embedding a snapshot in every template. Otherwise a copied instruction can keep reviving an old product direction after the team has changed its mind.

Retain one small example of an acceptable requirement and one example of a rejected assumption. Those examples make review expectations concrete without asking a future assistant to imitate an entire old document. System prompt examples show reusable instruction patterns; project-management prompts help carry accepted work into tasks.

How to do this with fenbs

1. Create a free account and add the product project with its current problem and intended outcome.
2. Save a reviewed requirement prompt in Skills and prompts, including source labels, assumptions, and acceptance checks as required fields.
3. Record the choices a person approved in Decisions and rules. Keep proposed options separate from those decisions.
4. Connect a supported assistant through Integrations and ask it to read the project context before drafting or reviewing.
5. Add accepted implementation work as tasks and save progress with unresolved questions, completed review, and the next person’s action.

fenbs does not conduct user research or decide your product scope. If you need only a one-time document draft, a document editor and these prompts may suffice. Its AI brain is useful when the approved reasoning must carry into later work; find more templates in the AI prompts hub.