2. Process Is the Product

Monday morning. Two programs had just failed the same end-of-line leak test.

On the test stand, the two failures looked identical.

Both teams have competent engineers, a supplier in the loop, and a date that will not move without consequences. Both have test data that says the current build is not stable enough to ship.

One program contains the issue in a day and restarts with a revised control plan. The other burns two weeks arguing whether the failure is fixture drift, operator variation, or the wrong revision on the floor.

The deciding variable is decision plumbing: how test evidence becomes a signed plan.

Same physics, different outcomes

Program A has one controlled source for the leak-rate limit and fixture calibration state, with revision history and owner. When failures spike, the containment decision, root-cause owner, and restart criteria are written in one decision record with signer and date. The PM one-page status pulls from that same record, so leadership, manufacturing, and supplier all see the same state. The date moves, but it moves once and with reasons.

Program B has the drawing revision in one system, the work instruction in another, and supplier evidence in email. Manufacturing says fixture drift. Design says tolerance stack. Quality says operator variation. The status deck still shows last week's confidence color because nobody owns the merge from evidence into decision. The PM spends the week reconciling contradictions instead of clearing blockers. By the time leadership sees the real risk, cheap fixes are gone.

Same technical problem. Different operating system.

Teams call this "execution," but the mechanism is simpler: the path from evidence to decision is either designed or improvised. If it is improvised, each shock costs more than it should.

What process actually is

In this book, process is not ceremony. It is the minimum written system that keeps one program reality across functions.

At minimum, that system has:

Named ownership for decisions and handoffs.
One source of truth for active limits, requirements, and revisions.
Decision records that explain what changed, why, and who approved it.
Gate criteria that decide, not just review.
One-page status that matches the underlying record.
Escalation rules for when evidence breaks the current plan.

If one of those is missing, the team does not fail immediately. It fails noisily over time: duplicate work, delayed truth, meetings that replay the same argument, and last-minute surprises that look like "bad luck."

This is why process belongs in design work, not in a PM appendix. It changes what gets built, when it gets built, and what can be defended to customers and leadership.

Why weak process makes technical problems expensive

Weak process adds cost in four ways.

First, it creates latency. Good data exists, but it takes days to become a decision because nobody owns the transition from test result to plan update.

Second, it creates rework. Different groups act on different versions of the truth, then spend time undoing each other.

Third, it creates risk blindness. The one-page status reports confidence while the underlying record reports uncertainty, so management acts on stale optimism.

Fourth, it creates trust debt. Suppliers, PMs, and executives stop trusting the current number because the number keeps changing without a visible decision trail.

None of that is abstract. It shows up as scrap, missed windows, overtime, and avoidable churn in people who are already stretched.

The operating rule

Treat process artifacts (written program records) as product artifacts.

If a limit, dependency, or risk can change build, cost, or date, it needs an owner, a controlled record, and a visible decision path. If it has no owner or no record, treat it as not real yet.

This rule is strict on purpose. Hardware programs punish ambiguity late. Remove ambiguity when evidence first appears, before purchasing and build decisions fan out.

A corollary worth keeping visible: every artifact in this system should reduce latency, rework, or ambiguity. If a record, checklist, or status field does not demonstrably do one of those three things, retire it. The minimum system listed above is exactly that — minimum. Do not add to it until the minimum proves it reduces argument and lag on your program.

What changes this week

If your program is already moving, do this before adding new templates:

Pick one active cross-team limit that is causing repeated meetings.
Name one owner for that limit.
Declare one controlled location as the live value.
Write one short change log entry format: what changed, why, who approved, impact.
Make the next one-page status pull from that record.

That is enough to expose whether your current process is implemented or cosmetic.

Field test: pick the highest-stakes open limit on your current program. Can you name its owner and point to a controlled written record of its current value? If the answer to either question is no, the process is cosmetic at that limit — regardless of what the status deck says.

Install one narrow control loop first. Prove it reduces argument and lag, then extend.