Topics
Push systems shove work into people; pull systems let people draw it when they're ready. The difference shows up in calendar pressure, blocker rates, and how often the team gets sick.

Pull is the difference between asking your team to commit to ten cards by Friday and letting them take the next card when they finish the current one. The first sounds productive; the second actually is.
Push: work is assigned in advance based on someone's plan or estimate. Monday morning the team gets handed a list of what to ship by Friday. The system optimises for the planner's view of the week. Pull: work waits in a backlog. People draw the next card when they finish the current one - no commitment beyond that. The system optimises for the actual rate the team can absorb. Same work, different mechanism, very different downstream effects.
Push is intuitive for managers and miserable for teams. Three reasons it persists: it gives the planner a sense of control; it produces a clean weekly status report; it matches how non-production work (announcements, customer commitments) shows up. The cost is invisible to the planner: when the plan misses (most weeks), the team carries the failure - either by staying late, by cutting quality, or by quietly absorbing the variance into next week's plan. The board's optimism becomes the team's unpaid overtime.
Calendar honesty. A pull system can't lie about throughput because the rate is set by what the team actually finishes, not by what someone wished they'd finish. Lower blocker rates. Pull systems give the team agency to refuse work that has structural issues (missing input, ambiguous brief); push systems force them to start anyway. Better recovery from disruption. When someone's sick, a pull system slows down evenly; a push system thrashes because the assigned-but-now-unstaffed cards become an emergency.
The pull discipline test
Look at this morning's first move. Did someone assign the day's cards to people, or did people take their next card from the backlog when they sat down? If it's the first, your board is a push system in kanban clothing. If it's the second, you're running pull and the board is doing its job.
Two cases where push is the right model. Hard customer deadlines that exist regardless of internal capacity (a wedding date doesn't move because the team had a slow week). The schedule is genuinely external; the team has to either stretch or refuse the work, but they can't pull-pace the deadline. Cross-team handoffs with strict SLAs: if your team is the input to another team's schedule, the second team needs a firm commitment they can plan against. The honest move there is to negotiate a realistic SLA based on observed throughput, then push to that, not to wishes.
{PRODUCT} is a pull-shaped board. The dashboard surfaces "next available card" per phase based on owner availability and WIP capacity; the team draws from the backlog rather than being assigned a week ahead. WIP limits enforce the pull discipline - cards can't be pushed into a phase already at capacity, the planner can't override the limit, the team's actual rate sets the rate. Hard customer deadlines are honoured by tagging the card with a delivery date and surfacing them at the top of the backlog so they're never accidentally deprioritised.
FAQ
Free plan, no credit card. We host in Germany. You can export and delete everything self-serve.
Read next
WIP limits, plainly: why constraining work-in-progress speeds the team up
What WIP limits do, when to set them, and the numbers that work.
Read
Phase durations vs estimates: a different mental model for production work
Why production teams are better off measuring the phase, not the item.
Read
Production board vs project management: knowing the difference
When work is *flow* through stages, not a *plan* with deadlines.
Read