Transcription
Have you ever struggled to get out of the detail and see the bigger picture? Well, this video is for you.
Because when I was a strategy consultant, I noticed that the best thinkers, they didn't see things in individual parts, they saw them as systems. This is known as systems thinking, and it was a way to level up your thinking.
With systems thinking, it's complex, it's theoretical. So look, I'm not gonna teach you the mind-numbing theory of systems thinking. Instead, I'm gonna give you a five-step process that you can use to apply systems thinking to your work. And to bring it to life, we're gonna use an example, which is we missed this quarter's revenue target because we didn't launch the new product feature in time. So with that, let's jump into the five-step process.
Things never happen in isolation. So the very first thing that you should do is map out the stages, the processes, or the connections between the things that you're looking at. So for our example, where we missed our revenue target because we didn't launch our product feature in time, it might look something like this, which is backlog, then prioritization, then scoping and requirements, then build, then test, then launch. This gives us a model that we can use to see how things influence one another. And it also highlights that there are a number of potential causes of our problem. So it could be something like prioritization was too low, or development time was too long, or test time was too long, or the scoping and the requirements weren't of high quality. There's a whole number of possible reasons. The lesson here is that it's very easy to jump to the wrong conclusion, but by applying systems thinking, by building this model of the space, we can start to see the full range of things that might be going on. Anyway, this model becomes our system. So in the next few steps, we're gonna use it in different ways.
Now we have a model or a system of the space, but that's not enough. What we actually need to understand now is the stocks and the flows. Now stocks are the things that accumulate at each step, and flows are how much throughput there is between steps. Now, I get this is a bit confusing, but it will become clearer soon. In our example, we have a model of product development. So we have to ask ourselves, what's the thing that flows through this model? And in our case, it's product features. Product features begin in the backlog, they work their way through the system, and they come out of the end as finished, launched product features. So now we need to look at the throughput of product features in our system. Now, not in any technical sense, we're not doing any technical analysis here, but we're just eyeballing our system to see if there are any potential bottlenecks for product features. And in our example, we might find that we have plenty of features in the backlog, so the stock is high here, and we are testing features fast, so flow is high here, but there's a throughput problem at scoping and build. The requirements are not clear enough, so developers repeatedly have to ask for more information, which slows down development. The lesson here is that the problems rarely exactly where the symptoms appear, often it happens upstream where the bottleneck is.
So once we've identified that bottleneck, we need to solve it. We just looked at whether any stage of our process or our system has a bottleneck. Now we need to flip that. So we're looking for leverage points. Now leverage points are where a small change in our system has a disproportionate impact. So in our product development system, and knowing what we know about the bottleneck, we're trying to identify which stage of the model gives us the biggest benefit for the least amount of work. So we know that there is an issue in the scoping requirement stage. So spending a couple of additional days writing more detailed feature requirements can save us weeks of unnecessary rework. This would very likely have much more of an impact than adding developers, because development time isn't actually a bottleneck. It's not actually a problem that we're having with feature development. So the lesson here is that we don't just wanna throw resources at the problem. We wanna identify where the best bang for our buck is.
So far we've identified the connections in our system. We have looked at throughput, bottlenecks, and leverage points, but actually systems are very rarely linear. They often have feedback loops. Now feedback loops are things that can speed up or slow down the system over time, which basically means that problems can lead to more problems. With this in mind, great thinkers don't just ask what is happening. They actually ask, how is this gonna change over time? They basically understand that small problems can turn into big problems very, very quickly. For example, as development speed slows due to poor feature requirements, executive pressure increases. Then the team puts in unrealistic deadlines and more work is given to developers, but the requirements aren't clear, so velocity slows even further. It just piles up and piles up and piles up. So by identifying the feedback loop, we can cut off that compounding really early. And the lesson here is this, problems are rarely caused by one bad moment. They're actually caused by the accumulation of problems due to feedback loops. So it's very important that you can identify the feedback loops early and address them. And by the way, if you wanna learn specific techniques for building models like this, you can check out my training program, which I'll link to in the description below.
The last thing we need to look at is second order consequences. Now, second order consequences are effects that happen after making a change to the system. So for example, if we were to introduce a solution, that might then introduce additional problems. Personally, I think this is the thing that really separates tactical thinkers from strategic thinkers. And look, anyone can optimize a small system, but good thinkers, they anticipate new constraints that these changes will make. In our example, we might wanna solve our issue of poor requirements by reducing the amount of work we do at once. We might wanna say that we hit pause on all a BAU work, which is basically bug fixes and minor enhancements and just focus on important strategic features. And that sounds great and probably would work in the short term, but by doing that over the long term, what happens is that you neglect your existing features, competitors catch up and bugs start affecting customer experience. So it doesn't work in the longer term, becomes a second order consequence. So when proposing a solution to the problem, the best thinkers will anticipate and mitigate second order consequences. If you wanna think more strategically, then check out my video where I teach you McKinsey's exact process for complex problem solving that'll be on the left of the screen now, or how you use AI to improve your structured and strategic thinking that'll be on the right of screen.