1. The Elevator That Didn't Need to Become Faster

Imagine entering a tall building.

You press the button for the 20th floor.

The doors close.

And then you wait.

If the building is 20, 30, or 50 floors high, the elevator needs time to travel.

Now imagine the early days of tall buildings, when elevators were becoming an increasingly important part of vertical transportation.

There was an obvious engineering question:

“How do we make the elevator faster?”

And engineers certainly worked on elevator speed, capacity, safety, acceleration and other technical improvements.

But there was another problem.

Even if you improve the elevator, there will always be some amount of time during which a person is simply standing inside a box.

And humans are not particularly good at doing nothing.

A few seconds can feel longer when you're staring at a wall.

A minute can feel surprisingly long when you are consciously waiting for something.

So a very simple object began appearing inside elevators:

A mirror.

Figure 1: The Elevator Mirror — Transforming dead standing time into an unconscious act of personal grooming and observation.

At first glance, a mirror seems almost irrelevant to elevator engineering.

• It doesn't increase the motor's power.
• It doesn't change the cable.
• It doesn't make the elevator move faster.
• It doesn't reduce the distance between the ground floor and the 20th floor.

But it changes something else:

What the passenger experiences during the journey.

Suddenly, there is something to look at.

People check their hair. They check their clothes. They look at themselves. They look at other people. They become distracted from the fact that they are waiting.

The actual journey may take exactly the same amount of time. But the perceived experience of that time changes.

And this is where the idea becomes much bigger than an elevator. Because product design is often not about changing the underlying physics. It is about changing the human experience of those physics.

You cannot always remove the constraint. But you can sometimes change the relationship between the user and the constraint.

And that is a powerful product principle.

2. ChatGPT and the Snake Game

Now jump from elevators to artificial intelligence.

The technology couldn't be more different. But the product problem is strangely similar.

You ask an AI to generate an image. The request goes into the system. The model starts working.

And then... you wait.

AI image generation involves significant computation. The system has to process your request, generate the output and perform the necessary diffusion or transformer steps before the image can appear.

As AI models become more capable, expectations also increase. Users don't just want “Generate an image.” They increasingly expect “Generate an image quickly.”

But there is an uncomfortable reality for any AI company:

Computation takes time.

You can improve models. You can optimize infrastructure. You can improve GPUs. You can optimize inference. You can redesign systems. But you cannot simply make every computational process instantaneous.

So what happens when the user has to wait?

You could show a loading spinner. That's what most software does. A circle. Spinning. And spinning. And spinning.

It communicates only one thing: “Wait.”

But recently, ChatGPT has taken a much more interesting approach during some image-generation waits:

It gives the user something to do.

A classic Snake-style game can appear while the image is being generated.

Figure 2: Turning Computational Latency into Engagement — An interactive Snake mini-game during model inference.

Think about what just happened.

The image didn't suddenly become instant. The underlying computation still takes time. But instead of making the user stare at a loading state, the product gives them an activity.

And that changes the psychological experience completely.

The underlying waiting time may be similar. But the user's experience of that time isn't.

And there is another interesting layer here. The Snake game isn't necessarily the final solution. The company can continue improving image-generation speed.

But until that happens, the waiting period itself becomes an opportunity.

That's an important distinction.

3. Disney: When the Queue Becomes Part of the Ride

Now let's leave technology completely. Go to a theme park.

There is one problem almost every successful theme park has:

Too many people want to experience the same attraction.

Imagine a ride that can accommodate only a certain number of people at a time. You cannot put everyone on the ride simultaneously. You have a physical capacity.

You could build another ride. You could increase the capacity. You could make the ride cycle faster. But all of those things have limits. And even after doing all of them, there will still be queues.

This creates an interesting question:

“What should happen to the customer while they're waiting?”

One answer is: “Nothing.” Put people behind a rope. Create a line. And let them wait.

But theme parks such as Disney have approached this very differently.

The queue itself can become part of the experience.

Figure 3: Immersion Over Stagnation — Designing environmental storytelling so waiting feels like the opening chapter.

The environment is themed. The architecture tells a story. There are things to look at. There are details to discover. There may be interactive elements.

The customer isn't simply standing in a queue. They are gradually entering the world of the attraction.

And this is brilliant because the physical limitation hasn't disappeared. There is still a queue. There are still people ahead of you. The ride still has a fixed capacity.

But the product has changed the meaning of the waiting period.

That's a completely different psychological frame.

And this is one of the reasons great product experiences often feel much better than technically similar experiences.

They don't necessarily eliminate friction. They reframe friction.

4. Domino's: Don't Make Me Wonder What's Happening

Now let's talk about something much more ordinary. Pizza.

