How Engineers Want to Work with Product Managers

Engineers want to build the product. They do not want to manage it. So, you can see why a good product manager is an engineer's dream come true. They empower the engineers on their team to build things that matter by setting clear and comprehensive goals, strategy, and initiatives. Then, great PMs prioritize potential features by how well they help their company achieve its goals.

Conversely, a bad product manager is an engineer's worst nightmare. An incompetent product manager can keep the engineers chasing shadows as they are "asked" (aka forced) to build and rebuild to keep up with priorities that may shift on a whim.

Even worse, an ineffective product manager forces the engineers to take on portions of managing the product — a role that distracts and detracts from their primary work of building what matters. What separates a good product manager from a bad one? Endless articles have been written on this subject.

At Aha! we speak with hundreds of product and engineering teams each month. We see both sides of the story. From an engineer's perspective, though, here is some simple advice for how to stay in the good graces of the engineers you work with.

Do Your Job First

It can be tempting as a product manager to overthink the product. Really, doing so is part of your job. But one area where it is important not to overthink is in actual implementation of new features or "how" things get built. That is what engineers are for. You should not prioritize features based on how hard you think they will be to build. Instead, start with the "why" and ask yourself if each feature will help your company achieve its vision and goals.

Engineers care deeply about building things that people use. Sometimes, good product management creates extra work for engineers; they might have to push the limits of what your technology stack can do, or even add new components to provide new core functionality. There is a cost associated with this that a responsible product manager must consider — but do not overthink it. Instead, trust your engineers' estimations and let go. A hyper-productive engineer loves a good challenge.

Plan Twice, Code Once

Unrealistic expectations are perhaps the most frustrating aspect of working with non-technical users. These colleagues often have a poor understanding of how long something will take to build. Every engineer gets knowing grimaces when they relate stories of non-technical users spouting lines like, "You just tap a few lines of code and it's done!" Or, "Just go drag some things around your screen!"

A healthy application is like a healthy organization: it is not a jumble of code, but rather a carefully organized hierarchy, and frequent changes often require substantial restructuring of that hierarchy behind the scenes. This creates work and frustration for the engineers.

This is also why master product managers are thorough and — most importantly — decisive while planning. Waffling about whether new functionality should be added or how it should work creates frustration for the engineers (whether they show it or not). This indecision forces us to code and re-code the same thing over and over again — work that could have been saved had you been more willing to think through your plan before sending it to your dev team.

Admit Your Mistakes

We understand — you are human. Sometimes, you ask for a feature that a customer demands and then decide it is unnecessary. Or maybe you have a feature built and then decide that it should work a completely different way. The company's strategic goals and initiatives ought to be the highest priority; if this requires reworking an already-built component of the application, so be it.

The most important thing is that you are able to admit your mistakes. Engineers will rarely get frustrated with a sincere, "I am sorry; I had you implement this feature the wrong way, and I would like you to build it out differently instead."

What will frustrate the engineer (especially if this happens often) is obfuscation and gaslighting. Yes, sometimes requirements change or are added as the feature takes shape. But if you ask for a complete restructuring of the initial spec, do not try to pass this off as a small change. Yes, the feature may have turned out differently than you wanted it. But it is your job to clearly and concisely communicate what you would like to have built. Do not pass blame off to your engineers.

A good product manager is an engineer's best friend. Maintaining a solid relationship between the product management and development teams is essential to the healthy growth of any organization. The best news of all? This does not have to be hard. Clear communication is your gateway to success. Everyone on both teams will thank you both for it.

Engineers and product managers, what have you found to be helpful when interacting with the "other half" of the relationship?