Working with Engineers

You will spend most of your time working with engineers. Your actual job is to translate an abstract problem into a concrete product definition, then partner with engineers who own the solution space to build it as close as possible to your vision. This collaboration is where many product managers fail — because they don’t understand the engineers’ mindset or communicate effectively.

Engineers think differently. They solve technical puzzles and optimize for the smartest, most maintainable solution. You think about the user problem and business impact. You are in the problem space; they are in the solution space. Your job is to bridge that gap.

Engineers and PMs live in different thought worlds

Engineers have a distinct way of working: they want clarity on scope, stability in requirements, and respect for their technical judgment. But they also expect you to understand the problem deeply. If you say, “Build this feature exactly this way,” without explaining the why, they push back. They might say, “This is not the smartest way. We can do better, but it will take more time.” That conflict is natural.

The trap is expecting engineers to blindly execute your wish list. Instead, you must explain the logic behind your requirements — the user insights, data, and business rationale. When engineers understand the reasoning, they become very accepting and rational collaborators.

For example, if you insist on a one-week timeline, don’t just say “Because I said so.” Share the data: “We need this to launch before a major event on March 15. If we delay, we lose 10% of our expected revenue.” That context helps engineers prioritize and negotiate trade-offs.

Who does a product manager work with?

Your main collaborators are engineers, designers, and business stakeholders. Of these, engineers consume most of your time.

With business stakeholders, your commitment is about timelines and ensuring the product justifies their requirements. Designers are partners in crafting user experiences. But engineers are the builders — the ones who turn your abstract vision into reality.

Clarify outcomes, not implementation details

A common misconception is that you should not give engineers too many details and let them decide how to build. That is partially true — but you cannot be vague either.

The key is to define the desired outcome clearly, not the means. For example, a Salesforce product manager once told an engineer: “When an account updates, send the owner an email.” The engineer implemented it literally. The first email the owner got said: “TRUE.”

That’s because the PM specified what to do but not the intended result.

Instead, say: “When account details change, notify the owner with a summary of changes and next steps. The goal is to keep them informed without flooding inboxes.” This guides engineers to design a usable solution.

Sometimes stakeholders ask for data in a specific format like CSV for manual analysis. Instead of demanding CSV, explain the question you want answered. Engineers might suggest automated dashboards or SQL queries that save hours of manual work.

Use the right communication channel for the situation

Engineers value asynchronous communication for general requests but expect quick responses when urgent.

Respecting this helps prevent frustration and builds trust.

Also, know who to contact for what:

Lead engineers without authority

You do not have a direct reporting line over engineers. Leadership is influence, not command.

Leadership means:

• Taking ownership of the product outcome
• Showing self-discipline and follow-through
• Speaking up for your team’s needs
• Listening actively to concerns and ideas
• Making decisions confidently
• Being unpredictable enough to keep attention but consistent in your vision

Engineers respect PMs who explain “why” clearly and tie daily work to the product vision. Showing how their work impacts real users motivates the team.

Expose engineers to other teams and users. Cross-team interactions often spark creative ideas and build empathy.

The importance of transparency and flexibility

If you anticipate that requirements will change or that the roadmap will shift, communicate this openly. Engineers can then design flexible architectures or plan iterations accordingly.

Hiding changes only causes frustration later.

Example: How to explain a priority conflict

Imagine engineering says a feature will take two weeks but you need it in one.

Instead of insisting or conceding immediately, explain:

“This feature is critical because our competitor just launched it and we risk losing customers. If you need more time, what can we reduce in scope or postpone to meet the deadline?”

This invites collaboration and trade-offs, rather than conflict.

Field Exercise: Practice your engineering collaboration

Test yourself: Handling an engineering pushback

Influence without authority is your daily work

You will not have a formal reporting line over engineers. Your power is your credibility, clarity, and ability to align incentives.

Influence builds over time through consistent delivery, respect for expertise, and transparent communication.

Where to go next

• If you want to deepen your stakeholder management skills: Understanding Stakeholders and Negotiation
• If you want to master writing clear product requirements: Writing Effective PRDs
• If you want to lead without authority across functions: Influence Without Authority
• If you want to practice prioritization with engineering constraints: Prioritization Frameworks