We’ve noticed a pattern in how we make product decisions when we’re tired or anxious: we add things.
Add a feature to hedge against a user complaint we imagine. Add an onboarding screen to prevent confusion we haven’t seen evidence of. Add a settings panel because what if someone wants to configure this?
The additions feel like progress. They’re not. They’re noise — decisions made in response to imagined problems rather than real ones.
The cost of imagined problems
Every feature you build for an imagined user is a feature a real user has to navigate. The onboarding screen that prevents no confusion still takes three seconds of every new user’s first experience. The settings panel that nobody opens still loads on every launch.
The products we admire most — the ones we actually use — are relentlessly edited. Not minimal for its own sake, but minimal because someone made hard calls about what mattered.
How we try to decide
We ask two questions before adding anything. First: do we have evidence this problem exists? Not a hypothesis, not a user story — actual evidence. A support email, a conversation, observed behavior.
Second: is this the simplest solution to that specific problem, or are we solving a general case that hasn’t appeared yet?
Most of the time, we wait. The problem either solves itself, turns out not to matter, or becomes clearer with time. Patience is underrated as a product tool.
What we say no to
We keep a list of things we’ve decided not to build. It’s longer than our feature roadmap. Some items will eventually move to the roadmap. Most won’t.
The list is one of the most valuable documents we have. It’s proof that we’ve thought about these things and made deliberate choices — not that we forgot them or didn’t care.