Broken-in-production is an automatic fast path - small thing with embarrassing impact jumps the queue regardless of the size of the epic around it

August 28, 2026 at 9:41 PMstrategymedium

Situation

In the 2026-08-25 Exec Product Prioritization session the errata CPE-to-product mapping item had drifted to number 30 on the board. The specific defect was that CIQ was shipping images identified as Rocky Linux when they should have been identified as RLC Pro. Peter moved it into the top ten on the spot. Brian Dawson stopped and asked what criterion drove the move, and Peter generalised it: something broken that we are shipping is an automatic fast path. He bounded it in the same breath - the broader errata epic is genuinely large and stays where it is; only the shipping-the-wrong-identifiers piece jumps, because fixing that piece is not dramatic at all. In the same meeting he pushed the reciprocal direction, arguing that some net-new items should be prioritized above keep-the-lights-on work because a two-month effort sitting at number 34 becomes a six-month effort.

Reasoning

Peter confirmed this reading. The board belongs to Bjorn Hovland - Peter said explicitly that he had no problem with the board as it stood, and the other trades in the session (9.9 and 10.3 down, Ollama above Halo) were Bjorn calls that Peter backed. What Peter contributed was the criterion rather than the verdict, and he contributed it because he was asked to generalise, so the next instance does not require him in the room. The cost asymmetry is what turns it into a rule: a cheap fix to something customers can already see costs almost nothing to execute and keeps costing reputationally every day it sits at number 30.

Additional Context

Greg Kurtzer had already been arguing in the same session that effort size should drive ordering - of course do the thing that is two hours first. Peter reframed that from a size heuristic into a defect heuristic. The item is now visible in the 2026-08-28 TPS report as RAT priority 4, Errata CPE to Product Mappings, at 84 percent confidence with a target of September 1.

Observed Evidence

Direct exchange in the transcript where Brian Dawson explicitly asks Peter to state the criterion and Peter confirms it, followed by Brian naming it as an automatic fast path with no pushback. Peter separately bounded the scope so the criterion could not be used to pull the whole epic forward.

Matching Patterns

55%
Reclassify to Route - Decide Who Owns It, Then Give a Criterion Not a Verdict(gave the criterion rather than only the verdict when asked, strategy category, left ownership of the board with Bjorn)
40%
Decide on the Precedent, Not the Case(generalised a single reordering into a standing rule, 100 percent success rate over 6 observations)

Confidence Breakdown

33/35
Evidence
24/30
Pattern
20/20
Source
7/15
Corroboration

Reasoning Depth Analysis

Org Signal:Shipping something wrong is a different class of problem from shipping something late, and it is the only class that gets to skip the queue automatically.
Who Affected:Brady Dibble and the RAT team, who now have a rule they can apply without escalating to Peter. Bjorn Hovland, whose board Peter deliberately left intact otherwise. Customers running scanners against CIQ images, who were seeing the wrong product identifiers.
Precedent:This is the point of the decision. Brian Dawson asked for the generalisation explicitly and Peter gave it so the next instance resolves itself.
Consequences:Real - the item moved to roughly number seven or eight during the session and is now tracking to September 1 at 84 percent in the TPS report.
Timing:Peter took the opening when Brian asked for the criterion rather than simply making the one reordering and moving on.

Source

reflection

AI Confidence

84%

Related Context

🎥
Exec Product Prioritization Discussion

fathom

Brian: Peter, whats your criteria that drove you to say, lets just move it up and get it done? Is it because it is something broken that were shipping? Peter: Yeah. Brian: Okay. So thats an automatic fast path.

🎥
Exec Product Prioritization Discussion

fathom

That item, I agree, the broader item is big, but fixing that is not dramatic at all. So to Gregs earlier point of prioritization, small thing with embarrassing impact, lets just get it off our plate and be done with it.

🎥
Exec Product Prioritization Discussion

fathom

And thats why I want to push us, in some cases, to prioritize some of these items above keep the lights on work. I think thats important. And the people on this call get to make that decision.

Outcome

No outcome recorded yet.

Decision ID: c9dc7609-435c-4f94-bc10-173652f5c8a3