Every software organization experiences the same pattern. Early on, the team ships fast. Features go out the door. Stakeholders are happy. Then, gradually, things slow down. Features take longer. Estimates are less reliable. Bugs increase. Developers talk about “tech debt” and ask for time to “refactor.” The system that once felt like an asset starts to feel like a liability.

This isn’t because the developers got worse. It’s because the codebase got harder to change. Business rules are scattered across the system. Only certain people understand certain parts. The test suite (if it exists) is unreliable. Deployments are large and risky. Changes in one area break things in another.

The typical organizational response is to add people. More developers should mean more throughput. But in a codebase that’s hard to change, new developers spend weeks ramping up, then spend most of their time navigating complexity instead of delivering features. The additional headcount produces less improvement than expected.

This is the problem XP solves. Not by working harder or adding people, but by maintaining the conditions that made the team fast in the first place.

What XP actually changes

Extreme Programming is a set of development practices designed to work as a system. Each practice reinforces the others. The result is a team that maintains its delivery speed over time instead of degrading.

Here’s what changes at the organizational level.

1. Rework Drops

Rework is one of the largest hidden costs in software development. Features that need to be rebuilt because requirements were misunderstood. Bugs introduced because code was changed without adequate testing. Integration failures because teams worked in isolation for too long.

XP reduces rework through several mechanisms:

Test-driven development catches defects at the moment they’re introduced, when fixing them takes minutes instead of hours or days.

Customer collaboration keeps developers aligned with business intent throughout development, not just at the beginning and end. Misunderstandings are caught early, before they’re built into the software.

Continuous integration surfaces integration problems daily instead of allowing them to compound over weeks.

The reduction in rework is not incremental. Teams practicing XP consistently report that defect rates drop and features are built correctly the first time more often. Each instance of avoided rework is time that goes toward new value instead.

2. Delivery Becomes Predictable

Predictable delivery matters to every part of the business. Sales needs to know when features will ship. Marketing needs to plan around releases. Leadership needs to allocate budgets against expected outcomes.

Most teams struggle with predictability because of hidden complexity. An estimate of “two weeks” becomes four weeks when unexpected dependencies surface, when merge conflicts consume days, when a bug in production pulls developers off planned work.

XP improves predictability by reducing these surprises:

Simple design means the codebase has less hidden complexity. What you see is closer to what you get.

Collective ownership means work isn’t blocked by individual availability. If the person who usually works on a module is busy, someone else can pick it up.

Small releases mean the team ships frequently. Progress is visible and measurable in working software, not in status reports.

Short iterations with real customer feedback mean course corrections are small and frequent. You don’t discover at the end of a quarter that the project is off track.

3. Key-Person Risk Drops

In most engineering organizations, certain individuals hold knowledge that exists nowhere else. They understand the billing system, or the deployment process, or the integration with a critical vendor. When these individuals are unavailable, whether due to vacation, illness, or departure, the organization’s ability to operate in those areas is compromised.

This risk is expensive. It limits team flexibility, creates bottlenecks, and makes succession planning difficult.

XP addresses key-person risk directly through two practices:

Pair programming distributes knowledge continuously. When two developers work on a problem together, both understand the code, the decisions, and the context afterward. Rotate pairs regularly and within weeks, knowledge is distributed across the team.

Collective code ownership means every developer is expected to work across the entire codebase. There are no personal fiefdoms. No “Steve’s module.” Combined with pairing, this creates a team where multiple people can modify and maintain any part of the system.

The result: no single departure creates a crisis. Vacations don’t delay work. On-call rotations work because anyone can diagnose problems in any part of the system.

4. Teams get faster instead of slower

This is the most important outcome and the hardest to achieve without disciplined practices.

In a typical codebase, the cost of change increases over time. Each feature is harder than the last because the code is more complex, the dependencies are less clear, and the risk of breaking something is higher.

XP reverses this trend through continuous refactoring: the practice of improving code structure as a routine part of development, not as a periodic cleanup project. Combined with comprehensive tests (from TDD) and simple design, the codebase stays clean. The cost of the next feature stays roughly constant, regardless of how many features came before it.

This compounds over time. A team that maintains a clean, well-tested codebase in year three is operating at close to the same speed as in year one. A team without these practices is operating at a fraction of its original speed, spending most of its time managing complexity instead of delivering value.

Why Partial Adoption Fails

Most organizations already practice some XP techniques. They have a CI server. They write some tests. They do code reviews. They work in iterations. These are all derived from XP.

The problem is that these techniques are practiced in weakened forms, and the practices that make them effective are missing.

CI without trunk-based development means long-lived branches that integrate infrequently. The CI server runs, but integration problems still accumulate.

Tests without TDD means tests are written after the code, verifying implementation instead of specifying behavior. The tests are brittle. Developers don’t trust them. They slow down the team instead of enabling change.

Code review without pairing means feedback is asynchronous and shallow. Knowledge transfer is minimal. Design quality is verified after the fact instead of being built collaboratively.

Iterations without customer collaboration means the team ships on a cadence but doesn’t get real feedback between planning sessions. They’re iterating on a schedule without iterating on direction.

Each of these partial adoptions delivers a fraction of the value. The practices are designed as a system. They reinforce each other. Pair programming spreads the knowledge that makes collective ownership safe. TDD creates the safety net that makes refactoring routine. CI keeps the codebase in a releasable state that makes small releases possible. Customer collaboration ensures that what the team builds is what the business needs.

Remove one loop and the system degrades. Remove several and you’re left with process overhead that delivers minimal benefit. This is why many organizations tried “Agile,” found it didn’t deliver the promised results, and concluded the practices were flawed. The practices weren’t flawed. The adoption was incomplete.

What Leadership Should Care About

Total cost of ownership

Software is not a one-time expense. Most of its cost is in maintenance: fixing bugs, adding features, updating dependencies, onboarding new developers. A codebase that’s hard to change has a high total cost of ownership regardless of how cheaply it was built initially.

XP reduces total cost of ownership by keeping the codebase in a state where change remains inexpensive. Tests catch regressions. Refactoring prevents complexity from accumulating. Simple design minimizes unnecessary structure. The system stays maintainable over its entire lifetime, not just its first year.

Time to value

The gap between investing money in development and receiving value from that development is a direct cost. Unreleased features are inventory: they cost money to build and deliver no return until users have them.

XP minimizes this gap through small releases and continuous integration. Features reach users in days or weeks, not months. Feedback arrives quickly. Course corrections are small. The organization learns faster and wastes less money building things that don’t deliver value.

Team scalability

Adding developers to a poorly maintained codebase produces diminishing returns. Onboarding takes longer. Coordination overhead increases. The new developers spend more time understanding existing complexity than delivering new value.

XP creates conditions where adding team members is productive. The codebase is well-tested and well-named, so it’s faster to understand. Knowledge is distributed through pairing, so onboarding is built into the daily workflow. Collective ownership means new developers can contribute to any part of the system immediately, not after weeks of learning one module.

Organizational resilience

Markets change. Priorities shift. Key people leave. Competitors move. An organization’s ability to respond to change is a competitive advantage.

XP builds this resilience at the team level. Code that’s easy to change means the team can pivot when priorities shift. Distributed knowledge means departures don’t create crises. Short iterations with customer feedback mean the team detects wrong directions early. Small releases mean new directions can reach users quickly.

What Adoption Looks Like

XP is often perceived as rigid or extreme (the name doesn’t help). In practice, adoption is incremental and the return on investment is visible quickly.

Start with the code quality loop. TDD, refactoring, and simple design have the most direct impact on codebase health and developer productivity. Begin with new code. Don’t try to retrofit tests onto an existing system all at once.

Introduce pairing on complex work. Don’t mandate full-time pairing immediately. Start with bugs, unfamiliar areas, and complex features. Let the team experience the benefits before expanding the practice.

Shorten your delivery cycle. If you release monthly, try biweekly. Then weekly. Each reduction in batch size reduces risk and increases feedback speed. Invest in CI/CD automation to make frequent releases practical.

Bring the customer closer. If your product owner only attends planning and demo meetings, increase their availability. Create a channel for real-time questions. Review working software continuously, not at sprint boundaries.

Measure what matters. The right metrics aren’t XP-specific. They’re delivery metrics that any engineering organization should track:

• How long does a change take from first commit to production?
• How often do changes in one area break something in another?
• How many developers can confidently modify any given part of the system?
• How much time is spent on rework versus new development?
• How quickly can a new developer contribute?

The Bottom Line

Extreme Programming is an investment in sustainable delivery speed. It’s the discipline of maintaining the conditions that make software teams productive: clean code, shared knowledge, continuous integration, frequent delivery, and tight feedback with users.

Most organizations have tried pieces of XP and found them insufficient. This is because the pieces work as a system, not as independent techniques. TDD without refactoring produces rigid code. CI without small releases delays feedback. Pairing without collective ownership limits knowledge distribution. Each practice enables the others. The value is in the system.

The organizations that adopt XP as a complete system don’t just ship software faster. They ship the right software faster, and they maintain that speed over years instead of watching it erode.

Your engineering investment compounds or it decays. XP is the discipline that determines which one.

 

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

Your developers are already using AI. The question is whether they’re using it with a methodology that protects the business, or without one.

Most developers using AI tools today are doing it ad hoc. They open a chat, describe what they want, and paste the output into the codebase. Sometimes it’s good. Sometimes it’s subtly wrong. Sometimes it contradicts a decision the team made three months ago that the AI doesn’t know about.

