Tools and methods you may already use

You may already use tools and methods like these in your work. Bring that experience with you. Choose a method for the question it can help answer, then carry its evidence and limitations into the reasoning. These methods have their own purposes; using one does not automatically demonstrate first principles thinking.

FPT means First Principles Thinking. First Principles Reasoning (FPR) is related wording, and FP is a shortened reference to first principles. We use FPT consistently in this course. The abbreviations below identify supporting methods and concepts, rather than alternative names for FPT.

BrightPath: selecting a tool for a question

Function analysis: distinguish “clarify the client’s need” from “hold a meeting.” Examine the properties that make clarification possible, including understandable language, access to relevant context and a way to resolve ambiguity.

Fishbone and 5 Whys: explore why some requests lack context. Consider unclear prompts, an unsuitable channel or an unknown information need. Ask what observation would distinguish those explanations; do not treat a completed diagram as a finding.

FMEA: consider a recommendation based on missing context. A possible effect is an unsuitable next step. Identify prevention, detection and response measures, and test whether they work for the intended users.

A3: summarize the outcome, evidence, alternatives, proposed test and owner. The decision record should expose uncertainty rather than conceal it behind a polished format.

These are fictional teaching applications, not completed analyses or service results. This overview introduces connections; it does not teach every method in full or confer method-specific competence.

Practice: choose a tool, then name its limit

Within the existing W2A discussion, choose one unresolved question. Name a useful tool, the output it would produce, the evidence still needed, and what the tool cannot establish. You may also conclude that a direct observation or conversation is more useful. No additional scored question is introduced.

How the tools support FPT, and how FPT improves their use

The relationship works in both directions. A method can help organize evidence, expose risk or develop an alternative. First principles thinking helps a team decide what the method must answer, challenge the premises it carries, and interpret the output within its limits.

FMEA: begin with the function and the consequence

How FMEA helps: it makes potential failures, effects and proposed controls visible while a team rebuilds a process. It can identify a consequential uncertainty for a test and a condition that must be monitored after implementation.

How FPT improves its use: begin with the required function and intended user outcome. Examine the parts, their relevant properties and their dependencies before listing failure modes. Challenge whether the current form, approval or job title is necessary to the function. Give each rating and assumed control an explicit basis. Revisit the analysis when a different operating mechanism changes the failure paths.

BrightPath example: “meeting not booked” describes a failure of today’s method. The required function may be helping a client obtain suitable guidance and a usable next step. A broader failure mode is advice based on inadequate context. Identify the effect on the client, possible causes, preventive checks, how missing context would be detected and who responds. Compare how conversation, written exchange and guided intake manage that risk. An FMEA identifies questions and actions; a rating alone does not show that a control works.

Root cause analysis: explain the failure, then reconsider the design

How RCA helps: it investigates causal explanations for an observed problem and helps distinguish symptoms from contributing conditions. Fishbone diagrams and 5 Whys can organize that investigation.

How FPT improves its use: define the effect precisely, test competing explanations and separate observations from inference. Then ask which functions and constraints are necessary, rather than automatically restoring the existing arrangement.

BrightPath example: a question arriving without sufficient context could reflect an unclear prompt, a channel mismatch, or a user who cannot yet identify the needed information. Investigate those alternatives. Even if an unclear prompt contributes to the problem, “write a longer form” is only one candidate response. A short clarification conversation or staged intake may achieve the same function differently. Compare and test them.

The same discipline applies to the other methods

• Function analysis and MECE: clarify functions and organize the investigation. FPT checks the grouping boundary and preserves properties, interfaces and dependencies.
• TRIZ: generates ideas around a contradiction. FPT checks whether the stated conflict is real, which requirements are justified and whether a proposed mechanism can work.
• TOC: focuses attention on system performance. FPT challenges how the system, goal and supposed constraint were defined and asks for evidence that the limiting factor has been identified.
• A3: makes a decision story reviewable. FPT strengthens the trace from outcome through claims, alternatives and evidence, including what would change the recommendation.
• Zero-based and critical thinking: reopen commitments and scrutinize reasoning. FPT turns that challenge into a model of necessary functions and testable alternatives, while retaining applicable obligations.

Working prompt: What question does this tool answer? What assumptions does it bring? What does its output establish, and what evidence is still missing?

These examples and connections are Colabmo teaching applications. The reference table links to the professional and author sources for each method.

Parts, properties and investigation tools

· W2A practice sheet

Individual parts and their properties

Let’s make the habit explicit. Break the thing down into its individual parts. Then examine the properties of each part. Properties are attributes, not smaller components. For a physical object, useful properties might include dimensions, shape, material, mass, stiffness or resistance to heat. For a business process, the parts may include information fields, decision rules, permissions, people’s capabilities and interfaces between systems. Their properties might include accuracy, freshness, availability, capacity or the scope of an authorization.

Consider a service request. Treating it as one document can hide the important differences. Separate the customer identifier, requested start date, supporting evidence and authorization. Then examine each. Does the identifier uniquely match the customer? Does the date mean requested or confirmed? How old can the evidence be before it needs checking? What decisions does the authorization actually permit? A property becomes useful when we explain how it affects the required function. Keep dependencies and interactions visible as well. The parts only produce the outcome when they work together.

