Your Customers Don't Need Another Platform. They Need Your Capabilities.

Many organizations repeatedly solve similar problems for different customers, business units, or markets. Each engagement produces something valuable, but much of that value remains trapped in the individual solution.

A composable product strategy changes the unit of investment. Instead of treating every solution as a separate deliverable, organizations identify the underlying capabilities that can be reused, combined, and extended.

The result is not necessarily a software platform. It can be a portfolio of technology, data, intelligence, workflows, and expertise that supports many different solutions.

The problem with solving the same problem twice

This distinction matters particularly for services businesses. Agencies, consultancies, technology integrators, and specialized service providers develop substantial expertise through client engagements. They solve difficult problems, build integrations, develop methods, establish measurement approaches, and refine operating processes. Yet much of that knowledge remains embedded in individual projects, teams, or customer implementations.

The organization gains experience, but it doesn’t always build assets that make the next engagement fundamentally more efficient or valuable.

There is a difference between becoming better at delivering projects and developing a system that becomes better with every project delivered. The first scales primarily through people and experience. The second creates opportunities to scale through reusable capabilities, shared infrastructure, and accumulated organizational knowledge.

The question is no longer simply how to deliver the next solution. It is how much of that solution should become part of a growing portfolio of capabilities.

The market is moving toward composability

Composable architecture is not new, but its relevance is expanding beyond software engineering into enterprise strategy, product management, and AI adoption.

Gartner’s 2024 research on composable product roadmaps argues that modular product design should serve both provider and customer business strategies. It connects composability with customer flexibility, component autonomy, and support for additional use cases at lower incremental engineering cost.¹

That represents an important shift. Modularity is no longer valuable only because it makes systems easier to maintain. It can influence how organizations invest, how products evolve, and how customers consume capabilities.

More recent research suggests that architectural maturity may be particularly relevant to AI.

The MACH Alliance’s 2026 Enterprise Technology Report surveyed 600 enterprise technology decision-makers across seven markets. Among organizations with fully implemented, scaled composable architectures, 78% reported clear evidence of return on AI investments. Among organizations in the early planning stages, that figure was 13%.²

That is a substantial difference, but it is not proof that composability alone produces better AI outcomes. Organizations with mature architectures may also have stronger engineering practices, governance, investment capacity, and operational discipline. The finding establishes an association between architectural maturity and reported AI results, not causation.

Nevertheless, the pattern supports a broader argument: as organizations introduce more data-intensive applications, automated workflows, and AI capabilities, their ability to connect and coordinate existing systems becomes increasingly important.

The direction is also visible in customer data technology. The CDP Institute’s February 2026 industry update reported 7.8% growth among composable, warehouse-native customer data platform vendors, compared with 3.3% among delivery CDPs. More than a quarter of CDPs supported warehouse-centric architecture.³

These findings do not establish that every industry is abandoning integrated platforms. They do, however, show growing commercial activity around architectures that allow capabilities to work with existing customer technology foundations.

For services businesses, this creates an opportunity to rethink not only what they build, but how they deliver value.

Maybe we need to rethink what we call a product

I’ve increasingly questioned whether we should continue calling everything a product. And yes, as a product leader myself, the irony isn’t lost on me.

The term isn’t technically incorrect, but it often encourages us to imagine something more rigid: a defined solution, packaged around a particular use case, with relatively fixed boundaries. That interpretation can shape how we identify opportunities, allocate investments, and measure success.

What if we started thinking in terms of capabilities instead?

A capability might be an automation, an AI agent, a predictive model, an integration, or a workflow. It might operate independently or become part of something larger. Its value isn’t necessarily limited to a single interface, customer, or use case.

This changes the questions we ask. Instead of starting with “What product should we build next?” we can ask, “What capability is missing? What could it enable? Where else could it create value?”

Consider an AI agent developed to automate a specific customer workflow. In a conventional product model, success might be measured by how effectively it solves that workflow. Through a capability lens, we also consider the value created beyond its immediate purpose: the knowledge accumulated, the processes improved, the data and intelligence generated, and the dependencies or inefficiencies uncovered along the way. Its underlying reasoning, integrations, orchestration, and governance mechanisms may also support entirely different applications.

The original solution still matters, but it is no longer the only source of value created by the investment, nor the limit of what that investment could enable.

This isn’t about abandoning product management. It’s about applying product thinking to a more flexible unit of value. Capabilities still require ownership, prioritization, performance measurement, and continuous improvement. What changes is how we define their boundaries, recognize their potential, and manage the value they create.

