Handling Low-Frequency, High-Value Users
The 80/20 rule tells us to prioritise the majority. But what happens when the 20% you're ignoring pays for the lights to stay on? Here's why your most important users might be the ones you barely see.
I have seen a B2B SaaS company lose a £2.3 million contract because their admin console couldn’t handle a quarterly audit workflow. The feature request had been sitting in the backlog for fourteen months. Tagged “low priority” because, you know, only 3% of users ever touched it.
Three percent. That’s the number that killed the deal.
The product team wasn’t wrong, exactly. They’d done their research. Built their personas. Followed the 80/20 rule like gospel. Focused relentlessly on the daily active workflows that 80% of users touched 80% of the time. Textbook prioritisation.
And yet.
The translation layer problem
Here’s what I keep seeing: teams treat the 80/20 rule as a sorting mechanism when it’s actually a visibility filter. It tells you what most people do most often. It says nothing about what matters when the stakes are highest.
The enterprise admin who logs in twice a quarter isn’t a low-value user. They’re a different category entirely. They’re the person who signs off on renewal. The one who gets asked “should we switch to Competitor X?” during budget reviews. The one whose frustration never shows up in your NPS survey because they’re not filling out your NPS survey.
I’ve started calling this the translation layer problem. Your product strategy says “serve high-value users.” Your execution framework says “prioritise by frequency and volume.” Somewhere between those two statements, the definition of “value” gets quietly swapped out. Strategy means business value. Execution means engagement metrics.
Nobody notices because both sound reasonable in isolation.
The strategy-execution gap isn’t about teams failing to execute. It’s about translation errors between what we mean at the top and what we measure at the bottom.
This is where things get uncomfortable. Because most product teams have built their entire prioritisation infrastructure around frequency. Usage analytics. Feature adoption rates. DAU/MAU ratios. All of which systematically undercount the people who matter most in enterprise sales, accessibility compliance, and platform governance.
The surgery analogy
Think about it like surgery. The anaesthetist doesn’t do much during most of the operation. They’re monitoring, adjusting, watching. For hours, they might look almost passive compared to the surgeon doing the visible work.
But if something goes wrong, suddenly they’re the most important person in the room. Their low-frequency interventions are the difference between a good outcome and a catastrophe.
Your enterprise admin is the anaesthetist. Your power user running quarterly compliance reports is the anaesthetist. The accessibility advocate who needs screen reader support is the anaesthetist.
You can’t evaluate their importance by how often they act. You have to evaluate it by what happens when they can’t.
Where I’ve seen this go wrong
Basecamp learned something interesting about this years ago. They found that the customers who complained loudest about missing features were often their most engaged, most loyal, longest-tenured accounts. The quiet ones just left. No feedback. No feature requests. Just gone.
Low-frequency feature usage can mask the same pattern. The admin who struggles through your terrible quarterly export workflow doesn’t file tickets anymore. They’ve just added “evaluate alternatives” to their Q3 objectives.
Shopify figured this out with their Partner Programme. The developers building on their platform might only use certain tools a few times per project. But those tools determined whether agencies recommended Shopify or moved clients elsewhere. Low frequency. Massive leverage.
Actually, that’s not quite right. It’s not just massive leverage. It’s asymmetric consequence. When a power user fails, you lose revenue. When a daily user gets slightly annoyed, you lose... some engagement metrics, maybe.
The prioritisation paradox
Here’s the tension I haven’t resolved: you genuinely can’t build for everyone. Resources are finite. The 80/20 rule exists because you have to make choices. Telling a team to “also prioritise the 20%” isn’t advice. It’s just adding requirements without adding capacity.
What I’ve seen work, sort of, is separating the prioritisation question into two tracks.
Track one: what do we build next for the core workflow? This is your normal backlog. High frequency wins. Standard prioritisation rules apply.
Track two: what would cause us to lose a deal, a renewal, or a regulatory certification? Different rubric entirely. You’re not measuring engagement. You’re measuring risk.
The companies that handle this well tend to have someone, often a solutions engineer or enterprise PM, who owns track two explicitly. Not as an afterthought. As a defined responsibility with dedicated capacity.
The problem with “edge cases” is that we named them wrong. They’re not edges of your product. They’re edges of your visibility.
Slack does something interesting here. They have internal advocates specifically for accessibility and enterprise compliance. Not just as a checkbox, but as a weight in the prioritisation process. Someone whose job is to say “yes, only 4% of users need this, but those users include our largest accounts and we’re legally required to support them.”
That’s not elegant. It’s a workaround for a prioritisation framework that wasn’t designed for asymmetric value.
What this reveals
I think we’ve built an entire generation of product practices around consumer metrics. Monthly active users. Feature adoption curves. Engagement funnels. All of which made perfect sense when we were building consumer apps where value scaled linearly with usage.
Enterprise and platform products don’t work that way. Value is lumpy. Concentrated. Often inverse to visibility.
The 80/20 rule isn’t wrong. But it’s answering a question most of us aren’t actually asking. “What do most users do?” is not the same question as “what would make us lose our best customers?”
I’m still not sure how to fix this without creating parallel prioritisation systems that eventually conflict with each other. Maybe that’s fine. Maybe the conflict is the feature. It forces the conversation about what “value” actually means.
But I keep watching teams optimise for the users they can see while the ones they can’t see quietly decide their fate.