The Product Manager Who Knew Too MuchThis week, I’m going to talk about a different kind of trap. The knowledge bottleneck. It happens when you, the product manager, become the person who knows everything about the roadmap, the customer, the edge cases, the trade-offs, the architecture, the goals, the caveats. That might sound like a good thing. It’s not. The longer you’re the only person with context, the more you turn into a blocker. You slow down decision-making. You burn out. Your team can’t move without your input, which feels great for your ego but terrible for the product. If you want to scale as a Product Manager, you need to stop being the center of every conversation and start distributing your knowledge like it’s your job. Because it is. Product folks are rewarded for knowing things. The more you’ve memorized, the smarter you look. The more fluent you are in every Jira ticket, Slack thread, and stakeholder request, the more you seem “on top of it.” But knowledge isn’t leverage if it’s locked in your head. It becomes a liability. And most PMs don’t realize this until it’s too late and they’re drowning in context-switching, answering the same questions six times a week. Hoarding knowledge makes you a bottleneck, not a leader.You don’t scale by being the smartest person in the room. You scale by making other people smarter without you in the room. Takeaway 1: If every decision routes through you, you’ve failed Let’s say a designer wants to finalize a flow but can’t move forward because they’re unsure about a customer use case. They ask you. An engineer has a question about an edge case. They ask you. A stakeholder needs to know why the roadmap changed. They ask you. Multiply that by a 6-month initiative and you’re now the human API for your product. People ping you for context instead of having the tools to figure it out themselves. This might feel like job security. It’s not. It’s job fragility. Because the moment you’re out; on vacation, parental leave, switching teams, the product grinds to a halt. Stop hoarding context. Start building systems that outlive you. Takeaway 2: Knowledge isn’t power if no one else has it PMs love to say they’re “the connective tissue” of the org. But if the tissue is only inside your head, you’re not connecting anything. You’re just centralizing it. Your job is not to memorize everything. Your job is to externalize. That means shared docs, not private notes. It means project updates that are written like they’re for someone who just joined the company. It means onboarding teammates with clarity, not half-explained references to past Slack threads. Documentation sounds boring until you’ve lived without it. Then it becomes the difference between a fast-moving team and one that’s stuck in a loop of "who knows the answer to this?" Write the thing down. Share it early. Share it often. Repeat yourself on purpose. Takeaway 3: If only you know the roadmap rationale, your roadmap is fragile Every roadmap has a story behind it. Here's why this thing made the cut and that one didn’t. What trade-offs were accepted. What bets were made. The problem is, most of us forget to share that story. So when your roadmap gets questioned, (and it will) your team is forced to defend a plan they didn’t help shape and don’t fully understand. That erodes trust. It also slows everything down because every challenge to the plan gets escalated back to you. A strong roadmap shoudln't be a list of features. It’s a set of shared decisions. If you’re the only one who can explain them, you’ve built a fragile narrative. A resilient one is co-owned and co-defended. Stop being the narrator. Make your team part of the authorship. Takeaway 4: High-trust teams don’t rely on hero PMs You know what a “hero PM” is. It’s the person who shows up at 9 PM to answer the question nobody else can. Who jumps in when a critical bug report comes in because they’re the only one who remembers the original intent behind the feature. Who gets tagged in every Slack thread because “they’ll know.” Sounds noble. It’s not. Hero PMs build fragile teams. The more you center yourself as the source of truth, the more you teach people not to think for themselves. And don't forget, few things annoy people more than an overbearing hero that corrects them or adds context over them every time they open their mouth. Over time, this creates a team that hesitates. That defaults to asking instead of deciding. That waits for the PM to make the call, even when they’re perfectly capable. Want a high-trust, high-velocity team? Be boring. Be predictable. Document decisions. Make your team the hero, not you. Takeaway 5: The more senior you are, the less of a repository you should be Senior Product Managers get rewarded for elevating others. (Or at least in a strong Product organization they do). If you’re trying to level up, stop measuring your value by how many answers you can give. Start measuring it by how often you don't need to because someone else on the team already knows it. That’s real influence. That’s scale. That’s leadership. The easiest way to spot a true Product leader isn’t their title. It’s how quiet they are in meetings. Not because they’re checked out, but because they’ve already empowered their team to operate with clarity and context. The best Product leader I ever worked with had an uncanny sixth sense for only interjecting when he was truly needed. He understood that doing it excessively cut you down at the knees and made you look junior and unknowledgeable. Even if you didn't share his style or method of communicating. In Conclusion It’s tempting to think that being the most informed person on the team makes you indispensable. But in product, being indispensable is a failure mode. It means you haven’t scaled. It means you’ve built a knowledge silo with your name on it. The best PMs don’t hoard context. They spread it. They make the roadmap, customer insights, technical trade-offs, and product decisions easy to access, easy to understand, and easy to defend without needing to be in the room. You don’t get promoted by knowing the most. You get promoted by making sure the team knows enough to move without you. Be the source of clarity, not the source of all answers. Then go do the work that only you can do. Thanks for reading. See you next week. |
I help grow the practice of Product Management by simplifying and demystifying the things that help you go from Product Novice to Product Ninja in no time
Why Most Product Ideas Die Quietly The backlog is where good ideas go to die. For most product managers, it becomes a cluttered mess of stakeholder requests, customer quotes, aspirational ideas, and one-off experiments that never went anywhere. The signal gets buried under noise, and when planning time rolls around, nobody can make sense of it. It creates chaos instead of clarity. And worse, it makes product managers look unorganized and indecisive. They treat the backlog like a museum...
Stop Prioritizing Speed Over Progress Today we're going to discuss the difference between real product progress and the illusion of momentum created by speed. Early-career product managers often get praised for being "fast." People say "Fail fast" or "Be quick to pivot". And while those statements good mantras generally speaking, speed can be deceptive. Moving quickly doesn’t mean you’re moving in the right direction. And it certainly isn't an indicator of progress. Over time, chasing speed...
The Trap of “Being Helpful” This week, I’m going to walk you through one of the most common traps junior and even mid-level product managers fall into: mistaking responsiveness and availability for effectiveness. It starts innocently. You answer questions quickly, offer to write up docs, sit in extra meetings, and jump into every problem. But before long, you’re underwater. Your core responsibilities slip, and you’re not seen as a strategic leader. You’re seen as “the person who helps out.”...