How I Decide What NOT to Build (It's Harder Than Saying Yes)

The spreadsheet that changed how I think about features

When I joined Sonic Linker's founding team, we were drowning in requests. Enterprise prospects wanted custom integrations. Early users wanted dashboards. Our CEO wanted AI features that would wow investors. Sales wanted anything that would close deals faster.

I made a spreadsheet. Not because I love spreadsheets, but because I needed to stop lying to people (and myself) about what we'd build.

Three columns: Feature, Who Asked, Why They Think They Need It.

Then I added the column that changed everything: What Problem Does This Actually Solve?

Turns out, 60% of requests were solutions masquerading as problems. Someone would say "we need a bulk export feature" when what they really meant was "I can't easily share this data with my team." That's a different problem. Different solutions. Way different level of effort.

The 3 questions I ask before saying no

I don't use frameworks like RICE or ICE anymore. They're useful for prioritizing things you've already decided to build. But deciding what NOT to build? That needs different questions.

1. Is this a painkiller or a vitamin?

At Finvestfx, we had a client who wanted real-time currency alerts. Sounded urgent. But when I dug deeper, they were checking rates manually twice a day anyway. It was a nice-to-have, not a blocker. We said no.

Meanwhile, three different clients were complaining about our reconciliation process taking 4+ hours. That was a painkiller. We rebuilt it in two weeks.

Painkillers get built. Vitamins get parked.

2. Does this request represent a segment or just one loud voice?

One enterprise client at Finvestfx wanted custom report templates for their 15 regional offices. Big client. Loud voice. I was ready to say yes.

Then I talked to 8 other clients. None of them cared. They wanted better mobile access. That client's request would've consumed 3 weeks of dev time for one use case.

We built mobile improvements instead. Retention jumped 12% across all clients. That one loud client? They adapted. They always do.

3. Will this make us better at our core thing, or just different?

This is the hardest one. At Sonic Linker, we got asked constantly to add features that would make us "more like" competitors. More dashboards. More integrations. More customization.

But our core thing was speed. AI-powered linking in seconds, not hours. Every feature that added complexity was a feature that made us slower.

I started asking: Does this make us faster? If not, does it make fast linking more valuable? If neither, we're not building it.

We said no to a dashboard that would've taken 6 weeks. Built performance improvements instead. Cut processing time by 40%. That became our sales pitch.

The hardest no I ever had to deliver

At NJ Group, I was coaching insurance advisors and IFAs on product adoption. One advisor, really sharp guy, wanted a mobile app that would let him generate quotes on the spot during client meetings.

Made total sense. I pitched it internally. Got budget approval. Started scoping it out.

Then I spent a week shadowing him on actual client visits.

He never generated quotes in meetings. He built rapport, asked questions, and sent quotes later after doing research. The mobile app would've been used maybe twice a month.

What he actually needed? Faster quote generation back at the office. We rebuilt the backend workflow instead. Cut quote time from 20 minutes to 4 minutes. He closed 30% more deals in the next quarter.

I had to tell him we weren't building his idea. That sucked. But I showed him the data from shadowing 8 other advisors. He got it.

What I do instead of building

Saying no doesn't mean doing nothing. When I park a feature request, I do three things:

First, I explain the why. Not corporate speak. Real reasons. "We're not building this because it would slow down the core product, and speed is why you chose us."

Second, I offer an alternative. Sometimes it's a workaround. Sometimes it's a different feature that solves the same problem better. At Finvestfx, we couldn't build custom dashboards, but we made our export format work with every major BI tool. Problem solved.

Third, I revisit it quarterly. I keep a "parking lot" doc. Every quarter, I review it. Some requests age like milk. Others become obvious priorities once we've shipped other things.

The real skill isn't saying no

It's saying no while keeping people excited about what you ARE building.

At Sonic Linker, we shipped 6 features in Q1. But we talked constantly about those 6. Showed progress. Got feedback early. Made people feel part of the build.

The 41 we didn't build? Most people forgot about them. Because they were busy using the 6 that actually mattered.

Here's what I learned: Your product isn't defined by what you build. It's defined by what you refuse to build. Every feature is a vote for what kind of product you want to be. Choose carefully.