Skip to main content

The Art of Saying No to Features (Without Burning Bridges)

1 min read
career reflection meta

The default

Most engineers default to “yes.” It’s easier. It avoids conflict. But it also fragments the product and burns out the team.

A better framework

When asked for a new feature, ask:

  1. What problem does this solve? (Not what feature, what problem.)
  2. Who has this problem? (One user or 1000?)
  3. What’s the workaround? (If there’s a reasonable one, start there.)
  4. How would we know it worked? (Define success before building.)

Saying no constructively

Instead of: "No, we can't build that."
Try: "I understand the problem. Here's what we'd have to stop building
     to make room. Could we try a simpler version first?"

What I learned

The goal isn’t to say no more often. It’s to say yes to the right things. Every feature has an opportunity cost. Make it explicit before you commit.