First Principles Thinking: Rebuild the Process from What Must Be True

Start by questioning what the process must accomplish

A customer waits eight days for an account to become usable. The organization responds with familiar ideas: send more reminders, buy a workflow tool, or ask the approval team to work faster. Each proposal may have merit. But before choosing one, the team needs to answer a more fundamental question: what must happen for the customer to receive a usable, properly authorized service?

First Principles Thinking provides a disciplined way to answer that question. It examines the premises beneath a process, separates necessary functions from inherited arrangements, and builds alternatives that can be explained and tested. Its value lies in making the reasoning visible enough to challenge.

For a business-process team, this means looking closely at statements such as “every request needs three approvals,” “customers must complete this form,” or “the system cannot support that.” Some will turn out to be justified. Others will combine a legitimate purpose with a mechanism that no longer serves it well. The work is to discover which is which.

The Colabmo course First Principles Thinking for Business Process Redesign develops that practice through lessons, cases, worksheets and coached application. This article explains the method and shows how a facilitator can help a team use it without taking over the team’s decisions.

Give business premises the right status

First principles reasoning has a long philosophical history. In Posterior Analytics, Aristotle connects demonstration with primary premises. A modern business workshop needs a more provisional working stance: people, policies, information and operating conditions can change. The team should be explicit about what it knows, what it assumes and what is binding within the decision at hand.

Consider four statements. “Twelve of the last forty completed requests were returned” is an observation about a sample. “Activation requires an authorized agreement” may be a binding rule if its source applies. “Customers will submit better information through a portal” is a hypothesis. “We want one point of contact” is a preference or a chosen design requirement. Treating all four as established facts will produce weak reasoning even if everyone agrees.

A working principle sits above a particular mechanism. If an organization must establish the right customer identity and authority before activating a service, a defensible design condition is that those pieces of evidence must be connected to the activation decision. That does not by itself require a spreadsheet, a weekly committee, or a particular sequence of departmental handoffs.

A principle should have a visible basis, a defined scope and a challenge test. Ask whether a plausible acceptable design could violate it. If the answer is yes, the statement may need to be narrowed or reclassified as a preference. “Never ask for the same information twice” sounds appealing, but correction or independent confirmation may sometimes be justified.

The practical task is to find foundations strong enough to support a decision while preserving the uncertainties that could change it. The evidence-ledger lesson turns that distinction into a repeatable habit.

Move from the outcome to a testable design

Colabmo uses six stages as a working teaching method: frame, decompose, ground, rebuild, test and learn. This is a course framework, not a claim that all FPT practitioners use the same standardized sequence. Teams revisit earlier stages when new evidence changes the problem.

Frame the outcome

Name the recipient, the triggering event, the required end condition and the decision owner. “Implement a portal” is a proposed solution. “Give an eligible customer a usable service account and a confirmed start date” describes an outcome. Define how quality, elapsed time and effort will be observed. Preserve incomplete, rejected and abandoned requests in the evidence rather than allowing them to disappear from the story.

Decompose the necessary functions

Identify what must be accomplished before assigning functions to departments or systems. A request process may need identity, eligibility, authority, a decision, communication and retained evidence. “Finance signs the spreadsheet” combines a function, an actor and a tool. Separate them. Ask which information each decision requires and whether a sequence is logically necessary or merely inherited.

Ground the reasoning

Classify material claims, inspect their sources and identify the consequence of being wrong. Separate a control’s purpose from its current implementation. A committee may protect against unauthorized commitments, provide specialist judgment, or do both. Understanding those purposes is essential before proposing a replacement. A current obligation remains applicable until someone with authority changes it.

Rebuild from the foundations

Generate different arrangements of the necessary functions. Vary authority, timing, information ownership and exception handling. Centralized triage, delegated decisions and customer-assisted preparation are structurally different options; three tools reproducing the same flow may not be. Trace each option back to the premises that make it acceptable.

Test the assumption that matters most

Identify what would make the design fail. If the proposal depends on independent checks running together, test that independence. If it depends on customers providing complete information, test actual comprehension and completion. A small simulation can expose a missing dependency, but it cannot establish real-world elapsed-time savings or adoption.

Learn and decide

Compare observations with the stated hypothesis. Record what changed in the team’s understanding, what remains uncertain and which decision is now justified. Possible outcomes include revising the design, abandoning it, or expanding the test. A useful experiment can disprove a popular idea before the organization invests heavily in it.

Three ways to make the reasoning visible

Duncker’s candle problem: a familiar role can hide a useful function

Imagine a candle, matches and a box of thumbtacks beside a cork board. How could you support the candle on the board so wax would not reach the table? In the familiar classroom version, emptying the box and mounting it as a tray reveals a use that its role as a tack container can hide. This illustrates functional fixedness: difficulty seeing beyond an object’s familiar use.

Colabmo’s lesson uses a sketch-only adaptation, with the solution hidden until learners have tried it. It draws on Duncker’s On Problem-Solving and Adamson’s later repetition, without claiming to reproduce the experiments. Recognizing the answer is not a competence test.

