From the July 22nd, 2026, edition of How Teams Work
Most teams think about software implementation the same way.
You get the system set up, get everyone trained, and you go live. Done.
There's a moment where the system is live, the data is in place, and people are using it. What most people don't realize is that your software journey is just getting started.
Go-live feels like the finish line. It's actually the starting line. And what comes after it is where the real implementation work happens.
Most teams think about implementation as a project that happens once, gets handed off, and you move on. It's "done" when the team's trained and the tools are live.
To be fair, that's how most software is sold. Whatever platform you're rolling out, the vendor will tell you they can get you live in a matter of weeks. And you can be. But live isn't the same thing as fully implemented.
Being live means the system is configured, the team is trained, accounts are set up, and the out-of-the-box tools are ready to go. For many teams, that's enough to get started.
But implementation is a far more long-term and in-depth process. It's what sets your software up to reflect how your business actually operates, not just on day one, but every day after. When that work gets treated as finished at go-live, the gaps start to show up pretty quickly.
The platform isn't the problem. The mindset is.
We're live. Now what?
So what actually happens after go-live? Here's what has to keep happening, on an ongoing basis, for the system to stay useful:
You have to continually enable the team. Training on day one doesn't hold. People forget, people change roles, new people join who never sat through the original session. Enablement isn't an event; it's a habit you have to keep.
You have to check whether the tool is actually being used. Not whether it was rolled out. Whether people are actually working inside it the way it was designed. Adoption and access are two different things.
You have to get feedback from the team and act on it. The people using the system every day will tell you where it's breaking down, if you ask them and if you actually build a way for that feedback to turn into changes.
You have to release updates iteratively. You built a foundation and got everyone into it. Now it needs to evolve. Feedback turns into updates. The business changes, and the system has to change with it.
You have to expand. Once the foundation is solid, you can extend the system's reach: more tools, more use cases, more of the business running through it instead of around it.
Skip any one of these, and you haven't finished implementation. You've just paused it.
Where things start to break down
Here's the thing: this isn't a technology problem. It's a mindset problem.
Go-live gets treated as the finish line. There's no owner past that point, no plan for what changes next, no structured way for the people using it to say what's not working. So the system quietly drifts further from how the business actually runs, and nobody notices until something breaks.
Treating your software like a product means moving away from a one-off IT project and toward a continuous, value-generating system. That means building a roadmap, establishing real feedback loops with the people using it, and assigning dedicated ownership, so the platform scales with the business instead of just sitting there as it was on day one.
The product mindset shift
Core product principles to apply
Your implementation doesn't exist in a vacuum. Every time something significant changes in the business, it creates a reason to revisit how your system is set up and whether it still reflects how your team actually operates. Here are the events we see trigger that most often.
Go-to-market shifts. Moving from a sales-led to partner-led model, or bolting a low-touch, product-led motion onto what you already do, isn't a simple system change. Your entire process has to get re-evaluated, step by step. Does it still work the same way? Do you need two separate flows now instead of one? Are there new teams and stakeholders in the process who weren't there before? Once you've redefined the process, somebody has to actually go build and run it. And the system itself has to be reconfigured to support the new motion. One decision just touched everything, and nobody in the room called it an implementation.
Leadership change. A new leader shows up wanting things tracked their way, their own priorities, their own view of the world. Overnight, there's a new set of requirements nobody budgeted time for. The process has to be redefined, the system has to be rebuilt, and the team has to actually adopt the new way of working. All triggered by one new stakeholder.
Pricing or business model shifts. Across most industries, business models keep evolving, whether that's a move to usage-based pricing or a change in how revenue gets recognized. When the way the business runs changes, almost everything built around the old model has to be revisited. None of that process exists yet in the new model. It has to be defined, built, and someone has to own running it.
Changes to how you package, bundle, or price your offering. Every time the business changes how it sells something, the system has to change with it. If it doesn't, your team goes and builds what the system can't in a spreadsheet, and now you've got a workaround instead of a process change.
Vendor feature releases. Sometimes the trigger comes from the platform itself. A vendor ships something that closes a gap teams have been working around for years. The vendor finally ships it, and now every one of those workarounds needs to get reassessed. Is the native version good enough to use yet? Does it replace what was built? Someone has to decide how things should actually be defined and handled from here, and then actually get the team to use it.
We saw a smaller version of this problem recently. One of our developers built a custom integration between two systems for a client. A few weeks later, one of the vendors shipped a native update that does almost the same thing. Great outcome for the client. But now there's a real decision to make: rip out the custom build and move to the native version, or keep what's working and monitor how the feature continues to develop.
Different starting points, same pattern every time. Something changes. It exposes one or more gaps. Closing that gap exposes the next one. It's never a single fix, and that's exactly why it never feels like "implementation" to the people living through it.
Most teams don't walk into our first conversation saying they have an implementation problem. They say the software isn't working the way they expected. Or they can't get the reports they need. Or the team has stopped using it the way they were trained to.
What they're describing is friction. They know what they're trying to do. They know the tool should be able to do it. They just can't get there on their own. And most of the time, they don't connect that friction back to how the system was set up.
Where teams differ is in how quickly they recognize what they're dealing with. Mid-market and enterprise teams usually know when they need outside help. They either don't have the skill set on the team to execute what needs to happen, or they don't have the bandwidth to get it done on the timeline they need. They come to us knowing they need capacity and expertise.
Smaller teams tend to get caught off guard. They're still learning how connected everything is inside the system. Flip one feature on, and there's a downstream effect nobody expected. They're not looking for an implementation partner. They're looking for someone to help them fix what just broke.
But at any size, the pattern is the same. Something feels off. The tool isn't doing what it's supposed to. And nobody in the room is calling it an implementation problem.
The go-live date is the starting line. Not the finish line.
If implementation never really ends, success can't be one moment either. It has to be a series of checkpoints.
Set a milestone, hit it, set the next one. Each one should get you something you couldn't measure or do before, not just keep the lights on.
Trust is the real signal along the way. Nobody's back-channeling into a spreadsheet because they don't believe the report in front of them. Adoption holds. The system stays a step or two ahead of where the business is, instead of constantly playing catch-up.
That's the difference. Not whether implementation ends. It doesn't. It's whether your system is being managed like the product it is, or whether you're finding out the hard way every single time something changes.
Implementation isn't a project. It's the ongoing work of keeping your system lined up with how your business actually runs.
The teams that get this right aren't the ones that finished implementation. They're the ones who never stopped treating it like a product.
Want to get the "How Teams Work" newsletter sent to your inbox? Subscribe Now.