You see it everywhere: Engineers complaining about the product managers that they work with. Hating on PMs is kind of like complaining about your utility provider or the TSA – so universal that it’s always good for a light chuckle in the right circles. The PMs don’t know how the technology works. All they do is send emails and take credit. They’re meeting generation machines.

This cycle is worth breaking. When things are going well, PMs can focus on business / user needs, which takes a significant amount of time when done right. Engineers can focus on building elegant and stable solutions, which also requires major time investment. When the functions work together, everything gets done with focused attention. It’s far from rocket science.

(This applies just as much to Designers, Data Scientists, Program Managers, and others – but Engineers tend to be the most numerous members of a product development team and PMs are often the most visible, so they come into conflict more easily)

One of the things I’m most proud of in my career is the bridges that I’ve built from the product management team that I run, and the engineering partners that we work with (and I’m a former engineer myself). Here are some of the areas where I’ve focused most.

Hold Yourself Accountable

Product Managers, on the surface, are the least useful members of a traditional product development organization. Engineers write code, Designers create mockups and wireframes, but PMs’ primary output is decisions, and decisions are ephemeral and fluffy enough that it’s all too easy for them to appear to be… nothing.

Some ways to hold yourself accountable include:

• Participating in standups / check-ins and sharing your own goals and activities so that your teammates know what you’re doing.
• Write things down and share them, particularly research, decisions, analysis, and wins. Even sharing the raw notes from a customer conversation (that will go into a more complete synthesis later) helps distribute knowledge and shows that you’re making forward progress.
• Being first in line for key activities such as generating initial Product Requirements Documents, collaborating with sales and marketing, or writing documentation.

Demonstrate Obvious Expertise

As a PM, you show value most rapidly by having expertise at the ready, and the first place to establish expertise as a PM is by knowing your customers. Most great PMs that I’ve worked with could do their customers’ jobs reasonably well, because they know so much about what their customers do all day. The litmus test: When an engineering team wants to know a customer’s needs or motivation for a particular scenario, your first guess as to what they’d want should be correct about 80% of the time.

A closely related area where PMs should demonstrate expertise is the broader market landscape. Who are our main competitors? Where are they strong, where are they not? How about our partners – which ones matter, and which don’t? A good litmus test is that you should know all of your product’s major competitors and the top / bottom three characteristics of each.

And of course, one of the most important dimensions of being a great PM is simply having a nose for what will make money. Make the right call on a product that flies off the shelves a few times, and you’ll build credibility for years.

Being able to provide trustable expertise on command is valuable because it frees up engineers to focus and build. If you bring expertise to the table, you’re an accelerant. If you don’t, you’re a passenger.

Help With the Dirty Work

A lot of the most important dirty work that PMs typically do is operational – communicating project status, helping to set up processes around items like OKRs, tracking data, or training sales. In many organizations some of this work is covered by Product Ops or Program Management; whatever the split of work is for PMs, don’t skip your share.

As a PM who isn’t in the critical path for producing the hard outputs of designs or code, it’s also important to be the glue on the team. If someone needs to do some light QA, edit some docs, or hit up a member of support to clarify a need, you’re the first person who should raise their hand. This is especially true during periods of high stress like an urgent response to a customer need, an escalation, or an upcoming deadline.

Operational work does help teams run more smoothly and people on smooth teams tend not to dislike their team members. But more importantly, if it feels like you’re shirking these responsibilities you’ll get a reputation as a freeloader – a great way to be hated.

Be an Engineering Management Ally

In most organizations, Product and Engineering (and often Design / Data Science) work in tandem. Great PMs shape their organizations beyond just their own work and their own teams, by helping to (productively) structure the organization in ways that will help the company get more done. This is especially true for the Engineering / PM relationship, because engineers typically comprise the lion’s share of the team.

Org structures have a tremendous impact on the speed and quality of shipped product. Some of the ways that PMs can be partners to their counterparts include helping to identify different org structures – would a team function better if it was split, or would a reorg of a few personnel help accelerate. By virtue of the fact that they often are in contact with many teams and projects, PMs often have good insights for identifying these potential shifts, and are important in communicating the vision of why they should happen to get teams onboard.

Other key ways that PMs can help bolster engineering include communicating a compelling vision (to motivate the team) and being an ally in prioritizing tech debt or incident reduction (to avoid burnout). As a PM, your engineering management counterpart’s KPIs are health indicators for your job as well. Employee retention, engineer job satisfaction, and development efficiency all matter.

Be a World Class Copilot

When it comes to implementation, you’re like the copilot of a plane. It’s your job to navigate, to help check that nothing is going wrong, to communicate, to help jump in in a pinch, and to be judicious about when to shut the fuck up. It’s not your job to distract the pilot flying by second guessing all of their decisions, and even worse to try to grab the steering wheel yourself.

If you think that something is being executed incorrectly, the right approach is to ask questions. And not in a sarcastic way – sincerely try to understand. Listen actively and repeat back what you’re hearing. Ask about assumptions they’re making; ask about risks; ask about the hardest rate-limiting steps in the proposed implementation, and what other ideas were considered.

The two phrases to avoid at all costs are prescriptions like “I think you should” and “Why didn’t you.” If you think that something is being built incorrectly, or taking too long, one of a few common outcomes will happen from asking questions:

• You’ll realize why the assessment you heard was right.
• They’ll understand from your questions that they’re wrong (you may need to steer them there).
• You’ll both realize that there was some sort of misunderstanding or optimization to be had – for example, the least important feature would be the hardest to implement, and can be skipped. This is one of the things that you’re getting paid for.
• You’ll realize that this is way harder than you thought to understand, and that you need to learn more.

In any event, backseat driving isn’t going to get you to a good conclusion, and all of the outcomes above are better than jumping in and trying to tell engineers what to do.

The ability to thoroughly question the actual engineering level of effort required for a project without causing mayhem is one of the most advanced PM arts. As a result, it’s little surprise that many of the strongest PMs are former engineers, highly empathetic, very close with many partners in engineering, or all three.

Be an Advocate For Your Team

And finally – give credit liberally and take credit sparingly. PMs are usually in charge of communication, so credit in the organization naturally accrues to them. As a PM it’s absolutely vital that you publicly pass that credit to the team.

This final step is both the easiest and the most important. If you take too much credit your team will resent you, and you’ll fail. You won’t necessarily be a great PM if you’re great at giving credit, but you’ll definitely be a bad one if you don’t.

I have seen great PMs do very unnatural things in order to give their teams credit, and in my opinion that’s totally fine:

• Putting mildly awkward messages into public Slack channels to make sure that their partners got recognition.
• Interrupting or correcting other communication to make sure that a thank you was given.
• Expending political capital to make sure that teams were thanked (“hey marketing, you have to call out X engineer in the announcement of this launch”).

Another part of advocating for your team is that you should also take blame with the team. Saying things like “our engineering team screwed it up” is a great way to sow division on your team, and it’s also frankly a pretty bad look to any observer who’s worked with high-performing product development teams – if they screwed up, where were you? Your goal is to make sure that you and your engineering partners are in the foxhole together.