A Framework for Software Product Line Practice, Version 5.0

Customer Interface Management

During the development of complex systems, there are dependencies and commitments among the producers of products (including products in intermediate stages of production) and the people for whom these products are intended–that is, the customers.

Customers have requirements for and expectations of what the producers will provide and may communicate them either in a highly structured fashion (such as in a formal requirements document) or in an informal way (such as when an interdisciplinary integrated product team has producers and customers working side by side). In the case of a commercial product produced and mass-marketed for end-user consumption, the "agreement" is the one between the vendor and the perceived demands of the marketplace, possibly gathered through surveys or interviews with proxy groups standing in for the customer community at large.

Understanding and managing the commitments between your organization's producers and customers will require your organization to manage its customer interface. Doing so involves knowing answers to the following questions:

Who is involved? Who are the customers or customer representatives? Customers are sometimes represented by individuals who portray particular facets of the customer's overall interests, such as legal, financial, technical, operations, or training. Which groups or individuals are responsible for interfacing with customers? Typically, they might include marketers, product managers, requirements engineers, architects, or a user group coordinator. Identify exactly who is responsible and clearly define their roles and responsibilities.
What information will be communicated and delivered? What are the product offerings, and what variations are available? What are the cost, schedule, and quality benefits of doing business with the organization? What is the strategy for evolving the product(s)?
How is the information communicated and delivered? What policies and procedures apply to customer interactions? How are customer requirements to be negotiated and managed? How will a consistent interface with the customer be enforced? How is the customer to be kept informed of schedule, budget, progress, and unexpected problems?

Managing a customer interface also involves ensuring that those in the organization with customer responsibilities are trained properly in their roles and applicable processes.

Aspects Peculiar to Product Lines

Organizationally, the customer interface must be managed from a multiple-product, multiple-customer perspective as opposed to a single-product, single-customer (or single-customer-base) perspective. This means that those responsible for interacting with a particular customer about a product must act on behalf of both the customer and the product line organization at large.

Over time, customers will want new products or features and ask the product line organization to add to existing products. These requests will have to be evaluated from two dimensions: the feasibility of carrying out the desired changes and the desirability of including them in the current or future development cycles. The product line's scope will address the first aspect, while a business case will address the second. From a strategic perspective, features that have widespread appeal represent tangible opportunities to expand the product line.

These considerations mean that some of the traditional customer-interfacing roles will have to extend their interaction to consider the entire product line. For example, the architect and requirements engineers certainly need to understand the requirements of each individual customer. But they also need to understand them in the context of the overall product line. They may even need to "nudge" a customer's requirements where possible to gain closer alignment with the other products in the family, so as to achieve higher usage of the existing core assets and achieve faster time to delivery and lower cost.

The following table identifies a set of product line roles, the activities they typically involve, and some artifacts they commonly use in their customer interface duties.

Typical Product Line Organization Roles Involved in Customer Interface Management
Interfacing Role	Typical Activities	Example Artifacts
marketing, sales, financial, and legal personnel	Explain product line offerings. Explore the customers' requirements. Prepare proposals and conduct preliminary negotiations. Represent the interests of the organization in contract negotiations.	marketing plan, product proposals, product offerings, specifications, other marketing collateral, requirements input to product management plans, upgrade plans, legal and contractual documents
product manager	Represent the product developer to the customer. Be responsible for the customer's product and all liaisons with the customer after contract award. Be responsible for finalizing negotiations and coordinating efforts across the product line organization. Be responsible for overseeing all the programmatic aspects of the customer interface, including the specification, development, delivery, and acceptance of the customer product.	technical proposals, product specifications, schedule and cost data, work breakdown structure, technical documentation, status/progress reports, action item tracking, issue resolution, product deliverables
program manager	Be responsible for the business success of the product line.	business case, forecast, cost/pricing models
senior technical staff members (domain and architecture experts)	Assist marketers, product managers, and customers in defining the technical specifications of product offerings and negotiating tradeoffs in requirements affecting cost, schedule, and quality.	domain model, functional specifications, architectural views, quality attributes
systems/software product engineers	Deliver and install product upgrades. Assist customers in resolving operational problems and provide training and technical consultation.	product releases, technical advisories, trouble reports, training courses
user-group coordinator	Work with customer groups to collect product requirements that meet the collective and prioritized needs of users.	customer workshops, strategy sessions, customer operational plans

