Why your business systems keep letting you down

If someone clearly owns a business system once it goes live (and that someone is you), you’re a lot less likely to end up with a Frankenstein pricing app, a brittle CRM, or a Jira instance everyone hates.

The home-rolled pricing app, the under-used HubSpot features, and the over-configured Jira instance are examples of what happens when no one treats a business system as an asset.

Business systems are living assets. Treat them like it.

Earlier versions of InsideProduct talked a lot about internal products. Experience has taught me that almost nobody thinks of their organization’s software that way.

They talk about CRMs that don’t work, HubSpot setups nobody uses, Jira instances that make everything harder.

So I changed InsideProduct’s focus. Instead of teaching internal product management in theory, it now treats those tools and workflows as business systems that need an owner, not just a project plan.

Most businesses implement a new business system using a project. They spin up a temporary team, burn through the project budget, and then disband the people who knew how it worked.

On the surface, that makes sense. Especially with SaaS or COTS applications, most of the work is getting them configured to run in your environment and hooked up to your other systems. Once that work is done, you probably don’t need that entire team of people running it ongoing.

You’ll get no argument from me there.

The problem comes once you’ve implemented the tool and you’re ready to head out to the local watering hole to celebrate another death march that’s come to a successful conclusion.

Or rather, it comes the next day or next week when people use the business system and find it doesn’t seem to quite work how they expected it would. If it works at all.

You built the plan, cut over to the new tool, and assumed the system would quietly do its job in the background. Unfortunately, you’ll never know everything you need to know when you lay out the initial implementation plan, and you’ll learn a lot more as people use the business system in real situations.

Since you didn’t plan for what to do with the business system once it’s launched, everything you discover afterwards either gets lost in a list or never captured at all.

People find problems, invent workarounds, and move on. The system gets a little more brittle each month and people stop using the system altogether, defeating the purpose of implementing it.

Without someone explicitly responsible for how the system and the real process stay in sync, every workaround and undocumented change quietly becomes the new normal.

What happens when you don’t treat a system as an asset

Let’s look at each of the three scenarios I mentioned before

The system rebuild

Too many teams building custom-built systems focus all their energy on getting the system built and forget to plan for life after the launch.

I was on a team of consultants asked to rebuild a 20-year-old app that set the prices for corn, soybean, and wheat that an agribusiness company would buy from farmers and sell in their bags of seed. In case you ever wondered how seed companies ever got the seeds they sold, now you know.

This app priced a billion dollars worth of seeds a year, yet only three people directly interacted with it. There were two people who used the app daily, and the guy in charge of maintaining it who worked in IT.

There was no one responsible for making decisions about the ongoing use of the app. So, decisions either didn’t get made, or the IT guy made them based on what he thought was best (maybe for him, maybe for the two users).

As you might expect, the app grew haphazardly, with new features bolted onto existing ones to address quirks in how the system or those it connected with worked.

By the time we came on the scene, it was a Frankenstein’s monster of an app that only the IT guy could maintain because he knew where the bodies were buried. And he wasn’t always able to figure everything out.

The org figured out that the only correct way to fix the app was to rebuild it. And it was only then that the organization identified an owner. But not because they realized the importance of having someone in a decision-making role in relation to the app, but because that’s what “Scrum said to do.”

This is a classic example of a custom-built piece of software that fulfilled an important business function but wasn’t treated like the business asset it was.

Rarely or never-used features

Compared to building a custom app, hooking up a SaaS app seems like child’s play. All you have to do is slap down a credit card, click a few boxes, and give people access. There’s thought that goes into those button clicks that determines whether people will use your app.

I recently worked with a consulting firm switching its CRM to HubSpot. They had been using a different CRM that was way over-featured for what they really needed, so the move to HubSpot was a chance to right-size their sales workflow.

While we trained the sales team on how to use leads and deals, we did the training a few weeks before we fully turned on HubSpot, so they didn’t have time to use the new lead functionality right away while the information was fresh.

