Effective Product Manager: Work with Engineering

This week I’m going back to the “Effective Product Manager” series, and I’m going to talk about how to work with engineering effectively.

Feel free to check out or revisit the previous posts in the series!

• Execution
• Roadmapping
• Stakeholder Management
• Strategy
• Building Relationship
• Empathy
• Communication

In this post, I’ll speak to:

1. Why is it important to work well with engineering
2. What is engineering looking for in you
3. Principles of working with engineering
4. Frequent FAQs

Why Is It Important?

Engineering actually builds, delivers, and maintains the product. Engineering is probably more important to a PM than foods are to a human. (I mean, you can probably still drink to survive…for a while).

If they don’t trust you, don’t get what they need from you, think you’re full of shit, don’t want to build what you propose, or flat out hate you, you’re DONE as a PM.

Is it important enough? I thought so.

What Are They Looking For In You?

Not exhaustive, but the top ones as follows in my experience:

1. Leadership: They look to you for directions: what’s important for the business and why? what are the top problems worth solving (and why)? Which ones on the roadmap are more important (and why)? Look, it’s different from just telling them what to do. They want the full context. It’s not that they’re not smart or curious enough to understand business. It’s that they don’t have the time and they’re focused on technical. They look to you for it because it’s your job. They want to be “convinced” but not dictated. They want directions when they’re lost. They want you to get out of the way when they know what to do.
2. Clarity: Similar to above, but specifically for you to always bring clarity to the ambiguities and unknowns. There are a ton of those in all phases of the product lifecycle. From problems to vision/strategy, to roadmap/prioritization, to processes and tools, to blockers/distractions/dependencies, to how we roll out, to how to determine success and next steps, to some paragraphs in your PRDs, to design options etc etc.
3. Technical Chops: They might not expect you to know technical as broadly/deeply as they do. But they want you to want to talk technical with them as needed. If you don’t understand, they want you to be curious and try hard to learn and understand. They want you to know and respect how sausages are made. They want you to not only participate but also to influence technical decisions at times, in your business/product lenses.
4. Respect: They want you to respect them, respect technology, and respect their work (and all complexity behind it). They want to be deemed as equal partners in product (vs as just “resource” to get things done).

Principles

Just like any other topics, these principles should not be universally best for all of you. These are the top 3 principles that worked well for me and I’d like to share with you:

1. Bring Them Along the Journey: Treat them like equal partners like you mean it. As much as you can and their times allow, get them to participate in problem discovery, vision definition, planning too along with execution and delivery. Get their opinions beyond technical point of views. Expose them to the end users in the right opportunities as seeing is believing. There’s not a better way to motivate engineering.
2. Empower: Provide context but not control. Give engineering what they need, including ownership and get out of the way. Do what you can to make they successful. Because when they are, your product will be successful, and then you’ll be successful as a PM.
3. Don’t Fear to Get Into the Weeds: The best PMs effortless navigation between the trees and the forests back and forth and not lose sight on either. Step in to the very project execution gaps and technical details as needed to unblock the teams, and step back out to ensure we’re headed toward the bigger picture.

And finally as with all other roles, take the time to develop personal relationships and understand what drives/motivates them. It goes a long way.

Frequent FAQs

How technical should I be? What if I have ZERO technical background?

It might vary from role to role. Some roles are more technical (e.g. ML/AI, Platform, Developer products) in nature than others. The rule of thumb is to be as technical as needed by the role. But always keep in mind that 1) you’re NOT and should NOT be an engineer. 2) your #1 job is to deliver value to the business.

It’s always okay to not have any background. It’s NOT okay to not want to learn technical. If you’re not interested in even the highest level technical topics, product management in tech is not for you. (Believe me you won’t be happy).

How much time should I spend with each engineer on the team vs with tech lead / engineering manager?

There’s no single best answer. In my experience, you do want to make sure you spend quality time with engineers on the team directly as well, not just with engineering managers. You usually (and as you should) spend more time with the lead to stay aligned on how to steer the team toward the shared goals, but as much as you can, engage with the individual contributing engineers directly too, both in team settings and 1:1s.

You will have to find the best balance for yourself based on the needs and your time. Just know that any of the following is not ideal:

1. Spend no time with the ICs
2. Buddy with the ICs but have a bad relationship with the Leads
3. Spend all your time building connections with Leads and the ICs but overlooking other key responsibilities of yours

Sounds like my goal should be to please the engineers, is it true? What if I disagree with them?

NO. Your goal is NOT to be please the engineers. You goal is to deliver value to the business. Sometimes (or more often than not) that happens to align with making your engineers happy (by providing them what they really need to succeed in their jobs, for instance). But their happiness is not what you optimize for. So go ahead and disagree with them if you do. Go ahead and provide constructive feedback, hold them accountable, and drive them to do what they should.

To Wrap

I’m pretty sure my coverage above is not comprehensive. It is a simplified take on how to work with engineering. But I can assure you that I used above as my reminders a lot, and it helped. I’m curious to learn about your own experiences and challenges! Contact me.

—

Like this article? Subscribe to join the community and receive free weekly posts!