The output varies by developer. One developer prompts carefully and gets clean results. Another prompts loosely and gets code that works but doesn’t match the team’s patterns. Over time, the codebase accumulates inconsistency; different naming conventions, different error handling approaches, different test structures.

All technically functional, all slightly different.

This is AI without methodology.

It’s fast, but it’s undirected.

It trades short-term speed for long-term maintenance cost.

What Spec-Driven Development Changes

Spec-driven AI development introduces structure around the AI interaction. Before any code is generated, the feature is designed in a detailed specification — what the feature does, why it exists, what the acceptance criteria are, and how it fits into the existing system. A rules file encodes the team’s architectural standards and conventions. The AI reads both before producing a single line of code.

This changes three things that directly affect the business.

1. Design is reviewed before implementation, not after

In a traditional workflow, the first time the team sees a feature’s design is in a pull request — after the code is already written. If the design is wrong, the code is rewritten. If the design is merely suboptimal, it ships anyway because rewriting feels too expensive.

In a spec-driven workflow, the design is reviewed as a specification before implementation begins. The team debates architecture, catches conflicts with other in-flight work, and agrees on the approach while it’s still cheap to change. By the time code exists, the design has already been approved.

The business impact: reduced rework. Catching a flawed API contract in a spec review costs an hour of discussion. Catching it in a pull request costs a day of rewriting. Catching it in production costs a sprint of emergency fixes. Spec-driven development shifts discovery to the cheapest possible phase.

2. The team’s standards are encoded, not implied

Every software team has conventions — how they name things, how they test, how they structure code. In most teams, these conventions live in people’s heads. New developers learn them through trial and error, corrected over weeks of pull request reviews.

In a spec-driven workflow, conventions are written in a rules file that the AI reads before generating code. Every developer’s AI assistant follows the same rules. The result is consistent output regardless of who’s implementing — a junior developer with six months of experience produces code that follows the same patterns as a senior developer with ten years, because the AI enforces the conventions for both of them.

The business impact: consistency at scale without constant oversight. Code reviews become faster because reviewers aren’t catching convention violations — the AI already handled that. New developers ramp up faster because the rules file is the onboarding material for coding standards. And the codebase stays coherent as the team grows, instead of accumulating the inconsistency that typically accompanies headcount increases.

3. Knowledge lives in artifacts, not in people

When a senior developer leaves, their knowledge of why the system is designed the way it is leaves with them. The code remains, but the reasoning behind architectural decisions, the tradeoffs that were considered, the edge cases that were deliberately handled — that context is gone.

In a spec-driven workflow, every feature has a specification that captures the design rationale. Every convention has a rule that explains the decision. These artifacts are versioned in the repository alongside the code. They’re always current because maintaining them is part of the development process, not an afterthought.

The business impact: reduced key-person risk. The cost of turnover drops because the institutional knowledge is in the repo, not in someone’s head. A new hire can read the specifications for the last twenty features and understand not just what the system does, but why it does it that way. This is the kind of documentation that teams always intend to write and rarely do — except here, it’s a natural byproduct of the workflow rather than extra work.

What Leadership Should Actually Care About

Predictable throughput

Specifications are scoped units of work with clear acceptance criteria. A spec that says “implement this domain model with these endpoints and these tests” is more estimable than a Jira ticket that says “add board collaboration features.” Teams that design before they implement can estimate more accurately because the scope is defined before the clock starts.

This doesn’t eliminate uncertainty — implementation still surfaces surprises. But it reduces the most common source of estimate variance: ambiguity about what “done” means. The spec defines done. The AI implements to that definition. The review verifies against it.

Faster onboarding, real output sooner

The traditional onboarding path for a developer joining a new team: read the wiki (if it exists and is current), shadow a senior developer for a week, make mistakes on the first few pull requests, gradually absorb the team’s patterns over a quarter.

The spec-driven onboarding path: read the rules file for coding standards, read recent specs for architectural context, pick up a spec, implement it with AI assistance. The AI enforces the team’s patterns from the first commit. The developer’s output is consistent with the rest of the codebase on day one, not month three.

This matters for organizations that are growing, that have contractor rotations, or that operate in competitive hiring markets where onboarding speed directly affects time-to-value.

Quality as a default, not a goal

In most organizations, code quality is maintained through code review — a manual, human-driven process that depends on reviewer attentiveness, available time, and consistent standards. When reviewers are busy, quality slips. When the team is under deadline pressure, reviews get lighter. Quality is aspirational.

In a spec-driven workflow, the AI generates code that follows the team’s documented standards every time. It doesn’t get tired. It doesn’t cut corners under pressure. It doesn’t forget the convention the team agreed on last month. The baseline quality of generated code is consistent regardless of sprint pressure, reviewer availability, or time of day.

Human review still matters — the AI can produce code that’s structurally correct but conceptually wrong. But the review shifts from catching mechanical issues (naming, structure, test coverage) to evaluating design intent and correctness. That’s a better use of senior engineering time.

Reduced technical debt accumulation

Technical debt typically accumulates through small, individually rational decisions: a shortcut here, an inconsistency there, a “we’ll fix it later” that never gets fixed. Over time, these compound into a codebase that’s expensive to maintain and risky to change.

Spec-driven development attacks debt accumulation at two points. First, the specification forces design thinking before implementation, which prevents the architectural shortcuts that create structural debt. Second, the rules file prevents the convention drift that creates consistency debt. The team’s standards are enforced automatically, every time, across every developer.

This doesn’t eliminate technical debt. Conscious tradeoffs still happen, and requirements still evolve. But it eliminates the accidental debt that comes from inconsistency, oversight, and eroded standards under pressure.

The Reframing that Matters

The conversation about AI in software development is often framed as “AI replaces developers” or “AI makes developers faster.” Both framings miss the point.

Spec-driven AI development doesn’t replace developers. The AI doesn’t make architectural decisions. It doesn’t design domain models. It doesn’t write specifications. It doesn’t evaluate whether a feature serves the business. All of that — the thinking — is still done by people.

What the AI does is eliminate the gap between a well-thought-through design and its implementation. Once the feature is fully designed — once the spec exists — turning that spec into working, tested code becomes nearly mechanical. The human effort shifts from writing code to designing features and reviewing output.

This is a leverage play, not a headcount play. The same team delivers more — not because they’re working harder or faster, but because the methodology eliminates the translation loss between design and implementation. The spec is the design. The AI reads the spec. The code matches the design. The review verifies it.

What Adoption Looks Like

Adopting this methodology doesn’t require reorganizing the engineering department or buying a platform. It starts with three files in a repository.

Start with one team, one project. Pick a team that’s about to start a new feature or a new project. Have them write specifications for the first three features before implementing anything. Write a rules file with the team’s conventions. Use AI to implement against the specs. Measure the results.

Evaluate on outcomes, not activity. The right metrics aren’t lines of code or commits per day. They’re: How much rework happened? How many spec review comments led to design changes before code was written? How quickly did a new team member produce consistent output? How does the codebase’s consistency hold up over time?

Scale gradually. If the pilot team’s results are positive, expand to a second team. Let the rules file and spec format evolve organically. Don’t mandate a process — demonstrate outcomes and let adoption follow evidence.

The investment is low. The methodology requires no new tooling beyond the AI coding assistant the team likely already has. The specifications and rules files are markdown documents in the repository. The workflow change is in how the team uses the tools, not which tools they use.

The Bottom Line

Spec-driven AI development is a methodology that turns AI coding assistants from individual productivity tools into team-wide quality infrastructure. It reduces rework by shifting design review upstream. It reduces onboarding time by encoding standards in machine-readable form. It reduces key-person risk by capturing design rationale alongside code. It reduces technical debt by enforcing conventions automatically.

The developers on your team are already using AI. The question isn’t whether to allow it — that ship has sailed. The question is whether they’re using it with a methodology that compounds quality over time, or without one, accumulating inconsistency with every feature.

The spec is the difference.

 

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

Every organization has at least one system that everyone dreads touching. It works. Technically. But nobody can confidently explain what it does or why it does it that way. Making changes takes longer than it should. Estimates are unreliable. New developers stare at the code for weeks before they can contribute.

This doesn’t happen because the original developers were bad at their jobs. It happens because the system was built as a collection of technical components (databases, APIs, services) without a clear model of the business it was meant to support. Over time, the business evolved, but the software’s structure didn’t evolve with it. Business rules got scattered. Terminology drifted. The reasoning behind decisions disappeared as the people who made them moved on.

The result is a system where the cost of change increases with every release. Not because the technology is old, but because the intent is buried. Nobody knows where “the rule” lives. Nobody knows which change is safe. Every modification is an archaeology project.

This is the problem DDD solves, and it’s a problem with real financial consequences.

What Domain-Driven Design Actually Changes

Domain-Driven Design is not a framework or a technology. It’s an approach that puts business understanding at the center of how software is structured. Before anyone writes code, the team develops a shared model of the business domain: the rules, the processes, the language, the boundaries. That model then shapes the software directly.

This changes several things that matter at the organizational level.

1. The business and engineering speak the same language

In most organizations, there’s a translation layer between what the business says and what the code does. Product describes a feature using business terms. Engineering interprets those terms, maps them to technical concepts, and builds something that hopefully matches the intent. When it doesn’t, the gap is discovered late: in QA, in production, or worse, in a customer complaint.

Domain-Driven Design eliminates this translation layer by establishing a ubiquitous language, a shared vocabulary used consistently by business stakeholders, product managers, and developers. When the business says “policy,” the code has a Policy. When the business says “claim is adjudicated,” the code raises a ClaimAdjudicated event. The language in the conference room is the language in the codebase.

