Tell me a time when you when you influenced engineering to build a particular feature

In the complex dance between product and engineering teams, the ability to successfully influence the development of a particular feature can make or break your effectiveness as a product manager. Throughout my career leading product teams across multiple industries, I've learned that this influence isn't about authority or mandate—it's about partnership, evidence, and strategic communication.

The Anatomy of Engineering Influence

Influencing engineering isn't a single skill but rather a constellation of capabilities that effective product managers develop over time. At its core, this influence stems from establishing trust, demonstrating value, and aligning incentives across organizational boundaries.

Let me share a particularly illuminating experience from my time at a mid-sized SaaS company where I led the product team for our customer engagement platform.

The Feature That Almost Wasn't

Our analytics had revealed a troubling pattern: while initial user adoption was strong, engagement dropped significantly after the first month. Exit surveys pointed to a specific pain point—users couldn't easily track the outcomes of their engagement campaigns without manual data compilation.

The solution seemed clear: we needed an integrated campaign performance dashboard that would automatically aggregate results across channels. However, our engineering team was deep into a major infrastructure migration, and adding this feature to their roadmap seemed nearly impossible.

This is where the real work of influence began—not with a demand, but with a journey of collaborative problem-solving that would ultimately transform both the product and our cross-functional relationships.

Building the Foundation for Influence

Before you can successfully advocate for a feature, you need to establish the groundwork that makes your voice credible and your requests reasonable. This foundation consists of several critical elements:

Establishing Technical Credibility

Engineers respect product managers who understand technical constraints and possibilities. While you don't need to code at their level, demonstrating technical literacy goes a long way.

In my case, I spent time understanding the architecture of our system and the challenges of the ongoing migration. I learned about the data models, API limitations, and performance considerations that would affect the dashboard implementation. This wasn't superficial knowledge—I needed to speak the language of our engineering team authentically.

When I finally approached our engineering lead, I could frame the dashboard not just as a product need but as a technical opportunity that aligned with their architectural goals. I specifically highlighted how the new data aggregation patterns required for the dashboard could serve as a prototype for similar functionality they were planning to build later.

Building Relationship Capital

Influence doesn't begin when you need something—it's built through consistent deposits in the "trust bank" long before you make a withdrawal.

For months before proposing the dashboard feature, I had been:

1. Protecting engineering from unnecessary scope creep
2. Providing clear, detailed specifications that reduced back-and-forth
3. Publicly acknowledging engineering contributions in company meetings
4. Bringing coffee and sitting with engineers to understand their challenges

These seemingly small actions created a reservoir of goodwill that proved invaluable when I needed to ask for something significant.

Mastering the Art of Timing

When you approach engineering matters as much as how you approach them. I deliberately waited until after a major release milestone before bringing up the dashboard concept. The team had just successfully delivered a complex feature and morale was high—the perfect moment to introduce a new challenge that could build on their momentum.

The Influence Playbook: A Step-by-Step Approach

With the foundation established, I followed a systematic approach to influence the engineering team to build our campaign dashboard feature. This methodology has proven effective across multiple organizations and can be adapted to various product contexts.

1. Frame the Problem, Not the Solution

Engineers are natural problem-solvers. Rather than prescribing a specific implementation, I started by sharing the user problem in vivid detail.

I compiled:

• Anonymized user feedback quotes expressing frustration
• Session recordings showing users struggling with manual data compilation
• Quantitative data on the correlation between this pain point and churn

During a lunch-and-learn session, I presented these findings without immediately jumping to the dashboard solution. Instead, I invited engineering to help define the problem space.

Our lead engineer, Sarah, was particularly moved by a video of a marketing manager spending 45 minutes compiling data that should have taken seconds. "That's just wrong," she said. "We can do better than that."

By the end of that session, the engineering team was intellectually invested in solving the problem—not because I had convinced them, but because they had convinced themselves.

2. Co-create the Solution

Rather than arriving with a fully-baked specification, I organized a collaborative workshop with key engineers, designers, and data analysts. Using a structured ideation process, we explored multiple approaches to solving the campaign tracking problem.

The workshop yielded three potential solutions:

What emerged was a hybrid approach that none of us had initially envisioned—an API-first implementation that would enable both an immediate CSV export improvement and lay the groundwork for the full dashboard in a subsequent release.

This co-creation process meant that engineering had authorship of the solution, not just execution responsibility. Their fingerprints were on the design, creating a powerful sense of ownership.

3. Connect to Broader Strategic Goals

Individual features rarely succeed in prioritization discussions unless they connect to larger organizational objectives. I carefully positioned the dashboard initiative as supporting three strategic pillars:

1. Retention Improvement: Directly addressing our highest churn factor
2. Competitive Differentiation: Closing a gap with our primary competitor
3. Technical Modernization: Implementing new data patterns aligned with the migration

During our quarterly planning meeting, I presented the dashboard not as a standalone feature but as a strategic initiative that would move multiple company metrics. Our CTO, initially skeptical, became an advocate when he saw how the implementation approach would accelerate parts of the technical roadmap he cared about.

