Feedback Needs A Decision

Teams often say they need more feedback. Usually, that is not quite true. What they need is feedback that can change the next decision.

Raw feedback is easy to collect. A tester spots an unexpected behaviour. A customer asks a question. A designer notices a mismatch. An engineer finds an awkward edge case while connecting two pieces of work. These are valuable observations, but an observation is not yet a direction.

The trouble begins when the observation is treated as if it were already a requirement. Someone remembers a discussion differently. A ticket title is close enough to sound right. A mock-up explains one state but not another. A change is made quickly, and later the team discovers that it solved a slightly different problem.

That sequence is not a failure of effort. It is a failure to turn uncertainty into a decision while the people who can resolve it are present.

The useful unit of feedback is small and structured. It should answer four questions.

What did we observe? Keep this factual. “This field is required in a scenario where the current setting suggests it should not be” is better than “the configuration is broken”. The first sentence creates a shared starting point. The second prematurely chooses a diagnosis.

What outcome is intended? State the rule in everyday language, without jumping to an implementation. For example: “The person completing this step should only be asked for information when the local policy requires it.” That gives product, operations, and engineering something concrete to agree on.

What evidence would prove the outcome? Name the scenario, action, and observable result. If success cannot be described, it cannot be reliably tested. This is where vague approval becomes a usable acceptance criterion.

Who makes the call when there is a trade-off? Many delivery delays are not technical delays at all. They are decisions waiting for an owner. The owner does not need to know every detail; they need enough context to choose the rule the team will implement and test.

This sounds like extra process, but it normally removes process. Without it, the same question travels through chat, tickets, review comments, test notes, and meetings. Each retelling adds interpretation. The work looks busy because it is moving, but it is circling an unresolved decision.

A practical habit is to end every significant feedback conversation with a decision note. It can be three lines:

1. We observed this behaviour in this scenario.
2. We have decided the expected behaviour is this.
3. We will verify it by doing this and seeing this result.

If the answer is not known, write that down too: “Decision needed before implementation continues.” That is far healthier than allowing an assumption to hide inside a task description. A visible unknown can be escalated. An invisible assumption is usually found later, when changing it is more expensive.

The same pattern improves code review. A review comment should not merely say that an approach feels risky. It should identify the invariant at risk: compatibility, data correctness, security boundary, performance expectation, or operational behaviour. Once the invariant is clear, the conversation can focus on evidence and options rather than personal preference.

It also improves release readiness. A release is not complete because all planned changes have merged. It is complete when the team has a credible answer to: what should happen, how will we know, and who will decide if the evidence is ambiguous? That standard makes small releases calmer. It gives testers a meaningful target and gives engineers a fair way to distinguish a defect from an open product question.

There is a subtle leadership benefit as well. Asking for the decision behind feedback is not dismissive. It is a way of respecting the feedback enough to make it actionable. It acknowledges that the person who noticed the issue may not be the person who owns the rule, and that both perspectives are needed.

The next time a useful observation arrives, resist the urge to turn it straight into a fix. First turn it into a decision that somebody can test. That small pause is often the fastest route to work that survives contact with reality.