What Feedback Loops Is (in Plain Terms)
Before you use Feedback Loops, it is critical to understand what kind of system it is - and just as importantly, what it is not.
Most misuse happens when people expect it to do a job it was never designed to do.
This section sets those boundaries explicitly.
What Feedback Loops Is
Feedback Loops is a facilitation system.
Its job is to help a group of people:
- surface real problems
- reduce ambiguity
- make decisions explicit
- stabilise business meaning
It does this by enforcing structure around:
- questions that must be answered
- decisions that must be made
- artifacts that must exist
- ownership that must be clear
Feedback Loops does not replace thinking. It forces thinking to happen in the open.
Feedback Loops Is a Decision System
At its core, Feedback Loops exists to manage decisions.
Every stage culminates in a decision:
- advance
- revise
- stop
Artifacts exist to support those decisions. They are not the goal.
If you treat the artifacts as deliverables instead of decision support, the system will degrade quickly.
What Feedback Loops Is Not
Feedback Loops is not:
- a software development methodology
- a requirements framework
- a design system
- a technical architecture guide
- a replacement for engineering judgement
It does not:
- design systems
- choose solutions
- optimise implementations
- guarantee outcomes
If you expect it to do any of those things, you are using the wrong tool.
Where Feedback Loops Intentionally Stops
Feedback Loops intentionally stops at Strategic Domain Design.
This boundary is deliberate.
The purpose of Feedback Loops is to make it possible to describe the business clearly enough that design can begin without guesswork.
Once that description exists, Feedback Loops has done its job.
What happens next belongs to Practical Domain Design:
- Strategic Domain Design (business description)
- Technical Domain Design (technical translation)
Feedback Loops supports the first half and hands off cleanly.
Why Feedback Loops Does Not Do Design
Design requires:
- tradeoffs
- creativity
- technical judgement
- context-specific decisions
Those activities cannot be safely automated or standardised.
What can be standardised is the work required before design:
- clarifying problems
- aligning intent
- stabilising language
- exposing constraints
Feedback Loops exists to do exactly that.
The Kind of Work Feedback Loops Is Good At
Feedback Loops is most effective when:
- problems are messy
- stakeholders disagree
- terminology is unstable
- consequences are real
- downstream work is expensive
In these situations, ambiguity is the enemy.
Feedback Loops exists to make ambiguity visible and resolvable.
The Kind of Work It Is Bad At
Feedback Loops is a poor fit for:
- trivial tasks
- well-understood, repeatable work
- changes with no meaningful tradeoffs
- work where failure is cheap
Using it here will feel slow and bureaucratic - because it is unnecessary.
A Critical Expectation Reset
Feedback Loops will not make work easier at the beginning.
It will:
- slow you down early
- force uncomfortable conversations
- surface disagreement
- require decisions to be made
It does this so that work later can be:
- faster
- cheaper
- more predictable
- less contentious
That tradeoff is the point.
The Mental Contract
If you choose to use Feedback Loops, you are agreeing to one thing:
You will not move forward while meaning is still unstable.
If that constraint feels unacceptable, do not use the system.
If it feels necessary, continue.
Next, we will look at The Shape of the System - how the stages fit together and why their order matters.