Skip to main content

First-principles thinking

First-principles thinking helps us look beyond accepted practice without dismissing the experience behind it. The goal is not permanent debate. It is traceable reasoning, a clear decision, and a shorter path to useful evidence.

The operating algorithm​

Use this sequence when designing a product, process, or consequential change:

  1. Meet the person and learn the work. Understand the human outcome, real workflow, rules, exceptions, and judgment already present.
  2. Define the observable improvement. Name the condition or rate that should change and why it matters.
  3. Question every requirement. Identify its source, owner, evidence, and protected outcome.
  4. Delete what does not serve the outcome. Include unnecessary steps, fields, approvals, interfaces, variants, and meetings.
  5. Make the remaining complexity feel simple. Clarify choices, consequences, and next actions.
  6. Run the shortest responsible test. Match evidence and safeguards to the change's reversibility and potential harm.
  7. Accelerate the proven flow. Reduce queues, batches, handoffs, and decision latency only after the path works.
  8. Automate stable, understood work. Keep people informed, capable of intervention, and in control.
  9. Write the learning back. Update the requirement, design, test, documentation, checklist, or tool so the next attempt starts further ahead.

The order matters. Optimizing or automating an unnecessary step makes waste faster and harder to change.

Challenge requirements responsibly​

Every consequential requirement needs an accountable source. Classify it as a law or regulation, security or safety control, observed user need, technical constraint, interface contract, assumption, or preference. Expertise contains hard-earned knowledge; expose its reasoning rather than dismissing it.

Use this record in an RFC or project document:

Requirement:
Protected outcome:
Source:
Accountable owner:
Type: law | security | user evidence | technical constraint | assumption | preference
Supporting evidence:
What fails if removed:
Last reviewed:

A requirement survives because its protected outcome and evidence remain valid, not because its source is senior or anonymous. Revisit settled requirements only when there is new evidence, a changed constraint, or a different intended outcome.

If you cannot explain the problem simply, keep investigating. Draw the flow, use an analogy, or teach it to someone unfamiliar with the domain. The goal is not to sound simple; it is to understand deeply enough to remove unnecessary complexity.

The test​

Did we discover a better question and turn the answer into useful service?

Guidance type: Working agreement
Owner: Company