You didn't sign up to own the CRM

Maybe your boss picked you to own the CRM.

Maybe the person who used to administer the CRM left (or was laid off).

Maybe you complained too loudly and too often about how broken the CRM was.

However it happened, you now have a new responsibility, and you’re not sure how to fulfill it.

Now you’re the person everyone asks about the CRM. The vendor emails you about quarterly updates and new features. IT routes CRM change requests to you. The sales manager drops by your desk every time a report looks wrong (although usually their numbers just aren’t as good as they thought they were).

You have all the CRM responsibility without a job description, budget, or training.

Welcome to the accidental system owner’s club. Membership is involuntary, and it’s larger than you’d think.

You know the business. That’s not the problem.

You’re probably well-suited for the role, even if it doesn’t feel that way right now.

You know how the business actually works. You know why the sales team ignores the CRM fields that looked great on paper. You know which workarounds exist, who invented them, and why. You know the difference between what the process is supposed to be and what people actually do at 4:30 on a Friday (if they’re not already at happy hour).

That knowledge is the hardest part of owning a business system, and you already have it.

You lack a framework for what to do with that knowledge.

You’re not sure how to manage requests without drowning in them. You need a way to decide what to change and when. You’d like a way to connect the system to what the users in your company actually need, rather than just keeping the lights on.

Nobody handed you that framework when they handed you the system.

How you got here: Three Ownership Traps

People accidentally become owners of a system for a variety of reasons. Here are three patterns common to growing businesses. Do any of these sound familiar?

Trap 1: Everyone owns it, so no one does

IT owns the tools. Business units own the requirements. The vendor owns the roadmap. But no one owns whether the system actually helps people do their jobs, produces the right outputs, or supports the business goals it was supposedly bought to serve.

You know, whether the system actually works.

When ownership is so distributed, accountability evaporates. People make changes without coordinating with anyone. Users catch bugs that nobody resolves. And the person closest to the system (ahem, you) absorbs all the confusion while holding none of the authority to fix it.

Trap 2: Split ownership across events

A subject matter expert owns decisions during meetings. A project manager owns delivery during projects. And in the long stretches when there’s no meeting and no project, no one owns anything.

Systems don’t just need owners during implementation. They need an owner all the time. Someone who tracks whether the system delivers on its purpose, fields the incoming requests that never stop arriving, and maintains the context needed to make effective decisions quickly.

Split ownership means that person doesn’t exist.

Trap 3: The permanent part-timer

Someone with a full-time job somehow gets named the product owner for the CRM. They attend the meetings when they can. They approve changes when they have a moment. But they never have real-time to talk to the people using the system, work with the team changing it, or track whether anything is actually getting better.

As a result, decisions stall. Context gets lost between handoffs. The team working on the CRM makes decisions that aren’t theirs to make to keep progress moving. The person holding the part-time title wonders why nothing ever feels resolved.

There’s a version of this trap that goes one level deeper: the person holding the title never builds real working knowledge of the system because they were never given the time to develop it. When the consultants leave, there’s no internal capability to fall back on, and decisions that should take an hour take a week. It’s a problem worth unpacking on its own, and I’ll do that in the next issue.

The one exercise worth doing this week

Do this before you redesign processes, clean up data, or research new tools.

For each of your key systems (CRM, ERP, ticketing system, whatever sits at the center of your operations), write down answers to these two questions:

1. Who actually decides what gets changed?

2. Who is accountable when it doesn’t work?

Not who is listed on the org chart. Not who the vendor thinks they’re talking to.

Who actually makes the call when a request comes in? Who’s involved in the hard conversation when the system causes problems?

If you hesitate before answering, or if the honest answer is “it depends” or “kind of me, kind of IT, kind of the vendor”, that hesitation is a telltale sign that ownership isn’t clear. And unclear ownership is the root cause of most of the firefighting that takes up your day.

You don’t have to solve it all at once. But identifying the lack of ownership is the first step.

What running a system looks like

Real ownership isn’t complicated. But it requires two things that the traps above consistently prevent.

Talk to the people who use the system

Not just escalations. Not just complaints that make it to your desk. Regular, intentional conversations about how work is actually getting done, what’s causing friction, what people have learned to route around.

The system exists to support work. You can’t know whether it’s doing that job without staying connected to the people doing the work.