For example, those who interact with a customer to sell a product go about their jobs in quite a different way in a product line organization. (In this passage, we'll call these people "marketers," but in some organizations this activity might be done by business development staff, product managers, sales personnel, or others.) In many software organizations, the marketers court customers by promising (and then pricing) the features that the customer requests. In a product line organization, however, the marketers have a responsibility to the entire product line and its customer base. For example, after listening to a customer's requirements, the marketer assigned to that customer must first understand if the desired product is in the product line's defined scope. If so, then all is well, and the marketer can promise delivery with confidence. If not, however, the marketer must interact with the technical staff to assess the proposal's technical feasibility and cost. The response to the customer must now be negotiated based on whether the organization wants to work on a product that is outside of the product line's scope. Perhaps the new product represents a funded opportunity to move into a desirable new business area. Or perhaps the opportunity cost of this new product is too high, and the organization would be better off negotiating contracts more in line with its production capability. In that case, the marketer must now negotiate with the customer about the non-conforming requirements. Or perhaps a customer will be willing to abandon out-of-line requirements once he or she knows their added cost and risk. In any case, the decision should be justified and documented in a business case (see the "Building a Business Case" practice area).

Aspects of the customer/development organization interface necessitated by a product line approach include the following:

Communicate the product line strategy to the customer. Provide the customer with information and guidance on product features and capabilities, customer-configurable options, and future development goals, objectives, and strategies. Communication involves educating the customer to encourage desired behaviors, helping the customer understand the rationale for deferring product requirements in order to reap cost, schedule, and quality benefits, and moving the customer toward acceptance of a customer relationship that is similar to a commercial, off-the-shelf (COTS) supplier model. The interface with customers becomes market driven and no longer focuses on an individual customer's specialized requirements. Specialized requirements can be accommodated but must be considered individually and have special cost and schedule implications to which both parties must agree.
Enforce strict product line organizational interfaces and operational procedures (see the "Structuring the Organization" and "Operations" practice areas). In particular, customer requirements for one product cannot be allowed to unilaterally supersede those of other products without considering what is best for the product line overall.
Encourage customers to choose from standard product offerings, relinquishing some flexibility in return for cost and time-to-market advantages.
Help customers form user groups to give the market a voice and drive requirements for product evolution jointly.
Institute a protocol for managing customer requirements on a product line (not an individual product) basis, and, through training, compel both the customers and the product line organization's personnel to follow it. The roles, responsibilities, and processes involved with the customer interface should be documented as part of the product line's operational concept (see the "Operations" practice area).

Application to Core Asset Development

If core assets are produced by a separate organizational entity, in many ways that entity comes to resemble a software development organization of its own, with the need to manage its own customer interface. To a core asset group, the customer is the set of product-building groups, and the same issues apply. Individuals working across the interface must be identified, their roles and responsibilities identified, the interface defined, processes for interaction defined and followed, and training provided.

Some software product line organizations actually make their core asset base "open;" that is, they allow other organizations to use it (for a fee) to build their own products. In this case, the core asset group has a customer interface to the outside world that must be managed along with its interface to its customers inside the organization.

Some of the core assets in the core asset base are aimed at the customer community; for example, marketing literature, sales support, product catalogues, feature descriptions, and cost and schedule information. Other core assets are a direct result of customer input; for example, market analysis, requirements specifications (including the common look and feel of the products), and the product line scope.

Application to Product Development

The organization's customer interface comes heavily into play in requirements negotiation for a product or set of products. A healthy customer interface will allow a customer to negotiate in the context of the benefits and limitations that a product line approach can provide. From the organization's side, it should be able to offer high-quality products of demonstrated capabilities and performance with predictable delivery dates and predictable costs.

Moreover, a product line organization is in a better position to produce "whole" products that include accompanying artifacts such as robust training materials, support, and documentation (that are backed up by standards and procedures), extensive test cases, and a proven operational track record. Since these associated product artifacts come bundled with the customer's product, from a marketing standpoint, they are touted as being "products with a pedigree" [Moore 1991a].

Example Practices

Establish an overarching customer interface process for developing work proposals and negotiating new contracts: At a minimum, this interface should cover roles and responsibilities including marketing, customer negotiations, contracting, customer liaison during product development, delivery of products and product updates, communications and problem resolution, product support, training activities, and other customer support functions.

A customer's request for changes in a product may or may not be within the product manager's authority to approve. Minimally, the customer's product manager must first determine if the request could be satisfied through existing product line components. If not, the product manager must determine if the product line manager believes the requested capability is likely to be needed in the future by existing or new customers. If that is the case, the capability can be developed with the rigor necessary for reusable components and added to the core asset base for the product line. Typically, this kind of unanticipated product decision would require the reallocation of resources or a downstream adjustment in product enhancement planning. The process needs to include safeguards to ensure that the established policies, procedures, and protocol for customer interactions are followed. This process must address issues such as

How are the potential architectural ramifications of a customer's requirements taken into account in the requirements negotiation process?
How are conflicting requirements or priorities reconciled across the products in the product line?

Provide centralized product support to customers: This support should include coordinating changes in requirements, providing fixes for operational problems, and managing multiple (new) product releases across the customer base. An essential piece of the customer interface management practice is providing ongoing product support to meet the operational needs of the customer. Such support typically begins with the product line organization that is responsible for helping the customer plan the system installation and ensure that all the required elements are in place. Support is then available for the installation itself. Once the system is operational, ongoing maintenance fixes may be required to stabilize the new system in the customer's operating environment. Ongoing support may also be available to help customers install product enhancements or major upgrades. In the product line organization, some of these responsibilities are centralized so that efforts to fix, test, and release product updates are not replicated. Fixes for one customer are compiled and released for the benefit of all the customers of that system.

Finally, the support organization is in the best position to track customer installations and configurations. This information is useful to the product engineering organization in planning the distribution of new releases, as well as to the marketing organization as a means of identifying opportunities for the sales of upgrades or new systems.

Establish a user group, or other liaison means, to help the product line organization identify and prioritize its customers' emerging and long-term future needs: The product line organization should encourage customers to form user groups to jointly manage the evolution of its products and drive product line requirements so that upgrades can be provided to all of them at a lower cost than would be possible individually. In user groups, customers who were once separate entities with no common interest have an opportunity to influence and work out requirements for future product upgrades jointly. From the standpoint of the product line organization, user groups represent an opportunity to maintain a tightly controlled product line capability by providing its customers with a forum for adjudicating their differences and migrating its products as a collection rather than as a set of disjointed products. Both sides benefit: the product line organization can continue to produce products that closely match its product line capabilities, and its customers can acquire their products more economically.

Practice Risks

Poor customer interface management can undermine the integrity of the product line and jeopardize the organization's market share. If customers are not paid enough attention, the products will fail to meet their needs, and the customers will go elsewhere. If the customer interfaced is not managed at the product line level, the organization will fail to take advantage, in a systematic way, of the customers' inputs. Poor customer interfaces can result from any of the following:

The organization fails to recognize the extent of the customer interface and its effects: A fundamental risk is that an organization will not fully realize the extent of the interface or the extent of the cultural changes that must occur on both sides to establish a healthy and mutually productive customer relationship. This risk could lead to a failure to exploit common requirements, customer alienation, and an eroding customer base.
The organization reacts to transitioning to a new business paradigm with discontent and resistance: Shifting responsibilities and the narrowing focus of new positions may not be welcome changes for many individuals in the product line organization. Satisfying individual customers, possibly at the expense of the product line, is a powerful incentive to undermine the product line approach. The result will be business as usual. Investments in internal promotion and capability development reinforce the organizational commitment to the change and provide team members the opportunity to change with the organization.
Marketers promise the world and fail to point out any tradeoffs that are involved: When pressed by their customers, marketers must learn to point out any key tradeoffs that are involved so that the customer can make fact-based, objective decisions. Failure to do so will result in dissatisfied customers and (in turn) unhappy product developers.
Marketers and product managers are insensitive to specialized customer requirements: A product line organization must ensure that the pendulum does not swing too far away from individual customers' needs. This is a key dilemma for the product line organization–that is, how to satisfy the specific needs of one customer without significantly impacting the product development momentum within the development group. This problem requires analysis by a cross-functional team to assess the impact of the requirement and make recommendations to management.
Customers fail to recognize benefits properly and see only the loss of flexibility: Some customers will be unwilling to give up the control that they associate with conducting business with a systems organization. They will continue to demand that systems be built to the full desired functionality, regardless of the cost, schedule, or risk benefits that a product line approach delivers. In the face of this inherent conflict, the product line organization and the customer will need to make a decision about the viability of their long-term relationship.
The product line organization releases a scheduled product upgrade to all customers that includes unannounced changes that cause sporadic problems for customers: Forcing unwanted changes on customers will alienate them.
The organization fails to enforce the interface: In organizations with poor product line discipline, customers may have direct access to development staff and may coerce or cajole them into producing specialized features just for them. While such direct connections make those customers very happy and enhance the organization's reputation for responsiveness, they almost always work to the detriment of the larger product line effort. They short-circuit the product planning process and result in work that satisfies small short-term goals at the expense of much larger long-term ones.
The customer interface staff is not trained properly: If representatives are not oriented toward product line operations and miss culture changes, or if representatives are not knowledgeable about the product line strategy and specific product capabilities, the result will be a customer community that is not properly indoctrinated into the benefits of the product line paradigm.
Customers with their own agendas dominate user group forums so that other users or customer communities are not heard: If this is the case, the result will be product line requirements that become skewed artificially in the direction of the dominant customer at the expense of the needs of other customers in the installed base.