Product and Service Differentiation by Robert Hales

							Product & Service Differentiation by Robert Hales
Introduction
As providers of software products and consulting services, we are all interested in
delivering value to our customers. Value in this context is simply the difference
between the benefit delivered to the customer and the price that the customer pays
to obtain the benefit. We are interested in delivering high value because that is what
allows us to stay in business. Delivering recognized value leads to repeat business
and referrals to new customers. It generates "buzz".

The value equation implies two approaches to increasing value. One approach is to
simply deliver a me-too product or service at a price that is lower than the
competition. While we should always be looking for ways to reduce our costs, there
is a definite limit to this approach. We cannot reduce the price of all of our products
and services too far and expect to stay in business. A better approach is to include
functionality in our products or services that make our customer's mouth water in
anticipation. When that objective has been achieved, price is not such an issue
anymore.

Let's carry the value equation a little further. Most products or services must deliver
a certain level of functionality in order to be considered as viable. If the product or
service fails to deliver expected functionality in any area, it will eventually fail
because the market will find it unacceptable. It will fail to deliver the benefit being
sought by the market. However, going beyond the minimally expected level of
performance may not increase the value of the product or service in the eyes of the
customer. Unless the customer recognizes the extra benefit being delivered by the
additional functionality, the enhancement only contributes to the cost of the product.
Unless the customer wants the additional functionality, the effort spent developing,
testing, documenting, selling, and supporting it is wasted. Clearly, it would be ideal if
we could identify exactly where to deliver exciting advanced functionality in order to
generate market enthusiasm and where we should provide only the expected level of
performance in order to save cost.

Identifying where the customer will recognize value is not easy. It requires
involvement by those that best know what is possible (Product Developers), those
that best know how to communicate with customers (Marketing), and those that
ultimately have to recognize the value of the product or service (Customers). It also
requires that everyone involved in the process recognize that they can learn from the
other participants. While the process that I describe below may not be perfect, it is
very good. In fact, it can actually generate a lot of enthusiasm among programmers
and engineers for the concept of talking with the customer.

Process Description
I think that the best way to describe a process like this one is to walk through it step
by step using an example to which the audience can relate. For this audience I will
use a team calendar application as the example.

Function Definition

The initial step is to identify the categories of functionality and other open design
issues. Generically, I call these items Functions. Each Function documents a
capability that must be delivered by the product or service bundle without specifying
how or how well it would be done. For our team calendar software example, the list
might include technical Functions such as:

          ??   Captures team member schedules

          ??   Resolves schedule conflicts

          ??   Communicates meeting times

It could also include non-technical "Functions" such as:

          ??   Alerts the market to product availability

          ??   Provides documentation

          ??   Provides user support

          ??   Is packaged

Each Function documents where the cross-functional development team is going to
have to make a decision. They will have to decide on the approach that they will take
to deliver the Function. Ideally, they will choose the approach that will best deliver
value to their customers. Hence the need for market research.

Feature Definition

Next, the team identifies several alternative ways each of the 15 to 20 main
Functions could be delivered. These alternative design approaches (Features) range
from minimally acceptable solutions (Expectations), through commonly requested
approaches (Requests), to surprising solutions that would get the market excited
(Exciters). This implies that there are at least three different ways each Function
could be delivered. Typically, there can be many more. In our example, some
Features in support of "Resolves schedule conflicts" could include:

          ??   Alert calendar administrator of conflicts so that he/she can
               resolve it

          ??   Schedule the meeting if quorum available and e-mail request
               to adjust schedule to those with conflicts

          ??   Automatically reschedule conflicting meetings across the
               enterprise

Some Features in support of "Alerts the market to product availability" could include:

          ??   Advertise in targeted magazines

          ??   Work with time management consultants so that they alert
               their clients and rely on word of mouth

          ??   Sell strictly through our own account management and sales
               force to key accounts

Challenging the team to identify exciting solutions for each Function leverages the
team's creative energies. Identifying multiple Features for each Function forces the
team to recognize that there are many alternatives available. They should not
commit to a particular alternative until they understand whether the customer wants
minimal or exciting functionality in that area.

