Introduction to Enterprise Concepts – A Shared Language for Better Communication

Defining concepts is essential for business development so that everyone has a common understanding of what is actually being discussed – when developing an enterprise.

What are Enterprise Concepts?

Enterprise concepts are definitions of things – a shared vocabulary, a common terminology, a common glossary for the enterprise. Enterprise concepts are simply names given to things in an enterprise. They are definitions of what we mean when we say product, service, capability, or process, etc. They are agreed meanings.

Why are they important?

Because development often suffers when people use the same words but mean different things, or use different words for the same thing. When meanings are unclear, communication weakens. When communication weakens, cooperation suffers. And when cooperation suffers, the enterprise suffers.

Clear concepts create shared understanding.
Shared understanding improves communication.
Better communication enables better cooperation.
Better cooperation builds better enterprises.

When we agree on what we mean, we can think more clearly together. And when we think more clearly together, we develop the enterprise more effectively.

When we speak the same language, we work better together. Using a common terminology is vital because:

It creates clarity: We avoid the confusion and ‘translation errors’, lost in translation, that often happen between people from different background or expertise.
It builds trust: When everyone from leadership to developers uses the same names for the same things, we form a shared understanding of everything.

How to use them in practice?

Enterprise concepts are practical tools that we use every day to design and develop a better enterprise.

Planning Changes. When we start a new concept, project, transition program, or initiative, we define the desired requirements, descriptions or outcomes using these shared terms.

In practice, enterprise concepts are used to build a common conceptual model of the enterprise. The same names are used for the same things across disciplines and stakeholders. Differences between ideas become clearer, overlaps are reduced, and conversations become simpler, shorter, and more focused.

Enterprise concepts serve as a shared vocabulary in discussions, documentation, models, and daily development work. They help stakeholders think and talk about the enterprise in the same way. Concepts themselves do not change the enterprise. Their value lies in enabling clearer shared understanding – and clearer understanding helps people develop the enterprise better, together.

Design & Development works better when we use the same words with the same meanings.

An example of a common conceptual model is shown below.

List of Enterprise Concepts

Enterprise concepts can be viewed from several complementary perspectives. To make them easier to understand and use, the concepts are presented here in six groups. Each group highlights a different aspect of the enterprise and how it works.

Identity Concepts
- Why the enterprise exists and where it is heading. This perspective focuses on the enterprise’s purpose, direction, strategic aspect, and long-term intentions.
Experience Concepts
- What people need, what they do, and what they experience when interacting with the enterprise. The perspective of customers and other stakeholders.
Architecture Concepts
- How the enterprise is built and how it operates. This includes the structure and behavior of operations: capabilities, processes, assets, and the way work is carried out.
Organisation and Management Concepts
- How people are organised and how the enterprise is led. This includes roles, teams, governance, and the cultural aspects of how people work together.
Development Concepts
- How the enterprise and its operations are improved and changed. This perspective focuses on design, development work, and the initiatives that move the enterprise forward.
General Concepts
- What are the common situations, changes, or conditions in the enterprise or its environment?
  These are basic concepts used to describe general things that are not tied to one specific perspective.

Together, these groups provide a simple way to organise and understand the key concepts used to describe, design and develop the enterprise.

The ***Enterprise Wheel*** can be used as an analysis tool for identifying the enterprise concepts.

1. Identity Concepts

Why the enterprise exists and where it is heading. This perspective focuses on the enterprise’s purpose, direction, strategic aspect, and long-term intentions.

Concept	Description	Notes	EDGY-element
Purpose	The fundamental reason for an enterprise’s existence.	Purpose answers the question: Why do we exist?	Purpose
Mission	The daily actions taken to fulfill the purpose.	Mission is about the present: What do we do?	Purpose
Vision	An inspiring description of a future state.	Vision is about the future: Where are we going?	Purpose
Strategy	High-level plan and choices to achieve goals.	Strategy answers: How will we win and reach our goals? Scenarios..	Story
Brand	The set of promises and perceptions.	Brand is the identity as perceived by others.	Brand
Principle	A guiding rule for decision making.	Principles guide behavior and choices in all situations.	Content
Value	Benefit or importance created for people. Organisational value guiding organisational culture.	Value is both a belief and an outcome (benefit).	Content
Identity	The core essence and personality of the enterprise.	Identity defines who the enterprise is in relation to others.	Story / Brand
Content	Refers to information and data that is communicated to people.	Can be used to describe values, principles, and change programs, projects, concepts.