The business impact: fewer misunderstandings, fewer features that miss the mark, and faster conversations about what needs to change. When everyone uses the same words to mean the same things, the cost of communication drops and the accuracy of implementation rises.

2. Complexity is contained, not spread

As systems grow, complexity tends to spread. A change to pricing logic touches the order system, which touches invoicing, which touches reporting. Everything is connected to everything else, and the blast radius of any change is unpredictable.

DDD addresses this through bounded contexts. These are boundaries that define where specific models and rules apply. The pricing context owns pricing logic. The invoicing context owns invoice generation. They communicate through defined interfaces, not shared databases or implicit dependencies. Each context can evolve independently, with its own model, its own rules, and its own team.

The business impact: changes become safer and more predictable. When pricing needs to change, the pricing team changes the pricing context. They don’t need to coordinate with invoicing, reporting, and three other teams in a two-week planning exercise. This is how organizations scale engineering without scaling coordination overhead proportionally.

3. Business rules are explicit and locatable

In most codebases, business rules are scattered. Some live in the application layer. Some are encoded in database constraints. Some exist only in the minds of developers who wrote them. Some are duplicated in multiple places, with subtle differences between copies.

When a rule needs to change (and rules always change) the first challenge isn’t implementing the change. It’s finding the rule. And then finding all the other places where a version of that rule might exist. And then figuring out which version is correct.

DDD requires that business rules live in the domain model, in one place. A pricing rule is in the pricing aggregate. A validation rule is in the entity that enforces it. When the business says “we need to change how we calculate late fees,” the developer knows exactly where to look.

The business impact: faster changes, fewer defects from partial updates, and less time spent on “investigation” before actual work begins. When rules have a clear address, the cost of business evolution drops.

4. Systems age well instead of decaying

Most software systems get harder to maintain over time. Not because the technology degrades, but because the conceptual integrity erodes. Early decisions that made sense are overridden by quick fixes. Naming conventions drift. New features are bolted on without revisiting the underlying model. Slowly, the system becomes a patchwork: functional, but fragile and expensive.

DDD-based systems resist this decay because the model is designed to evolve. When business understanding deepens, the model is refined to reflect that understanding. When boundaries shift, contexts are restructured. The design is a living representation of the business, not a frozen snapshot of what someone understood three years ago.

The business impact: lower total cost of ownership. The system in year five is not much more expensive to maintain than the system in year one. Features take roughly the same amount of time to build, rather than the slowdown that characterizes systems built without intentional modeling.

What Leadership Should Actually Care About

Predictable delivery in complex domains

The hardest part of estimating software work isn’t the coding. It’s the uncertainty about scope, impact, and hidden dependencies. In systems without clear boundaries and rules, every estimate includes a “discovery tax”: time spent understanding the current state before any change can begin.

DDD reduces this tax by making the system’s structure mirror the business’s structure. When a product manager describes a change in business terms, the engineering team can map that change to specific contexts and aggregates. The scope is clearer. The impact is more containable. Estimates become more reliable. Not perfect, but better.

Team autonomy that actually works

Many organizations pursue team autonomy through microservices, hoping that service boundaries will enable independent delivery. But if those boundaries don’t align with business boundaries, teams still end up coordinating constantly. Service A needs a field from Service B. Service C’s deployment breaks Service D’s assumptions. The boundaries are technical, not meaningful.

DDD provides the framework for drawing boundaries that work: boundaries based on business capability, shared language, and domain ownership. When contexts are well-defined, teams genuinely own their domain. They can make decisions, ship changes, and evolve their models without waiting for alignment meetings.

Reduced key-person risk

In systems without models, knowledge concentrates in individuals. The developer who built the billing module understands it because they hold the mental model. When they leave, that understanding leaves with them. The next developer inherits code without context.

DDD captures understanding in the model itself: in the names, the structures, the relationships, and the rules encoded in the domain layer. A new developer joining a DDD-based system can read the domain model and understand what the system does in business terms, not just technical terms. The model is the documentation.

A foundation for AI-assisted development

This is worth calling out. As organizations adopt AI coding tools, the quality of AI output depends on the quality of the codebase it works with. An AI reading a well-modeled domain with clear boundaries, rules, and consistent language produces better results than an AI reading a tangled codebase with scattered logic and inconsistent naming.

DDD doesn’t just make the system better for humans. It makes it better for every tool that reads, generates, or modifies code. The investment in modeling pays dividends across both human and AI-assisted development.

The Reframing That Matters

The conversation about DDD often gets stuck in technical details: aggregates, value objects, event sourcing. These are implementation concepts that matter to developers, but they obscure the real value proposition for leadership.

The real value of Domain-Driven Design is this: it keeps your software aligned with your business as both evolve.

Without intentional modeling, software and business diverge over time. Changes get harder. Communication gets fuzzier. Costs compound. With DDD, the software is structured around business concepts, bounded by business capabilities, and expressed in business language. When the business changes, there’s a clear path to changing the software. When a new team member joins, the codebase tells them what the business does.

This is not a one-time architectural decision. It’s an ongoing practice, like code review or testing, that compounds in value over time.

What Adoption Looks Like

DDD is often perceived as heavyweight. It doesn’t have to be. Adoption is incremental, and even partial adoption delivers value.

Start with language. Before anything else, invest in getting business and engineering aligned on terminology. This costs nothing but meeting time and delivers immediate improvements in communication clarity. If your teams argue about what a “customer” is in different parts of the system, you already have a problem DDD can solve.

Draw boundaries around your biggest pain points. Identify the area of the system where changes are slowest and riskiest. Define a bounded context around it. Give a team clear ownership. Let them model the domain and evolve it independently. Measure the results.

Don’t boil the ocean. DDD doesn’t require rewriting your system. It doesn’t require adopting event sourcing or CQRS or microservices. It starts with understanding the domain, establishing shared language, and structuring code around business concepts. The advanced patterns are options, not prerequisites.

Evaluate on outcomes that matter. The right metrics aren’t DDD-specific. They’re delivery metrics: How long does a business rule change take from request to production? How much coordination is required for a feature that spans multiple teams? How quickly can a new developer contribute? How often do changes in one area break something in another?

The Bottom Line

It reduces the cost of change by making business rules locatable. It enables team autonomy by drawing boundaries that align with business capabilities. It reduces key-person risk by capturing understanding in the model, not in people’s heads. It keeps systems maintainable over time by providing a framework for intentional evolution rather than accidental accumulation.

Your software is a model of your business whether you designed it that way or not. The question is whether it’s a model you can reason about, communicate clearly, and change confidently, or one that has become an obstacle to the very business it was meant to support.

DDD is the discipline of making sure it’s the former.

 

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.

When clients call us, they often say they want to become a product-led company, then spend the rest of the conversation talking about Product Ops as if the two are interchangeable.

They’re not.

They’re related. They reinforce each other. But they solve very different problems.

And if you blur that distinction, you usually end up doing one of two things. Either you say you want to become product-led, but you shrink the ambition down to Product and Delivery teams who still won’t have the agency to reprioritize the backlog or choose the right problems to solve. Or you convince yourself that better roadmaps, cleaner backlogs, stronger rituals, and better product management practices will somehow produce better strategic decisions on their own.

They won’t.

In both cases, you burn energy and political capital without materially improving value realization.

One Changes How You Invest; One Improves How Product Work Runs

Here’s the simplest way to separate the two conversations.

Product operating models define how the enterprise allocates capital and accountability to create value through products and platforms. This is the product-led conversation.

Product Operations improves the system of delivery around the products you already have. It strengthens decision flow, planning, measurement, and learning inside product areas.

A product operating model changes the economic logic of the enterprise. Product Ops improves execution inside the current logic.

That distinction matters because it changes what results you can expect. Product Ops can improve throughput, visibility, and coordination. It cannot, by itself, change where the company places its bets, how it funds learning, or whether it is solving the right problems in the first place.

How the Difference Shows Up in Organizations

You can usually tell which conversation you’re really in by the constraints people describe.

If leaders are talking about funding, portfolio trade-offs, decision rights, and whether they can move capital as evidence changes, you’re in product operating model territory.

If they’re talking about roadmap confusion, weak prioritization, too many stakeholder reversals, poor release coordination, and inconsistent metrics, you’re in Product Ops territory.

Both matter. But they do not operate at the same altitude.

What a Product Operating Model Actually Changes

A product operating model works the big levers.

It changes the environment product teams operate inside:

Structure

Stable, cross-functional teams organized around products, platforms, and value streams. Less project spin-up and tear-down. Clear domains and ownership boundaries.

Governance and Funding

Decisions happen at product and portfolio level. Funding shifts from one-off projects to durable product investment. Initiatives are treated as bets with explicit outcomes and short feedback loops that support persist, pivot, or cease decisions.

Metrics

Success moves away from “on time” and “on budget.” It shifts toward behavior change, customer outcomes, and realized value.

When this shift is real, you hear it in executive language. Leaders stop reviewing a list of projects and start reviewing a portfolio of bets. They ask where to invest, why, and what evidence would change the decision. Finance and governance reinforce that logic instead of quietly undoing it.

This is exactly why Product Ops alone cannot create a product-led enterprise. Product Ops cannot override a funding model that rewards project completion. It cannot undo governance that demands certainty before learning.

What Product Operations Actually Does

