The Curious PM: Why the Best Product Managers Ask the Worst Questions

A PM I coached found something strange during a customer visit.

She was shadowing nurses on a hospital ward. Twelve-hour shifts. High-stakes clinical work. She expected to see burned-out clinicians struggling with complex medical decisions. What she actually noticed was different. Thirty percent of the nurses' shift was consumed by manual note taking and vital sign calculations. Not medicine. Paperwork.

Most PMs would document that finding and move on. "Automate the manual process." Check the box. Ship the feature.

She didn't. She stayed uncomfortable with it. Why hadn't anyone solved this already? Hospitals spend billions on technology. Patient monitoring systems have existed for decades. So what was keeping this problem alive?

She spent weeks pulling on that thread. She mapped the full stakeholder network around the workflow she was studying. She discovered that the existing systems weren't designed for the way nurses actually worked with multiple patients simultaneously. The "obvious" fix (automate note-taking) would have been a band-aid. The real problem was architectural. She proposed moving monitoring off the bedside and into one place, so a single station could track several patients at once.

That instinct to stay bothered is the most important skill in product management. And I can't teach it.

The pattern across 500 coaching conversations

I've coached over 500 product managers. I can teach frameworks, stakeholder management, business case development, strategy articulation. Give me three weeks and I'll change how someone thinks about their product.

I cannot teach someone to be curious.

Not the performative kind. Not the "5 whys" exercise in a retro where everyone goes through the motions. I mean the PM who hears a customer describe their workflow and gets physically uncomfortable because something doesn't make sense. The one who leaves the meeting and keeps turning the problem over at dinner because they haven't found the root cause yet.

The PMs who got promoted within twelve months of our coaching shared one pattern. They asked better questions. Not more questions. Better ones. Questions that made me rethink my own assumptions about their problem space. Questions that told me they'd been thinking about the problem outside our sessions, not just during them.

The PMs who took much longer shared a different pattern. They wanted the answer. "What framework do I use here?" "What should I prioritize?" "What would you do?" Those are reasonable questions. But they're consumption questions, not curiosity questions. The difference matters.

Consumption questions vs. curiosity questions

A consumption question seeks an answer to apply. "How do I structure a roadmap presentation?" That's useful. It has a correct-ish response. You can apply it tomorrow.

A curiosity question seeks understanding that changes how you see the problem. "Why does every roadmap presentation I give end in a negotiation over features?" That question doesn't have a clean answer. It forces you to look at incentive structures, stakeholder dynamics, and organizational culture. It leads somewhere you didn't expect.

Consumption questions fill gaps in knowledge. Curiosity questions challenge the frame around the knowledge.

Both are valuable. But the ratio between them is diagnostic. A PM who asks mostly consumption questions is looking for tools. A PM who asks mostly curiosity questions is looking for understanding. And the second type finds solutions that the first type never considers.

Why curiosity is upstream of everything

Every framework I teach assumes one thing: that you genuinely want to understand the problem deeply enough to solve it well. Strategy articulation, incentive mapping, stakeholder management, customer discovery. All of them break down if you're filling in templates instead of investigating reality.

Think about a PM who discovers that nurses are spending 30% of their shift on manual calculations. The average PM writes a user story: "As a nurse, I want automated vital sign calculations so I can spend more time on clinical care." Done. Backlog updated. Sprint planned.

The curious PM asks different questions. Why hasn't anyone solved this in 20 years of hospital IT investment? What have they tried before? Who benefits from the current system staying broken?

That last question is uncomfortable, and it's usually where the real answer lives.

The second layer of questioning is where product insight comes from. Stop at the first layer and you get a feature request. Push through to the second and you find the actual product opportunity.

The self-diagnostic

There's a practical test for this. Think about your last customer interview or stakeholder meeting. Afterward, did you have a clean list of action items? Or did you have a nagging question you couldn't quite articulate?

The action items feel productive. The nagging question is where the value is.

If the meeting ended and you felt satisfied, like everything made sense and you knew what to do next, that's worth examining. Clarity itself is fine, but real problems rarely resolve that cleanly on the first pass. If it felt clean, you might have been hearing what you expected to hear instead of what was actually being said.

The PMs who find the real opportunities are the ones who leave meetings more confused than when they walked in. Confusion is a signal. It means you noticed something that doesn't fit your model. And updating your model based on what you noticed, that's the actual work of product management.

Curiosity applied to an interview

A PM was preparing for a VP-level role at Bonterra, which had acquired a mobile-first fundraising platform. She'd done her research. Understood the product. Had talking points ready.

I told her to stop preparing answers and start preparing questions.

Specifically: think about what the person sitting across from you would need to do to get fired. That single mental exercise tells you what they actually care about. Not what the job description says. What this specific person is worried about right now.

She shifted her entire approach. Instead of demonstrating competence, she became genuinely curious about the interviewer's reality. She asked questions that made interviewers want to keep talking. When time ran out before they'd finished their questions, they left the conversation wanting more.

She was treating the interview as a product problem. Who is the user? What do they need? How do I deliver value in 45 minutes? That's curiosity applied to a real situation.

Same instinct the researcher had when she stayed uncomfortable with the paperwork problem. Same pattern the fast-promoting PMs show in coaching sessions. They're more interested in understanding the problem than in having the answer.

Can you build curiosity?

Curiosity isn't a personality trait you either have or you don't. But it is a muscle. And like any muscle, it atrophies when you stop using it.

The PM who spends two years executing someone else's roadmap without questioning why it's structured that way will find it harder to ask deep questions when they finally get the chance. Not impossible. Just harder. The muscle isn't gone. It's just out of shape.

There are ways to exercise it.

Next time you're in a meeting and someone presents a plan, notice the question you're too polite to ask. The one that might make things awkward. "Why did we choose this approach over the alternatives?" "What evidence do we have that this is the right problem to solve?" "What would need to be true for this to fail?" Write that question down, even if you don't ask it. Then follow up on it afterward.

When you're reading a product spec, find the assumption that nobody stated explicitly. Every spec has them. "Users will adopt this because it's better" is an assumption. "The API can handle the scale" is an assumption. "Engineering can build this in the estimated timeline" is an assumption. Pick one and investigate it.

When a customer says something that surprises you, don't explain it away. Sit with the surprise. "That's interesting, tell me more about that" is the most powerful sentence in product discovery.

The question I leave every PM with

When was the last time something at work genuinely bothered you because you didn't understand it?

Not "what's our OKR for this quarter" bothered. "I need to figure this out or it will keep nagging me" bothered.

If you can point to something specific in the last two weeks, you're probably in good shape. If you have to think hard about it, that's worth sitting with.

The PMs who keep that muscle active are the ones who find the real problems. They stay uncomfortable with things that don't make sense. They ask the second and third question after everyone else has moved on. And finding the real problem is the whole job.

Keep reading: Curiosity without direction becomes a feature factory. The PMs who channel curiosity into influence do it by building the right relationships in their first 90 days. And the questions that matter most? The ones that connect user problems to business outcomes.

Want to see where you fall? Take the free 5-minute PM Diagnostic.