Most rework in hardware development isn't caused by bad decisions. It's caused by good decisions made in the wrong order — which also quietly limits the concepts still on the table.

Convergent Design is our answer to that. Four rules, applied at the seams between industrial design, mechanical, and electrical engineering — which is where most of the wrong-order decisions actually get made.

This is the short version: what the rules are and how they fit together.

Two kinds of constraint

The rules don't make sense without this split, so it comes first.

Some constraints close doors the moment you commit to them. Lock the enclosure split and you've limited where the mount can go. Commit to a wall section and you've narrowed your process options. Call these coupled constraints — they're coupled because solving one changes what's available to the others.

Most constraints don't do that. A power indicator on the dock. A branding surface. Real requirements, but they foreclose nothing, so they can be solved in any order once the coupled work is settled. That's a checklist.

The word doing the work here is foreclosure — how much downstream freedom a decision removes. It isn't the same as importance. A must-have can foreclose almost nothing. A nice-to-have can foreclose a great deal.

The four rules

1 · Rank the constraints that close doors.

Before solving any of them, the coupled constraints get ranked by how much freedom each one removes. Everything else goes on the checklist. The ranking is what makes the order deliberate instead of accidental — and it's also a tiebreaker agreed on before the first collision, rather than during it.

2 · Lead follows the constraint, not the calendar.

Every constraint has one discipline whose expertise is the sharper tool for it. Mount envelope and load case: mechanical. Grip, sightline, control layout: industrial design. Board-to-enclosure fit: electrical. Which discipline holds the pen changes a dozen times over a program, and the pattern is different on every project.

3 · Optimize the system, not the part.

You don't pick the best answer to the problem in front of you. You pick the one that keeps the most doors open for the problems still ahead. A connector centered on the back face might be the best board — and still the wrong answer if it's where the mount has to land. The board is easy to revise. The mount is not.

Run it this way and you reach the back half of the program with options still available, which is where late requirement changes get absorbed instead of resented.

4 · The other discipline confirms before the stack advances.

Whichever discipline didn't lead signs off before the program moves on. This isn't a courtesy review. Only the discipline that wasn't driving can see what a solution just closed off on their side — which is also why both have to be staffed at the same time rather than in sequence.

The ranking is Rev A

Nobody knows the right order on day one. Foreclosure depends on the solution space you're still exploring, and that space narrows as the program runs — a constraint that looked cheap in week two can become the thing everything hinges on once a direction is chosen.

So the stack gets re-ranked as concepts firm up. A constraint moving from seven to three isn't a miss. It's the process working.

What matters is that the order exists in writing early enough to be argued with, and that when it moves, everyone can see that it moved.

What it isn't

Not requirements prioritization. MoSCoW ranks by how badly you need something. This ranks by what it costs you to commit. Both are useful, and they produce different orders.

Not stage-gate. A phase gate fires on the calendar. This fires when a constraint resolves — one or two orders of magnitude finer, and usually a conversation rather than a meeting.

Not concurrent engineering. Concurrent engineering says run the disciplines in parallel. It doesn't say who leads which decision, or who signs off before the next one starts. That's the part this specifies.

Where it runs

None of the underlying ideas are new. Ranking by dependency, preserving optionality, front-loading constraint discovery — all documented, all taught. Large organizations run them with systems engineering functions and formal dependency analysis.

That machinery doesn't scale down. Nobody builds a dependency matrix for eleven constraints and five people. What makes this runnable at mid-market size is a team small enough that confirmation stays a conversation, and enough programs behind you to rank foreclosure by judgment rather than by building three prototypes to find out.

We frame the rules around industrial design, mechanical, and electrical because that's the seam we work in every day, and the one we've watched break most often. The logic isn't limited to those three — but that's where we can speak from experience rather than theory.

That's the whole framework. Each rule has more behind it than one paragraph — where the constraints on your list actually came from, who ends up holding the pen by default, what a confirmation catches that a review doesn't — and we'll take them one at a time from here.

So: on your next program, which of your coupled constraints got ranked — and which just got decided? If you can't answer that in five minutes, that's usually where we start.