The Question That Keeps Recurring
Building a design systems framework for data platform products, I keep running into the same architectural decision: should the framework distinguish products from services - and if so, how?
Working group discussions have circled this question repeatedly. When we map how platform products relate to patient pathways, we find ourselves using both terms - sometimes interchangeably, sometimes with important distinctions. A validation service uses a data linkage product; or is the data linkage tool itself a service? When a clinician validates a waiting list, are they using a product or consuming a service?
My current framework draft treats a service as the end-to-end user journey delivering an outcome, and a product as a reusable component providing outputs or capabilities consumed by multiple services. But Majid Iqbal's Thinking in Services (Iqbal, 2018) - which I have been working through as part of my research - does not make this distinction at all. For Iqbal, a service simply is the complete 16x frame: the interlocking promises between demand and supply across performance and affordance. There is no separate "product" concept because the service encompasses everything needed to deliver value.
So: is the distinction worth keeping? And what does the answer mean for how we structure a design system for platform services?
The Bank of England Study
Jonathan Rez, Amy Lynch, and Sandeep Achanta from the Bank of England recently tackled this question head-on (Rez, Lynch and Achanta, 2025). They interviewed practitioners across service design and product management to find a shared definition, and their conclusion was sobering: there is no universally accepted framework for distinguishing products from services. Individual definitions vary based on career history, organisational context, and framework exposure - ITIL, GDS, Scrum, and PRINCE2 all define these terms differently.
Rather than chase a universal definition, they propose that organisations develop local frameworks appropriate to their context. They identify five models worth considering.
In the first, products and services work together as interdependent elements shaping a cohesive user experience - a smartphone works with cloud storage and streaming services, with teams retaining distinct ownership but operating in an integrated manner. In the second, services act as containers for products, wrapping around them to deliver value; a housing provider's rental property is wrapped by repairs, maintenance, and support services, such that products cannot stand alone without service support.
The third model treats products and services as independent within the same organisation, delivering value separately - an MRI scanner and the financing arrangement for it have no ongoing integration need. The fourth model places the boundary at user perception: what the organisation calls a "product" the user may experience as a "service", and the organisation loses control over how offerings are perceived. The fifth is journey-oriented, where products and services hand off along a user journey; a patient's diagnostic journey involves GP services, hospital services, wearable devices, and apps, all requiring careful coordination regardless of how they are classified.
The Servitisation Perspective
The distinction becomes more complex when viewed through the lens of servitisation - the movement from product-focused to service-focused business models. Overkamp and Holmlid (2017) note that servitisation involves "a shift from a value-in-exchange perspective to a value-in-use perspective, where a consumer does not necessarily own the product but pays for access to its functionality". This suggests the product/service distinction may be historically contingent - an artefact of industrial-age thinking where tangible goods were primary. In a servitised economy, the distinction becomes less meaningful because everything is experienced as service.
Vargo and Lusch's service-dominant logic (Vargo and Lusch, 2004; 2007) makes this explicit: "service" in the singular - the application of knowledge and skills - is the fundamental basis of all exchange. Products are simply "distribution mechanisms for service provision", frozen capabilities waiting to be activated through use.
Iqbal's Alternative: No Distinction Needed
Iqbal's framework sidesteps the problem entirely. His 16 elements span both what others might call "products" and "services". Artefacts are things with shortcomings that create demand for performance; capabilities are things with skills that create supply for performance; resources are things with surpluses that create supply for affordance; and events are things with shortfalls that create demand for affordance. "Things" here can be either tangible products or intangible services - the framework does not care. What matters is the function the thing plays in the service system: does it create demand or supply? Does it enable performance or affordance?
This functional rather than categorical approach may be more useful for service design, where the goal is to understand how value is created rather than what category something belongs to.
Arguments For Keeping the Distinction
Despite the theoretical elegance of collapsing the distinction, there are practical reasons to maintain it - particularly in large-scale public service contexts. Organisational reality matters: platform programmes do have product teams with product managers, roadmaps, backlogs, and delivery accountability, and a design system working group that operates across products. A framework that ignores this structure creates translation overhead for teams who already have well-established working patterns.
Reusability is another consideration. Platform products in Pope's (2024) "Platformland" sense are explicitly designed for reuse across multiple services and trusts; a data linkage product can support waiting list validation, cancer pathway management, and elective recovery. This reusability pattern is worth naming and structuring within a framework. Ownership and accountability also favour the distinction: product managers own roadmaps while service owners in trusts own patient journeys, and when something goes wrong it matters whether the issue is a product defect or a service design failure. Finally, lifecycle differences are practically significant - platform products can be versioned, updated, and enhanced independently of the clinical pathways they support, and this independence has governance implications.
Arguments Against
The case against is equally compelling. As Rez, Lynch and Achanta (2025) note, "for users, this distinction is often irrelevant". A ward clerk validating a waiting list does not care whether the tool they are using is classified as a "product" or a "service" - they care whether it helps them do their job. Boundary fuzziness compounds the problem: is a notification capability a product, a service, a component, or a capability? The answer usually depends on organisational structure rather than any intrinsic property of the thing itself.
Adding product as a first-class concept alongside service also creates framework complexity - ambiguity about which layer things belong to, complicating system mapping. And the theoretical weakness is hard to ignore: neither service-dominant logic nor Iqbal's service grammar requires this distinction. If the strongest theoretical frameworks do not need it, perhaps it is not fundamental.
A Tentative Position
I am increasingly inclined toward a contextual approach following Rez, Lynch and Achanta (2025). For strategic service design, it seems right to collapse the distinction and focus on services as user journeys - patient pathways, clinical workflows - letting "products" be implementation detail. For platform architecture, maintaining the distinction has practical value: products-as-platforms, Pope's (2024) building blocks, remain a useful architectural pattern for programme teams. And for system mapping, the distinction should be used when it exists in the organisation but not imposed where it does not; the goal is to map what is there, not what should be there.
The key insight from the Bank of England work is that definitional debates are often proxy wars for organisational power - who owns what, who gets to set priorities. The product/service distinction frequently encodes political settlements rather than ontological truths. Perhaps the more honest framing is simply that there are things that create value, and there are journeys that orchestrate those things toward outcomes; whether you call the things "products" and the journeys "services" is a matter of local convention.
Implications for the Design System
If the distinction is contextual rather than fundamental, the design system framework needs to support both framings, documenting components in ways that work whether teams think in products or services. Transaction patterns and capability patterns cut across the product/service divide, which suggests focusing on patterns rather than categories. And when documenting how components support workflows, the framework should use whatever language the implementing team actually uses rather than enforcing a distinction that may not map to their reality.
The service patterns hierarchy I have been sketching may need revisiting in light of this. If "product" is not a fundamental layer, perhaps "capability pattern" does more work than I had realised - and Iqbal's functional categories (artefacts, capabilities, resources, events) may offer a more theoretically grounded vocabulary than the product/service binary.
References
Iqbal, M. (2018). Thinking in Services: Encoding and Expressing Strategy Through Design. BIS Publishers.
Overkamp, T. and Holmlid, S. (2017). Implementation during design: developing understanding about service realisation before implementation. The Design Journal, 20(sup1), S4409-S4421.
Pope, R. (2024). Platformland: An Anatomy of Next-Generation Public Services. London Publishing Partnership.
Rez, J., Lynch, A. and Achanta, S. (2025). Services are containers for products. Touchpoint: The Journal of Service Design, 14(2).
Vargo, S. L. and Lusch, R. F. (2004). Evolving to a new dominant logic for marketing. Journal of Marketing, 68(1), 1-17.
Vargo, S. L. and Lusch, R. F. (2007). Service-dominant logic: continuing the evolution. Journal of the Academy of Marketing Science, 36(1), 1-10.