Perhaps this also helps explain why the relevance of traditional product management is increasingly being questioned in the age of AI. Gartner has gone as far as declaring the generalist product manager obsolete, arguing that AI is changing the responsibilities and operating structures required to manage products effectively.⁴

Yet the underlying need for product thinking hasn’t disappeared. If anything, as AI makes it easier to build solutions, the harder questions become what is worth building, which capabilities should be shared, how they work together, and where they can create the greatest value.

Research from Productboard reinforces this shift. In a 2025 survey of 100 product leaders, 75% expected deeper AI and data fluency to define the evolution of product management, while 55% anticipated greater ownership of strategy and business outcomes.⁵

The evidence suggests a change in emphasis, not the disappearance of the discipline. Product management increasingly needs to connect technical possibilities with business strategy, customer context, and measurable outcomes.

Maybe product management isn’t becoming obsolete. Maybe our definition of what constitutes a product, and what it means to manage one, needs to evolve. But the strategic thinking, judgment, and accountability at the heart of product management are more essential than ever.

Product-led does not have to mean software-led

The conventional path toward productization often begins with an understandable ambition: identify a repeatable service, standardize it, and eventually turn it into a software product.

That approach can work, but it is no longer an exclusive path.

Some forms of specialized expertise are valuable precisely because they combine technology with judgment, context, and operational knowledge. A measurement framework, for example, may involve statistical methods, data models, governance rules, experiment design, and decision processes. Converting the entire capability into standalone software may not be practical or desirable.

A product-led approach can instead focus on making the underlying capability repeatable, configurable, measurable, and continuously improvable.

Consider an analytics and intelligence provider serving several industries. Different customers may require different solutions, but many of those solutions draw from common foundations: data integration, audience segmentation, predictive modeling, experimentation, decisioning, and activation.

Rather than rebuilding each foundation independently, the provider can develop a portfolio of capabilities that can be assembled around specific customer needs.

The product is not necessarily the final solution. The product may be the capability that makes many solutions possible.

Perhaps this is where product-led services begin to evolve toward a capability-led model. One that retains the strategic discipline of product management but shifts the focus of investment from individual solutions to reusable capabilities and the broader value they generate.

For services businesses, the implication is significant. Product leadership can extend beyond managing software applications into managing the reusable capabilities, methods, and technical foundations through which expertise is delivered.

This also changes how success is measured. A capability should be evaluated not only by the outcome it delivers in one engagement, but also by the value it generates across the broader portfolio, the effort it eliminates, and the new opportunities it makes possible.

Capability-to-Customer: bringing expertise to the customer’s ecosystem

Composability addresses how capabilities are built and managed. It does not, by itself, determine how they should reach the customer.

This is where I see an opportunity for a complementary principle: Capability-to-Customer (C2C).

The idea is straightforward. Instead of requiring customers to reorganize their technology, data, and workflows around a provider’s preferred ecosystem, providers bring adaptable capabilities to the environments customers already operate.

Think of it as a house call rather than asking every customer to visit the same facility.

The provider brings the expertise, tools, and specialized capabilities required to solve the problem. The customer brings its existing infrastructure, business context, operating processes, and governance requirements. The solution is assembled at the intersection of the two.

This does not mean every component must be installed within the customer’s infrastructure. Nor does it mean integration or migration will never be necessary. It means the starting point is the customer’s environment, not the provider’s preferred architecture.

A Capability-to-Customer approach should preserve several principles:

• Environmental flexibility. Capabilities can connect to different technology stacks, data environments, and operating models.
• Customer control. Customers retain appropriate ownership and governance over their data, business context, configurations, and resulting intelligence.
• Modular delivery. Components can be introduced, combined, extended, or replaced without unnecessarily rebuilding the entire solution.
• Clear ownership boundaries. Provider intellectual property and customer-owned assets remain distinguishable through architecture and contractual agreements.
• Continuous evolution. Providers improve capabilities over time while customers retain flexibility in how those capabilities are used.

This changes the nature of the provider-customer relationship.

Instead of competing primarily on the ability to control an entire technology environment, providers can compete on the quality of their expertise, the usefulness of their capabilities, and how effectively those capabilities adapt to changing business needs.

There is already a practical example of part of this approach in warehouse-native customer data platforms.

Hightouch’s composable CDP is designed to use a customer’s existing data warehouse as its foundation rather than requiring the customer to establish a separate, competing source of truth. Its offering adds audience management, identity resolution, activation, and orchestration capabilities around that existing data infrastructure.⁶

The example is not a complete implementation of the Capability-to-Customer philosophy. It illustrates the architectural principle of adapting specialized capabilities to an existing customer foundation rather than requiring the foundation to move to the provider.

