What Makes a Great Product Manager
informedpm.com
informedpm.com
I've been a PM for 15 years. I've watched the rise and fall of the "ceo of your product" mentality. Mentored dozens of PMs, interviewed hundreds. The one common thread I've noticed across a wide range of successful PMs (and absent from unsuccessful ones) is caring deeply about their team, what motivates them and what they love doing. If you can't apply the same empathy you have towards customers to your own people, you burn them out.
Strongly agree that empathy for the team is important, but I will also say that I'm increasingly seeing junior managers (product or otherwise) become so focused on pleasing their team that they lose track of shipping product that customers will pay for. The problem is compounded in over-funded startups or cash-rich companies where the financial pressure to ship and sell product has become so abstracted away that people forget what the real goal is (sell product, generate revenue).
It's a balance. Managers obviously need to work with, not against, their team. However, managers also need to be able to make the tough decisions and understand how to motivate their teams to do the work that needs to be done, even if it's not exactly the work that people most want to do.
For example, I've had to talk multiple people out of writing complex React-based SPAs for simple features that could be shipped more quickly as basic static sites. I've also worked at companies that suffered greatly because they chose to rewrite otherwise functional core software in new, fun languages because it's what the developers loved doing. A large part of being a manager is focusing people on developing the right things, even if it's not the most fun and intrinsically motivating thing that the engineers want to do.
Despite having the funds to slow down just a tad and do things the right way, you'll find the overfunded startups use their funds to put into hiring salespeople marketing and people on the business side who have been successful selling companies or preparing then for an IPO, and the number of engineers hired during this time is logarithmic in proportion to the exponential growth elsewhere. A recipe for disaster when the PMs are slave drivers all the same but everyone is asking for more all of the time.
I've personally never worked under a PM who cared about the team, and I'm my opinion who cared about the product. I think they cared about their ego and seeming important and the idea of taking input from someone they perceived should be providing then requested output perhaps subconsciously threatened their idea of how everyone else might perceive them as being critical to the team. They were critical to the team. They just screwed it up by being so caught up in their egos about maintaining being in control and being right they lost sight of very objectively how their behavior could be putting the technical development and business development of the product at risk.
For whatever reason people with massive egos who can control people is often valued more than the value of whatever output is produced by that. It must be deeply psychological, and for me of course as a woman, I could never be successful as a PM because if I acted the way the men I've worked for did I would be called a raging bitch, because that's exactly what they were in my opinion. For whatever reason in makes this behavior is rewarded. Very bizarre indeed.
For those that haven’t, or if my respondent hasn’t: https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Ma...
It’s no holy grail of engineering management, but what it _is_ is a well sourced book of “starting points”. Nuggets of thought. None of them really complete, a good deal wide, not very deep, but ultimately very relevant.
His systems approach to hiring and staffing engineering teams as a pseudo-mathematical problem I found intoxicatingly interesting because it spoke to a challenge my org faces intimately, and much of what you said reminded me of some of the themes in the linked book.
Another one I don't see is communication skills. The PM is the face of the team in so many ways, and if your PM has shoddy communication skills, that ends up feeling like your whole team has shoddy communication skills.
PMs only add value when they serve as an interface between the business, challenging and parsing requirements into actionable tasks with a clear definition of done, aligning with other teams to eliminate blockages etc etc.
Unfortunately, many (most?) PMs do none of this, but instead see themselves as some kind of overbearing slavedriver who cracks the whip on behalf of stakeholders and their every whim without question, demands 100% insight into what everyone on the team is doing at all times, creating stress and throwing people under the bus when the shitty requirements and deadlines aren't met. It a ubiquitous and fundamental misunderstanding of the role that make them not just useless but positively harmful.
Having been on the wrong end of a low empathy pm (who on the outside seemed to look like they had empathy), I can say that there is probably nothing more important than this wrt developer productivity.
I don't actually even think that the lack of empathy was intentional, I think that it had more to do with a basic lack of understanding in many areas, that lead to unrealistic expectations.
I wholeheartedly agree that a great PM is a great advocate for the team, bringing team issues forward and freeing the way to get stuff done.
On the other hand it's often a tight rope to walk. I've seen situations often enough where a dev team would like to change frameworks/backends/dev environments/codebases, whatever it might be. And this has to be weighed between short- and long-term success. This is where a more technical product manager shines. On the other end of the scale I've seen dev teams walk all over their (non-technical) PM because they knew they could do so. It's a give- and take between team happiness and advocacy as well as end-user satisfaction and what the company needs at any given point in time. Being a great PM is actually much harder than it seems at first.
Multiple PMs I have worked under have simply demanded an outstanding feature of product without:
a) asking if it's ever been done before anywhere including say a team of 1000 google engineers much less your 11 person startup.
B) input or a guesstimate of an engineers timeline on how long this would take before respectfully working towards a compromise to meet a company goal
For both points having any level of reality internalized about if what they are asking is realistic.
In these cases the engineers not only get burnt out but produce the feature request knowing without additional consideration whether it be addressing tech debt supporting the feature which may finally catastrophically fail under that new load or what have you, and then getting stuck putting out fires to maintain the system only to have the PM come in and finally say ok how are we going to solve this problem but under an even more agressive timeline because it's failing in production because they insisted on pushing it even though they are the only ones who were convinced it was ready.
The only thing worse than pulling all nighters for a PM who thinks engineers just need to be told what to do and given a deadline and don't have any valuable seat at the table when it comes to implementing the design and a desire to help the PM be successful by highlighting challenges that could put the goal at risk to find a cool way to overcome those, is being told to shove out a crappy solution you're not proud of in a fraction of the time and then be yelled at and asked to pull more all nighters fixing it slowly and painfully the right way, with the pressure of failing customers in real time or humiliating the company by rolling back a feature, all the while knowing the root cause of the problem: The PM, is not being solved.
I have crazy one liners I've been given from PMs including but not limited to: "don't talk during meetings. You don't know what you're talking about and this meeting will move along alot faster if I'm the only one speaking."
In 2018 I had a PM chastise engineers on a company public slack channel that on Christmas Eve that he was dissapointed to see people actually using their vacation instead of a chance to get ahead.
I've seen that same guy ask a 55yr old woman going through cancer chemotherapy to pull an all nighter on a plane during the weekend for a company trip to meet no critical deadline whatsoever externally or internally except to meet his own he had set that day and not think twice about it.
I now work for a much more successful company and have been promoted beyond a senior engineer level and don't have to deal with PMs directly as such anymore but wow, it's amazing how abusive people can be in this position.
On the contrary, a really good PM can take a company to orders of magnitudes of success beyond what was previously imagined.
Tldr: mutual respect on a personal and technical and product level between PM and Engineers.
How would this happen? All my experience with PMs has been where they are equals, not superiors to the Dev Manager. So they can prioritize, cajole, inspire, but they cannot force teams into unrealistic deadlines (unless they somehow whisper in the boss' ear.) How would a PM "force" a timeline without honoring the dev team's estimates?
Of course, in any sane organization this would result in the PM's immediate removal. But not all organizations are sane.
I personally don't look for Product Managers but Business Managers.
Difference?
All the traits discussed here plus an understanding that your responsible for delivering products that need to generate $. It may sound obvious but I have seen many PMs who are obsessed about crafting beautiful applications when sometimes a cheaper and dirty approach is what is called for to win the business. This requires deep commercial awareness and an understanding of client incentives along with ability to properly cost up your business to form an opinion on the profitability of each client.
A PM’s job numero uno is to MAKE THE BUSINESS SUCCESSFUL, ideally by maximizing the intersection between customer/user needs (solving a problem), business goals, and their team’s/company’s capabilities. Sometimes, though, these three facets are at odds and one needs to prioritize one over the others.
The best PMs bring experience, empathy, and data to bear to figure out which one to optimize for, when.
I've never heard of anyone with that title having P&L.
The biggest thing is knowing your customer and your market. Product-market fit. Get it thru analytics, experience or customer interaction... but that’s job #1. The best product managers know their market terribly well by experience but also trust the analytics to know when to veto their gut.
As a PM working on technical products and collaborating mostly with engineers, I'll offer up an opinion on "good" vs. "not so good" PMs that an peer in engineering told me one. In his opinion, a good PM is someone who an engineer may not be able to easily point at specific things and say the PM accomplished them (e.g., some technical breakthrough), but there is an overwhelming feeling that without that PM involved at every step of the way, the team would just not be as successful. Since then I've made it my goal to be viewed in a similar light by engineering partners (though perhaps with more "I can tell you what they accomplished").
Another one that feels missing but it critical when working in large organizations: great PMs can turn a "it's silly we're not doing this, but it's complicated" situation into "I'm so glad we're finally doing this". Big organizations have enormous political barriers to getting things done and the best PMs in those orgs can steadily cut through that bullshit to make something happen.
A lot of people (maybe most people?) want a playbook and roadmap for how to do their job. For a PM it might be: identify a problem based on data or customer feedback, conduct user research, ideate with design, get input from external stakeholders, build with engineering, run an A/B test and rollout successful variant. All of these things may be necessary activities in different contexts, but it's also very easy to lose the forest for the trees. The bigger and more complex a company gets, the easier it is to get lost in the process and over-index on the wrong details. I can't count the number of times I've heard lip-service played to "being data-driven" as an excuse to avoid tackling the bigger but less quantifiable problems of how a product is failing to meets its customers' high-level needs.
Ive seen this model of the PM implemented in small 5 person startups and large 5,000 person public companies.
PMs used to be different. They were excellent performers from engineering/marketing/business that caught a bigger view of what was being built and had a gut feel of what needed to be built. It seems like those folks don't have a place to go any more and we continue to beat the cross-functionalness out of folks while saying we aren't.
This to me is the ideal state. One person, most likely the lead engineer, essentially acts as what a traditional PM/PO would. They understand the deep technical and business requirements of a product.
I think this might be the only setup in which you can achieve real innovation.
A business only needs a modern PM once they’ve crested the hill. The data roles in. The PMs absorb the data, distill it into tasks, and engineers build it. It’s more of an assembly line than building a product.
A bad product manager handles jira tickets
https://www.joelonsoftware.com/2006/04/11/the-development-ab...
We try as much as possible to lay out information and address "meta" questions so people make decisions on their own, know what we're doing and why we're doing it.
For example, the "If I disappear, what will happen" link was a reply to an Ask HN: "What makes a great CTO".
Latest reply[1] to a thread about making product management decisions.
I like to think of it as putting myself out of a job.
I’m a PM and too many of my peers don’t know a lick about how the products in their portfolio even work at a fundamental level. This lack of basic technical literacy leads to the inability to communicate and empathize with their development team. That makes requirements writing a Herculean effort of wading through abstractions, which obviously isn’t going to translate to quick delivery.
Perhaps worse is these types of PMs instinctually don’t include their developers in the ideation process, because they struggle to understand what they could even add to the discussion.
A PM must be curious, and that includes curiosity about the underlying tech. They must be in the business of demystifying and democratizing the building blocks of their products. This shouldn’t be at the expense of the business functions of the job, but it should be part of the multi-pronged nature of the job. PMs shouldn’t just be lobbing requirements over the wall with no idea what they’re asking for. And this doesn’t mean we always need to hire PMs with a technical background. One of the best things about the nebulous “product manager” profession is that it’s really just a catch all for people from all related disciplines who have a talent for working at the intersection of the user and the business. All I’m saying is at least watch a damn YouTube video about React Native, GraphQL, Drupal, or whatever the heck you use and I guarantee it will pay dividends in your requirements writing and your communication with your developers.
Good job descriptions and resumes include a comprehensive (though not necessarily long) list of skills and activities that the person is/must be good at. I wish more articles were talking about these concrete things, instead of using words that don't mean much at best and actively cause confusion at worst.
How do people get over this?
A questions for PMs and this community - Would you use a service that delivers similar product insights and research to your inbox or to cloud? I am looking to get in touch with people building products right now for 15 min interview.
return opposites(ordered__bad_pm, count)