1. Make tradeoff decisions

“Most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.”
– Jeff Bezos

Why it matters

Making tradeoff decisions is a behavior that enables fast development speed (short time to market) during complex decision making such as prioritization.

The human brain is wired to compare options. We are capable of making tradeoff decisions at a rapid pace and with good enough precision if we simplify the decision making process to compare between options. This is especially true if you compare this with doing nothing, or seeking yet more information, which can cause analysis paralysis under complex and fast moving conditions.

Moreover, making tradeoff decisions by always comparing the upside with the consequence is a good habit. Remember, what might seem like a good decision in isolation can be a bad decision in the system you are operating.

Tradeoff decisions improve transparency, which enables faulty assumptions to surface quicker.

Better be “roughly right” than “precisely wrong”

A classic application of making tradeoff decisions during Agile product development is choosing which features to prioritize. While the cost and benefit implication of each feature (using absolute terms) can be complex, analysis paralysis can be avoided by simply comparing the features with each other (trading off Feature A for Feature B).

By focusing on the tradeoff decision, we can speed up the decision process and thereby development speed. This gives us the option to learn and adapt, even if our first call were to be proven later to be imperfect.

Making better system level decisions

“We need to cut costs in our department by 15%.” In isolation, this might seem like a strong and straight forward move. However, this is just weighing in the cost side of the equation. What are the system level consequences this will cause? When we compare this with the consequence, you might see it in a different light:

  • “Cut cost by 15% and take the consequence of increasing lead time by 40%” (by scrapping expensive test equipment that is not fully utilized)
  • “Cut cost by 15% and take the consequence of increasing people churn by 5%” (by not being able to pay key people market compatible salaries)
  • “Cut development cost by 15%, and increase product life cycle operation cost by 100%” (by choosing cheaper raw materials with inferior quality that require higher maintenance)

Give the consequences above, will you still make the call? When making a tradeoff decision, the sensible thing to do is to tradeoff the pro side of the equation with the con side (in this case the lower department cost vs. the system level effects).

System level optimum tradeoffs can be decentralised in scale scenarios through decision rules. A real example is the development of the Boeing 777. The 777 had a maximum weight which had been pre-agreed with clients (the weight of a plane correlates tightly with operating costs such as fuel consumption).

During the development of the 777, Boeing realized that they would exceed the maximum weight. They calculated the value of improving 1 pound of weight of the plane and shared this as a decision rule with their designers.

This meant that any designer was authorized to increase unit cost by up to $300 to save a pound of weight. This decision rule enabled the engineers to achieve the total weight requirement of the plane, and more importantly, without slowing down the development pace.

Practices

  • Always compare the gain with the consequence, avoid focusing on just one of the parameters.
  • Compare options. The human brain is wired to make relative comparison of options quickly.
  • System level tradeoffs can be leveraged using decision rules.

References

The Principles of Product Development Flow, Second Generation Lean Product Development, Donald G.Reinertsen, Celeritas Publishing 2009, p. 42.