Most organizations are stuck funding projects — but the best product companies fund teams. In this video, we break down how to shift from a project-based model to a product-led approach using value streams, durable teams, and continuous funding so your business can adapt faster, reduce waste, and deliver better outcomes for customers.

If you’re a CEO, COO, or senior leader trying to modernize how your organization delivers value, this video gives you a practical framework for making the shift — covering everything from mapping your product landscape and organizing around customer jobs, to placing small bets, building feedback loops, and staying aligned to business goals.

Video Transcript

And so currently in a lot of organizations, what happens is we wrap up all those goals and those objectives and the desired outcomes and the timeline into a project. We say, “We’ve got a project, these are what we’re hoping the project’s going to achieve. We’re going to end up building these things. It’s going to cost X amount. It’s going to take Y amount of time to do it. ” And then we set up a bunch of teams around that project and aim to get going with the project as soon as possible. If we’re working a little bit of awards full thing, we might do a lot of discovery, spend a lot of time and design, really understand the requirements, and then we get from discovery into actually starting to build up our first MVP. And then we might think about how to scale from the MVP and start adding all sorts of features in there.

And we go through the whole product life cycle. The challenge with all this is that that project is now in place with a bunch of teams around it and it’s been funded and we get stuck having to follow that maybe for two, three years, five years, even as we’re learning things that might make us want to change. We might want to make trade-offs. We might want to increase the number of teams in it. We might want to split it up or decompose it into two smaller projects, but a lot of the structures that we set up and the way we’ve incentivized people in the system means that we follow down a path that isn’t really open to changing some of the fundamental decisions when we first scoped the project.

And so another way to do this is to think about having … Well, first we need to understand our product landscape and the current sets of products and services that we offer. So I spoke before about that work to understand our customer jobs and the pains and gains. And what we find is you have very distinct areas where it’s these sets of customer jobs that we’re trying to support, and it’s these sets of product services that are going to support those customer jobs. And we might call that this little vertical slice, this little encapsulated value stream where we are going to work and build these sets of product services and they’re going to help these sets of customer jobs. And as much as possible, we want that to be encapsulated away from, say, another vertical slice set around a very different, distinct set of customer jobs that they’re enabling.

And you can have that depending on the scale, huge number of value streams. And this is where you can get a lot of overlap with looking at business architecture and capabilities and how you might look at the landscape of products and services across a whole company. Or if you’re more technically minded, you might look at domain-driven design and do the same thing. But ultimately, we’re trying to encapsulate a particular value proposition here, and we’re trying to say that we want these sets of teams, this set of skillsets, oriented towards resolving these pain points and gains for these users and their particular jobs. Now, it’s not distinct users. It might be the users who want to do X and Y. That’s what these teams are oriented towards. That same set of users might want to do Z over here, and you might have another set of teams helping them with that.

So it’s not customers and distinct customers to every single vertical slice. It’s the actual distinct jobs for a set of customers. Now, having got that landscape and that picture, the way you can approach this is to say, “We are going to fund those sets of teams.” It might be a group of AT people, it might be a portfolio team and two product teams, and then there’s four, five, six, maybe delivery teams in a particular area. That’s the sort of scale we’re looking at often when we’re trying to encapsulate because it’s the right number of people to be able to have the communications, to be able to get really good at solving for that particular set of problems that their users and their jobs they’re trying to achieve what they have. And so we fund that set of teams and they’re durable. They exist, they collaborate, they get really good at understanding their customers there.

We try as much as possible to minimize dependencies of that group of teams with teams working to resolve pain points and create gains for another set of customer jobs. And when we allocate like that, what you do is you try and empower and give agency to that portfolio team to go, “Look, you know what the broad business goals are that we’re trying to achieve. You know what our targets are. You might have some North Star metrics, you might have certain top level revenue that you’re trying to achieve, you might have certain growth you’re trying to achieve or sort of minimal attrition you’re trying to avoid. You’re trying to avoid beyond a certain amount of attrition, et cetera.” But that team, that portfolio team for this slice of the organization knows how many people it has and knows what capacity they have and what they can get done.

And so when they think about the problems that they can solve, they can think about those problems in the right sort of scale of box that they can actually come up with the right sized opportunities and the right bets to invest in. And as much as possible, we’re trying to make those bets really small. For a lot of product organizations, it’s really important that we get to a point of seeing the amount of implicit assumptions. Loads of people have to, every time you join an organization and park on boarding, have to do your unconscious bias type of training and make sure that you don’t have unconscious bias. And one of the important bits there is everybody has unconscious bias. Well, in every organization, we have assumptions. It’s what we have to do to understand the world around us is we have to accept that we are going to make some assumptions because of the sheer complexity of it.

It’s the only way to be effective and move forward. So there are always going to be implicit assumptions, but accepting the risks and accepting that we’ve done sufficient amount of discovery to understand our market and customers, we can select opportunities and think about the experiments and the small bets we can place that we can try and meet quickly, release something, test it with our customers, get something in their hands and see if it actually solved the problems they had or created gains for them and decide, should we do more of that? Did we solve that particular job they were trying to do or at least enough of that and now solve another type of job that they have to get done? Or should we actually make it even more powerful what our product does for them so they can go even more quickly or make even more money from the products and services that we have provided to them?

