The Root of Good Product

There are hundreds of "frameworks" for how to do product and in aggregate their performance is poor. The reason most frameworks do not work is not that they are wrong. It is that they are a way to avoid the part that is actually hard: sitting with what you do not know long enough to see clearly.

I have watched smart people adopt every new process, every prioritization method, every strategy template. In many cases I have been one of these people. We fill in the boxes. We build the trees. We present the output. And the products we built are mediocre anyway, because the quality of thinking that went into those boxes, trees, and maps was subpar.

Two Comfortable Lies

There are two stories we tell ourselves about why some product people are better than others.

The first: it is a gift. Some people have taste, intuition, a feel for what users want. You either have it or you do not.

This story is comforting because it absolves you of responsibility. If the skill is innate, there is nothing to practice.

The second: it is a process problem. Adopt the right framework, the right way to prioritize, the right research method, the right sprint cadence, and good products will follow. This story is also comforting, because it means the answer is external. Buy the right tool. Read the right book. Attend the right workshop.

Both stories are wrong. And they are wrong in the same way: they locate the problem anywhere except where it actually lives, which is in the quality of thinking itself.

What I Mean by Thinking Quality

I do not mean intelligence. I have worked with brilliant people who made terrible product decisions, and with people of ordinary intelligence who made extraordinary ones. The difference was never horsepower. It was something closer to clarity.¹

Thinking quality, as I have come to understand it, is three things working together.

Knowing the territory. Not just the market, but how people think of the market, which people like what and why. The actual, specific ground your product occupies. The daily frustrations of real people. The workflows they have cobbled together.

The thing they do before they open your product and the thing they do after they close it. This is not knowledge you get from a report. It is knowledge you get from proximity.

Assimilating to the customer. The ability to suspend your own assumptions long enough to understand what someone else is actually trying to do and what they are actually feeling while they do it. This is not empathy in the warm, interpersonal sense. It is a discipline: running someone else's experience through your own mind without coloring it with your preferences.

Being comfortable in the fog. The willingness to stay in uncertainty without reaching for a premature answer. Most bad product decisions are not the result of choosing the wrong option. They are the result of choosing too early, before the problem was actually understood, because the discomfort of not knowing became unbearable.¹

These three points are not personality traits. They are practices, and they compound.

The Garbage You Already Believe

The biggest obstacle to better thinking is not a lack of skill. It is the set of beliefs we already hold that we have never examined.

I have caught myself holding all of these at various points:

I am the customer expert.
This is almost never true, and it is most dangerous when it feels most certain. The moment you stop being surprised by what users tell you is usually the moment you have stopped actually listening.

If I cannot measure it, it does not matter.
This belief kills the most important product insights, which are almost always qualitative before they are quantitative. The feeling a user has when something is not quite right matters enormously, and no dashboard will show it to you.

I need to have an answer.
The pressure to perform competence in meetings, in documents, in Slack threads, in Teams threads. It is relentless.

And it produces a specific kind of bad thinking: answers that sound sophisticated but miss the actual question. You reach for abstractions and jargon because they signal intelligence. Meanwhile, the simple question (what problem does this actually solve, and how often does that problem actually occur?) goes unasked.

These beliefs are not character flaws. They are defenses born from past experience that have become part of who we are, reinforced by environments that reward certainty over curiosity. But they are the enemy of clear thinking, and they have to go.

The Simple Questions Nobody Asks

The best product thinking I have ever witnessed looked, from the outside, almost embarrassingly simple.

• What is this person trying to do right now?
• Why are they trying to do it?
• What are they feeling while they do it?
• What did they do before this product existed?
• How often does this problem come up, and how much does it matter?

These questions sound basic. They are basic. That is precisely why they work. They force you to think from the user's side of the experience rather than from the builder's side.

And thinking from the builder's side (describing what you made rather than what someone needs) is the default mode of nearly every product team I have worked with.

