I used to be a product manager at a previous job. It was a fascinating role that taught me a lot about how tech companies work, how software products get built, and the role of product managers in helping the company achieve its goals.
While the product management role varies across companies and industries, there a some invariants that, in my opinion, really sets one up for long term success in the role. I go into detail about two of these invariants below.
Breadth of Knowledge
A Product Manager should know their product better than anyone else. Everyone else in the software product development process is a specialist – Engineeers, Designers, DevOps etc.). Specialization is what makes them good at their jobs. Because the product manager has no real specialty, and therefore no tangible way of adding value to the team, their real value is in the breadth of knowledge that comes from being a generalist. Knowledge of features, bugs, and common workflows of not just their own product, but of adjacent products, is usually the difference maker in terms of bringing focus and clarity to the team.
One example is when an engineer has an erroneous view on how the product works and plans to build a new feature based on this incorrect view. Or a business stakeholder/executive is trying to make prioritization decisions based on how they think the product works. Sniffing out these wrong mental models, correcting them, and getting everyone on the same page is one of the highest leverage activities a product manager can be involved in.
Knowledge of previous states of the product might be even more important than the knowledge of the current state of the product. Odds are that the product manager did not build the product from scratch. The previous product manager(s), if there was ever one, made the majority of the decisions that led to the inherited state of the product. The product manager should always be asking why things were done a certain way. Why does this field exist? What problem does this workflow solve? Why was it done this way? are questions that should be at the fingertips of every good product manager. These questions should not be framed in a fault finding manner but rather as neutral fact finding questions for gaining historical context. A product manager will usually find themselves in situations where they have to debate pros and cons of various approaches to solving a problem. Armed with this historical context, they can contribute meaningfully to the conversation. They can say things like ”Hey, we used to have this feature but we deprecated it for reasons X,Y,Z”. Or “Hey, we can do it this way but remember when we tried it this way and X, Y, Z blew up?”. Again, this skill proves itself in bringing focus and clarity to all involved parties. It proactively unblocks engineers and improves overall development cycle time.
An extension of knowledge of the product is knowledge of the user. The product manager should know their user better than anyone else. In fact, knowledge of the user and knowledge of the product should be mutually reinforcing. This part is harder for internal/infrastructure/platform product teams because the majority of their users are internal users within the company. It is a little unfortunate building products for which your users are mostly obligated to use. For example, If everybody on the marketing team in the company must use your bulk email automation product, then there’s not as much incentive to thoroughly understanding your users. The incentive to learn, and the learning rate is exponentially higher for product managers that manage products for which users are not obligated to use and for which competitive alternatives exist for the user. Regardless of the type of product – customer facing vs internal user facing – user knowledge is still very valuable.
Judgement of Value
A product manager should be able to judge the value of every past, present and future feature in the product. Value means various things to various people but the product manager should always index on user value. Good value judgement is what prioritization skills and its synonyms all boil down to.
Development teams are constantly bombarded with feature requests. Good value judgement is knowing that a lot of requests give zero, or sometimes, negative value to the user. Even things that seem very valuable at the surface are usually more valuable to the requester and only marginally valuable to the user. This phenomenon occurs more often in engineering heavy product teams. A product manager can sometimes get convinced to sign off on and devote resources to a “reduce technical debt” feature that adds zero value to the user. This is not to say that reducing tech debt is not important. But in the world of software, where almost every decision can be framed as a tradeoff, every code change is, by definition, a technical debt on a particular dimension.
Exercising great value judgement is incredibly difficult for less autonomous product managers who have to get almost every product decision signed off by a business stakeholder(more common in internal tools product teams). In this situation, value is usually defined by the stakeholder as they probably know more about their particular business area than the product manager. The long term result here is that the product manager is pushed down from being the judge of value to the executor of requests and features.
Nice to Haves
- Data Skills
This might rank higher for certain products or in particular industries. Personally, data skills(sourcing, querying, interpreting, visualizing) made it easier to for me to judge value of potential features, win arguments, and triage weird bugs. - Knowledge of Software Engineering Jargon
For this, one mostly learns on the job and may not be as important if the product manger’s role(or the product) does not necessitate it. But knowing engineering jargon helps one to not be completely lost in certain conversations.