Knowing What You Don't Know

One of the things I have started to realise about Product Management is that becoming a better PM is less about collecting frameworks and more about developing a way of thinking.

You can learn how to structure a Product Design interview. You can memorise prioritisation frameworks. You can practise guesstimates, product improvement questions and root cause analysis. You can become comfortable talking about metrics, roadmaps, funnels and user journeys.

But none of that guarantees that you will identify the right problem.

And that, to me, is one of the hardest parts of Product Management.

The more I think about it, the more I believe Product Management is not a skill that you simply learn once and master. It is a journey. Most of the skills that make someone a good Product Manager are developed through experience, mistakes, conversations, observation and, perhaps most importantly, a willingness to recognise how much you still don't know.

This idea came out of a conversation I had with a Lead Product Manager who had previously worked in wealth management. We were discussing how Product Managers approach ambiguous problems, and the conversation eventually led us to a simple mental model that I found surprisingly useful.

It is the idea of separating what we know from what we don't know.

At first, it looks like a very simple framework. But I think it captures something fundamental about how Product Managers should approach problems.

I Know What I Know

The first quadrant is the most comfortable one.

These are the things we know with reasonable confidence. They might come from data, user research, direct observation, previous experience or established facts about the product.

Imagine that we are exploring a problem around group rides for motorcyclists. We might already know that riders in a group can travel at different speeds. We might know that riders have different fuel requirements and that some riders can fall behind. We might also know that people already use phones, location sharing and intercoms to coordinate with one another.

These are useful starting points because they give us something concrete to work with.

The important thing, however, is not to immediately turn these facts into a solution. A Product Manager should first separate facts from assumptions. Knowing that riders can get separated, for example, does not automatically mean that a new location-sharing feature is the right solution.

The question is whether the evidence actually tells us that this is a problem worth solving and whether users would value a better solution.

This is where the first quadrant becomes useful. Establish what you actually know before deciding what you should build.

I Know What I Don't Know

The second quadrant is where Product discovery usually begins.

These are the questions we are consciously aware that we cannot answer yet.

Going back to the group riding example, we might know that coordination could be a problem, but we may not know how frequently the problem occurs. We may not know how many people typically participate in a group ride, how often riders actually get separated or how painful that experience is when it happens.

We may also not know whether riders would use a dedicated feature. Perhaps they already have a perfectly acceptable solution through their intercoms. Perhaps they would prefer something else entirely. Perhaps the problem happens frequently but isn't painful enough for users to change their behaviour.

These are known unknowns, and that makes them relatively manageable.

Because we know that we don't know something, we can investigate it.

We can interview users, analyse behavioural data, conduct surveys, build prototypes or run experiments. The uncertainty becomes a research question.

This is probably the part of Product discovery that most people are familiar with. We identify what we need to learn and then find ways to learn it.

But the other two quadrants are where things get much more interesting.

I Don't Know What I Know

This quadrant initially sounds contradictory.

How can you know something without knowing that you know it?

I think this happens much more often than we realise.

Sometimes we have already seen the evidence. We may have experienced something ourselves, heard customers talk about it or noticed a recurring behaviour. But we haven't consciously connected that observation to the problem we are currently trying to solve.

Imagine that I have personally noticed that groups of riders naturally slow down at certain junctions. Maybe I have seen people repeatedly ask, "Where is everyone?" Maybe I have noticed that riders use different communication channels depending on what is happening. Perhaps I have also seen someone stop unexpectedly and watched the rest of the group become anxious because nobody knows why they stopped.

Those observations may have existed in my head for years.

But until I connect them to a Product problem, they remain unused knowledge.

This is where experience becomes extremely valuable in Product Management.

Experienced PMs often have a large mental library of observations and patterns. They may hear a new problem and immediately remember something from a completely different situation that could be relevant.

That does not mean they automatically have the answer.

It means they have more things to investigate.

This is one reason I believe Product Management gets better with experience. You don't simply accumulate frameworks. You accumulate observations, patterns and context. Over time, something that once seemed unrelated can suddenly become useful evidence for a completely different problem.

