You got a problem? Capturing the Problem Space

Of all the mistakes I've seen product managers make over the years (including me!), not sufficiently understanding the problem their product solves is perhaps the one that troubles me the most. Innumerable conversations with colleagues, acquaintances and students has taught me that asking a product manager to concisely express the key problem their product solves results in several seconds of silence followed by a significant amount of stammering. I guess it's understandable: I believe the tendency to think about solutions based on little more than an intuition regarding a problem is baked into the human psyche (quick thinking probably helped us avoid the "jaws of death" on a regular basis). As a product manager, it behooves us to overcome this "rush to a solution" and make sure that we not only understand precisely what problems our product address, but that the problem is expressed in a way that others can understand it too. In this post I'll talk about clear separation of problems and solutions and suggest a method for describing a problem holistically.

Allow me to begin by differentiating between the problem space, that is, a mental representation of a problem and its various states and the solution space, in the context of software products, the set of solutions that solve the problem. Keeping the problem and solution spaces separate is critical for a variety of reasons:

• Without understanding the problem space thoroughly, we may inadvertently only solve part of it or even solve the wrong problem
• For any given problem, there are typically multiple solutions. Picking the ideal solution in a given context can mean the difference between a successful product and one that fails (sometimes miserably)
• Taking a structured approach to this distinction can help us identify new problems that may be addressed by our solutions, uncovering opportunities to create customer value  far greater than we ever imagined.

If the problem space is a mental representation, a fair question would be how we can capture it so that others can grok and reason over it. Although there are plenty of templates for "problem statements", I find them insufficient. I feel so strongly about clearly capturing the problem space that I invented a "problem profile" that I believe provides critical information that cannot easily be captured in a simple statement. Whether you've identified a specific problem, have backed into one by imagining a cool solution or have an "old" solution at hand, capturing the following information regarding problems, a set of which can be thought of as being comprised by a problem space, can be an enlightening experience. The attributes of a problem profile are:

• Problem statement: A succinct representation of the problem that can be widely understood, capturing the what, who, when, how and why of the problem.
• Stakeholder pain: An articulation of the pain experience by problem stakeholders (typically a decomposition of "the who" from the problem statement)
• Supporting facts: Information relevant to the problem that proves or at least underscores its existence. The more quantitative the better
• Causes: The factors that contribute to the existence of the problem. This attribute is very important as often, the first problem we encounter is not the root cause of the stakeholder pain. Playing Five Whys can help here.
• Desired state: The desired state is the minimum set of conditions that must be satisfied for the problem to be considered solved. To the experienced eye, these conditions often appear to be high level requirements (they are!). These conditions will be used when evaluating alternate solutions to ensure that each indeed solves the problem
• Constraints: A constraint is an assumption that in effect reduces the solutions space. Constraints are important input to the solution definition task in that it helps to exclude solutions that aren't acceptable for reasons defined by the constraint. Constraints should be used very sparingly as they (obviously) have the effect of excluding solutions that might be outside our comfort zone.

Find below an example I created describing a problem I have experienced in real life.

Given my background, an obvious solution would be an app that provides parking information (I spent a few years working in the area of "smart cities"). However, who's to say that the obvious (to me) solution is actually the best one? Without a thorough analysis of the problem and all reasonable solutions, there's a good chance there will be a mismatch, even it it's partial, between the problem and the solution I design to solve it.

In future posts, I'll discuss how problem profiles can be used, including developing great products (and a reiteration of how I believe product management relates to the problem and solution states).

What do you think of the problem profile I've defined? Do you use something similar?