The Dark Side of Data-Driven Product Management: When Your Users Are Too Used to Discomfort

A story of Good Metrics Hide Bad User Experience in Enterprise Software.

Your enterprise product is killing it. Usage up. NPS solid. Renewals flowing. Your software runs deep in your clients' processes. Yet one of your biggest clients needs a team of 50 people just to help others use your software. "That's normal for enterprise software," they say.

Something's wrong with this picture, no? This is the dark side of enterprise software - when users don't just adapt to pain, they build their careers around it. And your data won't show it, because they're measuring the success of their workarounds, not the cost of their normalized discomfort.

The Comfortable Prison of Status Quo

I had a chat with a former colleague who recently started working on workflow automation in the insurance industry. They told me the initial user research was frustrating: "Everything is fine." "This is just how we do things." "Yes, it takes time, but that's normal." "This is insurance - it's supposed to require high competence. It's not meant to be simple."

Their metrics showed high satisfaction rates. Their users were "happy." But they were happy in the way someone who's never had air conditioning thinks a hot room is normal.

And I was reminded of the user research I did for my Master’s thesis, on insurance claims automation. The feedback I got 3 years ago was very similar - things were fine (good even) according to the interviewees. Manual work was thought of as sufficient and the need for automation in their opinion was not too pressing.

Why Your Users Won't Tell You The Truth

Here's an uncomfortable reality of enterprise software: Sometimes entire teams exist just to manage the complexity of your product. And here's the twist - they don't want you to make things simpler.

Consider these typical scenarios:

• A dedicated "Claims Processing Support Unit" - a team of 10-15 people whose entire job is helping other employees navigate complex insurance workflows

• A "SharePoint Administration Team" - groups of 5-7 people whose existence depends on employees needing help with basic document management

• A "Procurement Support Unit" - 15 people whose entire job is helping other employees navigate basic procurement processes

These teams have built-in reasons to keep things complicated. Their headcount, their budgets, and their entire existence depend on your product staying complex. Think about it - would a documentation team of seven people truly welcome features that let employees manage their own workflows? It would mean cutting the headcount and layoffs are scary.

Key patterns that signal this dynamic:

• Teams that have built their entire identity around being "experts" in your system - "Only Maria from Claims Support knows how to handle these special cases"

• Resistance to automation features framed as "but we need human oversight for compliance"

• Feedback that consistently pushes for more complexity rather than simplification

• Strong pushback against features that would reduce the need for specialized knowledge - "You can't simplify this process, it requires specific expertise"

Why Traditional Product Metrics Sometimes Fail Innovation

Think about enterprise software users. They've spent years building their entire work processes around existing limitations. They've trained their teams on complicated workarounds. They've even created their KPIs based on current constraints. Of course they'll tell you everything is fine – they're most likely measuring the effectiveness of the current work-around solution instead of the value chain and all the numbers indicate success.

Look at Slack challenging email's dominance in enterprise communication. When Slack launched, companies insisted they needed formal email chains for 'proper business communication' and 'audit trails.' Users had built elaborate systems of folders, flags, and rules to manage their inboxes. But Slack saw through this normalized pain. They proved that enterprise communication could be both simpler and more effective. Now many of those same users can't imagine coordinating their work through email threads.

Signs your users are too used to pain:

• Your top clients have created entire roles just to manage workarounds with your product - and they see this as normal

• When you suggest a simpler way, you hear "but we need all these steps for compliance" - without anyone checking if that's still true

• New team members take 3-6 months to learn "the system" - and everyone thinks this is just how long onboarding takes

• Users have built elaborate spreadsheets to track their work in your system - and they're proud of these "solutions"

Seeing Through the Lies Your Data Tells You

The trick isn't to ignore data – it's to look for different signals. When I’ve worked with teams building B2B software and e-Gov systems, we’ve always eventually gotten to a point where we’ve stopped asking if users were satisfied. Instead, we sat with them. We counted clicks. We timed processes. We noted every time someone said "You get used to it" or "That's just how it works."

What I’ve learned to look for:

• The gap between what users say ("This process is fine") and what they do (copying data between three systems manually)

• The size of their training documents - the longer they are, the more pain they're hiding

• The number of Excel sheets needed to make your product "work properly"

• How often phrases like "once you learn it" or "after you get used to it" come up in user interviews

• Expert users might resist your speaking to less qualified users insisting that all feedback go through them first

Finding Real Pain Points & Opportunities

The most telling feedback comes from people adjacent to these teams - those who wait for them, raise tickets to them, and depend on their specialized knowledge. In insurance, it's often the sales teams or customer service representatives who reveal the truth about unnecessary complexity.

To find real insights:

• Build relationships with other departments impacted by complexity

• Find allies in senior management who see the bigger cost picture

• Connect with new joiners before they become invested

• Look for overwhelmed teams - they're more likely to embrace automation

• Focus on metrics that matter to the business, not admin teams

The key is observing real usage patterns. Shadowing users reveals what interviews can't. Screen recordings work too if you know the context.

Watch for these hidden opportunities:

• Multiple system logins without a clear reason

• "Special cases" that could be automated

• "Wizard" users who've just memorized workarounds

• Features used differently than designed

Your Real Job as a PM

Your job isn't to trust the data blindly. It's to see the pain others have normalised. To imagine the better future others can't see yet. To build the bridge between "how things are" and "how things could be."

Sometimes the strongest resistance to innovation comes from the people who know your product best. Your job isn't just to build better features - it's to help organisations see past their internal politics to the larger value of simplification.

Next time your metrics tell you everything is fine, but your gut says otherwise, remember: the biggest innovations often start when everyone else thinks nothing needs to change.

The most transformative products weren't built by following the data – they were built by seeing through it.