How Do PMs Add Value to Engineers?
Spoiler: non-technical competence matters most
A big challenge for many PMs—especially junior product managers—is gaining and keeping the respect of the engineers. A *huge* part of the PM job is making life easier for engineers, and if you’re not making their lives easier then it’s pretty much impossible to succeed as a product manager.
A mistake many PMs make is to assume that engineers won’t respect product managers who don’t have strong technical skills. It (almost) never hurts for PMs to be technically strong, but in my experience it’s actually *non-technical* skills—organizational prowess, customer knowledge, clear communication, etc.—that will make or break the engineer↔️PM working relationship, because engineers primarily look for PMs to do things that engineers can’t or don’t want to do.
The list below summarizes a few relatively non-technical practices that PMs can follow. If you do all of these, you’re likely to win the respect of even the grumpiest engineers.
(Most Important) Be a customer expert. Become known for deep understanding of your user base. Whenever anyone (engineer, salesperson, support, etc.) has a question about what your users want, you should be able to answer it… or to figure out who can answer it. Spend as much time as possible learning about your customers via visits, surveys, market research, usability testing, A/B tests, etc. If the team knows they can trust your judgement about what the customer wants—and if you can prove it when needed!—then they’re more likely to enthusiastically support the roadmap you come up with.
Know the business and market. In addition to understanding your company’s customers, you also must know the competition, how products are sold and promoted in your industry, what industry trends are happening, and other details about how to maximize the revenue that your team brings in. You should periodically discuss what you’ve learned (at a high level) with engineers you work with. That way they’ll always know *why* they’re being asked to build all this cool tech.
Write documents with the right level of detail. Every engineering team has their own preferences for how much detail they need from PM to complete their work. Some teams like only high-level requirements or user stories that they will flesh out on their own. Others like very detailed specs with every UI element and behavior carefully specified. Some like to work directly with designers, others want PM to do that. Some prefer prose, others like numbered bullet points. Some like simple wireframes, while others like more realistic UI mockups. Learn what engineers on your team need to be productive, and give it to them! FWIW, “writes bad specs” (or user stories, requirements, PRDs, etc.) is the #1 complaint that I’ve heard from engineers about PMs.
Shield your team from randomization. Engineers hate being distracted by 1,001 questions or requests or meetings from marketing, support, sales, execs, end-users, etc. A good PM will figure out how to get all that communication pointed at yourself so you can triage the easy stuff and turn the hard stuff into more efficient formats (e.g. bug reports with clear repro cases, or feature requests with clear business context) so your technical team can focus on building cool tech. Especially important: minimize the number of meetings that you drag engineers to that they didn’t really need to attend.
Stay ahead of your team. There is, IMHO, no greater process failure for a PM than having your engineering team run out of work to do. You should always try to stay a few weeks ahead of your engineers. You should always have the next sprint’s backlog clean and ready in advance. You should always show up to meetings you accepted. And so on. You’re the PM, so it’s your job to make sure that the trains all run on time. If you find yourself doing your homework in real time (e.g. designing features on-the-fly in a sprint planning meeting) then you’re doing it wrong!
Avoid throwing away engineers’ work. Engineers hate working hard on projects that never actually get shipped or that don’t get used afterwards. Your goal is to minimize this happening by doing your homework on the business value, costs, risks, etc. for new features. My rule of thumb is that a task shouldn’t make it into a sprint unless I’m at least 95% sure that the feature behind that task will ship, and I’m at least 80% sure that it will be used by a significant portion of target users. If you need to run spikes or experiments to determine user interest, then be explicit with your team that this is a test, which will help avoid grumbling if it doesn’t pan out.
Take responsibility for problems. Never scapegoat. Never blame engineers for things going wrong. They’re just following the priorities and direction you asked them to, right? If the release took too long, think about and discuss what *you* could have done to reduce scope, to anticipate problems, etc. If the code shipped with too many bugs, think and talk about how you (and the team too) can do better next time. Never, ever throw engineers under the bus, even in private— it will get back to your team and they will shun you. Enthusiastically participate in sprint retrospectives or other post-mortems where you and your team can learn from mistakes.
Be a highly-responsive “unblocker”. In any complex tech project, engineers will frequently have questions or concerns about even the most simple features. Your job is to get those blocking questions answered as soon as possible so they can finish what they’re working on. Think of yourself as the JIRA of engineers’ questions; it’s not your job to answer all questions yourself but it *is* your job to be the tool that ensures that those questions get answered quickly. Especially important: don’t “go dark”. If you’re traveling or are so busy that you can’t reply, let folks know when you’ll be back online and what they should do if they get blocked while you’re out.
Be a bidirectional business<->engineering translator. Non-engineers and engineers often struggle to understand each other. As a PM you straddle both worlds, so you’re uniquely positioned to translate engineering communication and terms into language that the rest of the company (and your customers!) will understand. Similarly, engineers will often misinterpret what business folks want. They’ll have a much easier time if you can explain business requirements with enough context and detail that they can see how to write code to satisfy those asks. I’m not saying that engineers should be isolated from the rest of the business, only that helping engineers understand the rest of the business—and vice versa—is partly (mostly?) your responsibility.
Internally promote your team and their work. It’s your job to let the company know what amazing things engineers are working on. In most companies, most non-technical employees don’t understand exactly what engineers do. So it’s your job to explain why all those expensive engineers deserve those fat paychecks! This can include recognizing specific engineers or teams when a cool feature ships. It can mean explaining a technical improvement in business terms. It can mean inviting engineers to give demos or otherwise get visibility with management. One easy piece of advice: whenever *anyone* compliments you about product changes, you should immediately and publicly call out and compliment the engineers, designers, and others (ideally by name) who built the thing. Don’t let your team feel that you’re taking credit for their work. Instead, your team should think of you as their “agent” who’s always supporting and hyping them within the company.
Take technical debt seriously. You’ll probably want engineers to spend 100% of their time building new features. Resist this impulse. The team needs to refactor old code, to upgrade tools and platforms, to automate manual tasks, and to fix stuff that customers don’t see but which makes engineers' work much easier. This is called “technical debt.” If you defer this maintenance too long, your team’s productivity and morale will suffer. My suggestion: carve out a percentage of your capacity (sprint points, hours, whatever) and hand that portion over to your engineering team so they can triage engineering debt tasks and work on the ones they think are most important. Ideally, PM should not be involved with this triage—just give your engineering team a consistent, predictable chunk. They’ll do the right thing. In my experience, 20%-30% is probably the right allocation for most SaaS teams, with only occasional exceptions like the sprint before an annual conference or a “tech debt sprint” to tackle big refactors.
Encourage product feedback. Engineers often have great product ideas but they may not always feel comfortable sharing, so it’s good to encourage engineers to give product feedback and good for you to treat it seriously. Often this is easy and natural during sprint planning or spec review meetings, because you can ask for concerns or suggestions with the feature while you’re describing it to the team. The key is to be proactive about asking for feedback, because many engineers can be shy and may not think you will listen nor care. Another caveat: lots of internal feedback will be bad ideas. This is OK. I’ve found it helpful to start with praise and then ease into honest and clear feedback that sets realistic expectations about the likely priority of the suggestion. For example: “You’re definitely right that adding mouse-wheel support would make it easier for power users. I’ll add that idea to the ranking question in our next quarterly user survey. That said, only about 20% of power users log in on PCs; the others use iPads or phones only. If the survey doesn’t show big demand for this, I think we’ll probably want to focus on features that don’t need a mouse.”
Persuasion is better than force. Don’t yell at your team. Ever. Also, you should almost never force your team to do something that they strongly don’t want to do. It’s almost always easier to get humans—engineers included—to do what you want if they also want it. That means it’s your job to persuade and convince, not to “pull rank” as a senior person. Even if you have decades of experience and they’re just out of college, it’s still smart for you to spend the time to make a convincing, evidence-based case for your opinions, and to respectfully engage with theirs. You’ll win more respect that way, and you might end up avoiding a mistake if they’re right!
Like and respect engineers. This one is intentionally vague, but the basic idea is to ensure that your team knows that you like them and respect their work and their time. Get to know team members as people, not just “resources”. Hang out with the team, especially when you don’t need anything from them. Do favors for the team, like bringing coffee in the morning or dinner if they’re working late. Give away your conference swag. You get the idea: find ways to show that you care. Some PMs (often those infected with a “CEO of the Product” mentality) treat engineers imperiously as if the PM job is more important or more prestigious than the people who actually build the product. The best PMs are humble and helpful—they serve their teams rather than the other way around.
Most of the techniques above are common sense: if do your job effectively while treating your team well, then they’ll like working with you!
This post is a lightly-edited version of an answer I posted on Quora several years ago.