Partnering With Engineers

How to collaborate more effectively with engineering teams

Aug 05, 2025

The relationship between product managers and engineers has a significant influence on a product’s success. A product team’s ultimate output is code written by the engineers. We can’t guarantee great results by just assembling a team of skilled people. Even small misalignments can lead to people pulling in different directions, slowing down real progress. Therefore, a product manager’s ability to effectively collaborate with their engineers is critical. How they work with engineers impacts the consistency and cadence of the development. It can either unlock a team’s full potential or limit it. Great collaboration allows teams to operate with shared understanding, shared purpose, and shared goals. That’s how they increase the odds of building something truly great.

Why Empathizing With Engineers Matters

PMs must understand what different people need.

In strong product organizations, product teams serve the customers in ways that meet the needs of the business. The entire product team needs to understand how the things they build will increase value to customers (by solving a problem) and increase value for the business (by driving revenue, customer acquisition, etc.). Product managers (PMs) and engineers have distinct roles on a product team. PMs define what work needs to be done and why it matters. Engineers define how that work gets done. Effective PMs recognize that strong working relationships with engineers increase the likelihood of building a great product. They understand that it takes intentional effort to get different people (with different personalities and skillsets) to work together effectively.

PMs should be relentlessly curious about both the engineering work being done and the people who are doing that work. We can only discover what people need by deeply engaging with them. Product management work and engineering work are challenging in different ways. Engineers want PMs to understand the non-intuitive things that actually make engineering hard. PMs should regularly solicit feedback (in 1:1s, retrospectives, etc.) to get their engineering team’s perspective: What can they do better as a PM? What behaviors, processes, or tasks do engineers find frustrating? What recurring problems do engineers encounter during development? What technical issues or constraints are the most challenging? Etc. The more they can learn, the more effectively they can address their engineers’ needs and empower them to do their best work.

Learn what drives your engineering team. Learn what they love and what they hate. Then, serve those needs. Give your immediate attention and your fullest energy to serving their pain points.
— Clement Kao, Empathizing with Engineers

Where Do Product Managers Go Wrong

Dictating how engineering work should be done, instead of deferring to engineers.

Some PMs mistakenly assume that their job is controlling engineers, instead of empowering them. They believe that telling their engineers exactly what to do will lead to better results. So, they share the bare minimum context and pressure their engineers to work as fast as possible. This is often frustrating and draining for both sides. It undermines autonomy and erodes confidence. Sometimes, organizational culture is even designed to enforce this mindset. However, a culture of control only gives PMs the illusion of efficiency. In most cases, their teams are just producing bad outputs faster. The product value proposition is not actually increasing with every additional feature shipped.

Too often product managers exist to control engineers…You end up with a maze of half-baked features, and it’s just plain slow. PMs become the bottleneck and gatekeeper for all decisions, and engineers feel frustrated.
— James Hawkins, Co-CEO of PostHog

Effective PMs understand that engineers look to them for direction, not instruction. Engineers have the deepest understanding of what can be built. Each engineer has a useful perspective on the problem the team is trying to solve. While each one will have a different degree of interest and bandwidth, they still want to be involved in discussions that impact development work. When PMs only talk to engineers after the work has already been decided, engineering teams don’t have a chance to offer valuable input that could help shape the work. Therefore, partnering with engineers to solve problems is essential for building better products.

The most common complaint I hear from the engineers is that they are not included until it’s too late, and they are forced to deal with the consequences.
— Marty Cagan, Silicon Valley Product Group

Other common ways product managers create friction with engineers:

Refusing to make tradeoffs when on-time delivery is no longer feasible.
Committing to delivering something without consulting the engineers.
Asking for estimates and then demanding shorter, unrealistic timelines.
Expecting bug-free builds and thorough testing, despite rushing delivery.
Providing specifications that lack sufficient detail or have vague requirements.
Frequently changing the scope and requirements after work has already begun.
Asking for specific, complex functionality and then pulling the plug mid-way.

How To Collaborate More Effectively With Engineers

Acquire The Relevant Technical Knowledge

Become familiar with the core technical concepts related to your product development.

PM can’t precisely communicate with engineers and understand their perspectives without the right technical foundation. It’s hard to grasp the complexity of an engineering issue when you have a vague understanding of the relevant technical concepts. PMs don’t necessarily have to be technical experts, but they do need to understand the basic elements of engineering work. It is often useful to develop a robust, high-level understanding of what pieces come together to build an application. A strong technical foundation allows them to partner with engineers more effectively to determine the best way to accomplish the overall goals and objectives.

While technically knowledge is helpful, PMs still need to defer to the engineering team’s expertise. PMs who overestimate their technical proficiency often default to micromanaging. They assume that they know the best way to solve an engineering issue, even though their understanding may be incomplete or inaccurate. This is disastrous for the engineering team’s productivity and morale. The purpose of building up technical knowledge is to better empathize with engineers, not to tell them what to do. You are getting into the details to gain a richer perspective on what’s going on, so you can figure out what needs to happen—what actions you need to take to support, accelerate, or unblock engineering work.

