Software Product Lines
Framework Home
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Organizational Management
Practice Areas
Building a Business Case
Customer Interface Management
Developing an Acquisition Strategy
Launching and Institutionalizing
Market Analysis
Organizational Planning
Organizational Risk Management
Structuring the Organization
Technology Forecasting
Frequently Asked Questions

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

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:

  1. 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.

  2. 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)?

  3. 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:

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

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:

Next Section Table of Contents Previous Section