Products, Goods, and What Customers Actually Buy

Product, good, service, commodity, and offering are often used as if they named the same thing. They do not.

A phone can be a product, a manufactured good, an item in a retailer’s catalog, and the object transferred in a sale. Crude oil is a product of extraction and a commodity traded in standardized units. Software may be called a product even when the customer never owns a copy and only receives access to a service.

The material object alone does not settle the vocabulary. Each term highlights a different relation.

A product organizes capabilities for use. A market offering organizes the terms under which capabilities, goods, services, or rights are exchanged.

This distinction has to be established before asking what customers “really” buy.

What Is a Product?

In a broad business sense, a product is an organized set of capabilities and experiences made available to users in a particular context.

It can be a physical object, a digital system, a service, an informational work, or a combination of technology and human activity. The American Marketing Association defines a product broadly as a bundle of attributes—features, functions, benefits, and uses—capable of exchange or use. It may be an idea, a physical good, a service, or a combination. AMA: Definitions of Marketing

A product normally gives structure to six questions:

1. Who will use it, buy it, maintain it, or bear its effects?
2. In what situation will use occur?
3. What task, capability, or change is at stake?
4. What features, content, processes, and services make use possible?
5. How will people discover, obtain, learn, use, support, and leave it?
6. What evidence will show whether it worked and at what cost?

Technology is an enabling capability. A feature is one behavior within a larger arrangement. A project is temporary work. An output is anything a process produces. None of these alone establishes a product.

A language model is a technical capability. A system that combines the model with an interface, accounts, context handling, file operations, safety controls, support, and continuing operation can become an AI product.

Product, Good, Service, Commodity, and Offering

English separates several concepts that cannot be mapped to a single word in every context.

A laptop is a product and a good. Repair is a service. Wheat futures concern a commodity. A business laptop plan that includes hardware, financing, support, warranty, and device management is an offering.

The boundaries vary by discipline. Marketing often uses product as the umbrella. Quality management distinguishes outputs, products, and services to allocate process and delivery responsibilities. Software practice calls a continuously operated service a product because it has users, versions, capabilities, support, and an evolving value proposition. ISO 9000:2026

The useful question is not which vocabulary is universally correct. It is which distinction the present analysis needs.

What Makes Something a Market Offering?

A usable product does not by itself specify a transaction.

A market offering adds answers to questions such as:

• What is the unit being sold?
• What price and payment schedule apply?
• Does the customer receive ownership, possession, access, or a license?
• What quantity, duration, territory, or usage limit applies?
• What support, warranty, maintenance, or service level is included?
• What happens on cancellation, return, failure, or renewal?
• How are privacy, liability, and risk allocated?

The structure can be summarized as:

market offering
= product capabilities
+ deliverables
+ ownership, access, or license rights
+ quantity and duration
+ price and payment terms
+ service commitments
+ return, repair, renewal, and exit rules
+ allocation of risk and responsibility

One knowledge-management product can appear as a free personal plan, a monthly professional subscription, a per-seat team plan, an enterprise agreement with migration and training, or a private deployment contract. The underlying capabilities overlap; the offers do not.

A Product Can Exist Without a Retail Sale

The relation between product and market exchange is not one-to-one.

An internal tool can be managed as a product even though it is not sold outside the organization. Open-source software can be a mature product while access to the code remains free. A public service can be designed and operated as a product without charging the final user. A prototype can contain a product hypothesis before there is a stable commercial offer.

Conversely, being listed and sold does not establish product quality. A transaction shows that an exchange occurred under particular conditions. It does not show that the product was usable, beneficial, fair, or sustainable.

The same object can also change institutional roles without changing its physical form. A computer is a design object during development, a manufactured product at completion, a good in inventory, the object of a sale, the buyer’s property after transfer, and an organizational asset when put to work.

Ownership, Access, and Performance

Different offers transfer different things.

Physical goods

A sale usually transfers ownership or possession of an item. The buyer of a chair receives the object and, within legal and contractual limits, may use, resell, modify, or dispose of it.

Services

A service sale normally concerns an activity, performance, or commitment. A haircut, consultation, and journey are completed through interaction. The customer does not take possession of “the service” as a durable object.

Digital products

Digital transactions often transfer neither a physical object nor ownership of the underlying software. They may provide:

• a time-limited right of access;
• a license to run or reproduce software;
• a usage allowance measured by seats, storage, calls, or tokens;
• continuing operation and support;
• rights over content or virtual items defined by platform rules.

Calling all of these “buying software” hides the legal and operational differences.

Products and Offerings in Everyday Life

The distinction appears across ordinary domains.

Walking can satisfy a mobility need without a product purchase. Buying a bicycle usually transfers a good. Bike sharing sells temporary access. A metro ticket buys a transport service. The domain does not determine the form of exchange.

How Does a Product Relate to a Need?

A need describes a missing or required condition in a person’s situation. A product is one organized response.

A product turns a supplier’s interpretation of a need into a capability that can be used and tested.

“I need a car” already contains a proposed solution. Further inquiry may reveal a chain:

wants to buy a car
→ must commute regularly
→ wants to arrive reliably and comfortably
→ needs practical control over mobility within family, work, and time constraints

A car may be appropriate. So may rail, cycling, moving home, car sharing, remote work, or a different schedule.

This is why a product is better treated as a testable supply hypothesis than as the need itself. The hypothesis survives only if relevant users can discover, understand, obtain, use, and benefit from the product in actual conditions.

Need Is Not Market Demand