Capability-to-Customer extends that principle beyond data architecture into a broader delivery philosophy for product-led services.

AI makes reusable intelligence more valuable

The opportunity becomes more interesting as analytics and AI capabilities mature.

Historically, specialized analytical work has often been delivered through individual projects: a forecasting model, an attribution analysis, a segmentation exercise, or an optimization initiative. Each may create substantial value, but the underlying methods and infrastructure are not always designed for reuse.

A composable approach makes it possible to separate the reusable intelligence capability from the customer-specific context in which it operates.

A predictive model, for example, may require different features, training data, constraints, and validation across customers. But the supporting processes for feature preparation, model evaluation, monitoring, governance, and deployment can potentially be reused.

Similarly, an AI decisioning capability may be adaptable across use cases while drawing on different customer data, objectives, eligible actions, and business rules.

The goal is not to assume that one model or agent can solve every problem. It is to identify which parts of the intelligence system can be standardized and which must remain contextual. This is particularly important because AI increases the need for coordination across data, applications, workflows, and governance.

In the MACH Alliance’s 2026 research, 98% of organizations with mature composable implementations reported being able to support AI at scale, compared with 33% of organizations in the early stages.² While these are self-reported findings, they reinforce the relationship between connected technical foundations and the ability to operationalize AI.

But reusable intelligence also introduces a critical governance question: what belongs to the provider, and what belongs to the customer?

The provider may own its methods, software, and general-purpose models, representing valuable intellectual property that can be commercialized across multiple customers and use cases. The customer may own its source data, business-specific configurations, and certain outputs or derived assets. For AI systems that learn from ongoing interactions, those boundaries become more complicated and must be addressed explicitly.

A credible Capability-to-Customer model cannot treat ownership and governance as secondary implementation details. They must be integral to capability design.

The economics of scaling expertise

The commercial appeal of composability is not simply that reusable components can reduce repeated work. It is that they can change how investment and value accumulate.

In a primarily bespoke delivery model, each engagement may require substantial new discovery, development, integration, and validation. Even when teams reuse their experience, delivery costs can remain closely tied to the amount of work required.

A capability-based model introduces a different investment structure.

The provider invests in shared foundations that can support multiple customer solutions. Those investments may include technical components, analytical methods, workflow automation, integration frameworks, quality controls, and operating processes.

If those capabilities are genuinely reusable, subsequent engagements may require less repeated development and can benefit from improvements made across the portfolio.

The opportunity is also supported by changes in how organizations think about monetizing data and expertise. Deloitte’s 2026 research describes commercial models built around packaged insights, recurring datasets, data-powered products, and repeatable expert services. Its Global Technology Leadership Study of 662 C-suite executives identifies driving business value from data and AI as the leading technology priority for 2026.⁷

The significance is not that every service must become a subscription or a software license. It is that specialized expertise can increasingly be delivered through repeatable offerings with clearer value propositions and more deliberate commercial models.

For a product-led services business, this can create several potential advantages: faster delivery, more consistent quality, improved margins over time, greater account expansion opportunities, and recurring revenue tied to ongoing capability improvement.

However, these outcomes are conditional. Reusable capabilities require upfront investment, maintenance, documentation, integration support, security controls, and product management. A component that is rarely reused may cost more to maintain than the custom solutions it was intended to replace.

The economic test is not whether a capability can be reused. It is whether the expected value of reuse exceeds the cost of building, adapting, governing, and maintaining it. A distinction that should guide portfolio investment.

There is also an indirect dimension to value creation. A capability developed for one purpose may improve organizational knowledge, expose operational inefficiencies, strengthen shared infrastructure, or enable additional capabilities that were not part of the original investment case.

This means a capability portfolio should account for three forms of value:

• The direct outcome delivered.
• The indirect benefits generated.
• The future opportunities enabled.

Not all of those benefits will be easy to quantify, and potential value should not be treated as realized return. But ignoring them entirely can lead organizations to undervalue foundational investments.

The leadership challenge: composability requires discipline

Building reusable components is only part of the problem, while deciding what deserves to become reusable is often the harder task.

Organizations can easily mistake common technical patterns for common business needs. Two solutions may use similar technology while serving very different workflows, constraints, and outcomes. Standardizing them too aggressively can reduce flexibility and create additional complexity.

This is where product leadership and systems thinking become essential: a capability portfolio needs to be managed as a connected system. Leaders must understand the business domains being served, the workflows that create value, the dependencies between components, and the tradeoffs between standardization and customization.

Several questions become central to investment decisions:

• Which problems recur frequently enough to justify a shared capability?
• Which components create value across multiple customer contexts?
• Where does customization improve the outcome, and where does it merely duplicate effort?
• What dependencies, governance requirements, and integration costs does reuse introduce?
• How will direct outcomes, indirect value, and future opportunities be measured?

