A Dependency Blocker Board for Marketing Work in Progress

A task list can make every item look equally actionable even when some depend on a price decision, a product photograph, a legal review, or a landing page that is not ready. This method addresses shows what work cannot proceed and what specific decision would unblock it. It can be scaled down for a solo operator or split across staff when several people contribute.

The operating rule

A designer has produced the campaign layout, but the owner has not confirmed whether the offer applies on weekends. The design is repeatedly revised because the unresolved business rule is hidden inside comments. This example is hypothetical. It illustrates the decision pattern rather than claiming a measured customer result.

Run the process in this order

1. Define what counts as ready to start for each recurring work type.
2. Use explicit states such as ready, active, blocked, awaiting approval, and accepted.
3. For blocked items, write the exact dependency rather than “waiting.”
4. Assign the dependency to the person who can resolve it, even if that person is not the task creator.
5. Limit how much work can be active at once so unfinished drafts do not pile up.
6. Escalate only after the agreed decision time has passed and the deadline is at risk.

Risks and limits

A board does not solve a missing decision by itself. If the same blocker recurs, clarify decision rights or move the decision earlier in the process.

How to tell whether it works

Measure blocked age, number of reopened tasks, active work count, and time spent waiting for inputs.

Working record template

Task | readiness criteria | state | blocker | resolver | next check | deadline impact | acceptance evidence

Example of a proportionate decision

A local event campaign might be blocked by venue capacity, not by the copywriter. Put the capacity confirmation in the critical path before polishing the headline.

Make the dependency visible

A blocked task should not remain ownerless simply because the missing decision belongs to someone senior. The task creator can still record the question, deadline, and consequences of waiting, while the decision maker owns the answer. This keeps the production team from disguising a dependency as slow progress. If the same question blocks several campaigns, resolve it once in the relevant policy or source record and link future tasks to that decision. The board should reveal recurring friction, not merely display a growing list of overdue work.

Controls for the less obvious cases

When several tasks depend on the same answer, link them to one decision record. This avoids multiple staff members asking the same question and receiving slightly different answers.

A blocker should describe the missing decision in terms the resolver can answer. “Need owner input” is weak; “confirm whether the offer applies to Sunday bookings” gives the decision maker a bounded question.