Delivery
Agile and AI: Lessons from Group Policy
What Agile and AI change, and what they don’t. One feature, a team of about a dozen, over roughly two years, drove an estimated $57B in enabled revenue for Microsoft over its first thirteen years.
One feature, with a team of ~dozen people, over ~two years, for the first 13 years, drove an estimated $57 billion in enabled revenue for Microsoft. Through 2025, that number was closer to $125 billion (harder to isolate now — it’s folded into broader Windows Enterprise and M365 bundles).
The feature: Group Policy. The unglamorous Windows plumbing, built in the waterfall era, for Windows 2000.
So what can 26-year-old, pre-Agile software teach teams shipping with AI and Agile today? More than you’d think. The fundamentals of good product judgment haven’t moved. Here are nineteen lessons Group Policy still teaches after 26 years.
What Agile and AI change (and what they don’t)
Don’t confuse development methodology with product judgment
- Ask
- A defined set of customer and administrator requirements developed during the waterfall era.
- Delivered
- A solution whose lasting value came from architectural judgment, customer understanding, systems thinking, and disciplined execution — not from the development methodology alone.
- Fundamental truth
- Waterfall, Agile, and AI-assisted development are delivery mechanisms. None replaces the need to understand the problem, make sound tradeoffs, and build a coherent product.
Faster iteration doesn’t excuse short-term design
- Ask today
- Use Agile and AI to produce requested features more quickly.
- Risk
- Rapidly generate disconnected controls, duplicated logic, and fragile implementations that satisfy individual stories but don’t form a sustainable system.
- Fundamental truth
- The faster teams can produce software, the more important architectural coherence becomes. AI can accelerate both good design and bad design.
Human judgment remains responsible for the “why”
- Ask today
- Let AI translate customer requests directly into requirements, code, and tests.
- What is still needed
- Human judgment to determine the real customer problem, desired outcome, platform implications, acceptable tradeoffs, and long-term consequences.
- Fundamental truth
- AI can help determine how to build something. Product and engineering leaders remain accountable for deciding what should be built and why.
Keep a stable conceptual model while the technology evolves
- Ask
- Manage the current generation of Windows desktops.
- Delivered
- A durable model — policy objects, scope, precedence, inheritance, enforcement — that survived multiple Windows generations.
- Fundamental truth
- Technologies and implementations change rapidly. Strong products are built around concepts that remain understandable and useful over time.
A backlog is not a product strategy
- Ask today
- Deliver the prioritized stories and acceptance criteria.
- Risk
- Satisfy every individual request while failing to create a coherent, differentiated, and maintainable product.
- Fundamental truth
- Customer requests are evidence, not architecture. A backlog organizes work; it does not replace product vision or system design.
Product judgment
Build what customers need, not necessarily what they ask for
- Ask
- More policy-control settings than the roughly 100–130 available in Windows NT 4.0.
- Delivered
- An extensible, resilient policy platform built on the core capabilities of Active Directory.
- Fundamental truth
- Customers usually describe the next improvement to the current solution. Product teams must identify the underlying problem and design for the future state.
Optimize for total customer value, not feature count
- Ask
- An increase in the number of policy settings.
- Delivered
- Lower support costs, faster deployment, more consistent security, easier onboarding, and centralized control across thousands of systems.
- Fundamental truth
- Product success should be measured by the customer outcome created, not by the number of requirements completed or features shipped.
Platform and architecture for scale
Build a platform, not a collection of features
- Ask
- Additional controls for configuring Windows desktops.
- Delivered
- Group Policy Objects, inheritance, targeting, filtering, refresh, delegation, and extension mechanisms that could support thousands of settings and new technologies over time.
- Fundamental truth
- When many requests share the same underlying pattern, the highest-value solution is often a platform that makes future capabilities easier to add.
Architecture must reflect scale assumptions
- Ask
- Manage Windows settings in business environments.
- Delivered
- Hierarchical targeting, replication, distributed processing, delegation, and automatic refresh suitable for organizations with very large device populations.
- Fundamental truth
- A solution that works for a thousand users may fail for a hundred thousand. Scale must shape the design, not be treated as a later optimization.
Built for enterprise durability
Treat manageability as a core product capability
- Ask
- More administrative settings.
- Delivered
- A management system that reduced repetitive work, enabled automation, and made large Windows deployments economically practical.
- Fundamental truth
- Manageability, observability, deployment, security, and supportability are not secondary concerns. They are part of the product.
Operational depth and extensibility
Design for change from the beginning
- Ask
- Controls for the Windows environment that existed at the time.
- Delivered
- An extensible architecture that Microsoft and third parties could expand without redesigning the entire policy system.
- Fundamental truth
- Requirements will change. Good architecture does not predict every future requirement; it creates safe, economical ways to accommodate them.
Solve the operational problem, not only the configuration problem
- Ask
- A way for administrators to set more policies.
- Delivered
- A system that distributed, applied, refreshed, and re-enforced policy automatically across large environments.
- Fundamental truth
- A feature is incomplete if customers must manually deploy, monitor, repair, or maintain it at scale.
Make the desired state persistent
- Ask
- Configure a computer or user according to organizational standards.
- Delivered
- Policies that were periodically reapplied, correcting configuration drift and restoring the intended state.
- Fundamental truth
- Enterprise software must account for entropy. A one-time successful action is less valuable than a system that continuously maintains the correct outcome.
Integrate with the customer’s operating model
- Ask
- Control settings on Windows computers.
- Delivered
- Policies aligned with Active Directory Sites, Domains, Organizational Units, users, computers, security groups, and delegated administration.
- Fundamental truth
- Software creates more value when it fits how customers organize people, responsibilities, security, and operations — not merely how the software’s internal components are structured.
Separate policy intent from implementation
- Ask
- Enforce specific desktop and security settings.
- Delivered
- Administrators defined desired policies centrally while Windows and policy extensions handled how those settings were applied.
- Fundamental truth
- Users should express the outcome they want without needing to understand every implementation detail required to produce it.
Preserve consistency while allowing controlled flexibility
- Ask
- Standardize configurations across the organization.
- Delivered
- Central standards with inheritance, exceptions, filtering, organizational-unit targeting, and delegated control.
- Fundamental truth
- Effective enterprise systems avoid both extremes: unrestricted local variation and inflexible global uniformity.
Invest in foundations before accelerating delivery
- Ask
- Immediate additions to the existing policy mechanism.
- Delivered
- Foundational integration with Active Directory that required substantial up-front architecture but enabled years of subsequent capability.
- Fundamental truth
- Speed is not merely how quickly the first version ships. Sustainable speed comes from foundations that make every later change safer and less expensive.
Make extension safer than modification
- Ask
- Support more policy types and settings.
- Delivered
- A model in which new policy capabilities could be added through templates and client-side extensions rather than repeatedly altering the core engine.
- Fundamental truth
- Mature systems evolve more safely when new behavior can be added through defined extension points instead of continual modification of foundational code.
Extension example
- Ask
- Support thousands of additional policy controls across growing Windows versions, products and languages.
- Delivered
- A language-neutral, XML-based policy-definition format with localized resource files and an optional domain-wide Central Store.
- Fundamental truth
- Extensibility eventually requires improving the mechanism that defines and distributes features — not merely adding more features to the existing mechanism.
26 years later, the fundamentals still hold. Worth remembering the next time “ship faster” is the only metric in the room. What’s the “Group Policy” hiding in your product — the unglamorous capability quietly driving your best revenue?
I’m curious what others have found. Let’s talk.
On those figures: based on Microsoft’s reported Windows revenue, selected OEM premium and Pro/non-Pro disclosures, and explicitly stated modeling assumptions, cumulative non-home Windows revenue through FY2025 might be estimated at approximately $256–$294 billion. Of that, Group Policy may have influenced approximately $90–$162 billion and may have been directly responsible for approximately $26–$59 billion. Microsoft did not report or independently validate these attribution figures.
Two hours to find out whether we recognise your problem.
No deck, no obligation. We listen, we tell you whether we have seen this before, and we say what we think it would take. If a Jump Start is the right next step we will say so — and if it is not, we will say that too.