Product Operations lives closer to the work. It makes product work easier to execute, easier to understand, and easier to steer. It reduces friction across the interfaces that slow teams down.

Strong Product Ops practices usually show up in three areas. 

Decision Visibility and Cadence

Clear forums for prioritization and trade-offs. A stable rhythm for planning, bet reviews, and outcome check-ins. Fewer surprise reversals because decisions happen in the open and on a known clock.

Operational Consistency

Shared patterns for roadmapping, release planning, and stakeholder communication. Not because every team needs the same template, but because teams need a common language for intent, progress, and learning.

Instrumentation and Learning Loops

Standards for measurement, experimentation, and impact reporting. Teams ship with observation in mind. Leaders get signals early enough to adjust decisions before the budget is gone.

In other words, Product Ops tunes the system of delivery around products and services. It helps teams work in smaller, value-proving steps. It makes evidence easier to produce and easier to interpret. It reduces the transaction costs of working across product, engineering, design, data, marketing, and commercial stakeholders.

That is valuable. But it is still downstream.

And that is the point.

If the real constraint is upstream, in funding, governance, and investment logic, then improving Product Ops will hit diminishing returns fast.

When the Wrong Fix Creates a Product-Led Rebrand

Here’s the pattern I see all the time.

A company feels stuck. Roadmaps change weekly. Delivery teams feel whiplash. Leaders don’t trust what they’re hearing, so they add more reviews. Everyone agrees they need to “become product led.”

They hire a product leader, who ends up focusing on Product Ops, whether by choice, by belief, or because that’s the remit they’ve been given.

That leader does good work. They standardize roadmapping. They introduce a planning cadence. They improve stakeholder communication. They create dashboards. They tighten release coordination. Delivery becomes smoother.

Value realization barely moves.

Why? Because the real constraint sits upstream. Funding is still allocated as fixed-scope projects. Governance still expects certainty at the beginning. Portfolio still measures progress through milestones, not outcomes. Product Ops improves throughput and transparency. The enterprise is still placing bets without an evidence loop and still cannot reallocate capital when reality changes.

Now flip the scenario.

The same company starts by clarifying its product operating model. It defines product domains and creates stable teams. It changes portfolio governance to manage a portfolio of bets, not a list of projects. It funds learning in tranches, with explicit outcomes and decision points.

Then Product Ops steps in to make that model work today. It creates the cadences that keep decisions flowing. It standardizes what good evidence looks like. It helps teams instrument outcomes so the portfolio can move capital based on signals.

In the first scenario, Product Ops compensates for the operating model.

In the second, Product Ops multiplies it.

That is the difference.

How to Diagnose What You Need Now

A simple diagnostic question works well with executives:

Are you trying to change where and how you invest, or how well your current product system delivers on those investments?

If you want to move significant funding from project portfolios into durable product teams, align finance, HR, and governance around products and value streams, and run strategy as a portfolio of bets and customer outcomes, you’re in product operating model territory.

If you want to make existing product teams more outcome-driven and evidence-based, reduce friction in prioritization and stakeholder engagement, and standardize how you launch, learn, and iterate, you’re primarily solving a Product Ops problem.

But don’t confuse that with transformation.

If you are rewiring the enterprise, you must start with operating model design and with inspecting whether the wider system actually supports continuous evaluation of the opportunities you pursue. Then Product Ops becomes the fabric that keeps decision flow and evidence visible.

If you skip that step, Product Ops may make the machine run more smoothly.

It just won’t tell you whether the machine is headed somewhere worth going.

 

This content comes from our product and strategy practice, which specializes in structuring product organizations for clarity, flow, and customer alignment, while linking delivery decisions to enterprise strategy.

In this conversation, Andrew Young explains that organizational policies should be treated as part of a living system that must evolve as conditions change. He argues that systems always produce the outcomes they were designed for at a specific moment in time, but as organizations grow or shift, policies must adapt through continuous feedback and change.

However, simply having the right policy is not enough; successful adoption requires bringing people along through iterative feedback, stakeholder involvement, and trust-building. As complexity increases with more people and policies, organizations must focus not just on the policies themselves but on the relationships between them and the people affected. When policy conflicts arise, leaders should first diagnose structural duplication, measure the policy’s actual outcomes, and assess stakeholder trust before assuming the policy itself needs to change.

Video Transcript

Matthew Oatts

Thanks, Andrew for joining me again. Last time we were talking about policy and we were talking about how policy in an organization is sort of like a living thing. Maybe you could think about organizations as ecosystems. So where I want to get into now is like we talked about ecosystems, living organisms, whatever you want to call it. That’s natural world stuff. Those things change and I want to explore what happens with change tied to policy, but like we talked about last time, there’s a context that a policy exists. So can you talk to us about, fundamentally, is there a top of mind question when we think about organizational change in policy?

Andrew Young

Yeah. Before we get into how it shows up, maybe I’ll step back and talk about three core backstopping phrases, principles, references we have that help us frame why one should be comfortable with change or why change is present. So first and foremost, we think every system is currently designed to produce exactly what it’s producing. And that’s a result of, it was a snapshot of time and place. It was a snapshot of when the system was created. And you can look at the relationship of people or policy or the organization to how it’s operating. And you can tell how old that design was just purely by Conway’s Law, how things interact. It’s producing the organization. So there’s this truth of whatever you’re experiencing was right for when it was developed.

Matthew Oatts

You mentioned Conway’s Law. Explain that in a couple sentences.

Andrew Young

Conway’s Law says the interactions and the communication and the architecture could be technology, it could be people, it could be policy is designed, will be designed and it will reflect how people actually interact. The way you experience the organization is a reflection of the interactions in the organization is the way you say it. If you take this out of context for any company, I pick up the phone, I call customer supports. And if they don’t have this other information, I can clearly tell you behind the scenes, those two departments don’t work together. Law manifested. So we believe every system designed to produce exactly what it’s producing for the time and place and a healthy organization will continually update that time and place. It’s not static, it’s not deterministic. We know conditions change and those conditions could be market conditions, internal people shifts, leader shifts, vision shifts, even just how big the organization is and the number of interactions, all of those things influence.

Matthew Oatts

So, if you’re scaling really quickly, this ends up being a big thing, you’re probably spending a lot of time talking about what has shifted and changed in the organization.

Andrew Young

And hopefully you’re continually making incremental updates to reflect that shift.

Matthew Oatts

If you’re healthy, if you’re maybe not healthy, you’re sort of running with the same models that you had three years ago and you’re probably going to experience a bunch of pain.

Andrew Young

That’s right. And you’ll have a whole bunch of gaps and they’ll be very evident and gaps will show up in that version as tension, conflict, and upset people.

Matthew Oatts

Or suppression of all of those things underneath the surface and then it’s only happens.

Andrew Young

That’s exactly right. Okay. So there’s that truth or that principle. There’s a second one that having the right answer is necessary, but it’s insufficient.

So we can know what a better policy looks like. We can even write the better policy, we can create the better picture. But until you enlist people and bring them along, having the right answer won’t matter. I can know exactly what to do, but unless I enlist the people around me through co-opting or alignment or leadership, there’s a variety of ways we can talk about that. The right answer is insufficient because it’s about the application of the right answer and getting people comfortable with the right,

Matthew Oatts

Especially if there’s this under the surface thing going on where people are like, oh, well that’s how we said we were going to work, but we don’t work that way anymore. So they’re just not even going to get bought into any policy because they play the game where it’s like, oh, that policy is irrelevant. Or they joke about that 400 page policy. Did you read that today before you woke up? No.

Andrew Young

Yeah. And so then this gets into our last kind of truth. We believe, and we know it’s been proven and there’s whole consultancies just specialize in change, that once you have the right answer or a belief of the right answer, the hardest activity is not getting to the right answer. It’s actually creating the change to support the right answer. And that change takes more cycles, effort, energy than anyone’s going to predict and the people leading the change. So here’s the underlying of what we’re saying, are already exhausted because they were the creator of it. They were investing in it, they were the designer of it, so they had the right answer. They put all of the cycles in to get there and nobody else around them has any of this exposure or attention or energy of cycles with it. And so there’s a discrepancy of the people leading the change already feeling exhausted. And the receiver of the change could be a new policy implementation could be a shift in the organization, could be even just like when I get a new leader, the leaders who made that decision are already exhausted with that decision because they’ve been working on it for so long. But this is my first interaction with you is my leader and I don’t know what this means.

And we then shortcut maybe just to even abandon the energy it takes to change. And that’s where failure occurs. It’s not because we didn’t have the right answer. Again, it’s because we didn’t invest the appropriate energy into getting people along. So this is where you create skeptics. It’s not because always they disagree with it, it’s because they weren’t enlisted or brought along in the journey. So when I hear people talk about stakeholders, and we’ll talk about this, I think in a few moments, how do you manage your stakeholders? And that one’s a skeptic, therefore we have to dismiss them or we have to do something different. They might just be a skeptic because they haven’t been brought along.

So, you have to understand why are they getting mapped to where they are because it’s the change piece that’s probably the limiter, not to the actual mapping of where that person is as a skeptic. So take all that we believe those things to be true, and therefore we have to design change as the vehicle for adoption. We have to design the outcome of whatever the right answer is in a way in which can be absorbed.

Matthew Oatts

Okay. So are there different sort of levels of complexity with that? I know sometimes when we’re talking about change, if you have a direct report or if there’s a single person, you have to navigate that that’s different than if there’s a smaller group of people. That’s a different way. You have to think about change differently. If we’re talking about a large group of people,

Andrew Young

