Product Sense Means Knowing What to Delete

Every product team I've worked with has faced the same temptation: when something isn't working, add more. More features. More options. More complexity. It feels productive. You're shipping code. The roadmap looks full. Stakeholders see activity. But here's what I've learned: addition is easy. Any team can add features. The real skill—the thing that separates good products from bloated ones—is the discipline to remove. At Pangea.ai, we achieved 60% operational efficiency gains not by building more, but by ruthlessly cutting what didn't work. We transformed an Airtable-based system into a focused SaaS platform by asking one question repeatedly: "Does this actually solve the user's problem, or does it just make us feel like we're doing something?"

When I evaluate what to cut, I use three filters: 1. The Usage Test: If less than 20% of users engage with a feature regularly, it's a candidate for removal. Not every feature needs to be used daily, but unused features create maintenance burden and cognitive load. 2. The Explanation Test: If you can't explain why a feature exists in one sentence, it probably shouldn't. Complexity that requires training or documentation is often complexity that shouldn't exist. 3. The Reversal Test: If we removed this feature tomorrow, would users notice? Would they complain? If the answer is uncertain, that's telling you something. These aren't academic exercises. At NABR, we shipped three 0-to-1 products—Virtual 3D Tour, Capital Planner, and a SalesOps Platform. Each one succeeded because we cut scope aggressively. The Virtual 3D Tour, for instance, was instrumental in securing NABR's seed round. It worked because it did one thing exceptionally well, not because it did everything.

Adding features is politically safe. You're giving people what they asked for. You're showing progress. Nobody gets fired for shipping more. Deletion is different. It means telling stakeholders "no." It means admitting that past decisions were wrong. It means accepting that simplicity requires more thought than complexity. I've found that the best product decisions come from building, not just strategizing. When you're close to the work—when you're actually writing code, talking to users, and shipping features—you see the edge cases that PRDs miss. You feel the weight of unnecessary complexity. That's why I code. Not to replace engineers, but to understand what building actually feels like. The gap between spec and reality is where products fail. Closing that gap requires being willing to delete what you've built when you discover it doesn't work.

Here's something that took me years to internalize: removing features often improves metrics more than adding them. When you cut a feature: - Support tickets decrease - Onboarding time shrinks - Engineering velocity increases - User satisfaction often rises At Mireo, I grew revenue from €600K to €2.1M ARR—not by adding features to our fleet management product, but by restructuring the business model entirely. The problem wasn't missing features. It was a fundamental retention issue. Customers could leave after 12 months once they'd paid off their devices. The solution wasn't adding stickiness features. It was changing the commercial structure to secure minimum 3-year commitments. Sometimes the most important deletion isn't a feature at all—it's a flawed assumption about how your product should work.

If you want to develop better product sense, start here: Audit ruthlessly. Every quarter, review your feature set. What hasn't been used? What generates support tickets? What requires constant explanation? Prototype before committing. At Pangea.ai, we reduced specification time by 75%—from 4 weeks to 1 week—by using AI prototyping. When you can test ideas quickly, you discover what to delete before it becomes technical debt. Listen to what users do, not what they say. Users will always ask for more features. But their behavior tells a different story. Watch where they struggle. That struggle often points to complexity that needs to be removed, not features that need to be added. Embrace the uncomfortable conversations. The best product decisions often feel wrong initially. Cutting a feature someone fought for is hard. But if you can't justify a feature's existence with data, you're keeping it for political reasons—and that's a disservice to your users.