You open an app. You select a pizza. You pay. And then you wait.

The restaurant needs to prepare the order. The pizza needs to be cooked. Someone needs to pack it. A driver needs to pick it up. The driver needs to travel. Traffic can happen. Delays can happen.

There is a lot happening between: “I want a pizza” and “Here is your pizza.”

None of that can be completely eliminated. But there is another problem hidden inside delivery:

Uncertainty.

Imagine ordering food and hearing absolutely nothing for 30 minutes. You start wondering:

The waiting itself becomes uncomfortable because you don't know what is happening.

Now compare that with an order-tracking experience. You can see progress.

The order has been received. It is being prepared. It is being cooked. It is ready. It is on the way.

Figure 4: Replacing Anxiety with Clarity — The 5-stage order tracker pipeline eliminating blind uncertainty.

Now something important has happened.

The waiting hasn't necessarily become shorter.

But the waiting has become understandable. And understandable waiting is often easier to tolerate than uncertain waiting.

This gives us another version of the same principle:

Different mechanisms. Same underlying idea:

“If you cannot immediately remove the waiting, change what the user experiences while waiting.”

5. Amazon: Turn Waiting Into a Journey

There is another version of this idea that most of us experience constantly: ordering something online.

You find the product. You click Buy. You pay. And then the product begins a physical journey:

Warehouse → Packaging → Sorting facility → Transportation → Another facility → Local delivery network → Delivery vehicle → Your home.

There is no magical way around the physical movement of an object. Even incredibly sophisticated logistics still requires time.

But modern e-commerce has transformed one important thing:

Visibility.

Instead of simply telling the customer: “Your package will arrive in three days,” the experience can show a journey:

Figure 5: The Information Layer as a Journey — Turning transit time into an anticipated, trackable progression.

Now think about the psychological difference:

The customer has something to understand. Something to anticipate. Something to follow.

Again, the physical transportation hasn't disappeared. The package still needs to travel the same roads, pass through facilities and eventually reach the customer. But the information layer makes the waiting feel different.

And this is an important lesson for product builders:

The Pattern Behind All Five

At this point, we have five completely different industries:

They have almost nothing in common technologically. Yet they share the same product problem:

“There is something the customer wants, but they cannot get it immediately.”

And that creates a period of waiting.

The interesting companies don't necessarily treat that waiting period as empty space. They ask:

“What can we do with this time?”

And there are several possible answers:

These are different implementations of the same principle.

The Difference Between Actual Time and Perceived Time

This is where the topic gets particularly interesting.

Let's imagine two products:

Technically: They are identical.

But imagine Product A shows Loading... for the entire 60 seconds.

Product B gives you progress, information, animation, something to explore, something to interact with.

At the end, both products have taken one minute. But you may remember the experiences completely differently.

This is because humans don't experience time like a stopwatch. We experience time psychologically. A minute spent staring at a blank screen can feel much longer than a minute spent doing something interesting.

That doesn't mean companies should use tricks to hide terrible performance. That's where the distinction becomes important.

There are two fundamentally different strategies:

The difference is enormous. The first is manipulation. The second is product design.

Don't Hide Bad Performance

This is an important caveat.

If your website takes 30 seconds to load because you have written terrible code, adding a mini-game doesn't magically make your product good.

If your delivery takes three days because your logistics operation is inefficient, a beautiful tracking animation doesn't fix the underlying problem.

If an AI model takes an unreasonable amount of time because the infrastructure is poorly optimized, entertaining the user shouldn't become an excuse to stop improving it.

The best companies usually do both:

They improve the underlying system and improve the experience around the remaining constraints.

That's the real lesson.

• The elevator industry continued improving elevator technology.
• AI companies continue improving inference speed.
• Theme parks continue improving ride capacity and queue systems.
• Delivery companies continue improving logistics.
• E-commerce companies continue improving fulfillment.

But while those improvements are happening, users still have to live with today's limitations. And that is where experience design matters.

The Builder's Trap: Always Trying to Remove the Problem

There is a trap that engineers, founders and product people can easily fall into. When they see a problem, they immediately try to eliminate it:

This thinking is valuable. But it can also become restrictive. Because sometimes the constraint is not immediately solvable:

• Maybe you don't have enough infrastructure.
• Maybe the technology isn't mature.
• Maybe the economics don't work.
• Maybe regulations prevent it.
• Maybe physics prevents it.
• Maybe the business can't afford the perfect solution yet.

And this is where a second question becomes valuable:

“If I cannot remove the problem today, can I redesign the experience around it?”

That question can unlock completely different solutions.

The Most Interesting Product Opportunities Are Sometimes in the “In-Between”

We usually focus on the beginning and the end of an experience. For example:

