By Simon Sovič, Senior Product Manager
Every product manager knows the feeling. Your backlog is 200 items long. Stakeholders want everything built yesterday. Engineers are waiting. And somehow, saying "no" feels harder than shipping the wrong thing.
This guide gives you a repeatable process for deciding whatnotTo build. Follow it and you will protect your team's focus, ship features that move metrics, and stop wasting sprint capacity on work that sounds good in a meeting but helps nobody in production. The process takes about two to three hours the first time you apply it, then becomes second nature.
Difficulty: Intermediate. No tools required beyond a spreadsheet or your existing roadmap software.
What You'll Need
- Your current product backlog or feature request list
- Access to basic usage or retention data for your product
- A clear statement of your product's core objective for the next quarter
- A working relationship with at least one engineering lead who can give rough effort estimates
- 30 minutes with a customer-facing teammate (support, sales, or customer success)
Step 1: Write Down Your North Star Objective for the Quarter
Before you can say no to anything, you need a single sentence that defines what success looks like this quarter. Not a list of goals. One sentence. Something like: "Reduce time-to-first-value for new users from 14 days to 7 days."
This sentence becomes your filter. Every feature request that does not have a plausible, direct path to that outcome is a candidate for the "not now" list. Without this sentence, every request looks equally valid. With it, most requests sort themselves.
- Keep the objective measurable. Vague objectives create vague filters.
- Get explicit sign-off from your product lead or founder before you start filtering requests against it. This prevents stakeholder pushback later.
- If your company uses OKRs, the key result is usually close enough to use here.
Step 2: Map Every Request to a User Problem, Not a Solution
Go through your backlog and rewrite each item as the user problem it claims to solve. "Add dark mode" becomes "Some users find the current UI uncomfortable to read in low-light environments." "Build an API" becomes "Developers cannot integrate our product into their existing workflows without manual workarounds."
This step exposes two things immediately. First, some requests have no clear user problem behind them. They are solutions looking for a problem. Flag those immediately. Second, multiple requests often map to the same underlying problem, which means you might solve them all with one well-designed feature instead of three half-baked ones.
- Ask yourself: if you removed this feature, which user would complain and why? If you cannot name the user type or the pain, the request is not ready to build.
- Requests that come from internal stakeholders only, with no user evidence, move to the bottom of the list by default.
Step 3: Score Each Item on Impact and Effort
Use a simple two-axis scoring system. Rate each item on user impact (1 to 5) and engineering effort (1 to 5, where 5 is highest effort). Calculate a ratio: impact divided by effort. Items with a ratio above 1 are worth discussing. Items below 1 need a strong strategic reason to survive the cut.
From experience, teams that skip this step end up building high-effort, low-impact features because those features are usually the loudest ones in the room. A spreadsheet with three columns, item name, impact score, and effort score, is enough to make the math visible and take emotion out of the conversation.
- Get effort estimates from an engineer, not from the product or business side. Business people consistently underestimate complexity.
- Impact scores should reflect user impact, not executive enthusiasm. Use data where you have it: support ticket volume, churn surveys, user interviews.
- See the Full feature prioritization framework For a deeper scoring methodology you can apply alongside this step.
Step 4: Apply the "Reversibility" Test
For any item you are tempted to cut permanently, ask: how hard is it to add this later if we are wrong? Some features are cheap to add later. Others require database migrations, architectural changes, or retraining users on a new workflow.
Items that are cheap to add later can be safely deferred. Items that become exponentially harder to add later deserve a harder look even if their current impact score is moderate. This test stops you from making irreversible decisions by accident while clearing space on your roadmap.
- Architecture decisions are often irreversible. Feature decisions usually are not. Treat them differently.
- When in doubt, ask your engineering lead: "If we skip this now and want it in 12 months, does that change the build time significantly?"
Step 5: Create an Explicit "Not Now" List and Share It
Most teams have a backlog of things to build. Few teams maintain a visible list of things they have decided not to build and why. Create one. Call it your "Not Now" list. For each item on it, write one sentence explaining the decision: "Deferred because impact score is below threshold and this can be added later without architectural cost."
Share this list with stakeholders in the same place you share your roadmap. This is the step most product managers skip, and skipping it is why the same requests resurface every quarter. When people can see a request was considered and deliberately deferred with a reason, re-raising it requires new evidence, not just re-lobbying.
- Update the "Not Now" list quarterly. Conditions change. A request that made no sense in Q1 might be critical in Q3.
- Treat the list as a decision log, not a rejection pile. The tone matters when stakeholders read it.
Step 6: Write a One-Page Brief for What You Are Building Instead
Once you know what you are not building, the items that remain need enough clarity that your team can execute without ambiguity. A short product brief, sometimes called a product spec or one-pager, is the right tool here. It documents the problem, the proposed solution, the success metric, and any constraints.
A brief that engineers actually read is short, specific, and answers the questions they will ask before they ask them. It states what is out of scope as clearly as what is in scope. Learn more about How to write a product brief engineers actually read To make this step as effective as possible.
- Include a section titled "What we are not doing" in every brief. This prevents scope creep during the build.
- Limit the brief to one page or one Notion doc. If you need more space, the scope is too large.
Step 7: Run a Weekly "Kill Review" During Sprint Planning
Deciding what not to build is not a one-time event. Add a standing agenda item to your sprint planning or backlog refinement session: "What can we remove or defer this week?" Spend five minutes on it. Look at items that have been in the backlog for more than 90 days without being prioritized. Ask whether the conditions that created them still exist.
In practice, teams that do this consistently find they remove two to three backlog items per sprint without any loss of user value. The backlog stays actionable instead of becoming a graveyard of half-remembered requests.
- Set a rule: any item that has sat in the backlog for more than six months without being scheduled gets moved to the "Not Now" list automatically, unless someone can make a fresh case for it.
- This habit also reduces cognitive load for engineers who often feel anxious about the size of an untouched backlog.
Common Mistakes When Deciding What Not to Build
- Saying no without a reason."We are not building that" without context creates resentment. Always provide a one-sentence rationale tied to your current objective or scoring.
- Deferring everything instead of killing anything."Not now" should mean "not now, and here is when we will revisit this." If everything is deferred, nothing is truly prioritized.
- Letting the loudest voice win.A feature requested by one senior stakeholder is not automatically more valuable than a problem reported by 400 support tickets. Use data to anchor the conversation.
- Skipping the "Not Now" list.Without a visible artifact, deferred decisions are invisible and the same battles repeat every quarter.
- Treating the backlog as a commitment.Items in the backlog are hypotheses, not promises. Communicate this clearly to stakeholders from the start.
- Ignoring reversibility.Cutting something that becomes expensive to add later is a real cost, even if it feels like saving time now.
Applying This to Your Product Strategy
The decisions you make about what not to build are as much a part of your product strategy as the features you ship. Startups that stay focused consistently outperform those that try to satisfy every request. If you want a deeper framework for how these decisions fit into an overall product approach, the SaaS product strategy guide for founders Covers how to align your roadmap decisions with long-term competitive positioning.
FAQ
How do you say no to a feature request from a founder or CEO?
Anchor the conversation in the agreed quarterly objective and your scoring data. Say: "Here is how this request scores against our current focus and here is what we would need to deprioritize to fit it in. Do you want to make that trade-off?" This frames it as a resource decision, not a refusal, and puts the choice back in their hands with full information.
What is the difference between "not now" and "never"?
"Not now" means the request does not fit the current objective or resource capacity, but conditions could change. "Never" means the feature conflicts with the core product vision or would actively harm the user experience. Most decisions should be "not now" with a clear review date. Reserve "never" for requests that are genuinely out of scope for your product's purpose.
How do you handle features that customers have explicitly requested?
Customer requests are valuable signals, not binding commitments. Acknowledge the request, understand the underlying problem, and evaluate it through your scoring process. If you defer it, tell the customer what you are building instead and why it addresses their core need. Many customers care more about their problem being solved than about their specific proposed solution being built.
How often should you review the "Not Now" list?
Review it at the start of each quarter when you set your new objective. A request that did not fit last quarter's objective might fit this quarter's perfectly. Also review it when significant new user data arrives, such as a surge in a particular support category or findings from a user research round.
How does this process work for cross-functional teams?
The process works best when engineering, design, and product all participate in the scoring step. When engineers contribute effort estimates and designers flag UX complexity, the scores reflect real costs rather than optimistic guesses. Building this as a team ritual also distributes ownership of the "no" decision, so product managers are not the sole gatekeepers taking the political heat.
Built with SuperDuperSEO