And so you’re trying to flow these small bets through a portfolio and you’re learning and you’re creating these feedback loops. And now, because you’re funded and you’re funded for this capacity, you can choose to shift where your capacity is oriented. You still are accountable to business outcomes. You still have to make money for the company. So that feedback is all about, are we improving outcomes for our customers and improving outcomes for the business? And within those two big measures of success, you’re making decisions about, are the current thing problems we’re looking to solve going to continue us in the right trajectory? Are we going to keep on making more money and creating the right business outcomes?

 

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.

AI adoption is an investment decision. Like any investment, it needs to be evaluated on its returns, its risks, and its alternatives. The question is not whether AI is impressive. It is whether AI creates measurable value for your organization, and what happens if you do not pursue it.

The Current State of AI in Business

AI has moved past the experimentation phase for many organizations. Companies across industries are deploying AI in production for customer support, code generation, document processing, data analysis, and workflow automation. This is not speculative. It is operational.

What has changed in the last two years:

• Capability. Models can now handle complex reasoning, nuanced language, code generation, and multi-step workflows. The gap between AI output and human output has narrowed for many routine tasks.
• Accessibility. Using AI no longer requires a machine learning team. API-based models can be integrated by any software development team. Pre-built tools handle common use cases out of the box.
• Cost. The cost per task has dropped by orders of magnitude. Tasks that cost dollars per interaction two years ago now cost fractions of a cent.
• Reliability. With proper system design (RAG, guardrails, human oversight), AI systems can meet production reliability standards.

The barrier to entry is lower than it has ever been. This is both an opportunity and a competitive concern.

Where AI Creates Value

AI creates business value in four primary areas: 

1. Reducing Cost Per Task

AI handles routine, repetitive tasks at a fraction of the cost of human labor. This is not about replacing people. It is about redirecting human effort toward work that requires judgment, creativity, and relationship management.

Examples:

• A customer support team handles 5,000 tickets per month. AI resolves 60% of routine inquiries (password resets, order status, FAQ questions) automatically. The team now focuses on complex cases that require human judgment, improving resolution quality while handling higher volume.
• A legal team reviews 500 contracts per quarter. AI extracts key terms, flags anomalies, and generates summaries. Lawyers spend time on analysis and negotiation instead of reading boilerplate.
• A development team uses AI-assisted coding to generate boilerplate, write tests, and handle routine code changes. Developer time shifts toward architecture, design, and complex problem-solving.

2. Accelerating Time to Output

AI compresses the time from question to answer, from request to delivery, from data to insight.

Examples:

• A research analyst takes 4 hours to compile a market analysis from multiple sources. An AI-assisted workflow produces a first draft in 15 minutes, which the analyst refines and validates in an hour.
• A sales team waits 48 hours for a custom proposal. AI generates a first draft from the CRM data and previous proposals in minutes. The sales engineer reviews and customizes in an hour.
• An engineering team takes 2 weeks to onboard a new developer to a codebase. An AI assistant that understands the codebase answers questions and explains patterns immediately, reducing onboarding to days.

3. Unlocking Insights from Existing Data

Most organizations sit on data they cannot use because querying it requires specialized skills or takes too long to be practical.

Examples:

• A company has 10 years of customer support transcripts. AI analyzes them to identify recurring issues, product friction points, and feature requests that no one had the time to surface manually.
• A healthcare provider has thousands of clinical notes. AI extracts structured data, identifies trends, and flags patterns that inform treatment protocols.
• An e-commerce company has millions of product reviews. AI clusters them by topic, sentiment, and actionability, producing insights that drive product roadmap decisions.

4. Creating New Capabilities

AI enables products and services that were not feasible before.

Examples:

• Personalized customer experiences at scale. AI tailors recommendations, communications, and support to individual users in ways that manual approaches cannot match.
• Natural language interfaces to complex systems. Users query databases, configure settings, and generate reports by describing what they want in plain language.
• Automated quality assurance that checks work product against standards, guidelines, and historical patterns.

The Cost of Not Adopting

The business case for AI is not only about the value of adopting. It is also about the cost of not adopting.

Competitive Disadvantage

Organizations that adopt AI effectively are already realizing benefits. Their cost structures are lower, their response times are faster, and their ability to scale is greater. Every month of delay widens the gap.

This is not hypothetical. Companies in customer support, software development, financial services, and healthcare are reporting measurable improvements from AI adoption. Competitors who delay will face a structural disadvantage in cost and speed. 

Talent Expectations

Developers, analysts, and knowledge workers increasingly expect AI tools in their workflow. Organizations that do not provide them will struggle to attract and retain talent. This is already happening in software development, where AI-assisted coding tools have become table stakes for competitive hiring.

Compounding Knowledge

AI adoption is a learning process. Organizations that start now build institutional knowledge about what works, what does not, and how to apply AI effectively in their specific context. This knowledge compounds over time. Organizations that wait will need to learn those same lessons later, against competitors who have already learned them.

