Background

Elsewhere, the distinction between a Product and an Offering is defined. The most succinct description of this distinction, defined from an Experience standpoint, is that Offerings are Engaged and Products are Used. There are no Offerings without Products, however, there are lots of Products that are mistakenly designed without considering how they contribute to an Offering. Offerings and Products are symbiotic, but they are far from identical.

Motivation

To begin to clarify the distinction and relationships between Offerings and Products a more detailed description of the Product Use Experience is defined. Elsewhere, the Offering Engagement Experience will be defined and, later, the relationship between them will be discussed.

Product “Use” Experiences

Products are solely defined by their “Use” Experiences. The “Use” Experiences of any Product are defined, collectively, as the combination of (up to) seven types of Experiences: Preparing, Utilizing, Maintaining, Retiring, Customizing, Configuring, and/or Augmenting the Product as shown below.

Key Questions for the “Use” Experiences:

Each of the experiences that make up the entirety of the “Use” Experience of a Product are defined by answering one key question:

Preparing Experience

How does a Role make the Product ready for first Utilization?

Utilizing Experience

How does a Role put the Product into practice?

Maintaining Experience

How does a Role keep the Product ready to Utilize?

Retiring Experience

How does a Role remove the Product from practice?

Configuration Experience

How does a Role modify the behavior of the Product?

Customization Experience

How does a Role change the internals of the Product?

Augmenting Experience

How does a Role integrate the behavior of the Product with something else?

Examples of “Use” Experiences

A Car Example

Roles interacting with modern vehicle might experience: Preparing the vehicle for first Utilization by ensuring all fluids are topped off after factory shipment; Utilizing the vehicle by driving around town; Maintaining the vehicle by refilling the gas tank; Retiring the vehicle by removing all personal information in the OnStar service prior to selling the car; Configuring the vehicle’s radio presets, seat positions, and mirror positions; Augmenting the vehicle with the addition of an aftermarket trailer hitch; and Customizing the vehicle by replacing the core engine CPU with an aftermarket “Power Chip”.

A CRM SaaS Product Example

Roles interacting with a SaaS Product for Customer Relationship Management (CRM) might experience: Preparing the SaaS Product by entering prospect and customer records; Utilizing the SaaS Product by tracking and generating status reports on prospects and customers; Maintaining the SaaS Product by removing prospects who are no longer to be tracked; Retiring the SaaS Product by exporting all active prospects and customer records prior to decommissioning; Configuring the SaaS Product by redefining the default stages of prospect and customer progression to be tracked; Augmenting the SaaS Product by adding an automated data feed to a 3rd party tool; Customizing the SaaS Product by modifying the internal scoring module for when a prospect or customer should be contacted.

Discussion of some “Use” Experience Examples

Note that not all Products can, nor should, support all of the “Use” Experience types.

Retiring a Product is sometimes a complicated business decision. Making it easy to retire a Product may be in the best interest of the user, but it may not be in the best interest of the Product provider. Often Product providers explicitly avoid the creation of a Retiring experience under the presumption that the user will no longer be of interest.  This may be short sighted as the decision will almost assuredly lead to aggravated users of this Product but who may also be Preparing to use another Product from the same provider or even the same portfolio.

Customizing is a particularly interesting “Use” experience. In the above examples, the Product producer of the vehicle may not intend for the Power Chip Customizing experience but it is, nevertheless enabled in the aftermarket by reverse engineering the signals, sequences, and timing of the core engine CPU that comes with the vehicle. In this example, the Customizing experience is manifest, however, it does not mean that it is a supported experience by the Product provider.

Likewise in the CRM SaaS example above, the Product producer may not intend to provide a  Customizing experience that allows for modifying the internal scoring module but it may be inadvertently available. For example, perhaps through careful inspection of some JavaScript it is determined by an adventuresome developer that modification of some constants in an internal client side data structure will actually get pushed back to the internal scoring module on the server to elicit different results than expected by the Product provider.

Generally, providing Customizing experiences for goods can be a sensible decision if there is little or no concern with respect to warranty claims. For instance, changing the timing on the aftermarket power chip may void the warranty. Providing Customizing experiences for services should only be made available if there is a way to isolate the resulting customization from the rest of the service tenants. Absent this separation, each service becomes a singleton hosted on behalf of a single tenant, and the expense of maintaining the Customized Product (sometimes called an Asset once customized) can be debilitating.

Another often optional experience is the Augmenting experience.  Suppose that the CRM SaaS Product decided to only make their own AddOns to their base product.  In this case, the Augmenting experience for the base Product would not exist since the eco-system is closed.