To state the obvious, product management is about managing products. Often, the product manager is described as the CEO of the product, expected to decide on everything that touches it. In practice, things prove to be significantly more complicated and product managers often spend a considerable part of their time on stakeholder management.
Previously, we discussed the feature level of product management, which is of course related to the product. Even if features are important, no feature makes sense without being integrated into a product. This post focuses on the product scope. Of course, this includes cases where multiple products are derived from a common platform.
Although it seems obvious that product managers are concerned with products, there are at least three main challenges they run into: the scope of the product, identifying the real customer need and balancing new features, architecture refactoring and quality.
The first challenge frequently comes as a surprise to people not closely involved in product management. Especially in large companies, it often is surprisingly difficult to draw a clear line around the scope of “the product.” Many customers have specific extensions and configurations, which results in a wide variety of versions, even if the company may view them as one product.
In addition, within the company, it’s quite typical to have an asset that’s managed as a single, configurable product from an R&D perspective, but that’s put on the market as a family of products. The challenge then becomes whether the product manager is responsible for one of the customer-facing products or the asset as it’s viewed by R&D. This can easily be exacerbated when a family of products is derived from a common platform as each product can have product-specific as well as customer-specific extensions. In addition, the configuration opportunities in the platform and each customer-facing product may cause a situation where thousands if not millions of configurations can be created. The challenge of product management is to constrain the space of possible products to those that make sense from a business perspective.
There often also is an organizational challenge as in these contexts, the amount of work rapidly exceeds the abilities of a single product manager. This then results in a product management team where each team member has priorities that don’t necessarily align with all the other members. In that case, achieving and maintaining alignment within the team often proves to be challenging as each team member has an alternative set of priorities.
The second challenge is concerned with uncovering the actual needs of the customer base. This is difficult for three reasons: noise, the gap between espoused theory and theory in use and the different needs of different customers and customer segments. First, there tends to be a surprising amount of noise when it comes to suggestions for new functionality. Everyone and their brother have ideas as to what to add to the product and many have their pet peeves that they’ve been peddling for a long time. Ensuring a proper assessment and prioritization of these requests is quite challenging.
Second, there’s ample research out there that shows that there’s a significant gap between what customers say they’ll do and what they do in practice. In the B2C context, we see many companies moving toward measuring customer behavior and by and large ignoring what customers say. However, in B2B contexts, product managers need to carefully balance what customers say and what they do. This is because the product is selected and acquired based on the customers’ perception concerning the product, but the day-to-day use is driven by actual behavior, which may be significantly different from what customers say. This is known as the “espoused theory versus theory in use” problem.
Third, products often serve different roles for different customers and customer segments. Although quite a bit of the functionality will overlap, there are a lot of cases where there are mutually conflicting desires and wishes. A typical example is the difference between expert users who want to be able to tweak and adjust every aspect of the product behavior and the users who are simply looking to get the job done as quickly and smoothly as possible and consequently want the simplest user interface without any bells and whistles.
Due to the above, product managers often struggle with uncovering the highest priority use cases and functionality and deeply understanding the real customer needs. In hindsight, it’s usually obvious what the right prioritization was, causing product managers to catch quite a bit of flack for failing to prioritize what turned out to be important. However, identifying and prioritizing this functionality before it becomes obvious is what makes the job of a product manager so complicated at times.
The third challenge is that every digital product needs three types of R&D activities: new functionality, quality management, such as testing and defect removal, as well as architecture refactoring. The first two are focused on the short term whereas the latter is focused on the long term. Product management is concerned with ambidexterity, meaning addressing the short-term needs of the product while safeguarding its future. However, finding the right balance is very, very difficult and generally, we see that the long term is sacrificed for the short term.
Finally, the product scope isn’t orthogonal but rather interdependent with the feature and ecosystem scopes. It’s easy to think that the company level should dictate the portfolio level and so on, but in practice, there are upward influences as well where features influence products and products influence the company. Also, inward influences from outside the company can have an effect at all levels.
Although product management is concerned with products, it often proves surprisingly challenging to demarcate the boundaries of the product and the various product configurations that are available. This is especially the case when there’s a platform involved in the equation. Second, identifying the real customer needs for prioritization of R&D activities is far from trivial for a variety of reasons. Finally, balancing the short-term activities of building new functionality and managing quality levels with the long-term activity of architecture refactoring and managing technical debt is far from trivial either. The result is that product management proves to be challenging in most contexts. To quote Thomas Schranz: “Good companies manage Engineering. Great companies manage Product.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