Measuring ROI

AI investments should be measured like any other business investment. Here is a framework:

Direct Cost Savings

Measure the cost of performing a task before and after AI:

Metric	Before AI	After AI
Cost per support ticket resolved	$15–25	$2–5 (AI-resolved)
Hours per contract review	4–6 hours	1–2 hours
Time to generate first draft (reports, proposals)	3–8 hours	0.5–1 hour
Developer time on boilerplate code	30–40% of coding time	5–10%

Revenue Impact

Harder to measure directly, but real:

• Faster sales cycle from quicker proposal turnaround
• Higher customer satisfaction from faster support response
• More features shipped per sprint from AI-assisted development
• New products and services enabled by AI capabilities

Implementation Cost

Be honest about the investment required:

• API costs:Predictable, usage-based. Start small and scale.
• Integration effort:Engineering time to integrate AI into existing systems. Typically, 2-8 weeks for an initial use case.
• Training and change management:Time for teams to learn new workflows. Often underestimated.
• Ongoing maintenance:Prompt tuning, RAG pipeline updates, monitoring. Budget for continuous improvement.

Payback Period

For most initial AI implementations, the payback period is measured in weeks to months, not years. A customer support AI that handles 1,000 routine tickets per month at $2 per ticket instead of $20 saves $18,000 per month. If implementation costs $50,000, the payback is under three months.

Practical Adoption Path

Phase 1: Proof of Value (1-2 months)

Pick one use case with clear, measurable impact. Keep scope small. Prove that AI can deliver value in your specific context.

Good first use cases:

• Internal knowledge base Q&A (employees asking questions about company policies, processes, or documentation)
• Customer support triage and routing
• Document summarization or data extraction
• Code review or test generation assistance

Success criteria: Measurable improvement in cost, speed, or quality. User adoption and positive feedback.

Phase 2: Production Deployment (2-4 months)

Harden the proof of concept. Add monitoring, error handling, and feedback loops. Deploy to a broader user base.

Key activities:

• Define quality metrics and monitoring
• Build feedback mechanisms for users to flag issues
• Establish prompt management and version control
• Train users on effective interaction with AI tools

Phase 3: Expansion (4-12 months)

Apply the lessons from the first use case to additional areas. Build internal capability and processes for AI adoption.

Key activities:

• Identify the next 3-5 use cases based on Phase 1 learnings
• Establish an AI governance framework (data handling, model selection, risk management)
• Build or hire AI engineering capability
• Create shared infrastructure (RAG pipelines, prompt libraries, evaluation frameworks)

Phase 4: Strategic Integration (12+ months)

AI becomes part of how the organization operates, not a standalone initiative.

Indicators of maturity:

• AI is considered in product and process design decisions by default
• Teams have the skills and tools to implement AI solutions independently
• AI costs are understood and managed as operational expense
• Feedback loops continuously improve AI system quality

Addressing Common Concerns

AI will replace our workers.

AI augments human capability. It handles routine tasks so people can focus on judgment, creativity, and relationship management. Organizations that adopt AI typically redeploy staff to higher-value work, not reduce headcount. The teams that use AI effectively handle more volume at higher quality, not fewer people doing the same work.

Our data is too sensitive for AI.

Data sensitivity is a real concern with real solutions. Options include:

• On-premises deployment of open-source models (data never leaves your network)
• Enterprise agreements with model providers that include data privacy guarantees
• Architecture that keeps sensitive data out of the model (use AI for reasoning, not data storage)
• Regulated industries (healthcare, finance, legal) are already using AI with appropriate safeguards. The question is not whether it is possible, but how to do it correctly.

We tried AI and it didn’t work.

Early experiments often fail because of unrealistic expectations, poor use case selection, or inadequate system design. Common failure patterns:

• Testing AI on the hardest, most ambiguous tasks instead of starting with clear, routine ones
• Evaluating raw model output instead of building a system (RAG, prompting, guardrails) around it
• Expecting AI to work perfectly without iteration and tuning

The technology has also improved significantly. A use case that failed a year ago might succeed with current models and approaches.

We don’t have the technical expertise.

The barrier to entry has dropped significantly. API-based AI integration is within reach of any development team. Start with pre-built tools and managed services. Build internal expertise through the first project, not before it.

Closing Thoughts

AI adoption is not a technology decision. It is a business decision about competitive positioning, operational efficiency, and organizational capability. The technology is ready. The tooling is accessible. The economics are favorable.

The risk is not that AI will not work. For well-scoped use cases with proper implementation, it demonstrably does. The risk is waiting. Every month of delay is a month competitors are gaining experience, reducing costs, and building capability that compounds over time.

Start small. Prove value on one use case. Measure the results. Then expand.

The organizations that will lead in the next decade are the ones building AI competency now, not the ones that waited for the technology to be perfect. It will never be perfect. It is already good enough to deliver measurable value. The question is whether your organization captures that value or cedes it to competitors who started sooner.

 

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 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.