Every great solution starts with a well-framed problem. But most of us skip straight to solution mode — we smell a problem, grab the first fix that comes to mind, and wonder later why it didn't stick.
This lesson teaches you one thing: how to stop and frame before you solve. It's the single highest-leverage skill for becoming strategic.
A well-framed problem does three things that a reactive approach doesn't:
A hour spent framing can save a week of solving the wrong problem. At the VP level, this is the difference between a strategic conversation and a tactical status update.
Before you think about solutions, write a one-paragraph problem statement. Here's the structure:
Context: [What's the situation? Who is affected?] Observed symptom: [What's happening that's wrong?] Impact: [Why does this matter — cost, time, quality, morale?] Unknown: [What don't we know about the root cause?] Question: [The single question we need to answer first.]
Example — a real frontend scenario:
Context: Our checkout page has a 12% drop-off between "Add to Cart" and payment. Observed symptom: Users reach the payment step but don't complete. Impact: ~$40k/month in abandoned revenue. Unknown: Is it a UX issue (confusing form), trust issue (missing security badges), or performance issue (payment iframe load time)? Question: What is the primary driver of abandonment at the payment step?
A VP doesn't have time to hear solution A vs. solution B before understanding the problem. Opening with a framed problem statement shows you've done the thinking before the meeting. It changes the conversation from "should we do X?" to "do we agree on what we're solving?"
Not all problems are the same. The Cynefin framework (Dave Snowden) helps you classify which kind of problem you're facing — because each kind needs a different approach.
Known knowns. The cause-and-effect is obvious to everyone. Best practice applies.
Example: The production server is down because the SSL cert expired. Fix: renew the cert.
Approach: Sense → Categorise → Respond
Known unknowns. Multiple possible solutions, but experts can analyse and find the right one. Requires diagnosis.
Example: Our API response times degraded. Is it a DB query issue, a caching misconfig, or a new bottleneck?
Approach: Sense → Analyse → Respond
Unknown unknowns. The answer isn't knowable upfront. You need to experiment and probe to discover what works.
Example: Our team's velocity dropped after switching to a new tech stack. The cause is tangled — morale, learning curve, tooling issues all interacting.
Approach: Probe → Sense → Respond
Unknowable. The situation is in crisis. Act first to stabilise, then diagnose.
Example: Production is down and customers are furious. Stop the bleeding first, analyse later.
Approach: Act → Sense → Respond
The most common mistake engineers make: treating a Complex problem as Complicated — spending days analysing something that can only be understood through experiments. Or treating a Complicated problem as Clear — applying last year's solution to a different root cause.
Think of one problem you encountered this week at work. It can be technical, process, or people-related.
Read: "The Cynefin Framework" by Dave Snowden
Wikipedia: Cynefin framework → — the best entry point. Read the full article (10 min). Pay special attention to the table comparing the four domains and the examples.
Also recommended: "Chesterton's Fence" by G.K. Chesterton (via Farnam Street) — a short, powerful parable about understanding why something exists before changing it. Read it here: fs.blog/chestertons-fence/ (5 min).
In Lesson 2, we'll go deeper into Issue Trees — the MECE-based technique for breaking a vague problem into concrete, analyzable components. But first: practice the exercise above. The frame is the foundation.