behavioral · standard
Tell me about a time you said no to a stakeholder
Tell me about a time you said no to a stakeholder.
This question is not about conflict. It tests three things simultaneously: whether your judgment about what matters is sound, whether you can hold a position under pressure without damaging the relationship, and whether you understand that “no” is almost never the end of the conversation. Interviewers at Meta, Netflix, and AI labs now flag clean STAR answers as rehearsed. They want stakes, tension, and an earned resolution.
Do not conflate this with “tell me about a difficult stakeholder.” That question scores on empathy and influence. This one scores on judgment: you made a call, defended it with data, and did not capitulate because someone senior pushed back. A story where you initially said no and then the stakeholder made a valid point that changed your mind is actually stronger than one where you simply “won.”
Structure a strong answer
strong
"We were six weeks from launching a redesigned onboarding flow when the head of sales flagged that a major enterprise prospect had asked for SSO as a condition of signing. His ask was to pause the onboarding work and ship SSO first, which would have pushed the launch by at least eight weeks. I took two days before responding. I pulled our activation data, which showed that 40% of free-to-paid conversions happened within the first week, and our model showed the delayed launch would cost roughly $180K in conversion revenue over the quarter. I also looked at the enterprise deal: it was worth $120K ARR. So even with the deal, we'd net negative on the quarter if we pivoted. I went back to the head of sales with that math and asked if we could commit SSO for Q3 while he set the expectation with the prospect. He pushed back (he was worried about losing the deal). So I proposed a middle path: we'd build a lightweight SSO stub in two weeks that satisfied the prospect's immediate concern, ship onboarding on schedule, and deliver full SSO in Q3. Engineering confirmed the stub was feasible. The prospect signed. We shipped onboarding on time. That said, I was wrong about one thing: I underestimated how much that one deal would unblock three more enterprise conversations the sales team had been warming. In hindsight I should have asked sales for their full pipeline view before doing the math, not just the deal in front of me. Now my default is to ask what's behind the request before I pull the data."
weak
"A senior stakeholder on the sales team kept asking us to add a custom reporting feature. I explained that it wasn't on the roadmap and that we had bigger priorities. They pushed back a few times but eventually understood. I think it's important to stand your ground when you know what's right for the product." This fails on every dimension: no data, no acknowledgment of the stakeholder's legitimate business need, no tension (they just "eventually understood"), no framework that made the decision defensible, no relationship outcome, and the closing line signals arrogance rather than judgment. The interviewer cannot tell whether this PM made the right call or was simply inflexible.
Why strong answers include being wrong
The follow-up interviewers use to break rehearsed stories: “What would you have done if the stakeholder had escalated?” or “Looking back, is there any chance you were wrong?” Most candidates freeze because their story was designed to show they were right. The strong answer above preempts this by volunteering the blind spot. Intellectual honesty about what you got wrong, paired with a durable behavior change, is what separates a story that sounds lived from one that sounds coached. Strong answers also give the stakeholder a legitimate point. If the opposing argument is a straw man, there was no real judgment call.
Amazon scores this differently
Amazon maps this question directly to two Leadership Principles: Have Backbone; Disagree and Commit, and Are Right, A Lot. A story that scores at Amazon needs to show you registered the disagreement explicitly (not just internally), documented it, and then executed fully if overruled. “Disagree and commit” is not a compromise. It means you said your piece clearly, lost the argument through proper channels, and then put your full effort behind the decision anyway. If your story ends with “they came around,” it does not demonstrate the LP. If it ends with “I was overruled and I shipped it anyway,” it does.
The 2026 reframe
In an AI product environment, a “no” based on engineering complexity sounds out of touch. Most features are now technically feasible in weeks. The only defensible “no” rests on viability (the unit economics don’t support it, the market segment is too small to recover the cost, or the feature would cannibalize revenue without replacing it) or lovability (users don’t actually want the thing the stakeholder thinks they want, and you have behavioral data to prove it). The PM who defaults to “engineering says it’ll take six months” is scoring on the wrong axis. Name the specific RICE or ICE numbers. Name the revenue model impact. The stakeholder’s underlying interest was probably valid. Your job is to surface a path that serves it without building the wrong thing.
Follow-ups to anticipate
- “What if the stakeholder had gone over your head?” Have an answer that shows you would have escalated the data, not the argument.
- “How did that relationship end up?” The answer must show the relationship survived or improved. “I won the argument” is not a passing answer at senior level.
- “Would you do anything differently?” This is an invitation, not a trap. Use it.