Saying no to feature requests is the whole job. A founder's system for product prioritization: score requests, keep a graveyard, kill dead features, protect velocity.
One month at Shpper I kept a private tally of every feature request that came in. Sixty-one, all from real users, each one reasonable on its own. We built four. The other fifty-seven were the job.
Nobody warns you about this when you start building a product. Everyone obsesses over what to build. Almost nobody says out loud that a product roadmap is mostly a list of things you have deliberately refused to build. The refusing is not a side effect of strategy. It is the strategy. And most founders are bad at it because they treat "no" as a mood — a thing they feel when they're tired or cornered — instead of a repeatable system anyone on the team can run without them in the room. Product prioritization, done well, is the discipline of institutionalizing that "no" so it survives contact with a loud customer, a nervous sales rep, and your own worst instincts.
The mental model I wish someone had beaten into me in year one: a feature is not a thing you ship, it's a thing you own, forever, until you explicitly kill it.
When you say yes, you're not buying the two weeks it takes to build. You're taking out a mortgage. The principal is the build. The interest is everything after:
On a recent project we added a niche export format because one enterprise prospect called it a dealbreaker. The build took nine days. Over the next eighteen months it broke twice during unrelated migrations, forked three code paths, and confused four other customers who found it in the UI and assumed it was a supported first-class flow. The prospect never signed. That nine-day build cost us something like forty days of amortized interest, paid in installments I never saw coming. I didn't feel any of it on the day I said yes. That's the trap — the bill arrives quietly, spread across quarters, and by the time you feel it you can't trace it back to the decision that caused it.
Velocity in a young product isn't how fast you can add things. It's how few things you have to hold in your head to change anything. Every feature you keep is another node in the dependency graph, another branch in every conditional, another paragraph in the onboarding. Engineers call the aggregate of this technical debt and accidental complexity; I think of it more bluntly as the mortgage payment on past yeses. Each one shrinks your headroom by a little, and you only notice once there's none left and a two-line change somehow takes a week.
The reason teams underprice features is that they estimate the build and stop there. The real cost function looks more like this:
total_cost = build_effort + (maintenance_per_period * periods_alive) + coordination_tax(features_that_must_stay_compatible) + support_and_docs_load + opportunity_cost(what_you_didn't_build_instead)
The first term is the only one you can see clearly on the day you decide. The rest compound. periods_alive is usually measured in years, not weeks, and coordination_tax grows superlinearly — the tenth feature has to stay compatible with nine others, not with zero. When someone says "it's only two weeks of work," they've quoted you build_effort and silently ignored the four terms that actually dominate the bill.
I keep a document I call the graveyard. It is not a backlog. A backlog is a list of things you intend to do. The graveyard is a list of things you decided not to do, each with a reason and a date.
Sounds like bureaucracy. It's the opposite. It's how I stop re-litigating the same decision every quarter. When a request comes back — and the good ones always come back — I don't start from zero. I read what I wrote last time and ask one question: what changed? Usually nothing did, and the no takes thirty seconds instead of a thirty-minute meeting where three people rediscover a conclusion I already reached in March.
An entry is deliberately cheap to write. A row per request is enough:
| Date | Request | Underlying need | Decision | Revisit if ||------------|-----------------------|-------------------------|----------|--------------------------|| 2026-03-11 | Custom report builder | Month-end numbers hurt | No | 3+ paying accounts churn || 2026-04-02 | Bulk-edit button | 40 records one-by-one | No | Import redesign slips || 2026-05-19 | Niche export format | One prospect's checkbox | No | 5+ unprompted asks |
The Revisit if column is the part that earns its keep. It converts a judgment call into a falsifiable trigger — a condition that, if it ever becomes true, reopens the decision automatically. You are not saying "never." You are saying "not until the world looks different, and here is exactly how different."
What a couple of years of entries taught me:
The most expensive mistake I see founders make — I made it for years — is confusing volume with representativeness. The loudest customer is not the average customer. They're just the loudest, and loud is easy to mistake for important when it's landing in your inbox at 11pm.
A client once asked me, across a chain of escalating emails, for a specific dashboard widget. It felt urgent because they were urgent. Before building it I did something boring: I pulled usage on the screen they wanted to put it on. Roughly 4% of active accounts had opened that screen in the last thirty days. We were about to burn two weeks serving a request that, at best, one loud user in twenty-five would ever lay eyes on.
This is selection bias in its purest form: the people who write in are systematically unrepresentative of the people who don't. Vocal users skew toward power users and toward the frustrated; the silent majority — including the prospects you haven't won yet — never show up in your inbox at all. If you build only for the people loud enough to email you, you optimize for a slice of your market and quietly alienate the rest.
My filter now is a short list of questions a request has to survive before it earns real consideration:
None of this means ignoring individuals. It means weighting them correctly. The plural of "one angry email" is not "the market."
The reason "no" collapses into a mood is that it usually has nothing behind it. Someone asks, the founder feels a vibe, the vibe becomes the roadmap. That doesn't scale, and it isn't defensible. You cannot teach a vibe to your team, and you cannot argue with one either.
So I turned my no into a scorecard — a lightweight, transparent alternative to heavier frameworks like RICE or weighted scoring, tuned for a small team that has to decide fast. Every non-trivial request gets scored on five axes, each 1 to 5:
| Axis | Question | Weight |
|------|----------|--------|
| Reach | How many of our real users hit this pain? | x3 |
| Alignment | Does it push our core bet forward, or sideways? | x3 |
| Evidence | Anecdote, or data plus repeated unprompted asks? | x2 |
| Cost | Build plus the ongoing maintenance interest | x2 (inverted) |
| Reversibility | Can we undo it cheaply if we're wrong? | x1 |
Cost is inverted because cheap is good: a low-cost feature should raise the score, not lower it, so I score cost 1-to-5 and subtract its weighted value. Worked example — a request that scores Reach 2, Alignment 2, Evidence 2, Cost 4 (expensive), Reversibility 2:
score = (Reach*3) + (Alignment*3) + (Evidence*2) + (Reversibility*1) - (Cost*2) = (2*3) + (2*3) + (2*2) + (2*1) - (4*2) = 6 + 6 + 4 + 2 - 8 = 10
I add it up. There's no magic threshold that decides for me — the number is not the point. The conversation the scorecard forces is the point. It turns "I don't feel like building this" into "this scores a 10, Reach and Alignment are the two axes dragging it down, and here's exactly what would have to change to move them." Now anyone on the team can run it, and anyone can challenge the output on specifics instead of arguing with my gut.
Two rules keep it honest:
A structured no is worthless if you deliver it like a wall. The goal is not to win the argument. It's to keep the relationship while protecting the product. A few moves that hold up:
Say no to the feature, yes to the problem. Almost nobody actually wants the feature they asked for. They want the outcome. "We're not going to build a custom report builder, but I hear that month-end numbers are painful to pull. Here's how to solve that today, and here's what's coming next quarter that removes the pain for good." You just declined the request and kept the trust. Nine times out of ten there is a workaround, a config, or an integration that solves the underlying job without adding a permanent feature to maintain.
Be honest about the why, not just the what. People swallow a "no" far more easily when they see the constraint behind it. "If we build this the way you're describing, it makes the product worse for the other 90% of users, and I won't do that to them" is a reason a serious person respects. Vague deflection is not. Founders underestimate how much credibility a candid constraint buys you.
Never fake a maybe. The cruelest thing you can do is soft-yes something to dodge an awkward moment, then let it rot in a backlog forever. That's not kindness. It's cowardice with extra steps, and it wastes a year of their planning on a thing you already know you'll never build. A clean no today beats a fake maybe every time. A backlog full of polite maybes is not a roadmap; it's a graveyard you refuse to admit you've dug.
Make the graveyard a promise, not a black hole. I tell people, truthfully: "I'm writing this down with your reasoning, and if the situation changes — more users hit this, our bet shifts — it comes back up automatically." That's the Revisit if column doing customer-facing work, and they can hear the difference between that and a brush-off.
On deals specifically: in six years I've lost exactly two prospects to a feature I refused to build. I've kept my sanity and my product's focus by refusing hundreds. That trade isn't close, and I'd make it again tomorrow. A single-customer feature — what people call a one-off or a bespoke build — is one of the most expensive things a young company can agree to, because you inherit all the mortgage and only one customer helps pay it.
New features get the applause. Old, unused ones quietly tax you forever, and nobody notices because the cost never shows up on any single day.
Every feature you keep is:
Twice a year I run a usage audit. Pull the analytics, sort features by active usage, and stare hard at the bottom of the list. Anything a rounding-error percentage of users touch goes on a watchlist. On our last audit, three features came in under 1% usage — and one of them I had personally lobbied hard to build. Sentimental attachment to your own past decisions is the enemy in that meeting. The version of me who fought for it doesn't get a vote anymore.
To make the audit concrete, I want two numbers per feature before the meeting: active usage (share of active accounts that touched it in the last 30 days) and exclusive reliance (accounts for whom it's the only way to accomplish a job). A feature can be low-usage but high-reliance — a handful of accounts would be stranded without it — and that's a different decision than something nobody depends on at all. Splitting those two numbers keeps the audit honest.
The uncomfortable part: a feature nobody uses isn't neutral. It's a cost with no benefit on the other side of the ledger. It's negative. The only way to stop paying is to remove it.
Saying no to something that doesn't exist is easy. Nobody's using it, nobody's attached. Saying no to something you already shipped, already announced, already have a handful of users on — that's the discipline almost nobody practices, and it's the line between real product judgment and feature hoarding.
The excuses write themselves. "Someone might be using it." "We already built it, ripping it out wastes the work." That second one is the sunk-cost fallacy in a suit. The build is gone either way — you spent that money years ago. The only live question is whether keeping it is worth the interest it charges from here forward. Usually it isn't.
How I actually pull a feature without a revolt:
Here's roughly what the deprecation gate looks like in practice:
// Stage 1: hide from new users, keep it alive for existing ones.bool canSeeLegacyExport(User user) { if (featureFlags.isKilled('legacy_export')) return false; // stage 3: off for everyone if (user.createdAfter(deprecationDate)) return false; // stage 1: hidden from new users return user.hasUsedRecently('legacy_export'); // stage 2: only real, active users}When usage under that gate decays to near zero, stage 3 is a one-line flag flip, and then you delete the function and its call sites entirely. No orphaned code, no permanent conditional.
We killed that niche export format eventually. Two users noticed. One of them thanked us for simplifying the export screen. The product got lighter, the code got simpler, and I stopped paying rent on a decision I'd made under sales pressure years earlier. That deletion felt better than most of the features I've shipped.
The roadmap is defined by your refusals, not your yeses. Make "no" a system, not a mood:
Revisit if trigger that would reopen it, so you never re-litigate the same request from scratch.Building the right product is mostly the accumulated weight of the wrong ones you had the discipline to refuse.