The scale of difficulty is I think what you’re referencing, like the scale of size. So if it’s just two of us, it’s one thread. If there’s three of us, there’s this thread, this thread, and this thread. So three people have three, but you had a fourth. So it’s 1, 2, 1, 2, 3, 4, 5, 6. So with every new node, you’re adding the intensity of interpretation and point to point interaction increases. So you have to have a better foundation of alignment.

Matthew Oatts

Yep. Do you find even if there’s, let’s say there’s a just dropout idea of a policy in the middle of all of that space one, and then there’s almost, you could treat the policy as another part of the triangle, how I relate to you and how we both relate to the policy. That’s essentially another node. Do you find, does it help hurt? Does it even matter? Maybe the answer is all of the above. When a policy is supposed to, we talked about in a previous conversation, having a policy sort of being a central construct of the thing, but not when we start talking about people. You can only go so far getting everybody oriented against the construct of a policy. How does a policy fit into those spaces too?

Andrew Young

Yeah, when I think about the node, if we just oversimplify a node, be it a policy, a person, a thing, again, the increasing volume of nodes creates complexity. And so if it’s just you and I and a policy, we can very quickly understand is it you and I having an issue? Is it me individually with the policy? Is it you and I both having an issue with the policy? We can triangulate against the policy node. Is it the node or is it the relationship when there’s 10 policies and 10 people, 20 nodes? The ambiguity of is it a people,

It a one person to a policy, is it a collection of people all hating that one policy? Is it the concept? We don’t like that style and node CAU a policy. We’re adding layers of complexity into the narrative. So what I heard your question was, and tie it back to your opening question, living systems, which is what an organization is, time and place. We have an answer, wants to be deterministic and develop notes. Here they are, they’re stable, and now everybody go interact and play healthily. And what the living system tends to forget is that the node answer is insufficient. It’s actually about the connection of the nodes. And we under prioritize or deprioritize our energy into the strength of the relationship of the nodes. Meaning do I have conflict with the policy? Do I have conflict with the concept of policy? Do I have conflict with the person? And we forget that. And this is now the governance piece. How the nodes interact is a policy unto its own, regardless of if the node itself is a policy. So there’s policy to manage policy and then there’s policy to manage our relationship, and then there’s policy for policies to manage each other.

Matthew Oatts

Or processes the policy might have something that is actually affecting a different sort of aspect of the organization.

Andrew Young

And when we oversimplify and what so many organizations do, I developed a note, here’s a policy, everybody gets it. We also now are forgetting about the human emotional component of it. If it’s never as clear as the person who authored it thinks it’s going to be. And this gets into the change piece and the adoption piece,

Matthew Oatts

Why you need feedback loops as you’re developing policy, you get one of the things that we talk about all the time in terms of policy creation is maybe the drag it can feel when you’re creating policy and you have to go through different review cycles. Well, there’s reason there to give people an opportunity with authority to sort of change things. But there’s also, you’re sort of prototyping the efficacy of a policy at the end of the day, I’m guessing, trying to get in front of what you’re talking about is people are going to relate to the policy in different ways. And so you need to sort of get in front of how people might relate to this thing.

Andrew Young

And a tool liminal arc brings from our background would be fast incremental, fast incremental and iterative cycles. In the technology world, we call this the tension between agile development and waterfall development. So if I apply that here, do I want to spend all this time to get what I believe is one correct policy authorship and it takes a long cycle and I do it in a vacuum and I put it into the world. Well, I have emotional energy, it’s correct, but I have no feedback loops. And there’s a series of frameworks. We use one fast, incremental, iterative feedback cycles. Take the thinnest slice of that, get some feedback, iterate, iterate, iterate. And if you have that as a core pattern, you’ve already created the platform for a living organization. It’s incrementally changing all the time based off of feedback loop. You’re never done.

Matthew Oatts

So that should be good news for people that have to create policy. And there’s different gateways like you’re doing that not because people want to jump through hoops. If it’s an effective and healthy organization, you’re doing that to increase the likelihood that when it gets into the wild, people are going to be receptive and at best advocate for it or at worst just be comfortable with it.

Andrew Young

That’s right. And there’s a lot of ways you can gain feedback. So we want to add a little bit of structure to incremental and iterative feedback. One of the ways we bring that in is we think about the stakeholders. We’re asking for feedback. Do you want feedback from everybody or do you have someone who’s on this side of the gradient of I don’t believe in any of this and why it’s needed. So here’s my feedback and I actually have someone on this side that says, this is exactly what we need and I’m an advocate for, do you get feedback from one or both and building structure that, okay, skeptics and supporters are both valuable feedback loops and someone who is so close to it, they might’ve wrote one very similar and someone who’s never done this before, gaining feedback. We build this two by two concept of stakeholder mapping to use a mapping activity to understand where the feedback needs to live. And then back to our governance conversation and back to our prioritization conversation. Out of these stakeholders, who do I actually care about? Who am I trying to influence and bring along in the change? So we map those things out for incremental and iterative feedback. And we also use, I think to what you just said, the comfort nature of this, as if you can do a little slice of it and then you gain some feedback and someone sees their voice has been incorporated, the organizational voice has been incorporated, at least heard

You build trust and the more trust, so I’m drawing this with my hand. We have a visual that’s like an infinity symbol. The more trust you can build with someone, the easier it is to bring them along and change the easier it is. We label it as influence to build influence. And the only way you can build influence is based off of credibility and we will leave. One of the easiest ways to build credibility is with small thin slice, incremental, incremental and iterative attempts to showcase. I was here, I’m now here and I can bring you along. I was here, I’m now here. I can bring you along. And all of this is underneath the guise of don’t go disappear in a silo and build this thing in a vacuum in a really grand way and do this grand reveal. We use this phrase with our clients. Our clients should never be surprised

They’ve been brought along. We bring them as partners; we really enlist them as a partner. So when I think about as applying this to policy, anybody who’s going to be put in the box of that policy, you have to play this game should never be surprised with the first time of them reading the policy. They should have had either early iterations, this is directionally where we’re going, or they had some like this is also why we’re changing. We miss that component a lot in this development cycle of here’s a new rule book, but I never told you why we’re changing the rule book and I never enlisted you in helping me grow the narrative of why that’s a tactic as well. Again, going back the right answer of the new policy is insufficient

The way we think about changing to the new policy, the tools we use to enlist people that then slicing to incremental feedback loops to build trust. All of these are the patterns underneath of policy creation or policy change.

Matthew Oatts

So, if I tie it back to a fundamental question, when there’s some sort of issue that comes up and policy gets thrown into the arena of conflict around it, maybe it’s just one person, maybe it’s smaller group of people, maybe it’s a whole organization is starting to bubble up with issues around policy. The fundamental question is going to be do we need to change the policy or is it not actually a policy issue? So when we talk about the trust influence loop, we talk about stakeholder maps. At some point you sort of have to make the decision and it’s not necessarily just either or, but at what point do and what are the types of things that you do as a leader, as someone closely tied to the policy to say, you know what? I’m going to do maybe these three things before I go down the path of, oh, I need to change a policy because when I hear you talk about policies and their role within the organization and there’s a potential change coming forward, at some point quality policies shouldn’t change that much, but people should really be investing in the relationships around the policy. So what would maybe be three good tips to, you should do these three things before you go down the path of oh, we need to change the policy.

Andrew Young

Yeah, I’m going to tie it back to our prior conversation. I think a lot of it anchors on that. So I hear attention. An individual has a problem with the policy. A group of people have an issue with a policy. A policy is in conflict with another policy. That’s a very evident one that

Matthew Oatts

Yeah, the policy is clearly the impediment of some sort of process being effective. Okay,

Andrew Young

So my first question, when I root cause, so I’m going to start with a quick root cause analysis. Am I having a structures problem? Is this just because two different things were given autonomy and they’re in conflict with creation. So we’re creating duplication of responsibility or agency or energy. So I’m going to start there and if I say, oh, it’s just actually a, we don’t know where the boundaries are. Cool, let’s start with the boundary piece. Let’s figure out who owns it and then let’s figure out in that new boundary of application, is there still conflict? If we realize we have created duplication easy to solve. If we say, oh no, there’s no duplication, we actually haven’t changed and have any structures issue, we have a relational issue. So I think that’s level two. Level two relational. She says, is it because someone feels unsafe? Is it because they don’t feel heard? I’m trying to thin slice some categories that it’s unsafe, they don’t feel heard or it is creating a negative result if the policy is actually producing bad outcomes. I’m still going to tie it back to my structures conversation.

Matthew Oatts

Something that you could actually directly observe this as a negative, not necessarily emotional result, but something logical.

Andrew Young

Logical or objective. But the only way I know how to measure that is I go back to the structure of the value piece of it. The value structure says this thing is preventing this green light from remaining green, and now I’ve taken Matthew or Andrew’s opinion out of it and I say, look, here’s why this version of the policy is struggling. And that’s actually what the person is struggling to say most likely is I

Matthew Oatts

Don’t, especially if they’re bringing a lot of emotion to the table. The emotion could just be an indicator of their sort of sense that, hey, this policy, while it might not be in conflict with someone else, it is some impediment to the organization.

Andrew Young

And so the headline there is every policy and every structure needs to have measures. Can I measure what it’s producing and its impact? Is it going up where I want it or down?

Matthew Oatts

This goes back into why measuring things are so important. When we talk about navigating policy change, a good indicator to the fact you need to actually change the policy is do the measures tell you that yeah, something’s wrong and you can change the policy.

