As I was listening to a podcast a couple of weeks ago, I heard a guest, in the context of making consequential decisions, drop the term "first principles". Not being my first introduction to the concept, the mention of if made me think back to a time earlier in my life and career when I first discovered the idea and started to incorporate it into my thinking process. Since the concept made a cameo on the podcast, it felt like a good time to revisit the idea and do a write up on how first principles thinking can help product teams in their search for sound reasoning and a purer form of problem solving.
The overarching concept of first principles features heavily in other design maxims. You might have heard the phrase " If you're struggling to find a good solution then you don't have a good enough problem". First principles add some meat to the bones by layering in some intellectual rigour and in this article I will expand upon how to systematically apply it in a product design context.
So what is First Principles Thinking?
After having reacquainted myself with the topic, I've landed on a definition of First principles firstly as an intellectual solvent, dissolving flawed or lazy assumptions and secondly as form of analytical archeology that guides you away from making decisions based on conventional wisdom (analogies) or on any stowaway biases that you may be bringing into the problem space. So instead of accepting how things are typically done, you dig down to the fundamental truths of the problem and build your reasoning from there. It's the difference between copying what everyone else does (business as usual) and deeply understanding why things work the way they do and using that foundational understanding as a basis for your solutions.
Among his many innovations, Steve Jobs and his team applied first principles thinking by stripping away assumptions about how computers should work. After seeing an early version of the graphical user interface at Xerox PARC, Jobs interrogated many aspects of the design to make it more intuitive and affordable. For example, by redesigning the mouse from a complex, expensive three-button device to a simple, innovative and ergonomic single-button version, it could be manufactured at a fraction of the price.
That's first principles in action – questioning the fundamental assumptions everyone else takes for granted.
Do you Experience this in Your Product Team?
Product design often comes bundled with best practices, design patterns, usability heuristics and occasionally "this is how we've always done it" thinking. We copy what successful companies do without understanding the context that made those decisions right for them. We might follow design trends because they're trendy, not because they address the specific problems we are setting out to solve.
First principles thinking cuts through this noise. It forces you to ask uncomfortable questions like:
- Why does our signup flow have multiple steps when our core value prop can be demonstrated in one?
- Why are we building a mobile app when our users' core job-to-be-done happens at their desk?
- Why does our pricing page look like everyone else's when our cost structure is completely different?
- And one of my favourites, are we burdening the user with excessive amounts of data simply because we have it in our database and because it has featured heavily in our internal conversations?
The magic happens when you stop asking "what would Stripe | Google | Netflix do?" and start asking "what does our user actually need?"
The Framework: A Playbook for Bringing this to Your Team
Here's a quick system for applying first principles to your product decisions:
Step 1: Identify and Question Your Assumptions
Start by listing out or verbalising everything you "know" about your problem. Write down all the constraints, requirements, and givens. Then ruthlessly question each one. Are they actually supported by evidence, or are they just inherited wisdom or pet-project features?
For example, if you're designing a dashboard, it's tempting to assume the user needs to see everything at once. This is especially acute after seeing a beautiful but highly conceptual dashboard rendering replete with charts, oversized numbers and sexy visualisations. But does the user need all of this extra noise? What if the fundamental need is just quick access to their most critical metrics? Maybe the solution isn't a better dashboard – maybe it's a handful of impactful visualisations and a smart notification system.
Step 2: Distill the Fundamental Truths
What are the core elements that must be true for your solution to work? Strip away everything that's nice-to-have, industry standard, or "what users expect" and focus on the bare-bones mechanics of your problem.
If you're building a project management tool, the fundamental truth might be: "Teams need to be able to instantly see what features are needed to deliver the current iteration." Everything else – the size estimates, the comments, the file attachments and the emoji reactions – those are secondary details, not core requirements.
Step 3: Rebuild From the Ground Up
Now for the interesting part. With your fundamental truths in hand, start brainstorming solutions without referencing existing products or solutions. How would you solve this if you were the first person to ever encounter this problem?
Adopting this mindset can provide fertile ground for breakthrough product decisions to emerge. Consider that Slack didn't just build a better email client – they reimagined how work communication could function. Notion didn't just make a better wiki – they questioned why documents, databases, and task management had to be separate tools at all.
Real-World Application: A Case Study
Let me walk you through how we used this approach at an enterprise SaaS startup I worked for. We were building a cloud database cluster management tool and were struggling to build the features that would attract new users. Up until that point we had built a management interface for configuring the infrastructure and deploying the clusters but weren't supporting the users with enough exciting opportunities to interact with their brand new cluster after they had configured and deployed it. Our underlying instinct was to continue to skirt around the fundamental problem by leaning into creating new deployment options, and free-tier options.
Instead, we went first principles. We asked: what do our users want to do with our software? After a period of discovery and soul-searching we began to understand that our users want to get their hands dirty with their data right away so they can start exploring how the features of the underlying database can help them leverage their data.
That insight changed everything. Instead of spending yet more time augmenting the checkout flow with new usage tiers, we built a killer new data ingest feature which we showcased to the user immediately after a successful deployment as an exciting next step for them to take.
The feature allowed the users to ingest data from their own file system, Kaggle or Amazon S3 with the most common formats supported. We offered several example datasets to encourage experimentation. The result, a 30% reduction in ghost clusters in a 6 week period. The users were re-engaging with our software all because we solved a genuine problem and not the assumed problem.
The Common Traps (And How to Avoid Them)
Like any initiative of this kind, it's easy to fall back into old habits over time. Perhaps you do a workshop about First Principles thinking and maybe even feel good about the result. The team buys into the idea of questioning assumptions and momentarily becomes mindful of their own bias towards a particular solution. But as soon as you hit the implementation stage, you fall back into conventional thinking.
Guide your team towards embedding First principles thinking in your decision-making process. Every feature spec, every design review, every sprint planning session should include some version of the question: "Are we solving in this way this because it's the right solution, or because it's the expected solution?"
Another trap in a similar vein is using first principles to justify decisions you've already made. It's easy and more than a little convenient to reverse-engineer a set of fundamental truths to support your existing direction. Real first principles thinking requires a willingness to discover that your current approach might be wrong.
Making This Stick in Your Organization
I've been thinking a lot lately about the balance between achieving speed of execution vs reaching a depth of insight. In a fast-paced startup environment we're speed obsessed - we've all heard the maxims "Speed is everything" or "Time is your most valuable asset". But what about truly understanding the problems we're trying to solve? Perhaps we need to make "what are we assuming here?" a more prominent question in the work sessions we run and seek surety on the direction of travel before moving into the speed of execution phase.
So what can we do? A good starting point might be documenting your first principles reasoning. Maybe you're doing a product review and the CEO or founder asks why you made a particular product decision. It's always good to show your workings, even for your own benefit. With your first principles reasoning captured, you can then trace the solution back to fundamental user needs and constraints rather than casual anecdotes like "that's a customer pain point" or "that's what worked for Company X."
When you're truly thinking from first principles, your solutions might feel counterintuitive to people outside of your team. If every industry observer you know would immediately understand and approve of your approach, you might still be operating from the safety of conventional thinking rather than breaking through to something genuinely different.
The Payoff: Why This Actually Matters
Companies that consistently apply first principles thinking don't just build better products – they build different products. They find opportunities that everyone else misses because they're operating outside of the usual set of assumptions.
Your users don't care if your solution follows UX best practices. They care if it solves their problem better than anything else available. Sometimes that means following conventions, but often it means breaking them in thoughtful ways.
The teams that figure this out don't just win features wars – they redefine entire categories. And the good news - you likely already doing this but might not have a formalised understanding and approach towards this type of reasoning. By giving this method some thought, if you're not doing so already, you might be able to apply a bit more structure, linearity and intellectual rigour to your reasoning - and maybe get something truly brilliant in return.
So next time you're facing a tough product decision, resist the urge to look at what successful companies are doing. Instead, dig for the foundational truth, question everything and build from the ground up.
Your users – and your business – might just thank you for it.