The customer's perception of a product never really matches reality. For that matter, the perceptions of marketing and sales often do not match reality. Even engineering's perception of the product does not always match reality.
To help you understand this concept, study Figure 5-5, which provides a Venn diagram with some interesting mismatches of perceptions that highlight classic problem areas. The three perception circles show all the different cases that can occur with mismatched expectations. Each case is labeled with a letter. Examine each overlap case separately to see potential problems and solutions for perception mismatch.
- A: Alignment
We all perceive the same thing the same way. Perception probably matches reality. For these features, the product works as designed and the customer expectations match. Smile. This is a good thing.
- B: Fooling Ourselves
Sales and marketing believe the product offers capabilities that do not exist. Fortunately, customers are unaware of these fictional capabilities. The better the communication between engineering, sales, and marketing, the less likely this misperception will happen. If engineering and marketing regularly communicate during development, they should be in alignment about the feature set. Good documentation and good sales training will bring the sales team up to speed. If sales' understanding is incomplete and staff presents the wrong information to the customer, they have created a larger problem, which is case C.
- C: Defects, Omissions, or Overselling
In this case, what was sold does not match what engineering built. The cause of this mismatch can be a product defect, problems with the documentation, or sales intentionally overselling the product.
Overselling occurs when sales tells the customer that the product includes a feature that the product does not in fact offer. Some sales people do this to make the sale and then pressure engineers to add the feature quickly to avoid embarrassing the company.
Defect and omission cases are straightforward to correct: Either correct the code or change the documentation to match what is being delivered. If a sales person intentionally oversells the product, marketing and senior management should take corrective action with the person to avoid the situation in the future. Having single sales people define product direction without the active participation of engineering, marketing, and management will derail the longer-term product planning and hurt the company.
- D: Great Expectations
The customer thinks the product does something that it doesn't actually do, even if your company did not tell the customer that the feature is supported. This occurs when the customer makes unwarranted assumptions about the product. Good customer-facing documentation, marketing collateral, and proper training for the customer should keep this problem to a minimum.
- E: Hidden Capabilities
In this case, the product includes undocumented features that can be unintended artifacts of how the software is constructed. The development team might be unaware of these capabilities. Sometimes an engineer might add such features intentionally without documenting them. Hidden capabilities can be benign unless the customer becomes aware of them and exploits them.
Hidden capabilities should be documented and the cause investigated. If an unintentional side effect of the code creates the capability, it should be either documented as a feature or disabled. If the capability was intentional but added without permission, talk to the engineer who added it to prevent this from happening in the future.
- F: Code Artifacts and Unsupported Features
An artifact describes a behavior that was unintended and covers some aspect of the system that was an unusual and unexpected case. This behavior or hidden feature was not intended to be included in the product. It does not appear on your test systems and is unknown to you.
When a customer discovers code artifacts or unsupported features, big problems can result. Customers can exploit unintended code artifact effects on their systems, and because your company does not support the artifact, it might not appear in the next new release, leaving the customer without that option in the future.
Understanding the customer-use model helps you identify and avoid such problems. Talk to customers about how they use the product to help identify unusual and unplanned uses. Ideally, map out a customer-use model. Understand how your customers use the product.
Unsupported features can appear when an engineer adds undocumented and unplanned features into a release—perhaps the engineer wanted to experiment with a nifty idea. Some customer service and support technicians will hear of this feature and tell a customer that it is legitimate, because they want to help the customer with a problem. To avoid unplanned features, tell the development team that adding in features without approval is unacceptable. See the next section for more discussion of this case.
- G: Missed Opportunities
In this case, the customer is unaware of a feature of the product because the company somehow missed the opportunity to describe the feature and improve the sales potential of the product. You can avoid this situation by fully documenting all features and training sales staff on the most important features. Keep customer-facing documentation up to date to avoid creating missed opportunities in the future.
Finding features in the product that an engineer added without your knowledge is an unpleasant surprise. Engineers will add unplanned features in the product code for three main reasons, all of which are unacceptable:
The engineer wants to please someone (a client, a customer service representative, or a senior manager) but knows management will not approve this feature.
The engineer thinks he knows better than everyone else.
The engineer wants to experiment with a new feature but does not want to ask permission to add it to the product.
Building unapproved features can delay implementation of required features and can hurt your product. In some cases, these unapproved features can force required features out of a release due to lack of development time. Unplanned features can also create inconsistency in the product, because often an engineer will implement them only in one section of the product. Such features often do not fit an overall product definition or strategy. They also ensure big problems for QA and documentation teams because the hidden feature's behavior differs from the documented behavior. Finally, adding unapproved features to a product shows an engineer's disrespect for everyone else in the company.
A small "back-door" feature might increase immediate customer value and please a client. However, your customers will be upset if they try using this feature in another part of the software suite and find it's unsupported: The surprise feature becomes a major problem for your company. When a customer expresses displeasure, you might be forced to scramble to provide support for the feature. Completing support for a feature after the product is released can be 10 times more expensive than creating the feature at the start and providing support. Suddenly, the small change has disrupted your company's next few releases and potentially its future revenue.
If an engineer adds unapproved features to product code, pull her aside and coach her about her action's impact on the product and the company. When talking to the responsible engineer, remember that your goal is not to stifle innovation, but to encourage team discussion of key features before they are implemented.