Most PM workflows have a built-in assumption baked in before any discovery starts: *something will ship.* The brief gets written. The spec gets drafted. The sprint gets kicked off. The question is never "should we build?" — it's "what should we build?" Halt is the competency that breaks that assumption. It's the judgment that the correct answer to a product opportunity is: not us, not now, possibly not ever.
That sounds like a small thing. It isn't. Halt is arguably the rarest practiced competency in the Map skill because the organizational pressure runs entirely against it. Teams are staffed to build. Roadmaps are built to fill quarters. Stakeholders bring requests and expect delivery receipts. The PM who stands at the start of a planning cycle and says "I don't think we should work on this at all" is fighting an entire system's worth of momentum — and doing it before there's even a prototype to point at.
What Halt specifically tests isn't pessimism or conservatism. It tests whether you can distinguish between "this problem is real and ours to solve" versus "this problem is real, it exists in the world, and either it doesn't need us or our team would generate more value doing something else." The competency lives in that gap.
Beginners confuse Halt with caution. It's not caution — it's clarity. A PM who halts well has done the work. They've looked at the opportunity, run the numbers, checked the fit, identified what else the team could be doing instead, and landed on a clear non-build position. That's not risk aversion. That's the hardest call in product.
citation
PL Standard v3.1 · Map · Halt
Markdown form: [PL Standard v3.1 · Map · Halt](https://pragmaticleaders.io/framework/competencies/halt)
the four levels
Anchored at every rung. The blockquote at each level is panel-authored and pulled live from the rubric — edit anchors via the panel tooling and they appear here.
L1Developing
flags "we shouldn't build this" signals only after a senior teammate names them first; does not identify halt conditions independently.
you'll see this when…
the PM builds anything they're handed because "someone senior asked for it" is treated as sufficient justification
scope decisions are framed entirely around what to include or cut, never whether to start
opportunity cost of building goes unexamined — the team doesn't ask what they're *not* doing by doing this
common failure mode: the PM conflates taking a request with making a decision. Receiving a request and evaluating a request are different acts. L1 treats them as the same.
L2Competent
flags low-demand or duplicative build requests and recommends stopping; defers when the business case is ambiguous or a stakeholder pushes back.
you'll see this when…
the PM can name what they're trading away when committing to a build — the conversation has opportunity cost in it
they push back on low-confidence opportunities before spec-writing, asking for more evidence
they bring the "why build at all" question to planning, even if they don't always win it
common failure mode: the PM raises the question but defers the answer. "We should think harder about whether to build this" becomes a standing note that never resolves. Raising the concern is necessary; landing a position is the competency.
L3Proficient
spots unviability conditions before work begins and walks teammates through the reasoning so they can make the call independently next time.
you'll see this when…
the PM kills opportunities in pre-spec, with a clear and documented rationale the team can stand behind
they distinguish between "the problem is real" and "the problem is ours to solve" — and name that line explicitly
they can redirect team energy toward a higher-leverage bet immediately after a halt, so stopping one thing doesn't feel like it just created a vacuum
common failure mode: the halt is clean but the redirect is weak. "We're not building this" lands well; "here's what we're doing instead and why it's better" doesn't follow fast enough. The team is left uncertain what the halt was for.
L4Expert
kills work others won't touch by naming the real cost of building it, then reframes the team's default from "how do we build this?" to "should we?"
you'll see this when…
the PM creates an organizational norm — teams bring pre-spec halts as a standard deliverable, not just a judgment call one person makes
they can halt in politically charged situations: when an exec owns the request, when a partner is waiting, when the team is eager — and hold the position with evidence, not just assertion
they use halts to generate creative force: "we're not solving it this way" frees the team to think about what *is* worth solving
common failure mode: the expert becomes a no-machine. A PM who has exercised strong halt judgment can drift into reflexive skepticism — every new opportunity pattern-matches to a previous bad bet. The result is a team that stops bringing ideas because the answer is always "why would we do that?" The L4 trap is calcification. Expert halt requires remaining genuinely open to the cases that pass the filter, not just sharpening the filter until nothing gets through.
how to develop it
The most leveraged move is to make the halt decision explicit and visible as a practice — not something that happens by accident when an idea dies, but something you run deliberately at the start of planning. That means building a "no-build brief": a single-page document that states the opportunity, the case for building, the case against, and the opportunity cost — and committing to a non-build position in writing.
Read. Start with [Roadmap Prioritization](/manual/core-skills/strategy/roadmap-prioritization) — the section on the "no list" is directly relevant. The idea that a roadmap without explicit nos is a wish list is the foundation of Halt. Also read [Product Vision and Strategy](/manual/core-skills/strategy/product-vision-strategy) for the discipline of defending a direction by naming what doesn't fit it.
Practice. Scenarios that present product opportunities at the spec stage and ask whether to proceed — specifically the GTM and strategy scenarios where "halt the expansion" or "halt the build" are presented as live options, not just rhetorical ones. Find scenarios where the answer isn't obvious and the team is building momentum.
Write. The Brief prompt that tests Halt most directly: *"You're two weeks into a new quarter. The roadmap includes a feature that was added at the last planning meeting. You've done early discovery. What's your recommendation, and what does it cost you to not build it?"* The evidence you look for: does the person ever land "don't build"? Do they distinguish between "costs of halting" and "costs of building the wrong thing"?
Coach yourself. Ask once a quarter: *"What did we build this cycle that we shouldn't have? What did we build that no one used, or that we've already killed, or that absorbed capacity without generating value?"* The answer is the training data for a sharper halt filter.
how to spot it in others
In planning, they frame the build/no-build question explicitly — you can see them running the test, not just defaulting to spec
When they kill an opportunity, they can explain what the team is doing instead and why it's a better use of the quarter
They separate "the customer has this problem" from "we are the right thing to solve it" — and don't slide between the two
In 1:1s, they bring decisions they halted and their reasoning, not just decisions they made and shipped
When pushed by a stakeholder, they hold the non-build position with evidence rather than softening it to "we'll keep it in the backlog"
three failure modes we see often
The consolation prize build. The PM or team runs the analysis, sees the halt is right, but the team wants to build *something* — so a smaller, safer version of the idea gets built instead. The consolation prize exists to give the team something to do, not because it solved anything. It costs capacity, creates maintenance debt, and muddies the product surface. The halt was right; the team just couldn't sit with it.
The political halt. The PM halts not because they've decided the problem isn't theirs to solve, but because a political signal — a competitor moved, a budget shifted, an executive changed priorities — makes stopping feel safer than proceeding. This looks like halt judgment from the outside, but it isn't. A political halt is reactive. Real halt is proactive and evidence-based. The failure mode: the team loses confidence in the PM's read, because the call clearly came from outside rather than from actual analysis.
The perfectionist halt. The PM waits for certainty they'll never have. Every signal has noise in it. Every opportunity has risk. The perfectionist halt is the refusal to take a clear non-build position until the data is unambiguous — which means it never comes. The result isn't discipline; it's paralysis wearing discipline's clothes. A clean halt, stated with the evidence you have and with acknowledged uncertainty, is more valuable than six more weeks of discovery.
Worth is the upstream question: among everything we could build, what's most worth building? It operates in a world where *something* is being built and asks which thing. Halt comes earlier — it asks whether to build at all. You can arrive at a good Worth decision and still have a Halt question: "these are our top three options, but is any of them actually worth the team's quarter?" Worth is selection; Halt is the veto before selection.
Kill operates on something already in motion. A spec has been written, a team is working, investment has been made. Kill is the judgment to stop despite sunk cost. Halt is pre-commitment — before any significant investment exists. The practical difference: Kill is harder emotionally (you're stopping something real); Halt is harder organizationally (you're stopping something that has momentum but no artifact yet). Both are no-build conclusions; the stage is different.
what good looks like in the wild
A product team at a mid-size B2B SaaS company entered Q1 planning with four initiatives on the table. The PM — three years in, recently promoted to senior — was running the process. One of the four initiatives had been on the roadmap in some form for two quarters: an in-app analytics dashboard customers had been requesting in support tickets and NPS verbatims.
Most PMs would have built it. The signal was there. The requests were real. The engineering lead had already scoped it at three weeks of work. The PM ran it through halt anyway.
What they found: three enterprise customers had been asking for the dashboard — the same three customers, repeatedly, who had also asked for six other features that hadn't been prioritized. The broader base hadn't mentioned it. A lightweight export to CSV had been available for six months; usage was low. The underlying need — "help me understand what's happening in the product" — was real, but every signal pointed to a different intervention: better onboarding, not more dashboards. The PM wrote a one-page no-build brief, walked the team through it, and proposed redirecting the three-week slot to an onboarding improvement that addressed the same underlying need for the whole customer base, not just the three vocal accounts.
The stakeholder who owned enterprise relationships pushed back. The PM held it. The team redirected.
By Q2, the onboarding improvement had measurably reduced time-to-first-value for new accounts — the year's single highest-impact metric improvement. The three vocal enterprise customers got a follow-up explaining the reasoning and a roadmap date for the dashboard in a future quarter. None of them churned. Two said the onboarding change had actually addressed the friction they were experiencing.
The analytics dashboard — the thing that looked like the clear next build — never shipped that year. The call that mattered wasn't made in the build; it was made in the week before the sprint started, when one PM looked at the evidence and said: not this, not now, not us.