Problem Space and Solution Space

An extremely fundamental concept that is influencing most of my thinking around software projects is the distinction between the problem space and the solution space. It is one of the best models that I have found so far to think about the software development process on an abstract level. In this article, I would like to illustrate the concept and highlight some examples.

One of the people that popularized the concept is Dan Olsen. Here is his definition from “The Lean Product Playbook”:

Any product that you actually build exists in solution space[…]. Solution space includes any product or representation of a product that is used by or intended for use by a customer. It is the opposite of a blank slate. When you build a product, you have chosen a specific implementation. Whether you’ve done so explicitly or not, you’ve determined how the product looks, what it does, and how it works. […]

[P]roblem space is where all the customer needs that you’d like your product to deliver live. You shouldn’t interpret the word “needs” too narrowly: Whether it’s a customer pain point, a desire, a job to be done, or a user story, it lives in problem space.

Dan Olsen, The Lean Product Playbook, Chapter 2

Olsen provides many examples of points in problem space: Taking notes in zero gravity, securely and quickly unlocking your phone, or filing your taxes to cite a few. We could add anything else that can be formulated as a need: Preventing a meltdown in a nuclear powerplant, finding the closest fast-food restaurant, or predicting next year’s fashion trend.

Any point in solution space corresponds to something you can build. A concrete product implementation. As engineering teams, we spend a lot of time finding points in solution space meaning designing, architecting, and engineering software products.

Projections Between the Spaces

Connecting the problem space and the solution space is where the magic happens. This is where value is created. A solution s can be connected to a problem p if s solves p. The problem p could be “remembering which groceries I need to buy” and a matching s could be a shopping list app.

There are some important facts about problem-solution mappings that I would like to point out:

Firstly, for any point p in problem space, there are many points in solution space that can be mapped to p. For example, you can solve the problem of taking notes using pen and paper or a voice recording device.

The converse is also true: One single solution might address several needs. Pen and paper can be mapped to both filing your taxes and to taking notes.

Let us call these respective sets projections: The projection onto problem space P(s) of a solution s is the set of all problems that the solution s solves. Conversely, the projection onto solution space S(p) of a problem p is the set of all solutions that solve problem p.

Taking this one step further, we can also talk about the projection S(P) of a set of problems P into solution space: The set of all solutions s such that there exists a p in P with s in S(p). More intuitively, the projection S(P) can be seen as the set of all possible solutions given what we currently know about the kind of problem we want to solve.

This gives us a structured way of describing what it means to narrow down a problem: If P includes “taking notes”, then a regular ball pen is part of S(P). However, if P is narrowed down to only include “taking notes in zero gravity”, this solution is ruled out, because regular ball pens need gravity to work.

Clearly, the narrower we define a subset of the problem space P, the smaller the set of candidate solutions S(P).

Another important observation is that the mapping between problem space and solution space is not a continuous function: If two points in problem space p and p’ are very close to each other by some measure, this does not necessarily mean that S(p) and S(p’) have a lot of points in common. This explains why, when business people ask engineers for estimates during a roadmap exercise, the conversation is often difficult. The engineers usually come back with a ton of detailed questions. However, during early planning, all that is known is a vague area somewhere in problem space. If this area is narrowed down one way, an easy solution exists. If it is narrowed down slightly differently the team might end up on a 5 years-long research project as the following XKCD classic aptly points out (ignoring the fact that the example is slightly out-of-date):

The Importance and Challenges of Navigating Problem Space

One of the premises of the Lean movement is that generally, not enough attention is being paid to identifying the right point in problem space. This leads to the creation of products that fail to address any real underserved need and hence end up not delivering any tangible value.

One of the reasons is that navigating solution space is comparatively straightforward. We have good maps at our disposal. Once we know what we want to build, there are recipes available: If you are asked to build a mobile app there are a couple of questions you know you can ask to select one of several standard implementation strategies. Should it be cross-platform? Do users need to authenticate? Does it need to perform intensive graphical computations? Depending on the answers you can quickly zoom in on a fairly small subset of the solution space.

To navigate problem space we have not nearly as many straightforward tools. Market analysis studies could be seen as one such tool. However, they are more on the level of larger trends and insufficient to identify a specific point. You can conduct interviews with your target audience but that approach suffers from the fact that often people simply do not know themselves what they need before seeing the solution.

A cynic might say that in practice, the way that problem space is navigated is having the highest-paid person in the room point to a location, a phenomenon prevalent enough to receive its own abbreviation: The “highest-paid person’s opinion” (HiPPO).

Lean techniques can be seen as a strategy to probe the problem space by finding the least expensive point in solution space (the MVP) that allows obtaining important information about an area of the problem space.

A neat example of this is the concierge MVP that Eric Ries proposes in “The Lean Startup”: Instead of implementing an expensive scalable technical solution that solves a given problem, you temporarily implement it as a human in a box. The point is to set this up as an experiment that probes an area of the problem space. Are people signing up for your service? Is this a real need?

Quality Metrics of a Mapping

Not every solution s in S(p) will be equally well suited for solving the problem p. There are several dimensions that you may want to evaluate a problem-solution mapping against. Cost is likely going to be one of them. But there will be many other metrics depending on the exact strategy you are pursuing: Performance, ease of use, time to market, …

Naively one might think that this turns the exercise into some kind of optimization problem: Find the s in S(p) such that the cost is minimized.

The issue is that many of these metrics are difficult to estimate without actually doing the work and it is easy to get lost in trying to establish an accurate estimate of the cost of a solution whilst not knowing if you are even working on the right problem.

The Goal of the Product Team

Imagine you were able to identify an underserved need to target in problem space. Then, the product design and engineering process can be described as identifying a mapping between problem space and solution space while balancing out the relevant metrics.

So when setting up your team you want to maximize the probability that a connection between a valuable point in problem space and a point in solution space is formed.

Looking at it that way it makes intuitive sense that the best way to do this is to bring people with good knowledge of the solution space together with people that deeply understand the problem space. People that know the solution space are your engineers, data scientists, and interaction designers. The people that can spot the technical opportunities. The people that best know the problem space are your customers and people with access to relevant data. Finally, there is product management who, I think, needs to play an important role as a guide in this interaction and in making sure that the focus does not become too narrow.

This also makes it apparent why it is so important to avoid a game of Chinese Whispers in which the need is formulated at one end, then passed over several desks, and then only arrives at the other end where a solution can be designed. This setup makes it very hard to find the most appropriate problem-solution match, simply because a quick exchange of the two parties most central to the process is not possible.

Looking at it that way directly leads to Marty Cagan’s critique of how Software Projects are often organized.

Conclusion

As shown in this post, I think that the concept of problem spaces and solution spaces is a useful abstraction to think about the software engineering process. Of course, I am handwaving away several caveats and ignoring some exceptions just as much as there are other phenomena that I think this concept illustrates rather nicely. I will save all of those for upcoming posts.