Every product manager has heard leadership make promises in a real meeting. They tend to come in three kinds: promises about priorities, promises about dates, and promises about tech debt.
It's easy to laugh along and think leadership got it wrong. I used to. Now I see both sides.
Here is what goes wrong in how product managers usually react, what the job actually is in that moment, and the words to use for each of the three.
Two reactions that both miss
When leadership commits to something, product managers tend to go one of two ways.
Some accept everything. The new priority goes on top of the old ones, the date goes into the plan, and the risk goes unspoken until it turns up on its own.
Others dig in. They are sure leadership "just doesn't get it", so they argue against the promise itself.
Both misunderstand their job. The first hides the cost. The second fights the person instead of making the cost clear. Neither gives leadership what it needs to make a good call.
The job: make the hidden trade-offs clear
Leadership can't decide well without knowing what the commitment actually costs. Your job is to make the hidden trade-offs and risks clear enough for a real decision.
The rule that helps: be firm about the consequences, and be flexible about the options.
Every commitment has three parts that are easy to miss in the moment. It depends on assumptions. It displaces other work. And it carries a risk. When you name those three things plainly, the conversation moves from "yes or no" to "which cost are we willing to pay", and that is a conversation leadership can actually have.
For the related case where a request arrives as urgent and everything else has to wait, see /vault/how-to-push-back-on-urgent-requests.
What to say on priorities, dates and tech debt
Here's how that sounds for each of the three promises.
On priorities, don't argue about whether the new thing matters. Ask what it replaces: "We can take this on. What are we willing to delay to make room?" That makes the displaced work visible without refusing the request.
On dates, bring the people who know the delivery risk into the answer before the promise leaves the building: "Let's check delivery risk with engineering before we tell sales what they can realistically promise." The date may still stand. Now it stands on evidence.
On tech debt, turn an abstract worry into a cost leadership can compare: "This debt is already costing us [specific time, money or failures]. Let's compare the cost of leaving it with the value of the next feature." Fill the gap with real numbers from your own team. Tech debt only wins against a feature when both sit on the same scale.
Notice what each line does. None of them says no. Each one names an assumption, a piece of displaced work or a risk, and hands the decision back with the cost attached.
Make it a choice, not a surprise
Sometimes accepting the risk is the right business call. A deal may be worth a tight date. A feature may be worth carrying debt for another quarter. That is leadership's call to make.
What matters is that it gets made as a choice. A risk that was named, weighed and accepted is a decision. A risk nobody mentioned is a surprise, and surprises are what damage trust between product and leadership.
So the aim is not to win the argument. It is to make sure nobody is surprised later. Make it a choice, not a surprise.
Which of these three promises do you hear most, and how do you react to it?