I Don't Know What I Don't Know

The fourth quadrant is the one I find the most interesting, and probably the most dangerous.

These are the questions we haven't even thought to ask.

We don't know that they exist.

Imagine we are designing a feature for group motorcycle rides. We might spend hours discussing how riders should see one another on a map, how a group should be created and how notifications should work.

But perhaps we never ask what happens when someone intentionally leaves the group.

We may not think about what happens when someone loses network connectivity or when GPS becomes inaccurate. We may not consider whether constant location sharing creates privacy concerns or whether notifications could actually distract riders while they are moving.

We might also make a much bigger assumption without realising it.

Perhaps group riders aren't even the most important segment. Maybe families travelling together have a much stronger coordination problem. Maybe the real opportunity isn't group navigation at all.

These are unknown unknowns.

And this is where Product thinking becomes more than answering the questions that have already been identified.

A strong Product Manager needs to develop the habit of actively searching for blind spots.

The Fourth Quadrant Is Where Product Discovery Gets Interesting

I think this is one of the biggest differences between solving a Product case and actually doing Product Management.

In an interview, it is tempting to demonstrate that you have identified all the important questions. You might say, "Before building this, I would validate these five assumptions."

That is good Product thinking.

But there is another level.

What if there is a sixth assumption that you haven't identified?

What if the entire framing of the problem is wrong? What if the user segment is wrong? What if the problem is real but not important enough to solve? What if the proposed solution creates a new problem somewhere else? What if the metric we are optimising isn't actually the metric that matters?

Those questions force us to step outside the original framing.

That is where I think some of the strongest Product thinking happens. The goal isn't to prove that we have all the answers. The goal is to remain open to the possibility that we haven't even discovered the right question yet.

Product Management Is A Journey, Not A Checklist

This is also why I have become less convinced by the idea that Product Management can be learned as a fixed collection of skills.

Of course, there are skills that matter. A PM needs to understand users, work with data, communicate clearly, prioritise, understand technology, think about business models, run experiments and collaborate with design and engineering.

But many of these skills only become meaningful when you use them repeatedly in real situations.

• You learn prioritisation when there are more important problems than resources.

• You learn stakeholder management when two teams genuinely disagree.

• You learn data analysis when the numbers don't tell a clean story.

• You learn user research when customers tell you something completely different from what you expected.

• You learn technical fluency when an implementation constraint forces you to rethink your product.

And you develop Product judgment by making decisions, seeing their consequences and gradually becoming better at recognising patterns.

A course can teach you the framework. Experience teaches you when the framework isn't enough.

The Willingness To Say "I Don't Know"

One thing I increasingly noticed in good Product Managers is their willingness to say, "I don't know."

That sentence can feel uncomfortable, especially in interviews where you are expected to demonstrate confidence.

But there is an enormous difference between saying "I don't know" and stopping there.

A strong PM can say, "I don't know, but here is how I would find out."

If I don't know how frequently users experience a problem, I can investigate it. If I don't know which segment experiences the problem most severely, I can find out. If I don't know whether a proposed solution will change behaviour, I can design an experiment. If I don't know whether my interpretation of the data is correct, I can validate the assumption.

Not knowing is not the problem. Not knowing that you don't know is the problem.

Curiosity Is A Product Skill

This is where I think curiosity becomes more than just a personality trait.

A curious PM doesn't stop at the first reasonable explanation. They ask what else could be happening. They look for contradictory evidence. They speak to users who disagree with the majority. They question metrics that look too good. They investigate edge cases. They ask engineers what could break and designers what users might misunderstand.

Most importantly, they question their own framing. They ask whether the problem they are solving is actually the problem worth solving. That constant questioning gradually expands the boundaries of what the PM knows. And over time, those expanding boundaries become part of their judgement.

Thinking Outside The Box Doesn't Mean Having Crazy Ideas

"Think outside the box" is one of those phrases that gets used so often that it has almost lost its meaning.

