Build prioritization criteria for feature requirements

작성자: AILesson9 분 소요테스트::ChatGPT검토일: 2026-08-28

빠른 답변

Define evidence-based feature criteria, gates, scales, uncertainty, dependencies, and decision rules before scoring candidates. 제공할 내용: Decision context, Feature candidates and evidence, Scoring and governance constraints. 예상 결과: A calibrated prioritization rubric, evidence contract, scoring table, sensitivity test, and decision log template.

맥락 추가

텍스트는 이 브라우저에 유지됩니다. AILesson Prompts는 이를 모델이나 서버로 보내지 않습니다.

Decision contextFeature candidates and evidenceScoring and governance constraints

프롬프트

채워지지 않은 필드는 플레이스홀더로 표시되므로 프롬프트를 복사하고 편집할 수 있습니다

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.

Playground에서 사용해 보기

기본적으로 비공개프롬프트 구성은 브라우저에서 로컬로 이루어집니다. 조직에서 허용하지 않는 한 기밀 정보를 AI 서비스에 입력하지 마세요.

입력에서 결과까지

적용 예시

구체적인 맥락이 이 레시피를 바로 사용할 수 있는 결과로 바꾸는 방법을 확인하세요

실제 입력

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.

예시 출력

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.

Feature	Evidence	Collection	Fit	Feasibility	Sustainability	Weighted	Confidence/gates
F1	4	2	4	2	2	2.9	medium-high; accessibility open
F2	2	1	3	2	1	1.8	low; privacy/content risks open
F3	3	1	2	1	2	1.9	medium for integration pain, low for collection; security gate open
F4	2	1	1	4	4	2.2	low-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.

효과가 있는 이유

1
Behavioral anchors and evidence contracts keep scores comparable across reviewers
2
Gates and sensitivity tests reveal when a neat ranking is unstable or invalid

결과 확인

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?

안심하고 사용하세요

자주 묻는 질문

이 레시피를 언제 사용해야 하는지, 무엇을 제공해야 하는지, 그리고 어떤 부분에서 사람의 검토가 여전히 중요한지에 대한 실용적인 답변

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.

더 많은 탐색 방법