Busting product management myths: Part 2 of 2

In a previous article, I had described five common Product Management myths and contrasted them with facts. In this part, we will continue the article to provide clarity on 5 more myths. Let’s get right into it.

A product manager’s only job is to decide what to build and when

Image credit: iconicbestiary

Fact: While this is a large portion of responsibilities, a product manager does have another critical responsibility of deciding what amongst the existing set of capabilities or products no longer provide sufficient value, and hence should be retired. Product capabilities can lose value over time because of fluidity in customer requirements, market conditions as well as product priorities. Retiring or deprecating capabilities is a massive responsibility, and when done well, it can set up both customers and product teams for success.

It can help drive focus away from less important capabilities that may have provided substantial value when they were first built, but not so today. This is also important because there is always a danger of customer/user backlash upon retiring existing capabilities. Hence, the product manager has to show immense empathy to customers when doing this, potentially by sending deprecation notices, guiding key customers away from such capabilities, providing alternatives, and so on. In fact, management at great product companies will also appreciate the efforts of a product manager towards retiring capabilities as a step towards streamlining, consolidation and paying off tech debt. Like for many other portions of their job, instrumentation and collection of usage metrics is often the first step in this process.

A product manager must be the biggest power user of the product

Image credit: aleksandarlittlewolf

Fact: In many ways, this is related to Myth# 5 (A product manager should be able to perform multiple roles all by themselves). It is true that the job does not end at specifying the requirements. A crucial part of a product managers’ responsibilities is to ensure that the product or feature is built per the specifications that they had defined. As such, they are the “gatekeepers” of the product, they ensure that the right product gets built. There is also a popular view that a product manager represents the user, and so must use the product extensively. While this is true, it doesn’t mean that a product managers’ usage of the product is a substitute for:

1. Automated and manual verification/testing by the engineering team
2. Periodic collection and mitigation of actual user feedback
3. (Optionally, and especially at larger companies) Independent end-to-end testing of the product by a dedicated quality assurance team

Hence, a product manager should absolutely use their product to the extent sufficient to ensure that the right product gets built. However, this should not be used as a substitute for other important activities and job functions.

Watch this ProductTank session on What Makes A Good Product Manager?

A Product Requirements Document (PRD) can be called “done” after shipping

Fact: Great product teams, and especially great product managers treat PRDs as living documents, for a substantial amount of time after shipping, if not until the product/feature is sunset/retired. This is especially true for PRDs of larger features and entire products. As one of my favorite authors and one of the most authoritative minds in Product Management—Marty Cagan of Silicon Valley Product Group—mentions in his book “Inspired: How to Create Tech Products that Customers Love”, product teams often go through a number of iterations before they land on the “right” solution. Hence, the first few iterations of implementation are unlikely to be the final solution to the problem described in the PRD. What’s more, for larger features, the product team may end up making trade-offs on the requirements due to a lack of sufficient staffing or pressures to meet deadlines.

As such, it is the responsibility of the product manager to continue to track the undelivered requirements and evolve the PRD as a live document. Through the development of the feature, it is important for the product manager to keep the PRD updated with decisions that may get made along the way. Even after a feature is delivered, an updated PRD is a critical resource since it captures the reasons why certain decisions were made along the way. This can avoid some unnecessary confusion and provide much-needed clarity when the team has to look back at some of the decisions in future.

Read: Don’t let your first PRD be your last

A product manager is the same as a product owner

Image credit: freepik

Fact: Recently, with the advent of Agile methodologies, a new role of product owner has been defined as a member of the agile team that oversees the execution through scrum or other methodologies. This role is often confused with the product manager role. It is important to understand that while there is some similarity between the two roles, a product owner really performs a small, but important subset of the responsibilities of a product manager. As I’ve stated before, tracking seamless execution is very much a part of a product managers’ job. They often work with project/program managers, and engineering leads towards this job. However, this is a subset of the overall responsibility, which is to set the vision/direction for a product, and influence a cross-functional team to ultimately solve critical customer problems.

Read more about product manager roles and hierarchies

You can organically grow all by yourself as a product manager on the job

Fact: So far, we’ve discussed myths about product management as a function. This particular myth segways into professional growth of a product manager. If you haven’t already realized it, product management can be a hard, high-pressure job. There are various reasons for this, not the least of which is that there is a lack of education (in academia) as well as the fluidity of the role depending on the industry, business and company size. It can often seem like a kitchen sink of responsibilities.

Great product managers deal with these challenges by maintaining an insatiable urge to learn. Although a lot of the learning happens on the job, as you deliver products, there is more to it. Product managers need to invest not only in growing their product skills but also keep a keen eye on the world around them to grow their domain knowledge and market dynamics.

Thankfully, today, a lot of resources are available for product managers to grow their skills. More importantly though, and I cannot stress this enough, it is absolutely critical for product managers to invest in finding the right mentors, and developing long-lasting relationships with them. There is no substitute to learning from face to face interactions with proven industry leaders, who have lived and breathed products for many years. Product managers need to continuously invest in themselves beyond their day jobs, to the extent of treating their career as a product and building a vision, strategy, and roadmap for it.

In this two-part article, I’ve attempted to provide my perspective on some common myths, misconceptions and half-truths about product management. By busting these myths, I hope you can get a better idea about what good product management boils down to. Although this is not an exhaustive list by any stretch of the imagination, hopefully it plays a small part in demystifying the enigma that is product management.