The Curse of the Know-It-All Product Manager
Letting go of technical opinions earns respect.
You’re a product manager working on a highly advanced software or technology product. You have tons of experience, deep technical understanding, and can chart the best path forward for your development team — if only they would listen to you.
It’s common for PMs, especially those with strong technical backgrounds, to want to drive technical discussions for their product. Just because you’re the “CEO of the Product” doesn’t mean you have to know everything and make every implementation decision. By letting go of your technical opinions on “how” the product delivers the intended outcome, you can make the team much more effective.
Now you might be asking, “will the developers respect me if they think I’m not technical?” Perhaps not. But they certainly won’t respect you if you are wrong. Further, earning mutual respect means first showing that you value their role and ownership of designing and implementing the product.
Better to remain silent and be thought a fool than to speak and to remove all doubt. — Abraham Lincoln
A Product is More than Implementation
I’m not suggesting that you should ignore technology trends or that you can be incurious about how things work — quite the contrary. If you learn the finer details of your domain, you can become a well-rounded product manager.
Every product has pressing matters that have little to do with implementation. An effective product manager will get answers to essential questions: Who are the users, what will they buy? How will it be packaged and priced? How will we gain awareness and adoption? What legal or compliance requirements do we need to consider? These questions are critical to the success of the product, and you — the product manager — need to ask and answer them.
Some of these seemingly implementation-agnostic decisions will have real consequences on the development team. For example, a usage-based pricing model might require extensive metering plumbing. Your ability to discover and describe the hard limitations and negotiable constraints that a developer needs to solve for will make you an invaluable asset to the team.
How will you thoroughly investigate these issues if you spend all your time trying to outsmart the engineers?
Starting the Conversation with a Dev Leader
Many years ago, back when I was a programmer, I was sitting with a colleague in his office (I said it was long ago). A hapless product manager stumbled in and pointed at the whiteboard, which still had the leftover scribbles of a coding interview.
“COOL!” he exclaimed.
The other developer and I looked at each other. He spoke up first.
“Why do you think that’s cool?” he asked.
“That’s like… code, right?”
We both burst out laughing. Probably not the most professional response, but how could we help ourselves?
When I later became a product manager myself, I’ve shared the above scenario with my development lead counterpart to illustrate the non-technical extreme I didn’t want to become. This story helps open an up-front conversation about how we can effectively divide responsibilities — while keeping a healthy respect for each other’s point of view — in working together toward a common purpose.
What’s Behind Know-It-All Syndrome?
When we work with brilliant people, our insecurities give us a feeling of being an imposter. We think that being part of this team, this company, this project is a mistake. We think, “I’m a fake. I don’t belong.”
Working with brilliant engineers is intimidating. So we have the urge to impress the engineers on the team by surprising them with technical knowledge.
You might share some technical insight you found through hours of late-night research and get some nods of approval. But let me share a dirty little secret — they’re just humoring you.¹
Maybe not every time, but it’s better to assume they are.
I’ve fallen into this trap, more recently than I’d like to admit. I was working with an extremely knowledgeable developer on an IoT-software update tool. I got it in my head that we needed a “self-extracting” installer, something I remembered from building applications on Windows many years ago.
He patiently waited as I explained the idea and finally just rolled his eyes. I suddenly realized I was acting outside my area of expertise, and I should defer to him. I told him to forget my proposed design that it was his job to figure that out. He was relieved that I hadn’t imposed unnecessary technical constraints.
But I’m Not The Know-It-All!
At this point, you may think that your technical background is more likely to get you in trouble than to help you out. Not at all. Your technical background is an asset. It’s when you forget your role that it turns into a liability. If you hear something fishy, by all means, push back.
You may end up on a team with a weak or inexperienced development manager. Or one that flips the script and is trying to overrule you. These situations will require finesse. Your well-roundedness and your self-awareness may save the team — if used correctly.
The opposite of a Know-It-All is a Learn-It-All. An open mindset that stays curious will discover deeper truth and richer solutions to whatever problems you encounter. The older we get, the more we realize how little we know.
Break The Curse
Our brains can work against us when we’re trying to prove ourselves. Sometimes we think we’re smarter than we are. Other times we lack confidence because we look around and see so much brilliance.
If you’re a product manager, be on the lookout for how your own biases may be impacting your relationship with the development team. Focus on customer needs, understanding the market, documenting personas, clarifying priorities, and clearing the path of red tape in legal, security, privacy, and financial issues.
If you came from a technical background and you’ve transitioned to product management, it can be especially scary to let go of technical opinions. Allow yourself space to prioritize the skills and knowledge that will make you a truly exceptional product manager, not a know-it-all.
 A close friend and also one of the most productive developers I know read the draft of this story and commented, “In my experience, the best demonstration of technical depth is the ability to ask insightful questions after an explanation of the technical details. If you can consistently ask insightful questions, they won’t just be humoring you.” Wise words from the kind of person we’d all like to impress.