Systems thinking for products

There’s a book I keep coming back to. Thinking in Systems by Donella H. Meadows. It’s not a product book. It’s not a business book. It’s a book about how the world actually works, written by someone who spent her career studying the invisible structures that shape everything from ecosystems to economies.

The reason I keep returning to it is that once you start seeing systems, you can’t unsee them. And when you apply that lens to building products, a lot of decisions that used to feel complicated become surprisingly clear.

The bathtub

Meadows uses a simple metaphor to explain how systems work. Picture a bathtub.

The faucet is the inflow. The drain is the outflow. The water level in the tub is the stock, the current state of the system.

If the faucet runs faster than the drain empties, the water rises. If the drain is faster, the water drops. The water level at any moment is just the result of these two forces over time.

That’s it. Every system, no matter how complex, can be understood through this same pattern: what flows in, what flows out, and what accumulates.

Products work the same way

Now replace the bathtub with your product.

Inflows: new ideas, feature requests, user feedback, market research, new team members, funding, technical debt you’re knowingly taking on.

Outflows: shipped features, fixed bugs, resolved support tickets, published updates, content you produce, problems you eliminate.

The stock: the current state of your product. Its features, its bugs, its user base, its reputation, its technical health.

Just like the bathtub, the state of your product is determined by the balance between what flows in and what flows out. If new ideas and feature requests pile up faster than your team can ship, you get a backlog that grows forever. If you ship faster than the mess accumulates, the product gets cleaner and more focused over time.

Most teams I’ve worked with are drowning. Not because they’re bad at building, but because the inflow is completely unmanaged. Every stakeholder adds to the faucet and nobody controls the drain.

Where this gets useful

Once you start thinking about your product as a system with flows and stocks, a few things click into place.

Balance the faucet and the drain. If the backlog is growing out of control, you don’t necessarily need more engineers. You might need to turn down the faucet. Prioritise harder. Say no to more things. A smaller, focused inflow with a steady outflow produces a better product than a firehose of ideas that never fully ship.

Watch the feedback loops. Every system has feedback loops, and they matter more than most people realise. In product work, a feedback loop might look like this: you ship a feature, users react, their reaction feeds back into what you build next. If that loop is tight and fast, you improve quickly. If it’s slow or broken, you drift.

This is something I think about a lot when it comes to how AI can close the feedback loop in software development. The tighter the loop between building, testing, and learning from real signals, the faster the whole system improves.

Expect unintended consequences. Push too hard on one part of the system and something else breaks. Accelerate shipping speed and quality drops. Cut the team and institutional knowledge disappears. Add a feature and it complicates three other flows. Systems thinking doesn’t prevent these things, but it helps you see them coming.

Adapt, don’t plan. The water level in the tub changes constantly. So does the state of your product, your market, your team. Instead of trying to plan everything up front, build the ability to sense changes and respond. Treat your product as a living system, not a blueprint.

Why this matters now

I think systems thinking matters more now than when Meadows wrote the book. Products are getting more complex. Teams are getting smaller. AI is accelerating the outflow dramatically, but the inflow of ideas and possibilities is growing even faster. If you don’t have a way to think about the whole system, you end up building more and more while understanding less and less of how the pieces connect.

The teams that build the best products are the ones that see the system, not just the features. They know which loops to tighten, which inflows to cut, and where the stock is silently accumulating risk.

If you haven’t read Meadows’ book, I’d recommend it. It’s short, it’s clear, and it will change how you look at everything. Not just products. Everything.