Andrew Young

And from all of our history with all of our clients, the first thing that gets abandoned is measures. It gets put under the table because it’s hard. People don’t know how to actually measure things, especially impact of a policy on a thing. The traceability of measurement is not easy. So we just tend to not do it and hope for the best.

So, create measures against the structure though. That’s the second thing. I think the last thing, so if we realize it’s not duplication and we have measures and someone is still having tension or a group of people who have attention, I go instantly to my stakeholder map, where do I put them? And is it that they don’t have trust with the person that created it or trust with the organization or trust with the policy itself. So we figure out do they not have trust and is it because they’re skeptic or not brought along? And I then go through that mapping activity of is there noise because I really think about all this. It’s just kind of noise. There are probably some happy, healthy truths underneath all this, but is this noise that is emerging because we haven’t enlisted them?

And if all of this, no duplication, we have good measures, we’ve enlisted them, now I can finally get to the person issue. Maybe I might actually now have evidence that the wrong person’s in the wrong seat attempting the wrong thing and it could now just be skills, capability or vision, mission, values, alignment issues. But so many people start with that you don’t get it, or I did it right. How come you don’t see it? And we skip all of this root causing to get there. So I think the three things that I identified get ruled up into the statement. There’s a objective logical chain of progression for root cause analysis that starts with every bit of noise can be patterned into that. If we air quoted framework, start with duplication reduction or make sure that there’s not start with measures. Start with where does a person get enlisted and all of this is true and it still has tension. Now we have a conversation we can actually index to.

Most product failures don’t come from bad intent or weak engineering. They come from unstated assumptions that enter the organization as facts.

“We know what customers want.”

“This workflow will drive adoption.”

“Of course, this will increase revenue.”

None of those statements are automatically wrong. The problem is what happens next.

Once an assumption hardens into “truth,” it slides into a roadmap, gets translated into epics and stories, and reaches a delivery team as if it’s already validated, creating a sunk cost in unvalidated beliefs. And this quietly kills your ability to realize value.

Make Belief Inspectable Before You Fund

In healthy product systems, leadership doesn’t try to eliminate assumptions. It makes them visible, discussable, and testable.

Two disciplines do most of the work:

• Value propositions turn belief into a clear hypothesis about who we expect to impact, what changes, and why it matters.
• Outcomes turn that hypothesis into a measurable learning contract.

Together, they shift the conversation from certainty to stewardship. You’re not debating whose idea wins. You’re deciding which bet deserves investment right now, what evidence will change your mind, and how quickly you will revisit the decision.

Why Value Propositions Often Fail

Value propositions, like many powerful frameworks and tools, have turned into an artifact to fill in. In practice, the power is not the canvas. The power is the discipline of divergence and convergence.

Divergence means exploring the customer’s world with range. Different jobs, pains, and gains across segments and contexts. What are they looking to accomplish. What makes the current approach costly or fragile. What would count as meaningful improvement.

Convergence is where value becomes meaningfully defined. You force a choice. Which job and pain will you address in this bet. Which will you explicitly not address. That choice becomes a value map. It is the slice of the customer’s world you intend to change.

A well-formed value proposition does three things at once:

• It bundles assumptions into a single hypothesis you can inspect
• It makes the investment explicit, including when you expect to see signals
• It anchors the bet in the problem, not in a solution you happen to like

Without that clarity, bias does what bias does.

Recency bias builds for the last loud customer.

Confirmation bias selects supportive data.

Authority bias turns the highest-paid hunch into a roadmap.

Outcome-Driven Work Often Hides Output Thinking

Many organizations say they are outcome-driven.

But what shows up on paper often falls into three categories:

• Vague aspirations such as “delight customers.”
• High-level business goals such as “grow ARR by 20%.”
• Outputs wearing a disguise such as “launch self-service onboarding by Q3.”

Those statements can be useful, but they don’t help a product team make trade-offs.

A usable outcome has three qualities:

• It describes a change in the world, not a thing you shipped
• It includes clear success criteria, including a baseline and a “good enough” threshold
• It is small enough to steer by, meaning the team can plausibly influence the result

When outcomes lack that sharpness, they become a translation layer back to output. The organization still governs by features and dates. Teams cannot answer the question that matters most:

If this works, how will we know?

If you can’t answer that, you can’t make the most important decision in product development: persist? pivot? or cease?

When a Roadmap Becomes a Learning Contract

Imagine this scenario: an Executive Team wants to improve onboarding efficiency for its customers.

The roadmap arrives with confidence: “Launch self-service onboarding in Q3.”

A product leader pauses and turns the certainty back into a bet.

Value Proposition Hypothesis

For new customers in a specific segment trying to complete first-time setup, we believe guided onboarding will reduce setup friction and increase early activation, leading to faster time to first value (TTFV) and higher conversion from trial to paid.

Now the assumption is inspectable. It also creates productive constraints. You have named the segment, the job, the friction, the expected behavior change, and the value you expect to follow.

Next comes the outcome.

Outcome Hypothesis

Reduce median TTFV from thirty days to seven. Increase first-week activation from ten percent to 40% for the target segment. We will review in four weeks.

Notice what changes.

Portfolio can ask whether this is the best bet for investment right now, given the expected upside and the uncertainty. Product can decide what smallest slice can prove or disprove the proposition. Delivery can instrument the experience, so the signals show up quickly and credibly.

Most importantly, the organization has permission to change its mind without blame. If the signals move, you double down. If they do not, you adjust the proposition or stop funding activity around that set of customer onboarding assumptions altogether.

That’s value realization in practice. You don’t have to have to execute perfectly, but you do have to develop a system that values learning as a critical component of delivery.

Key Takeaways to Reduce the Impact of Assumptions on Value Delivery

• Treat roadmap statements as hypotheses until you can point to evidence
• Use value propositions to make belief shared, explicit, and testable
• Define outcomes that include a baseline, target, and decision date
• Instrument delivery so learning shows up early, not after the budget is gone
• Make persist, pivot, or cease a normal, regular, and consistent portfolio decision, not a performance judgment

It’s been a little over three years since I last sat down with A&G Managing Editor Holt Hackney to talk about the State of Agile. As of May 2025, the bloom is clearly off the agile rose. This has been the case for long enough that one might say the plant itself is dead. Industry prognosticators have also been rather blunt in their recent assessments of “agile.” For example, earlier this year Scott Ambler wrote what he called his ‘agile scatological series,’ starting with The Agile Community Shat the Bed, where he attempts to hold the agile community to account for its failures.  This article represents my take on the contributing factors that explain why “agile” failed as a brand, describes measurable sources of value contributed by the agile movement, and offers guidance each of us can use to start improving business results without the baggage of “agile.”

Going Off the Rails

While I agree with much of Scott Ambler’s recent writing on this topic, a primary contributor to the current state of agile was its focus on agility as an end rather than a means. That is, over the past 15 years a considerable amount of marketing material about “agile” made the pitch that the end state was “to achieve business agility,” versus agile being a means or tool that supports an organization’s objectives. These objectives invariably revolve around sustained, profitable growth. Absent a clear connection to profitable growth, it’s not surprising that “agile” is being tossed aside in favor of the next candidate for the hype cycle: AI.

…and speaking of hype cycles, another reason “agile” went off the rails is that while riding its hype cycle, “agile” never reached the plateau of productivity. Why? One reason is that agilists introduced too many conflicting and divergent approaches that fragmented the market.  “Agile” meant so many things to different people that hiring managers could never predict what they were getting when a candidate’s resume indicated s/he was “experienced in agile development.”

Another reason organizations failed to generate value with “agile” was that too many agile approaches focused on changing practices or culture while ignoring the larger delivery system in which the practices operate, reinforcing a culture that is resistant to change.  This shouldn’t be a surprise to people following our industry, as my colleague and LeadingAgile CEO Mike Cottmeyer has been talking about why agile fails for over a decade, such as his Agile 2014 presentation, Why is Agile Failing in Large Enterprises and What You Can Do About It.

The final reason that led “agile” to its current state of disfavor is that early in the agile movement there was too much money to be made in training and certifications. The industry’s focus on certifications had the effect over time of misaligning the goals of the methodology / training companies and their customers. “Train everyone. Launch trains” may be a short-term success pattern for a methodology purveyor, but it is ultimately unsustainable because the training and practices are too disconnected from tangible results senior executives need to compete and win in the market.

Show Me the Money

After the dust settles, there are three compelling sources of value from “agile” that business leaders ignore at their peril:

• Productivity,
• Risk Management, and
• Product / Market Fit.

Each of these sources of benefits can be measured and therefore tied to business outcomes that generate incremental profit and/or revenue growth.

Productivity

Productivity is the ability to efficiently convert inputs into outputs, We can measure it as the output per unit of input over time. Agile approaches help improve productivity in three distinct ways, including:

Establishing Predictability:

The ability to accurately identify when work is going to complete.

Many organizations struggle to know when work will be done, which makes it difficult to plan the introduction of new products and services to customers and markets. Improving predictability allows an organization to more efficiently align its resources around product and service launches. Agile approaches, starting with establishing the structure, governance, and metrics for a system of delivery, rapidly improve predictability.

Smaller Work:

The ability to break large work units down into smaller ones that contribute business value and can be completed independently.

Agile approaches encourage decomposition of work into smaller units that are easier to estimate and therefore easier to deliver with speed and quality.

Eliminating (or Orchestrating) Dependencies:

A relationship between two or more tasks where one task cannot start, continue, or finish until a predecessor is completed or reaches a specific milestone.

