Behavioral Scenario #07
The PM Who Keeps Changing Scope
“Your PM has changed checkout feature requirements 3 times in 2 sprints. Your team is frustrated. You're the tech lead. What do you do? Focus: scope negotiation with PMs under delivery pressure.”
The Situation
You're the tech lead on a 4-person Android team building a new checkout flow. The PM has changed core requirements twice in the last two sprints, each time after significant implementation work was done — both times communicated verbally in standup without a written spec update. Two engineers have raised their frustration to you directly.
Context
- The PM is under pressure from a VP who keeps adjusting the product direction based on live user research
- Both scope changes were communicated verbally in standup — never reflected in written documentation
- The team has burned 1.5 sprint-equivalents of capacity on work that was subsequently discarded
- Two engineers have vented to you — the sentiment is nearing 'I don't trust this PM'
- Your EM is aware of the friction but has asked you to resolve it before escalating
The Question
“Tell me about a time you had a difficult working relationship with a cross-functional partner. How did you handle it?”
Response Options
One of these is the strongest response. The others reflect common approaches with real trade-offs.
I told my EM the situation had become untenable and asked them to escalate to the PM's manager.
I accepted the situation as part of the agile process and helped the team stay positive about it.
I set up a recurring 30-minute weekly sync with the PM and proposed a spec freeze practice: requirements locked 48 hours before sprint start, with any mid-sprint changes formally documented as scope adjustments with impact noted. I framed it as protecting the PM's credibility with leadership by making scope changes visible and attributed.
I documented all scope changes in a detailed timeline and sent it to the EM and PM as a formal record.
The Debrief
Why the Best Response Works
Answer C works because it solves the problem collaboratively rather than defensively. The spec freeze is specific and implementable, and framing it as protecting the PM's credibility with the VP removes the adversarial dynamic. The PM isn't the villain — they're also under pressure. The best solutions address both parties' incentives.
What to Avoid
The 'scope change timeline document' approach is a common mistake — it creates a paper trail but no structural fix, and the PM reads it as a complaint rather than a proposal. If you're going to document, use the documentation as context for a conversation, not as the conversation itself.
What the Interviewer Is Probing
The interviewer is testing cross-functional emotional intelligence. Can you drive a process change with a partner who has no obligation to comply? Can you frame a problem in terms of the other person's incentives? The best Staff engineers make it easy for cross-functional partners to do the right thing.
SOAR Structure
**Situation:** 4-person Android team, 3 scope changes in 2 sprints, 1.5 sprint-equivalents of capacity burned. **Obstacle:** PM under VP pressure; changes communicated verbally; team trust eroding. **Action:** 30-minute recurring sync proposed; spec freeze practice with change documentation and impact logging; framed as protecting PM's leadership credibility. **Result:** PM adopted the process; no verbal-only changes in the following quarter; team frustration resolved; sprint velocity stabilized.
The Learning Arc
"This taught me that the people who create the most friction are usually under the most pressure. Once I understood that the PM was getting whipsawed by VP feedback, the adversarial framing disappeared. The spec freeze worked because it protected both of us — I got stability, and the PM got a clear record to show the VP when changes happen. I now start every cross-functional conflict by asking: what pressure is the other person under that I'm not seeing?"
IC Level Calibration
Have a direct, private conversation with the PM about the pattern. Express the impact on the team. Ask for written spec updates going forward. Set a personal boundary around verbal-only changes.
Design a lightweight process fix (spec freeze + change documentation) that serves both the team's need for stability and the PM's need for flexibility. Frame it in terms of the PM's credibility, not the team's frustration. Make it easy for the PM to adopt.
Recognize this as a systemic product-engineering coordination failure, not a PM failure. Propose a cross-team working agreement for requirement changes that becomes standard across all product-engineering pairs at the company. Use this as a forcing function to clarify the company's change management norms.
Company Calibration
Airbnb
Collaboration + belonging: creating psychological safety across functions
Bloomberg
Interpersonal skills + adaptability + communication clarity
Googleyness: Collaborative problem-solving + intellectual humility
NYTimes
Cross-functional collaboration + pragmatic problem-solving
Want to pick your response and see the full analysis?
Practice This Scenario Interactively