The business connection is direct: a form may collect evidence, route a decision and record authority. Naming those functions makes it possible to question the form while preserving what matters.

The brick: look beyond its familiar use

Start with “How many uses can you find?” Then “Look past the label”: describe the brick’s properties without naming it, and connect each suggested use to a property. A paperweight uses mass; a bookend also needs a stable shape. The playful suggestion “slowing down cars” is a nod to the brick-basket crosswalk meme, not a separate exercise.

At work, apply the same curiosity to a favorite tool, form or meeting. What function does it serve, and which properties make it useful? Generating ideas expands the search; checking their underlying assumptions helps the team decide what to test.

Apollo 13: change the interface while preserving the function

During Apollo 13, command-module CO₂-removal canisters could not directly fit the lunar module’s different interface. Ground specialists developed and tested an adapter from materials available aboard; the crew assembled it using instructions. NASA’s account and photograph document the “mailbox” arrangement.

Our first principles reading asks: what function must continue, which constraints are real, what resources have useful properties, and what evidence must precede use? This interpretation does not claim NASA used Colabmo’s method. The historical account highlights the work of a ground team and the crew; movie scenes are not the source.

For a business handoff, the parallel might be preserving customer identity and decision evidence across incompatible systems. Compare a controlled translation, a shared record and a redesigned intake; then test the uncertain interface. An analogy can help generate questions. It cannot establish that a proposal meets your requirements.

The course places the candle exercise in lesson 02, and the brick and Apollo 13 examples in lesson 06, with matching workbook and facilitator prompts.

The individual parts, and their properties

A useful habit is to break a thing down into its individual parts, then examine the properties of each part. A service request contains information, rules and permissions. A start date has a meaning and format. Evidence has a source, scope and age. An authorization has an owner and a defined reach. Connect each relevant property to the function it supports, and keep the dependencies between parts visible.

This creates more precise design questions. A process may need an agreed start date before making a commitment. That does not establish that it needs today’s form or handoff. Different mechanisms may supply the same necessary information, provided their properties and applicable constraints support the outcome.

Two tools for investigating the current process

5 Whys uses repeated questions to examine an explanation in greater depth. It can help when a team repeatedly addresses a symptom or accepts its first answer. The number of questions depends on the inquiry. Record each proposed explanation, the evidence that could support it, and an alternative that could also explain the observation. Branch when necessary, and stop guessing when the evidence runs out. ASQ: Five Whys.

A fishbone diagram organizes possible causes around a defined effect. It helps a team consider a wider set of contributors. In business processes, useful prompts may include information, workflow, roles, systems, rules and demand. The branches record hypotheses to investigate. A completed diagram does not establish which causes are true. ASQ: Fishbone diagrams.

For example, a delayed activation might involve a missing start date. Repeated why questions could explore how the value went missing. A fishbone could reveal other possibilities, such as batch waiting or an interface problem. Check these possibilities against records and tests. Then use FPT to reconsider the required function and compare mechanisms that could achieve it. Investigation of today’s failure and design of tomorrow’s process are related tasks, each needing its own reasoning.

Take apart a service: does the client need a meeting?

In the fictional BrightPath Advisory example, every client books a 45-minute consultation before receiving professional-learning guidance. The sponsor asks for faster booking. First principles inquiry asks what the client needs to understand, decide or do.

The candidate outcome is relevant guidance, understood limits and an appropriate next step. Break the service into the client's question, context, adviser capability, communication channel, recommendation and follow-up commitment. Then examine the properties that let each part support a function.

Part	Relevant properties	Function	Evidence or check
Client question	Clarity, ambiguity, urgency	Understand the intended decision	Original question; client restatement
Supporting context	Relevance, accuracy, freshness	Establish applicability	Source/date; confirm material gaps
Adviser capability	Competence, scope, limits	Interpret and justify guidance	Relevant work samples; peer review
Communication channel	Access, privacy, clarification	Exchange enough meaning	Realistic user trial; assisted path
Recommendation	Fit, rationale, actionability	Support an informed next step	Review and client explanation
Follow-up commitment	Owner, trigger, completion	Recover from uncertainty or change	Recorded commitment and follow-through

For example, a recommendation needs explainable fit to the client's situation. That requirement supports the functions of establishing context and exposing material uncertainty. A bounded principle follows: before claiming the guidance applies, identify its material basis and gaps. A gap may call for clarification, a conditional answer or referral. The principle does not establish that every client needs a video call.

Compare a prepared live consultation, asynchronous expert review with targeted clarification, and guided self-service within an evidenced boundary. Test access, understanding, wrong fit and clarification effort. An existing applicable answer may make another consultation unnecessary. A favorite channel is still a hypothesis.

Suppose three of six deliberately selected trial users cannot express their need through a written prompt, and two of those three can do so in a short conversation. These invented observations expose a design assumption; they do not establish a population rate or a universal winner. Revise the boundary and next test. Keep client effort, unresolved needs and abandonment visible alongside staff time.

