What is the commitment point in a flow-based workflow, and what changes when an item crosses it?

middleshould knowfreq 46%

answer

A boundary in the workflow, not a meeting
Options one side, undertakings the other
Discarding is free before, costly after
Where an item is pulled into work

basics

~20 s

The commitment point is where a team undertakes to finish an item. Upstream of it an item is only an option that can be reordered or discarded; downstream of it the team has taken on delivering it.

solid answer

~50 s

The commitment point is the boundary in a workflow where an item stops being a candidate and becomes work the team has undertaken to finish. Everything upstream of it — requests, ideas, half-formed items — is an option: it can be reordered, reshaped or dropped entirely, and dropping it costs only the thinking already spent. Everything downstream is committed: the team intends to carry it to completion, and abandoning it now wastes real work. In a pull system the commitment point normally sits at the moment an item is pulled out of the queue of options into active work, which is also where the delivery clock a customer cares about starts. Drawing the line explicitly is what keeps the distinction honest — teams that never draw it end up treating every logged request as a promise, which is how a queue of options becomes a register of debts.

The **commitment point** is the boundary in a workflow where an item stops being a candidate and becomes work the team has undertaken to finish. Everything upstream of it — requests, ideas, half-formed items — is an **option**: it can be reordered, reshaped or dropped entirely, and dropping it costs only the thinking already spent. Everything downstream is committed: the team intends to carry it to completion, and abandoning it now wastes real work. In a pull system the commitment point normally sits at the moment an item is pulled out of the queue of options into active work, which is also where the delivery clock a customer cares about starts. Drawing the line explicitly is what keeps the distinction honest — teams that never draw it end up treating every logged request as a promise, which is how a queue of options becomes a register of debts.

code

pseudocode · 11 lines

pseudocode

POLICY: Options column  (upstream of the commitment point)
  - anyone may add an item here
  - items may be reordered, reshaped or discarded at any time
  - no delivery expectation is given to the requester
  - items untouched for 8 weeks are reviewed for discard

POLICY: Committed column  (downstream of the commitment point)
  - an item enters only by being pulled, never by being placed
  - the team undertakes to finish it
  - discarding it requires a decision made with the requester
  - the delivery clock for the item starts here

go deeper

for a junior

Learn the vocabulary: upstream of the commitment point an item is an option that may be dropped; downstream it is work the team has undertaken to finish. Be able to say which side a given item sits on and why.

for a middle

Explain where the line sits in a pull workflow — the moment an item is pulled from the queue of options into active work — and what the policy on each side says about reordering, discarding and what a requester is told.

for a senior

An interviewer expects the failure modes: commitment at intake, a line the team believes in but requesters do not, and a queue nothing is ever discarded from. Describe how you would make the boundary visible and what you would change first.

for a principal

Own the negotiation with the wider organisation. Late commitment is defensible only if you can say what it buys — option value, far fewer broken promises — and offer something in return, such as a stated worst-case wait before an item is considered.

Options and undertakings

Work arrives long before anyone can honestly promise it. Somebody has an idea, a customer complains, a partner asks for a change. Each of those is a candidate — and the useful property of a candidate is that it can be dropped. The commitment point is the place in the workflow where that stops being true.

Upstream of the commitment point an item is an option. It can be reordered, reshaped, merged with another item or discarded outright, and discarding it costs only the thinking already spent on it. Downstream of the commitment point the item is work the team has undertaken to finish. That is not a date and not a contract, but it is a real intention: the team means to carry this item to completion, and abandoning it now throws away work that has actually been done.

Naming the boundary does two things at once. It tells the team where its freedom ends, and it tells everyone else which items are promises and which are still ideas.

Where the line sits in a pull workflow

In a pull system the commitment point normally sits at the moment an item is pulled out of the queue of options into active work. That is a natural home for it: pulling is a deliberate act by the people who will do the work, it happens only when capacity exists, and it is visible on the flow board.

	Upstream of the commitment point	Downstream of it
What the item is	an option	an undertaking
Who may change it	anyone, at any time	the team, by agreement
Cost of discarding	the thinking spent so far	the work already done
What a requester is told	it is under consideration	it is being worked on
Delivery clock	not running	running

The last row deserves attention. The commitment point is where the elapsed time a customer experiences begins, because before it the team has agreed to nothing. How that duration is then measured and reported is a separate subject; what matters here is that its starting instant is a decision, and the decision is visible.

Why teams draw the line explicitly

It preserves option value. Everything learned while an item waits upstream is free information, and a large share of what any team logs turns out not to be worth building. Late commitment is how that value is captured.
It makes discarding legitimate. With no boundary, dropping an item feels like breaking a promise, so nothing is ever dropped and the queue becomes a monument.
It gives requesters a straight answer. "Not started, still an option, next selection is Thursday" beats a silence everyone reads as agreement.
It prevents accidental commitment. Without a line, an item becomes committed the moment somebody senior mentions it in a meeting.

Failure modes

Committing at intake. Every logged request is treated as a promise. The team now owes far more than it can deliver, and the option queue has become a debt register.
An invisible line. The team believes it commits late; requesters believe logging an item was the commitment. Both sides are surprised, repeatedly.
Never discarding. A commitment point only pays off if things are genuinely dropped on the upstream side. If nothing is ever dropped, the boundary is decoration.
Commitment by outsiders. Somebody outside the team moves items across the line. The team's capacity signal is bypassed and the pull rule is dead.

A worked example

The eleven-person team building a hotel housekeeping app is holding 47 logged requests. Under an explicit boundary only the 6 items currently pulled are commitments; the other 41 are options.