The simple questions are hard not because they require intelligence, but because they require humility. They require you to admit that you do not already know the answer. In a culture that rewards sounding smart, that admission is expensive.

Two Products

I worked on two products that highlight the difference between thinking that looks right and thinking that is right.

The first was a community product, pre-product-market fit. The team was genuinely impressive: a behavioral scientist, strong analytical minds, early funding, and a mountain of external research. They had done the work, or what looked like the work.

But they had a generalization problem. They had identified a broad, macro-economic trend and assumed their users felt it as a problem. The research said the problem was real. The data said the market was large.

What nobody had done was sit with actual users long enough to discover that the people they were building for did not experience the problem the way the team described it. Some did not experience it as a problem at all.

The thinking looked rigorous. It was rigorous. But it was rigorous about the wrong thing: precise answers to a question their users were not asking.

I got swept up in it. I let my fear of perception override the alarms firing in my own thinking. Surely these people have done the thinking, I told myself.²

They had legit backgrounds. They had a massive amount of research data. They had conviction. And so I deferred, when what I should have done was ask the simple questions: do the people we are building for actually feel this problem? How often? How deeply?

The second product was a service management platform. The team partnered with a union to deeply embed with their target users. They were in the community Discord every day. They had dinner with users.

They knew individual people by name, their workflows, their frustrations, the workarounds they had cobbled together. The team was saturated with reality.

And the result was not what you might expect from all that qualitative immersion. It was not a bloated product stuffed with every feature request. It was the opposite.

They could identify one specific problem. Nearly everyone experienced it deeply. And they built precisely the thing that solved it. The first week it shipped, word-of-mouth referrals poured in. Not because of marketing. Because the product did the right thing for the right people, and those people told others.

That intuition was not a gift. It was the output of immersion.

They had spent so long in close proximity to real people that their mental model of the user was detailed, specific, and alive. When a product question came up, they did not have to guess. They could feel the answer, the way a musician who has practiced a phrase a thousand times can feel when a note is wrong.

Developing Quality Thinking

The good news is that thinking quality is not fixed. It responds to practice the way any skill does, slowly at first, then with compounding returns.

Whatever distance currently exists between you and the people who use your product, close it.³ Not with more surveys. With more proximity. Read their support tickets. Join their communities. Watch them work. Sit across from them and ask what their day actually looks like. Have a real conversation where you shut up long enough to listen and actually peel back the onion on how they feel and why they feel it. Do it every week.

The goal is not to collect data points. The goal is to build a mental model so detailed that you can simulate their experience in your own mind.

In your daily practice when discussing a feature. When talking with the team. When guessing about a data trend. Answer the basic questions. Write them down. Say them repeatedly. Get real answers to them, not your own bastardized version.

In those moments when you feel the urge to immediately answer, whether due to perception or the fear of not knowing where the answer lies, resist it. Give yourself permission to not know.

The discomfort of ambiguity is not a signal that something is wrong. It is a signal that you have not yet seen clearly, and that if you wait, you might. The best product thinkers I know are not faster than everyone else. They are slower at the right moments.

What This Is Really About

The reason thinking quality matters is not abstract. It is not a career development insight.

It matters because people use what we build.

When a product is built from clear thinking, from genuine understanding of real problems, from earned closeness to real people. It shows. You can feel it.

The product does the right thing. It solves the problem it set out to solve. It does not waste your time. There is a level of delight because it understands the nuance of lived user experiences.

When a product is built from fear, from performance, from the need to ship something by a deadline regardless of whether the thinking was done. That shows too. The user pays for our lack of clarity. They pay with their time, their frustration, their quiet decision to stop using the thing and go find something else.

The root of good product work is not a framework, a process, or a gift. It is the quality of the thinking that precedes everything else. It is knowing the territory, assimilating to the customer, and being comfortable in the fog long enough to find something true.

That is the root of good product thinking.