Feature Prioritization Board — 3-Lens Product Decision Review
Decide whether to build a backlog item: tests it for one-loud-customer demand, hidden effort scope and roadmap misfit with a three-reviewer board verdict. Reviews a pasted feature request, backlog item or PRD through three independent lenses: User Value Skeptic (is this wanted by many users or one loud requester), Effort Realist (hidden scope behind words like 'just', missing edge cases, unshipped dependencies) and Strategic Fit Pragmatist (does it move this quarter's stated goal, and what is the opportunity cost). Phase 2 has the lenses challenge and corroborate each other's findings, and Phase 3 tags each finding CONFIRMED, CORROBORATED or DISPUTED and ends with a build, defer or cut recommendation. It does not invent user counts, revenue impact or competitive pressure, and it asks for missing effort or strategy inputs. It does not write the PRD or replace usage data. Text you paste is sent as-is to the model, so redact customer names and revenue figures first.
Example input
Use the Feature Prioritization Board on this (a sample I wrote). Backlog item BL-212: "Custom PDF report builder" for our fictional invoicing app, LedgerLeaf. Why: Our biggest enterprise customer (Acme-style account "Contoso Freight") asked for it on a call, and our VP of Sales says it would unblock their renewal. Request: let users drag fields into a branded PDF report template and schedule it by email. Effort: Engineering says "just a quick add on top of the existing CSV export", estimated 2 weeks for one engineer. Depends on the new permissions model, which is still in review. Roadmap context: This quarter's stated goal is to raise self-serve trial-to-paid conversion from 6% to 9%. Other backlog items competing for the same sprint: onboarding checklist (BL-198) and a bank-feed import fix (BL-205). No usage data attached. One other customer mentioned reports in a survey last year.
Example output
## Phase 1 — Independent findings ### 👥 User Value Skeptic - Single loud requester: the request originates from "Contoso Freight" on "a call," relayed by the VP of Sales. Request volume across users is not cited. If shipped tomorrow, would more than that one account open it? Unknown. Fix: pull request counts and usage of the existing CSV export before committing. - Only other signal is thin: "One other customer mentioned reports in a survey last year." One mention, a year old, is not demand. Fix: re-survey or check support tickets. - Possible overlap: the item builds "on top of the existing CSV export," so users who need reports may already get their data out that way. Whether anyone actually needs branded PDFs is unverified. - "No usage data attached." The benefit is stated as renewal protection for one account, not user benefit. ### ⚙️ Effort Realist - "Just a quick add on top of the existing CSV export" hides scope: drag-and-drop field layout, branded templates, PDF rendering, and email scheduling are four separate features, not a CSV variant. Two weeks for one engineer is not credible for that list. - Undisclosed dependency: "Depends on the new permissions model, which is still in review." Unshipped work gates the whole item, so the estimate is conditional on another team's timeline. - No edge cases or maintenance cost mentioned: scheduled email delivery failures, large reports, template versioning, bounced addresses, and ongoing PDF rendering bugs. Fix: re-estimate after listing them. ### 🎯 Strategic Fit Pragmatist - Off-goal: this quarter's goal is "raise self-serve trial-to-paid conversion from 6% to 9%." An enterprise report builder serves paying accounts, not trial users, so it does not move that metric. - Wrong segment: the requester is a large enterprise account, while the stated target is self-serve conversion. - Opportunity cost: it competes for the same sprint as "onboarding checklist (BL-198)" and "bank-feed import fix (BL-205)," both closer to conversion. No tradeoff is discussed. - The renewal claim is the only strategic argument, and no revenue figure for the renewal is stated, so the size of the retention risk cannot be weighed. ## Phase 2 — Cross-examination - [User Value #1 single loud requester] challenged by Strategic Fit Pragmatist: "A renewal at risk is a real business reason, so 'loud' is slightly overstated if the account is large, but the draft states no size." / corroborated by Effort Realist: "Cost scales with the whole feature set, which is a lot to spend on one account." …
Real output from running the skill on a sample problem, shortened. The skill file itself is not published here.