Tell me about a time you disagreed with a decision your product manager made.
answer
- name the decision and the stakes
- state their reasoning fairly first
- evidence you brought, not taste
- the channel, not the hallway
- outcome, and what you did with it
basics
~10 sTests whether you push back on the decision rather than the person. Name one real disagreement, show the evidence you brought, use the proper channel, and end with a decision that everybody owned.
how to answer
5 beats- the decision and why it matteredOne or two sentences: what was decided, by whom, and what was at risk if it was wrong. Keep setup plus stakes to roughly fifteen to twenty percent of your airtime; the commonest structural failure here is a two-minute preamble and a ten-second ending.
- their reasoning, stated fairlyGive the other side its best argument in their own terms, including the constraint you did not see at first. This single beat does more for your score than the rest of the story, because it proves you were disagreeing with a position rather than a caricature.
- how you made your case, and to whomThe bulk of the answer, around sixty percent. Say what evidence you gathered and how, what alternative you proposed with its cost attached, and which forum you raised it in. Name the reversibility judgement if you made one: cheap to undo means argue once and move on, expensive to undo justifies spending more.
- what was decided and what you did nextLand the decision explicitly, including a partial or a loss, then say what you personally did afterwards. Result and reflection together are about a quarter of the answer. If you can attach one number to the outcome, this is where it goes.
- what you took from itTwo sentences at most, about your own behaviour rather than about the decision being vindicated. The strongest version names something you now do earlier or differently when you feel a call is wrong.
your answer
4 story prompts- Pick a disagreement you raised yourself, ideally within the last two years, where you can name the evidence you brought.
- Choose a case where the other side had a defensible reason, and write that reason down in their words.
- Have one number, prototype or user observation ready, plus the forum you raised it in.
- This can be the same episode as your conflict-with-a-coworker answer, re-angled onto the decision itself.
draft and rehearse your own answer in a learn session
go deeper
Interviewers use this to probe conflict resolution and intellectual honesty at the same time. They want evidence that you raise concerns through the person who owns the decision instead of around them, that you argue from evidence rather than status or taste, and that you can be overruled without becoming a worse teammate. A strong answer also shows judgement about which disagreements are worth spending on.
On my first team I owned the results list on a rebuilt search page for an enterprise catalog product. There were fourteen of us and an eighteen-day window before a customer preview, and our product manager decided to cut saved searches from that release. I disagreed, but I started by asking why, and her reason was solid: two of our largest tenants had asked for the export flow first, and she had exactly one of me. Rather than argue taste, I spent an afternoon in the session tool. Out of 212 recorded search sessions I watched, 38 retyped the same query inside ten minutes, mostly people checking stock across sites. I wrote that up in four sentences on the ticket and asked for fifteen minutes with her and my tech lead. She still cut saved searches, which was a much bigger build than I had understood. But she took the underlying problem, and we shipped a recent-searches row instead, which took me a little over two days. Search-to-click on the results page went from 27 percent to 34 percent over the first month. What I took from it is that I had been ready to argue for my feature. What actually moved her was the number, and the fact that I brought it to her directly instead of grumbling about it in standup.
The signal is carried by the fairly-stated reason and by evidence the speaker gathered personally at a scope she owned. The partial win reads as more honest than a clean victory. It would downlevel if the session numbers were replaced with an opinion about what users obviously want.
A year later I was the front-end lead for that same search surface, and the disagreement was about rollout rather than scope. Our product manager wanted the redesigned results page turned on for every tenant on one day, because support wanted a single training push instead of a staggered one. That is a real reason, not a whim. My worry was that this was hard to undo. Once every admin has seen the new page, pulling it back is a public retreat, and our tenants configure their own facets, so I could not predict how the new ranking behaved across all of them. I asked for a pilot instead of asserting the point. We put the page in front of five tenants I picked to be awkward: two with enormous custom taxonomies, one still on an old browser build. The pilot settled it. Zero-result searches on the custom-taxonomy tenants came in at 18 percent against 6 percent on the default configuration, because a facet mapping had never been migrated. Nobody would have caught that in staging, and it would have hit roughly forty accounts at once. She agreed to a three-wave rollout and I owned the go criteria for each wave. Support still got their single training session, recorded a week earlier. The part I would keep is that I argued about reversibility, not about whether the design was good.
Feature-and-rollout scope, an alternative that produced evidence instead of an opinion, and an explicit reversibility argument. The named go criteria show ownership past the decision. It would downlevel if the pilot were something someone else ran and the speaker merely cited.
Scope is your own task or ticket. Show that you asked why before you asserted, that you raised it with the person who made the call, and that you could accept an answer once you understood the constraint behind it.
Feature scope. The bar is the mechanics: evidence you gathered yourself, a concrete alternative with its cost attached, and a decision that landed rather than drifted.
Team and roadmap scope. Show judgement about which disagreements are worth spending on, timing that gave the decision room to change, and a working relationship that was still productive afterwards.
Org scope. The interesting part is not the one call but what you changed about how these calls get made, and evidence that other people used it without you in the room.
saying these in an interview costs you the question
- Casting the product manager as someone who simply did not understand engineering
- Bringing only opinion where a number or a recorded user session was available
- Venting sideways to teammates instead of raising it with the person who owns the call
- A story where you were right and the account stops there
- Quietly building the version you preferred after the decision went the other way
- No decision at the end, just an argument you are still carrying
- What did the other person say when you first raised it?Answer with their actual reasoning, stated as strongly as they would state it. Interviewers use this probe to see whether you understood the constraint or only your own side. If you cannot reconstruct their argument, say so plainly and say what you would ask now, rather than inventing a weak version of it.
- What would you do differently if that came up again?Pick one specific change, usually about timing, channel or evidence, not a global confession. Something like raising it before the estimate was public, or bringing a two-day prototype instead of an argument. Avoid answering that you would push harder, which reads as unfinished rather than reflective.
- How did that working relationship look six months later?This probe tests for collateral damage. Give a concrete sign the relationship held, such as being asked into decisions earlier or shipping something together afterwards. If it did get worse, say what you learned about how you handled it, and do not use the answer to relitigate who was right.
## One story for every wording This prompt is the most reliable disagreement question in the loop, and it arrives in several wordings that all want the same answer: - *tell me about a time you disagreed with your manager* - *when did you push back on a product decision* - *describe a time you thought the roadmap was wrong* - and the softened *how do you handle it when you think a decision is a mistake* Prepare one story that survives all of them. ## What the interviewer is scoring Three things, roughly in this order. 1. **First**, whether you separate the decision from the person, which shows up in how you describe the other side. 2. **Second**, whether your pushback was evidence-shaped: a number, a support thread, a session recording, a prototype. 3. **Third**, whether the episode ended in a decision that people executed, rather than an argument that dissolved. A surprising number of candidates fail on the third, not the second. ## The weak version and the strong version - **The weak answer** sounds like this: the product manager wanted a feature that made no sense, I explained the engineering reality, and eventually we did it my way. Nothing there is checkable, the other side is a cartoon, and the win is asserted. - **The strong answer** sounds like this: the call was X, their reason was Y and it was a real constraint, I thought the cost was Z and here is how I found that out, I raised it in this forum, here is what was decided and what I did next. The second version is longer only in the middle section, which is exactly where your airtime should go. ## Evidence types, in rough order of persuasiveness - A behaviour you observed in real usage beats a metric, - a metric beats a cost estimate, - a cost estimate beats a principle, - and a principle beats taste. A **small prototype** often outperforms all of them, because it converts an argument into something the other person can look at. If your story rests on taste alone, either find a different story or be honest that the disagreement was about judgement and describe how you resolved it without data. ## Picking which battles to fight Strong candidates volunteer a filter without being asked. The most portable one is **reversibility**: - If the decision is cheap to undo, argue once, lose gracefully and move, because the cost of being wrong is a revert. - If it is expensive to undo, because it ships to customers, changes a contract, or trains users into a behaviour, spend real credibility on it. Naming that filter in the middle of the story is a quiet seniority signal and costs you one sentence. ## How the bar moves - **Early in a career** the interviewer mostly wants to know you will speak up at all and then work the decision that was made. - **Around the middle**, they want the mechanics: how you built the case and what alternative you offered. - **Higher up**, they want to see that you chose this fight deliberately and that the relationship and the roadmap were both intact afterwards. ## Endings that work - You changed the decision. - You changed part of the decision, which is the most common real outcome and the most credible. - The decision stood, you executed it fully, and you instrumented the assumption so the next version of the argument would have data. All three pass. Only one ending fails: nothing was decided, and you are still annoyed about it.