There are several ways to solve a problem: the 7-step McKinsey framework, design thinking, the 5 Whys, root cause analysis, etc. Despite well-established frameworks, why do most people and organizations fail to solve problems holistically? It's because of ill-defined problems.
Problem definition is difficult because every situation is unique, and the templates available online often feel forced or ill-fitting. The issue with this approach is that it assumes you already understand the problem and are simply documenting it for others. But these templates rarely guide you on how to define the problem in the first place.
The "C-S-O" Framework
The first question is: When should you use a problem definition framework? Ideally, from Day 1 of your project. But don't get married to the problem statement on Day 1. It will evolve. Sometimes the entire definition might change as new data and insights emerge. Once you accept this, use the following framing:
C — Context
Understanding context means getting to the background of the problem:
- Why are we even talking about this
- Who asked us to solve it
- Who is impacted by it
- Are there key considerations or constraints (e.g., budget, time)
Can you answer "What are we trying to do here?" to your CEO in 30 seconds?
S — Sizing
This is the most critical — and most overlooked — aspect of problem-solving. Here, you define the scope. It's easier said than done.
Say a particular product is struggling with sales in the market. If you're focusing on solving the pricing issue based on your hunch, you've already "sized" the issue as a pricing problem. But maybe the issue lies elsewhere — distribution, awareness, product-market fit. You may need to zoom out.
For zooming out, ask "What would my skip-level manager try to solve here?" This helps you elevate the problem, seeing it from a level or two up in the hierarchy.
O — Outcomes
This is the most well-known problem-solving step and often the easiest. Because this is the easiest step, you might often see folks jump into defining the outcomes. The risk is that sometimes you are so attached to the outcomes that you completely miss out on the bigger picture that could have been revealed while understanding the "context" and "sizing" of the problem.
A common method is SMT: Specific, Measurable, and Time-bound. You should define:
- A specific metric
- A way to measure it with confidence
- A timeline for hitting the target
Summary
Start by understanding the context — ask the right questions. Then, size the problem — zoom in or out, elevate your perspective. Finally, define the outcomes — specific, measurable, and time-bound. If you can't communicate this clearly in under a minute, don't panic — just iterate.