2. Experience Concepts

What people need, what they do, and what they experience when interacting with the enterprise. The perspective of customers and other stakeholders.

Concept	Description	Notes	EDGY-element
Customer	A person who buys or uses offerings.	The customer is the focal point of value creation.	People
Customer Journey	The flow of events from the person’s perspective.	Journeys focus on the flow of events from the person’s perspective.	Journey
Experience	Subjective perception of an interaction.	Experience is described using journeys and steps.	Journey
Customer Experience (CX)	Total perception of all interactions.	Measured across multiple touchpoints and channels.	Journey
Employee Experience	Perception an employee has of their workplace.	Critical for operational efficiency and culture.	Journey
Customer Insight	Deep understanding of customer behavior.	Insight is the foundation for design and innovation.	Content
Channel	A medium where interaction occurs.	Channels are the “where” of the experience.	Channel
Touchpoint	A specific moment of interaction.	Touchpoints are building blocks between channels and journeys.	Task / Channel
Customer Need	A requirement felt by a customer.	The starting point for “Outside-In” development.	Outcome
Task	Something a person wants to get done.	Tasks represent the functional side of a person’s intent.	Task
JTBD	The job a customer “hires” a product for.	Focuses on the underlying goal rather than the feature.	Task
Need	A gap that motivates action.	Needs are the “why” behind human action.	Outcome
Demand	A request or desire for an offering.	Demand drives the activity of the enterprise.	Outcome
Product	A tangible or digital artifact that the customer owns or uses.	Products are what we offer to create value.	Product
Service	Value creation for a customer without transfer of ownership; enables the desired outcome. Facilitating outcomes customers want.	Services can be composed of several products and activities.	Product
Offering	The sum of offerings of an enterprise.	Offering represents the value proposition.	Product
Cust. Value	Perception of benefit for the customer.	Value is defined by the customer, not the enterprise.	Outcome
Pain	A negative experience or obstacle.	Pains are negative experiences that need to be relieved.	Outcome
Gain	A positive benefit sought by the person.	Gains are positive outcomes that are being sought.	Outcome
User	A person who interacts with a solution.	Users can be customers, employees, or partners.	People
User Role	A specific role in a system context.	Defines permissions and tasks in a software.	People
Use Case	Steps to achieve a specific goal.	Defines the interaction between an actor and a system.	Task / Activity
User Story	Simple description from a user’s view.	Format: As a [role], I want [action], so that [benefit].	Task / Journey / Story

3. Architecture Concepts

How the enterprise is built and how it operates. This includes the structure and behavior of operations: capabilities, processes, assets, and the way work is carried out.

Concept	Description	Notes	EDGY-element
Capability	The ability to coordinate resources.	Capability combines people, processes, and assets.	Capability
Process	A repeatable sequence of activities.	Processes answer the question: How?	Process
Data	Raw facts and figures.	Data is a critical intangible asset.	Asset / Object
Information	Data processed into context.	Information adds context to raw data.	Content / Object
Knowledge	The ability to apply information.	Knowledge is the result of learning and experience.	Outcome
Data Management	Execution of data policies.	Ensures data assets are usable and protected.	Capability / Process
Application	Software supporting business.	Applications are technical assets.	Asset
IT Service	Technical service supporting business.	IT-service is a technical asset (often ITSM/ITIL).	Asset
Interface	A point where systems interact.	Interfaces enable communication between assets.	Asset / Task
API	Technical interface for software.	API: Application Programming Interface.	Asset
GUI	Visual interface for humans.	GUI: Graphical User Interface.	Asset
Component	A modular part of a larger system.	Components build up larger assets.	Object / Asset
Technology	Knowledge used for practical purposes.	Technology is an enabler for capabilities.	Asset
Facility	A physical place or building.	Facilities are physical assets.	Asset
Location	A geographical or logical place.	Locations define the spatial distribution of assets.	Object
Device	A physical technical tool.	Devices are material assets.	Asset
Resource	Any entity used to perform an activity.	Resources are consumed or used to produce value.	Object / People
Asset	A valuable resource owned.	Asset can be a resource (tangible or intangible).	Asset
Function	A specialised area of responsibility.	Functions are often organisational units like departments.	Capability
Structure	Arrangement of elements.	Structure provides the skeleton for behavior.	Object
Behavior	The way an enterprise acts.	Behavior is described by activities and processes.	Activity
Platform	A foundation for building solutions.	Platforms enable reuse and scalability.	Asset
COTS	Commercially available product.	COTS: Commercial Off-The-Shelf.	Asset
Entity	A distinct business object.	Entities form the core of the data model.	Object

