My friend was in Austin for the weekend.
It was raining, we were rushing, and we jumped out of the cab quickly to avoid getting drenched. A few minutes later, he realized he had left his sunglasses in the car.
There was one more thing that made the moment stay with me. We were originally going to a bridge, but because it had unexpectedly started raining, the driver did not just blindly complete the destination we had entered. She suggested dropping us at a nearby cafe instead, so we could take cover. Technically, she could have dropped us at the bridge and ended the ride. But she understood the context had changed.
Normally, this would have been annoying. But because this was not a Waymo, not a fully autonomous vehicle, not a perfectly optimized robotaxi experience, because it was just a regular car driven by a human, we called the driver. She picked up. She was nearby. She came back.
Problem solved in minutes.
And that's when it struck me. Product teams often misunderstand what humans are actually doing inside a workflow.
The driver was not just driving
The driver was not just driving us from point A to point B. She was noticing when point B no longer made sense.
She was also the exception handler. She was the support layer. She was the escalation path. She was the person who could understand, “These people are standing in the rain, someone forgot something, and I can solve this quickly because I am still nearby.”
That is the part technology often removes first. And then product teams are surprised when the experience feels worse.
The product was not the ride. The product was the recovery.
This is what I keep thinking about with AI products
Most teams are obsessed with the happy path.
Can the AI answer the question? Can the agent complete the task? Can the workflow run without a human? Can we automate this process end to end?
That is the demo. But the product is not tested during the demo.
The product is tested when the AI misunderstands the context." "The product is tested when the system says, 'I completed the task,' but the human says, 'That is not what I meant.'
The product is tested when there is no obvious button for the user’s very real problem.
In those moments, the question is not whether the technology is advanced. The question is whether the product has a recovery path.
Humans are often not part of the task. They are part of the exception system.
This is the mistake I see often in AI product conversations.
We look at a workflow and say:
“This person is just doing repetitive work. Let’s automate it.”
But sometimes that person is not valuable because of the repetitive work. They are valuable because they know what to do when the workflow breaks. They know when to bend the rule. They know when to call someone.
They know when the customer is anxious. They know when “technically correct” is still a bad experience.
That is not always visible in a process map. It does not show up cleanly in a workflow diagram. But it is the difference between a product that works in a controlled demo and a product that survives real life.
The part that looks inefficient on a workflow diagram is often the part that saves the customer experience.
The lesson for AI products
This is not an argument against automation.
I use AI every day. I build AI products. I believe in automating painful, repetitive, low-value work.
But I do not believe in pretending that removing the human removes complexity. Usually, it just moves the complexity somewhere else.
If you remove the human from the front line, you need to design the fallback layer even more carefully.
Who handles the exception? How does the user escalate? How fast can the system recover?
What happens when the user does everything “wrong” but still has a valid need? What happens when the edge case is urgent?
This is where many AI products break. Not because the model is bad. Not because the workflow is useless. But because the product team designed for completion, not recovery.
The uncomfortable truth
A human driver returning forgotten sunglasses is not a massive technical achievement. But it is an excellent product lesson.
Because the best experiences are not always the most automated ones. Sometimes the best experience is the one where the system can pause, understand the context, and recover gracefully.
That does not mean every product needs a human in the loop forever. But it does mean every serious AI product needs an exception loop.
Users don't remember the smooth rides.
They remember the driver who came back.
Your AI product will have a version of this moment. A user in the rain. A forgotten context. A task technically completed but humanly wrong.
The question is whether you designed for it.
Build the exception loop. Build the fallback path. Build the way back.
That's the product.
