When I started my career, 'product design' meant designing physical products. For me, that meant treadmills, exercise bikes, and commercial strength equipment: complex bits of steel and electronics. As a snotty-nosed industrial designer fresh out of uni, I had a lot to learn about... everything. The whole team was in one studio, an old Victorian building tucked away behind the main warehouse. We were largely out of sight and out of mind, which meant we were left to our own devices to get on with deep design work. There was no army of product managers making tickets; designers owned the work. Properly. We owned the design and the outcome of our decisions.

The haunting of the one-way door

In that world, there was a concept that haunted every project: the "one-way door."

It’s a choice that, once made, is nearly impossible to reverse. For a software team deciding on a new feature, these are rare. For an industrial designer, they were the only doors we had.

Signing off on the final drawings for a new treadmill was the ultimate one-way door. The moment you walked through it, you were committing the company to a fortune in hardened steel moulds: the 'tooling'. There was no going back. Getting it wrong meant you had just created a very, very expensive mistake. This reality, the constant presence of that one-way door, bred a certain kind of mindset: a healthy, productive paranoia. You were forced to do the deep, upfront thinking because you only had one shot to get it right.

The revolution of the two-way door

Then came the software revolution, a world built entirely on "two-way doors." Its central belief is that failure is cheap. Don't like how a feature works? Ship a patch. Found a bug? Push a hotfix. This is a monumental advantage over the old world, where a mistake meant a furnace full of money.

But this low cost of failure has bred a culture where the deep, rigorous thinking that was once mandatory is now often seen as a bottleneck. An entire generation of designers has been raised on the Silicon Valley mantra of "move fast and break things." This is a wonderful philosophy if you’re designing an app for rating sandwiches, but a catastrophically irresponsible one if you’re designing software for the crew of a $200 million supertanker.

A one-way door in agile's clothing

I saw this firsthand not long ago. A team, under immense pressure to "get stuff done" and with the best of intentions, decided to treat a new payroll system as a simple two-way door. The plan was to build it by completely sidelining the design team.

We're not talking about some minor internal app; this was payroll, arguably one of the most critical, high-stakes tools a company has.

The strategy was simple: product managers would write the tickets, engineers would build them, and this, apparently, would be the fastest way to tick the box that says "we have this feature."

The result, predictably, was a catastrophe. A confusing, unusable system that created more problems than it solved. The things they broke weren't just pixels; they were people's pay slips and their trust in the company's tools. It was a one-way door decision disguised as an agile two-step.

And the true cost wasn't just the initial build. It was the endless, expensive aftermath: the extra training, the reams of documentation trying to explain a fundamentally broken system, and the flood of support tickets from frustrated employees. It was an iceberg of a problem that could have been avoided, but which the design team was, of course, now being asked to fix.

This is a textbook example of a common organizational blind spot. It stems from a fundamental misunderstanding of what design actually is. To many, we’re still just the people who add the visual polish at the end. The colouring-in department, called in after all the 'real' decisions have been made.

When that’s your worldview, your measurement for success becomes completely broken. The goal wasn't to solve a problem for our employees; it was simply to launch. The feature was the goal, not the outcome.