Hilights of «Managing the Design Factory» by D. Reinerstsen

Awesome book for those who manages any kind of enterprise, wether it is a small web-design firm or a big company manufacturing smartphones or making enterprise level software.

The book lifts you up to a meta level and gives you the general perspective of how any kind of producing organization works.


But it’s not just the perspective, the book is full of insights on how you can make your producing unit more effective, more profitable, get better time & quality management.

Though insights are quite generic. It’s not a book of practical solutions from a battlefield. It requires you to have a certain level of awareness of what you really do. You would have to analyze and apply ideas to your specific area.

Author bases his theory on 3 other:

  1. Queue theory
  2. Information theory
  3. Systems theory

Information theory highlights

Information is defined as a logarithm of inversed probability of an event.

It means that if you something is going to happen for sure — there’s no information for you in this event (you already know it’s going to happen). And vice versa — if something highly improbable has happened, it brings a lot of new information.

That’s one of the reason behind a long time required to master some field — you have to wait for improbable events, that give you the most of information.

One of the practical conclusion here is how you should test. The most effective tests are the ones that have 50% probability of failure! Those are the tests that give you the most information.

You can’t do everything right the first time. And you shouldn’t test the things you know work for sure. As well as the things you know will never happen.

Your test process need to have an adequate failure rate to generate sufficient information.  If your tests have high success rate, you probably not testing good. Try to move to another level, where errors occur (i. e. from unit to integration testing).

Systems theory

The key to success here is a feedback. Any system with a feedback works as effective as its feedback loop is.

It means you should invest in the feedback loop quality (whatever it means in your system), rather than in the other part of product development process.

For example you should provide fast and hi quality communication between your designers and your clients or art directors, rather than write detailed rules and requirements on your design process.

This is the reason behind the success of agile methodologies — effective communications, proper feedback loop. While strict product specifications and «do it right the first time» approaches don’t work well.

Design the design process

You better have your product development process designed rather than evolved  from chaos. You should design the process from your financial goals.

Product Architecture drives market

It’s not the technical guy who may solely control the product architecture. There are much more expectations from marketing, sales and other departments that depends on what a product would be and how it would be built.

Development and specifications

First, your specifications should be thin. But it is the quality of the specification that makes it thin, not the thinnes that makes it a high quality specification. Brevity is a test of clarity and focus, not the cause of clarity and focus.

Second, your specifications should be driven and constantly tested by your customer (customer preference driven process). Your specifications may change during the design process. Your processes should allow this.

Third, everything is changing. You should incorporate the risk evaluation and process changes in your business processes themselves. Proper feedback, queues management and testing processes can help.

Remember the magic 50% failure rate of testing which produces the most information. This is about testing the design, not the final product (where failure rate should be zero).

Testing the design is about checking wether it meets the customer preferences and expectations (see above).