A business's product catalog is made up of the products which it offers to its customers. When such products are related by one or more reference architectures or shared elements, the collection is called a product line, or less formally, a family of products. Each family of products is designed to respond to a spectrum of customer needs, including positioning for offering a stream of more cost-effective derivative products over time. The approach which produces these collections is known as product family engineering, and it requires focusing on the core characteristics that will satisfy the broadest set of applications within the planning horizon established for each offering.
Businesses adopt a product line strategy to simplify the complexity of their development efforts and reduce development and sustainment costs for the collection of products. This strategy is effective because derivative works realize greater economies of scale through reuse of components and development artifacts, increased utilization of production capabilities, and acceleration of important feedback within a given timeframe. In highly competitive markets, additional benefits may be achieved through a broadened customer base (such as by expanding access to new markets), an enhanced ability to adapt to changing market conditions, and improved resiliency in response to external threats. once established, further product line extensions can be used to diversify or add additional depth.
Let's explore an example of product-line engineering in the Ford Motor Company, one of many companies which employs a product line strategy. Ford and its competitors strive to create distinctive features which will appeal to more customers so the business can gain market share. Since many automotive engineering disciplines are involved in automotive design, it typically takes 3-5 years to converge on a design solution that can be economically introduced into service. Ford has done this many times throughout its history, and hundreds of automobile models have been produced. As the automotive industry has matured, the competition between such automobile manufacturers has steadily increased. This competition has driven consolidation within the industry so that marginal businesses are absorbed into a smaller, more efficient set of competitors. Over the last 50 years alone, the marquees of Mercury, Edsel, Merkur, Jaguar, Aston Martin, Volvo, and Land Rover have become members of Ford's product family.
When Alan Mulally became Ford's CEO in 2006, Ford's competitiveness was in question, and he was faced with a diverse, geographically distributed collection of brands which each had a a proud history and a loyal (but shrinking) customer base. Ford's existing product catalog was no longer economically sustainable. The initial step in engineering any product line involves 'right-sizing' the reference architectures that are actively being developed or supported. This right-sizing assures that the solution space for future products is appropriately bounded and rationalized, so that reuse can be focused on the most economically viable members, and can gain traction as a foundation for future development. The book American Icon describes how Alan positioned this right-sizing activity for the rest of his leadership team:
Mulally understood that Ford’s global operations were too complex to be run centrally out of Dearborn, but he also appreciated the tremendous cost savings and efficiencies that could be gained by eliminating duplicate efforts around the world and creating real economies of scale.* During one of his first press conferences, Mulally was asked if Ford was considering a merger. “Yes,” he said. “We’re going to merge with ourselves.”
As an aeronautical engineer, streamlining was as dear to Mulally as pork to a politician. He had spent his entire professional life figuring out how to reduce drag and improve aerodynamics. Now he began applying these same principles to Ford’s product portfolio. He asked for a chart showing every car and truck the company made around the world. To his dismay, none existed. So Mulally went to the websites of each of Ford’s divisions and printed out pictures of all of their offerings. Then he asked his secretary for scissors and glue. When she brought them, she found Mulally sitting at his conference table with printouts spread all over it. He took the scissors and started cutting out pictures of each vehicle made by Ford and its subsidiaries. Then he divided them by region and started pasting them together on pages like a kid working on a school project. When he was finished, Mulally counted them all. Ford and its subsidiaries were making and selling ninety-seven different nameplates around the world.
Way too many, Mulally thought as he studied his handmade charts. He picked up the scissors and started cutting again.Mulally would later share his charts with Ford’s board of directors. Before their December meeting, he commandeered a conference room and mounted blowups of them on the wall. When the directors had gathered at World Headquarters, he ushered them into the room. Mulally stood there silently as they studied his handiwork. As he expected, they were as overwhelmed as he was by the dizzying array of cars and trucks. Mulally had no trouble convincing them that Ford needed to radically simplify its global lineup.
As customers, we only think deeply about such consolidation if it impacts us directly (like when the product we use is discontinued). Instead, we tend to mentally categorize the components and subsystems which make up a car, even when we only have a cursory understanding of the true nature of the components themselves, or how they interact, even though we use the functions and become acclimated to their performance so that we can drive without thinking about it at all. We might know the chassis holds all of the components together, but are clueless of the vertical and lateral loads which must be transferred in order for the car to even stay on the road.
Unless we actually have design experience in building automobiles, we rarely stop to think about these components much, though we may often use names for one or more categories of components as if they were interchangeable designs. This ignores the fact that different models rarely share the same vehicle frame, engines, doors, or wheels, let alone other parts. Yet if we probe our mental models, we soon discover they are incomplete and inadequate; for example, in the depiction on the right (click to expand), where exactly do lights appear in the components listed? Where is the instrumentation? How many lights are there? And what are functions do each provide (illumination, warning, indication, Etc.)?
If we completely disassembled a car in our driveway, it would be hard to argue that there wasn't still a car in that pile. Yet in this disassembled configuration, it would not serve our needs very well as transportation. If many different car models were disassembled at the same time, and the parts were all mixed together, we would still have the same number of parts and cars as we began with. However, it could be quite difficult to determine how the various parts all fit together through trial and error. Each assembly of components like this depends upon design cohesion in order to work properly, a bill of materials, and technical drawings that explain the assembly instructions to put each car together. It isn't enough just to have parts that are categorized as similar, as they are depicted in a component model of a car; they must be the right set that matches all the other parts as a collection, so everything fits and works together properly. Within cars, the backbone designs that do this are are called automotive platforms, and as end users, we often don't even know they exist.
As customers, we buy vehicles expecting that these details have all been sorted out in the design, and with confidence that they have been assembled and verified as being a complete, operationally useable configuration. In the record-keeping performed by manufacturers, this delivery configuration can be traced to the vehicle identification number (or VIN), which designates the manufacturer, the details of the vehicle configuration, and enables the specific instances of parts which were manufactured and assembled to be tracked over time. This configuration includes information on the vehicle's type, automobile platform, model, body style, and engine choice. Each separate VIN thus establishes a baseline of components for the various subsystems that make up the car, which documents the selection of components at a particular moment in time (such as when sold). Over time, operational vehicles evolve to become combinations of original and replacement parts. But you aren't likely to reverse engineer what the valid combination of components are by looking at a few operational vehicles. TO be done properly, there is a need for a top-down structure; this fact exposes the underbelly of incremental development for a complex, new product; agile development techniques are much more likely to be successful once an overall product structure has stabilized, and the required features can be attacked concurrently.
When an organization seeks to consolidate its product lines, it needs to find a way to reason about which parts of these product lines share common characteristics, by evaluating the utilization, performance, and operational functionality of the products in their catalog and portfolio. This analysis should examine where each product is in its design, production, and support lifecycle, and what forces are expected to shape the future evolution of these offerings. Organizations also need a way to reason about the structure, economics, and features of these offerings which are most desirable to emerging customers, make reasonable projections of revenue from these products (under both optimistic and pessimistic business scenarios). From this foundation, they can then determine alternatives for how product line offerings would be evolved over time, through additions, consolidation, deprecation, or evolution.
Ultimately, these activities require decisions to be made about where variation is appropriate and where it is not warranted. Tradeoffs need to be performed between functionality that is basic and stable, and specialized tailoring necessary to individual situations. For this consolidation be successful, the reference architectures need to be sufficiently defined so that an engineering analysis of alternative configurations can be performed, and the functional integrity of current and future offerings can be preserved as the consolidation proceeds. The additional levels of discipline that are required to share and manage common components across products as they all undergo evolution is often not given the attention it deserves.
The book A Framework for Product Line Practice describes the kinds of behavioral changes which must be carefully introduced into organizations which want to adopt a product line orientation. Technical [W:product management] must harmonize the means of development and production for both products and their related core assets. It must also provide the necessary project management elements for the production plan to be reliably executed. Manufacturing and operations units must also be involved, since they must integrate and assemble the core with all products that reuse or tailor them. In addition, product line management depends upon several key practices which distinguish product line engineering from traditional engineering:
- distributed configuration management of change, through hierarchical controls
- parametric estimation of options and configurations
- feature-driven engineering across planned application areas (since many more cooks will want to stir the pot)
- more robust specification and fulfillment of the right combination of parts needed for each particular situation (this may involve use of a configurator)
The efforts required of many different stakeholders must be integrated as these practices are performed, and aligned with product requirements, architectural direction, and component specifications. Existing software may require considerable code refactoring and deprecation of particular instances or features in order to have an appropriate foundation for proceeding. Work package owners must commit to produce and support core components over the lifecycle of all products. The planning required for this covers a wider range of topics, and must be more robust than plans for individual projects; otherwise, dependencies may make the entire business susceptible to a single failed launch of a shared element that is not ready when needed.
As another example, consider the Boeing Yellowstone Project, a widely reported effort to right-size the company's product lines. Many different alternative configurations need to be defined and evaluated in such efforts to discover the right balance for candidate solutions. A reduced set of candidate configurations must then be elaborated sufficiently to find the right mix of risk and reward. Customer development and follow-on detailed design activities can then be focused on the areas with the highest and most accessible value.
Adopting a standard cadence can be helpful to channel feedback from such product line efforts to where it is most appropriately incorporated, without delaying the velocity of either core asset development or product development. When manufacturing must be performed, operations management must anticipate production constraints and develop an effective strategy for maneuvering within these boundaries. The authority for decision making must be sufficiently responsive to allocate and provision organizational units with the resources they need. For this to all work, organizational sponsorship must also be highly visible so that adequate resources are available for both the development and sustainment of these core assets, and their integration into product development activities. A product line champion must also be available who will sell the concept and keep it sold.
A coordinated release schedule can help assure that timely feedback can be incorporated across the ongoing iterations of core asset development and new and derivative products. Support teams of the core assets must be capable of quickly responding to emergent issues, as they are uncovered. The usage and field experience from these core assets must be tracked and communicated back into the organizational units responsible for the products which incorporate those assets, with enough credibility that finger-pointing is minimized. Gradually, the high value functionality at the periphery of the systems which use these core assets will migrate to the core, once the utility and feasibility of such solutions have been validated. It is then that the real leverage from product lines can be realized - features appear almost by magic, paid for by as many revenue streams as possible.