4. Quantify the Impact

Engineers, like most technical professionals, respond to data. I built a comprehensive business case that included:

• Projected retention improvement (3.5% reduction in monthly churn)
• Customer acquisition impact (15% increase in conversion from trial to paid)
• Revenue impact ($450K additional ARR in the first year)
• Time savings for users (estimated 5 hours per user per month)

I worked with our data science team to validate these projections, making them credible rather than aspirational. When presented with this analysis, our engineering leadership could see that the dashboard wasn't just a "nice-to-have" but a significant business driver.

5. Address Resource Constraints Proactively

The most common objection to new feature requests is resource constraints. Rather than waiting for this objection, I proactively addressed it by:

1. Identifying lower-priority items that could be delayed
2. Suggesting a phased implementation approach
3. Offering to secure temporary resources from another team
4. Proposing to simplify certain aspects of another planned feature

By acknowledging the zero-sum reality of engineering capacity and offering concrete solutions, I demonstrated that I understood their constraints and respected their challenges.

Overcoming Resistance: When Influence Meets Obstacles

Despite thorough preparation, my dashboard proposal hit significant resistance. Our engineering manager, Alex, was concerned about the timeline impact on the infrastructure migration. Two senior engineers were skeptical about the data architecture implications. These obstacles required targeted approaches.

Technical Objections: Collaborate, Don't Capitulate

When faced with technical pushback, many product managers either immediately back down or dig in their heels. Neither approach is effective.

Instead, I scheduled a dedicated technical deep dive with our data architect and the skeptical engineers. Rather than defending "my" solution, I positioned myself as seeking their expertise to refine the approach. This subtle reframing changed the dynamic from confrontation to collaboration.

During this session, one engineer identified a legitimate flaw in the proposed data aggregation method. Rather than becoming defensive, I thanked him and asked for his recommendation. His alternative approach actually improved the design and gave him a stake in its success.

Competing Priorities: Find the Win-Win

Alex's concern about timeline impact required a different strategy. I needed to find a way to make the dashboard and the migration mutually reinforcing rather than competing.

After several one-on-one conversations, we identified an opportunity: certain data structures needed for the dashboard could serve as a test case for the new architecture patterns being implemented in the migration. By sequencing the work carefully, the dashboard could actually de-risk aspects of the migration rather than delay it.

This realization transformed Alex from a blocker to a champion. At the next leadership meeting, he was the one who proposed including the dashboard in the quarterly roadmap.

Organizational Politics: Navigate with Emotional Intelligence

Not all resistance is technical or resource-based. Sometimes organizational politics play a role. In our case, the VP of Engineering had previously committed to completing the migration "without distractions."

Recognizing this political dimension, I arranged a private meeting with both the VP of Engineering and our Chief Customer Officer. Rather than putting the VP in a position where he had to publicly reverse his stance, I created a space where the CCO could emphasize the customer impact while I outlined how the dashboard could actually accelerate certain migration goals.

By giving the VP a face-saving way to support the dashboard while honoring his commitment to the migration, we overcame the final obstacle to approval.

Execution: Influence Doesn't End with Approval

Securing agreement to build the feature was only the beginning. Maintaining influence throughout the development process was equally crucial to ensure the final product delivered on its promise.

Staying Involved Without Micromanaging

I established a rhythm of brief, focused check-ins with the engineering team—not to control their work but to remove obstacles and provide clarification. These touchpoints were explicitly positioned as support opportunities rather than status updates.

When the team encountered an unexpected challenge with data latency, I was able to quickly convene user research sessions to determine acceptable performance parameters rather than letting the team make assumptions.

Adapting to New Information

Midway through development, we discovered that certain campaign types generated data volumes that would impact dashboard performance. Rather than rigidly insisting on the original specification, I worked with engineering to develop a tiered approach that optimized for the most common use cases while providing alternative views for edge cases.

This flexibility demonstrated respect for technical realities while preserving the core user value, strengthening the collaborative relationship with engineering.

Celebrating Engineering Contributions

As the dashboard took shape, I created multiple opportunities to showcase the engineering team's innovation. This included:

1. Demo sessions where engineers presented directly to executives
2. A customer advisory board meeting where they received direct user feedback
3. Recognition in company-wide communications

These visibility opportunities reinforced that I viewed them as partners in success, not just implementation resources.

The Launch and Beyond: Measuring Success Together

After twelve weeks of development (longer than our initial estimate but shorter than it would have been without the collaborative approach), we launched the campaign performance dashboard. The feature was an immediate success, with 78% of active users engaging with it in the first month and NPS scores improving by 12 points.

Shared Metrics for Shared Success

Rather than claiming this win for the product team, I established shared success metrics with engineering. We jointly tracked:

• Dashboard usage and engagement
• Performance and reliability metrics
• User feedback and satisfaction
• Business impact indicators

This shared accountability reinforced that we succeeded or failed together, strengthening our partnership for future initiatives.

The Compound Interest of Influence

