Key takeaway
Treat "build this feature?" as a bet on a specific outcome, not a verdict on whether the idea is good. Build only when the feature moves a metric you are trying to move, has demand evidence beyond a single loud voice, and no cheaper reversible test would answer the question first.
Almost every feature someone requests is a good idea — to that someone. That is exactly why "is this a good idea?" is the wrong question, and why feature backlogs grow without ever shrinking. Here is the worked version: the same seven-section structure YourBrief generates, applied to the build-or-not call so you can see the shape before running it on the feature actually in front of you.
| Demand evidence | Strength | What to do with it |
|---|---|---|
| a request — even a loud one | weakest | log it; look for the pattern |
| a willingness-to-pay signal | stronger | worth a designed test |
| measured usage of a fake-door or prototype | strongest | decide on this tier, not the loudest voice |
The decision
A single feature looks like a two-way door — you can always remove it later — but underneath it is closer to a one-way door. You are spending the roadmap slot you are deciding right now, and you are taking on a maintenance tail, a larger surface area, and a support burden you will own long after launch. So the real question is not "is this worth building?" It is "is this the best use of the one slot we are deciding right now, against everything else it displaces?"
Key questions to answer before deciding
- What specific outcome or metric is this feature supposed to move, and how will you know it did?
- Who exactly asked for it — one loud account, a churned prospect, or a repeated pattern across the market?
- What is the smallest version that would tell you whether you are right?
- What does it cost to maintain after launch, not just to build?
- What are you not building if you build this?
Recommended frameworks
Roadmap-displacement / opportunity cost. Force the trade explicit: name the specific thing this slot displaces. A feature is only worth building if it beats what it pushes out, not if it merely has value in isolation.
Demand-evidence tiering. Rank the evidence: a request is weaker than a willingness-to-pay signal, which is weaker than measured usage of a fake-door or prototype. Decide on the strongest tier you have, not the loudest.
Reversible-test-first. Before the full build, ship the cheapest probe that resolves the core uncertainty — a fake door, a fast pilot, or a prototype in front of five users.
Decision criteria
Build only if the feature moves a metric you are actually trying to move, has demand evidence beyond a single loud voice, and no cheaper reversible test would answer the question first. Otherwise ship the smallest probe or decline and revisit.
Sources to consult
Your own product usage data for the metric this is meant to move; the actual requesters (are they buyers, or just vocal?); one competitor who shipped something similar and what happened to their adoption afterward.
Next steps
Name the target metric; tier the demand evidence you actually have; design the smallest reversible test that would resolve the uncertainty; only greenlight the full build if that test clears a bar you set in advance.
When to escalate
Escalate if the feature would commit the team to a new platform or architecture, if it is driven by one strategic account's threat to churn (a sales exception wearing a product-strategy costume), or if it reshapes the roadmap for a quarter or more.
The honest answer for most feature requests is not "build it" or "reject it" — it is "run the cheapest test that would tell us." Generate this exact brief against the feature actually on your desk — $1 to start.