Too often, people debate new work in absolute terms. They describe how good an idea is. How exciting. How valuable it could be.

That framing is almost always unproductive.

You can’t be absolutist about prioritization. The question isn’t whether a piece of work is good. Many things are good. The question is whether it’s better than the other things you could be doing instead.

So stop asking, “Wouldn’t this feature be great?”

Start asking, “Is this more valuable than the work we’re doing right now?”

That’s a debate with a chance of being constructive. It forces trade-offs into the open. It makes priorities explicit. And it avoids the false conclusion that an idea was rejected because it was bad. Most ideas aren’t bad — they’re just not the best use of time right now.

For example, imagine your top priority is fixing a reliability issue that affects a small but meaningful percentage of users every day. Someone proposes a new feature that would genuinely delight people and probably generate positive press. It’s a good idea. But if it delays the fix, it’s still the wrong one.

The same dynamic shows up in infrastructure work. A team might want to build a new product surface because it’s visible and exciting. Meanwhile, there’s backend work that would cut cycle time in half for every future project. Both are valuable. But only one compounds. Relative prioritization makes that trade-off explicit.

This kind of thinking is hard. Sometimes the right move after finishing the #1 item on your list isn’t to start #2 — it’s to go back and redo #1. Priorities shift as you learn, and pretending they’re fixed is how you accumulate wasted effort.

There’s a useful side effect to this framing. People walk away with a better understanding of what is higher priority and why, rather than feeling like their idea was dismissed.

It isn’t hard to say no to bad ideas. The real work is saying no to good ideas that aren’t the best ones.