Product Management for Engineering Managers
Your best contribution might be outside of engineering

An Engineering Manager’s (EM) primary goal is to create an effective team. With that in mind, they will spend most of their time focusing on engineering work and how engineers work. However, that should not be all of it. A product engineering team works within a broader system, and an effective EM should also ensure this system is as effective as possible.
The motivation for it is simple. The context where an engineering team operates will significantly impact the results they can have. Therefore, understanding and acting on the broader system is a direct way for EMs to influence their team positively.
And the most critical area to look at is Product Management. Product thinking defines not only what an engineering team will work on but also how they will work, depending on how ideas are shaped and executed.
Like Two Peas in a Pod
The Product Manager (PM) and EM partnership is the most important in a cross-functional product engineering team. Product defines the what, and engineering defines the how. Both being in sync will mean the team will work on the right things in the right way, correct?
Correct. However, being aligned doesn’t always mean working effectively together. A successful partnership between PM and EM is about more than agreeing on what will be delivered. It is about creating an effective system, from idea to production, where work can be executed successfully, delivering customer value.
From an EM’s perspective, it means ensuring the product process helps the engineering team be effective. And that means that they work on the right things and do it in the right way.
Not Water and Oil
Unfortunately, it is common to see teams where both PM and EM are aligned and agree, but the team still suffers from ineffective collaboration. That is because everyone stays in their own lane too much. PMs feel uncomfortable asking “Why is this taking so long?” while EMs focus on executing what they are told.
A process where product hands over what to do and then have engineering execute it is what waterfall processes are, and moving people into the same team does not solve it by default. Collaboration means working together, not working side by side.
Since product development influences all work that is done by the team, this anti-pattern can lead to problems in many different ways. These are a few that I have seen:
In one team I have managed in the past, we had an independent product research cycle lasting multiple months, which would define how the team would solve a customer problem. As a result, designers and product managers spent a long time interviewing customers, defining design options, and getting feedback without consulting any engineers (or at least not consulting them often).
As expected, this resulted in ineffective product decisions across the board that didn’t consider the effort involved and the alternatives to designed solutions. It peaked in one particular project, where an engineer stopped a project kick-off meeting (that had gone through extensive customer research) after five minutes since the product proposal could not be done without a rewrite of our system.
In another team, engineering was executing well but often below expectations regarding how much they could achieve in a specific amount of time. As a result, while the team delivered work, it was underwhelming. After a while, it became clear that the common anti-pattern was that product and design decisions were often not ready (enough) when work had started, leading to constant cycles of questions and redesign while work was in progress.
While real-time collaboration between product, design, and engineering during execution is very healthy, work switching hands back and forth for extended periods is not. It usually means that part of the process needs to be fixed before the work reaches engineers.
In a third example, a team missed a critical deadline on a strategic project. While everyone worked diligently on what was assigned, there was a lack of shared understanding between product and engineering about what work was executed. This usually manifests as technically focused tickets that PMs need help understanding, leading to people hoping that what engineers are working on is the right thing to do. Unfortunately, in this case, it wasn’t. That led to the scope increasing significantly within the project and frustration all around.
Think Globally, Act Globally
Ultimately, EMs have to think about managing their team end to end. That means managing engineers, where they have authority and decision-making power, and also across product and design, where they only have influence but are also impacted by decisions.
When thinking about that, there are a few critical broad principles EMs should focus on for their teams:
Think from idea to production — the EMs scope of interest should not only be how code is written. It should be about how problems become ideas and how those ideas are shaped and executed. That means understanding the product process in your company and influencing it when needed.
Lower lead time means higher value — when influencing your company’s process, focus on lowering the lead time from idea to production. A team’s success is not defined by how well engineering executes but by how fast they can deliver high-quality and impactful work to their customers. That means making decisions incentivizing short feedback loops, short iterations, and close collaboration between disciplines across the board.
Focus on early alignment — the main benefit of cross-functional product engineering teams is to have different perspectives shaping the product in all phases of product development. Because of that, it is essential to incentivize early alignment between product, design, and engineering, ensuring everyone understands and agrees with what they are building, why they are building it, and how they will do it. A practical process I have used to achieve this is Inception workshops for planning, assuring the whole team has a say right from the start.
Scope development in iterations of quality — the easiest way to avoid crunch time is to guarantee that there is always a version of the product that is live or ready to go live. That turns any uncomfortable scope conversation (“Why is this feature not live yet?”) into a more amenable business decision (“Should we release version 0.2, which is ready now?”). The best technique for that is User Story Mapping, which allows teams to think at scope in gradients and not on/off switches.
Create space for challenging conversations — EMs need to ensure that other disciplines understand the work and the trade-offs being made, allowing them to participate in the engineering conversation. In practice, that means writing all scope from a customer perspective, incentivizing healthy discussions about scope and effort, and allowing all sides to question the value of any work being executed within the team.
Ultimately, engineers and EMs need to focus on impact, and impact in a product engineering team is not only defined by writing code — the broader the conversation EMs can create around it, the better the results they will have.
If you have found this content interesting, this post is part of a series on Leading Software Teams with Systems Thinking. More broadly, I write about leading effective software engineering teams. Follow me if you are interested in the area.