Product and Service Differentiation by Robert Hales
Shared by: sio10796
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.