Set content work-in-progress limits around your review capacity

On Monday, a founder has six AI drafts waiting for review and an hour available to edit. Generating four more drafts is easy. Finding the product facts, checking the claims, and deciding which piece deserves publication are still unfinished work.

Content work-in-progress limits address that mismatch by making active commitments visible and limiting new starts when the team cannot finish what it already has. They are especially useful when AI drafting capacity is much larger than human review capacity.

The numbers in this article belong to a fictional editorial week. They illustrate decisions, not a benchmark for how much any founder should publish.

Decide when a content item has actually started

An idea in a backlog is not the same commitment as a commissioned article. A title written on a sticky note may need no attention for months. A draft awaiting a source check already carries a decision that someone must resolve.

Choose a visible starting point. For this example, work starts when the founder accepts an article brief and commits review time to it. It finishes when the article, image, and metadata have passed the team’s review and form a usable publication package.

The boundary could be different in another operation. A team responsible for publishing may finish only when the piece is live and verified. What matters is that everyone counts work against the same boundary.

The Kanban Guide defines work in progress as items between a workflow’s started and finished points. It calls for explicit control of that work and connects new selection to available capacity. The editorial example here applies that principle to a small content operation; it is not a complete Kanban implementation.

Count assets consistently. If an article is finished but its required image is missing, the package in this example remains active. Calling the writing task done is useful locally, but it does not make the deliverable ready for the next person.

Choose a limit you can explain

The fictional founder decides to experiment with no more than two article packages actively in review. That number is a starting hypothesis based on the time they have reserved, not a productivity target.

One package needs factual review. The other needs its example rewritten. Together they fill the available review slots. A third brief can remain in the backlog without pretending that it is being advanced.

If the founder routinely cannot finish even one package, lowering the limit may expose a scope or capability problem. If review slots stay empty while finished work is needed, the constraint may be earlier in research or drafting. The limit should help reveal the work, not become a number defended regardless of circumstances.

Do not derive the limit from how many drafts AI can generate in a session. Drafting speed says little about the number of claims a person can responsibly check or how much original thinking an article needs.

A useful limit has an owner, a counted unit, and a response when it is reached. Without that response, the number is just a label on the board.

When the lane fills, help an existing piece finish

In the example, the founder opens the first article and finds that its central product claim cannot be verified from current documentation. The piece is blocked pending a decision from the product owner.

That blocked package still occupies one of the two review slots. Moving it to a hidden “waiting” list would make the visible lane look healthier without reducing the unfinished commitment.

The founder can now make a real choice. They can obtain the missing fact, narrow the article so it no longer depends on the claim, or explicitly withdraw the piece from the active commitment. Each action changes the work in a way that renaming a column does not.

Withdrawal should have a reason and a re-entry condition. “Resume after the feature status is confirmed” is more useful than “later.” Preserve the draft and evidence so future work does not repeat the same investigation.

Meanwhile, the second package can move forward. The founder rewrites the example, checks the final image, and prepares the approved files. A review slot becomes available because useful work finished.

Treat urgent work as a visible tradeoff

On Wednesday, an important product correction needs a short update. It may deserve attention ahead of the planned article. A work limit should not stop a necessary correction, but the exception should remain visible.

Record which commitment is delayed and who made that choice. If the update requires the same reviewer, it consumes the same scarce capacity even when the content is short.

Repeated exceptions are evidence about the system. Perhaps the team needs reserved capacity for corrections. Perhaps the weekly article commitment is too large. Perhaps requests called urgent are really unplanned preferences that need a clearer intake decision.

Do not create a permanent exception lane with unlimited work. That allows the backlog to grow under a more respectable name. A small team benefits from saying what it is postponing when something else takes priority.

AI can help summarize the active queue or identify missing review inputs. It should not silently promote new topics because they are easy to draft. The decision to start work belongs to the operating policy and the people accountable for the output.

Read Friday’s results through finished work

At the end of the fictional week, the founder has one approved article package, one corrected product update, and one withdrawn article awaiting a confirmed fact. Those outcomes are more informative than the number of documents generated.

Review the active items and ask what prevented completion. Was it evidence, unclear scope, visual production, or an unavailable reviewer? Name the delay precisely enough to change something.

Keep a small record of when work entered the active system, when it finished, and why it waited. If item types differ greatly, separate them before comparing. A brief product correction and a researched tutorial should not be treated as interchangeable evidence of capacity.

A short experiment cannot establish a universal improvement percentage. It can show whether the queue became easier to understand and whether the chosen limit exposed a recurring obstacle. Use that observation to decide the next adjustment.

For example, repeated waits for product facts may justify confirming those facts before accepting a brief. Repeated image revisions may justify an earlier composition review. Neither problem is solved merely by commissioning more articles.

Keep the idea backlog cheap

An active-work limit does not prevent collecting ideas. It prevents an idea from becoming an invisible promise to finish a draft soon.

Store a backlog entry with enough context to reconsider it later, such as the reader problem, a useful source, and why it might matter. Avoid turning every promising headline into a full draft that then demands maintenance.

Before selecting the next piece, confirm that the topic is still useful, its evidence is available, and someone has capacity to review the finished package. An old idea does not gain priority simply because it has been waiting longest.

For the next review cycle, try one explicit rule. When the review lane is full, new drafting waits unless an owner records a deliberate exception. Use the available effort to finish, narrow, unblock, or withdraw an existing piece. The value of the limit lies in that decision, not in the appearance of an orderly board.