Practice

Today, let's dive into a real high -stakes business mystery. We're talking about a super promising B2B AI product, its most important customers just disappearing, and how one single designer managed to uncover the surprising truth behind it all in just 12 weeks. So, let's set the scene. The product is called Loyola AI, and

weeks. So, let's set the scene. The product is called Loyola AI, and its goal was incredibly ambitious. It was designed to be a plugin for Encompass, which is the dominant loan processing system in the U .S. The idea was to use a bunch of AI agents to automate all the tedious, repetitive, and frankly, error -prone

parts of processing a loan. For lenders, this was supposed to be a total game -changer. But there was a massive problem. During its most critical phase, the paid

-changer. But there was a massive problem. During its most critical phase, the paid pilot, Loyola AI was losing over 40 % of its mid -to -large -sized customers.

And look, these weren't just any users. These were the companies that were the key to their entire growth strategy. A churn rate that high isn't a leak, you know.

It's a flood. So, this became the million -dollar question for the whole team.

I mean, the product was powerful, the tech was solid, but something was just fundamentally broken. To save the company, they had to figure out why their most valuable customers

broken. To save the company, they had to figure out why their most valuable customers were just walking away. Okay, so where do you even start with a mystery this big? Well, the investigation kicked off with the very first clues. The initial feedback filtering

big? Well, the investigation kicked off with the very first clues. The initial feedback filtering in from the sales team and, you know, the assumptions that everyone was making. The

first signals all pointed in one direction. Frustration! Customers were complaining that the tool felt really rigid. Every time they needed to tweak a workflow for some special loan case,

really rigid. Every time they needed to tweak a workflow for some special loan case, they had to call support, and the wait times were just killing their efficiency. It

was the complete opposite of the flexible, automated future they were promised. And this led to a really crucial crossroads for the company. The founder, looking at what other workflow products were doing, wanted to jump straight into building a really complex node -based editor.

I mean, it seemed like the logical fix, right? But the team's designer pushed back, asking a really simple but powerful question. Are we sure we understand the real problem here? And this is where the mystery takes its first big twist. The team did

here? And this is where the mystery takes its first big twist. The team did an internal tech review and discovered something pretty shocking. The support team? They were actually incredibly fast, resolving most tickets almost instantly. And the requests weren't complicated. They were

simple things, like installing a tool or changing permissions. The problem wasn't slow support. It

was that users had absolutely zero control to make these simple changes themselves. So those

initial clues turned out to be a total dead end. To solve this thing, the team realized they had to stop guessing and go directly to the source, the users themselves. And what they found was completely counter -intuitive. Turns out users didn't want

themselves. And what they found was completely counter -intuitive. Turns out users didn't want a powerful, flexible workflow builder. In fact, a lot of them were kind of intimidated by them. They loved their old, clunky, but really familiar Encompass system. What they wanted

by them. They loved their old, clunky, but really familiar Encompass system. What they wanted were simple tools that made their current jobs easier, not a whole new platform they had to learn from scratch. The user research identified these three key people, whose frustrations were all connected. See, the loan processor gets blocked, so they ask their manager for

help. But then the manager is also blocked because they can't grant permissions or install

help. But then the manager is also blocked because they can't grant permissions or install tools themselves, so they have to go to Loyola support, which creates this one single bottleneck that brings everything to a grinding halt. And this, this is the breakthrough moment in the whole investigation. The entire complex problem was suddenly made crystal clear, and

it was all thanks to a simple analogy from a user. shared this brilliant analogy.

Needing Loyola's support for a simple permission change was like being at a self -checkout, scanning an item wrong, and the staff having to call the overall store manager just to avoid the item. It's such a tiny problem, but it creates this massive, unnecessary delay, and it leaves everyone feeling powerless and frustrated. And there it was. The real

problem was never about features or how flexible the AI was. It was about control.

The single biggest point of failure was the manager's inability to do simple admin tasks to unblock their own team. So with the real problem finally identified, the team's entire strategy shifted. They stopped thinking about building some giant, complex editor, and instead focused on one thing, giving users the right kind of control. And their strategy

was really smart. Instead of trying to solve everything at once, they split the idea of flexibility into two different scenarios. First, they'd focus on letting users operate the workflows they already have. The much more complex need, letting them build new ones, well that could come later. Their phased plan was just beautiful in its simplicity. Phase one

would directly attack the biggest pain point by enabling self -service for managers. That would

deliver the most impact with the least amount of development and fast. More advanced features could just follow in later phases. So the plan was set. The diagnosis was clear.

But did the cure actually work? Let's take a look at the results when they finally put this new, focused solution into their customers' hands. That first version, their MVP, wasn't a complex editor at all. It was a simple workflow page. Its only

job was to let managers manage permissions and turn pre -built workflows on or off for their team. It directly targeted that self -checkout bottleneck. The impact was immediate.

And it was staggering. With just this one simple page, 80 % of the customer requests that used to require contacting support were just gone. The bottleneck vanished. The frustration

vanished. And that 40 % churn rate? It stopped. You know, the story of Loyola AI really leaves us with a critical question to consider in any project. It's so

easy to get excited about building the most powerful, feature -rich solution out there. But

this case proves that true success comes from deeply understanding the user's real -world friction solution and building precisely what's needed to solve it.