Unknown or unmanaged dependencies frequently cause teams to fail to deliver on commitments. Agile approaches, especially those that leverage the Theory of Constraints (where we design work around the limiting factor of a work system) improve the rate at which work moves through the system by reducing the impact of dependencies on cycle time.

In combination, these factors contribute to significant reductions in the cost per unit of work, which directly contributes to profitability.

Risk Management

Risk management is the ability to identify and mitigate things that could go wrong with a project or work effort. It includes a well-known process: a cycle of identification, assessment and mitigation. Mitigation approaches range from the reactive (acknowledgement, avoidance) to proactive (hedging, transfer, and escalation). We can calculate the value of risk management with techniques like Expected Monetary Value, where one identifies the probability of occurrence and the financial impact if the risk occurs.

Agile approaches to work enable effective risk management, especially the combination of escalation (moving risky work earlier in a project) and hedging (investing in multiple alternatives to ensure a minimally viable solution exists when needed). An example of the use of agile approaches to manage architecture and delivery risks is the business fable, Risk Management is Never Having to Say, “I’m sorry.”  In the fable the lead character takes on a highly risky assignment, delivering in ten weeks what another team failed to deliver in eight years.  This fable is also a good segue to our last source of value generated by agile approaches: product / market fit.

Product / Market Fit

Product / Market Fit is the degree to which a product (or service) satisfies a strong demand in a specific market. It effectively meets needs in ways that, as one of my former product management colleagues describes it “…products that customers love to use.”  We can measure product / market fit through a variety of metrics, including customer demand, retention, revenue growth, willingness to pay a premium price, and a differentiated value proposition.

Agile approaches contribute to product / market fit in four distinct ways. First, they help organizations quickly build things that customers want to use. The frequent, rapid delivery of working tested product allows a product development team to learn through customers’ actual use of a product the things they want to use.

Second, agile approaches help development teams more quickly eliminate things that customer don’t use, reducing wasted investment. Next, rapid iterations and customer feedback allow us to discover and eliminate customer dissatisfiers. Finally, the agile focus on simplicity, dependency removal and avoiding over-engineering results in products that are easier to maintain and change, contributing to increased profitability over the life of a product.

Where to Begin: Get Off the Pareto Chart

Over my career I have seen organizations take three basic approaches to change, including top-down, bottom-up, and middle-out. Each approach has its strengths and weaknesses. With sufficient research, one can find a body of theory to support each approach.

However, they all converge at the role an individual leader plays within the organization.  This is the approach I call “get off the Pareto chart.”  A Pareto chart is a continuous improvement tool that combines a bar chart of problems in descending frequency with a line chart to illustrate the cumulative percentage of problems. The goal of the chart is to identify and mitigate the 20% of sources that generate 80% of the problems. The items on your chart should focus on business problems that your stakeholders care about and want solved.

Any leader can look at the pain points or problems within the leader’s span of control, and make those problems go away through a three-step process of:

1. Organize teams and work to become predictable,
2. Make work smaller to improve quality and make the pain go away, and
3. Eliminate / orchestrate dependencies to improve cycle time.

By establishing metrics to measure improvements in flow, quality, and productivity, it becomes easy to communicate the incremental value generated in business terms: impact to business growth and profitability.

This approach also reduces conflict over change because rarely do colleagues argue with someone who openly discusses problems within his/her own organization and owns the solution of those problems instead of blaming others or making excuses.

Finally, by making small but measurable improvements over the things within one’s span of control, one can deliver significant improvements in as quickly as three months, making subsequent improvements “self-funding.”

The Future of Agile?

“Agile” continues to generate value, even if the “brand” of agile has become toxic. This is why the future of agile isn’t “agile.” It is demonstrably contributing to sustained, profitable growth. It is taking on business and technical risk to solve gnarly business problems.   It’s about leaders modeling accountability by establishing the necessary structure, governance, and metrics so the organization can become predictable, make work smaller, and eliminate dependencies. It is leaders establishing dedicated, multidisciplinary teams with specific backlogs who frequently deliver working tested product to customers, resulting in products that customers love to use. It is teams delivering better quality products and services, faster, and in a sustainable manner.

In other words, we finally stopped talking about agile and started doing it.

This article was originally published in Architecture & Governance Magazine in June 2025.

In most large enterprises, business and technology each have their own view of how the organization works.

On the technology side, Domain-Driven Design (DDD) is used to make software modular and adaptable. The goal is to keep software systems “soft” by encapsulating complexity inside each domain. It’s a powerful approach in theory, but in practice, business requests can couple domains together, requiring heavy orchestration. This results in complex release plans with lots of dependencies that negate the benefit of the adaptable architecture.

On the business side, Business Capability Models (BCMs) define what the company must be able to do to execute strategy, such as managing orders, fulfilling services, or acquiring customers. BCMs help clarify the “what” of business execution, but they rarely tie directly to the “how” in technology terms. The BCM appears to enable business agility by simplifying complex business processes into discrete and independent units. However, the technology systems that support these capabilities often tie these units together, increasing the complexity of change and slowing down progress.

The current reality is two models that describe an organization from entirely different points of view:

• One architectural and technical, focused on software design.
• One operational and strategic, focused on business function.

When technology modernizes without business context, it defaults to all-or-nothing initiatives, such as lift-and-shifts, rip-and-replaces, and rewrite-everything programs that take years and yield little measurable value. When business capabilities evolve without technology alignment, strategy becomes constrained by legacy systems that can’t change at the speed of the market.

At LiminalArc, we believe the answer lies in unifying these perspectives through Business Domain Architecture, a model that fuses the principles of domain-driven design and business capability modeling into a single, cohesive approach.

Business Domain Architecture: Core Definitions

Business Domain 

A business domain is the unifying architectural structure that aligns business capabilities with software domains. Business domains encapsulate the operations, policies, software, data, and infrastructure necessary to deliver measurable value. Domains provide a stable, unified structure for decision-making, change management, and measurement across the enterprise.

Business Domain Modeling

The practice of identifying and describing business domains and their roles, interactions, and interdependencies. It gives business and technology leaders a shared language, facilitating better prioritization, avoiding waste, and creating traceability from investment to KPI improvement. It becomes the blueprint for extracting and encapsulating teams, technology, and data to create clear boundaries between business domains. It also defines the interaction model between business domains, increasing adaptability and minimizing the cost of orchestration.

Relationship to Business Capabilities

While business capabilities describe what the business must be able to do, business domains group those capabilities with the supporting technology into cohesive execution units that can change independently, reducing complexity and improving speed to market.

Relationship to Domain Driven Design

Business domains extend the principles of modular software architecture beyond the codebase, applying it to the entire operating model. Where DDD defines how software should be organized to stay adaptable, business domains define how the enterprise should be organized to take advantage of that adaptability.

Why Business Domains Matter

By elevating the concept of a “domain” from a technical construct to an enterprise-level structure, business domain architecture ensures that modular software design, funding models, operating models, and governance all reinforce each other.

By aligning business capabilities (what needs to happen) with technology architecture (how it happens), organizations can make smaller, targeted improvement investments with measurable economic impact. Savings and performance gains from one cycle fund the next, creating a self-funding improvement program. Modernization shifts from focusing on the cost of doing business to a portfolio of value creation opportunities.

Private equity firms have mastered financial arbitrage. But when software is the product, value creation depends on how fast you can modernize and integrate.

Video Transcript

Philippe Bonneton

Building upon what we discussed on Monday, the PE world, and what’s happening there, and what I took away from our conversation were three shifts. One, there’s a big move towards PE ownership. It’s more and more of the buyouts that we see are driven by private equity. There is a sort of race to the top and to how big you can get. So the platforms are getting consolidated and you’re starting to deal in the PE world with bigger and bigger and more complex conglomerates and roll-ups of companies. And where the financial playbook, the financial arbitrage playbook was really the name of the game traditionally. Now it’s moving much more towards product and software execution as the way to drive value or to a lot of these PE firms have value creation teams now or entities that are very much focused on, okay, it’s not just going to be cost cutting, rationalization, rip and replace. It’s going to be we need to make sure that we drive growth, that we expand the product set, that we adopt new technologies and so on.

And so that’s what I took away as the three shifts that are happening in the PE world. And where I think LiminalArc is super relevant to help play there because the big dilemma or the big chasm to cross there is if you’re a PE firm and you’re acquiring assets, you’re acquiring companies, you have your portfolio companies, something we’ve talked about before, when you acquire them, they’ve been very successful at getting to point a right? Getting to a place where they were valuable to you as a private equity company. Now, the team that’s in place, the products that are in place, the infrastructure underneath that was what took that company that you acquired two point A. As a private equity firm, you look at it and you have a business plan, you have a business case that you say, I want to take it to point B. What does it take? Point B is not just financial arbitrage anymore. Point B is all of these things I talked about.

Mike Cottmeyer 

Yeah. Well, I think to some degree, I think what we’re really going for is that you start to, as these companies roll up and roll up and roll up, at some point in time, a large private equity firm gets caught holding the bag. And there’s only so much that you can get in economies of scale, and you just have to start looking at combined product offers, integrated services, technologies that work together. We have to be able to add new features, capture new markets, much like that. And what I think we’re seeing in a lot of our clients and just generally in the marketplace is that the software that these companies run on is often not great. It’s often not easy to change. And now we combine multiple entities and we want to build combined feature sets. And you start asking yourself the question, how are we going to do that without creating a total mess?

