Turn Objections Into Conditions
A reframe from Playing to Win that gets teams unstuck
A lot of product discussions are just people trying to find a polite way to kill a competing idea. Someone says “this won’t work,” someone else disagrees, and back to the start you go. People dig into positions. No matter the research, there’ll never be a definitive answer, discussions turn into arguments about who’s right rather than what’s the right thing to do.
What would have to be true?
In Playing to Win, Lafley and Martin suggest a reframe: instead of debating whether an option will succeed, ask “what would have to be true for this option to succeed?”
Logically, “this fails if churn exceeds 3%” and “this succeeds if churn stays under 3%” are the same insight. But in practice, they’re different. Threats narrow focus. When someone attacks your idea, your brain shifts toward defence, and you quickly try to find counterarguments, not solutions. Success framing helps you go around that reaction. It can help people think constructively, figuring out how something could work rather than why it won’t.
Say your team is debating whether to move from one-time purchases to a subscription model. The sceptic says “churn will kill us.” That’s a verdict that shuts things down. But if you ask what would have to be true, the same objection becomes a starting point: “We would have to keep monthly churn under 3%. We can only do that by...” Now you have something to explore. Instead of an endless debate about whether 3% is realistic, the team is designing a way to measure early retention signals. The conversation moves from theology to testing: concrete experiments with decision deadlines.
The same pattern works for non-numeric questions. Say someone objects to a major re-architecture: “The team doesn’t have the skills for this.” As a verdict, that’s a dead end. As a condition, it becomes: “We’d need two engineers with distributed systems experience, or a six-week ramp-up for the current team.” Now you’re comparing hiring timelines against learning curves and posing a real trade-off you can evaluate.
The reframe doesn’t remove negativity. You can still be sceptical. But you have to express your scepticism as a positive condition to be explored, not a conclusion to be accepted. Listing the condition is just the starting point. The real work is figuring out how to make it true.
Everyone explores every option
The key mechanic is that everyone has to apply this to all the options, not just their favourite. If you prefer option B, you still have to genuinely explore what would make option A succeed. And the person who prefers A has to do the same for B.
This does more than prevent camps. When sceptics have to solve for an option instead of just poking holes, they often surface solutions the advocates missed.
Of course, this doesn’t eliminate politics. Someone can still list impossible conditions to sabotage an option they hate, like “we’d need 100% market share” or “the CEO would have to personally approve every release.”
But it makes bad faith more visible. When everyone has to do this for every option, listing miracles for one and easy answers makes insincerity obvious. If someone lists a miracle condition, don’t argue with them. Ask them “what would have to be true for that to happen?” Force the logic all the way down until the absurdity is undeniable or until it turns out to be a real constraint worth addressing.
The framework surfaces the problem. It doesn’t fix it. That still requires someone in the room willing to call it out, and in a political environment, that’s the hard part.
When it doesn’t help
This reframe works best when conditions are things you can influence. It’s less useful when the key conditions are external, like regulatory changes, macroeconomic shifts, or competitor moves you can’t predict. You can still list what would have to be true, but if the answer is “the regulations would have to change” you haven’t gained much.
It also struggles in strongly hierarchical organisations. It assumes a baseline of psychological safety, an organisation where people are willing to state real conditions honestly. In teams where opposing ideas are shut down, you’ll get safe conditions instead of true ones, and it’s probably best to skip the whole thing.
Comparing options after exploration
By the time you’ve properly explored how to make each option succeed, you’ll often have better versions of the original ideas. The sceptics found ways to address their own concerns. The advocates spotted weaknesses they’d glossed over. The options have been stress-tested and improved.
Now you can compare. Which conditions are already true? Which can you test quickly? Which require leaps of faith you can’t verify? The winner is often the option where the untrue conditions are easiest to de-risk, not the one with the fewest conditions or the most enthusiastic advocates.
Most product debates loop because they’re structured as arguments in which someone’s idea has to lose for someone else’s to win. This reframe changes the game. Instead of finding polite ways to kill each other’s ideas, the team works together to find what would make each option viable. The debate becomes conditional exploration.
It won’t always get you to consensus, but it might create some clarity.