An operations manager overseeing a CRM migration noticed almost no leads were showing up in the new system.

It wasn’t until she sat down with the sales team that she discovered they weren’t using leads at all because they didn’t understand how leads related to deals in the new system. Nobody explained the connection between leads and deals in their new CRM, so they’d quietly routed around it and started creating deals directly, skipping the lead stage entirely.

The system was technically working. The process had silently broken. She only found out by asking.

Work with the people changing the system

Whoever configures, maintains, or implements changes to your tools — whether that’s IT, a RevOps team, or a consultant — needs a real counterpart who understands your business. Someone who can translate business needs into a clear direction, and translate what’s technically possible into what actually matters.

Real ownership means sitting between those two groups, not as a message-passer, but as the person who holds the purpose of the system in view. You own the outcomes the system should deliver. You own the decisions about what gets changed, when, and why. You own the filter between someone wants this and we should do that.

An operations manager became the de facto CRM owner after the person who used to administer the CRM left. IT could configure anything she asked for. The problem was she didn’t know what to ask for. She’d describe a symptom such as the pipeline report is wrong and IT would fix the field they thought she meant. Nothing actually improved. When she started coming to those conversations with a written description of the desired outcome and examples of what was broken the fixes started working. IT stopped guessing and she stopped re-opening the same tickets.

None of that requires a formal product management background. It requires clarity about what the system is for, and enough time to actually do the job.

A lightweight CRM operating model

Those two habits are the foundation. But habits need structure to survive a busy week. That’s where a lightweight CRM operating model comes in handy. The CRM operating model is a simple set of routines that let you run the system rather than just react to it.

That CRM operating model has a few core components:

A way to handle requests

When people find out you’re the system owner, you’ll get a constant stream of requests such as “Can we add this field,” “Can you fix this report,” or “Why doesn’t it do this thing?” Without a filter, you’ll triage forever. A simple request intake process lets you capture requests, evaluate them against business priorities, and respond with something more useful than “I’ll look into it.”

A way to decide what to change

Not every request deserves work. You’ll want a set of questions you can use to evaluate each request.

The first question you should ask is a decision filter to make sure the request is aligned with your key outcome. This single question in the form Will this help us achieve [desired outcome] allows you to focus on those requests that drive the business forward, not just satisfy someone’s personal interest.

For those requests that make it through your initial decision filter, ask these follow-up questions:

• Does this make the system work better for the people using it, or does it make it more complicated?

• What does fixing this actually enable?

• Is there a compelling business need that drives having this done by a certain date?

• How much are we willing to spend on this solution?

An established set of questions helps you filter requests consistently instead of deciding case-by-case under pressure.

A way to track whether things are working

Building and deploying a solution is a necessary but insufficient first step. You also need to make sure the system continues to deliver the outcomes it’s supposed to.

That might mean adoption metrics, data quality checks, or simply regular conversations with the team about what’s getting easier and what isn’t.

None of these needs to be elaborate, but they need to be consistent.

You’re not doing it wrong. You just need the right tools.

If you’ve made it this far feeling a low-grade sense of recognition, that’s by design. The accidental system owner isn’t a failure state. It’s a common position that gets little support.

Everything above applies to your CRM today. It also applies to your ERP, your ticketing system, and whatever else sits at the center of how your business operates. The pattern is the same: a system that matters, ownership that’s unclear, and a person in the middle trying to make it work without a real framework.

Most of what’s written about systems, tools, and technology implementation is written for CIOs, IT directors, or software engineers. It assumes formal training, dedicated time, and organizational authority that most system owners at growing businesses don’t have.

What you need is something much more practical. You need a way to structure your thinking about what the system is for.

A way to handle the requests.

A way to make the changes that matter and push back on the ones that don’t.

A way to connect the system to the business outcomes your company is actually trying to hit.

That’s what I’m building at InsideProduct.

Frameworks, tools, and plain-language guides for the people who own systems inside growing businesses. Not product management theory. Not enterprise architecture. Not agile process theater. Practical help for someone who was handed a system and now needs to run it.

If that’s you, you’re in the right place.

Want a structured way to start? The Systems Discovery Starter Kit walks you through how to assess what your systems are actually doing, surface the real problems, and build a plan that’s grounded in how the business works, not just what the software can do.