When a product decision keeps waiting

Which decision is keeping the work waiting?

A blocked task can hide several different problems. Nobody may own the decision, the named owner may lack authority, important evidence may be missing, or the business may have deliberately parked the choice. Start by writing the decision in one sentence. “Improve onboarding” is a topic; “Choose whether the next release includes self-service onboarding” is a decision.

Record when it began waiting and which work depends on it. Waiting time helps make the cost visible, but age alone does not tell you what to do. A reversible choice affecting one team can be treated differently from a commitment that is costly to undo.

Find the owner and the authority

Name the person who can choose, the people whose input is necessary and the limit of that authority. If nobody owns the choice, assign an owner before asking for another estimate. If the owner cannot commit the budget or change the process, identify the person who can. Avoid treating a meeting invitation as decision authority.

Ask the owner to confirm the question and its consequences. A delivery team can clarify the work, but it should not have to invent a commercial choice through implementation.

Bound the next evidence-gathering step

List the available options and what remains unknown about each. Separate information that could change the decision from information that would merely make the presentation more complete. Give the next action a person and a date. If an experiment is appropriate, state what it can establish and what remains outside it.

For a modest reversible decision, a convergence date can prevent endless option gathering. For a consequential commitment, choose a named review and the evidence it requires. Two sprints can be a useful prompt to inspect a waiting choice; it is not a universal deadline or a reason to rush a high-consequence decision.

Fictional example: self-service onboarding

A small service business is considering self-service onboarding. The decision has waited since 6 October because the delivery team does not know whether identity checking must happen before an account is created. The affected work is the signup flow and support procedure. These details are invented for teaching.

The operations lead owns the process choice; the service owner approves changes affecting customer access. Options are staff-led onboarding, a self-service request with staff confirmation, or immediate self-service access. The missing evidence is whether staff can confirm eligibility within the promised service window.

The next action is for the operations lead to walk through five fictional requests with the support team by Friday. The service owner will then choose the first release boundary. If the walkthrough cannot resolve the access question, the team parks immediate access and revisits it after an agreed eligibility rule is confirmed. No launch or outcome is implied.

Copy a waiting-decision note

Use the same fields for a live question. Keep the reason for waiting beside the action so that a future reader can tell whether the decision progressed or was deliberately parked.

Decision:
Owner and authority:
Waiting since:
Affected work and consequence of waiting:
Options:
Missing evidence that could change the choice:
Smallest next action:
Action owner:
By when:
Decision/review date:
If parked, reason and revisit trigger:

Close the loop visibly

At the review, record the choice, its reason, remaining assumptions and who needs to act. If the evidence is still insufficient, agree the next bounded action or an explicit parking decision. This is a practical way to structure a conversation; it is not a validated audit service or a promise of faster delivery.

Bound an evidence-gathering pilot

Carry the reason into the next team

Consider how a commercial commitment can constrain the next decision