Your Users Are Lying to You (And It’s Your Fault)

There’s a dangerous dopamine hit that comes with shipping a feature. Most product teams don’t fail because they can’t build. They fail because they build the wrong thing.

And the scary part is — you usually don’t realise it immediately.

• You ship.
• You iterate.
• You improve.

And nothing really changes.

Metrics move a little. Engagement improves marginally. But the core problem stays untouched.

Because the issue was never execution. It was clarity.

Albert Einstein famously said:

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about the solution.”

But we often spend 5 minutes looking at a customer support ticket and 55 days staring at a Jira board.

This Takes Me Back to Medicine

In the first few years of MBBS, one thing is drilled into you repeatedly:

Don’t jump to treatment - in fact very little focus is placed on treatment in the early years.

Focus is entirely on history taking - ask questions. Then ask better questions.

Go beyond what the patient is saying.

Because what a patient tells you is rarely the full picture.

• They might not remember accurately.
• They might not know how to describe what they’re feeling.
• Sometimes, they don’t even realise what’s relevant.

It is your job to extract the truth.

Not just listen.

There’s a reason William Osler said:

“Listen to your patient, he is telling you the diagnosis.”

But listening here doesn’t mean taking things at face value.

It means probing, interpreting, connecting.

Diagnosis Over Prescription

This medical philosophy translates perfectly to building products.

Charles Kettering, the legendary inventor and head of research at General Motors, had a principle that every PM should tape to their monitor:

“A problem well-stated is a problem half-solved.”

It means sometimes stepping away from the analytics dashboard. Data tells you what is happening; it will never tell you why.

Great PMs don’t just read user feedback; they observe the context of the user. They sit in the back of a chaotic 7th-grade classroom and watch how a teacher’s anxiety spikes when the Wi-Fi drops, realizing that “offline mode” isn’t a technical feature - it’s an emotional safety net.

They watch a dyslexic student quietly abandon a math problem, not because the math is too hard, but because the text density of the word problem is overwhelming.

When you understand the problem at this level, your roadmap changes entirely. You stop building features to close OKRs, and you start building tools that actually alter the trajectory of a student’s day.

Look Outside the Classroom

The PMs who truly understand human behavior rarely confine their research to their own industry.

If you want to understand how to teach complex, multi-step problem-solving, don’t look at other EdTech platforms. Look at how modern video games teach players incredibly complex resource-management mechanics without ever showing them a tutorial screen.

If you want to understand habit formation, look at behavioral economics and fitness apps. You have to synthesize signals from psychology, game design, and social media to understand how your students are being rewired by the world around them.

The Flip

I’ve just spent a few minutes tearing down the concept of being a “problem solver.” But let me flip this on its head.

Solving problems is still your job. It’s just the easiest part of your job. Writing the code, designing the UI, and shipping the feature is the mechanical outcome of the work.

The real craft of product management lies in the discipline of refusal. It’s having the courage to look at a perfectly viable, highly requested feature and say, “No. That treats the symptom, not the disease.”

The next time a customer hands you a problem, don’t rush to the whiteboard to sketch a solution.

Sit with it.

Interrogate it.

Turn it over in your hands.

Because solving a problem ends the conversation. But understanding a problem changes the product entirely.