Outcomes/Recognition Metrics/Performance Levels
Now we really depart from standard practice. Many companies generate lists of
Functions and Features for their products. However, few try to rigorously understand
why the customer would prefer one set of Features to a competitive set of Features.

Generally, customers prefer one Feature to another because it will give them a more
desirable result (Outcome). If we understand the Outcomes that the customer is
seeking we are better able to offer them a complete solution to their "problem". We
are also better positioned to continually improve our offering. We are able to change
the paradigm and use a different approach to delivering the Outcome, as it becomes
available. Outcomes endure over time. Features come and go with frequency.

Outcomes are identified by asking "What is the benefit to the customer that would
cause me to choose one of these Features over the others as the best way to deliver
this Function?" Let's get back to our example. Prospective customers will be more
likely to purchase team calendar management software that…

          ??   Requires less team member time to keep the calendar up to
               date

          ??   Is more proactive at helping resolve our schedule conflicts
               Is more readily configured to our situation
               Includes more accessible customer support
               Is more widely endorsed as the industry standard.

For each Outcome we also define a Recognition Metric. A Recognition Metric
indicates, in the language of the company, how the customer recognizes whether a
particular product design is capable of delivering the Outcome. They are identified by
asking "What would you look at in competing product specifications to decide which
of the products would be more likely to deliver this Outcome?" For our example,
prospective customers would probably recognize which competing product is more
likely to deliver the Outcomes listed above if they were to examine…

          ??   Steps required to define and update calendar events with this
               product

          ??   Method used by this product to resolve user schedule
               conflicts

          ??   Product functionality that is not able to be configured by the
               user

          ??   Customer support that is available with the product
               Recognized industry experts endorsing/acknowledging use of
               the product

Recognition Metrics help in a couple of different ways. First of all, it forces team
members to define what the Outcome really means. Secondly, it puts the Outcome
into the language of the company so that the company can act on it. The Outcomes
themselves are often quite subjective in nature. The Recognition Metrics are very
objective.

Finally, the team documents some alternative levels of performance for each
Recognition Metric. They document the level of performance that is expected as a
minimum. They also document the level that they hear requested when customers
are asked. Finally, they estimate what performance level would get the market
excited if it were achieved. For example, if we were defining levels of performance
for "Customer support that is available with the product" we might find the following:
Expected                800 number - Regular business
Performance:           hours
Requested              800 number - 24hr availability
Performance:           800 number - Direct access to
Surprising             assigned
Performance:
Customer Research
The team goes to the customer. We spend time with customers in either interviews
or focus groups getting them to identify potential Functions, Features, and Outcomes
we may have missed. They also listen for verification of performance levels.
Typically, at least two team members are involved in each meeting. The interviewer
focuses on keeping the discussion on topic and moving while the other listens for
new information. Most of the time the discussion leader works to extract experiences
that illustrate what the customer likes and dislikes about their current solution. The
discussion then leaps into the future and the discussion leader attempts to get the
customer to describe the ideal solution (e.g. The ideal team calendar software).

Importance, Satisfaction, and Opportunity
When the customers indicate that the interviewer has accurately captured the
Outcomes they are seeking, they are asked to prioritize the Outcomes based upon
their impact on the purchase decision. They are also asked to rate how well their
current supplier or solution delivers against each Outcome. Market opportunity exists
where there are Outcomes that have high importance, but are not well satisfied by
the existing products. Ideally, the team will want to provide a product that directly
addresses those Outcomes that present the most market opportunity. That is where
value will be recognized!

Design Synergy
We prioritize the Recognition Metrics. A Recognition Metric's priority is defined by
how well its value correlates with the customer's perception of performance. If it is a
good predictor of perceived performance for several of the most important
Outcomes, its value will be very critical to get right. On the other hand, if its value
only predicts the perceived performance for a few of the less important Outcomes
then its value will not be very important. The prioritization is done using a matrix
such as those used in Quality Function Deployment. However, in this case, generally
project facilitator or project leader does the initial matrix work. The team then
analyzes the matrix to validate the relationships and the resulting priorities.

