Reduce Product Portfolio Problems with Variability Management

When one product succeeds, the idea for a variant quickly comes up, and soon a new product family starts scaling. This is good, but often struggles when it comes to bug fixing or feature dependencies. A solution approach can be found in variability management.

Abstract

Making the first product of its kind is difficult. Making the next variant or version is difficult in another way. Latest with the 2nd variant the teams realize that some bugs are in the 1st variant also, because both variants have the affected feature in common. Doing the bugfix twice increases the effort, slows down the release cycles and may cause further bugs. The way of making the first of its kind usually doesn't scale directly.

The best approach for scaling is to manage the "commonality" of all product variants in a way that it exists only once and can easily be reused for all. Then a bug is done once and also fixed once. The "specialty" of a product variant should be managed in that variant only, because it exists only there. "Variability" is between commonality and specialty. It happens when something could be this way or that way, e.g. a vehicle door handle is needed for the left and the right side, so some parts are mirrored. The affected feature "door handle" should have a corresponding variation point. A variation point defines the options and the time when the decision has to be made.

For managing platform based product family engineering it is essential to design the product family variability with dedicated variation points. Therefore defining the high level "product needs" and designing a "feature tree" to suit those needs is essential to decide which product variants are needed and which feature combinations and feature variants make up those product variants. A premium vehicle will have more complex feature variants than a mainstream vehicle of the same platform. Maybe the customer can select features and their variants in an online configurator. Then the dependencies need to be designed by constraints (include/exclude conditions). To validate typical configuration sets it helps to define "reference products" within the platform. This also simplifies later testing of individually configured variants.

So while it first looks like standard requirements engineering, architectural design and component development, just with some variation points added, in fact it makes a real paradigm shift. While the detailed engineering doesn't change, the overall view to a product is completely different.

Details

This big diagram is similar to the one above, showing some more arrows, comments and structure. It is explained below piece by piece, while each piece again shows some more details - just like zooming in.

The left half of the diagram represents the platform with all requirements, derived from the needs and clustered according to the feature model (yes, I consider a "feature" technically being defined by a set of requirements). The platform is technically structured by an overall architecture, that describes all variants by designing the variability using variation points. The components derived from the architectures and built according to the requirements may represent a single feature or may support multiple features.

Dedicated sets of features and feature variants select the components that are integrated to make reference systems, representing typical groups of future product variants, e.g. premium products or purpose-focused products. This simplifies testing, because as much as possible test results should be reused: testing is very time consuming and should be redone only after changes. The final product variants will be close to one of the reference systems, but further customized, specialized and configured.

Consider different lifecycles for platform and for application: the platform is maintained continuously in many short iterative incremental cycles, ideally in an agile fashion by multiple teams at a time, working on different features and components. The final customer product variants may be done in a classical project style, because they are done pretty much straight forward and quick anyway, because they reuse maybe about 70% from the platform, that is already developed, tested and proven in earlier product variant projects.

So while multiple teams work in a scaled agile fashion to improve the platform steadily, other multiple teams work in parallel classical customer product variant projects on top of the platform. This must be harmonized by an >overall organization<. Therefore the middle axis of Needs, Features and References is a kind of interface between the product family platform and the product variant projects, and it can be used as a common communication language by all participants. In other words: This is a real opportunity to map the agile technical platform nerds to a classical product portfolio sales management vice versa.

Within the platform perform regular >lessons learned sessions< (maybe as Retrospectives after Sprints), while within the application they can be performed after each project. Have in mind that the focus is different, and don't mix it up. For overall improvement "in the middle" overall sessions may be performed after a new Reference has been created, which is not often and therefore worth the time of maybe three days to involve the experts "from both sides" in an extensive >Open Space Technology< event.

For "Needs" and "Requirements" in addition to the different levels of abstraction the view is also different: "Needs" rather look at the problems to be solved, at the use cases of the customers, to figure out where support by a product is needed. "Requirements" look at the product to be build, at the technology to be provided to suit the needs as solutions of the problems.

Collect innovation needs from the market by scouting initiatives and influencer inputs. Collect improvement needs from the market by consumer interviews and sales questionnaires. Collect new opportunities from research and engineers.

Do not only consider the functional or non-functional product requirements, but also >additional requirements< from regulatory standards, corporate processes and organizational constraints.

The collection of needs defines the scope of the product family, that may be different to other product families within the product portfolio of the company. Therefore, which each new input and each change the scope of the product family and each product variant must be reviewed and maybe redefined, maybe even by scoping sessions on multiple levels.

The defined scopes with the corresponding needs are an essential design input for the feature tree, that finally shows commonality and specialty of the products within the product family. If a company starts making an innovative mobile phone and adds a low-cost variant later and then starts a second product family for tablets, maybe one day a mini tablet is not needed anymore, because the largest phone maybe offers more features for even lower price. This fictional example shows also how product families within the company product portfolio may interfere with each other.

