Why is systems thinking now table-stake for PMs?
Software is designed, but models are grown, not designed. As such, AI products are organic. PM’ing AI products has an organic nature, akin to growing a garden. It’s more about creating the system for your plants to grow in rather than specifying exactly how an individual plant will look like. (See Alex Komoroske’s Gardening Platforms.)
To apply systems thinking in building AI/agents in existing products, these truths from Donella Meadows’ Thinking in Systems help explain the principles. (I read the book a few years ago, but only understood it after living through building agent systems in a platform PM role.)
1. Behavior arise from the interactions between the parts, not the individual parts.
A system’s output is the result of how the components connect and interact. You can perfect every individual part and still get a broken whole. The classic PM role (let’s call it the domain PM), especially at a large company, owns a specific scope/product area. By org design (and Conway’s law), every domain PM optimizes for their part. The product is not the part itself, but how the parts are organically assembled to a useful whole. Systems thinking means optimizing the connections between the parts. This matters more with agents because agents don’t know your org chart. Agents need to act holistically across the product on the user’s behalf.
2. Structure, rules, information flow have greater leverage than parameters.
The places to intervene in a system has a spectrum of leverage. Tweaking parameters has the weakest leverage. Next is changing the structure, the rules, and the information flows. Changing the paradigm has the highest leverage on the system. When experimenting with versions of a feature, it’s only parameter level intervention. Designing the contract that many teams can build on is a rule. Capturing the correction signal between what the agent did and what the user corrected is an information flow. Traditional product management is often filled with planning parameter tweaks. The higher-leverage product work is building the contracts and new information flows.
3. When there’s a new actor in the system, value goes to the interface.
Systems don’t exist on their own. Every system nests inside larger systems and they exchange with each other through interfaces. When agents are added to a product system as a new actor, new value goes to the interface for how the agent communicates with the product surface. For example, the shipping container was the interface for trade. API was the interface for software. MCP is the interface for agents and the tools they use. So what’s the interface for agents to use your product?
Building for the agent is systems work. Here are a few specific ways to apply systems thinking in PM’ing AI products - that I learned the hard way. Whether you work on a product domain or a platform, these might be helpful for PMs (especially in incumbent SaaS) trying to add agents in their products beyond just a bolt-on. It’s not a framework or a prescription, but examples of how the above principles were applied.
Decompose the product
Traditional workflows and UI has always been built for human consumption (so called "UX"). But now the agent enters as a new actor in the product’s system. Most existing products aren’t composed in a way that is easily digestible by agents. New value comes from creating the interface that lets agents understand and act in the product. Let’s call this AX: “agent experience”. It requires thinking from the agent’s perspective, not just the user’s.
To make products more usable by agents, a product can be decomposed into a few ingredients: structured context (so agent can “see” what the user sees), typed actions (so agent can know what actions are available to take in the workflow), preconditions and rules for human intervention, and the coordination to know what action to take given the context.
Decomposing the product into these common primitives and providing the interface for agents to access them give you a chance to differentiate from the AI labs. Otherwise, you’ll end up with bolt-on “AI features” that don’t perform any better than ChatGPT/Claude etc., and your customers will balk at AI’s disruption to their usual workflows without delivering significant new value. New value can only be realized when agents are deeply wired inside the product and can understand and act in workflows that are already familiar to the customers.
Define the contracts
Once the product is decomposed, the parts need a contract (agreement) to specify how they should behave, so different product areas can plug and play to get to their agents to perform the desired behaviour.
Contrast this from the traditional feature-level PM’ing: building a feature on your product area alone only works on your product area. But a contract defines how a capability can work at a system level, what each component means, the rules by which they can interact, etc. This allows any team or agent to add that capability in their own surface or use case. It makes the capability much more scalable, consistent, and cohesive across the entire product. It’s like the electrical outlet - individual appliance maker don’t have to negotiate with the power company because the outlet gives them the contract. Contract thinking was not always needed for domain product PMs but is required when building agents, since agents need defined preconditions to operate in your product.
Design the loop
New features come with a lifespan. But a loop can improve the agent system over time. An example of a valuable loop is capturing the correction signal: the delta between what the agent did and whether the user corrected it. For example, when the user edits the field the agent updated, or accepts the draft but rewrites the last paragraph. Corrections are labeled examples from real usage.
The correction signal gives two benefits. One is eval data: signal for where the agent fails in production, which no offline benchmark can. The second is improvement data: corrections improve the agent by preference pairs or past corrections retrieved into context so the agent doesn’t repeat the same mistake.
Great AI products are built on these loops. Coding agents track what jobs are accepted, rejected, or edited after accepting. The bonus: this valuable signal is simply a byproduct of normal use of the product that doesn’t require any additional action from the user (unlike a feedback form). Improving the agent with this signal makes it perform uniquely better inside your product on subsequent use, compared to starting cold in generic AI chat products. Features depreciate, systems (with loops) compound.
An example:
Sierra’s newly launched Horizon platform is a great illustration of the systems thinking that’s required to conceive new and real value with agents. Horizon’s innovation is in the seams, the interface layer that can feed signals, goals, guardrails, and cross-interaction context to agents. It answers the differentiation question that most companies are struggling with: “How can you build a durable moat in your business as frontier AI progresses so rapidly?”?
Systems thinking’s velocity advantage
Stewart Brand’s “pace layers” explains that buildings work because the things that change fast (furniture, room layouts) aren’t welded to the things that are harder to change (the frame, foundation). The fast layer can change quickly because of the affordances built in the foundation layer that don’t have to change.
In software products, you might think decomposing and building contracts and loops sound slower than shipping that new AI feature in the next cycle. It’s the age-old tension between speed and scale. But in the agent era, the features are so much cheaper to build, so read speed actually comes more from investment in the system, the platform. The system level capabilities and contracts are the product thinking that can bring real differentiation in your existing (especially non-AI native) product. One contract allows you to test many variants of an experience in one sprint, and new variants can easily be added as a new surface on the same contract. But if that capability was built on individual surfaces, then each variant needs to re-implement the same plumbing. Platform is now the speed play.
What now
Elizabeth Stone on Lenny’s podcast shared that Netflix is hiring people who can look across the business domains and abstract the building blocks. It previously let local teams build off the paved path to move fast, but agents operating across multiple systems make common paved paths and solving problems once more important.
To practice systems thinking, pick a high traffic JTBD area and ask a few Qs:
What would the agent need to see, know, and do at each step to complete this job accurately for the user? What are the structured ingredients it would need?
How can your agent access those ingredients across multiple surfaces? Is your capability attached to your UI surface only or is it interchangeable with other areas of the product or of the customer’s workflow holistically?
How are you capturing unique context from your customers and improving your agent?
Software used to be designed. But now, AI products are grown. A great PM/builder acts more like a gardener who creates the conditions, sows the seeds, and tends to what comes up. Don’t stay stuck in the traditional PDLC boundaries of defining the perfect feature and perfect roadmap. Think about the core primitives that make up the system, define contracts and loops, and watch the new organic value that can grow from your system and maybe surprise you.
More fun reads
Lenny’s podcast with Elizabeth Stone: “we need more systems thinkers in a world with AI.”
Why product sense is the only product skill that will matter in the AI age
