First Principles for Product Managers

First-principles thinking is the most overused phrase in tech that is also genuinely one of the most useful tools I have. The problem is that most descriptions of it are either too abstract to be usable ("reason from fundamental truths!") or reduced to the Elon Musk rocket story without explaining the underlying method.

Let me try to explain what it actually is, how I use it, and when it's worth the effort.

Section 1: What First-Principles Thinking Actually Means

First-principles thinking is the practice of decomposing a problem or belief into its fundamental components, testing each component independently, and rebuilding your conclusion from the ground up rather than borrowing from existing frameworks or conventional wisdom.

The contrast is reasoning by analogy: "Company X did this, it worked for them, so we should do the same." Analogical reasoning is fast and often right. It's also the source of many of the worst product decisions I've seen, because it borrows not just the answer but also the assumptions that made the answer right for someone else - which may not hold for you.

Here's a concrete example from my own work. The conventional wisdom in enterprise AI sales is that you need a proof of concept before a customer will commit to a contract. That's the analogy: AI vendors do POCs, therefore we do POCs. But what does the POC actually accomplish? It demonstrates technical feasibility, builds trust that the team can execute, and lets the customer evaluate fit. Once I decomposed it that way, I asked: are there ways to accomplish each of those goals faster or cheaper than a 3-month POC? In some cases, yes - a well-structured demo with real customer data, an independent technical audit, and reference calls with existing customers can accomplish the same goals in 2 weeks. We tried it. It worked for certain customer profiles. First principles found a path that the analogy would have hidden.

The actual practice

Step 1: State the belief or decision clearly. "We need to build a mobile app for this feature." "We should price at $X/seat." "This customer will buy if we add feature Y."

Step 2: List every assumption embedded in that statement. What are you taking for granted? What would have to be true for this to be right?

Step 3: For each assumption, ask: do I actually know this is true, or am I borrowing it from convention, analogy, or someone else's decision? If I had to verify this from scratch, what evidence would I look at?

Step 4: Test the assumptions you're least confident about first. Not all of them need to be tested - some are so foundational (gravity, basic economics) that testing them would be a waste. Focus on the ones that are both uncertain and consequential.

Step 5: Rebuild the conclusion using only the assumptions that survived testing. The resulting answer may look identical to the original, or it may be completely different. Either is fine - you've now grounded it in evidence rather than convention.

The Elon Musk thing

The rocket story is real and it's a good example, but it creates a misleading impression that first-principles thinking is only for billion-dollar problems. I use it on mundane product decisions several times a week. It doesn't require breakthrough insights. It requires slowing down long enough to notice your assumptions.

The hardest part is not the decomposition. The hardest part is being honest about which assumptions are actually tested versus which you've borrowed from somewhere and forgotten to question. Most assumptions in product management are borrowed, and they're borrowed for good reasons - analogical reasoning is efficient and usually works. First-principles thinking is for when you have reason to believe the usual answer is wrong for your context.

Section 2: Applying It to Product Decisions

Let me walk through four decision categories where I've found first-principles thinking most useful.

Prioritization

The conventional approach: RICE score everything, rank by score, execute from the top. This is borrowed wisdom, and it embeds assumptions: that you can reliably estimate reach, impact, confidence, and effort; that the resulting ranking maps to actual value; that the top item in the backlog is the right thing to work on right now.

A first-principles examination of prioritization asks: what is the decision actually trying to accomplish? Usually: maximize value delivered to customers and the business given resource constraints over a given time horizon. What assumptions does RICE embed? That all items are substitutable and can be ranked on a single axis. That effort estimates are reliable. That impact is knowable in advance.

When I've rebuilt prioritization from those components, I often arrive at a different process: instead of ranking all items, I'm making a small number of binary choices. Is this the most important problem we could be working on right now? If yes, is there a better way to solve it than what's currently in the backlog? This is slower than running RICE scores, but it catches the cases where the entire backlog is optimizing for the wrong thing.

The case where RICE failed me: we had a beautifully prioritized backlog of feature improvements for an enterprise product. Every item had high reach, high impact, and high confidence scores. First-principles examination of what "value" actually meant to our enterprise customers revealed that they cared almost entirely about one thing: reducing time to value in onboarding. Nothing in our backlog addressed this directly. We were optimizing efficiently for the wrong objective.

Feature Trade-offs

The conventional approach: compare features on customer value, engineering effort, and strategic alignment. Score each dimension, make the call. Fast, consistent, often right.

