Single Product or Multiple Product Variants?

There is no way to beat the cost of a 1-off custom product… but how often do you make a ‘ground-floor-up’ new product?

The cost argument is true every time, for an isolated product. But how many of your products are really an evolution of something you have done before and, tellingly, for which the engineering community are claiming large percentages of savings through re-use? Does it deliver?

If you can relate to that, then have ever thought about standing back and building the common parts as deliberately designed for re-use and just dealing with the customisations? Did you try it? You have to invest in making it work (which makes it more expensive), but obviously if you are ONLY working on the custom (application) bits for the second (and later) iteration, it must be a LOT cheaper. Did it work? Were you able to configure and deliver product as you expected, for those much improved costs?

Well, it may be obvious, but it’s not as easy as it looks to deliver on this technique, known as Product Lines, but get it right and it really delivers… more than just technically… it changes your organisation, culture and even the business connectivity between marketing and engineering! Planned, re-use without deliberate design doesn’t come anywhere close.

The prizes can be some of 10x productivity, 40% cost, 10x quality, 10x faster to market. Don’t believe me?… then look here or at these cases studies. Lots of industries use these techniques every day, and it clearly should work for those with high product repetition rates, large volumes, closely related functionality and, if you regularly develop similar products, it could for you. What you are doing is reducing the recurring cost burden, and with a wise investment, making it a non-recurring cost.

But if you think about it, it is a significant culture change:

i)                    You are asking the vast majority of engineers to work across-projects, on common (domain) assets, and very few engineers (if any) to work on a specific customer (application) project  – Project managers won’t like that (Loss of power/control).

ii)                  You are asking the company to use the vast majority of project funds as a ‘pool’ to serve the needs of many projects, rather than accounting each on its own, making it much tougher to spend control – Finance won’t like that (Loss of accountability).

iii)                You are asking the designers to define frameworks that are capable of being ‘dressed’ with a ‘pick-list’ of features with potentially sub-optimal connectivity or performance – Architects won’t like that (It’s hard and counter-intuitive!).

iv)                You are asking change control boards to separate scope and decisions for project specific or common changes, the latter needing all project representation to be quorate – Configuration Managers won’t like that (Difficult to make decisions).

There are numerous examples of this working all around us, from automotive assembly lines to software and many Open Source products (e.g. WordPress). The reality is, even if done right, the investment breakeven is reached at say the 3rd product iteration – so you need to hold your nerve.

The keys to delivery are well-documented, but centre around recognising the scope and variation of your market, the alignment of quality attributes and a steely focus on delivering a design that delivers just those patterns of configuration that you need (or forecast you need) rather than building an ‘all possible combinations’ product that drives complexity and huge cost.

Every customer wants a unique product, every supplier wants to deliver what he has, or a minimal change – have the best of both worlds.


Let us help you maximise the business potential of your product and its software

Email me on

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________


Leave a Reply