Probably more impactful, the office manager took over ownership of the CRM when the system admin left. Unfortunately, the office manager didn’t have a full grasp of the current sales process and didn’t revise it to account for the availability of the lead functionality in HubSpot.

The result is that the sales teams just didn’t use leads and instead stumbled along trying to guess how they should manage their pipelines in HubSpot based on what they remembered from the previous CRM.

This goes back to a lack of strong decision-making that considered the process the business system enabled. Had there been a clearly defined owner who understood how the business system and the business process should interact, chances are adoption would’ve been considerably higher.

Over-configured and not usable

People like to blame Jira for being unusable. Truth be told, it’s not Jira itself that’s unusable; it’s all the people who over configure their instances that make it unusable.

I worked with a team revising an online booking tool for a travel company. The company had a process and tools team responsible for setting software development practices. Unfortunately, the people on the process and tools teams had little experience actually building the software at the company, so they didn’t have a good understanding of the difficulties the teams faced.

Instead, these teams took an approach that applied onerous process controls and overly relied on inspection to bring quality into the work. They saw all the controls Jira lets you put on software development processes and reasoned that if some controls were good, even more controls would be better.

Unfortunately, they enacted so many controls that teams actually spent more time wading through the process than they did making their software more usable.

If there ever was a case where just because you can do something doesn’t mean you should, it’s here. You needed a system owner for Jira who understood the software development processes the teams used and could find the right balance of control and enablement.

You probably didn’t set out to become the person who owns the system. You ended up with it because you know the process and people trust you to keep things moving.

The system owner’s real job

When you treat a business system as an ongoing asset instead of a project deliverable, you also need someone who owns that asset. In most organizations, that person is called a system owner or, in Scrum-influenced places, a product owner. The role name matters less than the responsibility.

That responsibility is not what they teach in a CSPO class. You’re accountable for how the system supports the business process day to day, not just whether the implementation project shipped on time.

You have skin in the game. You live inside the process the system enables, so you feel it immediately when the tool gets in the way.

Your job is not just to listen to complaints or collect feature requests; it’s watching how the system performs, capturing what you’re learning, and deciding which changes are worth making. That judgment picks up where the implementation team left off and keeps your list of requests from turning into a parking lot for every random idea anyone has ever had about the system.

You may think, “We already have a product owner.” If that person doesn’t own the process, can’t say no, and doesn’t use a filter like this, you have a product owner in name only.

Instead of waiting until there’s “enough” work to justify a new project, use the system change filter to triage each request as it comes in. When that filter is clear, you can act on small, high‑leverage changes without spinning up a full project.

And you can say “no” to changes that only make the system more brittle.

The system change filter

Here’s a simple filter you can start using this week.

1. Do we understand the problem we’re trying to fix with this change?

2. Is this problem about how people use the system, or about how the system is configured?

3. Is there already a workaround that people rely on today — and is that workaround actually the real process now?

4. If we make this change, what existing data, reports, or workflows could break or become inconsistent?

5. Can we address this problem with clearer guidance or training first, and only change the system once we see how people actually work?

These questions pull you out of a someone asked for it, so we should probably do it mode and into an is this worth changing the system for mode. They force you to name the problem and look for the simplest fix that helps before you say ‘yes’ to a change that might make the system more fragile.

Your first step to ownership

The next time someone sends you a change request, don’t immediately add it to your backlog and figure out when you can fit it in.

Instead, start by asking yourself these five questions.

If you can’t describe the problem you’re trying to fix, or you discover that the real issue is how people use the system, you’ve just saved yourself from spending time and money on the wrong fix.

Over time, that habit turns you from a request jockey into a decision maker.

You don’t have to wait until you can justify a project; you can make smaller, better decisions as you learn more about how the system shows up in real work.

That’s how you keep the tool from becoming brittle, keep workarounds from quietly taking over, and keep the system from owning you.

Share your system story

Reply and tell me about a situation where this system change filter would have come in handy, or where you wish you’d used it before saying “yes” to a change. The more examples you share, the better tools we can build together for people who suddenly own systems without a playbook.