Split the Problem Meeting from the Solution Meeting
Never let the first plausible problem statement become the thing your team solves
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 92%
The mechanism is structural separation. In a single meeting, the first reasonable-sounding problem statement is treated as settled and everyone races to solve it — especially in high-calibre, type-A teams. Splitting the session into two prevents that: the first meeting produces only a problem statement, and the second, held later, produces solutions. The gap does the real work, because many people do not think well on the spot and only surface their best objection on the walk home. Two further rules protect the first meeting: assume the pre-read has been read, and ask each person for the unique contribution nobody else can see. That shifts the social reward from air time to distinct insight. Accountability sits with whoever owns the decision: they take input but must write and communicate the problem statement themselves.
Origin
Parrish and his team ran in-person decision-making workshops, then converted the material into an online course, Decision by Design, when covid ended live events. Separating problem definition from problem solution was one of the practical tools they found people actually used in the real world.
Core principles
- 01The way you frame the problem determines which solutions you can even see.
- 02The person accountable for the decision must own the problem statement.
- 03Type-A teams jump to solutions on the first statement that sounds reasonable.
- 04When the boss thinks out loud, the team hears direction.
- 05Two thirty-minute meetings beat one sixty-minute meeting because thinking happens in between.
- 06Speed without direction is running in circles.
How to run it
- 1
Schedule two meetings, not one
Replace the single sixty-minute session with a thirty-minute problem meeting and a thirty-minute solution meeting held the next day or the next week.
Watch out Expect the objection that this slows you down; the opposite is true if you would otherwise solve the wrong problem.
- 2
Set the contribution rule
Assume everyone has read the material and ask each participant only for the lens they hold that nobody else does. Restating the summary does not count as contributing.
Pro tip This rewards unique contribution rather than air time, and kills meeting posturing.
- 3
Interrogate whether it is even a problem
Before framing, ask whether this is significant enough to deserve attention and resources against everything else competing for them.
Pro tip Bigger teams manufacture non-problems as busy work; small teams feel the cost immediately.
- 4
Run 'and then what?' on the framing
Thought-experiment the state you would be in if this problem were solved as framed, including the cost in time, money, effort, and brain drain.
Watch out Organisations routinely swap software to fix one problem while creating dozens they never counted.
- 5
Let the decision-maker write the statement
The accountable person takes all input, mulls it over, then writes and communicates the problem statement — which forces them to genuinely understand the problem.
Pro tip Speaking last protects the room from anchoring on the boss's first instinct.
Watch out When the boss speaks first, a musing becomes direction and the team starts solving it.
- 6
Open the solution meeting only after agreement
Reconvene once the statement is settled and use it as the test for which proposed solutions actually fit.
In the wild
Ferriss had years of legacy email addresses scattered across platforms and framed the problem as a security and consolidation issue: move everything into one modern, enterprise-secure inbox and decommission the rest. Parrish pushed on whether that was the real problem. Halfway through recording instructions for his team, Ferriss realised his actual objective was to spend far less time in email and reclaim three-to-four-hour creative blocks. Consolidating would have moved the unsolicited inbound to a new address and solved almost nothing.
→ He caught himself giving the best possible advice for the wrong problem before the team executed it.
Parrish describes organisations he has worked with switching out software to solve a single identified problem, without asking what state they would be in afterwards. The new tool does not do something the team relies on, so workarounds get built; everyone needs retraining; support and update cadence are worse. The change feels like progress because it looks like work, but the net position is worse than before.
→ A visible fix to one problem, paid for with dozens of unpriced new ones.
Common mistakes
Solving the first reasonable statement
The first framing that sounds plausible gets treated as settled, and a capable team then executes efficiently against the wrong target.
Boss speaks first
A leader thinking out loud is heard as a directive, so the room stops evaluating the framing and starts building toward it.
Treating the extra meeting as delay
Compressing both jobs into one meeting optimises for speed without direction, which is fast movement in circles.
Is it for you?
Best for
Decision-makers running small, capable, fast-moving teams that reflexively jump to implementation.
Not ideal for
Genuine emergencies where the problem is unambiguous and delay carries real cost.
From the transcript
“separating problem definition from problem solution having two separate meetings for that”
“the way that you frame that problem will determine in a large part what Solutions you see is available”
“you're thinking in terms of speed but speed doesn't have a Direction so it doesn't matter how fast you're going if you're running in circles”
From the episode
#695: Shane Parrish on Wisdom from Warren Buffett, Rules for Better Thinking, How to Reduce Blind Spots, The Dangers of Mental Models, and More