Build prioritization criteria for feature requirements

Author: AILesson9 min setupTested with:ChatGPTReviewed: 2026-08-28

Quick answer

Define evidence-based feature criteria, gates, scales, uncertainty, dependencies, and decision rules before scoring candidates. Provide: Decision context, Feature candidates and evidence, Scoring and governance constraints. Expected result: A calibrated prioritization rubric, evidence contract, scoring table, sensitivity test, and decision log template.

1

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

2

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt

Build a defensible feature-prioritization framework for the supplied decision and candidates.

Decision context:
[decision]

Candidates and evidence:
[candidates]

Scoring and governance rules:
[rules]

Separate mandatory gates from comparative criteria. For every criterion define the decision question, scale with behavioral anchors, allowed evidence, disallowed proxy, direction, weight only if approved, missing-data treatment, confidence, and double-counting risk. Keep user reach, severity, strategic fit, evidence confidence, effort, operational load, technical risk, accessibility, privacy, safety, and dependencies distinct when relevant. Do not invent impact, estimates, users, revenue, obligations, weights, or precision. A weighted score supports discussion; it does not override gates, dependencies, uncertainty, or decision authority. Calibrate with at least two supplied candidates, show raw and confidence-adjusted views only when the rule is explicit, test sensitivity to plausible weight or estimate changes, identify dominated and incomparable options, and output a scoring sheet, evidence gaps, sequencing choices, decision log, and review trigger.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.

From input to outcome

A worked example

See how concrete context turns this recipe into a usable result

Actual input

Decision context
Choose at most one six-week discovery-and-delivery bet for a small invoicing product in Q4. Goal: reduce failed invoice collection for freelancers. Capacity: four engineer-weeks, one designer-week, and no new support headcount. Security review is mandatory for any change to payment data. Product lead recommends; GM decides. Accessibility baseline WCAG 2.2 AA is a release gate. Mandatory regulatory work is handled separately and must not compete in this ranking.
Feature candidates and evidence
F1 payment-reminder scheduling: 18/24 interviewed freelancers report manual reminders; event data show 31% of overdue invoices receive a manual reminder. Prototype task success 7/8. Estimate 3–5 engineer-weeks, one designer-week; depends on notification service; support expects configurable timezone questions. F2 AI-written reminder tone: 9/24 ask for wording help; no behavioral usage evidence; prototype comprehension 5/8; estimate 2–4 engineer-weeks plus ongoing model cost and content review; privacy and hallucination assessment not done. F3 payment-status webhook: requested by 4 bookkeeping partners representing 620 linked accounts; partner logs show status polling 14,000 times/month. Estimate 5–8 engineer-weeks; requires security review and API versioning; user collection effect unmeasured. F4 invoice color themes: 6/24 mention branding; analytics unavailable; estimate 1–2 engineer-weeks; no dependency. Estimates are ranges, not commitments.
Scoring and governance constraints
Use 1–4 anchored scales. Approved comparative criteria and weights: user-problem evidence 30%, expected collection contribution 25%, strategic fit 15%, delivery feasibility 20%, operating sustainability 10%. Evidence confidence is shown separately, not multiplied into score. Gates: accessibility for all; security for payment data. Do not use requester seniority or raw partner account count as a substitute for end-user benefit. Unknown impact scores 1, not zero. Effort range crossing capacity must be flagged. Tie within 0.2 is unresolved; use evidence-gathering value as tie-break, not arbitrary decimals.

Example output

Prioritization framework

Anchors use 1–4. Problem evidence: anecdote only; repeated qualitative; qualitative plus behavioral; replicated strong evidence. Collection contribution: unknown; plausible indirect; measured leading signal; measured collection outcome. Strategic fit: peripheral to direct. Feasibility: clearly exceeds capacity; range crosses capacity or unresolved major dependency; fits with manageable dependency; comfortably fits. Sustainability: unresolved recurring risk; high load; manageable; low load. Each score cites evidence; confidence is low, medium, or high and remains separate.

FeatureEvidenceCollectionFitFeasibilitySustainabilityWeightedConfidence/gates
F1424222.9medium-high; accessibility open
F2213211.8low; privacy/content risks open
F3312121.9medium for integration pain, low for collection; security gate open
F4211442.2low-medium; accessibility open

Recommendation: F1 is the leading discovery-and-delivery bet, not an automatic approval. Its 3–5 week range crosses four-week capacity and timezone operations are unresolved. Before commitment, narrow the estimate, test notification-service dependency, define timezone defaults, and verify WCAG AA. F3 cannot fit the stated capacity and lacks collection-effect evidence; consider separate discovery. F2 is dominated by F1 on current evidence and adds unresolved recurring controls. F4 is feasible but weakly connected to the goal.

Sensitivity: raising feasibility from 20% to 35% could bring F4 close to F1; lowering F1 problem evidence from 4 to 3 reduces its lead. The decision is therefore sensitive to capacity confidence but not enough to make F2 preferable. Log GM decision, selected evidence, exceptions, owner, and review trigger. Reopen ranking if F1 estimate exceeds five weeks, accessibility fails, notification dependency blocks, or new collection-outcome evidence arrives.

Why this works

  1. 1

    Behavioral anchors and evidence contracts keep scores comparable across reviewers

  2. 2

    Gates and sensitivity tests reveal when a neat ranking is unstable or invalid

Check the result

  • Does each criterion measure one decision-relevant construct with observable anchors?

  • Are missing evidence, confidence, gates, dependencies, and double counting visible outside the total score?

  • Would plausible changes to weights or estimates alter the recommendation and trigger review?

Use it with confidence

Frequently asked questions

Practical answers about when to use this recipe, what to provide, and where human review still matters

What should I prepare before using “Build prioritization criteria for feature requirements”?

For “Build prioritization criteria for feature requirements,” prepare Decision context, Feature candidates and evidence, and Scoring and governance constraints. Replace placeholders only with information you can verify. If a detail is unknown, preserve that uncertainty explicitly instead of asking the model to infer it.

When is the “Build prioritization criteria for feature requirements” result not ready to use?

The result is not ready if it does not yet deliver the stated outcome—A calibrated prioritization rubric, evidence contract, scoring table, sensitivity test, and decision log template—from the supplied evidence, or if it relies on unresolved assumptions, missing approvals, or invented details. Use the checks as release gates: revise the source inputs or assign a named, authorized reviewer instead of polishing an unsupported output.

Which AI tools have recorded tests for “Build prioritization criteria for feature requirements”?

The published test record for “Build prioritization criteria for feature requirements” lists ChatGPT as of 2026-08-28. This confirms recorded runs, not guaranteed compatibility or identical results in later product versions. For another tool or version, keep every constraint visible and repeat the result checks before use.

Keep the work moving