What stakeholder buy-in or support did you need?
How did you first learn about or encounter the resistance?
What steps did you take to understand the concerns behind the pushback?
How did you adapt your approach or communication style?
What data, evidence, or reasoning did you use to address objections?
Did you compromise, pivot, or hold firm? Why?
What was the final decision or outcome of the project?
How did stakeholder relationships evolve through this process?
What measurable impact did your handling of the situation create?
What would you do differently next time?
Sample Answer (Junior / New Grad) Situation: During my internship at a fintech startup, I proposed redesigning our onboarding flow based on user research I had conducted. The flow had a 40% drop-off rate, and my research showed users were confused by the KYC verification step. However, the product manager pushed back strongly, saying the current design was intentional and had been approved by compliance.
Task: As an intern, I needed to present my findings in a way that would be taken seriously without overstepping my position. My goal was to improve the user experience while respecting the existing constraints and the expertise of senior team members.
Action: I scheduled a meeting with the PM to better understand their concerns. I learned that previous design changes had created compliance issues, which explained their caution. I then worked with the compliance team directly to understand the actual requirements versus assumed constraints. I created three alternative designs that maintained all compliance elements but improved clarity through better copy and visual hierarchy. I presented these options to both teams together, framing it as a collaborative exploration rather than pushing my original idea.
Result: The PM appreciated my willingness to understand their perspective and do the additional research. We implemented one of the hybrid designs, which reduced drop-off by 18% within the first month. More importantly, I learned the value of understanding resistance as information rather than opposition, and this approach helped me build credibility with the team despite being an intern.
Sample Answer (Mid-Level) Situation: As a software engineer at a healthcare company, I proposed migrating our legacy patient data system to a modern cloud-based architecture. The migration would reduce infrastructure costs by $200K annually and improve system reliability. However, I faced strong resistance from the operations team, who were concerned about potential downtime and data security risks, and from senior engineers who had built the original system and felt the current setup was sufficient.
Task: I was responsible for driving this technical initiative and needed buy-in from both engineering leadership and operations to proceed. My challenge was to address legitimate concerns while making the case for modernization, especially given that I was relatively new to the company and the stakeholders had much longer tenure.
Action: Instead of pushing my proposal harder, I organized a series of working sessions with the skeptics. I asked operations to walk me through their biggest concerns and documented every potential risk they raised. I then created a detailed migration plan that included rollback procedures, a phased approach with minimal downtime, and enhanced security measures that actually exceeded our current standards. I also acknowledged the quality of the original system and framed the migration as building on that foundation rather than replacing something broken. I brought in case studies from similar healthcare companies and arranged a conversation with a peer company that had completed a similar migration.
Result: After three weeks of collaborative planning, we gained unanimous approval for a pilot migration of a non-critical system. The pilot succeeded with zero downtime, which built trust for the full migration. We completed the entire project over six months, reduced costs by $230K in the first year, and improved system uptime from 99.2% to 99.8%. The operations lead later told me that the collaborative approach transformed their view of engineering initiatives, and we established a new cross-functional planning process for major changes.
Sample Answer (Senior) Situation: As a senior product manager at an e-commerce company, I championed a major initiative to implement dynamic pricing based on real-time demand signals, competitor pricing, and inventory levels. This was a strategic priority that could increase margins by 3-5% annually, translating to $12M+ in additional revenue. However, I encountered fierce resistance from multiple directors: the sales team worried it would damage customer relationships, the brand team believed it contradicted our value-based positioning, and engineering leadership questioned whether we had the technical capability to implement it properly.
Task: My responsibility was not just to launch the feature, but to ensure it would be adopted and supported across the organization. I needed to transform a controversial proposal into a unified company initiative, which required addressing both rational concerns and emotional resistance to change.
Action: I stepped back and conducted a listening tour with each stakeholder group to understand the deeper concerns behind their resistance. I discovered that sales had lost a major account years ago due to perceived pricing inconsistencies, brand had never been included in pricing discussions and felt undervalued, and engineering had been burned by a previous failed pricing project. I restructured the initiative completely: I brought together a cross-functional working group that included skeptics as key decision-makers, not just consultants. We conducted a competitive analysis showing that our top competitors already used dynamic pricing successfully while maintaining brand value. I proposed a phased rollback strategy and created clear guardrails—prices would only adjust within a 15% band, and we'd exclude our premium product line initially. I also allocated budget for additional engineering resources and committed to a six-month pilot with clear success metrics agreed upon by all stakeholders.
Result: The working group approach transformed opponents into champions. We launched the pilot across 30% of our catalog, with the sales director actually presenting the results to the executive team. The pilot exceeded projections with a 4.2% margin increase and no measurable impact on customer satisfaction scores. We expanded to 80% of products within a year, generating $15M in incremental profit. More significantly, this collaborative approach became our template for other cross-functional initiatives. I learned that resistance often signals missing perspectives rather than wrong ideas, and the time invested in building genuine alignment creates much faster execution later.
Common Mistakes
- Framing resistance as obstruction -- Position pushback as valuable input rather than opposition to overcome
- Focusing only on your perspective -- Failing to genuinely understand and address stakeholder concerns
- Being defensive -- Taking pushback personally rather than professionally analyzing the feedback
- No measurable outcome -- Not quantifying how your approach to handling resistance led to concrete results
- Steamrolling ahead -- Showing that you pushed through resistance without adaptation or compromise
- Blaming others -- Making stakeholders sound unreasonable rather than showing empathy for their position
- Missing the learning -- Not reflecting on what the resistance taught you or how it improved the final outcome
- Vague actions -- Saying you "communicated better" without specific examples of what changed in your approach
Result: The working group approach transformed opponents into champions. We launched the pilot across 30% of our catalog, with the sales director actually presenting the results to the executive team. The pilot exceeded projections with a 4.2% margin increase and no measurable impact on customer satisfaction scores. We expanded to 80% of products within a year, generating $15M in incremental profit. More significantly, this collaborative approach became our template for other cross-functional initiatives. I learned that resistance often signals missing perspectives rather than wrong ideas, and the time invested in building genuine alignment creates much faster execution later.
Result: The revised proposal gained unanimous support from technical leadership and board approval. We successfully extracted three major services in the first year, which improved deployment frequency by 300% for those domains and reduced our largest incidents by 60%. The collaborative evaluation process identified risks that my original proposal had missed, likely preventing a failed migration. More importantly, this became a template for how we approach major technical decisions: bringing skeptics into the solution rather than treating resistance as something to overcome. The architecture evolution continues today and has enabled us to scale from 50M to 200M users. I learned that at staff+ levels, your job isn't to have the right answer—it's to orchestrate the process that finds the right answer.
I started by acknowledging that the pushback represented valid concerns and treating this as an open question rather than a foregone conclusion. I formed a tiger team of principal engineers and architects from different organizations—including several skeptics—to conduct a comprehensive evaluation over six weeks. We analyzed our specific scaling bottlenecks, created detailed cost models for different approaches, and interviewed 15 companies about their architecture journeys. We discovered that a pure microservices approach would actually be overengineering for our needs. Instead, we proposed a "macroservices" architecture: extracting 5-6 larger services from the monolith rather than dozens of microservices. This addressed our core scaling issues while minimizing operational complexity. I also established a 12-month timeline with clear checkpoints where we could pause or pivot. To address political concerns, I proposed a rotating leadership model where different VPs would own different phases, ensuring distributed ownership. I personally committed to embedding with the first team to execute the migration to ensure hands-on support.23:[