Modern CRM Transformation - Part 2: Designing a CRM Delivery Model That Works

Signal Boost: "Changes" by David Bowie
A classic anthem about evolution and reinvention, perfect for shifting from legacy project thinking to a modern product mindset.

We all know how traditional CRM projects go. Endless requirement gathering. Gantt charts stretched over two years. Big bang deliveries where users only see the new system once it’s too late to change anything. Frustration, resistance, and missed opportunity.

When we started our CRM transformation, we knew that model was not going to deliver the future we needed. This wasn’t just about going live with new technology. It was about building a CRM platform that could evolve, improve customer experiences, and empower colleagues for years to come.

That meant designing a delivery model built for adaptability, ownership, and continuous value, not just ticking off milestones.

From Programme to Product Mindset

Most large programmes are structured around phases and milestones. Teams are temporary. Delivery is the end.

In a product mindset, teams are stable. They own outcomes over time. They discover, deliver, learn, and adapt continuously.

Instead of asking "What features must we deliver by go-live?", we asked "What business outcomes must we deliver, and keep improving, over time?"

This shift changed everything about how we structured teams, planned work, and measured success.

Designing the CRM Product Delivery Model

We anchored the model around three core elements:

1. Value Stream-Aligned Teams

Each product team was aligned to a value stream — a real-world flow where CRM capability directly impacts outcomes. For example:

• Customer Onboarding: How quickly and smoothly can a new customer be activated?
• Customer Service and Support: How fast can we resolve customer issues?
• Partner Management: How effectively can we onboard and support business partners?

These teams were cross-functional: Product Manager, Engineers, Functional Consultants, Business Analysts, and shared UX and QA support.

Each team owned a mission, not just a backlog. "Reduce onboarding time" was a mission. "Build the Onboarding Module" was not.

2. A Platform Enablement Team

Alongside the value stream teams, we built a Platform Enablement Team responsible for:

• Maintaining and evolving the Dynamics 365 core platform
• Building and managing the API layer and integrations
• Supporting data migrations and data quality
• Maintaining DevOps pipelines and environments

Without this team, there would have been no solid foundation. It protected us from fragmented, fragile architecture as the programme grew.

3. Rolling Roadmaps, Not Fixed Gantt Charts

We worked to a rolling six-month roadmap, refreshed every quarter.

This allowed:

• Visibility of major work ahead
• Flexibility to adapt priorities based on learning
• Joint discovery and delivery planning across teams

Instead of treating the roadmap like a contract carved in stone, we treated it like a living guide, visible enough to plan, flexible enough to adapt.

Governance to Support, Not Suppress

We kept governance lightweight and focused on outcomes, not status reports.

• Product Reviews every two weeks: teams showed real product demos, learning, and outcomes.
• Risk Reviews monthly: early surfacing of risks and dependencies.
• OKRs set quarterly: focused on business impact, not feature delivery.

Steering committees weren’t about RAG statuses. They were about steering outcomes.

Challenges We Faced (and How We Adapted)

Team Stability:
As the business reorganised and priorities shifted, keeping teams stable was hard. We had to defend stable missions even when org charts changed. In one case, a team working on partner onboarding was at risk of being broken up when a reorganisation moved some staff into a different function. We fought to keep them together — and it paid off in delivery continuity and morale.

Prioritisation Pressure:
Every value stream wanted more. Prioritisation forced hard conversations. We learned to make business outcomes the judge, not stakeholder volume.

Technical Complexity:
Legacy integrations ran deeper than anyone predicted. Building a clean API layer while managing the old spaghetti was painful, but investing early in the Platform Team meant we could adapt faster later.

We stumbled sometimes. But because our model was flexible, we could course-correct without derailing the programme.

What It All Comes Down To

By designing for stable, empowered, outcome-driven teams, we created:

• Faster learning cycles
• Stronger alignment to business value
• Better resilience to change
• Higher quality user experiences

And most importantly, we shifted the perception of CRM from being a system to maintain, to being a platform that would keep improving as the business evolved. Users noticed. Customers noticed. Leadership noticed.

Next Up: Part 3: How to Empower CRM Teams and Manage Risk.
Governance doesn’t have to kill momentum. We show how to empower teams while managing risk.