Why I Keep Asking Why Users Do What They Do

The trap of the rational user

Most product specs assume a rational user. The rational user reads labels, follows the flow, and chooses options that maximise their stated goal. The rational user does not exist.

Real users are tired, distracted, in a queue, or texting their boss. They tap the closest button. They skip onboarding. They re-enter the app three times before completing a flow because they got interrupted twice. If your product is designed for the rational user, every metric quietly underperforms — not because the design is wrong, but because the user it was designed for isn't the one in your funnel.

So the work I keep doing is the work of replacing the rational-user mental model with the real-user mental model. It is the single most leveraged thing a PM can do.

What I do that actually helps

Three habits, each unsexy:

1. Watch users, don't just talk to them. Self-reported behavior is unreliable. People will tell you they want a feature and never use it. They will say they hate a flow they actually depend on. The only honest signal is what they *do* — recorded sessions, support transcripts, behavioral analytics, even just sitting next to someone while they use the app.

2. Find the moment of confusion, not the moment of complaint. Users complain about things they noticed. They don't complain about things they didn't notice — they just leave. The interesting bug is the one where the user pauses for two seconds longer than expected and then closes the app. That two-second pause is where retention lives or dies.

3. Treat support tickets as discovery research. When I joined LexMeet, the highest-leverage week I spent was reading three months of support tickets back-to-back. It's the cheapest, most honest user research a PM can do. Patterns become impossible to ignore: the same flow being described in three different ways, the same edge case showing up under five different labels.

A specific example

At IPSY I once spent a week trying to understand why a particular shopping flow had 70%+ drop-off at the same step. The team had hypotheses — wrong copy, wrong CTA placement, slow load. We A/B tested all of them. None of them moved the metric.

The actual reason — discovered by sitting on a call with three users — was that the step *looked complete* before it actually was. Users were walking away from a page that visually felt finished, even though there was a final action below the fold. Once we fixed the visual hierarchy, drop-off collapsed. No copy change had ever been going to fix that.

The lesson wasn't about that page. It was that without watching users, we'd have spent another quarter optimising things that weren't the actual problem.

The shorter version

Every product I've worked on has had a gap between the workflow we designed and the workflow users actually performed. The PMs who close that gap fastest ship the products that retain. Everyone else ships the products that look right in the demo and quietly bleed users in production.

So I keep asking: *why are they doing what they're doing?* And I try not to leave the room until the answer is something I didn't already know.