On Forgetting My Own Advice: The Strategic Value of Simplification

Last month, I found myself debugging a feature that no user had asked for.

I'd spent three days building an elegant notification system with customisable triggers, multiple channels, and a scheduling engine. It worked beautifully. It also added cognitive load to every user's first experience, required documentation nobody would read, and distracted from the core job my product was supposed to do brilliantly.

The irony? I'd written an entire analysis about exactly this trap—companies that add complexity because they can, not because they should. I'd studied Chapman's Lotus, Sony's Walkman, Apple's iPhone, Google's homepage. I knew the pattern. And I'd still walked straight into it.

The Seduction of Easy Creation

Here's what happened: AI development tools had collapsed my build cycle from weeks to hours. Ideas that would have died in my backlog were suddenly shippable by Tuesday. The friction that used to protect me from my own enthusiasm—the effort required to actually build something—had evaporated.

And so I built. Feature after feature. Each one defensible in isolation. Each one adding weight to a product that needed to stay light.

It took a user interview to wake me up. "I love the idea," she said, scrolling through my app, "but I'm not sure what I'm supposed to do first." That's when I remembered my own framework.

Simplification as Active Discipline

The companies I'd analysed—Lotus, Sony, Apple, Google—didn't simplify once at launch and move on. They fought for simplicity repeatedly, against constant pressure to add more.

• Chapman didn't just build a light car; he stripped weight from every subsequent Lotus, obsessively, even when it meant throwing away finished components
• Morita defended the Walkman's lack of recording against his own engineering team who wanted to "complete" the product
• Jobs killed products Apple had invested years in—products that worked—because they diluted focus
• Google's homepage stayed sparse while every advisor told them they were leaving money on the table

Simplicity isn't a design decision. It's an ongoing discipline. And in an agentic world where creation costs approach zero, this discipline matters more than ever.

The Framework That Saved Me

I went back to my own analysis and asked three questions:

1. The Core Job Test: Can a new user discover what my product does brilliantly in under 60 seconds?

My answer was no. I'd buried it.

2. The Remove Test: If I removed this feature tomorrow, who would actually notice?

For three features: nobody. They'd never been used.

3. The Trade-off Test: What am I making harder in order to make this possible?

Onboarding. First impressions. The thing that actually mattered.

I spent the next week removing code. The product got smaller. The user experience got better.

The Full Analysis

I've documented everything I learned—six case studies from Lotus to Slack, anti-patterns from BlackBerry and enterprise bloat, and the complete framework for evaluating simplification decisions.

Read the full Strategic Simplification analysis →

The analysis includes:

• Six pillars of strategic subtraction (Lotus, Walkman, iPhone, Google, Basecamp, Slack)
• Anti-patterns: BlackBerry's fall and the enterprise trap
• Voices of subtraction: Quotes and context from Dieter Rams, Jason Fried, Jony Ive
• The Chapman Test: A practical checklist for any simplification decision
• Interactive visualisations of the trade-offs each company made

---

The hardest part of building products isn't adding the right things. It's having the discipline to remove the wrong ones—especially when removing them is now the harder path.