4. Organisation and Management Concepts

How people are organised and how the enterprise is led. This includes roles, teams, governance, and the cultural aspects of how people work together.

Concept	Description	Notes	EDGY-element
Organisation	A structured group of people.	Organisations define the social structure.	Organisation
Ecosystem	An entity capable of performing actions.	Includes partners, competitors, and customers.	Organisation
Actor	Person or group affected by the enterprise.	Actors trigger activities and processes.	People / Organisation
Culture	Shared values and behaviors.	Culture is the “invisible” engine of the enterprise.	Story / Brand
Group	A collection of people.	Groups can be informal or formal.	Organisation
Team	Small group with a common goal.	Teams are the basic units of collaboration.	Organisation
Role	Defined set of responsibilities.	Roles link people to activities and processes.	People
Stakeholder	Person or group affected by enterprise.	Stakeholders can be internal or external.	People
Owner	Entity with ultimate responsibility.	Can refer to shareholders or asset owners.	People
Business Owner	Responsible for a business area.	Responsible for value and alignment.	People
Product Owner	Responsible for the product backlog.	Bridge between business needs and development.	People
Partner	External entity co-creating value.	Essential for modern networked enterprises.	People / Organisation
Business Model	The logic of how value is created.	Describes revenue streams and value delivery.	Story / Object
Op. Model	The day-to-day running of the enterprise.	The “engine room” of the enterprise.	Story / Object
Dev. Model	Methods used to change the enterprise.	Defines how innovation and design are done.	Story / Activity
Operations	The day-to-day running of enterprise.	Focus on efficiency and value delivery.	Activity / Process
Business Value	Value generated for the enterprise.	Often measured in financial or strategic terms.	Outcome
Benefit	A positive effect or advantage.	Benefits justify investments in development.	Outcome

5. Development Concepts

How the enterprise and its operations are improved and changed. This perspective focuses on design, development work, and the initiatives that move the enterprise forward.

Concept	Description	Notes	EDGY-element
Development	Activities aimed at changing enterprise.	Includes design, engineering, and innovation.	Activity
Initiative	A specific effort to achieve a goal / goals.	Initiatives are how we implement change. describes the change (such as a program, project, or concept). An initiative is the structural definition of the change effort, not the change activity itself, nor the final outcome or output.	Content
Program	Group of related projects managed.	Aimed at achieving strategic outcomes. Describes the change.	Content
Project	Temporary endeavor for a result.	Projects have a defined start, end, and scope. Describes the change.	Content
Concept	A high-level idea of a new solution. A design concept	Concept is mainly an Object, describing the future “what”. Describes the change.	Object
Backlog	A prioritised list of work to be done.	Backlogs manage the flow of development.	Object
Requirement	A condition or capability needed.	Requirements guide the design and engineering.	Outcome / Object
Action	A single step taken to advance change.	Actions are the smallest units of development.	Activity
Gap	Difference between current and target.	Gaps define the scope of development work.	Outcome
Transition	A controlled stage in moving.	Transitions allow for managed change.	Activity / Outcome
Need for Change	Necessity to alter the enterprise.	Often triggered by drivers or problems.	Outcome
Dev. Need	A specific need for new solutions.	Drives the creation of initiatives.	Outcome
Constraint	A factor that limits options for design.	Constraints define the boundaries of change.	Outcome

6. General Concepts

What are the common situations, changes, or conditions in the enterprise or its environment?
These are basic concepts used to describe general things that are not tied to one specific perspective.