The most valuable outcome wasn't the dashboard itself—it was the transformation in how product and engineering collaborated. Our next feature prioritization discussion was markedly different, with engineers proactively suggesting user-centric improvements and product managers showing deeper appreciation for technical considerations.

This "influence compound interest" made each subsequent feature negotiation easier and more productive. Six months later, when I proposed an even more ambitious feature, the conversation started from a place of trust and shared purpose rather than skepticism.

Lessons for Aspiring Product Managers

As you prepare for product management roles and interviews, understanding how to influence engineering is a critical skill that separates great product managers from merely good ones. Here are the key lessons from my experience:

1. Technical Empathy is Non-Negotiable

You cannot effectively influence engineering without understanding their world. Invest time in learning technical concepts, appreciate the complexity of what you're asking for, and respect the tradeoffs engineers must make.

During interviews, be prepared to discuss how you've built technical credibility and worked effectively with engineering teams. Companies like Google, Amazon, and Facebook specifically evaluate candidates on their ability to collaborate with technical stakeholders.

2. Evidence Trumps Opinion

Engineers respond to data, not assertions. When advocating for a feature, bring quantitative and qualitative evidence that demonstrates its value. User research, analytics, competitive analysis, and business impact projections are your most powerful tools of persuasion.

Practice articulating the business case for features using concrete metrics and projections. This skill is frequently tested in product manager interviews through case questions about feature prioritization.

3. Relationship Building is a Daily Practice

The time to build influence with engineering is before you need it. Make deposits in the relationship bank consistently through support, recognition, and genuine curiosity about their work.

Be prepared to discuss your approach to cross-functional collaboration in interviews. Questions like "Tell me about a time when you had to influence without authority" are staples in product management interviews at companies like Microsoft, Airbnb, and LinkedIn.

4. Co-creation Beats Dictation

The most successful feature implementations come from genuine collaboration, not product dictation. Create spaces for engineers to contribute to problem definition and solution design, not just implementation.

In your interview preparation, develop stories that demonstrate how you've facilitated collaborative solution development. Tools like NextSprints' Product Manager Interview Questions can help you structure these narratives effectively.

5. Flexibility Preserves the Core

Be firm on the user outcomes but flexible on implementation details. Understand the difference between the "what" (user needs) and the "how" (technical implementation), and know when to stand firm versus when to adapt.

This balance of conviction and adaptability is often tested in product management interviews through questions about handling stakeholder disagreements or technical constraints.

Putting It Into Practice: Your Influence Roadmap

Developing your ability to influence engineering teams is a journey that requires deliberate practice. Here's a roadmap to build this critical skill:

For Aspiring Product Managers

1. Build technical literacy: Take basic programming courses, understand system design concepts, and learn about development methodologies. This foundation will help you speak engineers' language.

2. Practice data-driven argumentation: When proposing ideas, back them with evidence rather than opinion. This habit will serve you well in both interviews and on the job.

3. Develop your storytelling: Engineers need to understand the "why" behind features. Practice articulating user problems and business impacts in compelling ways.

4. Seek collaborative experiences: Even in non-product roles, find opportunities to work across functions and influence without authority. These experiences provide valuable interview stories.

5. Prepare specific examples: For interviews, develop detailed stories about times you've influenced technical decisions or collaborated effectively with technical teams. The NextSprints AI Resume Review can help you highlight these experiences effectively.

For New Product Managers

1. Map your engineering relationships: Identify key engineering stakeholders and invest in understanding their priorities, challenges, and working styles.

2. Start small: Build influence through smaller, lower-risk feature requests before tackling major initiatives.

3. Become a user advocate: Bring engineers closer to users through shared research sessions, customer meetings, and user feedback reviews.

4. Learn the technical landscape: Invest time in understanding your product's architecture, technical debt, and engineering roadmap.

5. Find engineering allies: Identify engineers who have strong user empathy and enlist them as partners in advocating for user-centered features.

The Multiplier Effect of Engineering Influence

The ability to successfully influence engineering to build features is more than a tactical skill—it's a strategic multiplier that enhances every aspect of product management. When you master this capability, you unlock:

1. Faster time-to-market for critical features
2. Higher quality implementations through true collaboration
3. More innovative solutions that leverage diverse perspectives
4. Stronger team morale across functional boundaries
5. Better business outcomes through aligned execution

In my case, the campaign dashboard not only delivered its promised business impact but also transformed how our product and engineering teams worked together. This transformation enabled us to accelerate our overall product velocity, ultimately contributing to the company's successful acquisition two years later.

As you prepare for product management roles through resources like NextSprints' company-specific interview preparation, remember that technical influence stories are among the most powerful examples you can share. They demonstrate your ability to navigate complex organizational dynamics, balance user needs with technical constraints, and deliver business impact through collaboration.

The next time you find yourself needing to influence engineering to build a particular feature, approach it not as a negotiation but as an opportunity to strengthen one of the most important partnerships in your product career. With the right foundation, evidence, and collaborative mindset, you can transform "no" into "let's figure out how" and deliver exceptional value to your users and business.