A PM promises a date without asking you

"You find out in a customer meeting that your PM has committed to a delivery date you were never consulted on, and it is not achievable. What do you do?"

What the question is actually testing

Whether you separate the immediate problem from the recurring one. There is a date to handle and a process that produced it, and fixing only the first guarantees a repeat.
Whether you can be direct with a peer without escalating. Going to your manager first is the move that damages the relationship permanently, and going to the PM's manager is worse.
Whether you protect the customer relationship rather than winning the argument. The commitment has been made externally, and "that was never realistic" said in front of a customer costs the company more than the slip would.
Whether you distinguish "hard" from "impossible". Some dates are achievable at a cost worth paying, and reflexively declaring a date impossible is as much a failure as accepting it.

Structure: first move, information I would gather, line I would not cross.

The answer

First move: do not react in the room

"If I find out in the customer meeting, I say nothing in the meeting. Contradicting my PM in front of a customer costs the company more than any date does, and it is a thing you cannot take back. If the customer asks me directly whether it is achievable, the most I would say is that I want to check the sequencing and come back with specifics, which is honest and does not commit me either way."

That restraint is the first thing being scored, and it is genuinely hard in the moment.

Then: work out whether it is actually impossible

Before any conversation, an hour with the real numbers, because "impossible" and "hard" are different problems and I do not want to be wrong about which one this is.

WHAT I WOULD ESTABLISH

  The forecast, from cycle time rather than story points.
  For the last 15 to 20 comparable items: what does the
  distribution say about this scope? 60 percent confidence
  on what date, 90 percent on what date?

  What is genuinely fixed. A contractual deadline, a
  conference, a regulatory date and an aspiration are
  completely different, and the PM may know something I do
  not.

  What could move. Scope, people, quality bar, dependencies.
  If there are versions of this that hit the date, I want to
  know them before the conversation.

  What the customer actually needs. Frequently narrower than
  what was promised: "the API available" rather than "the
  full product", or a pilot rather than general availability.

The last one is the highest-value question and it is the one nobody asks. In a large share of these situations the customer's real requirement is a subset of what was promised, and the conversation becomes "here is what we can have on that date" rather than "we cannot make that date".

Then: the conversation with the PM, privately and quickly

Within a day, direct, and framed as a shared problem rather than an accusation.

"I want to talk about the date you gave [customer] on Tuesday. I'm not raising it to relitigate it, I'm raising it because I don't think we hit it and I'd rather we work out together what we tell them now than in six weeks.

Here's what I've got: based on the last eighteen comparable items, full scope is about 60 percent confidence on the 29th and 90 percent on the 12th. The date you gave is the 15th, so we'd be committing at roughly one time in four.

Three options I can see. Full scope on the 29th at 60 percent. The 15th with the bulk import and the admin UI cut, which is the core flow working end to end. Or the 15th at full scope with two engineers borrowed from platform, at about 70 percent, and I'd be honest that it slows their roadmap.

What I'd like to understand is what the date is anchored to, because if it's a hard external commitment then option two is where I'd go and I'd want to talk to the customer about what they actually need by then."

Four properties, each doing work:

It leads with the problem, not the process failure. The process conversation is coming and it is separate, and mixing them makes the immediate conversation defensive.

It brings evidence rather than an assertion. Percentile forecasting from actual cycle time is much harder to argue with than "the team thinks it's too tight", and it converts the discussion from opinion to arithmetic.

It offers options with costs, not a refusal. A flat "we can't" gives the PM nothing to work with and puts them in a corner they will fight out of.

It asks what the date is anchored to, because the answer changes everything and I may not know it.

Then, separately: the process conversation

A different conversation, a few days later, once the immediate thing has a plan.

"Separate from the date itself: I want us to agree how commitments get made, because I don't think either of us wants to be in this position again.

What I'd propose is that any external date commitment gets a sanity check from me first, and I'll commit to turning that around in a day so it's not a bottleneck. Not approval, just a check, so we're not committing to something at 25 percent confidence without knowing that's what we're doing.

And in return, I'll give you forecast ranges proactively rather than making you ask, so you have numbers to work with in the room."

The reciprocity is the part that makes it work. A request for a veto over the PM's commitments is a power move and will be resisted. A trade, where I get a check and they get faster forecasts, is a process both parties want.

And "a day, not approval" removes the objection that this slows them down, which is the real reason PMs commit without asking.

When to escalate, and how

ESCALATE IF
  the PM refuses to revisit the commitment, AND
  the date is genuinely unachievable at any acceptable cost

HOW
  Together, not around them. "I think we should take this to
  [manager] because we disagree and it affects a customer
  commitment" is a completely different act from going alone.

  And escalate the DECISION, not the person. The thing being
  escalated is "which of these three options do we take",
  not "my PM committed without asking me".

Going to my manager first, before talking to the PM, is the move that permanently damages the relationship, and it is what a lot of people do because it feels safer. The PM finds out, and every future commitment gets made without me on purpose.

The line I would not cross

"I wouldn't publicly undermine my PM, and I wouldn't quietly accept a date I don't believe in and let it slip. The second one is more tempting and it is worse: it looks like being a team player, it means the customer plans on something false for six weeks, and when it slips the cost lands on people downstream who could have planned differently."

Where this goes wrong

Reacting in the meeting. Costs the company the customer's confidence, and it cannot be undone.

Going to your manager first. The PM finds out, and the relationship does not recover. Every subsequent commitment is made deliberately without you.

