I remember sitting in an Environmental Studies class during my first year of engineering - a no-brainer for extra credits. You mugged up basics about pollution to get through tests, and that was it.
Then walked in an unusually energetic professor, Mr. Dhar.
I don't remember most of what he taught, given the nature of the class, but one idea has stayed with me ever since:
Every problem is a system problem.
Quite a generalized claim, but he explained it with a garbage capacity problem.
Suppose a city identifies a critical waste management problem in 2010. A proposal is drafted in 2013, approved later, and finally implemented in 2017. Infrastructure like a garbage disposal system is expected to serve a city for the next 10, 15, or even 20 years. Yet the capacity planning is often based on input levers from 2010. The system works—for a while. Then it starts failing again, and definitely not linearly.
Even if we assume the system was designed perfectly, it's unsustainable because growth from feedback (population explosion here) is faster than the system can learn from it. By the time the feedback loop closes, the assumptions it was built on are already outdated.
I didn't understand it then, but that example stayed with me.
Around the same time, I had come across The Design of Everyday Things by Don Norman, which has been foundational to my design thinking journey. In one of the examples, he argues: why put a handle on a door that should be pushed? Why not a flat plate? If the aesthetic choices invite the wrong action, the fault isn't with the person—it's with the design.
Over the years, I've found myself looking at almost everything through a systems lens. Instead of isolated events, I try reducing them to inputs, outputs, constraints, functions, incentives, and feedback loops. I find myself building "flow" charts and reverse-engineering outcomes instead of assuming causal relationships.
When something goes wrong, I avoid the knee-jerk reaction to assume blame, painfully forcing myself to ask, "What about the system allowed this mistake to happen?"
Props to Prof. Dhar's claim, this way of thinking has transferred across domains for me—products, organizations, and people.
Practicing this has developed an intuitive understanding of systems that helps me visualize stock and flow. And good design helps fix the inefficiencies you find.
I think this is what eventually drew me to product management. Every issue, inefficiency, or confused customer is rarely just an isolated event. It's usually a sign that somewhere, the system can be designed better.
The more I practice this way of thinking, the more I steer away from spot fixes and band-aids.
And once you start seeing systems, you might unknowingly start becoming Prof. Dhar.