First-principles examination: what are we actually optimizing for with this feature decision? Not "which feature is better" in the abstract, but what is the job this feature does for the customer, and what is the business outcome we're trying to move? Once you've defined those, the decision often becomes obvious without needing a scoring matrix. The matrix is a proxy for the actual question - sometimes a useful proxy, sometimes an obscuring one.

The specific case where this matters most: when two features seem to serve the same customer need but via different mechanisms. Feature A is a UI improvement that makes the existing flow easier. Feature B is an automation that eliminates the flow entirely. A feature comparison matrix will compare them on the same axis and one will score higher. First-principles thinking asks: which outcome does the customer actually want - an easier flow, or no flow at all? They're different answers to the same problem, and the right choice depends on assumptions about customer behavior that need to be tested.

Market Entry

The conventional approach: TAM/SAM/SOM analysis, competitive space, positioning. These are useful, but they're borrowed frameworks that embed assumptions about how markets work.

First-principles examination: who has the problem? How do they solve it today? What would it take for them to switch? What's the minimum viable version that creates enough value to earn adoption? What prevents us from serving this segment that doesn't prevent others?

When I've used first principles here, the conclusion is often a narrower initial target market than the frameworks suggest. Frameworks optimize for market size. First principles optimize for achievability. In the early stage, a small market you can win is worth more than a large market you can't penetrate.

Pricing

The conventional approach: competitive benchmarking, cost-plus, value-based pricing framework. All valid starting points, all borrowed from somewhere.

First-principles examination of pricing asks: what is the customer actually buying? Not the software - the outcome. What is that outcome worth to them in dollars? What determines how much of that value you can capture versus what the customer keeps? What constraints prevent you from charging more - competition, switching costs, budget cycle timing, procurement process?

Here's what I've found: most B2B AI products are underpriced relative to the value they deliver, because pricing decisions were made by analogy to comparable software products rather than by calculating the value of the outcome. If your AI reduces a process that costs $500K/year by 40%, you've created $200K in value. Charging $20K/year because "comparable SaaS products are priced in that range" leaves $180K on the table. First principles says: start from value delivered, then work backwards to a price the customer will accept.

Section 3: Building a First-Principles Practice

First-principles thinking is a skill, not a trait. You build it through deliberate practice, not through reading about it. Here's how I've tried to build it into my daily work.

Daily habits

The most useful habit I've developed: when I find myself agreeing with a recommendation, a priority, or a direction without much resistance, I pause and ask "what would I have to believe for this to be wrong?" This is the contrarian question, and it surfaces the assumptions embedded in the agreement.

I keep a short list - rarely more than 5 items - of the assumptions I'm operating on in a given week. Just naming them makes me more honest about which ones are tested versus borrowed. When something goes wrong, I check whether one of those assumptions failed. Over time, this improves my assumption quality.

Write down your predictions before the data comes in. "I expect this A/B test to show X." "I think this customer will say Y in the discovery call." This forces you to surface the assumptions behind your expectations, and it tells you when your model of the world is wrong. It's uncomfortable. It's also how you get better.

Question frameworks

The questions I find most useful for first-principles examination:

"What would I have to believe for this to be true?" - surfaces hidden assumptions.

"If I had to build this from scratch with no prior knowledge of how it's usually done, what would I do?" - breaks path dependence.

"What is the simplest version of the underlying problem?" - cuts through solution complexity to find if you're solving the right thing.

"Who benefits from the current approach staying the same?" - identifies whose interests are embedded in conventional wisdom.

"What would change if I discovered that [core assumption] was wrong?" - tests sensitivity to assumptions.

When to use it vs when to trust heuristics

This is the most important calibration question, and most treatments of first-principles thinking get it wrong by suggesting you should always reason from first principles.

Use first principles when: the stakes are high and the conventional answer is unverified, you have reason to believe your context differs from the context where the conventional wisdom developed, the conventional approach keeps failing and you can't explain why, or the decision is novel enough that analogies don't cleanly apply.

Trust heuristics when: the decision is low-stakes and reversible, the conventional wisdom is well-tested in contexts similar to yours, the cost of first-principles analysis exceeds the value of a marginally better decision, or you need to act quickly and the stakes don't justify the delay.

Most daily PM decisions fall into the second category. Use heuristics and frameworks - they exist because they work. Reserve first-principles thinking for the decisions that are high-stakes, novel, or where you have a nagging sense that the conventional answer doesn't fit your situation. That's when the extra investment pays off.

The meta-lesson: first-principles thinking is not an alternative to frameworks - it's a tool for knowing when to trust them and when to set them aside. The PM who applies first principles indiscriminately wastes time. The PM who never questions conventions makes predictable mistakes. The skill is knowing the difference.

More on this

Further Reading