It is essential to manage a feature model that defines the dependencies on a hight level, i.e. which feature includes (requires) which other feature, and which feature excludes (contradicts) which other feature. Tools can help here of course, e.g. >pure::variants from pure-systems< or >Gears from BigLever Software<.

It is also essential to derive reference products that are never sold, but clearly represent different types of product variants, e.g. as showcase for improvements, as test base for changes, or as "all-in" for certification.

On the technical level analyze the requirements to design the most suitable technical architecture. As shown in the big diagram the requirements are derived from needs and clustered to sets according to the features. The feature model structure also should be analyzed for finding a good architectural design, containing the needed variability by variation points. Thereby, it is not an architecture for only one product, but for variants of multiple products. The variation points should be related to the variation points of the requirements. Dedicated tools can help here, e.g. pure::variants (see above) provides plug-ins for IBM Rational DOORS (requirements engineering tool) and IBM Rational Rhapsody (architectural design tool).

When deriving the components from the architecture also the original requirements must be considered of cause, also for creating the needed variability. For software components this variability could be an #if for conditional compiling as early binding, or a runtime-if for parameterization as later binding, depending on available memory, runtime, etc.

In the diagram the terms are given in plural by purpose, because we need to consider a systems of systems discussion and domain discussion for each aspect. An embedded system may cover domains as software, hardware, housing, mechanics and lighting (if it is a vehicle LED matrix head lamp). A vehicle system may be divided into ECU sub-systems for dedicated purposes, so one must always consider the abstraction level of system scope.

The domain components are developed one by one according to decisions from feature model, technical architectural design and requirements, including variability or not. In case of total variability it may be only a reusable frame that is to be filled by the final product variant project, e.g. for a crypt algorithm only known to the final team. In case of alternatives it might end up in multiple similar components, e.g. for different sort algorithms. In case of variability there might be some parameters to be set correctly by the final product variant project, e.g. for limit values that depend on the environment. In case of clear commonality it might end up in a single fixed component to be reused as is, like traditional single project development.

If the final products are almost completely different (no commonality), then the platform approach doesn't help, but then we are also not looking at a product family. If the final product variants are almost the same it might end up in a single configurable product, where the platform approach also doesn't really help. So it is important to decide from feature model, technical architecture and component development, how much commonality, variability and specialty the product family shows, to decide about tools, teams and methodologies. These decisions should be considered system for system and domain for domain also. Maybe the software is quite different, but the housing is the same. Maybe the software is almost the same, but the housing needs lots of different adaptors.

The components finally need to be integrated to a product variant. Due to strong dependencies between components in different variants and versions this should be done incremental in frequent iterations (Continuous Integration). Therefore it helps to define reference systems that will never be sold as products, but that can detect dependency problems, that can show the improvements to potential customers, that can be tested for later reuse, and that can be used for certification also.

Depending on the complexity of the systems stack, the domains, the number of components and the degree of variability this can make more or less trouble. Key is a good understanding of the product family engineering (also called product line engineering) as it is roughly shown here, driven by some highly sophisticated tools and also somehow described in the regulatory standard ISO 26550 et al.

I have seen a small efficient team of 9 developers driving a good platform based product family approach for 29 variants of their small embedded systems product. Before they estimated half a year for the next product generation. Then they switched to the product family approach, created a platform, derived the variants and did all that in less than half a year!

I have also seen international teams of 250 developers with a complex automotive embedded system for driver assistance with fairly different requirements from multiple OEMs, and also with totally different release dates - there it took almost 5 years to educate the teams (and it was more difficult for the managers), to setup the platform, to perform the testing on the reference systems and to finally create suitable product variants. But now they can derive much more product variants in much shorter time, and thereby efficiently make many profitable projects at once.

The final product variants that are to be delivered to the customer depend on the real requirements of that customer. If it is a market of end users the own company usually decides what is in and out and when it will go to market. That is the easy case. When from supplier position multiple huge companies get the product variants they will tell requirements and also timing. That is the harder case. Then the components, that meet the required features, are to be integrated and the rest of the variability has to be bound to meet the customer requirements.

Binding variability may mean to fill stub platform components with secret customer algorithms, design adaptors for the housing or calibrate hardware. For testing, focus on the individual work of the product variant project to validate the customer needs, because the reused stuff from the platform has already been qualified by the reference systems of the platform and in earlier customer projects. Consider Continuous Delivery approaches to satisfy the customer in steps and get early quick feedback often. Pass feedback to the platform for bug-fixing, optimization, adjusting the variability, improving features, etc.

Depending on the type of products in the product family the result of the customer product variant project is directly delivered to the customer (e.g. in custom software development) or a factory with a production line has to be build, a supply chain has to be established, and the products need to be produced and qualified in volume over time. Also for production, thinking about variability management is often beneficial. The former is what e.g. agile software companies have in mind, the latter is what e.g. automotive suppliers have in mind. Both can benefit from this systematic product family variability management approach to reduce many product portfolio problems of the company.