You were talking about the idea of rationalization. I think rationalization is actually part of it, depending upon how you use the word. And so things that are common and can be used across the companies should be collapsed into a single thing. And that’s how I see rationalization. That’s how I’ve used the word, right? So that’s real, but how are you going to do it when every company has some version of some sort of legacy software, legacy monolith that they can’t untangle, unpack, decompose, that kind of a thing. And so what our hypothesis is in this space is that if we can find those value props that they want to exploit, look across the software ecosystem, figure out what components across that ecosystem to extract, rationalize, combine, rewrite, whatever, and then start organizing around it. We actually get the merger part of the mergers and acquisitions side of it. I think what you’re alluding to in the old playbook is that there’s a lot of merging of the business, but not necessarily merging of the technology. And in some companies you could probably say, well, we’re going to rip out your CRM and we’re going to put everybody in Salesforce or SAP or something like that. But when the software is the product, what are you going to do there?

And that’s where I think our offer really comes into play is because when you can start to look at the business capabilities, the product capabilities, start to understand at least the hypothetical domain design of the technology stacks, start to figure out what to extract, rationalize, combine, align the technology to the business, and then connect it up into the business problems they want to solve, then I think that’s where we start to be able to win. The idea is that somebody in that rollup at some point is going to be left holding the bag and is going to have to run that company and is going to have to grow that company and exploit its capabilities. And most of what we’re seeing in private equity rollups, at least the ones we worked with, is that that level of rationalization isn’t happening.

Philippe Bonneton 

Yeah, I think so. And I have sort of a yes and to it where you’re leaning towards the technology integration consolidation, figuring out the pieces. So on the rationalization, absolutely, I follow you. I think the yes end is as a private equity firm, you’ve acquired this asset and now the job is going to be to de-risk it, right? You have a business case to hit, you have a sort of valuation or an exit valuation that you’re thinking about how do you make it as predictable as possible? And so you can go with sort of financial leverage to figure out exactly how you’re going to get some gains early on. But I think what we’re seeing is that increasingly the de-risking needs to happen with how teams deliver software, how teams deliver product. And that’s where, in addition to the technology modernization that we can help companies with, portfolio companies with, there is the how the work is done and how is it done in a rapid manner, in a predictable manner, in a reliable manner.

And I think that’s becoming one of the key levers for PE firms is figuring out how am I going to get those teams that work under the CIO, those legacy software teams, IT teams, how am I going to make sure that I know they’re delivering very predictably that they’re focusing on value on what drives the business case. So there is some foundational operating model aspects to this that need to be worked on that go way past the financial arbitrage I was mentioning earlier. So I guess what I’m trying to say is there is a sort of technology modernization and consolidation play that’s critical to master. So you need to know how to do that, but you also need to know how to drive the right sort of governance, the right sort of flow of work with the teams that are executing within those portfolio companies.

And that’s a big shift, a big overhaul that if you’re focused on quick wins, kind of like, okay, we need to exit this or consolidate it in a year and we just need to focus on broad stroke consolidation and so on, you’re never going to tackle this aspect of it of how do you increase the throughput and the predictability of the teams that are delivering the software. Going back to my point, the teams that took that company to point A, how do you get them in a motion that goes towards that point B that’s going to lead to your exit?

Most modernization efforts fail because they focus on technology first instead of the underlying economics. In this clip, we unpack why aligning IT projects to measurable value is the key to sustainable change.

Video Transcript

Mike Cottmeyer

If I’ve got to spend tens of millions of dollars and wait years to be able to do it well then it’s not particularly economically viable and it’s a huge risk. So, it’s not just find the business problem that’s worth the dollars, do the extraction, build the organization. It’s find the problem that you can solve in an incremental and iterative way, incrementally and iteratively extract and modernize and incrementally and iteratively build the organization around it and tie it up through governance.

And for us, because we started off as an agile transformation company, our kind of mental model was stabilize the system in place in the presence of dependencies start to reduce batch size and increase flow and then start to break down the technical dependencies creating encapsulated objects like you might in a composable enterprise and then we can fund independently those composable objects. What we’re really fundamentally doing with this; it’s really almost a reverse.

It’s like figure out the economics first and what you want to fund persistently, which things are going to be the largest force multipliers in our ability to solve economic problems. Those are the things we want to invest in. And which technical dependencies, which areas of technical debt, which areas of the applications need to be modernized and then start to run small batches through it and then stabilize the system and make sure that it operates in a reliable and repeatable way moving forward.

Stacy Gordon

Well, so the question I have about that is I think the biggest challenge is that people have is really defining that MVP, what is that minimal viable product? How do I make sure that it is small enough that the things that we are putting in that goal can be done? I think that’s got to be something. I wonder if we talk about a enough, because from what I’ve seen over the years, and it’s not always in modernization, but it’s in application goals or new feature sets and it’s like, okay, if we’re trying to build this thing and this is the minimum viable product, making a customer understand really do you don’t need all these other things, it’s going to make it more complicated and harder to reach that goal in 90 days. So how do you make sure that they understand that you can’t throw too much into that minimal viable product if we want, because we are looking to get something out the door in 90 days that’s going to start returning value.

And the more things you throw in, the bigger that thing that you’re trying to solve is, which is going to continue to, it’s not going to happen 90 days now. It’s going to happen in 120 days now. It’s going to happen longer. To me, there’s this dynamic that I don’t know if we talk enough about on how you walk them through the process to make sure that the chunks that you’re choosing to work on so that you can show time to value faster. There’s definitely a nuance to that and how you manage the customer.

Mike Cottmeyer

Yeah, for sure. What was going on in my head as you asked that question or made that statement was kind of interesting. It was almost like my brain wanted to take a step back and what I was kind of teasing out was this idea of a minimally viable product on one side that almost implies that maybe we’re building something from the ground up. What my brain was floating over to was almost like the idea of a minimally viable extraction, a minimally viable modernization. So one of my initial hypotheses is when we started going down this path a couple of years ago, especially around with AWS, was that we had had these monoliths that were moved to the cloud that were driving out control spend and preventing often those lift and shifted applications from being able to consume what we might call the high value strategic services that AWS can do. And my initial hypothesis was that yes, Amazon’s going to take a hit on the front side because their cloud costs are going to be lowered, but then there’s opportunity on the backside for them to consume more strategic services, which also has the net effect of making those customers more sticky to the AWS platform. So, they can’t as easily be enticed away with lower prices on the next contract negotiation or something like that.

And it’s fascinating because if I take it from a cloud optimization perspective, the minimally viable extraction might be something like, okay, let’s go find the areas of the application that are driving most of the costs and let’s extract and modernize those and see how we can then make that extracted object work with the rest of the legacy monolith. On one of the use cases we’ve referred to here recently, one of the challenges that they had is that it was yes, they were using a legacy monolith, but they actually had legacy business processes associated with that legacy monolith. And so as once we identified the business problem that they wanted to solve and we had our revenue increase hypotheses, we didn’t actually really extract the code out of that monolith. What we ended is rewrite it, rewrote it, and deprecated it. And when we had the opportunity to rewrite it, because the business and the technology organization were so closely aligned and both had a seat at the table, we could reevaluate the business processes, take a fresh look at the application and data architecture that were needed to support that, and then that flips into the other side of what you’re talking about that was more like, okay, now what is minimally viable in the presence of these new business processes and this new data architecture?

So, it’s kind of interesting and I’ll tell you, I think that’s what’s so hard about having these conversations sometimes because very self-aware as I’m even using these words, because what I try to do is I try to use words that are a high enough level of abstraction. So, they’re generally applicable in most settings, but then when people hear the messages, they’re like, well, what do you mean by technology object? I had somebody ask me that on LinkedIn the other day, what do you mean by technology object? And what I want to say is anything that can be encapsulated that provides a service, right? On one side it could be a microservice on the other side, it could be maybe an application that could be supported by a team, something like that. To me, it all comes back down to this encapsulation orchestration thing that I talk about all the time. So, it’s like I have this kind of riffing here at this point. I have this problem in lots of areas in my life right now. I’m trying to sort through just and create a mental model around. It’s like how do you have conversations about really abstract, important things when people are living in the details of it every day?

And so, you got to align people on concepts, you got to align them on the words you’re using. You have to understand the constraints that they’re operating within their particular world. You’ve got to, it’s almost like creating an instance of a language to have a very specific conversation that’s tough. And just even Stacy and some of the stuff that we’re talking about here, just the idea that you could have the business show up at the table, reimagine the business process while we’re extracting that technology object out of the monolith and do that in parallel in such a way that we can do the transformation, the teaming strategies and the governance and stuff on the other side. Even that I think is a psychological barrier for a lot of people that might hear this. And then that gets to your earlier comment that we made is like, are we selling to the CIO, the CTO or the CFO?

And I think that’s where a lot of this problem is going to have to eventually be solved and why it has to start with the dollars. Because at the end of the day, who else can solve the business and IT have to interact appropriately. They have to partner together. We have to look at the business process while we look at the technology so that we can actually solve the economic things that the company needs us to solve. And when you can get all that stuff aligned, magic can happen.

And when that stuff’s misaligned, I think that’s why we end up with agile transformation on one side doing its thing. You got the technology modernization, extraction, refactoring stuff on the other side. And I think if we can align it around the economic value prop that gets delivered incrementally and iteratively, bring the business and IT together to figure out what to extract and modernize, whether it be on business process side or whether it be on the technology side, and then organize around it and make it accountable and make it measurable on the backside. That’s the secret sauce in it.