Every software company has a favorite customer in its head, and it is almost always the power user. The person who learned every shortcut, built the elaborate setup, and bends the tool to their will. They write the glowing reviews, they fill the feature requests, they are loud in exactly the channels product teams listen to. So we build for them. We add the advanced option, the keyboard command, the configurability they asked for, and we feel good about it because the feedback is so positive. The trouble is that the power user is not your team. The power user is one person, and a team runs at the speed of its median member, not its fastest one.
That gap is where a lot of productivity quietly leaks. A tool optimized for the few is a tool that asks everyone else to climb. Every shortcut that replaces a visible button is a thing a new person has to be taught. Every layer of configuration is a decision someone has to make before they can do their job. The power user experiences all of this as flexibility. The other fourteen people on the team experience it as friction, and friction at the median is what actually sets how fast work moves.
A team is paced by its median, not its star
Think about what determines throughput on a real team. It is not how fast your best operator can fly through the interface. It is whether the new hire can find the project, whether the person who only opens the tool twice a week can remember how it works, whether the handoff from one teammate to another survives the fact that they have different habits. The work moves at the pace of the slowest necessary step, and on most teams that step is someone who is perfectly competent at their job and merely ordinary at your software.
When you design for the power user, you optimize the part of the distribution that was already fast and ignore the part that sets the limit. It is like tuning a car's top speed when the real constraint is how long it takes everyone to find the keys. The honest measure of a work platform is not what its expert can do on a good day. It is what the median user does on an ordinary one, without thinking, without asking, without a refresher.
Example: we once shipped a power feature that let people build custom views with a small query language. Our advanced users adored it. When we looked at the data, under five percent of users ever created one, and teams where someone had built a clever view actually onboarded new members more slowly, because now the newcomer had to learn one person's private system before they could contribute. The feature looked like productivity and functioned as a tax on everyone who had not built it.
Adoption is the real productivity metric
Usability and adoption are the same conversation, and they are the conversation that actually predicts whether a tool makes a team more productive. A capability that only the power user reaches is not a capability the team has. It is a capability one person has, and the moment that person is on vacation or leaves, it evaporates. Real team productivity comes from things the whole team can do reliably, not from the ceiling one expert can touch.
This reframes how I evaluate features. The question is not can a determined user accomplish this. A determined user can accomplish almost anything. The question is what the tenth user does, the one who is busy and uninterested in mastering software and just wants to get on with their actual work. If the feature only pays off after a learning curve, it is a feature for the few. If it helps the median person on contact, it raises the whole team. Productivity tools earn their keep at the median or they do not really earn it at all.
Designing for the many without boring the few
None of this means stripping power out of the product. The false choice people hear is simple tool or capable tool, and the best software refuses it. The principle we hold to is progressive disclosure: the common path is obvious and requires nothing, and the depth is there for the person who goes looking. The power lives under the surface, not on top of it, so it never stands between an ordinary user and an ordinary task.
In practice that looks like sensible defaults that make the empty state useful before anyone configures anything, primary actions that are visible rather than memorized, and advanced options that reveal themselves in context instead of crowding the first screen. When we build features for Atlas, the test a feature has to pass is not whether our most enthusiastic customer will love it. It is whether the median person on a team can use it correctly the first time they see it, with the depth waiting quietly for whoever wants it. Get that right and the power user is still happy, because the ceiling is high. The difference is that everyone else can reach the floor.
So be skeptical the next time a tool is praised for how powerful it is in expert hands, and ask the question that actually matters: how does it feel to the person who is not an expert and never will be. That person is most of your team, and your team's real speed is theirs. Designing for the power user feels like investing in excellence. More often it is quietly slowing the many to flatter the few.