Concept	Description	Notes	EDGY-element
Outcome	A measurable result of an action / activity.	Outcomes represent the “effects” or benefits we seek.	Outcome
Output	A direct product of an activity.	Outputs are used to achieve outcomes.	Object
Event	A state change in the environment.	Events trigger activities or mark milestones.	Outcome
Driver	Factor that creates motivation.	Drivers are the root causes of development.	Outcome
Activity	Any action or behavior.	Activities build up processes and journeys.	Activity
Object	Any structural or informational entity.	Objects are the “things” we have or use.	Object
Problem	An issue that needs to be addressed.	Problems often act as negative drivers.	Outcome
Challenge	A demanding situation to overcome.	Challenges drive innovation and improvement.	Outcome
Cause	A factor that produces an effect.	Understanding causes is key to diagnosis.	Outcome
Effect	A result or outcome of a cause.	Effects are what we observe or experience.	Outcome
Value Stream	End-to-end steps to deliver value.	Visualises how value is created across silos.	Activity / Process
Operational Val. Stream	Daily activities to serve customers.	The core value delivery mechanism.	Activity / Process
Development Val. Stream	Activities to build new solutions.	The pipeline for innovation and change.	Activity / Process
Value Chain	High-level view of value-adding activities.	Often used for strategic business analysis.	Activity / Process
Risk	Uncertainty that could impact goals.	Must be managed to ensure resilience.	Outcome
Threat	A potential cause of harm or loss.	Threats are the sources of many risks.	Outcome
Vulnerability	A weakness that can be exploited.	Reducing vulnerabilities increases security.	Outcome
Cost	Cost represents the consumption of resources (such as money, time, or effort) required to perform an activity or produce an output. In an Enterprise Design context, cost is often viewed as a constraint or a necessary investment that must be justified against the desired outcome.	Financial state change.	Outcome
State Change	Transition from one condition to another. E.g. in the case of a business entity such as Order.	Essential for understanding outcomes and events.	Outcome

EDGY Facet elements around the Enterprise Wheel (see more details from here: link).

The Enterprise Wheel is a practical tool for analysing the concepts of an enterprise.

The Enterprise Wheel can be used as a tool for identifying the elements of enterprise – the enterprise concepts.

Concepts that are often confused – commonly mixed-up terms

Here, we clarify concepts that are often confused, such as Service versus Product. This guide clarifies concepts that are often confused.

Capability vs. Process

Identifying the difference between Capabilities and Processes is one of the most common challenges in enterprise design and development. While they are closely related, they serve different purposes.

Here is a simple guide and a set of rules to help you distinguish them.

Key Definitions and differences between CApability and Process:

Capability (What):
- A “building block” of the business. It describes what an enterprise is able to do to create value.
- It is a stable package, business component, that combines people (with skills and comptences), processes, and assets (such as data, applications, technologies, devices, facilities) – all that belong together.
Process (How):
- A sequence of activities, steps to be taken, triggered by an event or input, producing specific output. It describes how work is performed over time to produce a specific output.
- Processes exist at different levels of an enterprise, ranging from the big picture end2end value streams to the smallest daily workflows of tasks. Understanding these levels helps us see how value is created and how work flows.

Rules of Thumb:

Rule	Capability	Process
Primary Question	What does the business do?	How do we do it? How is the work done?
Stability	Stable. Stays the same for years. Does not change even if the way of working changes.	Dynamic, flexible. Changes frequently when we improve or automate work.
State of Action	At Rest. The potential of the enterprise.	In Motion. The enterprise in action.
Nature	Abstract. A conceptual building block. High-level (strategic) business component.	Concrete. A visible sequence of steps. Task-oriented: Specific steps and flows.
Outcome vs Output	Produces a meaningful business Outcome (value). (e.g., “Invoices Paid”)	Produces a specific Output (product, document, deliverable, artifact, data) – based on specific input. (e.g., “PDF Invoice generated”)
Outsourcing	Independent. Can be outsourced as an autonomous, standalone unit (e.g., Payment, Invoicing).	Dependent. Part of a larger flow. Hard to outsource alone without the surrounding context (capability) and related processes (e.g. supporting).

Checkpoint Questions: Capability or Process?

Use these questions to test your concepts. If you answer “Yes” to the left column, it is likely a Capability.

