Tell me about a disagreement with the development team over scope
Model answer
Use the STAR structure.
Situation. Before a trade-show demo, I wanted a full onboarding flow in the next release. The developers said it was too large for the time left and feared quality problems.
Task. Reach a plan that served the business date without burning out the team or shipping something fragile.
Action. I stopped pushing the scope and asked the team to walk me through their concerns. I explained the business goal of the demo: show a smooth first-run experience. Together we split the flow, kept account creation and the first guided task, and moved the advanced steps to the following release. We agreed what "done" meant for the demo version, and I took on the communication with the marketing team.
Result. The slice was ready two days early, the demo went well, and the team trusted me to listen to estimates in later planning.
The lesson: share the goal, not just the feature, and let the team shape the solution.
Key points
- Listen to the team's concerns before defending the scope
- Explain the business goal behind the request
- Reduce scope together and agree on what done means
Likely follow-ups
- What would you have done if the team still could not deliver?
- How do you keep a good relationship after a disagreement?
Common mistakes
- Pushing scope by authority and ignoring the team's estimates
- Giving in with no discussion, so the business goal is lost