But there is an entire area between those two points. And that area is often ignored.

Let's call it: The In-Between.

The user has already taken an action. But they haven't received the final result yet.

That period could be:

And every one of these periods can potentially be designed.

This is a huge opportunity. Because companies often think:

“The customer is waiting for our product.”

A better question might be:

“What experience are we giving the customer while our product is becoming ready?”

That is a much more interesting product question.

What If We Applied This Everywhere?

Imagine applying this principle beyond our five examples:

The Four Ways to Design Waiting

After looking at these examples, I think waiting can broadly be designed in four ways:

The Competitive Advantage Nobody Talks About

Here's the part I find most interesting.

Companies often compete on: Price. Speed. Features. Quality. Distribution.

But there is another dimension:

How does your product make people feel while they wait?

Imagine two companies offering essentially the same service:

The underlying service might be almost identical. But the customer may strongly prefer Company B.

That preference can become a competitive advantage. And unlike a purely technical advantage, this one can sometimes be surprisingly inexpensive to create:

• A mirror is cheap compared with rebuilding an elevator.
• A progress indicator is cheap compared with rebuilding an entire logistics network.
• A digital interaction can be cheap compared with reducing computational requirements by an order of magnitude.

This doesn't mean these solutions are always cheap or easy. It means they attack a different layer of the problem.

The Temporary Solution That Can Become a Product Feature

There is another lesson hidden here. Sometimes an experience improvement starts as a temporary workaround. You haven't solved the core technical problem yet. So you think:

“Until we make this faster, let's give users something else to do.”

But then users start liking that experience. And suddenly the workaround becomes a feature.

This happens because users don't experience your architecture. They experience your product.

They don't care whether the reason for waiting is GPU computation, elevator mechanics, kitchen preparation, or logistics. They only know:

“I'm waiting.”

So the product designer's responsibility isn't limited to solving the internal engineering problem. It also includes designing the human experience surrounding it.

Don't Confuse “Busy” With “Useful”

There is one more distinction worth making. Giving users something to do is not automatically good design.

A company can fill every waiting period with notifications, advertisements, animations and unnecessary interactions. That doesn't mean the experience is better.

The question should be:

“Does this make the waiting period better for the user?”

Not: “Can we monetize this waiting period?”
Not: “Can we make the user click something?”
Not: “Can we distract them?”

The best waiting experiences respect the user's time. They either:

That's a much higher standard.

The Question I Would Ask Every Product Team

If I were sitting in a product meeting and someone said:

“We need to make this faster.”

I wouldn't disagree. I'd ask one additional question:

“How long will it take us to make it faster?”

If the answer is: “Six months.”

Then I'd ask:

“What happens to the user during those six months?”

If the answer is: “They wait.”

Then we have another product problem. And perhaps that problem can be solved today. Not by making the system faster. But by making the waiting experience better.

The Real Innovation May Not Be Where You Think

We often celebrate the obvious innovation: The faster chip. The better algorithm. The bigger server. The quicker delivery network. The higher-capacity ride.

And rightly so.

But sometimes the cleverest innovation happens somewhere much less obvious:

Around the limitation.

The mirror doesn't change the elevator's physics. The Snake game doesn't eliminate computation. The themed queue doesn't eliminate capacity constraints. The pizza tracker doesn't make dough cook instantly. The package tracker doesn't make a truck teleport.

But each one asks a different question:

“What can we change even if we can't change the underlying limitation?”

That's where the real product insight lies.

Maybe We Are Solving the Wrong Problem

Perhaps the most important lesson from all of this is that users don't necessarily experience the technical problem you are trying to solve. They experience the consequence of that problem.

The best product thinking sometimes comes from stepping away from the technical description and looking at the human one. Don't ask only:

“What is the technical problem?”

Ask:

“What does the user actually experience because of the technical problem?”

Those are not always the same thing. And once you understand the second one, completely different solutions become possible.

Conclusion: Don't Always Fight the Constraint

Innovation is often described as removing limitations. But sometimes, limitations are simply part of reality.

There will always be things that take time. There will always be physical constraints. There will always be computation. There will always be queues. There will always be transportation. There will always be processes that cannot happen instantly.

The mistake is assuming that the only possible response is: “Make it faster.”

Sometimes the better question is:

“What can we do with the time that already exists?”

Put a mirror in the elevator. Put a game inside the loading experience. Turn a queue into part of the attraction. Show the customer where their food is. Show them where their package is.

Different industries. Different technologies. Different users. Same fundamental idea.

You don't always have to make the process faster. Sometimes you just have to make the time around the process better.

And perhaps that is one of the most underrated forms of innovation:

Because in product design, the constraint itself isn't always the experience.