Question	It is a Capability	It is a Process
Is it a “What” or a “How”?	What, it answers “What do we need to be able to do?”	How, it answers “How do we do what we do, how do we execute this specific flow of activities?”
Can you outsource it?	Yes, it is a self-contained unit with its own people, processes and assets.	No, it is just a sequence of steps within a larger unit.
Does the name remain the same if we automate it?	Yes. “Customer Billing” remains the same whether manual or digital.	Often No. The steps and the flow change completely.
Does it produce meaningful value to customer and/or to business?	Yes, it produces a meaningful business- or customer-related outcome (value, benefit, end result).	No, it produces a specific Output (product, deliverable)
Is it a group of things?	Yes. It groups people, processes and assets together – what belong together.	No. It is a specific path through those things / steps / activities.

Practical tests for identification:

The “Stability” Test
- Capability: If you upgrade your software from a manual spreadsheet to AI-driven automation, the Capability (e.g., Financial Reporting) stays the same.
- Process: The Process (the steps to create the report) changes completely.
The “Outsourcing” Test (The Black Box Test)
- Can it be outsourced as an indpendent, atutonomous whole? If yes, it’s a Capability.
- Capability: Can you ask a partner to “take care of this result” for you? If yes, it’s a Capability. You are buying the result, not the steps.
- Process: If you are asking someone to “follow these 5 steps in our system,” you are outsourcing a Process.
- Imagine you want to buy this as a service from a partner. If you can define it as a clear “black box” with a clear result, it is a Capability. If it is just a small step that requires too much coordination with other teams to be independent, it is a Process.
The “What vs. How” Test
- Capability: Describes a business ability, the What. Example: “We have the capability to Recruit.”
- Process: Describes a business activity, the How. Example: “This is how we conduct an interview.”
Completeness Test:
- Is it a complete whole that consists of all the required elements such as people, processes and assets (data, applications etc.) -> Capability
- Is it a partial behavior, which requires other elements (e.g. processes) to be complete – in certain context -> Process
The Active-Passive Test (In Motion-At Rest Test) – the state of the enterprise:
- If you stop all work in the company for a day, the Capabilities still exist (you still have the ability to bill customers), but the Processes have stopped (no one is currently billing).
- Capabilities represent the enterprise at rest, while Processes represent the enterprise in motion.
- Capability (At Rest / Passive): It represents the potential (“stored energy”) of the enterprise.
- Process (In Motion / Active): It represents the execution (“kinetic energy”).

Abstract Capabilities vs. Concrete Processes

In enterprise design and development, this distinction is crucial for understanding why we model both. Capabilities provide the “conceptual map” of the enterprise, while processes provide the “operating manual”, as the operating model is based on processes.

A helpful way to distinguish the two is by their level of concreteness:

Capabilities are Abstract (The “Ideal”): They represent the potential of the enterprise. We cannot “see” a capability directly – it is an idea that groups together people, processes, and assets (such as applications, data). Because capabilities are abstract, they are stable: they describe a business function regardless of how it is actually done.
- Example: “Customer Support” is an abstract concept. It exists as a requirement for our business even if nobody is currently answering a phone.
Processes are Concrete (The “Action”): They describe the actual work being performed. We can observe a process, measure its duration, and list its specific steps. Because processes are concrete, they are tied to specific roles, applications and technologies, which is why they change more often.
- Example: “Support ticket handling” is a concrete process. You can see the steps, the software used, and the time it takes.

The “Snapshot” Rule. If we take a photo of our office:

The Processes are the people moving, the data flowing, and the machines running.
The Capabilities are the reasons why those people and machines are there in the first place, even if they were all standing perfectly still.

Note! Naming conventions:

Capabilities often use nouns or gerunds: Recruitment, Claims Management, Asset Maintenance.
Processes often use verb-driven flows: Review Application, Approve Claim, Repair Machine.
Note! However, avoid “Management” and “Development” traps:
- Every capability needs to be managed and developed. Unless the capability is specifically about managing the whole enterprise, avoid or at least think about putting “Management” in every name, as that often describes a process within a capability.

Characteristics of Capabilities and Processes:

Capability is:

Coherent composition, container of readiness, of what an enterprise is able to do to create value.
Context for why its internal elements exist and how they are bundled together.
Abstract: represent the potential of the enterprise.
Holistic, all-in-one “box”, a wrapper, that holds everything required to achieve a specific business outcome.
Autonomous, independent, self-contained unit.