I don't think Product thinking is about constantly coming up with unusual ideas. Sometimes the best Product insight is extremely simple. Thinking outside the box can mean questioning the box itself. If everyone is discussing how to improve a feature, ask whether the feature should exist. If everyone is discussing how to improve conversion, ask whether conversion is actually the right metric.

If everyone is discussing a particular user segment, ask whether another segment is experiencing a more important problem. If everyone is optimising the existing workflow, ask whether the workflow itself is necessary. The goal isn't to be unconventional for the sake of being unconventional. The goal is to avoid becoming trapped by the assumptions that came with the original problem statement.

A PM's Mental Model Should Keep Expanding

I think of the four quadrants as a moving system rather than four permanent boxes.

Something can start as an unknown unknown. You discover it through observation, and it becomes a known unknown. You investigate it, and it becomes something you know. Eventually, through repeated experiences, you develop enough pattern recognition that you begin noticing similar situations before someone explicitly points them out.

The cycle keeps repeating.

And that is what makes Product Management such a continuous learning process.

You never reach a point where you know everything.

Instead, the quality of your questions improves.

You become better at recognising what matters, identifying what you need to learn and noticing when something doesn't fit your existing understanding.

How I Want To Use This In Product Problems

I've started thinking about this framework whenever I approach a Product problem. Before jumping into solutions, I want to understand what I actually know and what I am assuming.

I want to establish the facts first. Then I want to identify the questions I consciously don't have answers to. After that, I want to think about what experiences, observations or patterns I might already have that are relevant to the problem but haven't consciously connected yet.

Finally, I want to deliberately search for blind spots. That last step is difficult because you cannot simply list an unknown unknown. If you knew what it was, it wouldn't be unknown. Instead, you can create conditions that make blind spots easier to discover.

Talk to someone with a different perspective. Speak to a user who behaves differently from the majority. Challenge the original framing. Look at edge cases. Try to disprove your own hypothesis. Ask what happens if one of your assumptions changes. The objective isn't to predict every possible unknown. It is to develop a mindset that remains open to discovering them.

This Changes How I Think About Product Interviews

There is an interesting lesson here for Product interviews. When an interviewer gives you a case, the obvious objective is to solve it. But perhaps the better objective is to understand it first. If someone asks, "Design a product for group motorcycle rides," the weakest response is to immediately start designing features. A stronger response begins by understanding the user, the context and the problem.

An even stronger response starts identifying what is known, what is uncertain and what might be missing from the problem statement entirely. That doesn't mean spending the entire interview asking questions. It means demonstrating that you understand the stated problem may not contain the entire problem.

And I think that is a much more authentic representation of Product thinking.

What My Conversation With A Lead PM Changed For Me

The conversation that led me to this framework wasn't a formal lesson. It was simply a discussion with someone who had spent years working across different domains, including wealth management, and had developed a very different way of looking at problems. What stayed with me wasn't a particular framework or a particular product idea. It was the mindset behind the conversation. A Product Manager should not be afraid of the gaps in their knowledge.

Those gaps are where discovery begins.

The important thing is to understand which gaps exist, actively search for the ones you haven't identified yet and remain open to changing your understanding when new evidence appears. That is much harder than memorising a framework. It is also much more useful.

Final Thoughts

The longer I explore Product Management, the less I think of it as a profession where you eventually become "good enough" and more as a journey where your mental model keeps expanding.

You learn from users. You learn from data. You learn from engineering. You learn from design. You learn from mistakes. You learn from products that failed. You learn from products that succeeded for reasons you didn't expect. You learn from people who have worked in completely different industries.

And sometimes, you learn from a simple conversation that gives you a new way to look at a problem you thought you already understood. For me, the four quadrants are a useful reminder that knowing the answer is not always the goal. Sometimes the most valuable thing a PM can discover is a question they didn't know they needed to ask.

The journey from "I don't know" to "I know" is where learning happens.

But the journey from "I don't know what I don't know" to discovering that blind spot is where Product thinking really begins.

Product Management isn't just about finding the right answers. It is about continuously getting better at finding the right questions.