As a product manager, you work with customers as well as technical and non-technical teams. I am a PM who has a technical background, and explaining non-technical issues to technical teams is easier for me than explaining a technical issue to a business team or customer. Even though you may know all the details, explaining it to people with different backgrounds and perspectives is not easy.
In one meeting, you may need to talk about something at a very technical level. In other meetings, you may need to simplify what you’re talking about as much as possible. You may hear “Can you please explain that again?” from customers or non-technical teams. You can elaborate, but it doesn’t change anything until you recognize the curse of knowledge you have. The right amount of information sharing with this awareness will reduce all this extra effort.
In this article, you will learn how to overcome the curse of knowledge as a product manager, as well as see strategies to improve your communication with different disciplines.
The curse of knowledge is a bias people develop where they assume other people have the same level of knowledge they do, thereby losing the ability to communicate well with others on a given subject.
You may have experienced the curse of knowledge unknowingly in your life. For example, teaching something easy, like basic addition and subtraction, to children can be so challenging that you can’t understand how they can’t understand it! That is exactly what the curse of knowledge is — you start to assume everyone has the same level of information as you.
Because of the curse of knowledge, your dad might shout at you while teaching you how to drive a car or you might feel angry while you are helping your friend with their homework. We all experience communication problems in different areas of our lives.
The consequences of the curse of knowledge for a product manager are different from a developer, tester, or other professions. You are the one who presents new features to internal and external stakeholders — sales and CS teams, business teams, customers, upper management, etc. are waiting for the updates, upcoming feature definitions, deadlines, roadmap summaries, and more!
When our product has a random bug or slowness problem, I work with our team to figure out the root causes and we solve them together. But once it comes to explaining the issue to customers, I have a hard time trying not to use any technical terms. Explaining a software problem to someone with a completely different background is really hard, you know.
As a PM, you need to be aware of the curse of knowledge and explain everything according to the people’s background. If you don’t have a clue what I am talking about, let me share some examples that I am sure you have experienced:
You delivered a shiny technical improvement that has no UI dependency to customers — and it is the most important issue you delivered in months! There are a bunch of technical terms you need to use to be able to explain it but your customers have no background in software development. You start to struggle with writing and talking about it. You simply don’t want to explain it.
Some people may choose to skip those features while explaining and just focus on the things the customer can see. As a result, customers think that you are developing different things than what they requested or that you are sharing exaggerated development efforts.
Other people may try to explain in their own words and, once they realize they’re confusing people even more, mention the technical terms followed by “This is technical so you may not understand this part.” Honestly, this is the worst thing you can do to a customer or business team. After such a meeting, you will lose their precious questions and feedback, and they will become more hesitant to ask questions. The synergy between you will be damaged.
In a business or technology update meeting, you may have experienced attendees who are not listening to what you are saying. If they know they don’t understand what you are explaining, they will find it unnecessary and even tune it out. And, since you have the curse of knowledge, you will assume that they understand what’s going on. Later on, you will realize that there are wide knowledge gaps because of this lack of communication.
The communication problem may occur in any event, not just in a meeting. You could experience this in the lunchroom, at company events, and really anywhere. But the friendship and synergy between you and other stakeholders keep you and the development team up to date. You need to be the person who communicates for your product and the team. Losing your communication skills means you will lose the ability to make your product better.
This curse of knowledge does not only affect others — you need to improve yourself for your inner peace too! Sometimes you may feel like you were wrong about a decision you made a long time ago.
Some people like to say “I knew it would fail all along!” after everything is finished. This kind of curse is actually the opposite of that — it creates a hard time for you in understanding your past behaviors. Your lack of knowledge at the time made you decide wrongly, even if you supported the idea strongly at that time.
You can call this curse the “knew-it-all along effect” or the hindsight bias.
After a certain level of expertise, people lose their ability to predict others’ behaviors. This effect of the curse of knowledge kills a product manager’s customer perspective. If it isn’t apparent, I saved the worst for last.
Imagine you are defining a new feature for a product you’ve been working on for a long time and have all the expertise on. If you have this curse of knowledge, you will develop the product according to your expectations — not to those who know nothing about its capabilities. The feature you create will most likely have the worst user experience for a new user. Some users may not understand it or not use it at all.
You will wait for others to use the information or knowledge they simply don’t have. This is a nightmare for a product manager — you don’t understand the customer and you don’t know their needs 😣
Knowing about the curse of knowledge is not enough; you should be aware of its impact on your day-to-day activities to overcome. You can reference the technique below if you are in a situation like this and use them to reduce the curse of knowledge:
The first step is staying aware of the curse of knowledge, as well as when and where it impacts your behaviors.
When you realize you are under the curse of knowledge effect, ask the people you are talking to if they have the same understanding you do. If their knowledge level is less than yours, you need to consider their way of understanding. You should be able to minimize the influence of the curse.
For example, in a customer meeting, I was explaining an incident’s causes with the terms “deployment pods,” “pipelines,” and “load balancers.” After a couple of minutes, one of them asked me a question that I already explained.
Just as I was about to re-explain what I told them earlier, I realized that the other people in the meeting were also waiting for the answer to this question. Then, I realized that I was explaining the problems to a group using software knowledge. I had been in meetings with the technology team for so long that it affected how I presented it afterward!
I just took a deep breath and remembered that my audience has changed. I was able to explain it again but with the right knowledge for this customer group to understand, not the technology team.
This is not just general awareness — you need to be able to communicate with every kind of background and level easily. As a product manager, you are the expert on customers, on product, on synergy, and on everything 😇
Especially on the customer side of things, you need to be intentional about your words to express what you mean. I always go through simple versions of technical explanations in my head before I have non-technical meetings.
You can list the specific knowledge you have and share it with others regularly. This will be a start for you, and with practice, you will be better every day.
Sharing everything you know will not get you (or the person listening to you) anywhere. Your knowledge is useful at just the right amount for the listener’s level. As a start, you can separate the audience’s backgrounds and share accordingly. Having this knowledge level in mind can save time in the meetings. You can briefly discuss the issues with those who have knowledge about it and explain in detail to others who don’t.
In one of my non-technical meetings, I shared more than the required information to explain something and confused some internal customers. After that meeting, they thought there was a huge mistake and asked about that feature repeatedly. They opened tickets about the feature as if there was a bug. It took me weeks to rectify this and help them understand that nothing significant happened, I just explained in an overly-technical way.
Yes, not explaining and being angry is bad, but over-explaining is bad too. We have to learn to share just the right amount of information.
Feedback is important for your personal growth in every aspect. You can share feedback and get feedback from everyone you work with. This will make you understand how you sound and how you look while you are working. Believe me, it will surprise you! Others are not seeing you exactly as you think they are.
A feedback loop will show if you overshare or undershare, as well as if you have the curse of knowledge. If your organization doesn’t have a feedback culture, taking constructive feedback as an adult may require practice. But believe me, you will get used to it!
There is nothing better than the feedback you get from your colleagues. You can see your personal growth point more easily than you can find by yourself.
One of my teammates said that they are cutting me off to ask questions sometimes because I talk too fast. And after that feedback, I tried to slow down while explaining something to customers and I realized that I got more questions than usual.
My teammates know me well and know they can interrupt my speech to ask something. But customers or other stakeholders may not feel comfortable doing that. With that feedback, I improved my communication with customers and maybe prevented more misunderstandings.
To be able to avoid miscommunications, you should assume the listener is unfamiliar with your expertise. It can be that both technical teams may not know non-technical terms, and non-technical teams may not know technical terms.
We always talk as if customer and business teams are the ones we should be focusing on. In a new project meeting, I was explaining the features we will develop to the team. They asked thousands of questions for simple things to the point where we couldn’t finalize the meeting or set aside more time to finish it. I couldn’t understand why they were interrupting me so much, even though they wanted to develop the project and I knew they weren’t doing it on purpose.
In the retro meeting, I asked for feedback and opinions about why we couldn’t finalize the requirements. After a couple of more questions, I saw that they did not know the business flow. They couldn’t imagine the flow as an end user.
Knowing the code side doesn’t mean you know the real flow. I created a UML diagram for all roles as an end user. The second meeting went very well and we all left happy. Now, I am adding the business side to almost all requests to avoid any misunderstandings.
We can prevent the curse of knowledge by assuming people have no idea about that flow. Before going deep down into an explanation, you may ask if they want to hear details.
As a product manager, you will face the curse of knowledge more than others because of your multi-disciplinary work style. If other options are not enough, you may use other techniques to avoid bias.
You can improve your decision-making by adding visuals like pro and con tables or UML diagrams to your presentations. You should be open to creating your own method though, because none of those may be relevant to your unique case.
I strongly suggest you try the feedback loop if you take nothing else from this article. If it is not a solution to your curse of knowledge, it will solve at least one of the other problems.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
At its core, product lifecycle management (PLM) software is a tool designed to manage every aspect of a product’s lifecycle.
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Learn more →
