In partnership with
Anyone can say no to a bad idea. The hard part is saying no to a good one.
Prioritization and focus are often talked about, but most of that advice is about saying yes to the right things. We don't talk as much about the other half: saying no to the wrong ones. And the wrong ones aren't even the hard part. That's what separates "we have a lot of priorities" from "we have a strategy."
I learned that the hard way when we kept getting integration requests at my last company. A customer needed their data in a specific system, a partner wanted a slightly different format, and sales could close the deal if we just built this one thing. Each request was reasonable on its own, and each one felt like a yes.
But saying no meant disappointing people we wanted to help. It meant watching deals slip or telling a partner they had to wait, and it didn't feel like strategy. It felt like holding the line. I'll be honest: if this problem showed up today, AI would make the one-off builds so much easier that the pressure to say yes would be even higher. But the decision would still be the same. We weren't choosing between "custom integrations" and "nothing." We were choosing between fast yeses that scale your pain and a slower yes that scales your impact. Saying no to good ideas was how we chose the system over the request.
That pattern shows up everywhere. When I think about it, I start with a reframe: no isn't rejection, it's protection.
A thank you from this week’s sponsor:
Speak fuller prompts. Get better answers.
Stop losing nuance when you type prompts. Wispr Flow captures your spoken reasoning, removes filler, and formats it into a clear prompt that keeps examples, constraints, and tone intact. Drop that prompt into your AI tool and get fewer follow-up prompts and cleaner results. Works across your apps on Mac, Windows, and iPhone. Try Wispr Flow for AI to upgrade your inputs and save time.
When we talk about saying no, we're usually talking about bad ideas: the wrong project, the wrong hire, the wrong technical direction. Good ideas are another story. Your team has them, other teams have them, and stakeholders have them. If you say yes to all of them, you end up with diluted focus, a tired team, and a bunch of things that are 80% done.
With the integrations, every yes would have been one more custom build; we'd have looked busy and we wouldn't have had a system. The system was "just do what's asked." When you learn to turn down a good idea, you're replacing judgment with protecting what you've already said yes to: namely your team's capacity and the quality of what's already on the board. No is how you hold the line for the things that matter most.
That said, sometimes you should pivot. You set a path, you commit to it, and then new information shows up. Maybe the market shifted. Maybe you learned something that changes the picture. Maybe the "good idea" that landed on your desk isn't a distraction, but a signal that the plan you set might need to change.
The difference between "stay the course" and "adjust based on what we know now" isn't always obvious. If you default to no every time something doesn't fit the current plan, you can end up rigid, and that rigidity can be career-limiting or get you labeled as "not a team player." So before you shut something down, ask whether it's worth evaluating. Is this new information? Does it change the assumptions we had when we set the plan? If the answer might be yes, give it a real look. Decide whether it's a pivot, a "not now but revisit soon," or a no. Say no to what doesn't merit changing the plan, and yes (or "let's explore") to what does.
Sometimes you don't have a choice. The ask comes from your manager or someone above you, and the decision is made. When that happens, your job is still to make the tradeoff visible. "If we do this, we're slipping X. I want to make sure that's the trade we're making." You may still have to pivot, but you're not pretending there's no cost. They own the trade, and you execute.
When it's not a pivot, I run through a few questions. I don't have a fancy matrix; I just use the same ones whenever someone brings me a good idea and we're already at capacity:
Does this move our stated priorities forward, or is it a side quest? If we haven't named it as a priority, adding it means something else gets less attention.
If we say yes, what are we explicitly not doing or deprioritizing? Making the tradeoff visible matters. Sometimes the answer is "we're not doing anything else, we're just adding this," but often it's not.
Do we actually have capacity, or are we already at the limit? "We're at the limit" is a valid answer. Just be prepared to defend it; you'll likely find yourself back at the tradeoff question.
The point is to make the cost of yes visible so that when you say no, it's a choice, not a reflex or a surprise.
Once you've decided, the next piece is how you say it. The worst version is "we're not doing that." No context, no path forward, no acknowledgment that the idea had merit. People walk away feeling shut down.
A better approach has four pieces:
Acknowledge it. "I like that" or "That could be valuable." Mean it.
Make it a prioritization call, not a quality call. "We're not ready to do it/we aren't moving forward with it as we're choosing X first." That keeps the door open and doesn't make them feel like they pitched something dumb.
Give a path if there is one. "Not this quarter. Let's capture it and revisit when we're past [milestone]." A backlog or "not now" list signals you're sequencing, not dismissing.
Stay clear. No over-explaining or apologizing for having priorities.
What this can sound like in practice:
"I like that idea and I see why it matters. Right now we're committed to [X] for this quarter, and if we add this we'd have to slip something we've already promised. I don't want to drop it, though. Can we capture it and revisit once we're past [milestone]?"
If they push back, restate the tradeoff and put the decision on them: "If we add this, we're not doing X by [date]. Is that a trade you're willing to make?" You're not blocking. You're making the cost visible so they can own the call.
The trick is making sure "not now" doesn't become never. We all know the classic parenting line of "maybe later" as a way to shut down a conversation. If "we'll revisit later" always means "we'll never talk about this again," people stop believing it and they stop bringing you good ideas.
So whatever your version of "not now" is (a backlog, a doc, a quarterly "what do we want to pick up?"), use it and revisit it. When you close out a project or free up capacity, look at what you deferred and see if something is ready to surface. You don't have to say yes to everything, but you do have to show that "not now" sometimes becomes "now."
Most leaders don't fail because they make a bunch of bad calls. They fail because they accept too many good ones without pricing in the long-term cost. Every yes has a tax. Sometimes the tax is visible: your team is stretched, quality slips, deadlines move. Sometimes it's quiet: you're building a system that gets harder to change, or you're training people that "priority" means "everything."
It didn't always feel good in the moment when we were turning down those integration requests. We had to say no to people we liked and to deals that would have made the quarter easier. When the platform finally shipped, the next integration request took a fraction of the time it used to. We'd built the thing that made the yeses scalable. The discipline of the no is rarely satisfying in the moment. It's satisfying when you look back and see that you actually shipped what you said you would.