The PM discipline built for work that moves faster than a two-week sprint.
Scrum was built for a world where a sprint takes two weeks because the work takes two weeks. AI-assisted development breaks that assumption — a scoped build can go from spec to shipped in an hour. Closed-Loop PM is the discipline for that world: a project system where the board updates itself in the same cycle as the work, not on a lag a human has to remember to close.
The name borrows from control theory, not marketing. A closed-loop system feeds its own output back into the process automatically, correcting in real time — an open-loop system runs blind until someone checks in. Most PM tools are open-loop: the board is only as accurate as the last time someone remembered to update it. Closed-Loop PM closes that gap by having the same system that executes the work also write the update back, in the same pass. It pairs with Spec-Driven Development on the build side — the spec defines what gets built; Closed-Loop PM makes sure the record of what got built is never more than one cycle behind the truth.Start a Conversation →
How it works
Spec the unit of work
Scoped tight enough to execute in one sitting — an hour, maybe two — not a two-week epic. This is the Spec-Driven Development half: the spec is the contract for what gets built.
Build against the spec
AI executes, with a human steering — reviewing direction, not rubber-stamping after the fact. The review happens here, at the point it actually matters.
Verify before it's marked done
A real check — build passes, output confirmed against the spec — not "looks done." Nothing moves to the next step on a guess.
Write the update back immediately
Task status, comment, artifact — logged in the same pass as the work, by the same system that did the work. Not a separate reporting step waiting to be forgotten.
Repeat, compounding
The record and the work never drift apart. A status meeting becomes unnecessary — the board already says what's true.
Traditional PM vs. Closed-Loop PM
| Dimension | Scrum / XP | Closed-Loop PM |
|---|---|---|
| Cycle length | ~2 weeks (sprint) | As fast as the work itself — often under an hour |
| Status reporting | Standups, retros, manual board updates | Automatic, written in the same pass as the work |
| Lag between work and record | Hours to days | Effectively zero |
| What it requires | Humans remembering to update the tool | The executing system and the tracking system sharing one loop |
You're looking at it. This site's build tasks moved through ClickUp in the same cycle as the code shipped — the board was never more than one verification step behind the actual work.
FAQ
Isn't this just CI/CD for project management?
Close, and that's not an accident. CI/CD closed the loop between code and deployment — no more manually shipping a build and hoping someone remembers to tell people it went out. Closed-Loop PM closes the loop between execution and the record of execution. Same principle, one layer up the stack.
What does this actually save me?
Status meetings, mostly. If the board is never more than one cycle behind reality, you don't need a standup to find out what happened — you can just look. That's real time back, not a productivity slogan.
Doesn't removing the human review step introduce risk?
It doesn't remove the human — it moves where the human sits. Review happens at the spec and the verification step, not at the reporting step. The part that gets automated is the part that was never load-bearing anyway: writing down what already happened.
Do we need to replace ClickUp or our existing PM tool?
No. Closed-Loop PM is a discipline, not a platform — it runs on the PM tool you already have. ClickUp is what we've built this practice on, but the principle holds anywhere the executing system can write back to the tracker directly.