Product Surface Area

While the Product “Use” Experiences (  here ) shape a Product, the corresponding Product Surface Area formally defines the Product.  A key part of creating a Product is to explicitly, and intentionally, design, develop, and deliver, exactly the right Product Surface Area. The set of Surface Area possibilities for a Product are depicted in the following refined conceptual model expanding on the conceptual model for the 7 potential experiences of Use for a Product.

Surface Area Choices

Each of the seven types of Experiences are intended to drive focused discussion around a variety of use-cases. For any given Product, any one of the seven Experience types may not exist at all. In fact, care should be taken to provide the smallest Surface Area possible to meet the needs of the market as this gives the best flexibility for evolution of the Product in the future. With the exception of Customization (see below), the Surface Area always represents a contract with Product users that is intended to be consistent, or at least inherently familiar, across Product releases.

Prepare – make the Product ready to Utilize

Preparing Experiences, and, hence, the Prepare Surface Area are employed when the Product requires some form of initialization preceding ongoing utilization.  Some Products are immediately ready for utilization which would then obviate the need for this portion of the Surface Area while others may require substantial Preparation Experiences before any utilization can proceed.

Utilize – put the Product into practice

Utilizing Experiences and, hence, the Utilize Surface Area are employed when the Product intends to deliver fully equipped use-cases.  However, not all Products are intended to deliver “out of the box” value.  For instance, if the Product is only intended to provide an API for developers (see Augment), then a Utilize experience may not be intended from the Product itself.

Maintain – keep the Product ready to Utilize

Maintaining Experiences and, hence, the Maintain Surface Area are employed when the Product requires ongoing care. This could include the replenishment of resources consumed by the Product (e.g. fuel), periodic cleaning, or simple, self-serve repairs.  If there is no need for ongoing care, then the Maintain Experiences are not required.

Retire – remove the Product from practice

Retiring Experiences and, hence, the Retire Surface Area are employed when the Product is no longer to be Utilized.  This could include the removal of resources that “personalized” the Product, the decommissioning of services that are PartOf the Product, or the physical removal of goods that were added via the Augment Surface Area.

Configure – modify the Product behavior

Configuring Experiences and, hence, the Configure Surface Area are employed when the Product intends to allow its behavior to serve a wide variety of interests. If a Configuring Experience is considered, care must be taken to ensure that the necessary increase in complexity does not alienate the simplest of users who are delighted with the default experiences, while also catering to those who need the Product to be adapted, through configuration, to their needs.  By definition, the Configure Surface Area always includes the necessary tools and capabilities in the Product itself to facilitate the Configuring Experience.

Augment – integrate the Product behavior with something else

Augmenting Experiences and, hence, the Augment Surface Area are employed when the Product intends to participate in a pre-integrated way with either another Product or in a Solution. The Augment Surface Area can be used for creating Add-Ons, creating Companions, providing pre-integration to 3rd parties, or bordering the Product with bespoke Capabilities. In all cases, the Augment Surface Area provides a durable, upward compatible manner in which to support these activities as contrasted with the Customize Surface Area (see below).

Customize – change the Product internals

By definition, the Customizing Experience and, hence, the Customize Surface Area, results in a derivative work of the Product itself. The Customize Surface Area of the Product resides within the actual implementation of the Product. Sometimes the Customize Surface Area is intentional (e.g. a Linux distribution) and sometimes it is reverse engineered from the Product implementation (e.g. electrical, timing, and sequence diagram of an engine control chip). Utilization of a reverse engineered Customize Surface Area can begin to put into question any warranty that might be implied by the Product. Utilization of an intentional Customize Surface Area typically results in warranty coverage being encapsulated with a bespoke services contract for each customization. Unlike the Augment or the Configure Surface Area, the Customize Surface Area is not guaranteed to be durable across future releases of the Product. Use of the Customize Surface Area, therefore, result in singletons that are associated in a 1:1 manner with a given Product instance and the aforementioned bespoke services contract for support.

Surface Area Evolution – Upward Compatibility

The Evolution of both the Product and the Offering must be done simultaneously.  Care must be taken to respect the Surface Area between releases of the Product.  Each of the Surface Areas have an expectation of upward compatibility, those the expectations can differ greatly between them.

For instance, assuming a widely successful adoption of the Augment Surface Area, it is imperative that it remain 100% compatible between releases unless an explicit deprecation strategy is employed in the overall Offering Experience. Without this assurance, the widespread adopters will surely be aggravated and, likely erode their engagement of the Offering over time.

The Customize Surface Area is typically a “buyer beware” risk from release to release.  However, in the presence of (unintended) widespread adoption, the emotional response of the addressable market to a new, non-compatible release may elicit more hard feelings than can be tolerated and, hence, adoption may force the Customize Surface Area to become supported from release to release.

The Configure Surface Area, if the configuration can be preserved in place or, conversely, exported and imported to between versions of the Product, will have similar upward compatibility requirements to the Augment Surface Area.  If there is no preservation or export/import then the requirements for upward compatibility are relaxed and long term delight must count on re-implementing the Configure from release to release.  (e.g. resetting the radio buttons on a new car is not a big deal, but re-configuring the entire prospect and customer pipeline in a new SaaS release might be a big deal).

The upward compatibility requirements for the Maintain Surface Area will be highly dependent on the process and interfaces used to perform the maintaining experiences. Generally, if 3rd party eco-systems are involved, then rigorous compatibility likely becomes a strong requirement (e.g. putting fuel into a vehicle from a gas station nozzle requires that the pre-existing gas nozzles fit into the vehicle from release to release). If the Maintaining experiences are more self contained, then subtle changes in the Maintain Surface Area may be tolerated with simple re-training for the user, especially if they are performed infrequently.

The upward compatibility requirements for the Prepare Surface Area If the end user provides the resources from a self contained source then the upward compatibility *may* be somewhat relaxed, especially if the Prepare experience is based on a one-time, non-consumable resource that persists from release to release and, therefore, only affects new users.

The upward compatibility requirements for the Utilize Surface Area are related to ensuring the experience is familiar to the user from release to release, with minimal retraining (except possibly for new Features).  Subtle changes in the Utilize Surface Area are typically tolerated with simple re-training for the user, while more drastic changes might be met with rebellion.