Lost in space(s): Does product management address the problem or the solution space?

In discussions regarding the roles of various disciplines in product development, it's not uncommon to hear folks differentiate between the problem space and the solution space. While the distinction between these concepts is reasonably clear, mapping them to product development roles is not always as straightforward, especially as it relates to product management.

As its name implies, the problem space comprises the information relevant to a problem. In the context of product development, we can think of the problem space as the set of customer problems we plan to address with our product (a problem is simply an undesirable situation). Understanding the problem space is critical in the context of both new product introduction and existing products. Problem space understanding for new products helps ensure you are solving a real, as opposed to perceived, problem. It's also the first step in determining if you've identified a problem people or organizations are willing to pay to solve at a price point that can sustain your business. Understanding the problem space for existing products is important as typically, the problem space is not a static concept: it changes over time as markets evolve. I talk a bit about the risk of neglecting the problems space later in this post.

The solution space comprises all the products and solutions that can solve problems identified in the problem space. If I'm feeling pain around opening beer bottles, a bottle opener is a potential solution and thus included in the solution space. It's important to note that a given problem can often be addressed by multiple, wildly different solutions. A lingering but apocryphal legend contends that two radically different solutions were found for writing in zero gravity during the Space Race: a sophisticated pen with pressurized ink (NASA) and a pencil (Soviets).

Treating the problem and solution spaces differently is important or even critical as it can help avoid the common human tendency of conceiving of a solution and then trying to find a problem it can solve. This trap is especially evident in the world of software as development costs can be relatively low and production costs are almost non-existent (producing CDs/DVDs or placing an installable version on a server tends to be a fraction of what producing physical goods often costs). Separating the two can also inspire teams to find creative solutions to problems, sometimes at much less cost and effort than more obvious solutions.

Understanding the evolution of the problem space over time and the solutions available to your target markets can help you respond more effectively to customers' changing needs and the changing environment in the market. We need look no further than household brands such as Blockbuster or Blackberry to find companies that apparently didn't fully understand the problem space sufficiently and failed to develop new solutions that were compelling in a changing technological landscape. Blockbuster may have been focusing on making renting DVDs simpler and less expensive when their customers' real problem or need was watching movies at home with as little effort as possible.

If we consider the various disciplines involved in software product development, some are easy to map to the problem/solution paradigm. Engineering, for example, is primarily involved in the solution space, actually developing the solutions that are taken to market. Other disciplines such as marketing often span "the spaces", providing insight on problems faced in the market and describing the key characteristics of possible solutions, sometimes based on solutions already being offered. Understanding where product management falls relative to the product and solution spaces is the subject of more debate. There is a camp that is of the opinion that product management's sweet spot is in the problem space, leaving engineering to define the appropriate solution. Others feel it's critical that product management, especially software product management, keep a foot planted on both "sides". Based on my worldview and painful experience I am an unflinching proponent of the latter.

I see product management as a critical bridge between the problem and solution spaces. I base this assertion on a couple of assumptions:

1. First-hand, intimate knowledge of the problem space is required to define a compelling solution
2. The solution space must be continuously shaped by professionals with a functional, rather than a technical, perspective.

I think the idea of product managers helping to define the problem space isn't particularly controversial. Without a thorough understanding of the problem you're solving including empathy for the consumers of your solution, identifying the optimal solution becomes almost a matter of chance. In some organizations, marketing also plays a role in defining the problem space. However, in my opinion, detailed knowledge of the problem space is simply too critical for product management to consider "outsourcing" problem space definition entirely.

The second assumption is a bit less obvious. As I've described in a previous post, the functional perspective addresses solutions from the outside in, with relatively little regard for the technical implementation of the solution. The technical solution addresses how a solution is actually developed or implemented. Staying on track throughout a development cycle requires establishing a delicate, ongoing balance between the functional and technical perspectives. Product managers must define in detail what the solution must do. Development takes this definition as input and defines how it will be implemented, e.g., using which technologies. While most engineers are creative people with great ideas, their clear focus should be implementing things as quickly and robustly as possible, not defining how an application should behave. Since the UI is very often critical in terms of product usability and success, development should also get direction from another functional discipline: UX. If we take a simple example of a weather widget for the desktop, PM and UX should define its height and width, what information is displayed, what colors are used, customization options etc. Development's job is to create the widget with high quality and perhaps with enough flexibility that it can easily be adapted over time.

A common mistake is to confuse the functional and. technical perspectives with levels of detail. I've heard more times than I can count that product managers define products at a high level, with development filling in the details. The truth is, there are varying levels of detail from both function and technical perspectives. I contend that product managers need to define products with a high level of detail but from a functional perspective. Although in some cases development has sufficient awareness and willingness to define the details correctly, more often than not their technical perspective will result in solutions that aren't optimal for the non-technicians that must use them (assuming the primary users aren't developers or architects). Product management and other disciplines such as UX must provide continuous guidance and advocacy for stakeholders at a level of detail that ensures that the product doesn't end up being something only a developer would love. Once again, I speak from painful experience on this topic.

In my experience, the key to defining compelling solutions that meet or exceed business objectives over time is creating a bridge between the problem space and solution space, not lobbing requirements over the chasm and hoping technicians build what you expect. I've seen this approach fail (first hand) so convincingly that I now reject it prima fascia. In my experience, product management must build this bridge and straddle it, continuously shaping the solution based on their evolving knowledge of the problem space, their experience and their knowledge of stakeholders.

It is also important to create the right balance between the functional and technical perspectives. Marketing should help define the problem space but at the level of high level requirements. PM (with the help of others like UX) should focus on what should be built, freeing engineering to focus on how the solution should be implemented.


Next post: Hitting the ground running as a new PM