How I Decide What NOT to Build (Spoiler: It's Not About Priority Scoring)
At Sonic Linker, I had 47 feature requests in our Notion board after month two. I shipped 4 of them.
The other 43? Still sitting there, and our users are happier for it.
Every PM guide tells you to prioritize ruthlessly. They hand you RICE scores, impact/effort matrices, value vs. complexity charts. I've used all of them. They're helpful for comparing things you've already decided to consider.
But the real skill isn't picking between good ideas. It's killing things before they even make it to your scoring spreadsheet.
The Question That Kills 60% of Requests Immediately
I ask: Does this make the core workflow faster, or does it add a new workflow?
At Sonic Linker, we built an AI platform that helps teams turn raw voice notes into structured content. The core loop is: record, AI processes it, you edit, you publish. That's it.
In month three, a user asked for a "collaboration mode" where multiple people could edit the same output simultaneously. Sounds reasonable, right? Google Docs has it. Notion has it. Why shouldn't we?
Because it's a new workflow. It doesn't make the existing loop faster. It introduces permissions, conflict resolution, comment threads, version history. Suddenly we're not an AI content tool, we're building a lightweight CMS.
I said no. We focused on making the AI processing 40% faster instead. That user churned. Five others upgraded to paid because the tool felt snappier.
The math worked.
The Finvestfx Test: Can You Explain It in One Sentence to a New User?
At Finvestfx, we had 20+ enterprise clients using our forex treasury platform. Every single one wanted custom reporting. Different currencies, different compliance formats, different export templates.
I could have built a custom report builder. Drag and drop fields, save templates, the whole thing. It would have taken two months.
Instead, I asked: can I explain this feature to a new client in one sentence during onboarding without them looking confused?
"You can build custom reports" requires 15 minutes of demo time. "Here are your three compliance-ready reports" takes 30 seconds.
We built three fixed report templates that covered 90% of use cases. The other 10%? We exported raw CSVs and let their finance teams handle it in Excel. Not elegant, but it worked.
Saved us two months of dev time. Onboarding stayed under 45 minutes. Retention actually improved because new users weren't overwhelmed by options.
If you can't explain a feature simply during onboarding, it's probably not core enough to build.
The Brutal Reality: Most Features Are Just Anxiety Responses
Here's what I've learned across Sonic, Finvestfx, and my time at Stampede Capital: most feature requests aren't about solving a real problem. They're about anxiety.
"Can we add SSO?" = I'm worried about security.
"Can we add bulk actions?" = I'm worried about scale.
"Can we add more integrations?" = I'm worried we're not sticky enough.
The anxiety is real. But building features to calm your own anxiety, or your stakeholder's anxiety, is how you end up with a bloated product that does 50 things poorly.
At NJ Group, I was coaching 60 insurance advisors and IFAs on product adoption. They kept asking for more features in the CRM we were rolling out. More fields, more automations, more dashboards.
But when I sat with them for a day, I realized they weren't even using 40% of what already existed. They were anxious about missing data, so they wanted more places to put data.
I didn't build more fields. I built a simple onboarding checklist that showed them exactly which five fields actually mattered for their compliance audits. Adoption jumped 30% in six weeks.
What I Actually Do Instead
When a request comes in, I run it through three filters:
- Does it make the core loop faster? If no, probably not building it.
- Can I explain it in one onboarding sentence? If no, it's too complex.
- Is this solving a problem or calming anxiety? If it's anxiety, I look for a simpler fix first.
If it passes all three, then I'll throw it in a RICE framework or whatever. But honestly, by that point, the decision is usually obvious.
The hardest part isn't the framework. It's having the confidence to say no to your CEO, your biggest client, or that one power user who emails you every week.
But here's what I keep coming back to: every feature you build is a promise to maintain it forever. It's documentation to write, edge cases to handle, onboarding time to add, and cognitive load for every user.
The best products I've worked on, the ones with the highest NPS and lowest churn, weren't the ones with the most features. They were the ones that did one thing so well that users forgave everything else.
That's the bar. If a feature doesn't clear it, it stays in the Notion graveyard with the other 43.