The role of product manager is somewhat synonymous with the agile concept of “product owner” where you are the representative of the “customer” to the development team. The implication is that this is a role that channels the customers’ needs, desires, demands into the process.
What this doesn’t mean is that the product owner is the customer, substituting her needs/experience/knowledge for actual customer facing requirements, but instead represents the customer to the team. This is an important distinction, and one that is often overlooked. This is doubly true when the product manager is also the product owner in the scrum team.
This can be a difficult lesson for many product managers. A strong product person has plenty of empathy, and a demonstrated knack for getting in the customer’s head, and truly grokking the need. But this comes with the temptation to conflate your personal experience and beliefs with how the wider market reacts to the product.
Sometimes, this comes from years of interacting with customers, across multiple market segments, and the deep understanding of the use cases, and the microscopic level, intrinsic, domain knowledge that entails. That is good.
However, it is far more likely that this is merely confirmation bias, wishful thinking, and to be frank, laziness.
The hazard is that you are either listening to too few customers, or you are selecting customers that conform to your prejudices and ignoring dissenting views, ultimately using that cherry-picked data to base product decisions on.
Real world scenario
One case that the Dude knows of quite well, was one that he inherited the mess of. 4 years before he started with a company, the then product manager was defining the “Next Generation” of the product technology. The first generation was born out of a university research program, spun out into a successful startup, which then attracted a multinational company to buy them. Three years post-acquisition, it was time for a significant third generation product.
However, instead of a broad market survey, a deep query of customers (both existing, and potential customers), a cross competitor evaluation, and an honest assessment of the trends in the market (and the growth potential), the product manager looked at his pride and joy, the existing product, and set about making it better for his desired needs, ignoring the trends clearly underway to move from a research instrument narrowly focused on a specific niche, and towards a platform that met a growing industrial application space.
His blinders to the wider market needs ensured that he focused solely on making a better generation two product, chasing a market that was not, and hadn’t been growing for several years.
In this case, the blurring the lines of customers, and product management, lead to spending far too much treasure building a product for a shrinking market, and ultimately a failed product.
Lessons from the Trenches
This is often due to the product manager being deeply entrenched in the domain. All too often, a desired attribute for a Product Manager job requisition is to have significant domain knowledge and experience. This is usually a desire to shorten the learning curve, and in fact I have found that often recruiters will gloss over a weak (or nonexistent) background in product management to get the domain knowledge that the team claims to need. This is a mistake. As Rich Mironov often mentions that it is far easier for a technical, experienced product manager to pick up enough domain knowledge in the ramp time, than to build product management skills to someone with deep domain knowledge.
To avoid this, product management needs to add “humility” to their persona. Some are born with it, some need to learn it. Fortunately, this is fixable. Get out of the office. Talk to customers. Talk to your competitor’s customers. Talk to support (you’d be amazed at how much nitty-gritty detail they have.) Do market segmentation. Understand the similarities and differences between your segments. Don’t scoff at negative feedback. Remember, you are a channel for the information, not the source of the information and feedback. Otherwise, you are breathing your own exhaust.
