It was not for a patient, but I was standing in a hospital corridor, about ten feet away from a newly installed facial recognition attendance device.
We had installed 20 devices across different locations in the hospital. Doctors, nurses, and staff belonged to different departments, and the shortest path to their workplace was never the same. The deployment itself was successful, but standing there and watching people interact with the device reminded me of something important.
The gap between how we think people will use a product and how they actually use it is where discovery happens. It is similar to the idea of desire paths in product management, where users naturally create behaviors and workflows that differ from the ones we originally designed for.
Your intended flow assumes a calm, linear interaction. Their reality is crowded, fragmented, and urgent.
Discovery surfaces what only becomes visible when real people use a product in a real environment. Not in a demo. Not in a requirements document. Not in your mental model. In their chaos, interruptions, workarounds, and impatience when something does not fit their workflow.
Some friction points remain invisible until you stand there and watch someone struggle.
One simple example was distance. How far should someone stand from the device? It seemed obvious to us, but it was not obvious to users. We later added a sticker on the floor to guide people on where to stand. A small change, but one that reduced confusion and improved the experience immediately.
Nobody mentioned this requirement in a meeting. No one asked for it. We discovered it by observing. Discovery was always about finding unknown unknowns.
AI is transforming how teams work, but it is also changing how organizations measure productivity. As I discussed in my article on productivity in the AI era, speed is becoming easier to achieve. Understanding whether that speed creates value is becoming harder.
Now it often sounds like this:
“Why spend weeks talking to users? Let me prompt ChatGPT. It will tell me what users need.”
Many founders skip discovery entirely. They start with answers before speaking to a single user. They build from known unknowns, the questions they already know to ask. The risk is that they end up building something nobody truly needs, making it harder to determine whether they have a product problem or simply a marketing problem.
But discovery was never about answering questions you already know.
It was about uncovering questions you did not know existed.
Somewhere in this rush, we also started treating UI and UX as something optional. Why hire a designer when you can generate an interface?
The craft becomes reduced to visual output. The thinking behind affordance, feedback, information architecture, and mental models gets lost. The designer’s job was never just to make things look good. It was to translate user insights into interaction patterns that feel natural rather than frustrating.
The cost remains hidden until launch. Until the product solves the explicit problem but creates friction in the workflow. Until the interface is technically usable but not enjoyable. Until competitors who invested in understanding users pull ahead.
The real question is simple:
- If your entire discovery process takes a couple of hours with an AI tool, what friction point are you not seeing?
- What workflow edge case is missing from your prompt?
- And how much of that gap will your first thousand users end up paying for?
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use.
Tahir Shahzad
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you are working on a product problem worth solving, reach him at tahirshahzad.com/contact/
