“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.” — Albert Einstein
In our eagerness to solve a problem, we can often shoot ourselves in the foot. This is because we typically take a cursory glance at the issue at hand, and immediately start applying our favourite methods and tools to it. As a result, we end up with narrow questions, shallow reasoning, and ultimately, an uninspired attempt at a fix that fails to solve.
To find a fix worthy of being called a solution, we must first invest in understanding the scope of the problem. Scoping a problem enables us to develop a working model of how things are. This understanding of the current state becomes the baseline, the starting point from which you and your stakeholders determine what needs to change.
The value of scoping a problem is realized through the creation of an actionable problem statement. An actionable problem statement is one that frames the issue in a way that enables you to formulate and test a falsifiable hypotheses within the given timeline, budget, and scope. In essence, it is framing the problem so it can be answered definitively.
Diving into research and analysis with a vague problem statement will lead to long, fruitless hours and frustrated clients. So how can you avoid a weak problem statement? Ensure you incorporate the following key components:
- Specificity: an actionable problem statement takes aim at a particular issue. No ocean boiling.
- Clarity of decision maker criteria: what information do the decision-makers need in order for them to select a path forward?
- Clarity of contextual constraints: capabilities of existing infrastructure, the political landscape, laws of physics…
- A plan of action for what happens if/when the problem is solved: Once this problem is solved, what will you be enabled to achieve? What is the immediate next step?
- A timeframe or required level of accuracy to consider the problem solved. For example, a go/no-go decision must be made by the end of the quarter, or, the projected cost savings must be accurate +/- 20%.
In its simplest conception, to scope something is to create a mental model that enables us to build an estimate. To build an estimate, we must be able to recognize the shape of the answer.
While this list of key components may not be a universal checklist for every possible problem space, it is a surprisingly versatile framework. To illustrate, let’s walk through a simple — but important — question from everyday life: What should we have for dinner tonight?
Scoping for Dinner
As with any good recipe, we’ll walk through this step by step:
- Specificity: Breakfast and lunch are decidedly out of scope; we will not entertain any “cereal for dinner” nonsense here.
- Clarity of decision-maker criteria: To make the best possible choice, we’ll need to answer questions like how much the ingredients cost, how long it takes to prepare them… and let’s not forget user experience — will we find it tasty?
- Clarity of contextual constraints: we don’t have a microwave, so the capabilities of existing infrastructure eliminate the frozen dinner option. But we don’t want to spend more than an hour in the kitchen.
- A plan of action for what happens if/when the problem is solved: We plan to execute on the grocery shopping and recipe-following to make ourselves a solid meal that will satisfy our most important stakeholders — our stomachs.
- A timeframe or required level of accuracy to consider the problem solved: The end of the day is approaching quickly, so we’ll need to decide within the next 30 minutes. We’ll aim for an hour in terms of cook time, +/- 15 minutes, so that we’ll finish in time to workout (or watch the next episode on Netflix) before it’s time to hit the hay.
Great! We’ve now established the key attributes of a dinner that will solve our hunger problem. Having successfully scoped the problem, we can create an actionable problem statement:
“How might we make a tasty, fresh dinner tonight so that we have time to exercise and still get a good night’s sleep?”
Next comes the fun part: generating hypotheses. Our initial hypothesis might be that homemade macaroni and cheese is the right dinner for tonight. This testable hypothesis is useful not (only) because it’s a delicious proposition, but because it serves as a good starting point for our investigation. It is a supposition based upon limited evidence — our colleague once made a half-decent home-made macaroni and cheese — and it can be proven wrong through further analysis. If we’re honest, most starting hypotheses are not much more empirical than that.
It would be unsurprising if, after reviewing the cost of cheese and estimating the time it takes to prepare, we decide to abandon our original hypothesis. Indeed, given our constraints, we might pivot towards a solution with more streamlined implementation: Kraft Dinner.
And there’s nothing wrong with that — our decision-making criteria did not set a high nutritional bar. Our priorities were speed and tastiness. By our own definition, we have found a solution! Now it’s all about the implementation… But before we move ahead into the next phase, let’s dig a bit deeper into the value of scoping and the relationship between problem statements, hypotheses, and solution development.
How to Maximize the Value of Scoping
The value of properly scoping any problem lies in the formulation of the problem statement. There are plenty of interesting problems we might like to explore, but our resources are not always as expansive as our curiosity. By being thoughtful about the way you ask the question — and formulating a precise problem statement — you afford yourself the opportunity to influence the type of answer you’ll get.
Answerability is the key to unlocking the value within a properly scoped problem.
As we’ve noted before, a useful problem statement is one that frames the issue in a way that enables you to formulate and test a falsifiable hypothesis within the given timeline, budget, and scope.
So, what is a hypothesis?
Google tells us that it is “a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.” And by falsifiable, we mean that a hypothesis can be refuted or even proven wrong by marshalling evidence to the contrary.
What’s the value of the hypothesis?
If we can test the hypothesis, we can provide a substantive answer to the original problem statement. And this is the most important proof point of a properly scoped problem: the possibility of solving it.
Without a testable hypothesis, the team is effectively engaged in a never-ending discovery process. Great for uncovering new areas of opportunity, less great for delivering results. Once we’ve arrived at a clearly defined hypothesis, the team can move on to testing that hypothesis.
Remember: while success is always preferable, failure also counts as a result!
In Lean Startup terms, it’s helpful to think of a hypothesis as the foundation of a Minimally Viable Product. The MVP seeks to solve for the original problem, but even when it fails to solve, it succeeds by generating validated learning. The expectation is that the MVP will require further improvements in the form of iterative build-measure-learn cycles.
A note on dynamic systems
It’s not always possible — or even desirable — to frame the problem so precisely. Sometimes the problem itself emerges from a dynamic system that changes over time. Dinner plans can change as we discover new recipes, new options in the grocery store, and surprise dinner guests. In cases like these, the problem itself evolves alongside with the system it is embedded in.
However, even in dynamic environments, it remains necessary to understand the size and shape of the problem you’re trying to solve. If anything, scoping becomes more valuable when the landscape is shifting quickly.
The adjustment in approach is one of scale and frequency. If you expect the nature of the problem to evolve, it is prudent to:
- undertake a less exhaustive approach to problem discovery, and
- re-engage in the scoping process through continuous cycles rather than as a fixed gate.
In dynamic and complex problems call for a dynamic but simplified approach to scoping. Ultimately, you want to afford yourself the opportunity to learn something about the problem and the wider system. The sooner you scope your problem, the sooner you can test your hypothesis — and the sooner you can learn from the feedback. The sooner dinner is made, the sooner we can find out if it’s any good.
Wrapping Up
So why does scoping matter?
Let’s answer that question with another question:
Can you answer an unanswerable question?
It is terribly difficult to solve a problem that has not been formulated.
Scoping a problem facilitates the creation of a good problem statement, which in turn enables the creation of a testable hypothesis. This hypothesis forms the foundation of the MVP, sending you down a path of iterative learning and improvement towards the ultimate goal: solving a critical problem for your users.
Scoping a problem empowers you and your team to know when you have solved it.
“A problem well stated is a problem half-solved.” — Charles Kettering
