A 5-step Guide to

Develop a Modular
System
Using the Modular Function
Deployment
CONTENTS
• Introduction

• Clarify Customer Needs

• Identify Functions and Solutions

• Propose Modules and Interfaces

• Define Variants and

Configurations

• Confirm Architecture Feasibility

INTRODUCTION
Modular Function Deployment (MFD) is a systematic approach for
creating an optimal Modular Product Architecture. An optimal
Modular Product Architecture is found through intentionally
balancing all stakeholder’s perspectives. To achieve this balance, MFD
integrates these perspectives into four distinct voices, which are all
considered during the development process: The Voice of Customer,
the Voice of Engineering, the Voice of Business, and the Voice of
Modularity.

MFD can be used to modularize a wide range of different mechanical,

electronic or software products and consists of five steps. This article
will guide you through each of these steps and provide insights on
how you can create the optimal Modular Product Architecture of your
product and business.
1 Clarify Customer Needs

In the first step of Modular Function Deployment, you should get an

understanding of who your customers are and what they care about.

Understanding the customer and taking an outside-in perspective

should be the first step of any modularization project. If you do not
fully understand the customers, how can you know what they want
from your products?

Describe the market with needs-based Market Segments

Firstly, you divide your customers in needs-based Market Segments. A

needs-based Market Segment is a group of customers within a market
who are seeking similar benefits from a product. A common way of
working for many companies is to divide the market in segments
based on demographics or applications. These types of segmentations
are great for organizing sales work and planning the outreach
strategy. But they don’t help us with product strategy, and that’s why
you want to introduce the needs-based segments. To understand the
needs of the customers, you should list the Customer Values that are
important for each Market Segment.

List all Customer Values relevant to your product

Secondly, make a list of the Customer Values related to your product.

A Customer Value is a statement about the experience the customer
desires when using the product, e.g. “I would like my product to have
a long operating life”. It should be formulated as if it was in fact
spoken by a customer and written in a positive manner (more is
better!). Often the Customer Values are similar for all market
segments, but they rate them differently when it comes to order of
importance.

Connect Customer Values and Market Segments through

Customer Value Ranking

When the needs-based Market Segments and the Customer Values

have been identified, you should determine the relative importance of
each Customer Value to each Market Segment. The result tells you
what Customer Values are of general importance for all segments, but
also what Customer Values have a specific importance for one or a
few of the segments. Where you have a large spread in opinions, you
have a need for variance in your product assortment, and you need
your modular system to offer this.
 Tip!

Not only should the needs-based Market Segments include customers

seeking similar benefits from a product, but the segments should also
be distinctly different from each other. If you see during the Customer
Value Ranking that two Market Segments rank the Customer Values
very similarly, you should merge the two segments together.
After all, why would you need two different segments to describe the
same type of customers?

Identify the Product Properties needed to specify your

product

To translate the need for variance to actual measurable product

development specifications, you need to identify relevant
Product Properties. Product Properties link market to technology
and can describe for example performance levels, features, or
functions. The most useful Product Properties are measurable
and controllable by the design of the product. Yet, they should
not be exclusive to or include a particular Technical Solution. The
Product Properties will form a specification for your complete
product assortment and help create a shared prioritization in
your development team. Product Properties are best identified
by deriving them from Customer Values, and you should specify
the relationship between the Customer Values and Product
Properties in a Quality Function Deployment matrix to enable
traceability between the market needs and the technology in
your product.
2 Identify Functions and
Solutions

In the second step of MFD, you ask yourself: what

technologies do I need to satisfy the market needs? To truly
understand the variance needed in the Technical Solutions,
the Product Properties and their Goal Values are key.

Define suitable Goal Values needed to specify the

wanted product range

First, you should define the Goal Values needed for all
Product Properties, to deliver the full range of products
required to satisfy the needs of the Market Segments. Every
Product Property has one or several Goal Values which are
used to specify the future product assortment on a detailed
level. This is easiest to explain by referring to a simple
example:
A graphical user interface can be implemented to fit different
screen sizes, meaning that screen size is a product property
needed to describe the graphical user interface. By analyzing
the Quality Function Deployment matrix you understand that
there is a market need for variance when it comes to screen
size. You decide to offer three Goal Values in your product
assortment, for example 4.7”, 6-7” and 20-30”. Noticeable
here is that the screen size affects both the actual display
hardware as well as the software using the hardware.

Conduct a Functional Analysis to analyze the ingoing

Technical Solutions and their respective components

Now it is time to dive into the actual technology in the

product. What are the main components? And what functions
do they deliver? Sometimes several different solutions are
used to implement the same function, and if there is no real
market need to offer different solutions, the recommendation
is to try to decide on one of them. Do this through Concept
Evaluation, where you evaluate the different Technical
Solutions, both from a market perspective (using criteria
based on Customer Values) and from the perspective of your
company (using internal criteria). Suitable internal criteria can
be for example reduced number of parts (applies mainly to
hardware) cost of sourcing, technical risk, or time to market.
Map variance of Technical Solutions in the Design Property
Matrix