A partner integration deadline lands. The team moves that work to the front of the option queue and pulls it next, and the only real cost is the 6 in-progress items finishing first. Nobody has to break a promise, because 41 of those 47 items were never promised. Two weeks later, in the replenishment conversation, 9 of the remaining options are discarded outright — the integration made them irrelevant. Had the team committed at intake, all 47 would have been promises, and the same conversation would have been a negotiation with nine disappointed requesters.

What the commitment point is not

It is not a meeting, and it is not a label on a card. It is a boundary in the workflow with a written policy on each side of it. Nor is it a promise of a date: undertaking to finish an item says the team intends to complete it, not that it will complete it by Friday. Teams that conflate the two either refuse to commit to anything at all, or start promising dates they have no basis for.

## Options and undertakings Work arrives long before anyone can honestly promise it. Somebody has an idea, a customer complains, a partner asks for a change. Each of those is a candidate — and the useful property of a candidate is that it can be dropped. The **commitment point** is the place in the workflow where that stops being true. Upstream of the commitment point an item is an **option**. It can be reordered, reshaped, merged with another item or discarded outright, and discarding it costs only the thinking already spent on it. Downstream of the commitment point the item is work the team has **undertaken to finish**. That is not a date and not a contract, but it is a real intention: the team means to carry this item to completion, and abandoning it now throws away work that has actually been done. Naming the boundary does two things at once. It tells the team where its freedom ends, and it tells everyone else which items are promises and which are still ideas. ## Where the line sits in a pull workflow In a pull system the commitment point normally sits at the moment an item is pulled out of the queue of options into active work. That is a natural home for it: pulling is a deliberate act by the people who will do the work, it happens only when capacity exists, and it is visible on the flow board. | | Upstream of the commitment point | Downstream of it | |---|---|---| | What the item is | an option | an undertaking | | Who may change it | anyone, at any time | the team, by agreement | | Cost of discarding | the thinking spent so far | the work already done | | What a requester is told | it is under consideration | it is being worked on | | Delivery clock | not running | running | The last row deserves attention. The commitment point is where the elapsed time a customer experiences begins, because before it the team has agreed to nothing. How that duration is then measured and reported is a separate subject; what matters here is that its starting instant is a **decision**, and the decision is visible. ## Why teams draw the line explicitly - **It preserves option value.** Everything learned while an item waits upstream is free information, and a large share of what any team logs turns out not to be worth building. Late commitment is how that value is captured. - **It makes discarding legitimate.** With no boundary, dropping an item feels like breaking a promise, so nothing is ever dropped and the queue becomes a monument. - **It gives requesters a straight answer.** "Not started, still an option, next selection is Thursday" beats a silence everyone reads as agreement. - **It prevents accidental commitment.** Without a line, an item becomes committed the moment somebody senior mentions it in a meeting. ## Failure modes 1. **Committing at intake.** Every logged request is treated as a promise. The team now owes far more than it can deliver, and the option queue has become a debt register. 2. **An invisible line.** The team believes it commits late; requesters believe logging an item was the commitment. Both sides are surprised, repeatedly. 3. **Never discarding.** A commitment point only pays off if things are genuinely dropped on the upstream side. If nothing is ever dropped, the boundary is decoration. 4. **Commitment by outsiders.** Somebody outside the team moves items across the line. The team's capacity signal is bypassed and the pull rule is dead. ## A worked example The eleven-person team building a hotel housekeeping app is holding 47 logged requests. Under an explicit boundary only the 6 items currently pulled are commitments; the other 41 are options. A partner integration deadline lands. The team moves that work to the front of the option queue and pulls it next, and the only real cost is the 6 in-progress items finishing first. Nobody has to break a promise, because 41 of those 47 items were never promised. Two weeks later, in the replenishment conversation, 9 of the remaining options are discarded outright — the integration made them irrelevant. Had the team committed at intake, all 47 would have been promises, and the same conversation would have been a negotiation with nine disappointed requesters. ## What the commitment point is not It is not a meeting, and it is not a label on a card. It is a boundary in the workflow with a written policy on each side of it. Nor is it a promise of a date: undertaking to finish an item says the team intends to complete it, not that it will complete it by Friday. Teams that conflate the two either refuse to commit to anything at all, or start promising dates they have no basis for.

What does it cost a team to move its commitment point earlier in the workflow?
Committing sooner destroys option value: work the team would have discarded once it learned more is now work it has undertaken. It also lengthens the elapsed delivery time the team is accountable for, because the clock starts earlier. The gain is that requesters get a firm answer sooner. The price is less freedom to change your mind, so move the line earlier only where certainty is worth more than optionality.
A requester says an item is committed because it was logged three months ago. How do you answer?
Age is not commitment. If the item sits upstream of the commitment point it is still an option, and the honest reply is that it has not been started and may still be dropped. If the team has been implying otherwise, the fix is a written policy at the boundary and a replenishment conversation where discards are made out loud — not a silent promise nobody intends to keep.

Holding an option on a venue costs only the deposit if you walk away; signing the hire contract means you are paying for the hall whether the party happens or not.

saying these in an interview costs you the question

Treats every logged request as already committed work
Says the commitment point is a meeting, not a workflow boundary
Cannot name anything the team would ever discard
Thinks committed means a delivery date has been promised
Believes items become committed simply by getting old

What is the commitment point in a flow-based workflow, and what changes when an item crosses it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Options and undertakings

Where the line sits in a pull workflow

Why teams draw the line explicitly

Failure modes

A worked example

What the commitment point is not

▾common follow-ups2 questions

▾analogy~10 s

▾red flags5 flags

Options and undertakings

Where the line sits in a pull workflow

Why teams draw the line explicitly

Failure modes

A worked example

What the commitment point is not

answer

go deeper