The new question for product and engineering teams

For years, many technology organizations were built around specialization. Product managers clarified customer problems, designers shaped the experience, engineers built the system, data scientists measured behavior, and leaders coordinated the machinery. That model worked because the seams between roles were manageable. Work moved from one craft to the next, and the bottleneck was usually human capacity.

AI changes the shape of that bottleneck. It can generate drafts, code, tests, summaries, research plans, mockups, analysis, and alternatives faster than most organizations can evaluate them. The scarce skill is no longer only the ability to produce output. It is the ability to understand how output moves through a larger system: how a product decision affects engineering complexity, how an AI-generated code change affects reliability, how a design shortcut affects user trust, and how a faster shipping loop affects quality.

That is why systems thinking is becoming a core capability for modern builders. Not because specialists no longer matter, but because specialization without system awareness can create local optimization. A team can make one part of the machine faster while making the whole product, platform, or organization worse.

The modern builder has to see the whole board.

AI creates output abundance, not judgment abundance

The most immediate effect of AI in product development is a flood of plausible output. A product manager can ask for ten strategy memos. A designer can generate multiple flows. An engineer can ask for a refactor, a test plan, and a migration script. A leader can summarize customer feedback and turn it into a roadmap draft before the next meeting.

That sounds like pure leverage, and often it is. But output abundance creates a new management problem: the team now has to decide what is worth trusting, what is worth improving, and what should be discarded.

Think of AI as opening more lanes on a highway. More lanes increase throughput, but they do not automatically improve navigation. If every car can move faster but nobody understands the destination, the merge points, or the road rules, the system becomes more dangerous. The same is true in software organizations. AI can accelerate code, design, and analysis, but the organization still needs people who can ask:

1. What problem are we solving?
2. What dependencies does this touch?
3. What failure modes are we creating?
4. What signal tells us this is better?
5. Who needs to understand or maintain this later?

These are systems questions. They are not tied to one function. They cut across product, design, engineering, data, operations, security, support, and leadership.

Why systems thinking is becoming a core skill

Systems thinking is the ability to understand relationships, feedback loops, constraints, incentives, and second-order effects. In a product organization, it means seeing how user behavior, technical architecture, team processes, business goals, and culture interact.

For example, imagine a team uses AI to generate a new onboarding flow. The first draft looks good: fewer screens, shorter copy, faster completion. A narrow specialist might evaluate only their slice. Product asks whether conversion improves. Design asks whether the flow feels cleaner. Engineering asks whether implementation is straightforward. Data asks whether events are instrumented.

The systems thinker asks a wider set of questions:

This is why systems thinking becomes more valuable as AI gets better. The more AI helps teams produce, the more important it becomes to know what should be produced.

Specialists still matter, but the walls are changing

Betting on systems thinkers does not mean abandoning craft. Great engineering, product management, design, data science, research, security, and operations still require depth. AI does not remove the need for taste, rigor, architecture, accessibility, privacy, customer empathy, or business judgment.

What changes is the isolation of the craft. In the pre-AI workflow, specialization often meant handoffs. A designer could hand a polished spec to engineering. A product manager could hand a requirements document to design. An engineer could hand data questions to analytics. Those boundaries already had friction, but AI makes the friction more visible because work can move faster than alignment.

The healthier model is not “everyone does everything.” It is “everyone understands enough of the system to make better decisions in their craft.”

An engineer who understands product context can reject an AI-generated implementation that solves the ticket but damages the product model. A product manager who understands architecture can avoid asking for a feature that creates months of hidden complexity. A designer who understands data and AI limitations can shape experiences that are both elegant and technically honest.

Specialization becomes stronger when it is connected to the system around it.

Managing the flood of AI-generated work

One defining leadership problem of the next few years will be managing the flood of AI-generated output without losing quality or signal.

The old review model assumed output was relatively expensive. If a team produced a proposal, a prototype, or a pull request, someone had already spent meaningful time creating it. Reviewers could assume a baseline of intent and effort. AI breaks that assumption. A person can now generate a long document, a detailed plan, or a large code change with much less effort than before.

