The best and worst traits of PMs I’ve worked with

I am curious to know about the traits of the best PM you ever worked with — what set them apart? On the flip side, what about the most difficult PM you ever worked with — what were the biggest challenges?  — Asked by Product Manager @ SAP

Dear PM @ SAP,

Great question! And luckily I have a lot of experience to share.

I’ve worked as a developer with a great number of product and project managers at various company stages and levels of project/technical difficulty, but I learned the most working with product managers at Amazon.

At Amazon I met some of the best product managers I’ve ever worked with… and ironically, also some of the worst. The three things that set them apart really came down to three areas:

• Willingness to improve your technical skills
• Ability to bridge the pm<->engineering communication gap
• Having an “enabling” vs. “telling” mindset

Willingness to learn technical skills

Engineers are notorious for being a little prickly and can be intimidating to work with, especially at the beginning. But as soon as you show even the slightest bit of being willing to understand them, and put some effort into trying things yourself before asking for their help, engineers will open up and this will go a long way towards building a rapport with them.

And here’s why…

Because as any real techie knows, building and maintaining software is really hard and an engineer’s backlog of tasks is never-ending.

So understandably, engineers are weary of product managers that want to add more onto their backlog. They’re much more willing to build a rapport with you if they feel you’re willing to understand them and help alleviate their work.

To sum it up:

• The best product managers I’ve worked with are curious about what I’m working on, willing to understand my work and the technical aspects of their product, and willing to get their hands dirty figuring out problems themselves or as much as possible before asking me for their help.
• The worst product managers I’ve worked with don’t care to learn technical skills, and/or feel they’re not “smart” enough to understand the technical side of things. Whenever there is a problem, they looked to me for all the solutions instead of trying to do some of the legwork themselves.

Ability to bridge the pm<->engineering communication gap

Translating between the product and engineering perspective isn’t easy, but the best product managers I’ve worked with are great at understanding the engineering perspective and have the communication skills necessary to bridge the pm<->engineering gap.

Use visuals to bridge communication

I remember once being in a meeting with a product manager trying to hash out the complex if/else user flows one of the product managers had outlined in the business requirements doc. Talking didn’t get us anywhere as the product manager had not thought through the edge cases herself and our discussions wound up in circles.

Luckily our TPM stepped in and really bridged the gap by using if/else diagrams to convey the complex edge cases. It’s the first time I’d ever worked with a product manager who used diagrams and visuals as the primary way of communicating business requirements and it was a game-changer for us.

Set expectations and priorities of deliverables

When writing product and business requirements for developers, it’s tempting to write out the entire short and long-term vision for your product. When you do this, you’re only seeing your app from the product/customer perspective.

But this is overwhelming and un-helpful for developers.

It takes lots of time and resources to build every piece of functionality so prioritizing what needs to be built and when it is expected is crucial for developers. Developers want to know what is expected of them and at what time. This means as the product manager you need to set priorities and expectations.

Here are a few ways to do that:

• Set priority of tasks/features using priority labels (i.e. P0, P1, P2, etc..). P0 means critical priority, and every number up is lesser in priority.
• If there are a lot of features, bundle and break the requirements down into phases for when they should be completed by so engineers know what is expected of them

To sum it up:

• The best product managers I’ve worked with understand the software development process and takes the engineering perspective into consideration when ideating on products and writing requirements. They think through edge cases in requirements and are able to communicate them in a way that is easy to understand.
• The worst product managers I’ve worked with fail to set expectations and priorities to engineers, and instead gives a long list of requirements expecting developers to parse through it.

Having a “enabling” vs. “telling” mindset

Many product managers make the mistake of seeing themselves as the “mini-CEO” of a product team. They view their relationship with devs as one-directional where they dictate the features and engineers build based on what they direct.

But this mindset only leads to more friction and is less effective.

Instead, adopt a mindset of “what can I do to take work off your plate or make it easier for you to build?”. In other words: how can I help enable you to do your best work and get the product across the finish line as quickly and efficiently as possible?

The best way to do this is by actively taking part in the software development lifecycle (SDLC). Not only are you showing appreciation for the work your engineering team is doing, but you’re also showing them you’re willing to take time out from your own schedule to help them with theirs.

You can take an active part in the software development lifecycle by taking over responding to customer tickets, helping write documentation, take over parts of the scrum process like grooming the backlog, clarifying requirements or areas of confusion, or taking over communication with cross-functional team members.

To sum it up:

• The best product managers I’ve worked with know that a big part of their job is enabling developers to do their best work and get the product to the finish line, and that means rolling up their sleeves to remove roadblocks for developers by taking an active part in the software development lifecycle.
• The worst product managers I’ve worked with tell engineers what to do and become upset when it doesn’t happen when they expect it. An active approach should be taken to understand what engineers are working on, and then work together on prioritizing tasks.

Positive feedback is feedback too!

We often think of feedback as “critical feedback”, but positive feedback is just as important! Team cohesive and effective teamwork ultimately comes from a place of positivity and a sense of forward/upward momentum. It’s difficult to have these when just focusing on critical feedback. You want to know what you’re doing right along with ways you can improve. So as much as possible, ask for positive feedback like “What did you like about [x] that you’d like to see me continue doing?” and “What was your favorite part about [x]?”

If you want to level up your technical skills and your ability to communicate and collaborate with engineers, enroll in the Skiplevel program. The Skiplevel program is a comprehensive, on-demand course + community that helps you become more technical without learning how to code.