Process is:

Sequence of steps (Step A → Step B → Step C).
Concrete: describes how work is done using specific roles and tools.
Repeatable: It is designed to be performed the same way multiple times to ensure quality.
Measurable: we can track its speed (cycle time), cost, and efficiency.
Context specific flow of activities.

How Capabilities and Processes work together:

Value Streams (High-level processes) flow through multiple Capabilities to reach an overall outcome of the business.
Capabilities contain internal behavior of core and supporting processes that work together to create an outcome of a capability.
- Processes are the internal behavior inside the Capability (the building block of the business).

Process types

Processes exist in different levels as follows:

High-Level Processes (The Big Picture)
- These are “end-to-end” processes that cross the entire enterprise and its capabilities. They are often called Value Streams.
- A Value Stream (the high-level end-to-end process) is “horisontal” – it cuts across the “vertical” functional silos or Capabilities of the enterprise to deliver value to a customer.
- They show the long journey from a starting point (like a customer’s need) to the final result (like a delivered product).
- Examples: “Order-to-Cash” (from receiving an order to getting paid) or “Idea-to-Launch.”
- Sometimes, the entire enterprise’s high-level activity, the overall flow, is viewed as a Value Chain, showing the main stages that add value to a product or service.
Operational Processes (The Working Level)
- These are the detailed workflows that happen “inside” a Capability.
- They are the specific steps and tasks that people and systems perform every day.
- One operational process often enables another. For example, a “Data Collection” process must happen before the “Data Analysis” process can begin. Together, these smaller processes create the overall functional result of a capability.

High-level, enterprise wide end-to-end process as a Value Stream:

A *Value Stream* spans over several capabilities / capability groups.

Low-level, context specific operational process:

a Process is a sequence of related tasks that turn an input into a specific output.

Process as an element of a Capability, that represents the context (the domain) for processes belonging together:

A capability can consists of several processes that belong together.

Different Types of Flows

Depending on who is doing the work and why, we use different terms:

Operational Value Streams: The daily work we do to serve our customers (e.g., building and shipping a car).
Development Value Streams: The work we do to build new things or improve our enterprise (e.g., designing a new car model).
Customer Journeys: This is the “process” from the customer’s perspective. It focuses on what the customer does, feels, and experiences while interacting with us.
Service Journeys & Blueprints: When we connect the customer’s journey to our own internal operational processes, we create a Service Blueprint. This shows how our internal actions support the customer’s experience.

Summary of Process Levels

Level	Common Name	Focus
Strategic	Value Stream / Value Chain	End-to-end flow of value across the enterprise. Coordinated flow of several capabilities working together to succeed.
Middle	Capability Internal behavior and cooperation of processes belonging together: core + supporting processes.	How different processes work together within a capability.
Operational	Workflow / Task	Precise, step-by-step actions and technical tasks.
External	Customer Journey	The process as seen and felt by the person using the service.

Outsourcing Considerations

In many cases, while we use the term process outsourcing, what is actually being outsourced is a capability. When an enterprise uses Business Process Outsourcing (BPO) or Business Process as a Service (BPaaS), they are not just handing over a sequence of steps; they are handing over the responsibility for an entire “black box” that includes the people, the technology, and the expertise.

Why business process outsourcing / BPaaS is often capability outsourcing:

Autonomy: We are buying a result (Outcome), not just a set of instructions. The provider is responsible for what is achieved, often deciding for themselves how (the processes) it is done.
Encapsulation: In BPaaS, the provider gives you the software (Asset), the staff (People), and the workflows (Processes). This “all-in-one” package is exactly what defines a Capability.
Clear Boundaries: You can detach a capability like “Payroll” or “Customer Support” and move it to a partner because it is a self-contained unit.

Notes:

Outsourcing a Capability: We hand over the “What.” We tell the provider: “Handle our Payroll.” We don’t care which software they use or which specific steps they take, as long as employees are paid correctly and on time. (This is most BPO/BPaaS).
Outsourcing a Process: We hand over the “How.” We tell the provider: “Follow our specific 10-step manual using our systems.” This is more like “staff augmentation” or “task outsourcing.” It is less common in modern BPaaS because the provider usually wants to use their own efficient processes.

Summary Rule