These are product portfolio questions, not simply architecture decisions.

Gartner’s research on application composability identifies fragmented and duplicative application portfolios as barriers to business agility, recommending reusable application capability building blocks as part of modernization strategy.⁸

But composability can create fragmentation of its own if organizations develop too many overlapping components without clear ownership, standards, or investment priorities.

A portfolio of reusable capabilities needs more than a catalog, it needs orchestration. It needs coherent architecture, defined ownership, lifecycle management, interoperability standards, and evidence that the capabilities are creating value.

In practical terms, that means measuring not only the success of individual customer solutions but also the health of the capability portfolio itself.

Reuse frequency, integration effort, time to deployment, operating costs, adoption, reliability, and contribution to commercial outcomes all become useful signals.

The purpose is not to maximize reuse at any cost. It is to build a portfolio in which each investment strengthens the organization’s ability to solve meaningful problems.

A different future for product-led services

The future of product-led services may not be defined by how successfully services businesses convert their expertise into standalone software.

It may be defined by how effectively they transform specialized knowledge into capabilities that can be reused, combined, and continuously improved without forcing customers into a single provider-controlled ecosystem.

Composable product strategy changes the unit of investment, from isolated solutions to reusable capabilities.

Capability-to-Customer changes the delivery philosophy, from requiring customers to adapt to the provider’s environment toward bringing capabilities to the customer’s existing ecosystem.

Together, they suggest a model in which providers can scale their expertise while customers retain meaningful control over their technology, data, and business intelligence.

This is not an argument against platforms, proprietary technology, or custom services. Each can play an important role. It is an argument for being more deliberate about what gets built once, what gets adapted, what remains customer-specific, and where long-term value should reside.

The research suggests that the technical foundations for this model are becoming more relevant, particularly as organizations modernize applications, invest in integration, and scale AI. The broader application to services businesses remains an opportunity to develop and test, not a settled industry outcome.

For leaders, the challenge is to recognize that composability is more than a technology decision. It is a product investment strategy, a portfolio management discipline, and potentially a different way of creating commercial value.

And perhaps that is where product management’s next evolution lies: not simply managing more products, but understanding how individual capabilities, their dependencies, and their accumulated value contribute to a larger system.

Build for reuse. Compose for context. Deliver where the customer is.

Notes

1. Gartner. “Deliver Application Modernization With a Composable-Product Roadmap.” Gartner Research, 15 April 2024. Public abstract. https://www.gartner.com/en/documents/5351663
2. MACH Alliance. “MACH Alliance Research: 6X More Organizations Achieve AI ROI With a Composable Foundation.” Enterprise Technology Report, 18 February 2026. Based on a survey of 600 enterprise technology decision-makers across seven markets. https://machalliance.org/insights-hub/mach-alliance-research-6x-more-organizations-achieve-ai-roi-with-a-composable-foundation
3. Customer Data Platform Institute. “CDP Institute Releases New CDP Industry Update.” 12 February 2026. https://www.cdpinstitute.org/news/cdp-institute-releases-new-cdp-industry-update/
4. Gartner. “The End of the Generalist PM: Enable ProdOps to Scale GenAI & Agentic AI Success.” Gartner Research, 22 December 2025. Public abstract. https://www.gartner.com/en/documents/7302330
5. Productboard. “What 100 Product Leaders Told Us About Strategy, AI, and the New Product Org.” 21 May 2025. Survey of 100 product leaders from organizations with more than 500 employees. https://www.productboard.com/blog/latest-from-product-leaders-on-strategy-ai-and-product-orgs/
6. Hightouch. “Composable Customer Data Platform.” Official product documentation and architecture overview. https://hightouch.com/platform/composable-cdp
7. Deloitte. “Data Monetization Strategy Beyond the Headline Deal.” 2026. Includes findings from the 2026 Global Technology Leadership Study of 662 C-suite executives. https://www.deloitte.com/us/en/services/consulting/articles/data-monetization-strategy.html
8. Gartner. “How CIOs Use Application Composability to Unlock Business Agility.” Gartner Research, 23 August 2024. Public abstract. https://www.gartner.com/en/documents/5698319

A note on method: the Gartner references rely on publicly accessible research abstracts rather than full subscription reports. The MACH Alliance findings are self-reported survey responses and should not be read as causal evidence. Hightouch is included as an illustrative vendor example, not independent validation of the proposed Capability-to-Customer model. Capability-to-Customer is presented as an emerging strategic perspective, not an established or independently validated industry standard.