Forcing Function

011 min

Forcing Function at a Glance

• What it is: A deadline or constraint a team imposes on itself to force a decision, not just pressure.
• Origin: Coined by Don Norman for a narrower idea — a design that blocks a physical error.
• Produces: A dated, public commitment, like a launch date or a written press release, that scope has to fit.
• Fails when: The work itself needs time no deadline can compress, like research or discovery.

021 min

What Breaks Without a Forcing Function

Without a forcing function, a decision with no natural deadline gets put off, because deferring almost always looks like the cheaper option in the short term. Planning Fallacy already explains part of why: a team's own estimate of when the harder call finally gets made keeps sliding, because every sprint feels like the one where there will finally be time to settle it, and there never quite is.

The specific failure this produces is not indecision in general. It is a trade-off that stays open because closing it feels costly and leaving it open feels free. A team debating whether to cut a feature from a release can debate it for months if nothing forces an answer, because the debate itself has no visible cost, so it continues. A team with no real launch date can keep polishing a feature nobody outside the company has used yet, because "not yet" always looks safer than "ship this version."

The real cost is not the delay by itself. It is that the decision gets made anyway, later, under worse conditions: a scope cut two days before a date someone else imposed, decided by whoever is still in the room during the final hour, instead of a decision made on purpose with time to think it through.

032 min

How a Forcing Function Works

A forcing function has three moving parts: a decision being avoided, a constraint that attaches a real cost to avoiding it, and a trigger date or event that makes that cost land. Take a subscription app whose team cannot agree whether onboarding needs three steps or one; the debate has run for a quarter with no end in sight. Nothing changes until the product lead books a demo with real prospective customers for a specific date. Once that date exists on other people's calendars, the team cannot show three half-built paths at once. They have to pick one and make it work, because the audience is real, the date does not move, and showing up with nothing working costs the team's credibility in a way that another week of debate never did. The demo did not make the onboarding flow better by itself; it made not deciding more expensive than deciding.

Two things have to be true for this to work. The constraint has to be real: missing it must cost something the team actually cares about, whether that is a public audience, spent money, or a commitment made to someone outside the team. And the constraint has to be specific enough that only one kind of action satisfies it. "We should ship soon" forces nothing, because no particular decision discharges it; a booked demo, a printed press release, or a signed contract does, because there is exactly one thing that has to be true by that date. A team that resists the constraint because of work already invested is usually fighting a sunk cost problem, not evidence that the constraint itself was wrong.

A forcing function also does not replace the work of deciding what to build in the first place. A team already using JTBD to understand what job the product does still needs something separate that forces the exploring to stop and the shipping to start — discovery and delivery are different problems, and a forcing function only helps with the second one.

The same mechanic fails when the work behind the decision cannot be compressed no matter who is watching. A constraint changes how fast a team decides between options it already understands. It does not change how long research, discovery, or a genuinely unsolved technical problem takes — a different failure, covered under Forcing Function done badly, below.

041 min

Where Forcing Function Came From

The term comes from outside product management. Don Norman introduced "forcing function" in The Design of Everyday Things (1988) as a human-factors idea: a feature of a physical or procedural design that blocks a person from completing an action carelessly. The Interaction Design Foundation's glossary states the underlying idea plainly: "A forcing function is an aspect of a design that prevents the user from taking an action without consciously considering information relevant to that action."

The example most often cited is the automated teller machine. Early ATMs dispensed cash before returning the card, so people walked away with their money and left the card behind. The redesign made card return a required step before cash comes out — what a later review of the fix calls "an interlock forcing function (Norman, 1988) ... requiring the user to remove the card before the cash is dispensed." That is a physical sequence, not a deadline: it makes one particular mistake impossible.

The product-management sense used through the rest of this entry is a later, looser borrowing: not a design that blocks an error, but a deadline a team sets on itself to block indefinite delay. Both share one mechanism: a real constraint that removes an easy way out.

051 min

Real-World Examples

Amazon's product teams write a press release before they write any code, and the constraint of the format is the forcing function. The press release is capped at one page, has to be written in plain language a customer would use, and cannot contain internal jargon or a list of features hedged as "and more." A team that has not decided what the product actually does cannot fill that page, so the format itself forces the prioritization decision that a longer planning document would let the team avoid.

As the Working Backwards process is described by the people who documented it: "Writing a press release is a forcing function to ensure that the creator of the new product idea is focused on the customer." The press release is followed by an FAQ, typically two to five pages, split into questions a customer would ask and questions about feasibility, cost, and risk that only the team needs answered. The method has been Amazon's standard practice for new products since the early 2000s and was set out in detail in Working Backwards, the 2021 book by former Amazon executives Colin Bryar and Bill Carr.

What makes the press release a forcing function rather than just a template is the one-page limit. A ten-page brief can hold every feature anyone proposed without choosing between them. One page cannot.

