Every PM framework — RICE, JTBD, Design Thinking — was built for consumer or enterprise SaaS. In life sciences, the biggest risks are regulatory rejection and clinical harm. This is where first principles thinking becomes essential.
What It Actually Is
Breaking problems to fundamental truths and reasoning upward — not by analogy ("X did it this way") or convention ("it's always been done this way"). In life sciences, conditions are changing rapidly. AI is new. Regulatory frameworks evolve. The "best practices" of five years ago may hinder innovation today.
Example 1: Challenge Compliance Assumptions
Conventional: "AI in clinical settings always requires FDA clearance." First principles: What specifically triggers FDA jurisdiction? The 21st Century Cures Act exempts certain CDS software. Administrative AI isn't FDA-regulated. I've seen teams waste a year pursuing unnecessary regulatory pathways.
Example 2: Rethink Clinical Workflows
Conventional: "Design AI to fit existing workflows." First principles: Are existing workflows optimized, or workarounds for limitations that no longer exist? "Fit into workflows" is often code for "don't challenge anyone."
Example 3: Question Data Architecture
Conventional: "Build a unified data lake first." First principles: What data does the AI actually need? Start with minimum viable data. Federated learning and API-based access can deliver value without 18 months of infrastructure.
Example 4: Rebuild Pricing Models
Conventional: "Price per-user like traditional health IT." First principles: If your AI reduces denied claims by 30%, the value is recovered revenue, not software access. Value-based pricing aligns incentives and commands 10x the price.
Example 5: Reimagine User Personas
Conventional: "The primary user is the physician." First principles: Who actually interacts with the software? Nurses, MAs, coordinators, and patients are often the actual users. The highest-leverage user isn't always the one with the most authority.
How to Practice It
- Ask "why" five times. Toyota's technique works in healthcare too.
- Identify assumptions, then test them. Is this a physical law, regulation, convention, or habit?
- Study adjacent industries. How does fintech handle compliance? Aerospace handle safety-critical AI?
- Talk to outliers. The most innovative health systems have already challenged assumptions you haven't identified.
The Bottom Line
- Best practices often encode outdated assumptions.
- First principles isn't ignoring regulations — it's understanding exactly what they require.
- The highest-value decisions come from questioning the problem, not optimizing the solution.
- It's slower upfront but faster overall. 30 minutes of analysis can save months of building wrong.
See About and Research for more on my approach.
Frequently Asked Questions
What is first principles thinking in product management?
First principles thinking is a problem-solving approach where you break down complex problems into their most fundamental truths and build up solutions from there, rather than reasoning by analogy or convention. In product management, this means questioning every assumption about how a product 'should' work — why does the workflow look this way? What does the user actually need versus what they're used to? Elon Musk's famous battery cost analysis is a classic example: instead of accepting batteries cost $600/kWh, he broke it down to raw material costs ($80/kWh) and engineered from there.
How do you apply first principles to life sciences product decisions?
Start by identifying the core constraint or assumption you're challenging. For example: 'Clinical trial protocols require 12-month patient follow-up.' Ask why — is it regulatory requirement, clinical convention, or statistical necessity? If statistical, can adaptive trial designs achieve the same confidence faster? Then map dependencies: what downstream decisions depend on this assumption? Finally, validate with domain experts (clinicians, regulatory, biostatisticians) before building. The key is separating regulatory requirements (non-negotiable) from industry conventions (challengeable).
When should I NOT use first principles thinking?
First principles thinking is expensive — it requires deep domain expertise and time. Don't use it for: well-solved problems with proven solutions (authentication, payment processing), compliance requirements with clear specifications (HIPAA technical safeguards, FDA labeling rules), commodity features where differentiation doesn't matter (user settings, password reset), or when speed-to-market is the primary constraint. The 80/20 rule applies: use first principles for the 20% of decisions that drive 80% of product value, and use best practices for everything else.
How do you convince stakeholders to accept first-principles solutions?
First-principles solutions often look unconventional, which triggers organizational antibodies. Three strategies: (1) Show the reasoning chain — walk stakeholders through the decomposition so they see how you arrived at the conclusion; (2) Find precedents in adjacent industries — 'this approach worked in fintech/aerospace/etc.'; (3) Propose a bounded experiment — 'let's test this with one site/one client/one quarter and measure X.' The biggest mistake is presenting the conclusion without the reasoning. Stakeholders need to take the journey with you, not just see the destination.
Can first principles thinking coexist with agile methodologies?
Yes, and they're complementary. First principles thinking happens at the strategy and discovery layer — deciding WHAT to build and WHY. Agile operates at the execution layer — deciding HOW to build it incrementally. Use first principles during quarterly planning, roadmap prioritization, and major pivot decisions. Use agile for sprint execution, iteration, and delivery. The anti-pattern is using first principles for every sprint decision (too slow) or using agile without first principles for strategic direction (building the wrong thing fast).
