Great product teams already ask great questions.

They ask about the user.

They ask about the problem.

They ask about assumptions, metrics, research, and experiments.

And yet — even the best product and design teams occasionally ship features nobody uses, build elegant solutions to the wrong problems, or fall in love with ideas too early.

If teams are already asking good questions, why does this still happen?

After spending years sitting in product design sessions as a business leader, I've noticed a pattern. Talented teams engage in thoughtful discussions with the best intentions — yet the conversation slowly drifts toward a solution that ultimately costs the team valuable time.

Not because the team lacked intelligence.

But because the thinking behind the thinking was never examined.

This raises an interesting possibility.

What if the real opportunity in product design isn't asking better product questions?

What if it's asking a different kind of question — one about how we're thinking in the first place?

This is where the idea of MQ — Metacognitive Intelligence — enters the conversation.

The Metacognitive Layer of Product Thinking

MQ builds on decades of research about metacognition, the ability to think about our own thinking.

In simple terms, MQ describes the ability to examine and improve not just decisions — but the thinking process across teams that produced them.

In product and design teams, this means stepping back and asking a deeper question:

How did we arrive at this way of thinking about the problem?

That shift may seem small.

But it changes the entire conversation.

The Limits of Traditional Product Questions

Modern product teams are already disciplined thinkers.

They ask questions like:

• What problem are we solving?
• What assumptions are we making?
• What does the user want?
• How can we test this idea quickly?

These are foundational questions embedded in the best product cultures.

But notice something about them.

They still operate inside the current frame of thinking.

When a team asks, "What problem are we solving?", they are already assuming their framing is roughly correct.

But sometimes the real issue isn't the solution.

It's the frame itself.

Teams may begin with the wrong interpretation of the problem, the wrong mental model of the user, or the wrong assumptions about what matters.

Traditional product questions refine ideas.

MQ questions refine the thinking that produced the ideas.

The MQ Shift in Product Conversations

Traditional product discussions focus on improving solutions.

MQ-oriented discussions focus on improving thinking.

Instead of asking:

"What problem are we solving?"

MQ introduces questions like:

• How did we decide this was the problem?
• What signals led us to frame it this way?
• What evidence would suggest our framing is wrong?

These questions reveal the reasoning process behind the current direction.

Once that thinking becomes visible, it can be improved.

From Assumptions to Assumption Systems

Product teams often talk about assumptions.

MQ goes one step deeper.

Instead of only challenging the assumption itself, MQ challenges how the assumption was formed.

High-MQ teams ask questions like:

• What mental model is generating these assumptions?
• What evidence originally led us to believe this?
• Are we relying on past experience that may no longer apply?
• What belief is this assumption resting on?

These questions reveal something important.

Assumptions rarely exist in isolation. They emerge from deeper beliefs and mental models.

If those mental models are flawed, the entire product direction can drift.

A Simple Example

Imagine a team building analytics software.

They might assume:

• Users want more dashboards
• Users want more control over their data
• Users want customization

These assumptions may stem from a deeper belief:

Users want control.

But what if that belief is wrong?

What if users don't actually want control?

What if they want confidence?

That shift — from control to confidence — could completely change the product direction.

Instead of building more dashboards, the team might focus on recommendations, explanations, and decision guidance.

By examining the thinking behind assumptions, MQ helps teams avoid building solutions to problems that don't truly exist.

From Problem Framing to Problem Construction

One of the most common questions in product design is:

"What problem are we solving?"

MQ suggests a more revealing question:

"How did we decide this was the problem?"

This encourages teams to trace the origin of their thinking.

Perhaps the problem came from:

• user interviews
• support tickets
• a competitor feature
• internal intuition

Each source can produce useful insight — but also partial interpretations.

When teams examine how the problem was constructed, they often discover alternative frames.

For example, a team might initially define the problem as:

"Users need better data visibility."

But after examining their thinking, they may realize the real issue is:

"Users don't trust their decisions."

Those two frames lead to very different product strategies.

MQ creates space for that discovery.

Testing the Thinking, Not Just the Feature

Product teams pride themselves on experimentation.

They run A/B tests, build prototypes, and gather user feedback.

But MQ reframes experimentation in an important way.

Instead of only testing the product idea, teams should also test the assumptions behind their thinking.

Consider a simple example: a team proposes adding a "Save for Later" feature.

Traditional experimentation might focus on testing whether the button increases engagement.

But MQ asks a deeper question:

Do users actually want to save content in the first place?

To test this thinking, teams might:

• show early mockups or concepts and observe reactions
• ask users how likely they would be to use the feature
• analyze existing behavior such as bookmarking, favoriting, or leaving tabs open

These signals help validate whether the underlying behavior already exists.

Sometimes the insight isn't about improving the feature.

It's about realizing the feature was never necessary.

Designing Better Thinking

Many teams assume the goal of product meetings is to produce decisions.

But the best teams recognize something deeper.

The real goal of a design session isn't just deciding what to build.

It's improving the quality of the thinking that produces those decisions.

When thinking improves, decisions improve.

And when decisions improve, products improve too.

In a world where product teams increasingly have access to the same tools, data, and frameworks, the real advantage may come from something subtler:

The ability to step outside our thinking long enough to improve it.

That ability — the discipline of examining the thinking behind the thinking — is exactly what MQ points toward.