Product Management For Software Product Lines: An -nsolved Problem?

The goal of this article is to call attention to an area that is yet not sufficiently researched: product management for software product lines (SPLs). Many companies developing standardized software products have adopted product management as a function that coordinates research and development, marketing, sales, and software development. Even though this function coordinates all of these areas, it is traditionally mainly a marketing function and often organized as part of the marketing department. This may be sufficient for "normal" software products, but not in a SPL context, as we will discuss here.

Back to Top

(Software) Product Management

Many companies developing software do not develop custom-fit applications for one customer, but instead develop one or more software products for a relatively anonymous market. This leads to the need for processes that differ substantially from the processes needed for "classical development projects." Among the processes that differ most are requirements engineering (there is not one customer or company supplying the company’s requirements, but potentially thousands of yet unknown customers), release management, as well as marketing and sales. To cope with the processes needed in this context, many successful software companies (including Microsoft, see [4]) have adopted the function of product management. Product management must coordinate many different functions within a company, often acting as a broker [3]. The most important tasks of software product management include the positioning of the products, the alignment of corporate strategy and strategy of each of the products, management of the marketing instruments place, price, promotion and product, as well as communication with customers, support, research, and development [7]. Due to this scope, product management is typically treated as a marketing function.

Back to Top

Pitfalls of Product Management for SPLs

Product management for a SPL comprises all the tasks mentioned previously, but seen in light of the interplay between the technical view of a product line (common technical platform) and the marketing view of a product line (products targeting a similar market, not necessarily technically related) [5]. More specifically, the common architecture and assets make product management for SPLs different and more complicated: the traditional (marketing-oriented) view of product management does not take into account how software is produced. As long as products are developed on a single-system basis, this is acceptable. But because products are interrelated in a product line, the technical perspective must be included. Therefore, product management for SPLs should not be mainly a marketing function but instead must treat technical and market-oriented input equally and simultaneously.

If this interrelation is adequately considered, this can strongly leverage product management; otherwise, it can become a threat to the success of the entire product line. If information on the marketed product line as a whole does not adequately flow to engineering, the product platform will not optimally exploit reuse potential. On the other hand, if information on technical opportunities is insufficiently communicated to marketing, major product opportunities may be missed. This includes opportunities missed when distribution channels and product-related service offerings are not tailored to the different needs of the customer segments targeted with the different members of a product line. Schmid [9] discusses the feedbacks between utility for the customer and utility for the producer (that is, cost reduction and shorter time to market through reuse) in more detail.

Current literature on SPL engineering does not provide any solution either: while literature on marketing/product management focuses on optimizing revenue, literature on product line engineering focuses on lowering costs through reuse. The question of which products to include in the product line is more or less considered input from marketing. For example, in Software Product Lines: Practices and Patterns [2], the Market Analysis practice and the What to Build pattern deal with Market Analysis, Scoping, and related activities, but provide no method for optimizing the product portfolio across both perspectives. PuLSE, especially PuLSE-Eco [8] provides more detail in the steps Product Portfolio Scoping and Product Line Mapping, but this method explicitly relies on a given product portfolio. Developing systematic methods for reliably interconnecting the market and the technical perspective remains a field where much future work is needed.

Back to Top

Solution

Currently, there is no methodologically sound solution for product management of SPLs. Such a solution should simultaneously optimize revenues and costs for the SPL. In marketing science, approaches have been proposed based on linear programming, but since both revenue forecasts and cost estimations are often not very accurate in software development, it remains to be seen whether this is helpful for SPLs. Presently, we assume that scenario-based approaches that integrate managerial and technical decision making are more promising.

Further useful input comes from the SPL engineering approaches mentioned here, combined with software product management literature, such as [3], literature on Innovation Management for SPLs (for example, [1]), and methods to improve the communication between technical and marketing personnel (including quality function deployment as used in [6]).

Establishing effective integration and communication between marketing and engineering departments is a challenge to most organizations because it requires a change of existing work procedures and can lead to a clash of cultures: those of marketing personnel and engineers.

Back to Top

Back to Top