Force a real feature-prioritization call instead of a roadmap where everything is 'high priority'

CANDIDATE FEATURES
Bulk CSV export, in-app notifications, SSO login, dark mode, custom report builder, Slack integration.

BUSINESS GOAL THIS QUARTER
Reduce enterprise-tier churn, which exit interviews cite security/compliance gaps as a factor in.

KNOWN EFFORT ESTIMATES (if any)
SSO login: ~3 weeks (two engineers); dark mode: ~1 week; custom report builder: ~6+ weeks, high uncertainty.

EVIDENCE BEHIND EACH FEATURE'S EXPECTED IMPACT
SSO login requested explicitly by 4 of the last 6 churned enterprise accounts; dark mode requested informally by a handful of individual users on Twitter with no revenue link.

TEAM CAPACITY
Two backend engineers and one designer, roughly 10 engineer-weeks of net new capacity after maintenance work.

For each feature in CANDIDATE_FEATURES, assign three scores on a 1-5 scale: Impact (tied specifically to BUSINESS_GOAL, not impact-in-general — a feature can be broadly useful and still score low here if it doesn't serve this quarter's specific goal), Effort (using EFFORT_ESTIMATES where given; where absent, state your estimate is a rough guess and flag it as needing real estimation before being relied on), and Confidence (how strong the evidence behind the impact claim actually is — a feature justified by one anecdotal customer request scores lower here than one backed by usage data or multiple independent requests, and you must state what IMPACT_EVIDENCE actually consists of for each feature, not just assert a confidence number).

Compute a priority signal from these three scores, but do not let the arithmetic alone decide — after ranking, sanity-check the top of the list against TEAM_CAPACITY and flag if the highest-scoring set of features would collectively exceed what the team can realistically ship this quarter, since a ranked list that ignores capacity is not a roadmap, it's a wish list. Where two features score near-identically, do not present them as tied; force a tiebreaker by naming the one additional factor (strategic sequencing, a dependency between them, an external commitment already made) that would actually decide between them in practice.

WHAT NOT TO DO
Do not inflate every feature's impact score to justify including it — if a feature genuinely doesn't serve BUSINESS_GOAL this quarter, its low score should be visible even if it's a good feature in general; a prioritization exercise that scores everything 4 or 5 has failed at its one job. Do not average the three scores into a single number without also showing them separately — leadership needs to see whether something ranked highly because it's truly high-impact or because it's merely low-effort.

OUTPUT FORMAT
1. Table: feature | impact score + one-line reason | effort score + basis | confidence score + evidence basis | resulting rank.
2. The ranked shortlist that fits within TEAM_CAPACITY, explicitly separated from the features that scored well but don't fit this quarter.
3. Any forced tiebreaker calls, with the deciding factor named.
4. One paragraph naming the feature most likely to be over- or under-rated by this exercise and why, so a human reviewer knows where to apply judgment.