Everything up to here has been an argument. This is one program, and one decision on it.

Havis builds rugged mounting and docking hardware for public safety and field vehicles. The program was a case and dock station covering a range of tablets — different widths, heights, camera positions — with a single dock interface serving all of them.

We didn't run it with a written framework. We ran it the way we work and wrote the framework down afterward, from what we'd actually done.

The stack

One requirement sat outside the ranking entirely: the case and dock had to pass Havis' crash, drop and vibration tests. Everything in the coupled list could be traded against something else. That couldn't, so any solution putting a test at risk was excluded before it reached the stack.

What got ranked, and who held the pen:

Four checklist items sat outside it — strap provisions, stylus holder, branding, power indicator. Real requirements, none of which foreclose anything, so they wait.

The rest of this is about rank 12.

The reversal

Commonality across a tablet range looks like a cost decision, and on most programs it gets treated as one. Share parts, cut tools, save money. A cost-down program would rank it near the top.

We ranked it last, on purpose.

The honest description of that constraint is a mandatory effort with a variable outcome: share as many parts as possible, without closing a door on anything above it. It yields to everything. That's what puts it at the bottom — and the bottom is exactly where it needed to be.

Ranked near the top, commonality may have constrained the connector placement, the dock interface, and the latch. Our read is that the shared geometry would have ended up fighting the constraints that actually closed doors — giving you a worse product and, counterintuitively, probably less commonality, because parts forced to be common early tend to compromise in ways that make them unusable later.

Ranked last, it took whatever freedom was left over. By then the internal geometry was fixed and the outside was still open.

Mechanical evaluated common parts across similar tablet sizes and worked up corner bumper geometry that allowed shared back housings, with a single flexible bumper absorbing the small dimensional variances between devices. ID confirmed with no changes — shared housings and one bumper cost nothing on the visual or usability side.

The bumpers ended up reused well beyond the family they were designed for, across manufacturers and tablet types rather than one case line.

What it paid

16+ tooled parts reduced to 9. Tooling savings north of 40%, and months off NRE and tooling time.

SKU count down by roughly half. The same decision, showing up in inventory instead of tooling.

Figures reflect the Apple device family.

The program also passed crash, drop and vibration on the first round, with no tool modifications — which is what the gate was set outside the stack to protect.

That last one is evidence about ordering. The tooling and SKU numbers are evidence about commonality, and they came from the constraint nobody would have ranked twelfth.

The part that transfers

The ranking wasn't right on day one. Two constraints swapped position as the solution space narrowed, and one got added that nobody had named at kickoff. That's a Rev A behaving the way a Rev A should.

What mattered wasn't getting the order right the first time. It was having an order, in writing, that could be argued with — and a rule about who confirms before the next one opens.

The other eleven constraints have their own versions of this. If you want the full walkthrough, we're happy to send it.

If you've got a program where the constraints are already stacking up against each other, that's the conversation we're best at. Thirty minutes is usually enough to tell whether the order is the problem.