The next step for you is to document the connections between

the system components and the Product Properties in the
Design Property Matrix (DPM). The connections should reflect
how much variance each Product Property drives in each
Technical Solution. Going back to the user interface example,
the Product Property “Screen Size” with three different Goal
Values, could drive development work or in worst case two to
three different implementation variants of the key components
that the user interface consists of. By using different strengths
of the connections in the matrix based on development impact
and variance, it becomes clear which components carry the
most complexity and which Product Properties are causing it.
Tracing the Product Properties all the way back through the
QFD matrix gives us a clear link between market needs and
actual variance needed in the system. If some Customer Value
changes, it is easy for you to see what Product Properties,
hence also system components, will be affected.

Identify Module Candidates based on connections in the

Design Property Matrix

You should use the same reasoning to find the first indication
of Modules. You will most likely have some components
connected to the same Product Properties, which means that
their variance is driven by the same reasons. Maybe they even
co-vary? If these Technical Solutions are clustered together in
one Module, that whole Module will vary for the same reasons.
The Module will be easy to update if there are any changes in
customer requirements, but if there are changes in other parts
of the product, it will probably not be affected at all. Therefore,
this makes it a good Module candidate.

Tip! Of course, some Modules will only contain one single

system component and that is fine. Modularization is not just
about clustering parts of a product into big building blocks, it is
rather about daring to break a system up into smaller parts that
will undergo changes for the same reasons.
3 Propose Modules and
Interfaces

When you reach step three, you already have an idea about
suitable Modules, but they should also be evaluated based on
company-specific strategic reasons. A Module should always be
free of conflicting strategies. On a high level, this means that
there should be no conflicts between Operational Excellence,
Customer Intimacy and Product Leadership. But does this mean
each Module can only be connected to one of these strategies?
No, not strictly.

To fully understand this, you need to go into details and break

up the above-mentioned strategies into Module Drivers.

Module Drivers connected to Operational Excellence

Operational Excellence is connected to keeping high volumes

and achieving economies of scale. But there are different ways
of reaching high volumes and different Module Drivers to
describe this:

• Carry Over: Describes a part that is unlikely to undergo

any design changes during the life of the product platform.

• Common Unit: Describes a part that can be used for the

entire product assortment or large parts of it.
Module Drivers connected to Customer Intimacy
Customer Intimacy represents the need for variance in the
product, but the actual driver for the variance can be slightly
different:

• Technical Specification: Describes a part that carries the

product’s variance and performance properties. For
example, support for different network fieldbuses in a
device.
• Styling: Describes visible parts of the product that
represent identity towards the customer. These parts are
strongly influenced by trends and are often connected to a
brand or trademark. This often applies most to hardware,
since software have few visible parts apart from the UI.
Module Drivers connected to Product Leadership
Many companies strive to reach Product Leadership, being the
leader in the market with a premium brand and a high degree
of innovation. But the underlying drivers can vary:

• Technology Push: Describes a part that is likely to

undergo design changes due to changing demands or
technology shifts.
• Planned Development: Describes a part that the company
intends to further develop, for example to better fulfill a
customer value or to cut cost. The planned changes are
described in the product platform development plan.

Make sure to avoid having Conflicting Strategies assigned

to the same Module
Some Module Drivers are incompatible, as they stand for directly
conflicting strategies. These conflicts occur when there are
different needs for development and/or variance. The main rules
are as follows:

• Carry Over should never be paired with Technology Push

or Planned Development

• Common Unit should never be paired with Technical

Specification.

If you find that there are conflicts within a suggested Module,

your countermeasure should be to break it up into smaller,
strategically clean Modules and make sure to have well-defined
Interfaces between the Modules.
Identify Interfaces between the Modules
For a modular architecture, the Interfaces between
Modules have a vital influence on the final product and
the flexibility within the product portfolio. Evaluating the
Interface connections will be one of the most important
factors when you are selecting a Module concept.

The essential question to ask yourself is: What can Module

A do to Module B? If the answer is “nothing,” no Interface
exists. If there is interaction between the Modules, the next
step is to determine the nature of it. For example: Should
it be an interface that can be called via Internet? Does the
interface have latency requirements?

Tip!
Interfaces are where the action is! They are the most
important control points in the system. For an engineer,
it’s easy to be distracted by system components
because they absorb most of the design work and
determine the cost of the system, but Interfaces
determine performance, risk and value of the system. By
using stable interfaces and standardized protocols, you
can allow a lot of variance and/or development in
certain Modules, without any risk of them affecting the
stable Operational Excellence Modules.
4 Define Variants and
Configurations

You have now created the product architecture that best matches
the Customer Values as well as the company strategy. Coming
into the fourth step of MFD, you will start to configure
appropriate products for your Market Segments.
A Modular Product Architecture is an enabler for efficient
configuration as the product is designed for flexibility of choice.
The product architecture is split into Modules and now it’s time
to decide what Module Variants you need to fulfil your market
needs

