Product managers (PM) and engineers depend on each other to execute and launch new products and features. They are partners-in-crime in the product development cycle, and the strength of this relationship has a huge impact on the success of the product team. As a PM, what can you do to build the foundation for a strong and thriving relationship with your engineers?
As a product manager, trust, ownership, and accountability are the foundation of a thriving relationship with engineers. In practice, this means having a good understanding of key technical concepts and establishing clear boundaries around the roles and responsibilities.
When it comes to defining the boundaries, a good rule of thumb is for product teams to take responsibility for the “why” and “what” while the engineering team defines the “how,” “who,” and “when.” But as you will see in the rest of the post, the way PMs execute their work can make a significant impact on the trust and accountability in the relationship.
What Engineers Hate about Product Managers
Nothing annoys engineers more than product managers who have little understanding of and make no effort to understand the world of engineering. This can take many forms and can be made by both technical and non-technical PMs. Some of the common mistakes PMs make that frustrate engineers are:
- Writing unclear requirements.
- Inability to make a clear decision
- Creating deadlines without engineering input
- Making commitments without engineering input
- Frequently changing priorities and context switching
- Deciding how something should be implemented
- Making assumptions on technical difficulty and complexity
- Throwing blame
- Scope creep
Even the most experienced PMs will make these common mistakes from time to time because PMs often feel like they can’t bother engineers for feedback or input. Not only is it the PM’s responsibility to communicate and gather input, but engineers are generally very happy to provide feedback. Let’s go a bit deeper into each of the points above.
Writing unclear requirements
This is usually an indication that you aren’t sure of the problem you are solving, or don’t have enough information to start development. As a PM, you might think that we need to get started with the development ASAP and figure it out along the way (after all, we’re agile right?) but doing due diligence here will save a lot of time down the road. The best recommendation here is to get feedback from engineers early and often. They will help you see the blind spot and identify dependencies and edge cases.
The Consequence– if there is little trust or accountability with your engineers, unclear requirements can be extremely dangerous because there will be little attempt to clarify the requirements before development. Consequently, what gets built is not the intended solution, and the team loses time, money, and credibility with each other.
Inability to make a clear decision
Even after careful planning and discussion of the requirements, new information will be found throughout the development process that may require new decisions to be made. Naturally, this will mean that there will be new tradeoffs to consider (scope? time? cost?). As a PM, it is critical that once the development has started, decisions are made quickly and clearly.
As a PM, it helps to discern between decisions that cannot be easily reversed (i.e system architecture change, pricing change, etc) vs ones that can. If it turns out that the development needs to temporarily stop for careful reconsideration, then that decision should be made quickly so as to not keep your engineering teams in limbo.
The Consequence– Indecisiveness not only wastes precious engineering time, but it also makes the PM appear to have little accountability
Creating deadlines without engineering input
PMs have a ton of pressure on them to deliver new products and features quickly. However, creating deadlines without proper technical due diligence is setting the entire team up for a lot of pain in the future. The chances of a technical blindspot are quite high and even if you are familiar with your technology, there may be resource constraints within the engineering team that you may not be aware of.
The Consequence– Creating deadlines without engineering input is a clear way to show that there is little respect or understanding of the development process. Creating deadlines on assumptions or solely on business needs is setting the team up for failure. The chances of the deadline being met are extremely low, and furthermore, trust and respect with your engineers deteriorate.
Making commitments without engineering input
Similar to the point above, making commitments like “yes we can add it to our roadmap,” or “yes, we can provide API to support the integration” without engineering input is like driving blind, hoping things would work out. Even though something might sound easy, the complexity and technical debt of your product may be unknown to you. Consequently, whatever commitment was made may not be possible- at least not in the time frame or manner you intended.
The Consequence– Creating commitments based on the business needs without talking with engineering creates a hierarchy in the relationship that deteriorates trust and accountability. Best teams have co-ownership of the product development, so involving the engineering teams early and often is key.
Frequently changing priorities and context switching
I know this one seems to be beyond your control since individual product priorities are often the result of a decision made by leadership, but there are some things you can do to protect your engineers from frequent context switching.
- Doing due diligence in the planning phase will help reduce the risk of priorities changing frequently. This means making sure that the problems you’re solving are the true root cause problems, and that you’ve weighted the impact analysis to make sure that it is the most valuable task your team can be working on.
- Always make sure that your priorities align to that of the larger organization. Having your OKR’s point to specific company level OKR’s will give you higher confidence that leadership won’t change their priorities on you.
- Even when there is a priority shift, it doesn’t mean that your team should immediately switch mid-task. If there is a reasonable milestone that can start bringing value, consider reaching it before switching tasks. The only exception to this would be if it is a critical issue that needs to be fixed immediately.
The Consequence– When PMs change priorities frequently without justification or alignment with engineering, not only does it kill productivity, but trust and respect for the PM deteriorate. From the perspective of engineers, changing priorities can be taken as a sign of incompetence and poor leadership.
Deciding how something should be implemented
PMs decide what needs to be built and why. Engineers have the final say on how it should be built, by whom, and how long it will take. Sometimes, PMs assume that they know better (especially technical PMs who have coding experience) and give direction on how something should be implemented, causing frustration for both sides.
To be clear, this doesn’t mean that each works autonomously in their respective areas. In fact, both PMs and engineers should be expected to challenge each other’s decisions. If you feel like the direction proposed by the engineers is not correct, it may be a sign that the requirements do not clearly reflect your motivations.
The Consequence– A PM telling engineering to build something in a very specific way needs to bring a very good argument for it. Even then, it is a suggestion and the engineers should make the final call on it- as they are the ones that will be taking responsibility for maintaining and building on top of it in the future. PMs who assume to know how it should be built can come off as arrogant, disrespectful, and dismissive to engineers.
Making assumptions on technical difficulty and complexity
Every time I make the mistake of thinking“that’s pretty simple, it shouldn’t take too long to implement,” I am proven wrong. As a PM, I have a good understanding of our tech stack and the capabilities of our engineering team. What I don’t understand is the technical debt we have or the details of the data structure. So even when there is a seemingly simple task, I always make sure to run it by my engineering manager to make sure that my assumptions are true.
The Consequence– Making assumptions on the technical difficulty and making decisions based on those assumptions can have severe consequences down the line. If those ideas go unchallenged, incorrect assumptions will surface mid-development, requiring schedule adjustments or complete redo. Most likely, the assumptions of PM’s will be vetted by engineering teams before
Finger pointing
PMs who throw blame at others in their team without looking at themselves first are forgetting that the product manager is ultimately responsible for the success or failure of the product. When things go wrong, product teams should take the time to retrospect and identify where things failed without pointing fingers. It is an opportunity to grow together as a team, but if handled incorrectly, it can break team trust.
The Consequence– Highly successful teams have a sense of safety when working together. A sense of safety is a fundamental human need, second to basic necessities like food, clothing, and shelter. When blame gets tossed around, this sense of safety deteriorates, and with it- trust. This makes transparent communication less likely, leading team members to want to hide mistakes rather than address them.
Scope creep
When the scope of the development increases gradually, it can frustrate all stakeholders as it will lead to cost and schedule overruns. Scope creep is usually a sign of unclear priorities and poor planning. When development begins with a high level of uncertainty (sometimes this is justified, but the risks should be understood), some level of scope creep is inevitable, however, the difference between managing scope creep and letting it manage you is in making calculated decisions to allow the scope to be added to an ongoing project.
Most projects keep a buffer to the schedule because things inevitably change throughout the development process. When that buffer gets used up, it is time to discuss trade-offs.
The Consequence– Continuous scope creep will burn out your engineering team and it will make it difficult for them to deliver high-quality work. As they get pinched to deliver more in the same time frame, frustration and anxiety will grow. A team where scope creep is the norm will begin to form bad habits, such as expecting to never meet deadlines and expecting frequent changes.
How to Thrive With Engineering Teams
Being aware of the common mistakes and being self-conscious as to avoid them can help maintain trust and respect between product managers and engineering teams. But how do you build trust in the first place? What kind of mindset and practices can help build the fertile ground for a thriving relationship?
Product managers who thrive in their relationship with their engineers have a set of common traits:
- Do not act like the CEO, because you’re not.
- Bring visibility to your work
- Generously give credit
- Challenge constructively
- Understand the development process
- Include engineers in discussions early and often
- Share the voice of customer (VOC)
- Understand basic technical concepts
By following the 8 guidelines, trust, ownership, and accountability can be built between the product and engineering teams, and the walls that exist between the two domains can be overcome.
Do not act like the CEO, because you’re not
I’m sure we’ve all heard product managers being described as a “mini-CEO.” While it is a romantic description of the role, the truth is that we are not. We don’t have the influence or decision-making powers like a CEO. So when working with engineers, realize that they are partners in the work.
Bring visibility to your work
Most of the work we do as product managers happen in the back and go unnoticed. Some might look at that and think that you are bringing little to the table. While the advice isn’t to seek attention, it is to not be shy about making your work visible. Share your findings from your market research, share VOC with engineering teams, share insight into what the competitors are doing. All of this helps to bridge the gap between the two domains and help build empathy for each other.
Generously give credit
Product managers have the privilege to be the person that gets the credit for the success of the product. But of course, behind the success is an entire team of diverse domains that made it happen. While it may seem like a trivial thing, giving a public call-out to specific individuals and their actions will go a long way in building a thriving relationship.
Challenge constructively
Don’t be afraid to challenge engineers. If your gut feeling says the estimates are too large, ask why and challenge if it really needs to be done that way. The point of a challenge is not to show authority but to really make sure that we are using our resources in the best way possible. Oftentimes, engineers will try to do more than is necessary. If we can save 15% of the development time by asking the right questions, everyone is happier for it.
Understand the development process
Having a grasp of how the development process works will help you execute with more precision. For example, if the team has a deployment freeze every Friday, it is something you need to take into account when planning a release.
Include engineers in discussions early and often
Including engineers in the product discussion as early as possible has a host of benefits down the line. Not only does it give context to your decisions, but the team can spend more time thinking about the right technical approach. Having the technical input in the planning phase can reveal new opportunities you didn’t realize.
Share the voice of customer (VOC)
While this may seem obvious, many early-stage companies forget to deliver the voice of customers to the engineers. Bringing the engineering team closer to the customer is the best way to help them see the impact of their work and understand why something needs to be built.
Understand basic technical concepts
While you don’t need to go out and get a CS degree, having a basic understanding of key technical concepts will help tremendously when working with the engineering team. While the exact list of things to know will vary depending on the product, industry, and technology, some common concepts are:
- Knowing how the internet works
- The difference between using open source vs customer code
- Technical debt
- QA testing process
- Data structures
- Databases
- API & SDK
- UI frameworks and design systems
- Software development methodologies
- Understanding your tech stack
Conclusion
Generally speaking, product and engineering teams work well together since they depend on each other for success. However, as a product manager, understanding what motivates the engineering team will help you thrive in your relationship together. Not only will this make your career in product management more fulfilling, but it will consequently allow the entire product team to accomplish more and make a greater impact.