Recognize The Engineering Challenges

Understand what specifically makes engineering work difficult in your product.

PMs must understand how the specific technologies used in their product (and their specific implementation) create certain capabilities and constraints. A seemingly simple change that may take a few hours in one product might take weeks in another. There may be pieces of the codebase that have multiple complex dependencies, interact with legacy systems, rely on “messy” code, etc. There may be deployment constraints that make releases, updates, and fixes especially complex and time-consuming in some scenarios. There may be recurring challenges due to unresolved tech debt. Regardless of the specific issue, for any work involving a “problem” area, engineers cannot reliably predict what changes are feasible and how long those changes will take to implement.

PMs need to understand the points of friction that can slow down development. They can’t properly evaluate engineering concerns, pushback, and trade-offs otherwise. Therefore, PMs must know what technologies (programming languages, infrastructure, systems, etc.) their product relies on and understand which specific parts of the product are challenging to work with. When they are aware of where challenges exist, they can have more nuanced discussions with engineers. This helps them in several ways, such as: determining what is worth doing now vs. later, recognizing which estimates are likely to be less reliable, understanding which tasks will likely require greater time, effort, and focus, identifying areas that will likely require rework/fixes, and so on.

Explain The Purpose

Provide clarity on why the work matters.

Engineers want to know the purpose of their tasks because they want to do meaningful work. They want to tackle something worthy of their time, energy, and deep thought. So, they need to know why the work matters, especially when they are working all day on a seemingly pointless section of code. Therefore, PMs must continuously help engineers connect the dots: Why does this piece of functionality matter? How does it relate to other things that we are building now or in the future? What impact does this have on our customer or our business? And so on. When the purpose resonates with engineers, they feel like they have a stake in what’s being built.

PMs can easily verify if engineers truly understand the purpose behind their work by asking them a simple question: Why are we building XYZ? If they don’t get a good answer, it means that the PM has not clarified the purpose. As a result, the engineers just don’t know or understand the overall motivation and rationale for building something. Therefore, it’s unlikely that they will be engaged and invested in their work because they don’t understand the importance of the why. They are not likely to build an amazing product operating this way. So, PMs must help their engineers put each project in the context of the broader product vision to give them a clear purpose.

Provide Clarity And Context

Give engineers the specific information necessary to make engineering decisions.

PMs need to ensure that their engineering team is best positioned to succeed. Highly competent engineers understand that solving critical customer and business problems is what makes their work valuable. Therefore, they are intensely curious about the customer’s and the business’s needs. They recognize that insight is necessary to determine the right thing to build and the right way to build it. Therefore, to make engineering decisions, they need context: Who are their users? What do they want to achieve? What is their specific problem? What is the proposed solution? Why will it be valuable to the users? And so on.

Engineers don’t have the bandwidth to gather and distill all the relevant information. Therefore, they rely on PMs to provide the context needed to determine what steps need to be taken and how to sequence those steps. They need PMs to clarify the product vision and product strategy: the vision is the shared goal, and the strategy is the plan to accomplish that goal. They also need PMs to provide key details relevant to specific engineering tasks. By providing timely context, they give the engineering team the information and insight necessary to plan and align engineering actions and decisions with broader goals. When PMs fail to provide the right context, engineers inevitably build the wrong thing and fail to meet the real customer and business needs.

Preserve Momentum And Focus

Minimize (or ideally avoid) changes to the initial scope and requirements.

PMs should make the development process as efficient as possible for the engineering team. While PMs certainly can’t optimize all the engineering work, there’s a lot they can do to make their engineers’ jobs easier. One of the primary ways they can do this is by insulating them from unplanned changes. When engineers get a set of requirements, they develop a certain plan of action. For example, we need to build XYZ, so we need to do steps A, B, C, and so on. The more clearly defined the initial requirements are, the more predictable the work will be. When PMs frequently change priorities and requirements mid-way, it’s hard for engineers to make progress.

Every time the team has to diverge from the initial requirements, they must alter their plan of action. Regardless of the size of the change, the time and effort involved are now different. These changes might be necessary because of accepted new stakeholder requests, issues with the initial requirements, or some change in the customer/business needs. Regardless of the specific reason, when engineers have to frequently jump between tasks, their momentum and focus are disrupted. It’s also incredibly frustrating for them. Therefore, PMs must defend the team against last-minute changes as much as possible. Even if a change is urgent and important, they must discuss it with their engineers first and notify stakeholders of the impact on the timeline before accepting it.

Conclusion

Strong working relationships between PMs and engineers are key to a product’s success.

Strong relationships between product managers and engineers are built on strong collaboration. Product managers are responsible for enabling their team to do their best work. When PMs operate with greater empathy for their engineers, they can make the right moves to align and empower their engineering teams. When engineers feel trusted, supported, and motivated, they are more likely to bring out their best thinking. When product managers and engineers work as true partners, decisions get sharper, priorities get clearer, and execution gets better. Investing in that relationship is how PMs transform their teams into high-performing product teams.

Priank’s Newsletter

Discussion about this post

Ready for more?