A New Year’s Revolution for Product Management: What Complexity Science Tells Us About Requirements

John_Holland_and_Complexity_for_RequirementsComplexity science is a scientific discipline that studies the behavior of complex systems. So what does it have to do with software and product requirements? As you’ll learn, quite a bit.  

Almost everything we encounter in the world is part of a complex adaptive system (CAS). John Holland, a MacArthur Fellow and professor of computer science, engineering, and psychology (!) defines these systems like this: “Complex adaptive systems are systems that have a large numbers of components, often called agents, that interact and adapt or learn.”

Doesn’t that describe every project you’ve ever worked on in your life? This also describes every market your company participates in. Agents can be your fellow employees, your customers, or your strange aunt Susan; and any system with more than a few agents quickly becomes a complex system. That’s why complexity science can give us many insights into the way the real world behaves.

One of the primary lessons of complexity science is that CAS’s are unpredictable. This may be obvious when you think about all the strange customer requests you’ve heard, but not so obvious when your boss asks you to predict what the monthly sales of your new product will be over the next 3 years.

We like to think that we can make reasonable predictions about the future. We can’t. This is an incontrovertible lesson that complexity science teaches us: CAS’s are fundamentally unpredictable, and no amount of data will change that. Some of our predictions may be correct, but a stopped clock also tells the correct time twice a day.

Even the smartest experts in the world can’t make accurate predictions about their domain. Here are just a few classic examples (click here to launch a PDF of the source for these quotes), but I’m sure you hear examples every day in your workplace:

“What use could this company make of an electric toy?”
- Western Union, when it turned down rights to the telephone in 1878

“I think there is a world market for maybe five computers.”
- Thomas Watson, chairman of IBM, 1943

“There is no reason anyone would want a computer in their home.”
- Ken Olson, president, chairman and founder of DEC, 1977

“Man will not fly for 50 years.”
- Wilbur Wright, American aviation pioneer, after a disappointing flying experiment in 1901 (their first successful flight was in 1903)

How is this relevant to requirements? Because the reason most projects fail is rooted in bad predictions: poorly-formed business goals, leading to the wrong scope, the wrong budget, the wrong time frame, the wrong objectives.

I am sure that if you trace the reasons for almost any failure, a bad prediction will be at the root. And what Complexity Science tells us, counter-intuitively, is that the solution for bad predictions is not better predictions. The prediction game is a guaranteed loser. The solution is better adaptation and learning.

Once again, this may seem obvious, but most traditional management practices generally limit adaptation and learning due to an inherent belief in prediction.  

Want proof? The next time your project doubles the budget and doubles the timeline, tell your boss that the reason was the inherent unpredictability of complex adaptive systems. That will either get you laughed out the door or fired.

But it’s the truth. An unfortunate response by management to unpredictability is to search for who to blame and punish those people. A better response would be to look at the situation as a key opportunity to learn about their market or company, and praise those who lead the internal revolution in thinking about markets for the company based on this changeable, complex new reality. (But I’m sure that’s not the first thing that comes to mind when your projects don’t hit their projections.)

How does this alter our requirements process? For starters, I’ve written several blog posts on the topic of dealing with unpredictability:

But that’s just a start. Agile development does a great job in making your development process more adaptable, but the agile philosophy must extend to everything you and your organization do: agile project plans, agile sales projections, agile corporate strategy. In general, nothing will go as you originally planned, and that is not a bad thing, because it increases the probability of hitting the target with your customers.

The ideal state for any organization is total transparency, adaptability, and flexibility. Clearly, this ideal will never be achieved. However, it is our job as product managers and leaders to consistently drive our projects toward these ideals. We need to create a revolution by creating the tools and the structures to enable more adaptability. We need to greet the unexpected with anxious joy. Even though we will never reach perfect transparency, adaptability, and flexibility, we will at least tackle the real problems and make real progress, rather than clinging to the hopeless, disproved falsehoods of believing that our success is dependent on how well we can predict the unpredictable.