#47 - Designing confidence as a Product Manager

Hi all 👋, this week I finally settled down a bit at work, so I've written another short blog post about what's on my mind. Hope it's useful to someone somehow!

“Everyone expects me to have the answers, but half the time I’m just hoping no one calls on me. I know I should speak up more, but I’m scared I’ll sound like I don’t know what I’m doing.”

I've observed this sentiment from many PMs I've met over the years, and even felt it myself sometimes. And no, this post is not about imposer syndrome. That's a related topic, but maybe for another day. What I want talk about here is, as the title suggests, confidence.

PMs are expected to be confident, sometimes unreasonably so. We’re the ones making hard decisions with incomplete information, framing trade-offs, speaking on behalf of users we haven’t met and systems we didn’t build. We’re expected to know the intimate details of our product, our customers, our metrics, our roadmap, and to communicate all of that with clarity and conviction.

This expectation isn’t just about making others think that you're confident in meetings. It’s more existential than that. PMs operate at the intersection of ambiguity and accountability. When things go sideways, people look to us for answers. Whether it’s stated or not, confidence is part of the job description.

There’s plenty of advice on how to “build confidence” as a PM. Know your product deeply. Seek feedback. Learn from failure. Master stakeholder communication. These are all helpful, but I think they treat confidence as a collection of habits or traits, not as something you can systematically think about and develop.

In this blog post, I propose a more structured way to look at confidence and build confidence, particularly if you're a Product Manager.

Confidence as Form-Context Fit

Confidence is often described as a feeling. But that’s not particularly useful, especially not for a PM. A more useful frame is this: confidence is a signal. It’s what you feel when your internal understanding - your mental model of the product, the problem, the people - actually fits the situations you're in.

That means true confidence only emerges when two things align: the form (your internal knowledge structure), and the context (the real-world conditions where that structure gets tested). If those two things match, you feel confident. If they don't, you don't - no matter how smart you are or how much you know. This perspective emphasizes on true confidence, and less about the kind of pseudo-confidence you feel when people think you know what you're talking about but you actually don't. I'll come back to this at the end of this blog post.

This idea draws from the work of Christopher Alexander, the architect and design theorist who introduced the concept of "Form-Context Fit." (avid reader of this newsletter will know that this is not the first time I mentioned this concept). According to Alexander, a good design isn’t just elegant in isolation. It must resolve tensions in its environment. It works because it was shaped by the forces it needed to withstand. When you apply this to knowledge, you have a pretty useful reframing:

Under this view, knowledge is treated like a design object, and confidence is how well your knowledge match against its context of use.

Treat knowledge as a design object 

So what happens when you treat knowledge as a design object?

Most people try to build confidence by learning more. That instinct isn’t wrong. It's just incomplete. If you look at the design world, then designers can get too fixated on the form by obsessing over visual details, clever interactions, or elegant ideas. Similarly, PMs too can fall into the trap of trying to perfect their understanding of a topic in isolation. You read a bunch of blog posts, collect frameworks, or debate terminology. You polish your “cup” of knowledge until it looks beautiful on the shelf. But what’s the use of a polished cup if it leaks when you pour tea into it?

In Alexander’s framing, a design is only good if it works in its context: if it enables activities and resolves tensions in the space where it’s used. Likewise, your knowledge is only as useful as its ability to hold up under pressure: in meetings, during debates, when questioned by skeptical stakeholders. If you’ve only focused on form and not on fit, you’ll feel it when you're in situations where your knowledge are stress-tested. The feeling of uncertainty in the pit of your stomach is a misfit. That’s a signal that you should pay attention to.

If the lack of Product-Market Fit scares you as a Product Manager and forces you to re-evaluate how you're developing your product, then the lack of Form-Context Fit for knowledge should also scare you so much that you evaluate how you're developing your knowledge.

Confidence is not the result of mastering concepts in the abstract. It’s the result of building knowledge that survives contact with reality. That means your learning process has to change:

This shift begins with asking a better question: not “What should I know?” but “Where will I need to use this?” What situations will this knowledge be tested in? What kinds of conversations will it shape? What scrutiny will it face?

To design for fit, you need to put your model into contact with context early and often. Here's a few things I've found helpful:

• Book time with a colleague you trust (usually your Engineering Manager or Tech Lead) and walk them through what you know about a topic. Don’t just ask for their input, or "does this make sense?" Ask them: “What feels vague? What assumptions feel off? Where do you feel unsure listening to me?” Their uncertainty reveals where your knowledge is leaking. The key thing here is to find people you can trust and who're willing to help you. If you don't have someone like that at work, then you should really start building these relationships.
• Another way is to simulate how you’d report your progress in a weekly review with senior stakeholders. Speak it out loud, as if to your VP of Product or Head of Product. Can you summarize what’s happening, what’s blocked, and what’s next - clearly, concisely, and with context? If your update feels confusing or too shallow, that’s a design problem in your model. I suffer from this problem myself, where I couldn't provide a concise update. It takes good knowledge of a topic to determine what's important and needs to be communicated, and what can be omitted. You can also go further and think about how you're gonna respond when your boss asks follow-up questions.
• Another way is to actually sit down to complete a task or an artifact that you'll share with others. For example, create a roadmap, then imagine the hardest critic in your org reviewing it (we all have that one person, they might not always hate you, but they're sure very critical of ideas). What would they ask? What wouldn’t stand up to scrutiny? What would you struggle to defend? When you design your knowledge with this kind of friction in mind, you're testing how your form fits into its context of use.

Confidence grows from these small moments of real contact. Each one is a design check.

Confidence as something you can iterate toward

And that brings us back to confidence. When you frame it not as a trait, but as the Form-Context Fit of your knowledge, it becomes far more useful. It becomes something you can iterate toward (just like a product or a design).

Smartness has nothing to do with it. Being smart might help you acquire knowledge quickly, but that doesn’t mean you can stand up under pressure. In fact, the kind of "confidence" people associate with sounding smart (saying things that go unquestioned or refusing to engage with the messy reality) is often more dangerous.

It’s easy to sound confident that way, but the moment you’re pressed, it falls apart. That’s not real confidence. That’s optimizing for the feeling of confidence itself, rather than designing your knowledge to actually hold up in the situations it needs to. Knowledge that isn’t tested, that can’t survive scrutiny, is like an elegant cup of tea with a hole at the bottom. Looks great. Useless in practice.

Finally, going a bit meta and using the concept of Form-Context Fit as an example, I have mentioned it multiple times on this newsletter and have a lot of private notes examining this concept in various angles. This is how I've been developing my knowledge about the concept, by trying to instantiate the concept in various circumstances. I feel relatively confident when talking about it, but I have to continue to seek more situations where I have to put what I understand about this topic into test, so that my internal mental models actually match well against their context of use. Otherwise, it's just me feeling good about myself for knowing the name of yet another concept in Product Management.

Test your model. Again and again. Learn where it breaks down. Learn where it becomes vague. Then refine. That’s how designers work, and that's also how confidence can be designed.