First-principles thinking
Derive the right product from the customer truth up — not from what competitors shipped.
The short version
First-principles thinking means reducing a problem to the facts that are inarguably true, then reasoning back up to a solution — instead of copying what already exists (reasoning by analogy). For a PM it is the difference between "build what competitors have, minus a feature" and "start from the customer truth and derive what should exist." It is the antidote to the most expensive phrase in product: "because that is how it has always been done."
Why it matters for product
Most product roadmaps are built by analogy: a competitor shipped X, leadership asks for X, so X goes on the roadmap. Analogy is fast and often fine — but it caps you at incremental variations of what already exists, and it quietly imports assumptions you never examined. The competitor may have built X for a customer you do not serve, a constraint you do not have, or a reason that stopped being true years ago.
First-principles thinking is the deliberate alternative: strip the problem to the customer truths that are inarguably real — what the user is actually trying to accomplish, what they will pay for, what the physics/economics of the situation allow — and rebuild the solution from there. It is slower and harder, which is exactly why it is a differentiator. It is also why the Amazon PM bar explicitly asks PMs to "reason from first principles, challenging assumptions and not treating past approaches as gospel."
How to do it (on a product problem)
Common mistakes
Using it on everything — first-principles reasoning is expensive; reserve it for high-stakes or one-way-door decisions, and reason by analogy for the rest.
Mistaking a convention for a constraint (and never testing whether the "fixed" thing is actually fixed).
Stopping at your own assumptions — the customer truth must come from real customer evidence, not from first-principles-flavored opinion.
Reinventing what genuinely works — "not invented here" dressed up as rigor. Derive when it matters; reuse when it does not.
In a startup
Your advantage is that you have fewer inherited conventions to unlearn. Use first principles to find the wedge an incumbent cannot copy without breaking their own model — then reason by analogy for everything non-core so you ship fast.
In an enterprise
The hard part is organizational, not intellectual: inherited requirements arrive with a sponsor attached. Use first principles to separate the real constraint from "what the last VP wanted," and bring the derivation (not just the conclusion) so stakeholders can follow you off the well-worn path.
Continue the path