The Practice Loop

Your team gathers a lot of feedback. There is a fortnightly retro, a metric dashboard someone checks each morning, a satisfaction score that lands in a channel, a customer council that meets each quarter, and a standup that surfaces blockers every day. By any reasonable audit, the team has feedback loops.

And yet the same problems keep coming back. The retro raises the same friction it raised last month. The dashboard moves and nobody can quite say why. A customer says the thing three customers said last year. The team is not short of feedback. It is short of loops that actually close.

That is the quiet version of the feedback problem: not too little signal, but signal that never makes it all the way back around to change the next move.

The mistake: treating feedback as collection

Most teams, asked whether they have good feedback loops, answer by listing what they collect. We run retros. We have analytics. We do quarterly research. We read every support ticket. All of that is real, and all of it is inputs.

But a loop is not a pile of inputs. A loop is a circuit. It only counts as a loop if what you see at one point changes what you do at the next, and then you see the result of that change, and it changes what you do again. Collection is the easy half. The link that makes it a loop – the part where a signal actually alters the next decision, out loud, where the team can see it – is the half that quietly goes missing.

When that link is missing, you get all the cost of gathering feedback and almost none of the learning. The ritual runs. The data accrues. Nothing turns.

The map

Think of one move your team makes, and follow it around a loop with four positions.

• Act – you make a move into the world. Ship a change, run a session, make a call, put words in front of a customer.
• Signal – something comes back. A behaviour changes, a number moves, a support pattern forms, a teammate raises an objection, a customer goes quiet.
• Sense – the team turns that signal into a reading. Not a number, a meaning: what it says about the move, whether it is noise or a real pattern, what it implies for what comes next.
• Adjust – the reading changes the next move. You do something different because of what you learned, and that difference becomes the next Act.

The loop is only a loop when Adjust feeds back into Act. Everything before that is preparation.

It helps to remember the difference between information and knowledge here. A ticket moving across a board, a report exported, a score posted in a channel – that is information travelling. It can move without anyone learning anything. Knowledge is what the team actually updates about the product and the customer when the loop closes. A status update is information. A closed loop is knowledge.

Where loops break

The map is most useful for spotting which link is open. There are four common breaks, one at each edge.

Act with no Signal. You ship into the dark. The change goes live, and nobody instruments it, follows up, or goes back to look. The move was made; the result was never watched. This is the loop open at the top, and it is easy to miss because shipping feels like progress on its own.

Signal with no Sense. The data piles up and nobody synthesises it. Dashboards, tickets, survey scores, call notes – all collected, none turned into a reading. Everyone has a number; nobody has an interpretation the team agrees on. This is the most flattering break, because a wall of signal looks like rigour.

Sense with no Adjust. The retro that changes nothing. The team names the lesson, writes it on a board, feels the relief of having said it out loud, and then the next cycle behaves exactly as the last one did. This is the most common break of all, and the most corrosive, because people slowly learn that saying the true thing leads nowhere.

Adjust with no Act. Endless replanning. The team keeps reworking the plan, the strategy, and the backlog, but never puts a fresh move in front of a real user to test it. It feels like learning because it is busy and thoughtful. It is motion without a move, so the loop never actually turns.

Loops run at different speeds

A team is never running one loop. It is running several at once, at different speeds, and it is worth naming which one you are in.

• A fast delivery loop: did this change work as intended? Days.
• A slower discovery loop: are we solving the right problem for the right people? Weeks.
• A slow strategy loop: is this still the bet worth making? A quarter or more.

Most trouble comes from mistaking a fast loop for a slow one. Shipping small improvements every week feels like learning, and the delivery loop may genuinely be closing. But if the discovery loop never turns, you are iterating efficiently on the wrong thing. Speed on the inner loop can hide a broken outer one. Staged rollouts help here for the same reason: try a change with a few users, then more, then everyone, so the signal comes back while the change is still cheap to undo.

A worked example

A team ships a redesigned onboarding flow to lift activation.

• Act: the new flow goes live.
• Signal: activation ticks up two percent on the dashboard, support sees fewer "how do I start" questions, and a couple of sales calls mention that users felt rushed.
• Sense: here the loop opens. Is two percent real or seasonal? The dashboard number gets celebrated, the support drop gets noticed, and the sales comments sit unread in a channel. Nobody reconciles the three signals into one reading.
• Adjust: with no shared reading, the team calls it a win and moves to the next feature.

The move was made and signals came back, but because Sense never happened, the team never learns the actual lesson: faster start, shallower understanding, a cost that will show up at renewal rather than at activation.

Now close the loop. Someone synthesises the three signals into one honest reading – "people start faster but understand less" – which changes the next move: add a light orientation step and watch week-two retention, not just day-one activation. That new move is the next Act, and the loop turns.

How to try this week

Pick one recent move. A shipped change, a decision, a session. Trace its loop out loud with the team.

1. Name the move in one line. What did we actually do?

2. Ask what signal we looked at afterwards. If the honest answer is "we shipped and moved on," the loop is open at the top. Decide now what you will go back and look at, and by when.

3. Ask who turned that signal into a reading. Not a number posted in a channel, a meaning the team agrees on. If nobody did, the signal is just noise you are storing.

4. Ask what we did differently because of it. If nothing changed, you had a report, not a loop.

If that is too much to run across everything, start with one recurring ritual. For the next retro or metric review, add a single column: what will we do differently next cycle, and who owns it. That one column is the link most loops are missing.

What to watch for

The first trap is mistaking cadence for closure. A loop that turns on time but never changes anything is just a very punctual open loop. How often the ritual runs is not the same as how fast the team learns.

The second is collecting signals you have already decided to ignore. If the direction will not change regardless of what comes back, running the survey is theatre, and people quickly learn that their feedback goes nowhere. Better to close a few loops honestly than to open many you will not act on.

The third is closing loops only inside one head. If the PM quietly notices and adjusts but the team never shares the reading, the learning leaves when that person does. A closed loop the whole group can see beats a private one, because it survives the next reorganisation.

Seeing practice through feedback loops

I keep coming back this quarter to the idea that product work goes wrong before the artefacts look wrong. A team can have every feedback mechanism running – dashboards, retros, research, a customer council – and still not be learning, because gathering feedback got mistaken for closing a loop.

The practice is not to add another feedback source. It is to close the loops you already have: to make sure that what you see changes what you do next, out loud, where the team can see it happen.

The next time someone says the team has good feedback loops, ask the quieter question: what did we change last cycle because of what we saw? If the answer is nothing, the loop is still open.