Beyond Problem and Solution Space: Better models for modern product development
I often encounter the phrases problem space and solution space. People use these words to try and articulate the types of work and activities they are referring to, or where they are in the process of building something new.
Unfortunately, rather than aiding communication, I notice that these words are so highly ambiguous that more time is spent debating what they mean than is gained by using them to improve communication and collaboration.
A John Cutler says: “Be aware that the problem vs. solution dichotomy isn’t all that clear. It sounds good. But there are many cases where it isn’t very helpful.”
For these reasons, I’ve stopped using the terms problem and solution space. In this post, I’ll summarize better models suited to modern product development from leading product voices like Marty Cagan, Teresa Torres, John Cutler, and Indi Young.
Problem, Strategy, and Solution Spaces
To gain clarity on the terminology, it’s helpful to describe the various activities involved in building a product, which can then be grouped into buckets like problem and solution space or something else.
An excellent piece of work to start with is Indi Young’s problem, strategy, and solution space model. Indi provides a precise definition of each space including the types of activities that fit within them.
Problem space in Indi’s model is “a person’s domain… separate from your solutions”. Activities here involve building up a big picture of people and their needs through techniques like listening.
Indi’s strategy space is where an organization intentionally makes decisions about which user needs it wants to solve and what types of products/solutions it will develop to address those needs.
The solution space is then broken down two parts — discovery and development, which is akin to what used to be called dual track agile. Discovery is about building hypotheses and testing ideas to put into a backlog while development is working through that backlog to build new features.
Augmenting Indi’s model
To aid clarity further, there are a few additional tweaks I propose to Indi’s model. The first is the clarification between problem discovery and solution discovery, which Marty Cagan explains as the difference between validating a user need and exploring solutions that will address it.
Marty’s definitions appear to fit nicely with Indi’s definitions of problem space and product discovery (the first half of her solution space).
In my work, I often encounter software developers who refer to the software as the solution space. Requirements are their problem space (e.g. the backlog) and implementing them in software is the solution. But that’s not consistent with other models, and I think a better name for this is the implementation space.
From problems to opportunities
I’m a big fan of the work Teresa Torres does in the product space. I think her framing of opportunities instead of problems is a better fit for the work we do. Not all of the work we do addresses a problem that people have.
In the product world, we don’t just solve customer problems. The word “problem” implies something needs fixing. However, we have many examples of products or services that don’t fix problems.
— Teresa Torres (via producttalk.org)
Teresa is the creator of a tool called the opportunity solution tree. It’s a model that connects desired business outcomes to opportunities, solutions, and bets. Teams can use the tool the visualize and plan their work, and therefore the model is actually usable.
If you are a software developer, remember that the solution is not just the implementation — it is the whole concept to address an opportunity.
Mandate levels
One of my favourite pieces of work in this space is mandate levels by John Cutler. It’s a tool for determining the scope or limit of a team’s autonomy which is broken down into 9 levels, from having full autonomy to build and discover whatever they want (level I) to being told exactly what to build (level A)
A team’s mandate level can have a big impact on what they perceive as the problem space. For example, if a team works in a feature factory having only mandate level A (told exactly what to build), they only have autonomy in the implementation space and may therefore perceive solution development or solution discovery as the problem space.
Mandate levels is an easy way to quickly escape from confusion arising from problem and solution space. You can simply present the mandate levels diagram and ask people to pick out which level they are referring to when they talk about problem space, for example.
Hope you find this useful
I wrote this article mainly for myself so that I can share it with others when the terms problem and solution space begin causing confusion. But I hope you find it useful.
Let me know if you disagree with anything or have further improvements to propose.
And remember, when you use the terms problem and solution space it conjures up many different thoughts and perspectives, so use them carefully or use a better model that more precisely conveys your intentions.
