How to Treat Implementation as a Product — Not a Service

Go-live doesn't mean being valuable.

Yet most implementation teams still measure success as if it does. The system is live. The project is closed. Everyone moves on. Whether the customer actually achieves the outcomes that justified the investment often becomes someone else's problem.

This is the difference between treating implementation as a product versus treating it as a service. Service teams optimize for completion. Product teams optimize for outcomes. One celebrates a launch date. The other owns what happens after.

At Propel 26, Emily Garza, Chief Customer Officer at Unit 21, shared the mindset and operational shifts that helped her team make that transition. 

Working with fintechs and financial institutions on complex fraud and anti-money laundering implementations, Unit 21 learned a difficult lesson: accelerating implementation doesn't matter if customers never realize value.

Their answer was simple but powerful—treat implementation like a product, not a service.

What Does It Mean to Treat Implementation as a Product?

Service teams optimize for completion. Product teams optimize for iteration.

That distinction sounds subtle until you see how it changes behavior.

Products launch—and then improve. They have owners. They have roadmaps. They evolve based on customer feedback. Most importantly, they're measured by whether they deliver value, not whether they shipped.

Implementation should work the same way.

Two and a half years ago, Unit 21 set out to reduce its average implementation timeline from 90 days to under 60. The team achieved the goal. Customers launched faster. Projects closed sooner.

Then the unintended consequences surfaced.

Many customers were going live without the data integrations, workflows, and configurations necessary to realize meaningful value. The implementation was technically complete, but the outcome wasn't.

As Garza put it, the team had optimized for a milestone instead of an outcome.

That's the core principle behind implementation as a product.

Go-live is a milestone.

Value realization is the outcome.

Customers can hit every project deadline and still fail to achieve the business results they expected when they signed the contract. When implementation teams define success through delivery alone, they unintentionally transfer ownership of outcomes to someone else.

The product mindset rejects that handoff.

It treats implementation as an evolving customer experience that requires ownership long after launch.

How to Reduce Customer Lift in Implementation (And Why It Matters)

Every task assigned to a customer introduces risk.

Champions leave. Engineering priorities change. Internal projects get delayed. Momentum slows.

Many implementation delays aren't caused by vendor execution. They're caused by work sitting on the customer's side of the project plan.

Unit 21 addressed this by systematically reducing customer lift.

One example was how they handled technical blockers. Rather than treating implementation challenges as isolated project issues, they created stronger feedback loops between delivery, product, and engineering. When API-only ingestion repeatedly slowed implementations for less technical customers, the pattern became visible across multiple engagements. Product responded by introducing a flat-file alternative, removing a recurring bottleneck for future customers.

The lesson wasn't simply to add more resources.

It was to make blockers visible early enough to eliminate them permanently.

The team also redesigned kickoff conversations. Instead of presenting customers with lengthy task lists, they clarified ownership from day one and deliberately minimized the amount of work customers needed to complete themselves.

Their philosophy was straightforward:

"If your customer's homework is the biggest risk to your implementation, stop assigning homework."

It's a useful exercise for any implementation leader.

Pull up your current project plan and review every customer-owned task.

Could your team do it faster?

Could your team do it more reliably?

Is the customer only responsible because that's how the process has always worked?

Those questions often reveal opportunities to remove friction and accelerate outcomes.

Outcomes First, Milestones Second—With AI as the Governance Layer

For years, Unit 21 started implementations with a question that felt customer-centric:

"You bought it. How do you want to use it?"

Most customers didn't know.

Implementation teams would wait for direction that never arrived, slowing projects and delaying value.

The solution wasn't simply becoming more opinionated. It was codifying successful patterns into repeatable implementation playbooks.

Today, customers begin with a proven path built from lessons learned across similar organizations. Customization still exists, but the default journey is clear.

That creates consistency.

It also makes deviations intentional rather than accidental.

Alongside this shift, Unit 21 introduced product-style measurement into implementation.

The team tracks:

• Time spent in each implementation stage
• Engagement drop-off points
• Feature adoption after launch
• Time-to-value metrics
• Outcome achievement

These metrics help answer a critical question:

Did implementation actually work?

This is where platform architecture matters.

The best implementation teams don't track success criteria in one system, project milestones in another, and adoption metrics somewhere else entirely.

Outcome ownership requires visibility.

At Rocketlane, implementation workspaces are designed around connecting delivery milestones, customer goals, adoption signals, and ongoing value realization. When success criteria live alongside project execution, teams can identify risks earlier and measure impact more consistently.

That's what treating implementation as a product looks like operationally.

The customer's definition of success becomes the organizing principle—not an afterthought.

AI plays an increasingly important role here as well. But not as a side project. As a governance layer.

Garza's team uses AI throughout the implementation lifecycle to improve handoffs, surface risks, identify documentation gaps, and accelerate repetitive work. One notable result: rule-writing time dropped from roughly one hour per rule to fifteen minutes.

The real value wasn't saving forty-five minutes.

It was what happened with the recovered time.

Senior consultants could spend more time helping customers achieve outcomes and less time performing repetitive tasks. Across a portfolio of implementations, those gains compound into greater capacity, stronger margins, and faster customer value realization.

Garza's advice for prioritizing AI investments was refreshingly practical: start with the work people hate.

• Documentation.
• Status updates.
• Administrative handoffs.
• Manual reporting.

The highest-return AI projects often aren't the most impressive.

They're the ones that give your team more time to focus on customers.

4 Key Takeaways from Treating Implementation as a Product

Stop Measuring Success at Go-Live

Go-live is a milestone, not an outcome.

The real signal is whether the customer's operation changed—and that signal needs to be visible continuously, not discovered six months later.

Track adoption, time-to-value, and outcome realization from kickoff onward.

Audit Every Task on Your Customer's Plate

Review every customer-owned task in your implementation process.

If customers are responsible simply because they've always been responsible, challenge the assumption.

Reducing customer lift often has a bigger impact on implementation success than optimizing internal workflows.

Define Success Criteria Before the Work Begins

The best time to establish success metrics isn't at renewal.

It's at kickoff.

If customers already have baseline metrics, document them immediately. If they don't, help them establish those baselines early.

You can't prove impact if you never define what success looks like.

Use AI to Create Capacity for Higher-Value Work

AI shouldn't just make teams faster.

It should make them more effective.

Start by automating repetitive tasks that consume valuable consultant time. Then reinvest those hours into discovery, adoption, customer guidance, and outcome realization.

That's where the real value lives.

Conclusion

The implementation teams that will win over the next few years won't be the ones with the fastest go-live timelines.

They'll be the ones that take responsibility for outcomes.

That shift starts with a simple reframe: implementation is not a service you render. It's a product you build.

Like any product, it requires ownership, measurement, iteration, and a clear understanding of what success actually looks like. It also requires systems that keep outcome data, project health, customer engagement, and delivery progress connected—so teams can identify risks early and improve continuously.

Emily Garza's story is ultimately a reminder that most implementation challenges aren't caused by a lack of effort.

They're caused by a mismatch between what teams measure and what customers actually care about.

Customers don't buy go-lives.

They buy outcomes.

The implementation organizations that understand that distinction will be the ones that create the most value—and earn the right to keep growing with their customers.