Every product team has a version of the same user in mind when they make design decisions.
This user responds to surveys. They show up in user interviews. They file detailed bug reports. They have strong opinions about keyboard shortcuts and export formats and the precise behavior of the filter panel. They've been using the product for two years and they know it well enough to navigate it with their eyes half closed. When a new feature ships, they find it within an hour and send a detailed message about what it should do differently.
This user is invaluable. They're also, statistically, a tiny fraction of the people using the product.
The problem is that design processes are structured in ways that give this user a disproportionate amount of influence over the product's direction. They respond to research requests. They attend beta programs. They have direct lines to product managers and founders. Their feedback is specific, detailed, and immediately actionable in ways that feedback from quieter users is not.
The result, accumulated over a series of product cycles, is a product that is excellent for its most engaged users and increasingly opaque to everyone else. Not because anyone made a bad decision. Because the design process was systematically biased toward the people who were loudest in it, and nobody noticed until the conversion data started to show that new users were dropping off faster than anyone expected.
Who the Power User Actually Is
The power user in a SaaS product is typically characterized by a combination of tenure, engagement, and domain expertise. They've been using the product long enough to have built a mental model of how it works. They use it frequently enough that efficiency features — keyboard shortcuts, bulk actions, saved views — genuinely matter to their daily experience. And they often have enough domain expertise in the product's category that they can articulate what they want in technical terms that map directly onto product decisions.
This combination of characteristics makes power users extremely useful sources of product feedback. They understand the product deeply enough to have meaningful opinions about it. They're engaged enough to express those opinions. And they're often operating in the same space as the product team — technically literate, articulate, and aligned on what "good" looks like.
These same characteristics also make their feedback systematically unrepresentative of the majority of users.
A user who has spent two years with the product no longer experiences the onboarding problem. They've already solved it — either by figuring the product out themselves, or by getting help, or by adapting their workflow to the product's constraints. Their feedback is about optimization within the current model, not about whether the current model makes sense to someone encountering it for the first time.
A user who relies on keyboard shortcuts has already learned them. Their request to add more keyboard shortcuts is meaningful for users at their level of engagement. For a new user who hasn't learned the existing ones yet, it's irrelevant — and a product that's been optimized for keyboard navigation at the expense of discoverability is one where the power user gains efficiency while the new user can't find the basic functions.
A user with deep domain expertise is evaluating the product against a sophisticated mental model of the problem it's solving. Their requests for more advanced functionality are genuine needs. A user without that expertise is evaluating the product against a much simpler question: can I do the thing I came to do without being confused? These users are not in conflict. They want different things from the same product, and optimizing for one without awareness of the other produces a product that serves both worse.
How the Bias Accumulates
No individual design decision looks like a capitulation to power users. The accumulation is the problem.
A feature gets added because the most vocal users have been requesting it. The feature is genuinely useful — the power users are right that it would improve their workflow. But the feature requires an additional entry in the navigation, which adds to the cognitive load of a new user trying to understand what the product does. The addition is justified. The new user's experience is slightly worse. Nobody files a ticket for "the product got harder to understand."
A complex filter panel gets expanded to support more filter conditions, because the users who were interviewed in the last research sprint all had use cases that required them. The expanded filter panel is more capable. It's also more intimidating to a user who just wants to do a simple search. The capability gain is visible in the product. The comprehension loss is visible only in new user activation data, which is reviewed quarterly and has many contributing factors.
The default view of a dashboard gets updated based on what power users said they wanted to see first. The new default is more information-dense and more useful to someone who knows what all the metrics mean. It's also more overwhelming to someone who has just signed up and is trying to understand what the product is showing them. The power users are satisfied. The new users are confused. The power users file responses to the feedback survey. The new users close the tab.
None of these are design errors. Each is a reasonable response to legitimate feedback from real users. The error is not in any individual decision — it's in the absence of a counterweight. The design process has a feedback mechanism for the power user and a weak or absent feedback mechanism for the new user, and over time the product drifts toward the people who are represented in the process.
The Metrics That Hide This Problem
The metrics that most SaaS products track closely tend to obscure the power user bias rather than reveal it.
Monthly active users and daily active users are dominated by existing users — because existing users are, by definition, a larger cohort than new users in any given period. When these metrics are healthy, it's partly because the power users are highly active. Their activity masks the dropout of new users who never became active at all.
Feature usage metrics tell you which features are used most by the users who stayed. They don't tell you which features were confusing to the users who left. A feature with high usage among existing users might be actively deterring new users — because it's prominently placed in the UI and creates confusion before a new user understands what it does — but this won't appear in feature usage data.
NPS scores from existing users are scores from survivors. The users who found the product confusing have already left. They don't complete the NPS survey because they're not users anymore. The NPS score reflects the satisfaction of people who figured out the product, not the people who couldn't.
The metric that most directly reveals the power user bias is new user activation rate — the percentage of new users who reach a defined moment of value within their first session or first week. This metric is not dominated by existing users. It measures only new users and their early experience. It's also the metric that most directly reflects the cost of a product that's been optimized for experts at the expense of newcomers.
The Newcomer's Experience as a Design Object
One of the most productive reframes for thinking about power user bias is to treat the newcomer's experience as a distinct design object — something that requires as much explicit attention as any feature or workflow in the product.
The newcomer's experience is not the onboarding flow. The onboarding flow is the designed introduction to the product — the welcome screens, the setup wizard, the empty state prompts. The newcomer's experience is everything that happens from the moment they log in until the moment they understand what the product does and how to make it do something useful for them. This includes the onboarding flow, but it also includes every piece of navigation, every label, every error message, every empty state, and every interaction model the new user encounters before they've built a mental model of how the product works.
Designing this experience well requires a different kind of research than the user interviews and beta programs that surface power user feedback. It requires watching users who are genuinely new — who have never seen the product before, who have no context about how it thinks, who are encountering it with the same combination of curiosity and impatience that any real new user arrives with.
Moderated usability sessions with new users, conducted not to test specific features but to observe the overall comprehension experience, consistently surface problems that internal teams and power users have become blind to. The step that everyone on the team finds obvious turns out to be confusing to the majority of new users. The feature that power users love turns out to be intimidating to someone who doesn't know what it does yet. The terminology that makes perfect sense to someone with domain expertise turns out to be opaque to someone who's new to the problem space.
These sessions are inexpensive relative to the cost of the insight they produce. They are also, in most product organizations, conducted less frequently than interviews with existing users — because existing users are easier to recruit, more articulate about their needs, and more satisfying to talk to.
The Progressive Disclosure Answer
The most durable design response to the tension between power user needs and new user needs is progressive disclosure — the principle that information and functionality should be revealed in proportion to the user's demonstrated engagement and expertise, rather than all at once.
A product that shows everything to everyone at all times is simultaneously overwhelming for new users and efficient for power users. A product that shows the most important things first and reveals additional complexity as users demonstrate readiness for it can serve both groups well.
In practice, this means designing the product in layers. The first layer contains everything a new user needs to accomplish their core task without being overwhelmed by the full scope of the product. The second layer contains the features and options that become relevant once the core task is understood. The third layer contains the power user functionality — the advanced filters, the bulk actions, the API integrations — that expert users need and new users don't.
These layers don't need to be separated by explicit onboarding steps or tutorial flows. They can be expressed through visual hierarchy — the most important things most prominent, secondary things accessible but not intrusive, advanced things available to those who look without appearing to those who don't. They can be expressed through defaults — sensible starting points that work for most users without requiring configuration, with more control available for users who need it. They can be expressed through progressive unlocking — certain capabilities revealed as users demonstrate they're ready for them, rather than presented upfront.
The layer design requires explicit decisions that most product teams don't make explicitly: what is the core task, what needs to be visible immediately to enable it, and what can be safely deferred without penalizing the new user? Making these decisions requires the same kind of deliberate attention that any design decision requires. It also requires a commitment to regularly revisiting them — because as the product grows, the default tendency is to expand the first layer rather than manage the layers deliberately.
A Practical Check
Before shipping a design decision that was driven primarily by power user feedback, one question is worth asking: what does this look like to someone who has never used the product before?
Not "is this good for new users" — that's too broad to be useful. Specifically: does this change make any part of the product harder to understand for a newcomer? Does it add a concept they'll need to learn before they can use this feature? Does it change something they might have just learned, creating a re-learning cost? Does it add visual complexity to a surface they're still trying to orient themselves in?
These questions don't require full usability testing to answer — although testing will answer them more reliably. They require a specific act of imagination: setting aside the product knowledge that makes the change seem obvious, and asking whether it holds up without that knowledge.
Most design teams are not good at this imagination exercise, because expertise is hard to unknow. The power user bias is partly a knowledge problem — the design team, like the power users, knows too much about the product to reliably predict how a newcomer will experience it. The structural solution is to build the newcomer's perspective into the design process formally — through regular sessions with new users, through activation metrics reviewed with the same rigor as engagement metrics, through an explicit brief for any design decision that includes the question of how it affects comprehension for someone who's never seen it before.
The power user is your best advocate. They're not your average customer. Designing for both requires knowing the difference — and building a process that represents each of them accurately.