We thought we were doing it right.
After years of frustration with an outdated, rigid Enterprise Asset Management (EAM) system that burdened our power plant teams, we finally replaced it. This wasn’t a top-down IT rollout — we put the power in the hands of the users. They helped define the requirements, scored the options, tested real environments, and chose the solution. We implemented it, right in the middle of COVID.
It felt like an incredible accomplishment.
And then our users betrayed us.
Three weeks after the new EAM went live, I received an email from our COO. Attached was a PowerPoint from one of our users — we’ll call him Shane — who’d taken the opportunity to voice concerns directly to leadership.
- Slide one: “We had an EAM system that worked.”
- Slide two: “This new EAM doesn’t work.”
- Slide three: “There are over 500 issues.”
Ouch.
At this point, we had a choice about how we defined this problem. Most IT teams reach for one of two classic explanations:
- The users are the problem. They’re never satisfied. They don’t adapt. They can’t make up their mind. They picked the system with us, and now they’re turning on us.
- The business leaders are the problem. Why aren’t they stepping in? Why aren’t they helping guide the users, reinforce expectations, and get things back on track?
Most IT organizations — mine included — have leaned on one or both problem definitions at some point. It’s the cycle IT gets stuck in — and it feeds itself endlessly. To break the cycle, we had to realize a hard truth. The problem wasn’t the users or the business.
The problem was us.
We had done the hard work of engaging users — right up until go-live. And then we stopped. We treated go-live as the finish line, not the starting line for a new kind of partnership.
That shift in mindset was enabled by an important new practice that we rapidly adopted during this period. We call it enterprise product management. It was an evolution of classic consumer technology product management, with some key differences.
Some elements of classic product management (CPM) are important to adopt. For example, in CPM, you don’t just measure success by schedule, budget, and scope. You measure:
- How fast users are getting new features
- How reliable those features are
- Whether users actually like using them
However, some elements don’t work well. Classic product management is consumer-driven, with distant users, small sets of features, and single purpose technology products. Those elements are very different in the enterprise — we had to create a grounded approach to product management appropriate for the nearness to users and complex capabilities contained in enterprise software.
To navigate the future of this EAM product, we would need to engage three groups through enterprise product management: Users, Business Leaders, and Tech Teams.
Users as radar
To help us navigate the immediate shoals ahead of us, our users became our radar. They are the most capable of telling us where friction exists and where features are or aren’t being adopted.
So we adapted that approach to our environment. We broke our system (EAM) into capabilities — like work order scheduling, preventive maintenance, etc. — and asked users to rate two things:
- The health of each capability (how well it supports their work)
- The priority (how important it is to improve it)
Then we mapped those results. High-priority, low-health items? Fix immediately. High-priority, high-health? Double down. The rest? Triage appropriately.
And we didn’t stop there. We formed user groups to interpret the data and guide where we invested development effort. Shane was invited to join one. His complaints turned into contributions.
Business leaders as navigators
That scoring model became our user radar. But we needed roadmaps too — so we started working with business leaders, helping them think of themselves as capability owners. They weren’t just consumers of IT. They were co-navigators.
We gave them simple tools: effort vs. impact matrices. Big bet? Go for it. Low value? Don’t bother. These conversations started happening more regularly, and we began building internal roadmaps that mirrored what vendors like PCI already do.
Technology teams as shipyards
Last but not least: our own tech teams. For this model to work, IT has to own products, not just run from project to project. We started forming small product-aligned teams around each major system, including EAM, with leaders focused on ongoing health, not just one-time delivery.
What changed — and what it meant
We started to see results. User scores rose. Capabilities got healthier. Shane sent an email months later that said:
“I realized we were all on the same team.”
That line hit me. It meant the work had paid off. Not just the fixes, but the trust-building behind the scenes. We were no longer two tribes. We were in it together.
At the end of the day, this whole transformation didn’t come from a tool or a vendor or a fancy process. It started with a mindset shift:
We are the problem.
That’s not a phrase people love to say. But once you do, you create space for real change. It takes two to make a pattern — but only one to change it.
That truth holds in any organization. In our case, we in IT decided to change the pattern. We owned the problem and changed how we worked. But if you’re on a business team and your IT partners aren’t meeting your needs, you can take the first step too. Own your capabilities. Start a real dialogue with IT about how products are impacting the health of those capabilities. Let IT know you need them — and that you’re here to help them invest where it matters.
Because once you stop pointing fingers and start listening, the pattern changes. And when the pattern changes, everything else can, too.
Want to learn more about how Associated Electric Cooperative is building better systems for their users? Visit Associated Electric Cooperative’s website to explore our mission, our people, and how we’re empowering progress every day.
This blog post was adapted from a keynote presentation delivered at INFOCUS 2025, PCI’s annual user conference.
