Break It to First Principles

Picture yourself staring at a problem as if it were a machine. The machine is complex, with many parts whirring. It’s easy to assume every gear and belt is necessary because that’s how you found it. But a first - principles thinker grabs a tool and carefully takes the machine apart. They lay out each component on the table and ask: What does this piece do? Do we really need it? Could we replace it with something simpler? Approaching problems with first principles is exactly that - disassembling the issues into basic elements and scrutinizing every assumption. It can feel a bit like being a curious child again, always asking “Why does it have to be this way?” or “Who says so?” The goal is to move from I think it’s so to I know what’s required by the laws of nature or policy, and what’s just convention. This approach can reveal creative solutions and alternatives that a surface - level view would never allow.

List out your assumptions and challenge them. Start by writing down everything you believe to be true about the problem and its solution. Be explicit. It might feel odd, because our assumptions usually hide unspoken in our plans. For example, if our problem is slow project delivery, assumptions could be: “We must do A before B,” “We need more people to go faster,” or “We can’t reduce scope because all features are required.” Write them as simple statements. Then, one by one, interrogate those statements: Why must we do A before B? Is that a physical requirement or just how we’ve always done it? If it’s a law of physics or a hard policy, fine. But often you’ll find the rule is arbitrary or flexible. Ask yourself, What scientific law, mathematical principle, or written policy makes this necessarily true? If you can’t point to something concrete, that assumption might be negotiable. For instance, an assumption “we need more people to meet the deadline” isn’t a fundamental truth; it’s a conclusion drawn from thinking more people = more capacity. But is that the only way? Could the existing team do it by working smarter or cutting tasks? By identifying assumptions, you throw light on the invisible rules guiding your thinking. Some will hold up (e.g., “we only have 24 hours in a day” - yes, that’s beyond negotiation!). Others might crumble under scrutiny, revealing new paths. The act of justifying each assumption against something fundamental separates facts from habits. It’s liberating to realize how many constraints are self - imposed.

Decompose the problem into functions, constraints, and resources. Think of this as sorting the parts of your machine into three buckets. Functions are what must happen or what the solution needs to achieve (the essential tasks or steps to solve the problem). Constraints are what must not happen or what boundaries you must respect (things like safety rules, budget caps, or “we cannot break feature X while fixing Y”). Resources are what you have available (people, time, tools, data, money). For a concrete example, say you’re trying to improve a delivery process. Functions might include “package items,” “schedule shipment,” “transport to customer.” Constraints might be “no item arrives damaged” and “transport cost per item must not exceed $5.” Resources could be “2 trucks, 5 staff, $10k monthly budget, and software system Z.” Writing this out does two things: it forces completeness (did we consider every function needed? did we list all hard limits?) and it separates necessary tasks from restrictions. Often, we realize some perceived “must” was actually a resource issue or vice versa. For instance, you might think “the process must send a confirmation email at 5pm daily” is a constraint, but that might just be a habit - maybe customers are equally fine with an instant confirmation at order time (function) and the 5pm batch was a leftover resource constraint from when a person did it manually. By structuring it this way, you can examine if each function is truly needed and if each constraint is truly binding. You might spot a function that’s actually extraneous or find a resource you forgot you had. This decomposition is a bit like debugging a program by reading the requirements line by line. It ensures your problem solving rests on a clear blueprint of what’s essential.

Do a quick reality check with rough math. Before diving into solutions, it helps to get a sense of scale and feasibility. Perform a back - of - the - envelope estimate. This is rough calculation using round numbers to see if your ideas even make sense. Suppose you assume “we need more people” to meet a deadline. Estimate how many hours of work are actually needed and how many hours your current team can produce. If the project is estimated at 600 hours of work and you have 4 weeks (160 work hours for one person), one person could do 160 hours in that time. You’d need roughly 4 people (because 4×160 = 640 hours) to complete it ideally. That’s a quick reality check. If you only have 3 people, you either need an extra person or to reduce hours of work needed (scope). Maybe your estimate is off, or maybe indeed you need to scale down the project by about 25%. Rough math also helps identify which variables matter most. In this scenario, the total work hours is a key variable. Another might be productivity per person (maybe overtime or efficiency tools could effectively increase hours). By plugging in ballpark figures and seeing which factor moves the needle most, you gain insight into leverage points. For example, if doubling team size theoretically halves the timeline, that’s a lever; if cutting one feature reduces work by 30%, that’s another lever. On the other hand, if a variable barely changes the outcome, you know it’s not where to focus. These estimates don’t need to be precise - if anything, using easy round numbers (10%, 50%, 1000 units, etc.) helps you think broadly. The point is to anchor your problem in reality. It’s easy to toss around ideas like “maybe this process is too slow” without quantification. Rough numbers turn vague worry into tangible insight: “ah, this step alone takes 70% of the total time, no wonder we’re slow!” That insight might scream bottleneck, telling you where to challenge assumptions next.

