The Working Loop: Build, Observe, Adjust

The fastest teams are not always the teams that type the fastest. They are often the teams that can turn an assumption into something observable, learn from it, and make the next decision without losing the thread.

A working loop has three plain parts:

1. Build the smallest thing that can answer the question.
2. Observe what the system and its users actually do.
3. Adjust the next step using that evidence.

None of those parts is novel. The leverage comes from making the loop explicit. If a team cannot name the question a change is meant to answer, the work may still be useful—but it is harder to learn from.

A useful planning note can be remarkably small: “We believe reducing the setup steps will help more new teams finish configuration. We will know by comparing completion and support signals for two weeks.” That sentence connects implementation to a question without pretending the team already knows the answer.

It also exposes a common failure mode. If the proposed change cannot produce evidence, it may be too broad, too indirect, or simply maintenance work wearing a product hypothesis as a costume. Maintenance is valuable. It just deserves a different reason.

Delivery pressure tends to compress observation first. A feature ships, the next ticket begins, and the result becomes a vague impression remembered at planning time. A small amount of instrumentation and a scheduled review can preserve the learning without creating a measurement bureaucracy.

Observation includes more than analytics. Error logs, support conversations, deployment behavior, latency, accessibility checks, and the effort required to operate the change all reveal something. The right evidence depends on the question. A dashboard full of unrelated counters is less useful than one signal the team has agreed to inspect.

The goal is not to measure everything. It is to keep the important assumption from disappearing after deployment.

Put the review on the calendar before the work ships. Otherwise “we will check later” usually becomes “we remember it seemed fine.” The review can be ten minutes if the question and evidence were chosen well.

Changing direction after learning is not evidence that planning failed. It is evidence that the loop worked. The practical habit is to make changes cheap enough that a new fact can improve the plan rather than threaten it.

Adjustment can mean continuing, stopping, narrowing, or investing further. Those are all successful outcomes when they follow better information. Teams get into trouble when the amount already spent becomes an argument for spending more.

Not every change needs an experiment. A security patch, standards upgrade, or obvious defect may have a known destination. The loop is most valuable when the team is uncertain about behavior, usability, feasibility, or cost.

The size of the loop should match the cost of being wrong:

Short loops do not eliminate judgment. They give judgment fresher material to work with.