I've seen good products fail because the PM optimized the product in isolation — great UX, solid metrics, clean roadmap — but didn't model how the product would interact with the broader system it existed in.
Systems thinking is the practice of understanding how components of a complex system interact over time. For PMs, that means seeing beyond the feature and understanding the incentives, feedback loops, and constraints that shape how users, customers, and the business actually behave.
Here's an example from enterprise SaaS: early in the AvaSense build, we designed a workflow automation feature that significantly reduced the time supplier managers spent on manual compliance checks. Adoption was strong. But when we looked at the downstream data, something was off — the accounts with the highest automation usage had lower renewal intent scores. The automation had removed the friction that previously prompted regular collaboration between supplier managers and their vendors. We had optimized the wrong metric.
This isn't a failure of execution. It's a failure of system modeling.
The skills that help: causal loop diagrams, stock-and-flow thinking, identifying feedback loops, and — most practically — asking "what happens when this scales?" and "whose behavior changes as a result of this change?"
I've come to treat this as a forcing function: before I write a PRD, I draw the system. Not the feature — the whole system the feature lives in. The users, their incentives, the adjacent processes, and the second-order effects. Most bad product decisions look obvious in hindsight. System modeling makes them visible before you ship.