Specify the Module Variants needed

A Module Variant is the realization of a Module, that complies
with the function, interfaces, and strategy for the module.
You define the Module Variants in a matrix called Module Variant
Specification, where the Product Properties are connected to the
Modules.
You should make sure that all connections between Product
Properties and Technical Solutions are inherited from the Design
Property Matrix to the Module Variant Specification.
The Product Property Goal Values are used to define exactly the
variants you need to have in our assortment to create the right
Product Configurations.
All Module Variants should exist for a reason, meaning that there
should be a market demand for them.
Example: Mechanical Product Structure

Example: Software Product Structure

When you have defined all Module Variants, it is time to decide
how they should be allowed to be combined into products. The
first step is to create a Generic Product Structure, enabling you
to configure Module Variants into marketable products.

Create a Generic Product Structure

The Generic Product Structure is a node structure, where every
node represents a position in the product’s architecture. For
each node, you may add constraints to limit what Module
Variants are selectable in a specific position.
The Generic Product Structure is a master template that will
give you a consistent structure for all different product
configurations and represents all products that can possibly be
built. If you want to capture pre-defined, reusable
configurations, you should save them in a Configuration Table,
simply listing all ingoing Module Variants in a specific Product
Configuration.
5 Confirm Architecture
Feasibility

In the fifth and final step of MFD, it is time for

you to evaluate the Modular Product
Architecture. Have you created the right
product configurations to cover the present
need of your Market Segments? How will you
incorporate future changes?
There is no coincidence that the MFD method
is illustrated as a circle. When reaching the fifth
step, further iterations should be made to
ensure that all four voices (Customer,
Engineering, Business and Modularity) are
being heard, as well as to keep the Modular
Product Architecture updated and relevant.
Implementing a Modular Product Architecture
comes with a new way of working and will
require continuous improvements.

You have used several tools/matrices to

structure the data in the earlier steps of
MFD. To get the best result of the Modular
Product Architecture, the data in these tools
should be linked together, meaning that all
design decisions can be traced back to the
market need driving it.

Tip!
If the data in the tools can be linked in an automatic way, this
makes it easy for you to update the Modular Product
Architecture if a Customer Value changes. It will be clear
which Product Properties, Technical Solutions and Modules
are affected by the change and a decision can be made about
whether to create a new Module Variant or not. The
standardized Interfaces between Modules secures a flexible
design and protects the Modular Product Architecture over
time.
Finally, you need to set-up a decision process and assign roles
and responsibilities for owning the modules and interfaces. This
is a pre-requisite to govern the value of the Modular Product
Architecture. Now is the time to harvest the benefits of the
modular product architecture and accelerate value creation –
for the customers and for your company!

Overview of the complete MFD hub

The MFD hub related to the four different Voices

 Let Us be Your
Sounding Board

We are passionate about modularity

and complex product portfolios. Don't
hesitate to reach out to us to discuss
your challenges over a virtual coffee.

Book Meeting Here!

Why Modularity?
Are you looking for ways to improve your product architecture? Do you have
problems with unnecessary component variance resulting in declining margins?
Do you spend too much time on fixing bugs, maintaining and testing, rather than
developing new features to stay ahead of the competition? Do you have trouble
with meeting new market requirements that demand varying functionality in your
products? Or are you struggling with implementing the latest technology in your
product portfolio? If you answered yes to any of these questions, modularity
might be the right answer for you.
Modularity is an enabler for many things. For instance, modularity makes it
possible to reach more customers with an extended product portfolio, keep up
with technology shifts, achieving economies of scale, improve software quality
and accelerate agile development – all at the same time. Modularity also can help
with e.g., reducing complexity in a product assortment by increasing the reuse of
components, as well as cut down on order engineering work and reducing
development time.

Modular Management – our story

“It all started in the 1990s, with a team of dedicated researchers at KTH Royal
Institute of Technology and the IVF Swedish Institute of Production Engineering
Research.

We were investigating the drivers behind modularization and how it was being
successfully employed in product design, development, and marketing by a
number of companies including Sony, Honda, and Scania. Using our research, we
built a working model for approaching and implementing modularization in a
structured and effective way. We recognized that our model would have great
value for any organization dealing with different or changing customer needs.
That led us to form Modular Management in 1996 as a product development
consulting firm.

In the years that followed, we developed two more methods: one to quantify the
cost of product structure complexity and another to manufacture a modular
product in the best possible way. These methods led to our growing reputation as
experts in modularity. Today we use 20 methods and over 70 tools to give your
company the best possible support for modularization. Modular Management
Group is an international company based in Stockholm, Sweden, with subsidiaries
in Sweden, U.S.A, Asia and Germany. We’re proud of the results modularity has
achieved for our customers – companies like Whirlpool, Ericsson, ABB and Volvo.
And thanks to them, we never stop growing and expanding our competence.
We’re continuously challenged to improve and develop more methods and tools
that make modularization faster, safer and more effective.”
Alex von Yxkull
Founder, Modular Management