A product manager once walked us through a new feature in our weekly review. Twenty slides. Conditional logic. Edge cases. Integration points. I watched people around the table nod along. The CEO asked clarifying questions that somehow made it sound even more complex. Fifteen minutes in, I still had no idea what problem we were solving.
I assumed I’d missed something. Maybe I wasn’t paying attention. Maybe everyone else just got it faster. So I stayed quiet.
Next day after the meeting, I’m on call with engineering lead. He looked exhausted. “Did you understand any of that?” I admitted I didn’t. He laughed. “Neither did I. Neither did anyone in that room.”
We’d all sat there pretending to follow along because we thought everyone else understood. The product manager thought we were all on board.
See, complexity isn’t just a design problem. It’s a courage problem. We keep things complicated because we’re afraid to admit we don’t understand them. And we’re afraid to cut things because removal feels like admitting we were wrong to build them in the first place.
Simple solutions look easy after the fact. The hard part isn’t making it work — it’s deciding what to cut. Complexity is the default. Clarity is the edit.
You don’t wake up one day and decide to build something complicated. It happens gradually. A feature here. An edge case there. A stakeholder request. A “what if” scenario.
New features get added. Old ones stay. Stakeholders contribute ideas, but no one volunteers to kill theirs. “Just in case” thinking accumulates over time until you’re maintaining a system that does everything and solves nothing clearly.
There’s a principle in systems thinking called Gall’s Law:
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
In other words, complexity isn’t a starting point. It’s what happens when you keep adding without ever subtracting.
I’ve seen this pattern repeat across every product I’ve worked on. The first stakeholder meeting generates ideas. The second meeting generates more ideas. By the third meeting, you’ve got a roadmap that would take two years to build and a feature set that would take users three months to learn.
On one project, we started with a dashboard concept. Clean. Three core metrics. One primary action. Then sales wanted to track their pipeline. Customer success wanted support ticket trends. Product wanted feature adoption data. Operations wanted system health monitoring.
Four months later, we had nineteen different widgets, eight filter combinations, and three different chart types. The product team loved it. “Look at all this flexibility users have!”
The support team told a different story. Every onboarding call was forty-five minutes of explaining what everything did. Where to find things. What each filter meant. Which chart to use when.
We’d built a monument to “just in case” thinking. Everyone got their widget. No one got clarity.
There’s a quote often attributed to Antoine de Saint-Exupéry:
“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”
It sounds poetic. It’s actually brutal in practice.
When we finally redesigned that dashboard, we cut fourteen widgets, six filters, and two chart types. The product team panicked. “What if someone needs that?”
Here’s what I learned: the edit isn’t cleanup. It’s not polish. It’s not the final ten percent. The edit is the actual craft.
Every article I write starts at around 3,500 words. I cut it to 2,000. Every wireframe starts with every possible state and interaction. I remove thirty percent before the first review. Every prototype includes features we know we’ll never build, just to see what happens when they’re not there.
Subtraction is where the real decisions happen.
On that dashboard redesign, here’s what we kept:
-
Five widgets (down from nineteen)
-
Two filter types (down from eight)
-
One chart style (down from three)
We made choices. Sales gets pipeline visibility, but not granular deal stage breakdowns. Customer success gets ticket volume trends, but not individual ticket details. Product gets feature adoption, but not user-level data.
Every decision had a reason. Every cut had a trade-off. That’s what made it clear.
The day we launched, support calls dropped by 60%. User satisfaction scores went up. Task completion rates improved. And here’s the part that surprised everyone: not one person asked for the missing features.
Not one.
If subtraction creates clarity, why is it so hard?
Because our brains are wired to avoid loss. Daniel Kahneman’s research on loss aversion shows that losing something feels roughly twice as painful as gaining something feels good. When you remove a feature, you feel the loss. When you add a feature, you feel the possibility.
Removal feels like failure. Like admitting you were wrong. Like wasting time and money on something that didn’t matter.
There’s also the sunk cost fallacy.
“We already built it. We already spent the time. We already committed to stakeholders. If we remove it now, all that work was for nothing.”
But here’s the truth: the work wasn’t for nothing. You learned what doesn’t work. That’s not waste. That’s progress.
I once had to defend removing a feature we’d spent 6 weeks building. The meeting lasted two hours. Engineers didn’t want to feel like their work didn’t matter. The product manager didn’t want to go back to stakeholders and explain the change. Leadership didn’t want to admit we’d bet on the wrong thing.
Everyone had a reason to keep it. No one wanted to face the emotional cost of letting it go.
I asked one question:
“If we were starting today, knowing what we know now, would we build this?”
Silence.
The answer was no. We all knew it. But admitting it meant accepting loss. So we’d rather keep something that didn’t work than face the discomfort of cutting it.
There’s also politics. Features have parents. Someone championed that idea. Someone got buy-in. Someone sold it to leadership. Cutting a feature feels like cutting that person’s idea. Like saying they were wrong.
In that same meeting, I watched team members defend features not because they believed in them, but because they’d been the ones to propose them. Ego gets attached. Identity gets wrapped up in decisions. The complexity becomes a monument to who suggested what.
Barry Schwartz wrote about the paradox of choice — how too many options create decision paralysis and decreased satisfaction. But the paradox doesn’t just affect users. It affects teams. More features mean more options. More options mean harder decisions. Harder decisions mean we avoid deciding. So we keep everything.
The hardest part of editing isn’t the cutting. It’s deciding what deserves to stay.
Here’s the framework I use:
-
Does this serve the core job? Every product has a primary reason to exist. A core job it does better than anything else. Does this feature support that job, or does it distract from it?
-
Does this create friction or reduce it? Friction isn’t always bad. Sometimes you want users to slow down and think. But most of the time, you want to reduce the distance between intent and action. Does this feature smooth the path or add steps?
-
Would we miss it if it disappeared? The thought experiment that matters most. If we removed this tomorrow, would anyone notice? Would anyone complain? Would anything break? If the answer is no, why are we keeping it?
We used to do an exercise with product teams called “if we could only ship three things.” Lock everyone in a room. No leaving until we agree on the three features that matter most. Everything else gets cut or deferred.
It’s uncomfortable. People fight for their ideas. But by the end, you have clarity. Not because you found the perfect three things, but because you were forced to choose.
On one project, we started with a backlog of 32 features. After three hours of debate, we had our three. Two months later, we shipped those three. The product worked. Users were happy. We never went back to build the other 29.
Not because we forgot. Because they didn’t matter.
The result of good editing is invisible.
When you use a product that’s been edited well, you don’t notice what’s missing. You notice what works. You don’t think about all the features that aren’t there. You think about how quickly you accomplished what you needed to do.
Dieter Rams said, “Good design is as little design as possible.” Not because minimalism is trendy. Because every element you add is a choice you’re asking the user to make. Every feature is a question. Every option is a decision point.
Clarity means fewer questions. Less explanation. Faster onboarding. Lower cognitive burden.
After we redesigned that dashboard, new users could complete their first task without a walkthrough. That was the goal. Not to make it beautiful. Not to make it flexible. To make it obvious.
The interesting part is what happened internally. Engineers spent less time on maintenance. Support spent less time on explanations. Product spent less time on edge case debates. We’d removed complexity from the user experience and accidentally removed it from our own workflows too.
Gloria Mark’s research on attention and cognitive costs shows that every interruption, every decision, every context switch has a cumulative toll. We think about users’ cognitive load, but we forget about our own. Complexity doesn’t just burden users. It burdens teams.
When I look at the hours I spent building versus the hours I spent removing, the ratio is embarrassing. Probably 3 hours of building for every hour of editing. But that one hour of editing is where the real value came from.
The builds got us to functional. The edits got us to clear.
Here’s what frustrates me about clarity: nobody sees the work.
When you add a feature, people notice. Leadership sees progress. Stakeholders see their requests implemented. Engineers see their code in production. It’s visible. It’s tangible. It’s rewarding.
When you remove a feature, nobody notices. The best outcome is silence. Users don’t miss what they never relied on. Teams don’t celebrate what’s gone. Leadership doesn’t reward subtraction.
But the impact is there. Faster load times. Simpler onboarding. Fewer support tickets. Better user satisfaction. It’s just invisible.
Most products fail not because they’re missing features. They fail because they include too many. Because every addition splits focus. Every option adds cognitive load. Every edge case complicates the core experience.
I worked with a team that had built a scheduling tool. The core job was simple: book a meeting. But over two years, they’d added timezone detection, calendar syncing, reminder customization, buffer time settings, meeting templates, availability rules, booking limits, and custom branding.
By the time I saw it, the average user took 8 clicks to book a single meeting. The product team was proud of how comprehensive it was. Users were exhausted by how much they had to configure.
We cut everything except the core path. Pick a time. Book it. Done. Three clicks.
The team resisted. “But what about power users who need advanced features?” What about them? We looked at the data. 94% percent of bookings used the default settings. 6% of users accounted for 90% percent of the customization requests.
We built for the 6% and made it harder for the 94%.
After we shipped the simplified version, usage went up. Not because we added anything. Because we removed the barriers between intent and action.
Complexity signals effort. It signals sophistication. It signals that you’ve thought of everything.
Clarity signals confidence. It signals that you know what matters and you’re willing to cut everything else.
Here’s what makes this hard: most careers reward addition, not subtraction.
Promotions come from shipping features. Bonuses come from hitting roadmap goals. Recognition comes from building new things. Nobody gets promoted for removing complexity.
If you’re the person who says “we shouldn’t build this,” you’re the obstacle. If you’re the person who says “let’s cut this,” you’re the critic. If you’re the person who questions whether something is necessary, you’re slowing things down.
That’s the tension. The system rewards complexity even though the outcome demands clarity.
I’ve been in reviews where I presented two options: build three new features or remove five old ones. Leadership picked the first option every time. Not because it was better. Because it felt like progress.
Subtraction doesn’t feel like progress. It feels like going backward.
But here’s what I’ve learned: the courage to say “no” or “not yet” is rarer and more valuable than the ability to say “yes.”
Anyone can add features. It takes no discipline. No judgment. No taste. You just keep building.
Editing requires conviction. You have to believe that less is actually more. That removing something will make the product better. That saying no is a service to users, not a disservice.
And you have to be willing to defend that choice when everyone else wants to keep adding.
Clarity isn’t a destination. It’s a practice.
Every new feature tempts complexity. Every stakeholder request tests your discipline. Every “what if” scenario threatens to pull you back toward “just in case” thinking.
The question isn’t whether you’ll face pressure to add more. The question is whether you’ll have the systems in place to resist.
-
Some teams do quarterly audits. What can we remove this quarter? What have users stopped using? What’s creating more support burden than value?
-
Some teams have a rule: for every new feature added, an old one must be deprecated. It forces prioritization. It prevents accumulation.
-
Some teams just have one person whose job is to say no. To ask the hard questions. To defend simplicity against the endless tide of addition.
I don’t have a perfect system. But I do have a principle: if you can’t explain why something should stay in 10 seconds — it should probably go.
Not every feature earns its place. Not every option deserves to exist. Not every edge case matters enough to complicate the core.
The edit is not cleanup. The edit is the craft. It’s where you decide what matters. It’s where you choose clarity over comprehensiveness. It’s where you admit that doing less, better, beats doing more, worse.
Simple is hard. That’s why it’s rare. That’s why it matters.