Part 2 — It’s the Design Review Process, Stupid

As an industrial designer, I tend to see development as a sequence of iterations.

sketches → idea → prototype → test → objection → review → revision → next iteration

That is not so different from an assembly line.

Manufacturing takes inputs through a series of stages, checks for defects, corrects problems and tries to prevent bad work moving further downstream.

Design does something similar, except the thing moving through the system is often an idea.

And ideas can carry defects too.

A weak assumption.

A biased interpretation.

An overly confident conclusion.

A design proposals and decisions argued overly dogmatically.

An objection about how an idea is delivered, that is ignored because of hierarchy, ego or poor delivery.

All of these can slow or stunt the process, create rework and push bad decisions further downstream.

The Wright Flyer to the Airbus A380 is a useful illustration.

The A380 was not the result of one brilliant leap.

It emerged from more than a century of accumulated thinking, testing, measurement, failure, objection, review and revision.

Potentially billions or trillions of individual thoughts, trials and reviews sat somewhere inside that process.

Some designs and reviews would have improved the thinking.

Others would have failed to do so, and sent the process backwards.

Some would have delayed production by incomplete information, bias, defensiveness, authority or overly dogmatic delivery, or generally people trying to unfairly convert the team, and winning.

And every one of these failed conversions has a cost.

Engineering time.

Meetings.

Rework.

Scrapped prototypes.

Testing.

Management.

Certification.

Opportunity cost.

Manufacturing learned long ago that if a process is repeated thousands or millions of times, even a small efficiency improvement can become enormously valuable.

So why should the design and review process inside the development of a product or service be treated any differently?

If we can reduce unnecessary subjective behaviors and reviews, shorten prolonged unfair disagreements and surface valid objections to overly dogmatic behaviour earlier, then perhaps we can improve the efficiency of the entire development assembly line.

Not by making people think faster.

By making the review of thinking more structured.

That is where I increasingly see Spatz.

Not simply as a micro-conflict-management tool, but as a possible quality-control layer for collaborative thinking.

A kind of Andon cord for alerting of unfair ideas.

We have spent more than a century optimising how products move through production. Perhaps the next significant efficiency gain comes from optimising how ideas move through objection and review processes.