Rule of three - How to make design decisions without getting a hangover

The road to Hell is made with Good Intentions. Our education as developers, engineers, physicists or academics in general is characterized by learning to make well-considered decisions, develop solutions and then justify or explain these solutions. This works quite well for simple tasks. But does this still apply when the complexity increases?

When complexity increases, when external influences are added, holding on to the wrong decisions can become toxic under certain circumstances. Take – you guessed it – the example of product development.

Basically, we make a design decision at a point in time when we don't yet have all the information, and we carry that decision through to the end. Of course, it is fatal if some of our decisions are flawed or imperfect and if the requirements are not completely clear or the influencing factors are not 100% understood or we have simply made a mistake, we will have difficulties in the later development process.

The fatal thing is that in most cases, the people involved had the best intentions. Experienced engineers who had developed products many times before. Highly intelligent technical experts who knew their way around the depths of their domain. Newbies, old hands – they all rush into things, make design decisions quickly, argue brilliantly for their actions, and at some point on the road to their goal, problems arise that had not been seen before. Or that have been added. Or, or, or.

It is human to want the best. It is human to draw quick conclusions based on experience. Our brain loves to work with little input. Unfortunately, the universe doesn't really care whether these quick conclusions are correct. And the market certainly doesn't. And yet it is the experiences and learning curves that we seek. We gain experience and learn so that we don't have to keep reinventing the wheel.

What can you do to reduce the risk of making quick design decisions that lead you down the wrong path? For this purpose, I have introduced a simple rule in development projects: the rule of three. I can warmly recommend it to every development manager and every developer. It was a pleasure to hear in a very interesting lecture on industrial design the other day that it is common practice in design studios to implement this rule, albeit under a different name.

The rule of three is based on the following principle: for each technical problem, we develop three different solutions and then select two of them, which we then work on in parallel as far as possible.

When I tell this rule, it always generates objections: “Why do the same work twice or three times?” “Nobody wants to bear the costs!” “I can't think of anything better!”

But once you've got used to it, you realize that you've achieved two things. One is that you force yourself to think outside the box, because if I have one solution, then I just need a second. Secondly, and this is often forgotten by critics, you have to think about how to make the interfaces so that both approaches are transferred into the big picture. The power of this concept can be illustrated with a simple calculation: if I have two components that are to be connected to each other – for example, a wheel with a wheel suspension or a chassis with an engine – and I design two possible approaches for both the engine and the chassis, and then further develop them to a certain extent, then I already have four different combinations in the project, but at the end of the day they all represent a solution for my customer. Two solutions with engine A and two solutions with engine B. If there is a delay in the development of engine A, if the price goes up, if there is a delay in delivery or if there are new requirements that cannot be met with it, I can still switch to engine B.

I would like to point out one more thing: this is not about hedging. It's not about always having a plan B and using this plan B to ensure that I achieve my project goal. If I do that, I won't get any innovation in. No, it's about pursuing different approaches and thereby broadening your view and ultimately finding the right projects and the right solutions.

How far you should take the rule of three is, of course, up to each organization. Too much will break any budget, but too little won't achieve anything either. Have you implemented these or similar approaches in your organization? What has been your experience? And, if you are familiar with the original problem, how do you solve it?

#Innovation #ProductDevelopment #EngineeringDesign #RuleOfThree #Complexity #DecisionMaking #Leadership #DesignThinking #SystemsEngineering #ContinuousImprovement #Scrum4Hardware