Properties make alternatives possible

A part’s familiar name can hide the properties that matter. A field called start date could contain the requested date, an agreed date, or the date someone happened to enter the record. The same label does not guarantee the same meaning. Write the property precisely, identify how you know it, and explain which function depends on it.

Next ask which properties an alternative must preserve. A decision may need a valid authorization with a defined scope. That requirement does not yet establish that a particular person must sign a particular spreadsheet. Another mechanism could establish the same authority, provided the applicable rules permit it and the evidence supports the design. Stop decomposing when further detail no longer changes a decision or a useful test. Then reconnect the parts. Examine what information crosses each boundary and what happens when a part is missing, late or wrong.

5 Whys: deeper questions

We now begin the section on Five Whys.

Five Whys is a repeated questioning technique. Ask why a specific problem occurred, then investigate the explanation and ask why that condition existed. The name is a prompt, not a requirement to stop at exactly five questions. It is useful when a team is accepting the first explanation or repeatedly treating the same symptom.

In our FPT work, write each answer as a hypothesis until appropriate evidence supports it. Ask what record, observation or test would distinguish that explanation from another one. If two conditions could contribute, branch the inquiry. If the next answer is a guess, record the gap and investigate rather than filling a fifth line. Avoid ending with a character judgment such as people are careless. Ask about the conditions, information and capabilities that shaped the action. A neat chain alone does not establish causation.

https://asq.org/quality-resources/five-whys

A possible chain to investigate

Here is a fictional example, not a completed investigation. The reported problem is delayed customer activation. A possible first explanation is that activation waits for a start date. Check the case timeline. Why is that date missing? Perhaps the request contains no date. Inspect the original request rather than relying on someone’s memory. Why could the request progress? Perhaps the intake form allows a blank. Test the actual form and its routing. Why does it allow that? Perhaps one generic form serves request types with different needs. Compare the rules and configurations for those types. Why was the field left optional for this type? Perhaps nobody defined the minimum decision evidence for each type. Review the design decisions and ask the accountable owner.

Every link could be wrong or incomplete. A date might have been captured and then lost at an interface. A customer might be unable to confirm it yet. Those alternatives deserve investigation. Do not present the fifth answer as the root cause merely because it occupies the last row.

https://asq.org/quality-resources/five-whys

Fishbone: a wider set of possible causes

We now begin the section on Fishbone diagrams.

A fishbone diagram, also called a cause-and-effect or Ishikawa diagram, organizes possible causes around one clearly stated effect. It helps a cross-functional team explore more than its first explanation. Define the effect, the measurement boundary and the period before brainstorming. Then choose categories that fit the process. The categories on this slide are business-process prompts, not a mandatory taxonomy.

For delayed activation, consider information, workflow, roles, systems, rules and demand. Could the date have an unclear meaning? Could requests wait in batches? Could an exception lack an owner? Could an interface lose a value? Could requirements differ by request type? Could peaks exceed capacity? Each branch is a possibility. Add other causes and connections when warranted. Use repeated why questions to explore a promising branch, then move the material claims into the evidence ledger. A populated fishbone records the team’s thinking. It does not show which explanation is true or how much each contributes.

https://asq.org/quality-resources/fishbone

Investigation supports first principles thinking

We now begin the section on Connecting investigation to first principles thinking.

Choose the tool for the question. A fishbone is helpful when the team needs a wider view of possible contributors. Five Whys helps examine the reasoning within a branch. Either can come first, and neither is compulsory for every redesign. Both can help identify claims to investigate.

First principles thinking then asks a further question: what must the process accomplish, and which properties must its parts have to accomplish that? In our fictional case, the necessary function might be establishing a usable, agreed start date before an activation commitment. Investigate whether that is actually required for every request type. Compare different mechanisms, such as collecting the date at intake or deriving it from an authorized scheduling agreement. Evaluate the evidence, exceptions and constraints for each. Do not assume that understanding why today’s process fails has proved the best future design.

https://asq.org/quality-resources/five-whys · https://asq.org/quality-resources/fishbone

W2A: parts, properties and causes

We now begin the section on Practice with parts, properties and causes.

Allow fifteen minutes for this practice. Choose a bounded process problem, or use the fictional activation example. First, take three minutes to identify its parts. For each part, record a property that matters, how you know it, and the function that depends on it. Spend four minutes building a fishbone of possible causes. Choose categories that help your team think. Spend four minutes examining one branch with repeated why questions. Label unsupported answers as hypotheses and record the evidence needed for each link. Use the final four minutes to state a necessary function and propose two different ways to achieve it.

Pause now. Before resuming, ask a partner to challenge one causal link.

For the debrief, assess the reasoning rather than whether you drew our diagram. A useful answer separates a part from its properties, links a property to a function, preserves an important dependency, and gives each causal claim an evidence check. If evidence is missing, a clear investigation plan is a valid outcome. Avoid rewarding a confident fifth answer that the team cannot support.

You now have a functional model and a way to classify claims. Carry both forward. Next, we will examine which constraints apply and build principles that a redesign must satisfy.