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

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.