Setting Release Performance Level Targets
After meeting with the necessary number of customers, the team defines the
strategy it will follow in delivering the product. The performance level targets that
are set for each of the Recognition Metrics spell out the strategy. The best strategy is
to set aggressive performance level targets, which approach the exciting level of
performance that the team initially estimated, for the most important Recognition
Metrics. As the Recognition Metrics become less and less important, the performance
level targets are lowered until they eventually approach a non-differentiating,
expected level of performance. The team focuses on differentiating their product only
in areas where there exists significant opportunity for providing recognized value.

The resulting Recognition Metrics and Release Targets document how well the
product needs to perform in order to be differentiated in the market. However, it
does not specify how that performance is to be achieved.

Definition of Design Concepts
There are, almost always, many different ways to achieve the level of performance
specified in the Release Targets. To decide which approach is best, we define
alternative implementations (Design Concepts) for the product. Selecting a specific
Feature for each Function creates a Design Concept. Generally, many of the Design
Concepts use many of the same Features and only differ in a few key areas. Ideally,
the team will come up with approximately five good alternatives that would all serve
well if implemented. The idea is to find a Design Concept that is elegantly simple.
This is another opportunity for the product development team to demonstrate their
creativity. Sometimes this is the most difficult part of the process.

Selection of Design Concepts
The team selects the optimal Design Concept. The Design Concepts are evaluated
against the prioritized Recognition Metrics in order to determine which Design
Concept would most effectively achieve the Release Targets that were previously
defined. Leading Design Concepts are also evaluated for relative development cost,
production cost, and technical risk. The final Design Concept rating is an indication of
the relative value of this Design Concept in comparison with the others that were
evaluated.

Deliverables
The selection of an optimal Design Concept concludes the process. The physical
deliverables include a prioritized list of the Outcomes, prioritized Recognition Metrics
and associated target levels of performance. Finally, it includes the definition of an
optimized Design Concept to ensure that the desired level of performance is
delivered as efficiently as possible.
More importantly, the process has focuses the team on delivering recognized value
to the customer. The design decisions, that the team agrees must be made, are all
made with a focus on the customer. This usually causes a remarkably different
attitude toward customers and product functionality in future projects.

Prerequisites
The process does not come for free. It requires discipline. In some ways it goes
against our nature. People want to take shortcuts. Unfortunately, shortcuts lead to
missing information or misunderstandings further down the road. In order to avoid
these problems, it is pretty critical that the rules be obeyed. A process facilitator
whose only responsibility is to make sure that the process keeps moving and that all
rules are being obeyed is very valuable. What is most important is that these
facilitators not have a personal stake in the direction taken with the product or
service; they should only have a stake in the quality of the results. It is too hard to
lobby for one's own opinions while ensuring that everyone else's opinions are also
given adequate consideration. Perhaps personnel from other projects can handle this
role.

Conclusions
In software, as with most industries, product development is most likely to be
successful when it is given the best possible start in the form of a well thought out
and agreed upon product definition. The process that I have just described really
does work. If followed, the process…

           ??   Ensures a better understanding of what the customer values

           ??   Generates more creative solutions

           ??   Solicits more useful customer input

           ??   Uses all "team members" more appropriately

           ??   Uses more of the information that is generated

           ??   Is more difficult to manipulate or bias

           ??   Gets everyone more involved so that there is deeper buy-in to
                the results

           ??   Ensures better security from competitive snooping

           ??   Is faster to complete

           ??   Encourages a longer term view covering multiple releases

           ??   Minimizes creeping functionality by focusing on benefit to the
                customer

           ??   Considers more viable alternatives

I must assume that we all want these outcomes. An interesting and worthwhile
exercise would be to apply these steps to the definition of your own product
development process. However, even if you do not apply it there, think about the
principles that have been presented. While you are likely going through many of
these steps, perhaps the missing steps can help you increase the value you deliver
to your customers. Increased value and the resulting improved customer satisfaction
are certainly worthy objectives.