I’ve been lucky enough to work with some awesome Product Managers (PMs), and I’ve also worked with some of the worst. When I started as an engineer, I had no idea what to expect of the PM function. If I had known more, I could have avoided time wasted toiling on misguided or mis-marketed products. Here’s my nerd-skewed/enterprise-skewed list of what I look for now — I wish I had this list a long time ago.
You might consider this list whether you’re interviewing a PM, or if you’re considering joining a company/group. You don’t want to build the wrong product, nor do you want to watch your product die on the vine. You deserve to work with an awesome PM.
The awesome PM is hands on with the product
Turn around and run if the PM can’t drive the product. The PM should be able to drive it as well as anyone in development. The PM should be able to point out all the sore spots in the UX — they can tell you what sucks by showing you.
The awesome PM knows the customer use context
The PM must understand how the product is deployed, managed and used by customers — well enough that you can develop from the information that the PM gives you. Real details, real examples from customers.
You can ask the PM questions like what %-age of our customers use feature-X? What happens to sales if feature-Y doesn’t make it into this release. You should get a quantitative answer. The accuracy will depend on the situation.
The awesome PM brings in customer problems/opportunities — not features
I once worked at a router company where the PM would always come back from customer visits waving a feature description. Invariably, the PM missed 20% of what it took to solve the customer’s use-case. This meant that we would miss the opportunity, because it always took two releases to get anything right.
Even if the awesome PM thinks they know the solution, they know that they’re better off sharing the problem with the team first. The team, working together, will find that missing 20%, or at least ask the right questions that lead to re-examining the use-case, or going back to the customer with more questions.
When the PM becomes a product definition autocrat, the entire team’s level of play drops down a notch. Engineering becomes just a factory, doing what it is told to do. It is important, however, to note that PM must still own the overarching product definition — team involvement is a leadership requirement placed on the PM.
The awesome PM involves Engineering with customers
A great PM has relationships with the customer base, and is secure enough to expose “customer-able” engineers to the customer. This gives the engineers a refresh on customer priorities/perspectives, and allows the engineers to technically understand the use-case deeply. This is another guard against the aforementioned “missing 20%” problem.
The awesome PM is technical
I’ve worked with PMs who wrote important RFCs — while they were employed as PMs! Beware the PM who isn’t curious, or who doesn’t have the technical chops or inclination to really understand how the tech works. To be clear — don’t expect them to design the product or write code. Do expect the PM to be able to hold a technical conversation with you. Do expect the PM to be able to hold a technical conversation with the customer!
The awesome PM can communicate
A PowerPoint master isn’t what you’re searching for. Nor are you looking for the author of boring-ass press releases. The awesome PM must be able to communicate the essence of the value proposition — what the customer cares about most — succinctly and passionately. No matter the medium.
Sure the medium is PowerPoint sometimes. But it is also live speaking, social media, thought-leadership engagements, and plain-old personal interaction. The awesome PM becomes a “player” in the space where the conversations about the product and your competition are happening. Customers want to meet and talk with the PM because the awesome PM is somebody in your market space.
The awesome PM knows the road to riches
Who in the customer organization has the burning problem? Which roles have to say “yes” to make deals happen? The awesome PM understands the perspective of all the buying constituents: CEO, CIO, Director of IT, LOB owner, end-user, admin — you name it. Leading to …
Which messages need to go where? How to measure message effectiveness? And how to constantly improve messaging? The awesome PM is all over it.
It almost goes without saying, but the awesome PM builds relationships with a smattering of people in all of the above constituent roles.
In the same way that you refuse to hire or work with a developer who is going to screw up the code base, you should apply your strongest selection criteria to the PM. An awful PM can be a lot more disastrous than a bad developer.