You Can’t Feature Blast Your Way to a Great Product
“I didn’t have time to write you a short letter, so I wrote you a long one instead.”
Something has been nagging me about how product teams are responding to AI coding breakthroughs.
AI-assisted development is here, but teams are euphoric about that without factoring in the second order effects. More development capacity doesn't reduce the need for filtering — it amplifies it. Teams are producing more and filtering less, at exactly the moment when filtering matters most. Just because something can be built doesn’t mean it should be built.
It’s not just that teams are shipping the wrong thing faster, it’s that this will make your product worse.
Feature Blasting
When the cost of building drops dramatically, the natural reaction is to build more. It’s enticing to say yes to everything we used to say no to. Clear the backlog. Ship the requests. Move fast. The result is what I'd call feature blasting — a high volume of output with insufficient signal about what's actually working.
This is like a TV remote with 100 buttons. It's capable of everything. It's also impossible to use.
Bloated features nobody uses don't just sit there quietly — they create user experience issues and build technical debt. Shipping the wrong thing makes your product worse.
Great Products Have Cohesion and Simplicity
Michelangelo described his sculpting process as removing everything that wasn't the statue.
This is what product sense actually looks like. It's not just knowing what to build. It's also knowing what not to build, what to cut, what to simplify, and how the pieces fit together into something coherent. Taste. Curation. Judgment. Revision.
When everyone can build fast, delivery stops being the differentiator. Discovery and validation matter more than ever.
At eBay, we used to warn against building the Winchester Mystery House — the nearby mansion whose owner kept adding rooms, staircases, and doors to nowhere for decades without a master plan. The result is an architectural curiosity, not a home with any logical plan. Products built by bolting on features without a coherent vision end up the same way: feature rich, yet useless.
Validation is Your Feedback Loop
The ability to produce more also magnifies the importance of evaluating features after they launch. Few teams do this consistently well, which means they are just delivery teams and not product teams. Evaluating success metrics and gathering customer feedback tells you whether your release met its goals. Most features don’t, which is exactly why you need to know.
Product development has three core activities:
Discovery: Understanding what problems are worth solving and how to solve them
Delivery: Building and launching the solution
Validation: Assessing whether the solution worked
Most teams treat validation as an afterthought. If that's you, fixing that is a high priority. Some good practices to build this habit:
Isolate one variable at a time to understand causation
Run bold experiments (high contrast) in responsible ways (e.g. starting with limited audiences)
Monitor trial and repeat usage after launch
Treat every result as a feedback loop: roll back, iterate, update your assumptions
Teams who do validation well will soon hit another ceiling. A/B tests need time to reach statistical significance. Customer feedback requires adoption cycles, interviews and synthesis. These constraints are real and structural. Once validation is a consistent practice, discovery becomes the highest-leverage investment. It raises the quality of what enters the pipeline before it ever reaches validation.
Product Sense Matters More than Ever
Validation tells you what's working. Discovery determines whether you're working on the right things.
Building better products requires focus at two levels. The first is strategic: having a clear vision of the longer-term experience you're building toward. This becomes your North Star that makes prioritization decisions clearer. Without it, every feature request looks equally valid.
The second is ongoing discovery to inform what actually gets built:
Customer interviews and research: Understanding customer needs before designing the solution
Thoughtful prioritization: Choosing fewer, high importance problems worth solving
Problem definition: Getting clear on what you're solving, why it matters and specific root causes
Building iteratively: Isolate core capabilities and test hypotheses one at a time for clearer signal
AI is also an asset in discovery, such as helping with synthesizing research and enabling rapid prototyping. The difference is that using AI to refine your direction before building is fundamentally different from building without a clear direction.
The Bottom Line
Customer focus, outcome orientation, and iterative validation have always been core fundamentals to build the best products. AI doesn't change that. It raises the consequences of skipping it.
The Twain quote at the top of this post captures the core tension: producing more is easier than producing better. It always has been. AI just makes the gap between the two harder to ignore.
Helping teams build better feedback loops — through clearer discovery, sharper validation, and stronger product judgment — is core to the work I do with product organizations. If this resonates, I'd be glad to connect.
