For a while now, product management has been undergoing a repositioning. Increasingly, it sits in contrast to the linear build & ship, the drab “feature factory”, and in alignment with the holistic process of designing, delivering, and maintaining a product system with all of its moving parts.
John Cutler, one of the most-cited voices in the Product Management space, is a big proponent of systems thinking for PMs. He believes it’s a form of situational awareness, the ability to understand how your product interacts with its environment, its time and place, its own internal components, and how it may change after a variable in it changes.
Systems thinking was popularised by Peter Senge in his 1990 book The Fifth Discipline, where he defined it as "a discipline of seeing the whole." Senge's formulation emphasised interrelationships over linear cause-and-effect and patterns of change over static snapshots.
The most-recommended introduction to the framework, though, is Donella Meadows' Thinking in systems: A primer (published posthumously in 2008). In it, she defined a system as a set of interrelated components that work together to perform whatever functions are required to achieve the system's objectives.
What does this have to do with building products? Quite a lot. Most systems theory emerged from observing nature, economies, and engineering, but the underlying principles translate directly to the problems product builders face every day.
How does a change to one feature ripple through user behaviour? Why does adding more engineering capacity sometimes slow down a team? Why do some product metrics look healthy while the product itself feels broken? Systems thinking offers a vocabulary and a set of mental tools for asking and answering those questions with more rigour.
In this deep dive, we’re going to define systems thinking in product and explore why it’s an increasingly sought-after skill, where a team can go wrong with it, and the frameworks you need to apply it to your own work.
How can a product be a system?
Rather than seeing products as a set of linear, causal relationships—features affecting users, measurements determining objectives—systems thinking looks at products as a network of user behaviours and needs, business goals, financial objectives, and features that are constantly interacting with each other. Change one and everything else changes, too.
A ProductPlan's conversation with John Cutler and PM director Annie Dunham captures this well: today's product management dynamic "defies structure, organisation, and the linear-oriented, waterfall processes of the past." Modern products don't have a beginning, middle, and end. They exist in ongoing ecosystems, interacting with users, markets, technology, and other systems simultaneously. Systems thinking helps PMs understand how a product works as a whole and how decisions create cascading effects across that ecosystem. It can’t “fix” your product problems, but it can present you with new solutions.
Systems thinking is one of the most sought-after skills for PMs in 2026
Systems thinking, as a framework, has been around for ages, but recent changes in product work, and, more broadly, in the tech landscape, have turned it into a highly desirable skill. Hiring data reflects this. According to Figma's research, 47% of hiring managers now rank systems thinking and service design as a top-five requirement for new hires, with one surveyed designer noting that "AI has automated a lot of surface-level design work. Now the value lies in systems thinking and the ability to translate complexity into clarity."
The consensus in the PM community is that the role, overall, is changing, in large part due to AI. Though it is taking on parts of discovery, prioritisation, drafting, testing, and updates, AI still doesn’t understand how its own outputs move through a larger system. Therefore, it’s now part of the PM’s job to figure out how a product decision affects engineering complexity, how a design shortcut affects user trust, how a faster shipping loop affects quality, and so on.
Unlike classic features, which are fairly predictable, AI features are probabilistic and require processes adapted to higher levels of complexity, interdependency, and emergent behaviour. This brings with it big changes to traditional product workflows and basic concepts. Failure, for example, stops being a one-off crisis that can be fixed and forgotten about and instead becomes a system to be understood and managed over time.
On the technical side, product complexity has grown, too, from managing a single codebase to managing a network of interconnected technical, regulatory, organisational, and environmental layers.
The One Knight in Product podcast summarised this well: "Systems thinking is important for product managers trying to make sense of their product or organisation. Nothing is linear, everything is composed of self-reinforcing loops.” They advise that PMs see themselves as part of the system they’re managing rather than a separate entity or change agent.
In online communities, some PMs believe systems thinking is the key to making yourself harder to replace, while others see it as a welcome addition to the toolkit, but hardly anything new or exceptional.
One redditor commented: “In an era where you can [spew forth] an infinite number of prototypes and systems faster than ever, someone has to be looking at the big picture and thinking about how it all plugs in together. If you can be that person, that's going to be an edge.”
Another believes in using systems thinking as a mental model to get an alternative—though not necessarily better nor more practical—perspective to a problem.
They went on to elaborate with an example: “Say you're a PM in charge of a KYC solution and are tasked to improve conversion. Possible answers from the non-systems thinking mental model might suggest reducing the number of pages or steps in the flow because it focuses on the ‘parts’. Using a systems-thinking mental model might come up with ideas such as integrating a CRM flow to persuade and remind users to complete their process or put incentives like earning $$ front and center during the flow because it focuses on the interactions between the parts (the app itself, Human Psychology, Marketing, and Commercials).”
The fact that this comment is three years old shows that systems thinking is not a recent trend in product management. What’s new, however, is the increased demand for this specific skillset and the resulting uptick in influencer content trying to teach it.
As you might already know, product management has an influencer content problem. Like with any other framework, relying too heavily on systems thinking can have its downsides.
Where teams can go wrong with it
The biggest challenge is making the time to see the method through and gaining buy-in from stakeholders who may not initially appreciate its value. In fast-moving product organisations—especially startups—there's a real tension between the pace required to ship and the depth required to map systems properly.
This is what John Cutler jokes about when he describes himself as a "systems overthinker": the same capacity that helps you see the whole board can become a reason to delay everything. And, generally speaking, organisations resist ponderous, time-intensive processes that don’t return immediate results.
It can introduce top-down thinking
Academic critiques of systems thinking note that it can marginalise community-based perspectives by prioritising technocratic, top-down approaches. In a product context, this can look like building a model that’s more real than the product itself and doesn’t take into account its users’ messy, human reality.
Worst case scenario, this causes product teams to lose touch with customers; best case, you spend a lot of time and money managing the model rather than the actual customer experience, with little to show for it.
It can end up being dogmatic and rigid
Systems thinking is a practice, not a solution. Meadows herself considers the points model an invitation to think more broadly about change.
For teams, there’s the risk of internalising The Framework (™) so completely that they stop questioning whether it works for a given use case. For product leaders, the risk is using the methodology as a veto tool, an excuse to turn down every approach that does not involve a full systems map before acting.
An overabundance of frameworks doesn't necessarily lead to better work and systems thinking is no exception. When the LinkedIn PM universe has collectively decided that "systems thinking" is the skill to have, it stops being a way of genuinely engaging with complexity and becomes another skill to post about. And anyway, the point of the methodology isn’t to “get it right”, but to help you see the system more clearly.
To that end, we’ll now go over some of the main concepts and how you can apply them to your own work.
Three key concepts
1. Feedback loops
A feedback loop occurs when the output of a system becomes the input for future actions. In practice, it can look like this: your product has great customer service > you earn lots of positive reviews > that gets you more customers > you get more revenue to invest in excellent customer service.
The consequences of a decision circle back and influence what happens next, sometimes in ways you didn't anticipate. That’s why it’s essential to find and understand feedback loops in your product system before intervening in any way.
There are two kinds: reinforcing loops and balancing loops. A reinforcing feedback loop amplifies change, for better and worse, while a balancing loop resists it and tends instead towards a target or equilibrium point.
Spotify's music recommendation algorithm is a good example of a reinforcing loop: the more a user listens, the better the recommendations become; the better the recommendations, the more the user listens.
Balancing loops, on the other hand, tend to preserve the status quo within a given system. A good example would be an organisation that’s always in fire-fighting mode.
When there is a crisis in one part of the company, resources get pulled from other teams to try and return results to at least a non-crisis level. Usually, these resources come from a team that’s doing particularly well. But then this lowers their performance, putting them in crisis and requiring resources from another part of the system. Over several iterations, the system stabilises somewhere just above crisis level because resources are always in short supply and flowing towards the next area that’s on fire.
Understanding the feedback loops driving your product system can shift your troubleshooting from “what’s causing this?” to “what structures are producing this pattern?”.
2. Bottlenecks
A bottleneck is a point in a system where the flow slows down, causing a buildup behind it. Solving bottlenecks often leads to the largest improvement in performance, even more than optimising other parts of the system.
A good example here is a food delivery app that’s trying to scale up its order volume, but something seems to be stuck. The PM doesn’t know it yet, but the bottleneck is a too-slow restaurant preparation time, not marketing or retention. In fact, tweaking those will only make things worse.
Though it might not seem like it at first, the worst thing you could do as a PM here is add supply to an already-constrained pipeline. You’d only be moving the pressure upstream, without removing the bottleneck. The solution is, of course, to tackle food prep times; treat the true cause rather than the symptoms.
Facebook's famous "7 friends in 10 days" insight is a good historical example: rather than spending more on acquisition to fix low retention, the team identified the true bottleneck (users needed to form social connections on the platform and they weren’t, yet) and focused there. The retention problem later resolved upstream, since it wasn’t the true bottleneck.
3. Leverage points
Leverage points are places in a system's structure where a small, well-aimed change produces a lasting shift in the entire system’s behaviour. If you picture a system as a ball of knotted cables, then a leverage point is where you can start disentangling them.
With a complex product system, linear approaches usually fall short. You don’t want to tweak a single feature, so much as understand what about the product system is making users behave in a certain way. Therefore, leverage points help reframe the common question: “Why doesn't adding new features fix our core problems?" to something more actionable.
The concept comes from Donella Meadows, whose 1997 essay "Leverage points: Places to intervene in a system" (later folded into Thinking in Systems) proposes a hierarchy of leverage points, going from least to most impactful.
On the bottom tier, we have adjusting parameters (tweaking features, prices, budgets, and similar isolated interventions). These are usually the least effective leverage points because they produce local changes.
Next, we’ve got changing the way things are connected within a system; in a product, that’s user and information flows, UI, interaction architecture. This kind of intervention takes a holistic view of the product and is therefore more effective.
The next most impactful type of leverage point is related to system goals and objectives. In a product system, this means a strategy shift and would usually happen during annual roadmap planning.
Finally, the deepest and most effective kind of change is at the level of mental models on which the system is built. This can look like organisational change or shifting the user problem your product is trying to solve.
A note of caution from Meadows, however: the most impactful system changes are also the slowest and most difficult to execute. At this level, moving in the wrong direction is more dangerous than a low-leverage mistake, because it deeply affects everything else.
For example, changing your product roadmap is a Tier 3 leverage point (i.e. shifting the system’s goals and objectives). Therefore, it will take more time, alignment meetings, and overall resources than a lower tier change. If it later turns out to have been the wrong decision, you’ll have a more expensive mistake on your hands than simply tweaking the wrong feature.
Product practitioners have been using these concepts for at least ten years at this point. In 2017, we highlighted a keynote talk by Johanna Kollmann about systems thinking at MTP Engage Hamburg. In it, she guides the audience through understanding the system before trying to change it. Her tools and frameworks are familiar: observation, note-taking (for example the User Journey Mapping method), and spotting trends and patterns that indicate what’s going on.
Johanna’s suggested solutions include tracking feedback loops, clearly defining your metrics, and knowing where and how to intervene (leverage points).
She zeroes in on the way information flows through a system as being one of the toughest and most rewarding leverage points. Controlling what information is made available, to whom, and who can manipulate it can be critical to product success.
Practical applications
These core concepts translate into practical things you and your team can do to level up your product work.
1. No specialisation without system awareness
A team can make one part of the system faster while making the whole product, platform, or organisation worse. You can improve one feature while making the overall product experience worse for a majority of users.
This applies to the people you work with, too: an engineer who understands product context can tell when a piece of AI-generated code solves the ticket but damages the product model. Similarly, a product manager with knowledge of architecture will avoid asking for a feature that creates months of hidden complexity.
These are examples where systems awareness works together with specialisation, making the product better off for it.
2. Consider the second- and third-order effects of new features and changes
A good systems-thinking PM learns to ask “and then what?” at least twice when considering the interdependencies within a product. That’s because, while the first-order effect of a decision is usually obvious and easy to measure, the second and third orders aren't, and they’re the ones with serious downstream consequences.
A recent Forbes Tech Council piece even suggests second-order thinking, as a skill, is valued more highly than systems thinking overall. According to its authors, PMs can leave the context retention part of systems thinking to an LLM, while they map out the possible second- and third-order consequences of a given product decision. To be completely honest, this is a pretty reductive view of both product work and systems thinking, but it serves to highlight the job market desirability of second-order thinking skills.
3. Designing for AI products specifically
Systems-thinking is better suited to AI products as it prompts PMs to ask different questions, like: "If users start interacting differently, what second and third-order effects will emerge?", and "How do we design products that get better, but not more complex, as the AI learns?".
4. Teams and organisations are systems, too
Just like the product exists in a system, so does the team building it, and the organisation around it. John Cutler notes that PMs are often sharp systems thinkers when it comes to their customers but self-described "over-thinkers" when they try to apply the same lens internally. He's advocated — most recently at INDUSTRY 2025 — for treating internal company processes as a product in their own right, designing them deliberately, iterating on them, and measuring them.
The same principle applies to team structure. A systems-thinking PM will work better with mission-based teams than project-based ones that complete a project and are done. When you understand your organisation as a system, you design for its resilience and knowledge distribution, not just its immediate output.
5. KPIs and metrics design with system well-being in mind
Most product metrics are local to one part of the system, like engagement, conversion or revenue, without accounting for what happens to the rest when you optimise one of them. Systems thinking, on the other hand, takes into account the product and the system that created it, and avoids a myopic overfocus on vanity metrics.
Increased of focusing on billing targets, for example, or engagement as an isolated metric, PMs may want to look to customer referrals, as a signal of durable growth. The logic here is that referrals capture something about the whole system's health: trust, product quality, and user experience all at once.
Conclusions
Systems thinking isn't new — its foundations are decades old — but the conditions that make it essential for product work have never been stronger. Products are more complex. AI makes linear thinking actively dangerous. The PM role is evolving toward orchestration, judgment, and holistic problem-solving, and the job market is starting to notice.
A few things worth taking away:
- Products behave like complex adaptive systems, where interactions determine outcomes.
- Feedback loops, bottlenecks, and leverage points are the vocabulary for understanding why a system behaves the way it does, and where you can intervene.
- Second and third-order thinking helps you consider wide-reaching consequences. Ask "and then what?" at least twice before shipping.
- AI products are probabilistic, which means teams without systems thinking will keep treating structural failures as isolated bugs.
- Systems thinking applied badly can be slow, top-down, or dogmatic. The antidote is Meadows' own prescription: humility.
From a PM reflecting on building AI products in 2026: "Once you recognize these patterns, something else becomes clear: none of this is new. Meadows described these same system dynamics decades ago. What persists isn't a lack of solutions, but a tendency to treat systemic issues as isolated events."
The core lesson, if we had to pick just one, is about seeing products as networks of relationships to be understood and designed. That’s what the best product thinkers are already doing anyway, whether or not they call it systems thinking.
