In my work as product designer, I’ve found myself returning to the same question over and over: “How much is enough?” As engineers and creators, many of us (myself included) are drawn to elegant, perfect solutions. We love crafting scalable architectures, comprehensive feature sets that address every edge case, and code that makes other developers nod in appreciation.

But I’ve learned—sometimes painfully—that this pursuit of technical excellence comes with significant trade-offs.

Over time, I’ve had a front-row seat to projects that collapsed under the weight of their own ambition. I’ve been part of teams that spent months architecting the perfect system, only to discover upon launch that we’d solved the wrong problem, or worse—there was no problem to solve at all.

This reflection isn’t about embracing mediocrity or advocating for cutting corners but to explore the balance between technical excellence and market reality; experience that I carry into every project.

The Brutal Truth About Market Uncertainty

Here’s a cold, hard fact that too many technical teams refuse to internalize: your product may die tomorrow. Not because your code wasn’t elegant enough or your architecture wasn’t sufficiently scalable, but because:

• The market you thought existed doesn’t
• The problem you’re solving isn’t painful enough to motivate adoption
• Your solution, while technically impressive, doesn’t actually solve the core user need
• External factors beyond your control (economic shifts, competitor moves, regulatory changes) rendered your offering irrelevant

In the face of this uncertainty, over-engineering is more than inefficiency—it is an existential threat to your product’s viability. Every additional hour spent perfecting a feature that users may never see is an hour not spent validating whether you’re building the right thing in the first place.

How Bruce Lee Might Approach Product Development

Bruce Lee revolutionized martial arts with his philosophy of Jeet Kune Do, which emphasized practical effectiveness over stylistic adherence. “Absorb what is useful, discard what is not, add what is uniquely your own,” he famously advised. His approach wasn’t about showing off with flashy moves or perfect form—it was about doing exactly what was needed to achieve the objective, nothing more and nothing less.

This philosophy translates remarkably well to product development:

My father, who practiced martial arts, often pointed out that those who constantly demonstrate their techniques are often the least prepared for actual combat. True masters show restraint and quiet confidence—employing only what’s necessary, when necessary.

In software, this means:

• Building a minimal solution that addresses the core problem
• Validating with real users before expanding scope
• Refactoring only when the evidence shows it’s necessary
• Prioritizing market fit over technical perfection

Matching Technical Sophistication to Business Lifecycle

This is something I’ve been stewing on for a while; can technical sophistication simply be thought of as a function of your business’s current lifecycle stage? This is not to say you permanently lower your standards—but instead think more strategically about the deployment of your engineering resources.

In early stages, when still searching for product-market fit, embrace:

• Quick implementation
• Rapid iteration based on feedback
• Minimal sunk costs (if a pivot becomes necessary)
• Solving the immediate user need, even if not optimal at scale

As validation emerges and a product finds traction, progressively refactor and enhance your technical foundation. This refinement should happen in response to real market signals, not speculative planning.

The Refactoring Safety Net

The liberating truth about software development is that refactoring is always an option. Your initial implementation decisions aren’t permanent prison sentences—they’re starting points. This realization can free you from the paralysis that often comes with trying to design the “perfect” solution from day one.

When you accept that today’s quick solution can become tomorrow’s refactoring project (if and when the market justifies it), you gain tremendous agility. You can focus on solving immediate problems and gathering the data needed to make informed decisions about where additional technical investment makes sense.

Some questions to drive a shift in mindset:

• “Will this approach work for what we know we need today?” replaces “Will this approach work for every possible future scenario?”
• “Let’s build this simply and see if users care” replaces “Let’s build this robustly before showing users”
• “We can refactor if this gains traction” replaces “We need to build this right the first time”

The Courage to Do Less

Perhaps the most challenging part of all this is that it requires genuine courage. It’s easier in many ways to hide behind over-engineering—to justify lengthy development cycles with appeals to quality and scalability. It’s much harder to ship something that you know could be technically better, but that delivers the core value proposition quickly enough to test your assumptions.

This courage—to do just enough, to show restraint, to prioritize market validation over technical elegance—may be the most valuable trait I feel like I can cultivate as a product creator. Like the martial artist who doesn’t need to show off, the confident developer knows that true mastery lies not in doing everything possible, but in doing exactly what’s necessary.

The next time you find yourself debating how much to build, remember: the line between "not enough" and “too much” isn’t drawn by technical perfection—it’s drawn by the actual needs of the people you’re trying to serve. Build just enough to meet those needs effectively, and you’ll ship faster and build stuff that actually matters.