If we outsource the responsibility for the outcome and the provider brings their own people and tools, we are outsourcing a Capability. If we only outsource the execution of our own steps, we are outsourcing a Process.

Product vs. Service

Products and Services are often confused because they both deliver value to the customer. However, they represent different perspectives of the same interaction.

The Basic Distinction:

Product:
- The “Object” or “Package.”
- What the customer buys or signs up for.
- The tangible or digital thing that promises value.
- Concrete because it exists as a “prepared, configured object” or a stable “package” of content that you build and make available.
- It represents a “static” offering that can be owned or leased.
Service:
- The “Activity” or “Relationship.”
- The act of helping or supporting the customer.
- The value in action, often occurs over time through various channels (on a customer journey).
- Abstract because it is “intangible” and “dynamic by nature,” existing primarily as a promise or a potential.
- Concretises during the interaction between a customer and a service provider, where it is used, consumed, and experienced in real-time.

Rule of Thumb: A Product is what you have or get. A Service is what happens to you or for you.

Identification Checklist: Product vs. Service

Use these questions to identify which is which:

Question	If the answer is “Yes”…	Category
Can the customer “own” it or hold it (physically or digitally)?	It is likely a Product.	Product
Does it describe an ongoing activity or a promise of help?	It is likely a Service.	Service
Is it a bundle of different features and legal terms?	This is the “Product Offer.”	Product
Does it focus on the Customer Journey and experience?	You are looking at a Service.	Service
Is it something that is “consumed” at the moment it is produced?	This is a classic Service.	Service

In modern enterprise design and development, a digital product is a unique hybrid that often functions as both, but it is primarily categorised as a Product that acts as a platform for services.

Key Rules:

The “Subscription” Rule
- If you pay for a subscription (of a brand such as Spotify, Netflix etc.), the subscription is the Product. The act of streaming music or watching movies and the related technical support you receive is the Service.
The “Relationship” Rule
- The Product belongs to the Content (what we offer). It is a “Package” of Capabilities and Assets.
- Service (the “what”) is realised by processes (the “how”). It is what the customer experiences during their Journey.
The “Ownership” vs. “Access” Rule
- If the customer takes it home (like a car), it is a Product.
- If the customer only gets the benefit (like a taxi ride), it is a Service.
Jobs-to-be-Done (JTBD) Perspective
- Ask: “What job is the customer hiring this for?”
  - The Product is the tool they hire.
  - The Service is the help they get to finish the job.

Product vs. Service comparison table:

Characteristic	Product	Service
Tangibility	Tangible (mostly)	Intangible (mostly)
Transfer of Goods	Physical, virtual, or digital objects or systems made available for customers.	Transactions where no physical goods are transferred from the provider to the consumer.
Logistics	Manufactured, stored, and transported.	Cannot be manufactured, stored, or transported.
Returnability	Can be returned or replaced.	Cannot be returned or replaced.
Uniformity	Products can be identical (or variants).	Each delivery of a service is unique.
Nature	Static by nature; can be owned, rented, or leased.	Dynamic by nature; can be used, consumed, and experienced.
Basis of Delivery	Based on a prepared, configured object of a certain type provided as an instance to the owner.	Based on the interaction between a customer and a service provider.
Examples	Based on the interaction between a customer and a service provider.	Specialist support or help, car repair, cleaning, medical operation, furniture assembly.

Product vs. Capability

This is a common point of confusion because both are “building blocks.”

Here is the simplest way to see the difference:

The “Direction” Rule
- Capability (Internal): It looks inward.
  - It describes what the enterprise is able to do. It is a combination of people, processes, and assets required to keep the business running.
  - Example: “Payment Management” is a Capability.
- Product (External): It looks outward.
  - It describes what the customer receives. It is a “package” that the enterprise sells or offers to the market.
  - Example: The “Gold Credit Card” is a Product.

Product vs. Capability Comparison table:

Feature	Product (External/Market Focus)	Capability (Internal/Ability Focus)
Goal	To solve a customer problem and generate business value (revenue or adoption).	To provide the enterprise with the stable ability to perform a specific function.
Owner	Product Owner / Product Manager: Focuses on the “Value Proposition” and the market.	Capability Owner / Business Owner: Focuses on “Operational Readiness” and efficiency.
Content (Elements)	External- / Customer-facing bundle: Brand, Price, Channels, specific Features, and the underlying Assets/Capabilities.	Internal-oriented composition: People (skills), Processes, Assets (IT, data, facilities).
Success Metric(s)	Market–driven: Net Promoter Score (NPS), Customer Lifetime Value (CLV), Revenue, Retention, Customer Satisfaction Score (CSAT).	Performance-driven: Maturity level, Efficiency (cost per transaction), Availability, and Capacity.
Outcome	Customer Benefit: e.g., “I can manage my money easily.”	Organisational Benefit: e.g., “The enterprise can process 1M transactions/sec.”
Output	The Offering: The actual app, tool, or physical item delivered to the user.	The Ability: A functional “black box” that is ready to be used or required by various products or services.

Key Takeaway for Identification:

Capabilities are the “Building Blocks” (The What): They are the internal engines. We don’t sell a capability; we use it. For example, a bank has a “Credit Scoring” Capability.
Products are the “Package” (The Offer): This is what we put on the shelf. The bank uses that “Credit Scoring” capability to offer a “Student Credit Card” Product.

The “Stack”

Customer-facing products and services require the internal capabilities of an organisation to fulfill customer needs, tasks, and jobs to be done.

Driver – Goal – Outcome (Three-Step Logic)

In all design and planning, goal setting is crucial.

Initially, it is essential to clarify why a change is needed and why goals are being set in the first place. Therefore, one should first clarify the drivers – answering the question: Why? This makes it easier to set goals that address these drivers, particularly the specific root causes.
Goals should be formulated to express both the subject (what is changing) and its qualitative characterisation (how it is changing). Thus, goals describe a qualitative change. A goal can be presented in the form: Subject + Qualitative Attribute. For example: ‘Improving customer satisfaction.’ Here, the keyword or ‘handle’ indicates the object of change, and the attribute indicates the nature of that change.
Once goals are set, we can derive outcomes from them. Outcomes express what has happened once the goals have been achieved. Outcomes are measurable, quantitative achievements or benefits that verify the realisation of the goals.

When setting goals, it is valuable to first analyse the root causes, the drivers: why a change is needed. This allows us to define the goals clearly, including the qualitative changes we aim to achieve. Finally, we can identify the business outcomes we expect to realise.

Below is a simple and practical tool for analysing and setting goals.

Question to ask	Driver (Why)	Goal	Outcome
Does it explain why change is needed?	✅ Yes	❌ No	❌ No
Does it describe what we want to achieve?	❌ No	✅ Yes	❌ No
Does it describe what actually changed?	❌ No	❌ No	✅ Yes
Is it about pressure, problem, or opportunity?	✅ Yes	❌ No	❌ No
Is it about intention or direction?	❌ No	✅ Yes	❌ No
Is it measurable and observable?	❌ Not necessarily	❌ Sometimes	✅ Yes
Does it exist before action starts?	✅ Yes	✅ Yes	❌ No
Does it exist only after action is completed?	❌ No	❌ No	✅ Yes

Comparing Goal and Outcome – what are their differences?

Question	Goal	Outcome
What is the nature of the statement?	It is a *qualitative* statement of intent or desire.	It is a quantitative or verifiable result.
When does it exist?	At the start; it is what we aim for.	At the end; it is what we actually achieved.
How do you describe it?	Using aspirational language	Using measurable language (e.g., “Market share is 30%”).
What does it guide?	It guides our direction and strategy.	It proves our success and impact.
Example	“We want to improve our customer service quality.” – What we want to be	“Customer satisfaction score increased by 15%.” – What has happened finally.

The Core Logic

A seamless causal chain goes:

A driver rationalises the goal, which aims for a specific outcome.
This goal creates the necessary activity, producing an output (object, deliverable, artifact) that directly impacts the outcome.
This ensures that every design, development and operational task is rooted in strategic identity and delivers value to both customer and the business.

Drivers represent the forces that impact the enterprise’s business operations. These include customer needs, shifts in the operating environment, technological evolution, and regulatory requirements. Identifying these drivers is the crucial first step in our continuous design and development process, as they provide the rationale for every goal we set.

A driver rationalises a goal. A goal aims for an outcome. A goal creates an activity. An activity produces an output (object). An output impacts the outcome.