Microsoft’s Copilot Problem Isn’t the Model. It’s the Operating Model.
Over the last year, several articles and community posts have highlighted that Copilot adoption is lagging expectations: organizations buy large numbers of licenses, but usage stays shallow, integrations feel inconsistent, and some leaders question whether they’re seeing real productivity gains. See, for example, Lighthouse’s view on what Microsoft 365 Copilot adoption really looks like and more recent analyses of Copilot’s adoption hurdles and integration issues
Many organizations have bought Microsoft Copilot, turned it on for thousands of users, and then discovered… not much has changed. People still spend too much time in email and meetings, content remains scattered, and “AI at work” looks more like a few demos than a new way of delivering value.
From an Agile Product Operating Model (APOM) perspective, this is exactly what we should expect when a powerful capability is dropped into a project‑centric, tool‑centric environment. The model is impressive. The operating model around it is not.
In this post, I connect APOM’s characteristics to real Copilot adoption challenges and offer some concrete steps Scrum practitioners can take to help their organizations treat “Copilot enablement” as a product with its own operating model.
Looking at Copilot Through APOM
Scrum.org’s Agile Product Operating Model describes how organizations can structure around products with characteristics such as unique, holistic, evidence‑based, empowered teams, empiricism, complete, and change management built in.
When I look at Copilot rollouts, I see patterns that clash with those characteristics:
Licenses are purchased centrally, but there is no clear product definition or ownership for “Copilot value” in a domain.
IT enables Copilot as a feature, while incentives, structures, and governance remain optimized for projects and manual work.
Success is measured in seats and logins, not in evidence of improved outcomes, flow, or the ability to innovate.
APOM gives us a language and a structure to change that.
1. Treat “Copilot Enablement” as a Product
APOM emphasizes that each product has a unique operating model tailored to its context. For Copilot, that means we should stop thinking only in terms of “turn Copilot on for everyone” and instead define clear Copilot‑related products.
Examples:
“Sales Copilot Enablement” – focused on opportunity management, proposals, and account communication.
“Customer Service Copilot Enablement” – focused on case handling, knowledge retrieval, and post‑interaction summaries.
“Internal Communications Copilot Enablement” – focused on writing, summarizing, and translating internal content.
Each of these Copilot enablement products should have:
A Product Goal (for example: “Reduce time‑to‑prepare customer proposals by 30% while improving quality”).
A Product Owner accountable for maximizing value.
A backlog that includes discovery, configuration, workflow changes, training, and measurement.
This aligns with APOM’s idea that each product owns its own operating model, rather than inheriting a generic one.
2. Make Copilot Adoption Holistic and Complete
Two other APOM characteristics are holistic and complete.
Holistic means changes to the operating model are considered across incentives, structures, processes, and tools. In many Copilot rollouts:
Teams are told to “experiment with Copilot” but performance measures still reward volume of individual output rather than improved flow or reduced waste.
Governance, security, and data readiness are handled separately from product development, creating friction and fear rather than enabling experimentation.
Complete means product groups own discovery, delivery, and operations, rather than splitting those across R&D, delivery, and support silos. Applied to Copilot:
A complete Copilot product group for Sales should include people who understand the customer journey, the data landscape, the M365 configuration, and the change approach.
That group should be able to discover valuable Copilot scenarios, deliver configuration and content changes, and support the new way of working in Production.
Scrum Teams working inside those groups can then use Sprints to evolve the Copilot‑enabled experience incrementally.
3. Anchor Copilot in Evidence and Empiricism
APOM extends Scrum’s empiricism with Evidence‑Based Management (EBM) to support product decisions at scale. This is exactly what Copilot adoption often lacks.
Instead of measuring Copilot success by:
number of licenses purchased, or
number of users who have tried Copilot once,
we can use EBM‑style measures such as:
Current Value: time saved on specific workflows, quality of outputs, stakeholder satisfaction.
Unrealized Value: high‑value processes that have not yet been redesigned with Copilot.
Ability to Innovate: how quickly teams can experiment with and refine new Copilot scenarios.
Time to Market: the time from idea for a Copilot‑enabled workflow to its first use in production.
Scrum Teams can then:
Start Sprints with explicit hypotheses about how Copilot might improve a workflow.
Use Sprint Reviews to inspect both the product changes (content, prompts, automation) and the measurable impact on flow and outcomes.
Adapt their backlog and operating model based on evidence, not opinion.
This brings Copilot out of the demo and into the inspect‑and‑adapt cycle that Scrum supports.
4. Empower Product Groups Around Copilot
APOM talks about empowered teams and the tension between local optimization and enterprise‑wide needs. Copilot adoption exposes exactly that tension.
A common anti‑pattern is:
Central functions choose and configure Copilot.
Individual teams are told to “use it” but have little influence over templates, governance, or process changes.
Local experiments remain local because there is no clear mechanism to share and scale patterns.
An APOM‑inspired approach would:
Create empowered Copilot product groups around key value streams or product domains.
Give those groups authority over how Copilot is integrated into their workflows, within guardrails defined by governance and platform teams.
Use flow metrics and outcome measures to detect local optimizations that harm the whole and adjust constraints accordingly.
Scrum Teams within these product groups become the engine of Copilot experimentation and improvement, rather than passive consumers of a centrally defined AI tool.
5. Build Change Management into the Operating Model
One of APOM’s most important characteristics is “change management built in”. Pursuing a product model is not an end state; the operating model must continuously evolve based on what is learned.
For Copilot, this means:
Treat change management activities (communication, training, coaching, policy changes) as work on the product backlog, not separate “adoption projects”.
Establish a small group responsible for observing how the Copilot operating model is performing across products and recommending changes to structure, incentives, and governance.
Use empirical data from Copilot usage and EBM measures to guide those changes.
Scrum Masters and agile coaches can play a key role here by:
Making impediments to Copilot adoption visible.
Facilitating conversations about how the operating model itself needs to change, not just the tool.
6. What Scrum Practitioners Can Do Now
Scrum.org’s audience includes Scrum Masters, Product Owners, Agile Coaches, and leaders who are in the middle of both agile transformation and AI adoption. You do not have to wait for a perfect enterprise‑wide design to start applying APOM thinking to Copilot.
Here are practical next steps:
In your context, define one Copilot‑enabled product clearly. Who is the customer? What outcome are you pursuing?
Use APOM’s characteristics as a checklist: is your Copilot approach unique, holistic, evidence‑based, empiric, complete, and supported by built‑in change management? Where are the gaps?
Introduce EBM measures for Copilot: agree a small set of metrics that capture value, flow, and the ability to innovate, and inspect them regularly.
Help create or influence a Copilot product group for your area that has real decision‑making power over processes, templates, and training—not just the tool configuration.
By approaching Copilot through the lens of an Agile Product Operating Model, we can move beyond “AI as a feature” and start treating it as part of our product’s operating model. That is where Scrum, EBM, and APOM together can help organizations turn Copilot from an expensive experiment into a disciplined, value‑delivering part of how work gets done.