062 min

A Second Case: The Apollo Deadline

A forcing function does not have to come from inside a team's own process. On 25 May 1961, President John F. Kennedy told the United States Congress the country would land a person on the Moon and bring them home safely "before this decade is out." That sentence became NASA's forcing function for the rest of the 1960s, and it worked by exactly the same mechanism as an internal one-page press release: it converted an open-ended engineering problem into a decision that had to be made by a fixed date, in public, with no way to quietly extend the deadline.

The space historian John Logsdon has traced what that constraint actually decided. "By setting a firm deadline, Kennedy put NASA in the position of finding a technical approach to Apollo that gave the best chance of meeting that deadline," he writes, and "this in turn led to the development of the Saturn V launcher, the choice of the lunar orbit rendezvous approach for getting to the Moon, and the design of the lunar module spacecraft optimized for landing on the Moon." NASA did not choose lunar orbit rendezvous because it was the best long-term architecture for spaceflight; none of that hardware suited any mission that came after Apollo. NASA chose it because it was the fastest credible path to the one date that mattered.

The variable that changes between the two examples is who imposes the constraint. Amazon's product teams choose their own forcing function and could, in principle, change the format. Kennedy's deadline was chosen for NASA, stated in public, and effectively impossible to reverse without a political cost the agency could not accept. A self-imposed forcing function is easier to set and easier to quietly abandon; an externally imposed one is harder to set and much harder to escape once it exists.

072 min

How to Set a Forcing Function This Week

A forcing function is something you build, not something you wait for.

1. 1

   Name the decision you keep deferring.

   Write down the actual trade-off, not the symptom. "Should this feature ship in v1 or v2" is a decision; "we need to move faster" is not.

2. 2

   Pick a constraint that makes deferring costly.

   A date on a calendar other people can see, a document sent to people outside the team, or a step that cannot be undone once taken. The constraint has to cost something real if it is missed.

3. 3

   Make it visible to people who did not create it.

   A deadline only you know about is not a forcing function, because you are also the only person who can quietly move it. Put the date on a shared calendar. Send the one-page document to the people who will read it.

4. 4

   Decide in advance what has to be true by the constraint

   , not just that something has to happen. A booked customer demo only forces a decision if the team agrees beforehand on what "ready" means for that demo. Cutting scope this way also does some of the work Paradox of Choice describes: a team carrying three half-built options is not just slower than a team with one, it is often less sure of what it is even trying to do.

5. 5

   Hold the constraint once it exists.

   A forcing function that moves every time it becomes inconvenient teaches the team that it will always move. After that, missing it costs nothing, so it stops changing what anyone does.

The artifact you should have by the end of this is small and concrete: one dated commitment, written down somewhere other people can see it, with an explicit definition of what has to be decided by that date. Not a plan to be more disciplined. A specific date, a specific decision, and a specific audience who will notice if it slips.

082 min

Forcing Function Done Badly

A forcing function fails a specific way: it assumes the missing ingredient is urgency, when the missing ingredient is time the work genuinely needs. Fred Brooks made the classic version of this point about adding people to a late software project, and the same logic applies to compressing a process with a deadline: "The bearing of a child takes nine months, no matter how many women are assigned." A launch date does not make user research faster, does not make an unsolved technical problem solved, and does not make a genuinely undecided strategic question answerable by Friday. Applying a forcing function to that kind of work does not produce a good decision under pressure; it produces a bad decision under pressure, delivered on time.

The second failure is quieter: a forcing function with no real cost for missing it is not one. A launch date that has already slipped twice, with no consequence either time, stops constraining anyone's behavior, because the team has learned, correctly, that the date is negotiable. The constraint only works while missing it costs something the team cares about — a real audience, spent money, a public commitment. Once a team learns a deadline is decorative, setting a new one does not fix that; only a constraint with a real cost attached does.

The tell for both failures is the same: the deadline moves and nothing bad happens. When that has already occurred twice, the fix is not a stricter version of the same deadline. It is a different kind of constraint, or an honest admission that the work needs the time it needs.

092 min

Forcing Function vs. Nearby Concepts

Forcing Function (human factors) vs. Forcing Function (product management). These are the same phrase carrying two different jobs. Norman's original sense is a property of a design that blocks a physical mistake before it happens — an ATM that will not release the card-holder's cash until the card is out. The product-management sense is a deadline or commitment a team imposes on itself to block an indefinite delay. One prevents an error; the other prevents avoidance. Reading a product article that cites "forcing function" as Norman's design term, or the reverse, is the single most common way this concept gets misapplied.

Not every deadline is a forcing function. A date nobody enforces, with no real cost for missing it, is just an estimate that failed.

?7 questions

Questions people ask

§7 sources

Sources