The amount of wasted effort in the US economy is enormous. This game console / fried chicken warmer. Cosmetology school. All those low-cost ventilators that never got emergency use authorization.
In no way do I look down on the people who make those decisions. We’ll go into some of my personal failings in a bit. It’s just often under-appreciated that picking the right problem to solve is often more important than solving the problem itself.
Ask anyone at a school or career transition, or a team starting a product design effort, or a policy maker. There are good career trajectories, product ideas, and policy efforts, and there are bad ones. At the outset it’s very difficult to tell the difference, but it can be made much easier if you are careful about the problem you’re trying to solve.
A lot of digital ink has been spilled on the topic of iteration, agile methodology, failing fast, etc. These techniques are meant to quicken the introduction of new and necessary information into the design process, and I’m not going to spend more time here espousing the benefits of doing that. What has been given less attention, however, is the step right before that one: problem definition. Once you’ve decided what problem to solve and started to characterize it, you’ve destroyed the vast majority of the white space in your project. Once you’ve started a degree program it becomes expensive to switch. Once you’ve started designing a new ventilator you’re unlikely to spend time working on licensing existing tech, or PPE import and education.
Making matters worse, once you’ve decided the problem you want to solve, you’ve begun to expose yourself to all kinds of bias. Some solutions are more fun to build than others. Some are easier to imagine because they’re more like things you’ve built before. Some are more cognitively available because you’ve seen similar work recently.
You have limited resources and limited time to allocate them. How should you utilize the high possibility early project stages to maximize impact, profit, and welfare?
How does problem definition happen now?
At the core of why this is hard to do well is the fact that most people are uncomfortable without constraints. It’s much easier to assume a problem and begin brainstorming solutions than it is to define the problem itself.
Constraints are part of life. Capital and time are limited, your company has core competencies, etc. Where many teams get tripped up, however, is in assigning constraints arbitrarily. You’re not constrained by what your competitors are doing. You’re (hopefully) not constrained by what your client thinks the problem is.
Arbitrary constraint application can be especially egregious when someone on the management team decides to take a crack at solving a problem because of some personal insight. Insight, vision, and creativity are for solutions, not problems. In “The Mom Test” Rob Fitzpatrick states, “you aren’t allowed to tell (customers) what their problem is, and in return, they aren’t allowed to tell you what to build.” It’s unlikely that you are your customer, and even if you are you‘re basing your decision on a sample of one.
Another way problems are chosen is wishful thinking or motivated reasoning. It’s tempting to start with a problem you want to be solved, like climate change or medication non-adherence, and then move on to the next phase the design process. The biggest issue with this strategy is that it’s likely to suffer from scope mismatch. It’s unlikely that you have the resources and capability to make a dent in big social issues.
There’s another, more subtle flaw present when you start with yourself as the motivating factor. Who are your users? Who actually experiences the problem you’re trying to solve? By not having a specific group of people to work with, you’ve hamstrung yourself when it comes time to list your stakeholders, test prototypes, and determine a business model. Your motivation for selecting the problem has turned into a process bias that is extremely difficult to work around.
So problem definition shouldn’t come from you, your boss, the client, or your competitors. Here are three places you can look to select a good problem.
Technique #1 — Ask Your User
If you’re looking for one weird trick to make sure you’re solving the right problem, this is it: stop thinking and listen.
Almost by definition listening is the only way to learn things, and yet user research and observation, the beating heart of human centered design, are seldom practiced well. Maybe you are that rare individual with unique insight and ability, but the beauty of human centered design as a process is that it can give anyone access to insight without prior knowledge.
It’s still easier said than done. It requires empathy and careful observation to see user needs that are not directly expressed, which are the ones more likely to generate novel value. Designers call these “latent needs,” and they’re the holy grail of design research.
Before OXO’s innovation, it was a latent unmet need that cooks wanted to be able to see the measurement from above
Above I use the language of product design, but the same process can be abstracted to other fields and areas of life. You can even design your life. Well, all of us are designing our lives, but you can apply these tools to do it better.
Latent needs and user research in general are a critical step in the problem definition process, but they suffer from one weakness, which is that you have to assume a user to start. You’re going to get a sense of the problems of the people you choose to talk to, which may or may not be the problems you want to solve.
A famous example of this is 2007 Nokia. At the time they manufactured 37.8% of all mobile phones globally, and had strong standards of user research. The problem was that Nokia’s users themselves were constrained by the imaginable solution space at that time. In early 2007 no user would have told you about apps and massive touchscreens as things they wanted, until the iPhone came out later that year.
Designers now have better tools for accessing those magical “what if” scenarios, but the sentiment remains. You can’t rely solely on users to define your problem for you.
Technique #2 — Identify Meta-Problems
Even if you understand your customer, it’s still possible to drop the ball strategically. In 2015 I co-founded the first escape room venue in Providence, RI, and we made a killing. So, I raised a bunch of money and opened seven more venues around the country. The problem that we chose to solve was meeting demand for escape room venues.
This turned out to be the wrong problem.
The new venues were by-and-large just as good as the first one. People came and had just as much fun as they ever had. However, the strategic landscape had shifted. The market was much more crowded in 2017 and the novelty of the experience had started to wear off. We were fighting an uphill battle from the start.
Perhaps one could frame this dynamic as a changing set of user needs, but conducting user research to evaluate the degree of novelty experienced by our customer base would have been…tough. Impossible, for our small team.
Some markets are just terrible. Some are capital intensive, have huge regulatory burdens, or are fickle. That’s not to say those problems are not worth solving, but it’s worth being honest going in about whether you’re able to manage those risks and constraints appropriately before you start designing solutions.
Market strategy is actually just one example of a meta-problem — a problem with the problem. These can be difficult to identify without experience in the space, but just knowing to think about them can be helpful. As early as possible, think about what it might mean to execute on a project, and how things might go wrong. Here are some other examples of questions that might reveal meta-problems:
—How much might your users need to change their behavior if you were to solve this problem? Behavior change is hard, and some behaviors are deeply ingrained.
—Might many solutions to a problem rely on network effects or virality? If so, you could experience cold start problems.
—What are the public optics of the problem? Political exposure can be difficult to manage.
Technique #3 — Address Your Biases
I love this post from Paul Graham — The Lesson to Unlearn. I recommend you read the whole post, but the gist for our purposes is the following. Throughout our lives we have been trained by a highly structured system of incentives to perform well on tests. Acing the test is always rewarded in lieu of (and often at the expense of) learning the material. Appeasing your boss is rewarded in lieu of (and often at the expense of) doing the best thing for the company.
I don’t want to be too hard on teachers and bosses. Designing incentives is devilishly hard. However, the result of our being bad at it is that we’ve collectively lost our ability to distinguish between value and the way value is evaluated. This is a potential source of bias for designers. Are you hacking a bad test? Are you building the flashy thing that will make a good rendering for the client?
I think most of what Paul Graham refers to as “hacking a bad test” can be rephrased as “approval seeking,” which points us to how you can effectively label, isolate and deal with this bias. Who are the people from whom you want or need approval in your project? What are their motivations and how might they influence you? Some of them you may have already identified as formal stakeholders, but some of them will not be obvious without this framework. For instance, in order to draw prestige a designer may prefer to work on a product that utilizes a flashy tool like deep learning, even if it’s not strictly necessary. You probably don’t often have “design team’s future employers” listed as a stakeholder.
Other biases can be mitigated in the same way. By listing and labeling the things that influence you, you don’t stop them from influencing you, but at least you can lay out all of the boxes you might be thinking inside and evaluate how much effort you want to spend stepping out of them. Here are some common biases you may want to consider evaluating:
—Availability Bias — Recent exposure to an idea makes it come to mind more readily.
—Normalcy Bias — We tend to assume that things will stay as they are or trends will hold course. Aka “black swan risk.”
—Bandwagon Effect — We assume things are a good idea just because they have popular support.
—Confirmation Bias — Our pre-existing assumptions about a problem or solution make us more likely to look for information to support those assumptions.
—Zero Risk Bias — We tend to reduce small risks to zero in our minds, which, depending on the risk, may or may not be advisable.
—Survivorship Bias — We tend to focus on the data, users, and other information we do have access to, when what we don’t have access to can be just as important.
It’s not a formal cognitive bias, but I think it’s also worth listing and questioning what personal preferences you have. You probably are more interested in solving problems that align well with your skill set, which may or may not be appropriate in context (I personally suffer from a bias towards hardware solutions.) Some problems will also simply be more enjoyable or novel, which likely does not correlate with their quality.
This process, and all design processes, are meant to be tools to achieve more optimal solutions to the problems of the world. However, it’s worth considering if all things should be optimized, or rather if it’s always worthwhile to spend the time to optimize them. If you’re a product design team at a company, you‘re likely optimizing for profit, growth, sustainability, etc. But there are many things for which optimization is a poor fit. It could be that you want to work on something spontaneously and impulsively, for your own enjoyment. It could be that you are operating under political constraints where taking a broader view isn’t possible. Trying to build all externalities into the problem definition process may give you a more complete picture, but it may not be worth the effort. Sometimes you just want to make weird food.
-Ethan