Working with Engineers

Most of your time as a product manager will be spent working with engineers. You will explain requirements, clarify doubts, and share the logic behind the product decisions you have made. Your engineers are tasked with turning your abstract ideas into concrete, functioning features. This relationship is critical — and often fraught with tension.

Engineers operate in the solution space. They take a fixed scope and figure out how to build it efficiently and correctly. You, as the product manager, operate in the problem space. You define what problem needs to be solved and why. This fundamental difference in perspective sets the stage for many conflicts.

You will often hear engineers say: "This is not the smartest way to build this," or "We can do this better, but it will take an extra week." They resist fixed deadlines or scope that don’t align with their technical judgment. This is normal.

Your actual job is to explain the reasoning and data behind your decisions clearly and early. If you remove assumptions and make your expectations explicit, engineers become far more accepting and rational.

The problem and solution spaces create natural tension

As a product manager, you crystallize a vague, abstract problem into a concrete product scope. Your engineers then translate that scope into code, design, and tests.

This is not a linear handoff. It is a dynamic conversation. Engineers will question your assumptions and propose alternatives. They will push back on timelines. They will optimize for technical elegance or reusability.

If you do not set expectations explicitly, you will find yourself in conflict repeatedly.

The trap is to assume that "the engineers just don’t get it." The truth is the opposite: engineers are highly rational and will accept constraints and trade-offs if you explain why they exist — backed by data and business context.

For example, if you say, "We need this feature in one week because the sales team has a demo with Razorpay," engineers can weigh that urgency against technical debt or quality concerns. Without that explanation, they assume arbitrary deadlines and resist.

Who does a PM work with?

You will typically collaborate with three groups:

• Engineers: The people who build the product. You spend most of your time here, clarifying requirements and resolving technical trade-offs.
• Designers: They craft the user experience and interface. You partner closely but designers usually have their own timelines and priorities.
• Business stakeholders: Sales, marketing, customer success, finance. You manage their expectations about what the product will do and when.

Among these, your relationship with engineers is the most intense and requires the most discipline.

The PM’s influence is not authority

You do not have formal authority over engineers. No one reports to you. Your power is influence.

This means you must:

• Build respect through your subject matter expertise.
• Communicate clearly and logically.
• Use data and customer evidence to back your decisions.
• Negotiate trade-offs rather than dictate solutions.

Because engineers do not report to you, trust is fragile. If you ignore their concerns or impose unreasonable deadlines, they will disengage or push back covertly.

The five buckets of PM skills that support working with engineers

Understanding how to work well with engineers requires mastery across multiple skill sets:

The engineering skills bucket helps you speak the language of engineers and understand their constraints. The influencing skills bucket helps you persuade them without authority.

Typical sources of conflict and how to address them

Conflict with engineers often arises from unmet or misunderstood expectations. Common scenarios include:

• Timeline disputes: Engineers say it will take longer than you budgeted.
• Scope changes: Engineers want to remove or change features for technical reasons.
• Quality trade-offs: Engineers push for more testing or refactoring; you want faster delivery.
• Resource constraints: Engineers are overloaded or lack necessary skills.

The solution is always the same: communicate early and clearly, explain the why, and negotiate trade-offs with data.

For example, if engineering says a feature will take two weeks instead of one, don’t react emotionally. Instead:

• Ask them to explain the blockers or technical challenges.
• Share the business impact of delay (e.g., losing a key customer demo).
• Explore options: Can scope be reduced? Can you accept some technical debt temporarily?
• Agree on a plan with explicit trade-offs.

The PM is the bridge between problem and solution

Your job is to translate customer problems into clear, actionable requirements that engineers can build. This means:

• Writing user stories or PRDs that explain the user problem, not just the feature.
• Prioritizing ruthlessly so engineers know what to build now versus later.
• Being available to clarify doubts and remove blockers.
• Respecting the engineers’ domain expertise and incorporating their feedback.

Remember: Engineers are your partners, not your adversaries. The best PMs build trust by listening and collaborating.

Managing expectations with engineers

Expectations about timelines, scope, and quality must be set explicitly.

If you say "We need feature X by Friday," engineers will hear "No negotiation." If instead you say, "We want feature X by Friday because sales needs it for a pitch. What can we realistically deliver by then?" you open a dialogue.

Expectations include:

• What is the minimum viable version of the feature?
• What are the quality standards?
• How will you measure success after launch?
• What are the dependencies or blockers?

Clear expectations prevent last-minute surprises and build credibility.

Indian context: engineering culture and PM relationships

In India’s startup ecosystem, many engineers have been trained in a delivery mindset where timelines are fixed and scope is negotiable. PMs who push deadlines without clear rationale often face resistance.

At companies like Razorpay, Flipkart, and Swiggy, PMs who succeed are those who:

• Understand the technical trade-offs engineers face.
• Use data to justify prioritization decisions.
• Build personal rapport with engineering leads.
• Avoid micromanagement and focus on outcomes.

The trap of “I am the boss” mentality

Talvinder has seen many new PMs fall into the trap of demanding immediate compliance from engineers because "I am the PM."

Here is the uncomfortable reality: You are not the boss. You have no reporting authority. Your team’s respect is earned through influence, clarity, and trust.

The deeper mistake is to assume that PM power comes from hierarchy rather than expertise.

How to build influence over engineers

• Know your product and users better than anyone else. Engineers respect PMs who understand the problem deeply.
• Speak their language. Learn enough technical detail to hold meaningful conversations.
• Be transparent about priorities and constraints. Engineers want to know the full picture.
• Involve engineers early in problem definition. They provide valuable input and feel ownership.
• Acknowledge their expertise and concerns. Build mutual respect.
• Celebrate wins together. Recognize engineering contributions publicly.

The logic behind your deadlines and requirements matters

When you tell engineers "We need this in one week," they ask: why?

If your answer is "Because the CEO said so," you lose credibility.

If your answer is "Because we have a sales demo with Razorpay next Friday, and this feature is critical for closing that deal," they understand the context and can help find ways to meet the deadline.

Always back your requests with data, business context, and customer impact.

When engineers propose alternatives: listen and evaluate

Engineers will often say: "We can do it better, but it will take more time."

This is a negotiation, not a rejection.

As a PM:

• Evaluate the proposed alternative carefully.
• Weigh the technical benefits against business urgency.
• Decide if the improved approach is worth the delay.
• Communicate your decision clearly, explaining trade-offs.

This builds trust and avoids resentment.

Common misunderstandings about the PM-engineer relationship

Collaboration is a continuous conversation

Working with engineers is not a one-time handoff. It is an ongoing dialogue through discovery, development, testing, and launch.

You will clarify requirements multiple times, adapt to technical constraints, and revise priorities as you learn more.

This dynamic requires patience, clarity, and mutual respect.

Summary: The actual job when working with engineers

• You translate customer problems into clear, actionable requirements.
• You set and communicate expectations explicitly.
• You back your decisions with data and business context.
• You listen to engineering input and negotiate trade-offs.
• You influence through expertise and trust, not authority.
• You maintain ongoing collaboration throughout the product lifecycle.

This is what week one looks like for most new PMs — and for most senior PMs, too.

Test yourself: Engineering conflict resolution

Where to go next

• If you want to master cross-functional collaboration: Stakeholder Management
• If you want to write clear requirements for engineers: User Stories and PRDs
• If you want to improve your influence skills: Influencing Without Authority
• If you want to understand Agile development deeply: Agile Product Development
• If you want to practice prioritization under constraints: Prioritization Frameworks