Saying No to Good Ideas for Great Products
There's a moment every programmer knows intimately—that split second when someone suggests a "small" feature that would be "really easy to add." Your ADHD brain lights up with possibilities, your INTP mind starts architecting elegant solutions, and your F-side wants to make everyone happy. It's like watching a beautiful sunset from Oregon Coast while simultaneously hearing storm warnings on radio.
I've been that programmer who said yes to everything. Who built features like driftwood collecting on beach—each piece beautiful on its own, but eventually creating a chaotic pile that obscures clean lines of shore. Today, I want to share what coast has taught me about art of subtraction, and why saying no might be most creative thing you ever do.
Let me paint you a picture. It's Tuesday morning, fog is lifting off Alsea Bay, and I'm in that perfect flow state where code seems to write itself. Then Slack pings: "Hey Ken, quick question—could we add a little toggle to let users change background color? Should be super simple, right?"
Here's what happens in my neurodivergent brain in space of 2.3 seconds:
And before my rational mind can intervene, I've typed: "Sure! Give me twenty minutes."
Three hours later, I've built a color picker, a theme preview system, added local storage persistence, and started sketching out user-customizable layouts. original "simple toggle" has become a feature hydra—cut off one requirement, and two more grow in its place.
Here's what I've learned from watching too many products drift away from their original purpose, like ships that lose sight of lighthouse: feature creep isn't just about adding code. It's about losing focus, and focus is most precious resource in any creative endeavor.
That "20-minute feature" becomes 3 hours of implementation, 2 hours of testing, 1 hour of documentation, and 45 minutes explaining to next developer why it exists.
Every new feature is a mental model your users have to learn, a decision they have to make, and complexity they have to navigate.
More features mean more surfaces for bugs to hide. Each addition creates new combinations, edge cases, and opportunities for things to break.
most insidious cost: losing sight of what your product actually does. Features become barnacles on hull of your original vision.
Learning to say no isn't about being difficult or uncreative. It's about being a curator of excellence. Think of it like beachcombing—you don't pick up every shell you see. You choose ones that truly belong in your collection.
Before saying yes to any feature request, I ask myself these questions:
If our app helps people focus, does this feature help them focus better, or does it add distraction?
Features that serve edge cases often create complexity for everyone else.
Sometimes best solution is making existing features work better, not adding new ones.
Every addition should mean something else gets simplified or removed.
Here's thing about my F-side—it struggles with disappointing people. But I've learned that saying no to a feature request doesn't mean saying no to person. It means saying yes to something bigger: integrity of what we're building together.
Instead of:
"No, that would be too complicated."
Try:
"I love that you're thinking about how to improve user experience! Let me share what I'm seeing: adding that feature would create complexity in areas X and Y, which might actually make main workflow harder for most users. What if we explored solving underlying need through [alternative approach]?"
Last year, I found myself maintaining a personal project that had grown from a simple note-taking app into something resembling a Swiss Army knife crossed with a Christmas tree. It had themes, plugins, multiple export formats, collaboration features, and a dashboard that looked like a NASA control center.
moment of truth came during a beach walk in Waldport. I was explaining app to Toni, and I realized I needed a flowchart just to describe how to add a simple note. That's when it hit me: I had built a monument to feature creep.
I spent three weeks removing code instead of adding it. Deleted entire modules. Simplified workflows. Removed options. And you know what happened? Usage went up. User satisfaction went up. My own stress levels went down. app finally did one thing really, really well instead of twenty things adequately.
Create a document for feature ideas that aren't immediate priorities. This honors suggestion while keeping focus on current goals.
Bonus for ADHD brains: This satisfies need to capture ideas without derailing current work.
For every new feature you add, remove or simplify an existing one. This keeps complexity constant while improving focus.
Never implement a feature same day it's requested. Sleep on it. Let initial excitement fade and see if it still feels essential.
Can you write a compelling user story for this feature? "As a [user], I want [feature] so that [benefit]." If benefit is weak, feature probably is too.
Minimalism in software isn't about having fewer features—it's about having right features. It's difference between a Swiss Army knife and a chef's knife. Both are tools, but one tries to do everything adequately while other does one thing exceptionally well.
Every morning when I walk beach in Waldport, I'm struck by how ocean's constant subtraction—waves pulling sand away, tide retreating—creates most beautiful landscapes. same principle applies to software.
Build It Now
These are your golden features—maximum value, minimum cost.
Avoid At All Costs
These will drain resources and add little value.
Plan Carefully
Worth doing, but needs dedicated time and resources.
Consider Later
Easy wins, but don't let them distract from bigger goals.
For those of us with ADHD brains, saying no to new ideas can feel like trying to hold back tide. Here are strategies that actually work with our neurodivergent wiring instead of against it:
Keep a dedicated place for feature ideas—a Notion page, GitHub issues, or even a physical notebook. This lets you honor idea without acting on it immediately.
Set a literal timer before implementing any "quick" feature. Use those minutes to document why this feature is important and what problem it solves.
Share your feature decisions with a trusted colleague or friend. Sometimes we need external perspective to see our blind spots.
There's a Japanese concept called "Ma"— pregnant pause, meaningful empty space, beauty of what's not there. In traditional Japanese gardens, it's not stones that make space beautiful; it's careful placement of emptiness between them.
same principle applies to software. features you don't build are just as important as ones you do. Every "no" to a mediocre idea creates space for an exceptional one. Every simplification makes remaining features shine brighter.
I've learned to find joy in art of subtraction. There's something deeply satisfying about removing a feature that seemed important but wasn't actually used. It's like clearing driftwood from a beautiful beach—suddenly you can see natural curves of shoreline again.
next time someone suggests a "quick feature," take a breath. Feel weight of that decision. Remember that saying no to one thing is saying yes to something else—cleaner code, focused purpose, delighted users who can actually understand what your software does.
After all, ocean doesn't try to be a lake, a river, and a swimming pool all at once. It's magnificent precisely because it knows what it is.
From our coast to yours,
Keep subtracting,
~ Ken
Written with sound of waves and discipline of tide pools
Part of Ken's Creative Coding Musings series
Oregon Coast AI • Where Innovation Meets Nature