Good Decisions, Wrong Order

Sit through enough hardware program post-mortems and a pattern emerges. The team is competent. The reviews were held. The reasoning was documented. And yet, somewhere in month seven, a decision made in month two is frustrating. Tooling estimates coming in high. A mount envelope that doesn't work with the enclosure that was already locked. A compliance requirement that arrived after the geometry did.

The conversation that follows always sounds the same. Someone should have caught this earlier. Manufacturing should have been in the room. The requirements should have been tighter. The team gets a little smaller in its chair, and the fix gets scoped and paid for, and the program keeps moving.

But nobody was actually wrong.

The industrial designer who chose that form direction was working from sound user research and a valid aesthetic brief. The engineer who inherited it made the best call available given what was locked. The product manager who set the priorities was optimizing for the customer segment marketing was targeting. Every decision was defensible in isolation. That's what makes the rework so infuriating and so hard to prevent. The retrospective can't find the guilty party because there isn't one. 

Most rework in hardware NPD isn't caused by bad decisions. It's caused by good decisions made in the wrong order.

Two kinds of rework

Once you start looking through this lens, you notice that rework has two flavors that fail very differently.

Execution rework is local. The right constraint was resolved, but the solution was ehh, mediocre at best. A tolerance nobody stress-tested, a snap geometry that needed one more iteration, a fastener choice that should have been reviewed further. These are the incidents that dominate the count in any given program, and most of them are recoverable inside the envelope you already have. You fix them, you move on, and you get a little faster next time.

Ordering rework is structural. A decision made at rank three foreclosed something that turned out to be rank one, and the team didn't know it at the time because rank one hadn't been named. Fixing this doesn't mean iterating on a part. It means climbing back up the stack, unlocking geometry, and rerunning decisions that were considered finished. Fewer of these per program by count. Almost all of the cost.

Any process that optimizes for reducing execution rework and ignores the ordering problem is optimizing the smaller of the two costs. That's the trap most hardware teams are in.

What Convergent Design actually is

Convergent Design is Radiant's answer to the ordering problem. It's not a new philosophy. It's a specific operating discipline for the industrial design and engineering interface that most mid-market hardware teams either haven't formalized or don't know they've drifted away from.

The premise is that four rules, applied at the right moments, prevent the expensive kind of rework.

Rank the coupled decisions before you solve any of them. Not every decision restricts every other one. The ones that do, the ones that close doors when you commit, need to be identified up front and ranked by how much downstream freedom each removes. Everything else is a checklist. The ranking is also a pre-negotiated tiebreaker.

Lead follows the constraint, not the calendar. Whichever discipline the constraint most directly speaks to holds the pen for that decision. On any given program, lead alternates a dozen times. The pattern is different on every project. The rule is the same.

Optimize the system, not the part. A superior solution to the constraint in hand that forecloses a higher-ranked constraint downstream is rejected. You don't pick the best answer for the problem in front of you. You pick the answer that keeps the most doors open for the problems still ahead.

The other discipline confirms before the stack advances. Nothing moves down the rank until the non-leading discipline has signed off. Only the non-leading discipline can see what a solution forecloses on their side.

Where the value actually lives

Two of these rules will look familiar to anyone who has read the development literature. Ranking by dependency has a formal cousin in design structure matrix work. Preserving optionality has a formal cousin in option value theory. Front-loading constraint discovery is documented in decades of published research. None of the pieces are new, and pretending otherwise would be the fastest way to lose an engineer's respect.

What Radiant has is the operating discipline that makes those pieces run together on a small team, and the pattern recognition, built from a decade of programs, that lets the third rule be applied without building three prototypes to discover what forecloses what. Toyota can afford to explore alternatives in parallel. Most companies can't, and shouldn't try. Ordered convergence is often faster than breadth-based convergence anyway, once you know what to rank first.

What this means for your next program

You don't need to hire Radiant to notice the pattern this piece is pointing at. Two questions, asked honestly, will tell you where you stand.

On your last program, when did the manufacturing process get selected: before or after form freeze?

The last time cost and industrial design collided, who broke the tie, and what was the basis for the decision?

If the answers came out of sequence, or if the tie-break wasn't a rule that existed before the collision, ordering rework is happening on your programs. Not because the team is doing anything wrong. Because good decisions were made in the wrong order.