That means teams need stronger filters. Not bureaucratic filters, but quality filters.

A useful way to think about this is to separate generation from judgment:

AI-assisted generation:  
  - draft options
  - summarize inputs
  - produce examples
  - write first-pass code
  - generate tests
  - identify edge cases
    
Human systems judgment:  
  - choose the right problem
  - define success 
  - inspect assumptions
  - connect dependencies
  - evaluate tradeoffs
  - protect quality

The danger is letting generated work inherit authority just because it is polished. A confident memo can still be wrong. A clean code diff can still be misaligned with the architecture. A beautiful prototype can still solve the wrong user problem.

Teams need a culture where AI output is treated as material, not truth.

AI fluency as a universal expectation

AI fluency should be treated as a broad expectation rather than a niche skill for a few specialists. This is an important distinction.

If AI fluency is treated as a senior-only capability, organizations create a two-speed culture. Senior employees use AI to extend their leverage, while junior employees are left either overusing it without guidance or underusing it out of fear. If AI fluency is treated as a universal expectation, the organization can build shared norms around when to use AI, how to verify its work, how to disclose uncertainty, and how to preserve craft.

AI fluency does not mean “use AI for everything.” It means knowing where AI helps, where it misleads, and how to combine it with domain expertise.

For a product manager, AI fluency might mean using AI to synthesize customer notes, then manually checking whether the synthesis erases minority but strategically important feedback. For an engineer, it might mean using AI to generate a first draft of a test suite, then reviewing whether the tests assert behavior rather than implementation details. For a designer, it might mean exploring interface alternatives quickly, then applying taste and user understanding to choose the version that feels coherent.

In other words, AI fluency is not a tool skill. It is a judgment skill.

A practical example: AI-generated code and systems judgment

Consider a simple example. A team asks AI to add caching to improve performance:

const cache = new Map();
export async function getRecommendations(userId) {  
  if (cache.has(userId)) {   
    return cache.get(userId);  
  }
  
  const recommendations = await fetchRecommendations(userId);  
  cache.set(userId, recommendations);  
  return recommendations;
}

At first glance, this looks reasonable. It is short, readable, and probably improves latency in a demo. But a systems thinker will slow down and ask what system this code lives inside:

1. Does the cache ever expire?
2. Can recommendations become stale after a user takes a new action?
3. Is this running in a long-lived process, serverless function, or client runtime?
4. Could memory grow without bound?
5. Does this leak data across tenants or users?
6. What happens during deploys, retries, or partial failures?
7. What metric tells us the cache improves the product rather than only the endpoint?

The improved version may not be much longer, but it encodes more system awareness:

const cache = new Map();
const TTL_MS = 5 * 60 * 1000;
const MAX_ENTRIES = 10_000;
export async function getRecommendations(userId, now = Date.now()) { 
  const cached = cache.get(userId);
  
  if (cached && cached.expiresAt > now) {    
    return cached.value;  
  }
  const recommendations = await fetchRecommendations(userId);
  
  if (cache.size >= MAX_ENTRIES) {   
    const oldestKey = cache.keys().next().value;  
    cache.delete(oldestKey);  
  }
  
  cache.set(userId, {   
    value: recommendations,    
    expiresAt: now + TTL_MS, 
  });
  
  return recommendations;
}

Even this version is only a teaching example, not production-ready code. A real system might need distributed caching, explicit invalidation, observability, privacy review, or experimentation. The point is that AI can generate the first version quickly, but the team’s value comes from understanding the system deeply enough to know what is missing.

Excellence as an operating system

“Excellence as an operating system” is a useful phrase because it moves excellence away from vibes and heroics. Excellence is not just hiring talented people and hoping quality appears. It is a set of repeatable behaviors, expectations, conversations, and feedback loops.

In an AI-heavy world, this matters even more. If the organization does not define excellence, AI will amplify inconsistency. Different teams will use different quality bars. Some will optimize for speed, others for polish, others for technical cleverness. The result can look productive locally while becoming chaotic globally.

An excellence operating system might include:

The phrase “operating system” is especially apt because culture is not a poster on the wall. It is the environment every decision runs inside. If that environment rewards shallow speed, AI will make shallow speed easier. If it rewards thoughtful velocity, AI can become real leverage.

Talent signals in an AI era

In the AI era, output volume alone becomes a less reliable signal of contribution because AI can inflate visible productivity. The better question is not simply, “Who produced the most?” It is, “Who made the system better?”

That includes people who:

1. Improve the quality of decisions.
2. Raise the signal-to-noise ratio.
3. Connect dots across functions.
4. Make AI-generated work safer and more useful.
5. Mentor others into stronger judgment.
6. Reduce complexity instead of adding to it.

This matters for junior talent too. If AI handles more entry-level execution, organizations have to be deliberate about how people build craft. You cannot become a strong systems thinker without contact with real systems. Teams will need to design learning loops where junior employees use AI, but also inspect, debug, reason, and receive feedback.

The apprenticeship model does not disappear. It has to be redesigned.

The future of product work is less linear

Traditional product development often looked like a sequence:

Research -> strategy -> design -> engineering -> launch -> measurement

AI makes the sequence more fluid. Research synthesis can happen while prototypes are forming. Engineering constraints can be explored before product direction is final. Designs can be tested against implementation ideas earlier. Data questions can shape the plan before the roadmap hardens.

That is powerful, but only if someone is holding the whole system in view. Otherwise, the team may confuse motion with progress.

A better AI-era product loop might look like this:

Frame the system  
  -> generate options  
  -> inspect tradeoffs  
  -> test assumptions  
  -> build the smallest coherent slice  
  -> measure real behavior  
  -> update the system model

The key step is the last one. Systems thinkers do not just ship and move on. They update their understanding of the system. They ask what changed, what surprised them, what broke, what improved, and what new constraint emerged.

What this means for builders

If you are an individual contributor, the lesson is not to abandon your craft and become a generalist in the shallow sense. The lesson is to deepen your craft while expanding your context.

Engineers should understand product strategy and user behavior. Product managers should understand technical constraints and data quality. Designers should understand implementation tradeoffs and system feedback. Data scientists should understand decision-making contexts, not just models and metrics. Leaders should understand enough about AI’s capabilities and failure modes to create useful norms rather than vague mandates.

A practical way to build this muscle is to add one systems question to every piece of work:

Over time, these questions change how you see work. You stop treating tasks as isolated objects and start treating them as interventions in a living system.

What this means for leaders

For leaders, the challenge is to avoid two traps.

The first trap is AI theater: mandating AI adoption without defining quality, learning, or accountability. This creates performative usage. Teams show that they are “using AI,” but nobody knows whether the work is better.

The second trap is defensive nostalgia: protecting old role boundaries because they feel safe. This slows learning and leaves leverage on the table.

The healthier path is to build an operating system for AI-era excellence:

1. Set clear expectations for AI fluency across roles.
2. Make review quality more important, not less.
3. Reward people who improve system outcomes, not only output volume.
4. Preserve craft by redesigning mentorship and apprenticeship.
5. Encourage cross-functional context without erasing functional depth.
6. Treat AI as leverage for judgment, not a replacement for it.

The organizations that win will not be the ones that simply generate the most. They will be the ones that can absorb more possibilities without losing coherence.

The bigger story

The phrase “systems thinkers, not just specialists” can sound provocative, but the deeper message is more balanced. The AI era does not eliminate specialization. It changes what makes specialization valuable.

A specialist who can only optimize their own lane becomes easier to bottleneck, easier to misdirect, and easier to replace with generated output. A specialist who understands the system becomes far more valuable, because they can use AI to move faster while protecting quality, coherence, and strategic intent.

As AI makes execution cheaper, judgment becomes more expensive. As output becomes easier, coherence becomes rarer. As tools become more powerful, the ability to understand the system around the tool becomes the real advantage.

The next generation of standout builders will not just ask, “Can AI help me do this faster?”

They will ask, “What system am I changing, and how do I make it better?”