Guidelines on Describing Product Families

1
Guidelines on Describing Product Families

• CORE-project report
• Tero Kojo
• 28.2.2005

2
Contents

• Product Families
• A Process View
• Describing Product Families
• Business Planning, Requirements, Architecture
• Important Aspects
• Conclusions

3
Product Families
4
What are They?

• A Short Introduction into families

5
A Product Family can be Seen from Many Views

• Different stakeholders, different views
• Project manager, Product manager, Different
  designers, Requirements engineers, Marketing
  manager...
• But basically the views should be of the same
  thing, the product family
• Individual products in the family may be closely
  related or more distant relatives
• i.e. only slight variations or larger ones

6
So How Does That Differ from Products?

• Why mass production is not always enough

7
Mass Production is Good

• Mass production gives economies of scale
• However the push is for customer specific things
• Either the customer can make the changes or they
  are pre-tailored into the product
• Products in a family have commonalities and
  variabilities
• That is they have a common base, architecture or
  idea
• But they differ from each other in a way that is
  significant to the customer
• In the product family style the customisation is
  pre-made

8
A Process View
9
Current State

• How are things done now?

10
A Process Just for Reminders
11
The State of Things

• Product families aka. product lines, modular
  products, platforms or component frameworks are
  used in practise
• A technical solution to the problem of handling
  variation in a product
• Marketing likes to present a variety of things to
  potential customers
• However the technical and business views should
  meet more often

12
An Infinitely Thin Funnel
Business planning
Requirements specification
Technical specification
Marketing
13
Possible Solutions

• How could things be improved?

14
Try these

• Increase communication
• Add variability to the descriptions
• We will get to this in just a jiffy
• Use more tables and pictures

15
A Wider Funnel is More Fun
Business planning
Requirements specification
Technical specification
Marketing
16
Describing Product Families
17
Business Planning

• Where it turns out we all want to be different

18
Peculiarities of this Phase

• The material created here will probably end up in
  your marketing message
• Actually business planning is all about families
• As the drive has been to increase
  personalization, product families have been
  forced in
• The family may seem to be more expensive, but it
  enables larger market segments

19
Common Description Types
20
Requirements

• Where our difference is documented

21
Peculiarities of this Phase

• Traditionally the aim in this phase is to drive
  for a single product, not a family
• The challenge is to have the requirements in a
  reusable form
• Support for families needs to be enhanced

22
Common Description Types
Use case UC-1 Meeting friend Actors User and
Friend Main 1. User sees friend 2. User greets
friend 3. Friend replies Exceptions 2b. User
does not identify friend
23
Architecture

• Where the difference should be implemented

24
Peculiarities of this Phase

• As the focus comes to smaller and smaller details
  the larger picture becomes hard to handle
• Traditional product families have evolved from
  the technical point of view

25
Common Description Types
Main design principles 1. Data hiding 2. Use
interface classes 3. Fast response times 4.
Algorithms easy to change
26
Important Aspects
27
One Vision

• One man, one goal, one mission
• One heart, one soul, just one solution
• Freddie Mercury, Brian May, Roger Taylor and John
  DeaconOne Vision - Queen

28
Business books have been at this for a long time

• If the team is focused on one thing it will not
  lose
• If the team does not know what the one thing is
  they will act like headless chicken
• Describe the vision shortly and make sure
  everyone agrees on it

29
But Many not One

• Remember it is a family

30
Many not One in One Box

• Even if you have a single vision, different
  specialists are going to need different views of
  it
• A mechanics designer will not use the software
  designers view
• The designed variability needs to be implemented
• The designers have to be aware that there is this
  thing called variability

31
Upgrade not Death-by-Planning

• Or, why it is bad manners to nit-pick

32
Plan it Right

• Death by Planning is a known anti-pattern
• The planning phase rages out of control
• With the family idea you can improve later
• Especially in leading edge solutions two years
  can make your design obsolete
• Modular design lets you encapsulate the possible
  problem areas

33
Conclusions
34
For the Process

• Introduce variability to the design process
• Your business planners already know, but what of
  the others?
• Document decisions
• When new people arrive they won't be as confused
• Consider both the market pull and technology push
• Where does the information come from and where
  does it go?

35
For the Descriptions

• Keep it simple
• If no-one can read it, no-one will
• Do you have the time to train everyone to a
  description method?
• Remember your Audience
• If you are writing for designers use their
  language
• Use colour and words in a consistent manner
• Do not change the meaning of things on the fly
• Lists, Tables and Pictures

36
Lists, Tables and Pictures
Main design principles 1. Data hiding 2. Use
interface classes 3. Fast response times 4.
Algorithms easy to change
Use case UC-1 Meeting friend Actors User and
Friend Main 1. User sees friend 2. User greets
friend 3. Friend replies Exceptions 2b. User
does not identify friend