What you'll understand by the end of this lesson
- What the False Consensus Effect is and why it's so common on product teams
- How it leads to features built for the team rather than users
- Why copy written by specialists often misses the actual audience
- What user research practices counteract this bias
The principle in plain English
People tend to overestimate how much others share their own opinions, preferences, habits, and behaviours. Whatever feels normal to you, you unconsciously assume is normal to everyone — or at least to most people.
This is the False Consensus Effect. It's not arrogance — it's a genuine perceptual bias. We experience the world through our own perspective, and that perspective shapes what we assume to be "the default." When you use a tool every day, you forget what it felt like to not know how to use it. When you care deeply about a feature, you forget that most users might not notice it exists.
For product teams and CRO practitioners, this bias is particularly dangerous because the people making decisions about a product are usually very different from the people using it.
A simple example
A team builds a data analytics product. The team are data analysts themselves — they understand SQL, they're comfortable with complex filters, they use keyboard shortcuts. They build the product in a way that feels obvious and efficient to them.
They launch. Users struggle immediately. The features that feel simple to the team require background knowledge that most users don't have. The copy assumes terminology that the team uses fluently but users have never encountered.
The team assumed their users were like them. They weren't. The False Consensus Effect produced a product designed for a narrow persona that existed mainly in the team's own mirror.
How False Consensus shows up in product and CRO
Features built for the team's preferences
When a product team votes on what to build, they vote based on what they would want. This is a reasonable heuristic when the team is highly representative of the user base. It's a serious problem when they're not.
The False Consensus Effect means each person on the team assumes their preferences are more widely shared than they actually are. The result: features that the team would love get prioritised over features that would genuinely improve the product for the actual user base.
The antidote is user research that reveals the actual distribution of preferences — not assumed consensus.
Before a feature planning session, ask each team member to write down their assumptions about the user: what they care about, what confuses them, what they're trying to achieve. Then compare those assumptions to actual user research. The gaps reveal where the False Consensus Effect is distorting the roadmap.
Copy written for an expert audience
Copy is one of the places where False Consensus does the most damage quietly. A copywriter who is immersed in the product writes in the language of someone who already understands it. A specialist who knows the industry inside out writes as if the reader has the same background.
Jargon appears that feels like plain language to the writer. Explanations are skipped because "that's obvious." The level of assumed knowledge is set too high.
The False Consensus Effect makes this invisible to the writer — because to them, the language is simple, the concepts are clear, and the assumptions are reasonable. It's only visible when you watch someone who doesn't share your knowledge read the copy and struggle.
Usability testing interpreted through the team's lens
When teams conduct usability testing, the False Consensus Effect can contaminate interpretation. If a user struggles with something the team finds simple, the team's instinct may be to attribute the struggle to the user: "they're not our target user," "they weren't paying attention," "that was an unusual person."
This is False Consensus in reverse: the team assumes that users who behave differently from themselves are the outliers, not the norm. The more representative the testing, the more disconfirming this assumption should be.
"That's not our user" is a very common response to usability research that produces uncomfortable findings. Sometimes it's accurate. More often, it's the False Consensus Effect protecting the team from evidence that their assumptions were wrong. If three out of five test participants struggle with the same thing, the problem is not the participants.
The CRO audit
Look at your product decisions and copy and ask:
1. When did you last talk to a user who was unlike anyone on your team?
If your most recent user research involved people who share the technical background, professional context, or usage patterns of your team, the sample is self-selected in a way that will confirm rather than challenge your assumptions.
2. Read your landing page copy out loud to someone outside your industry.
Where do they stop? Where do they ask what something means? Where do their eyes glaze? Every one of those moments is a False Consensus failure — you assumed your reader knew something they didn't.
3. What user research backed your last three feature prioritisation decisions?
If the answer is "we discussed it as a team," those decisions were made on assumed consensus. That's not always wrong — but it should be a conscious choice, not a default.
A SaaS team of five engineers builds a developer tool. They ship the product. User interviews reveal that 70% of early users are non-technical marketers, not engineers. Users are struggling with the interface and copy. What bias is most likely at work?
You know how assuming others think like you distorts decisions. Now — what about the opposite force? Next: why people deliberately follow what's already popular, and how to use genuine popularity signals to lift conversion.