Thinking from first principles
a practical antidote to “we can’t”
“We can’t split that.”
“We can’t release without the full flow.”
“We can’t hit that date.”
If you’ve worked in any kind of delivery team, you’ve heard a version of this. It lands like a brick in the middle of a conversation. Progress stalls. Nobody’s quite sure how to respond without starting a row.
The statement sounds final. But most of the time, it isn’t.
It’s often just a placeholder for uncertainty.
Or habit.
Or fear.
This is where first-principles thinking earns its keep—not as a buzzword, but as a reliable way to separate what’s actually impossible from what just feels hard.
What first principles thinking actually is
Forget the mystique.
Thinking from first principles simply means: start from what you know is true, and build up from there—without copying what others have done, or relying on what you've always done.
Most people reason by analogy.
“This is like that other thing, and we handled it that way, so let’s do the same here.”
First principles thinking strips that away.
It says: what are the fundamental facts, constraints, or forces involved—regardless of what’s been done before?
It’s less efficient, but more accurate.
Especially when the old patterns no longer apply.
Why “we can’t” sticks around so easily
There’s no mystery here.
People reach for “we can’t” because it’s low-risk language.
It avoids blame. It sounds prudent. It’s hard to disprove without sounding reckless.
It also spares us the work of thinking differently—because if we take the impossibility at face value, we don’t have to challenge our assumptions or open ourselves to failure.
Add a few legacy processes, some brittle architecture, and a couple of sacred cows, and “we can’t” starts to look like gospel.
It isn’t.
What really constrains us
Here’s a useful distinction:
Governing constraints: physics, logic, regulatory requirements, hard resource limits.
Assumptions: habits, preferences, undocumented decisions, inherited workflows.
First-principles thinking holds onto the first group and ruthlessly interrogates the second.
For example: “We can’t ship without the backend.”
Is that a governing constraint?
Or just the way things were done on the last five projects?
A lot of impossibility claims evaporate under that kind of pressure.
The four-move routine
Next time someone says, “we can’t,” try this:
Translate the claim into a concrete sentence.
Make it falsifiable. Turn “we can’t split it” into “This PBI has no smaller subset that delivers user value.”List the facts that must remain true.
Business rules, security constraints, API dependencies. Use physics, not folklore.Strip away any assumption not grounded in a fact.
If something is there “because we always do it that way,” park it.Rebuild your options from the surviving facts.
What’s left is your real design space. It’s often wider than it looked.
Applied example: splitting the “unsplittable” PBI
Let’s say a developer says:
“We can’t split this report. It’s all-or-nothing.”
You run the routine.
Step 1 – Translate it:
“No part of this report delivers value on its own.”
Step 2 – Facts that apply:
Finance needs totals by month.
Detail by customer is a bonus.
Frontend and backend are loosely coupled.
CI pipeline takes 6 minutes per run.
Step 3 – Strip assumptions:
“Users will be confused” — that’s fixable with a flag or UI message.
“It’s inefficient to test twice” — not with a fast, automated pipeline.
Step 4 – Rebuild:
Create one PBI for monthly totals, and one for customer detail. Release the first early. Learn something. Adjust the second if needed.
Suddenly, the impossible PBI is two small, testable, releasable items.
What helps this process land
This kind of thinking needs facilitation, not confrontation.
Use prompts like:
“What’s the smallest thing we could release that still helps someone?”
“Which part of this is physically or legally required?”
“What if the old way weren’t available—what would we do?”
And write it out in the open.
Whiteboards, sticky notes, Miro boards—anything that makes the logic visible and tamps down the emotional charge.
Once the assumptions are named, they can be challenged without ego.
Watch out for false positives
Not everything labelled impossible is laziness.
Sometimes the constraint is real: a legal requirement, a compliance gate, an irreversible data migration.
Sometimes the challenge burns more energy than it saves.
First-principles thinking isn’t about forcing every door open. It’s about checking which ones are actually locked.
Why it’s worth the effort
You find options that weren’t obvious.
You shrink risk by breaking work down sensibly.
You learn faster, because smaller experiments give quicker feedback.
You build a culture that challenges inertia.
And you replace “we can’t” with something far more honest:
“We thought we couldn’t. But actually, we can.”