Sort real constraints from perceived ones. When you challenged your assumptions earlier, you likely found some that are hard truths (like physical laws or non - negotiable rules) and others that are actually soft (company tradition, personal preference, outdated policy that could be changed). It’s crucial to separate these because first principles thinking thrives where there’s flexibility. If something is truly impossible or illegal, accept it and work around it. But many “rules” we operate under are not absolute. For instance, a team might say, “We always release on Fridays because that’s how it’s done here.” That’s a habit, not a law of nature or even a formal policy. It can be changed next week if needed. Or someone might insist “We can’t change the design once development starts.” Why not? Perhaps historically design was locked, but maybe you actually can iterate if you allocate some design resources during development. On the other hand, a real constraint could be “All data must be encrypted due to GDPR regulations.” That’s a must - do; no point challenging it because it’s backed by law. List out your constraints and mark each as hard (truly unchangeable) or soft (changeable if we choose). You might be surprised at how many fall into the soft category. That’s your opportunity space. Each soft constraint is potentially an assumption you can break. Freeing yourself from one might let you solve the problem in a radically simpler way. For example, if “current team size” was assumed fixed but actually you could get a contractor or borrow someone from another team, suddenly “needing more people” might be solvable after all without permanent hires. Or if “feature X absolutely must be in the product” is actually just one stakeholder’s wish, maybe you can negotiate it out. By explicitly identifying which rules are bendable, you empower yourself to redesign the problem on a cleaner slate.

Replace labels with measurable mechanics. Words can sometimes obscure what’s really happening. We often describe our processes with labels or vague terms: “high workload,” “quality assurance,” “user engagement.” To think in first principles, translate those into concrete actions and quantities. Pretend you’re explaining to a scientist or an engineer who only understands physical terms or numbers. For example, instead of “high workload,” say “each support agent handles 50 tickets per day.” Instead of “quality assurance is slow,” articulate “QA takes 3 days on average, including 2 days of waiting and 1 day of actual testing.” By doing this, you move away from broad labels and get to the mechanics: the rates, frequencies, durations, and capacities. One helpful approach is to append units or numbers to things: how many requests per day? How many minutes per handoff? How much does fast or heavy actually mean? If something is described as “always” or “never,” quantify that too: does “always” mean 100%? Often it doesn’t - it might be 90%, which leaves room for exceptions. Describing the problem in mechanical terms not only clarifies it for you but may reveal inefficiencies or opportunities. For instance, labeling something “low engagement” is fuzzy. But noting “only 5% of users click past the first screen” is specific - and invites asking why 5% and not 50%? Perhaps a fix is hidden in that first screen’s design or wording. By quantifying, you also remove emotional weight or bias that labels carry. “High workload” might sound like you need another hire, but “50 tickets/day per agent” can be examined: Is that truly too many? Maybe industry standard is 40, so yes it’s high. Or maybe others handle 60 with better tools, so the fix might be tooling rather than hiring. These insights come only when you speak in counts and measures rather than fuzzy terms.

Open up the problem with an example scenario. Let’s apply these first principles ideas to a specific, relatable case. Suppose your team says, “We’re overloaded; we need more people.” That’s a common refrain. Let’s break it down. Ask, what’s the objective? Perhaps to handle all tasks by the deadline. List assumptions: we assume current staff can’t finish in time, we assume adding a person is the only way to increase throughput, we assume all tasks are necessary as is. Now challenge: is adding a person truly the only solution? What if instead we find another way to get more work hours out of the week or reduce needed hours? Decompose function vs. constraints vs. resources. Functions: writing code, testing, deploying (for example). Constraints: quality must not drop, deadline fixed. Resources: 5 developers, each works maybe 40 focused hours a week, 4 weeks left = ~800 developer - hours. Quick math: If tasks require 1000 hours total, indeed 800 hours falls short. One assumption: each developer can only contribute 40 hours a week. That’s often roughly true due to human capacity, but maybe there’s slack time we haven’t accounted for, or overtime as an option (not ideal long term, but a lever). Another assumption: 1000 hours of tasks are truly needed. Challenge it: can some tasks be dropped or deferred? Perhaps 30% of those hours are for “nice - to - have” features. If we cut those, hours needed drops from 1000 to 700, which 5 people can do in 4 weeks (5×160 = 800 hours). Suddenly, problem solved without new hires. Or instead of people, what if a better tool or script could automate 20% of the work? That also cuts hours. By stating, “We need more people,” we labeled the problem as a staffing issue. First - principles break it into “we need more productive hours or fewer required hours.” Now solutions multiply: hire (increase hours), outsource some tasks (increase hours via external), streamline tasks (reduce required hours), tighten scope (reduce hours), improve focus (turn some of those 40 - hour weeks into 45 effective hours through fewer interruptions). In one real case, a team realized “we need more people” was actually “we need about 6 more focused hours per week from the team or to drop 30% of our scope.” They achieved it by blocking one no - meeting day per week (which gave each person a few more focused hours) and cutting the lowest - priority features. No hiring needed; problem solved by rethinking assumptions on time and scope. This example shows the power of breaking a request or complaint down to the numbers and fundamentals. It went from a knee - jerk solution (“hire!”) to a choice of solutions grounded in math and logic.

