Reading Time: 5 minutes

Product Development: Keep it Simple!

Main Takeaways

Reading Time: 5 minutes Modern Product Development is complex by nature. You can't simplify everything. Complexity can be beautiful. Nevertheless, the decision to make the product as simple as possible and stripping it down is sometimes the better option.

What makes a product complex? — What are the criteria to classify a product as "complex"? — Can we characterize the shift from a simple product to a complex one, is it silent sneakiness, or even disruption?

The Cambridge Dictionary defines complexity as "...the state of having many parts and being difficult to understand or find an answer to".
Wikipedia characterizes complexity as "the behaviour of a system or model whose components interact in multiple ways and follow local rules, leading to nonlinearity, randomness, collective dynamics, hierarchy, and emergence."

Since the Wikipedia definition gives us more and more detailed specifications I will stick to it. It is also based on Systems Thinking. A product as a system interacts externally with its environment. And inside the product, its subsystems and parts interact mutually. Both interactions react with each other. Small changes may have a big impact and we can’t control all factors, since we can't survey all potential interactions inside/outside.

Blending both definitions might be very helpful for Agile product development.

A complex product consists of many parts (subsystems), it is hard to understand, and it interacts with its environment in its own dynamic and emergence in multiple nonlinear, random ways.

Modern product development is complex by nature. Here are my arguments (an incomplete list):

Inside view: inside the product subsystems/parts react nonlinear, random, and emergent internally. — This affects the product development process directly.
Outside view:
- the product reacts with its environment nonlinear, random, and emergent. — This affects the product development process indirectly.
- our products have to solve modern-day problems and keep pace in a complex, volatile, and uncertain environment (VUCA).
Operational model: in case of proper functionality and in case of malfunction we have to analyze both interaction modes.
Challenge: We have to design product development to incorporate all of these views.
Process view:
- no two problems are the same nor are the approaches to solving them.
- we can’t expect a positive outcome by just coming back with best practices. In complex contexts instead, we have – according to the Cynefin framework – to find good practices. A complex product environment isn’t served well by traditional management approaches (Ageling 2020, Mar. 15).
- product development should be managed based on the outcomes, not on the output (amount of features/functionality) only (Ageling 2020, Apr. 18).
- we gain the best overall customer/user experience when we embrace collaboration across development areas and teams (Ageling 2021, Jan 17).

Working with my clients for more than 20 years, I made two frightening experiences.

The shift – in Cynefin terms – from a clean product to a complicated or even complex one happens to emerge, unnoticed by the developing team, over years.
However, in case, there is a strong feedback loop between the customer/user and the developing firm, there is a small range where the product becomes really more valuable (in the sense of customer/user experience and usability).
Unfortunately, often the complexity comes in because the developers and engineers gold-plate the product by adding more features without customer interaction. Here, we exceed this range, and all of the product development anti-patterns will hit us and the product becomes worse.
This shift is a one-way direction since it’s easier to make a product more complex than to make it simpler. This is caused psychologically: when improving products, people and engineers tend to add new features instead to remove features. They systematically overlook subtractive changes (Adams et al. 2021) because they typically consider a limited number of promising ideas in order to manage the cognitive burden of searching through all possible ideas, but this can lead them to accept adequate solutions without considering potentially superior alternatives.

John Maeda shows the simplest way to achieve simplicity:

"Simplicity is about subtracting the obvious, and adding the meaningful."
"The simplest way to achieve simplicity is through thoughtful reduction. When in doubt, just remove. But be careful of what you remove. … When it is possible to reduce a system’s functionality without significant penalty, true simplification is realized."

– (Maeda 2006)

Ok, this advice sounds obvious, but it is hard how to follow. From the perspective of product development, if we shift from simple to complex consciously and stay by purpose as long as possible in the value-creation zone, we innovate the product successfully. But, being beyond this zone, innovation might fail because we increase product complexity by adding more features than necessary. In consequence, more complexity leads to customer/user experience rot and the end to product death.

Unfortunately, still, often the complexity has its origin in doing Big Design Up Front (BDUF) and much detailed technical planning, even in Agile product development. Often it is caused by upper management chasing half-heartily the agile transition in adopting pseudo-agile frameworks supporting the existing silo hierarchies more than cross-department collaboration.
Products aren't designed to be complex by purpose (well, some were) but because BDUF involves inherently silo development and existing workflow bottlenecks.

"The more you focus on processes to avoid errors, the less you can benefit from agility."

– (Pereira 2022, Nov. 8)

Another aspect that products become unintentionally complex is Conway’s Law. Conway’s Law, stipulated by US computer science Melvin Edward Conway in 1968, says that the complexity of a product being developed mirrors directly the complexity of the manufacturer's organizational design. In consequence, when trying to minimise product complexity we might minimize the organizational workflow dependencies and functional (features) dependencies as well. And here is the crucial pitfall. When engineers intend to reduce product complexity they crash into the glass walls of organizational design and its complacent to change.

When developing products we act in two different complex systems parallel. System 1 is our organization with all its internal working dependencies in development activities, agreements, and workflows we work in. And system 2 is the product itself with all its intended interacting parts and sub-systems we have to implement facing system 1 constraints.

"With large organizations, you will face complexity and may try adding more of it. Don’t focus on complexity. Simplicity is your best ally."

– (Pereira 2022, Nov. 8)

This quote is sound, and obvious as well, but it is hard how to follow the advice. Sorry, David Pereira, I'm not personally, I really appreciate your work. My recommendation is if we can't simplify the organisational design by reducing the product's complexity, we should design our product as simply as possible. Thus we reduce the involvement of thus superfluous departments.

One side effect of the Agile Principle of Simplicity is that it holds for product design as well as for organizational design the workflow needed to build the product.

“Simplicity – the art of maximizing the amount of work not done – is essential.”

– (Agile Principles 2001)

My advice: keep the product design as simple as possible. Always ask you the following two questions: (1) do we need this function really? – (2) if we need the function, how can we implement it as easily as possible?

Contrariwise, we can't simplify everything. Some things can never be made simple. When we eliminate feature by feature, we should always follow the aforementioned quote from Maeda: we shouldn't reduce a system’s functionality only if there is no significant penalty.

Be aware, complexity can be beautiful.

Nevertheless, the decision to make the product as simple as possible and stripping it down to its extreme is sometimes the better option. On the one hand, it reduces the working dependencies (organisational complexity) and makes the product easier to maintain for the developers. On the other hand, the customer/user experience increases when product handling becomes easier. In the end, you get more and happier customers.

Just do less.
Less is always more.
Simpler is better.
Make the product as simple as possible. Reduce your amount of work.

This is the hardest challenge.