Find the Real Constraint
Added 2026-11-03
There are usually one or two real limits; the rest are excuses.
I feel something cannot be done (context below). Find the real constraint: 1) list every limit mentioned — time, budget, people, rules, technology; 2) judge each: if this were solved, would things actually move; 3) find the one constraint whose resolution makes the others bypassable; 4) point out which limits I assumed myself; 5) give a way to test the constraint within a week.
Site original
Chinese original
How to use
找到真约束，方案会突然变简单。
Try tweaking it
- Ask what evidence would overturn the judgement.
- Have it argue both sides with three reasons each.
What you should get
- A decision table: assumptions, evidence, counter-evidence
- A next action with an observable signal
Common mistakes
- Asking only "should I?" and getting equally valid answers both ways.
- Never asking for counter-examples, so you only hear support.
How to check the output
- It states what evidence would overturn the conclusion.
- Both sides are argued, with assumptions marked as such.
Where it works
- Good for: splitting a decision into assumptions, evidence and counter-cases, leaving the call to you.
- Watch out: ask what evidence would overturn the judgement, or you will only hear supporting reasons.
Good for
- A project keeps slipping and the team lists many reasons why it cannot move, but nobody has confirmed which is the real constraint.
- Before asking for resources or changing the approach, you want to separate being genuinely blocked from habitually saying so.
Not for
- You already know the blocker, such as an approval process, and are working on it — more analysis is just delay.
- The constraint is clearly hard, such as a legal or physical limit — focus on routing around or accepting it, not redefining it.
Example
Input
The launch keeps slipping. The team says: not enough time, too few testers, requirements keep changing, server provisioning is slow, designs are not final.
What you get
Test each with "if this were solved, would things actually move?". Testers and final designs may be secondary; provisioning is a fixed lead time you can start earlier; changing requirements are the likely driver — if requirements still move, fixing the other four will not ship anything. So the real constraint is that requirements are not frozen, and the rest are consequences. Test it: count requirement changes this week; if the count is zero and the launch still slips, the constraint diagnosis is wrong.
Common mistakes
- Treating the most frequently mentioned limit as the real constraint: frequency is not causality.
- Changing the plan without testing: you route around a false constraint while the real one stays.
Try tweaking it like this
- Sort by changeability: handle what you can change, then ask whether the rest can be bypassed.
- Ask "if only one constraint could be solved": it forces a single bottleneck instead of a list.