The same principle applies to overall capacity. Under explicitly simplified assumptions, twelve arrivals and ten completions each day add two requests daily to backlog. Faster routing alone cannot remove that mismatch. Reconnect parts and properties to the behavior of the whole service.

Try the advisory-service case and reasoning chain.

Examine an onboarding process

The following is a fictional teaching example, not a Colabmo client engagement or a claim of achieved performance.

Harbor Services activates standard business service accounts. A sample of forty completed requests shows a median of eight business days from initial receipt to activation. Twelve were returned for missing information. The process moves through sales email, a coordinator spreadsheet, finance review, operations review and activation.

The team initially wants to automate the spreadsheet. First principles inquiry changes the discussion. Its policy requires verified identity and an authorized agreement before activation. Finance must determine eligibility and operations must confirm capacity. The policy does not prescribe the spreadsheet or serial review. The team now has a more precise question: which decisions depend on which evidence?

One option retains specialist decision rights but gives both functions a shared evidence packet and starts independent checks together. Another gives qualified generalists authority for standard cases and sends exceptions to specialists. A third improves customer preparation while retaining the existing authority structure. Each option has different assumptions about capability, authority and behavior.

Suppose the team chooses to investigate the first option. It should not claim that parallel review will necessarily shorten service time. It first needs to establish whether the checks can be independent and whether shared information is reliable. Historical cases can be replayed to find missing dependencies, including cases with incomplete information and exceptions.

A later live pilot would need defined eligibility, a credible comparison, quality and workload measures, stop conditions and an authorized decision owner. The team must also acknowledge that its original sample excludes open and abandoned cases. A faster experience among completed requests could coexist with a worsening backlog.

The result of the workshop is therefore a defensible recommendation and an evidence plan. Actual improvement remains something to demonstrate. The full onboarding lesson walks through the reasoning and its limits.

Help experts challenge their own assumptions

Subject-matter experts know the work, exceptions and consequences. The facilitator’s contribution is to keep their reasoning explicit and their participation balanced. When the team jumps to a solution, the facilitator returns to the function it should perform. When it cites a rule, the facilitator asks for the source and scope. When it makes a causal claim, the facilitator asks what evidence would distinguish it from another explanation.

Useful interventions are specific. “We have always done it this way” invites “What outcome did that arrangement protect?” “That is best practice” invites “Under what conditions does it work?” “The system cannot do it” invites “Which capability is missing, and who can verify the limit?” These questions create a path to evidence rather than a contest of opinions.

The facilitator should also inspect their own influence. A question can smuggle in a preferred answer: “Wouldn’t one centralized team be simpler?” already promotes a design. “What different arrangements could satisfy these functions?” leaves the choice with the team. Facilitators can contribute expertise, but should label the shift from process guidance to content advice.

Respectful challenge matters because participants must be able to reveal uncertainty and correct themselves. Edmondson’s research on team psychological safety provides relevant evidence about learning behavior. In practice, silent writing, pairs before plenary discussion, and invitations to frontline staff can make important information easier to surface. They do not remove the need for evidence.

When the team cannot resolve a premise, assign an investigation and keep the affected recommendation conditional. Repeating the argument until time expires adds little. The facilitator guide includes intervention practice, observation criteria and coaching conversations.

Protect the outcome and the scope

First principles work can reveal that the original process boundary is too narrow. An intake redesign may depend on unclear decision rights elsewhere in the organization. Record the dependency and ask the appropriate owner to resolve it. Do not silently turn a focused exercise into a company-wide redesign.

Before comparing designs, distinguish conditions that must be satisfied from preferences that can be traded. A proposal that bypasses required authorization is not rescued by a high score for speed. Where feasibility is unknown, report it as unknown. Weighted scores are useful only when the underlying judgments and evidence are visible.

A familiar design can survive this examination. FPT does not require novelty or an attack on every established practice. It requires that important choices can be justified. Existing process-improvement tools may help measure or implement a sound design; benchmarking may suggest candidate mechanisms. The distinguishing practice is returning to the foundation and exposing the inference from that foundation to the proposed process.

Continue the reasoning after the workshop

The hardest test often comes when participants return to everyday work. A system limitation is discovered, an exception becomes politically difficult, or the first pilot result is disappointing. Coaching helps the team revisit its premises instead of merely defending the workshop’s favorite idea.

A useful coaching cycle reviews one real decision packet, investigates a disputed assumption, prepares or critiques a test, and then examines the result. At each review, ask what the team believed, what it observed and what it now proposes. Keep learning evidence distinct from task completion.

Begin with a bounded process and accessible evidence. Write the desired outcome without naming the current solution. List the functions needed to achieve it. Find the claims that most strongly constrain the design, and ask what would change if one proved false. This creates a practical starting point for the deeper work.

The Colabmo course provides eight chapters with fifteen core lessons, BrightPath Advisory and two further business-process cases, an assessed capstone, a ten-question knowledge check and four coaching session plans. The companion workbook helps participants carry their reasoning from the first question through to a reviewable test recommendation.