The Features I Killed Before Writing a Single Line of Code

The 15-minute rule that saved me from building garbage

I keep a "graveyard" doc. It's where feature ideas go to die.

At Sonic Linker, we were building an AI SaaS platform from scratch. Founding team, zero revenue, pressure to ship fast. Every user call generated 3-4 feature requests. Every competitor demo revealed something we didn't have. Every internal brainstorm added to the pile.

Within a month, I had 47 items in my backlog.

I built 6 of them.

The rest? Dead. And I'm not apologizing for it. Because the real work wasn't figuring out what to build. It was getting ruthlessly good at saying no before we wasted engineering time.

Here's the filter I actually used. If I couldn't answer these three questions in 15 minutes, the feature was dead:

1. Who asked for this, and did they pay us or churn because of it?

Not "would this be nice to have." Not "users might like this." Did someone literally stop using the product because it didn't exist? Or did someone about to pay us say "I'll sign if you add X"?

At Finvestfx, I managed 20+ enterprise treasury clients. One of them asked for custom report exports in a specific XML format. Felt important. Big client. But when I dug in, they had a workaround. It took them 10 extra minutes a week. They weren't churning. They weren't blocking expansion.

I killed it. Used that sprint on fixing a bug that was actually causing drop-offs in onboarding. Retention went up 12% the next quarter.

2. Can I validate this in a week without engineering?

If I can't fake it, prototype it, or manually deliver it to test demand, it's probably not urgent.

At Sonic Linker, users kept asking for bulk upload. Sounded critical. But instead of building it, I offered to manually upload CSVs for them via support. Three users took me up on it. Two never used the feature after upload. One used it once and never again.

We didn't build bulk upload for 4 months. When we finally did, we scoped it way smaller because we knew exactly how it'd be used.

3. Does this move the one metric that actually matters right now?

Early stage, that metric was activation rate (did new users complete setup and run their first task). Growth stage at Finvestfx, it was feature adoption among existing clients (were they using the new modules we'd shipped).

If a feature didn't directly move that number, it went in the graveyard. I don't care how cool it was.

Someone wanted a mobile app at Sonic Linker. I loved the idea. But our activation problem was on desktop. Users were dropping off during API key setup, not because they couldn't check the app on their phone. Mobile would've been a 2-month distraction that moved nothing.

Killed it. Spent that time simplifying onboarding instead. Activation went from 34% to 51% in 6 weeks.

The graveyard isn't a trash bin. It's a map.

I revisit my "no" list every quarter.

Some ideas age well. At Sonic Linker, we killed a Slack integration in month 2 because nobody was asking for it. By month 7, it was the third most-requested feature. We built it then, and it actually got used.

Others stay dead forever. And that's fine.

The mistake I see PMs make is treating the backlog like a promise. It's not. It's a hypothesis graveyard. Most of those hypotheses deserved to die. A few might get resurrected when the context changes.

What I actually do when a founder or exec pushes back

This happens. Someone senior wants a feature. You think it's wrong. Here's what worked for me:

I don't say "no." I say "here's what we'd have to de-prioritize, and here's the trade-off." Then I put the decision on them with data.

At Finvestfx, leadership wanted a mobile dashboard for treasury managers. I showed them: (1) only 8% of users logged in via mobile, (2) building it meant delaying API v2, which was blocking two enterprise deals, (3) the revenue impact was 40k vs. 300k.

They still wanted it. Fine. I built it. It got 11% adoption in 6 months and we had to delay API v2 by a quarter. I was right, but I didn't die on that hill. I just made the trade-off visible.

Sometimes you lose. The key is making sure everybody knows what you're losing.

The real insight: saying no is a product skill

At IIM Ranchi, we talk about prioritization frameworks. RICE, value vs. effort, all that. They're useful.

But the actual skill is getting comfortable killing ideas that sound good. It's not about being smart enough to pick winners. It's about being disciplined enough to starve the losers before they eat your roadmap.

I still have 23 features in my graveyard doc from Sonic Linker. Some of them were genuinely good ideas. Most of them would've been distractions.

The product we shipped in 3 months exists because of what we didn't build. That's the part nobody tells you.