An urgent need does not automatically create a viable offer.

A person may need care without being able to pay. A user may value a tool while rejecting its subscription terms, privacy policy, switching costs, or procurement requirements. A product may work but remain inaccessible through the available channel.

Moving from need to purchase requires several different kinds of fit:

1. Problem fit: the situation matters to the intended user.
2. Capability fit: the product supplies a relevant condition.
3. Context fit: the environment allows the capability to work.
4. Comprehension fit: people can find and understand the offer.
5. Economic fit: price, access, and payment conditions are acceptable.
6. Trust fit: the source and its promises are credible enough.
7. Outcome fit: use actually improves the original situation.

Need, demand, purchase, adoption, and outcome are different stages and different evidence.

User, Customer, Buyer, and Beneficiary

The person who needs or uses a product is not always the person who buys it.

For a child’s toy, a parent may decide, buy, and pay while the child uses and benefits. In enterprise software, executives may authorize, procurement may buy, finance may pay, employees may use, and IT or legal teams may control risk.

A product can satisfy users while failing to give a customer a reason to buy. An offer can satisfy procurement while imposing an unusable system on employees. Product design and commercial design must account for both sides without pretending they are the same person.

What Does a Customer Actually Buy?

There are two valid answers at different levels.

The transaction transfers deliverables, rights, and commitments

A customer may receive ownership of a good, licensed use, access for a period, a quantity of service, warranty rights, support, privacy terms, or remedies when performance fails.

An AI subscription grants access to specified capabilities under limits and terms. It does not directly transfer a correct answer, a finished career task, or improved intelligence.

At the transaction level, the customer buys a defined bundle of deliverables, rights, commitments, and allocated risks.

The motivation concerns expected progress

The customer accepts that bundle because it is expected to help complete a task, save time, reduce uncertainty, avoid loss, create an experience, express identity, or preserve an option.

Jobs to Be Done describes customers as “hiring” products to make progress in a circumstance. Its strength is to direct attention away from features and toward what changes for the customer. Harvard Business School Online

But saying “customers buy outcomes” goes too far.

Why the Outcome Is Usually Not the Product

A course can supply instruction, practice, and feedback without guaranteeing mastery. A gym can supply equipment and coaching without guaranteeing health. A physician can provide competent treatment without guaranteeing recovery. An AI system can provide analytical capability without guaranteeing truth.

Outcomes commonly depend on three sources:

capabilities and conditions supplied by the product
+ action and contribution by the user
+ surrounding circumstances and constraints
= realized outcome

Service-dominant logic captures part of this distinction by treating firms as participants in value creation rather than as manufacturers of value fully contained inside goods. Value becomes concrete in use and context. Vargo and Lusch

A precise formulation is:

A customer buys a bundle of conditions believed to improve the probability of a desired outcome, not the guaranteed outcome itself.

A contract may make a supplier responsible for a defined result. Even then, the result, measurement conditions, exclusions, and remedies have to be specified.

Exchange Value Is Not Use Value

A purchase demonstrates that a customer accepted an exchange under the information, alternatives, price, and constraints present at the time.

It does not prove that the product solved the problem, that the decision was fully informed, that the price was fair, or that third parties were unharmed. Promotion, misunderstanding, habit, conformity, lock-in, and lack of alternatives can all produce sales.

The evidence should remain separated:

noticed
→ understood
→ considered
→ purchased
→ activated
→ repeatedly used
→ produced an intended outcome
→ remained worthwhile over time

Exchange validates a transaction. Use validates adoption. Outcome evidence is required to test whether the original need was addressed.

Where Brand Enters

Customers cannot fully inspect future performance before purchase. They use source identity, prior experience, reputation, reviews, and promises to estimate uncertainty.

A brand compresses those signals into recognition and expectation. It can reduce search cost, make an offer easier to interpret, and identify who should be held accountable. It may also carry aesthetic, social, and identity meanings.

Brand can improve the exchangeability of an offer. It cannot perform the user’s task. The brand forms an expectation, the offer defines a transaction, the product enters use, and the result confirms or corrects the expectation.

A Test for Product and Offering Claims

Before saying that a product “meets demand,” ask:

1. What capabilities are organized into the product?
2. Who uses it, in what context, and for what task?
3. What precisely is included in the offer?
4. Which ownership, access, license, support, and exit rights transfer?
5. Who uses, buys, pays, decides, benefits, and bears risk?
6. Which need is the product intended to address?
7. What commercial and noncommercial alternatives exist?
8. Which outcomes can the supplier control?
9. Does purchase lead to adoption?
10. Does use improve the original situation after total cost and side effects are counted?

These questions test product structure, transaction structure, and need fit separately.

Conclusion

A product and a market offering are related but distinct.

A product organizes capabilities so that value can occur in use. An offering organizes exchange by specifying what the customer obtains, under which rights, obligations, prices, and risks.

Needs enter the account after those boundaries are clear. A need describes a condition required in a situation. A product is a testable response. An offering turns that response into a transaction.

Customers acquire deliverables, rights, and commitments because they expect those conditions to help them make progress. Whether value was realized remains a question for use and outcomes, not for the sales record alone.

References

• American Marketing Association — Definitions of Marketing
• ISO 9000:2026 — Quality management: Fundamentals and vocabulary
• ISO 9241-115:2024 — User needs and user requirements
• Harvard Business School Online — Jobs to Be Done
• Vargo and Lusch — Service-dominant logic: continuing the evolution
• Karl Marx — Capital, Volume I, Chapter One