Beware of the comfort of “always” and “never.” Some assumptions hide behind sweeping words. If you catch yourself or your team saying, “We always do it this way” or “That never works,” treat it as a signal. Such words can shut down inquiry, effectively locking a part of the problem away from examination. Challenge them gently: Why do we always do it this way? What would happen if we didn’t? Has it really never worked, or have we never tried systematically? Sometimes “always” actually means “we’ve done it this way for a long time and it’s comfortable.” And “never” can mean “we tried once and it failed, so we assumed it’s impossible.” These might be sacred cows or just outdated conclusions. For example, a company might believe “We never outsource because quality will drop.” Perhaps that was true 10 years ago in a specific instance, but is it an iron law? Maybe conditions changed (better outsourcing partners exist now) or maybe that memory is just a bias from one bad experience. Hidden assumptions can also nest in templates and processes: a form you always fill out might assume a step is needed that no one questions. Or a project plan template might have 10 phases because historically they were needed, but maybe now a few can be skipped or merged. Sacred cows (things that are immune to criticism or change) are particularly important to question when doing first principles thinking. It takes courage to say, “Let’s test this assumption that’s been untouchable.” But that’s often where breakthroughs come. If you notice emotional defensiveness around a certain element (“We can’t question that; it’s how the CEO wants it” or “It’s industry standard, end of story”), ask if it’s truly a fixed constraint or just an assumption wrapped in tradition. Not every challenge will lead to change - you might confirm some sacred cows are there for good reason - but you should deliberately surface and test them rather than let them silently dictate your solution space. First principles mindset is about not letting “just because” be the final answer.

Practice the art of influence diagrams. A practical way to break a problem into first principles is to draw it out. Take a blank page and sketch a simple influence diagram of your scenario. Identify three to five key variables or factors that seem to drive the situation. Draw each as a node or circle, and draw arrows from one to another where you believe one influences the other. For example, if the problem is slow customer service response, your diagram might have nodes like “Number of support tickets,” “Agents on duty,” “Average handling time per ticket,” “Backlog length,” and arrows showing more tickets - > bigger backlog - > longer response time. You might find that “handling time per ticket” is influenced by factors like tool efficiency or training. Keep it simple. When you see it on paper, put a star next to the factor that you can act on immediately and that would affect others. In our example, perhaps you can’t directly control number of incoming tickets (that’s customers’ behavior), but you can improve “handling time per ticket” by providing a better knowledge base or a macro for common replies. That factor has an arrow to backlog length and response time, so it’s a lever. Or maybe “agents on duty” is something you can change by reassigning one person - also a lever. The point of the influence diagram is to visually isolate what drives what. It breaks you out of linear thinking and helps spot feedback loops or dominant factors. Often one variable stands out as the fulcrum (small change, big effect). It also exposes if you missed a key variable altogether. While sketching, you might go, “Oh, I forgot about training level affecting handling time!” It’s okay to adjust as you realize more. In just a few minutes, you have a mini model of your problem’s mechanics. Now, choose one lever (starred) that you can pull now. It might be a variable you can improve or reduce. Commit to testing a change in that lever. This is where first principles meet action: you’ve questioned assumptions, broken things down, and identified a core piece you can change. Now you’re ready to fix problems at their root, not just slap band - aids.

By breaking your problem to first principles, you’ve stripped away the non - essentials and seen the naked truth of what’s going on. It’s empowering and sometimes surprising. You might feel a bit like a scientist of your own work, discovering that maybe what you thought was impossible is actually possible if you assemble the pieces differently. The habit of questioning “What must be true and what could be different?” unlocks innovation. Think back to our machine on the table, all parts laid out. Now you can reassemble it better, maybe even leaving some parts out or swapping in new ones. In the next chapter, we’ll take these fundamentals and use them to build something useful: a simple model that can guide decisions. First principles gave us the pieces; now we’ll learn to snap them together into a minimum working model of our challenges.