Refusing rather than offering options. "We can't do that" gives the PM nothing and makes it a confrontation they have to win.

Arguing from feel rather than data. "The team thinks it's tight" is an opinion and loses to a commitment already made. A percentile forecast from cycle time is arithmetic.

Fixing the date and not the process. The most common failure. The immediate problem gets solved, everyone is relieved, and it happens again next quarter with a different customer.

Assuming bad faith. Most PMs who commit without asking do it under pressure in a room, not maliciously, and treating it as a character problem rather than a process gap makes the process conversation impossible.

Interviewer follow-ups

"What if the PM says the date is non-negotiable because it's already in a contract?" Then the conversation changes shape entirely and it becomes a scoping problem rather than a date problem. I would go to the customer conversation with what is achievable by that date and what is not, and I would want to be in that conversation rather than have it relayed, because the trade-offs are technical. And I would say explicitly that the failure was not the date, it was that a contractual commitment was made without a feasibility check, which makes the process conversation more urgent rather than less.

"The PM says you're being pessimistic and the team can do it if they push." I would ask what specifically changes, because "push harder" is not a plan. If the answer is overtime, I would say plainly what that costs: we have done it before, we delivered, and the two months afterwards were 30 percent slower with two people close to leaving. If the answer is a genuine scope reduction or a dependency being unblocked, that is a real plan and I would revise the forecast. Being willing to change my number when the inputs change is what makes the number credible.

"What if you're wrong and the team makes it?" Good, and I would say so rather than defending the forecast. A 60 percent confidence date means we hit it three times in five, so making it is the expected outcome sometimes. What I would not do is conclude the forecast was wrong, because a single outcome does not invalidate a distribution, and the alternative reasoning, that the team can always do it if pushed, is how the ratchet starts.

"How do you handle it if this is the third time?" Then the process conversation is the whole conversation and it needs a decision rather than an agreement. I would go to my manager, together with the PM if possible, and frame it as a working-agreement problem: three external commitments in six months made without a feasibility check, here is what each one cost, and I need a mechanism rather than another conversation. At that point I would also be honest with myself about whether my proposed mechanism was actually workable or whether I made it too burdensome for them to use.

"The customer is in the room and asks you directly whether the date is realistic." I would not lie and I would not contradict the commitment. Something like: "I want to check the sequencing before I give you a confident answer, and I'll come back to you this week with specifics." That is honest, it commits to a follow-up the customer will hold me to, and it does not undermine my PM in the room. Then I make sure that follow-up actually happens, quickly, because the customer now has a reason to expect it.

"What if your manager tells you to just make it work?" I would commit and make the risk explicit, in writing: we hit this about one time in four, so let us agree now what we drop and what we tell the customer if it slips. Then execute properly, because a recorded objection followed by half-hearted delivery is the worst of both. What I would not do is keep arguing after the decision is made, because that costs the credibility I will need for the next one.

Production evidence

Percentile forecasting from historical cycle time (Vacanti's Actionable Agile Metrics for Predictability, and Monte Carlo forecasting practice generally) is the basis for quoting a range with confidence levels rather than a single date, and it is what converts an estimate argument into arithmetic.

Research on planning fallacy (Kahneman and Tversky's original work, and Flyvbjerg's later work on reference-class forecasting) documents that estimates from imagined effort are systematically optimistic and that historical data from comparable work is substantially better, which is why cycle time beats story points here.

Camille Fournier's The Manager's Path covers the peer-relationship dynamics directly, including that escalating before talking to the peer is the move that damages the relationship irreparably.

Google's re:Work research on psychological safety is the counterweight to the escalation instinct: teams where peers raise problems directly outperform those where problems route upward, and the pattern established by the first escalation persists.

The DACI and RAPID decision frameworks are the vocabulary for the escalation, since what is being escalated is a decision with a named approver rather than a complaint about a person.

Interview delivery note

Open with the restraint, because it is the first thing being scored and it is genuinely hard: "If I find out in the customer meeting, I say nothing in the meeting. Contradicting my PM in front of a customer costs more than any date does and you can't take it back. If the customer asks me directly, the most I'd say is that I want to check the sequencing and come back with specifics this week."

Then the diagnosis before the conversation, with the evidence: "Then an hour with real numbers before I talk to anyone, because 'impossible' and 'hard' are different problems. Percentile forecasting from the last eighteen comparable items, not story points, because points measure imagined effort and cycle time measures what happened. And the question nobody asks: what does the customer actually need by that date, which is frequently narrower than what was promised."

Give the conversation shape, with options rather than refusal: "Then a private conversation within a day, framed as a shared problem. Full scope at 60 percent on the 29th, 90 percent on the 12th; or the 15th with two things cut, which is the core flow end to end; or the 15th with two borrowed engineers at 70 percent, and honest that it slows the team I'm borrowing from. And I'd ask what the date is anchored to, because a contract and a conference and an aspiration need different answers."

Separate the process conversation and make it reciprocal, which is the part most candidates miss: "Then, a few days later and separately, the process. And I'd make it a trade rather than a veto: I get a one-day sanity check on external date commitments, they get forecast ranges proactively so they have numbers in the room. A request for approval over their commitments is a power move and gets resisted; a trade is something both of us want."

Close on the two lines: "I wouldn't undermine my PM publicly. And I wouldn't quietly accept a date I don't believe in and let it slip, which is more tempting and worse, because it looks like being a team player and it means the customer plans on something false for six weeks."

The Staff & Team Lead Interview Reference