Systems thinking in product development
Since I first learned about Systems Thinking I see everywhere processes that can be modelled as systems. The models are always simplifications of the real processes, but those visualisations allow me to start seeing events in a different light. I can then use the techniques available in Systems Thinking to dig deeper and, most importantly, to decide how to act on the system.
Events, loops and the innovation process
Systems Thinking helps us to visualise and understand complex systems with many interrelationships, like an economy. Me, and you, are another example of an immensely complex system that can, at a high level, be modelled with inputs, stocks and outputs.
Systems are everywhere, and systems and collections of them are really always loops in real life. Most systems are not simple cause and effect chains. They go on in circles, one part affecting another. In the same way, there is no beginning or end to an innovation process (system).
Consider for example a new service, product or feature that a business releases today: it will affect the products coming out from its competitors and potentially from other markets, and from providers. It will also change how consumers behave, which in turn will change how organisations in that market behave. All these changes will in turn affect the next move of the organisation.
What does it all tell us in practical terms? In my opinion, the most important point is to avoid thinking of innovation as a project: something that starts today and finishes at some point in the future with a new feature or product in the market. Innovating should be a continuous process that responds to changes in the system it belongs to.
Innovating with the Iceberg Model
Product development projects are often started by events, like a competitor launching a product that threatens your own, by requests from commercial teams, trends in your analytics metrics, or even some customers asking for a new feature (sounds familiar?). We are reacting to what others do, trying to protect ourselves from these changes in a part of the system, but it is easy to forget seeing the system as a whole.
Working in that reactive way, we can only see events happening here and there: we keep steering the boat in one direction or another reacting to the waves, but we are not seeing the currents on the route ahead.
If our knowledge of the market gets deeper, we may get into action when we spot patterns of changing consumer behaviour. An opportunity or a thread in the future will be the spark that puts efforts in place to innovate. It is an improvement: we now have a route to follow.
The levels we want to reach though, are those of the systems structure and the mental models (see the Iceberg graph above). Thinking in terms of systems can help us to understand how our market operates and can see how tiny changes in one place will have a snowball effect into the future and in far away places. We’ll see opportunities and threats that others simply cannot see or understand if they are looking at causes and events in isolation.
When our knowledge gets even deeper, we not only have a hand on the material side of things out there but also how we humans behave in that context and what to expect from us and from others. This insight is what we seek in innovation processes when we interview an audience in-depth, analyse data and compose behavioural models. We test assumptions and create hypothesis based on what we see and what our intuition (based on deep understanding) tells us: it is the nirvana of the innovation strategy.
Complexity is a key characteristic of systems (and of innovation)
That’s why we have Systems Thinking in the first place. In complex systems, every part affects the whole, and the whole is more than the sum of its parts. Systems are also interconnected with each other, making systems of systems, and on an on ad infinitum.
In my latest experience in product development, helping organisations to do market and user research, I often come across teams conducting AB tests on an existing product and failing to get anywhere with them. In a good part, this is because of the complexity of the system at play: those AB tests don’t tell us why the differences in behaviour happen, so we do not improve our knowledge of either the part or the whole of the system.
Another drawback with this type of feedback is that we are again concentrating in the events and their causes: a change in our product causing a change in consumer behaviour. In order to understand systems, as we saw, we need to see the loops, the interrelationships, the complexity. We need to be comfortable not knowing all of it too. Sometimes, we know what we don’t know, but we never know what we don’t know that we don’t know (the Unknown Unknowns).
Growth limits
You pull a lever somewhere to increase growth (say, sales), but the effects are weak, if any. You increase it even more. And more… with the same weak results. What is happening? Why are we not seeing the results of our actions?
Donella Meadows gives the soil for agriculture as an example of growth limit (the soil can be modelled as a system too). You can add nitrogen to help your potatoes grow, but it won’t have much effect if the limit to their growth is potassium. And indeed, you can add as many chemicals as you want, but if in the process you harm the microorganisms living in the soil, you are going nowhere.
There are many interrelated limits to the growth of a system, and it is impossible in most systems to model all of them, let alone control them. The best we can do is to have in place good feedback systems so we can correct as we go.
In The Lean Startup, Eric Ries touches on a related point. He describes how startups often focus on some metrics and push their teams towards goals on those, but often those metrics are what he calls “vanity metrics”: the number of sign ups, or the number of visitors to your website, or marketing leads... But the actual business figures stay the same (net profit, for instance).
The most confusing thing in this scenario is that those same metrics probably where at some point in the past good KPIs, but not any more. They have reached their growth limit, and the system does not respond to increases in that area any more. Solution? Know your system.
Bounded rationality — the problem of the common green
I think the classic example used for explaining bounded rationality is still the best one. Imagine a small rural village with a common green that is used in a rota by farmers. When it is your turn to use the green, it makes sense for you to take there as many sheep as you can, trying to maximise your time using it. But of course every farmer will sooner or later do the same thing, eventually putting in danger the viability of the grass on the green.
Back to our digital world, take this scenario: a newsletter is put in place and visitors to the website are forced to decide to join with a popup. “It works very well” says the web leads team, “we have increased subscriptions by 230%!”. But they are not the only farmers in this common. How is that growth impacting other metrics of the website? (say, visitor retention).
Each team makes decisions that are good for their area, with the knowledge they have, and they are getting good feedback for them. But no one is worrying about the effect on the whole of the system. This is bounded rationality: rational decisions for a small context, irrational for the larger one.
To fight the problem of bounded rationality we usually need someone who takes a view of the whole, and works on knowing the why behind the data.
In product development, we can avoid bounded rationality by working with multidisciplinary teams and doing research and testing that tells us the “why” behind the causal data. Thinking again about the example of the newsletter popup: if you interview a handful of users, you will learn that some are subscribing out of frustration, others are counting on just marking the emails as spam as soon as they arrive. Yet some others may like the idea of subscribing to the newsletter, and be grateful of having that popup notifying them. You now have some knowledge of the loop that is going on, and you can see how that small change might be affecting other metrics.
Rock’n’Roll non stop
Another key attribute of systems is that they can run forever (sometimes). These loops can be self-reinforced or self-balancing, depending on whether they tend to grow exponentially or whether they tend to be in equilibrium.
The important point is that they give feedback to themselves. In our previous example of the logging business, the system will tend to get to an equilibrium between the trees in the land and the sales of wood products. As the input gets more scarce, the output will be more costly and hence have less demand, which will slow down the input.
This never ending process is important when we think of innovation, which is another endless self-reinforcing loop, growing mostly exponentially (that’s certainly the case in technology).
If the system does not stop, it means we cannot stop acting on it either, if we want to control it to some degree. What we need is information. If something changes the input, we need to know it so we can adapt our stock and output. If the audience changes in attitudes, that will affect our output and in turn we need to optimise the system. When the system changes enough, say a disruptive competitor, we will need innovation in order to make a big enough difference in the system.
Information flows and delays
Delays are not good. Delays mean that we change something in our product, only to see no feedback of it for some time. We react to it, change the system again, and again we are left in the dark for some time until we get the feedback. Your instinct will probably tell you to increase the reaction times, but we cannot rely on our instincts here. Indeed we need to do the opposite: slow down, not act faster. We need longer term data, with averages and smaller confidence intervals.
We have all seen this happening when product teams react to requests from users, releases from competitors or sudden changes in commercial figures, translating them as fast as they can into new features.
Without enough quality data, we will find ourselves steering our boat in all directions, as you react to changes (the boat analogy is very handy!).
The Innovation System
You can see below a simple visualisation of the process of product development as a system (my interpretation anyway, there are many possibilities): our input is the business and market needs (sometimes we have raw ideas that are already available, based on those needs). The outputs are the tested prototypes. Whether they go well or bad, they give us valuable data. That’s our currency in Innovation: knowledge of the market.
Our stock is the knowledge of how our ideas (or prototypes) play out in the market: the data coming back from testing those ideas with end users. The more stock we have, the easier it is to come up with more output. The output is affected by the stock, but mainly by the reaction from people using our prototypes, which in turn increases and changes our stock.
You can see that we have a self-reinforcing loop, in which the more output we get from the system, the greater the stock, the better the output, which increases our stock… Innovation improves innovation.
If you think of the innovation process in this way, you can see how it is a never-ending loop that affects itself.
Thinking in Systems
If you are interested in learning more about systems thinking, you cannot go wrong with Donella Meadow’s classic “Thinking in Systems” (affiliate link).
Donella’s postomous non profit, The Donella Meadow’s Project, also offers on its website some free resources on Systems Thinking: http://donellameadows.org/systems-thinking-resources/
