We have defined product management too far downstream

September 26, 2026

I increasingly think that product management, as it is practised in most organisations, is defined too far downstream.

The traditional PM value chain looks something like: requirements → prioritisation → coordination → execution

A large part of the PM’s job is therefore to take a problem that someone else has already framed, convert it into requirements, prioritise those requirements, coordinate a bunch of people and eventually get something shipped.

This made sense when execution was expensive.

Writing the requirements was logically expensive. Research was time-wise expensive. Design was made expensive. Engineering was artificially expensive. Every iteration had a real cost attached to it. So getting better at prioritisation and execution created enormous value.

But we have entered a world where an increasing amount of downstream execution is becoming cheap.

AI can generate PRDs, prototypes, code, test cases, analyses, user stories, research summaries and multiple solution paths before a human has finished writing the first version of the requirement.

That changes something fundamental.

The scarce skill moves upstream.

My emerging definition of product leadership is therefore closer to: problem selection → system design → scenario analysis → orchestration → execution → adoption

The first thing that changes is problem selection.

I don’t think the highest-value question for a PM is “What should we build?”

It is increasingly: “Which problem is actually worth solving?”

That sounds obvious until you realise how much of product management is still built around assuming the problem exists, accepting the framing handed to you and then becoming extremely good at solving it.

A beautifully executed solution to an unimportant problem is still waste.

Then comes system design.

A feature is rarely the product.

The product is the system around the feature — people, processes, data, incentives, dependencies, failure modes, operational constraints, edge cases, exception handling, feedback loops.

This is also why I have become much less interested in feature thinking.

A feature answers: What does it do?

A system answers: What remains true even when everything around it changes?

Then comes scenario analysis.

• If I improve the velocity of X by 10-20-30%, what breaks and why?
• If adoption is 2x what we expected, where does the system fail?
• If the customer behaves differently from what we assumed, which parts of the product survive?
• If the AI gets something wrong, where does that error propagate?
• If the product works too well, what becomes the next bottleneck?

These are not strategy questions that get handed off to some strategy team. They are product questions.

Then comes orchestration.

This is probably the part of product leadership I am most interested in now.

The PM increasingly has to orchestrate humans, software, agents, data, workflows and decision systems around a problem.

Not manage people doing tasks one after another. Design a system in which the tasks themselves may increasingly be performed by machines.

Execution & adoption obviously still matter. But I think both are downstream expressions of upstream judgment. And this is where AI gets interesting.

AI may make some traditional PM skills dramatically less scarce while making other skills dramatically more important.

Writing a PRD can become cheap. Knowing whether the PRD should exist probably won’t.

Generating ten solutions can become cheap. Knowing which problem deserves one probably won’t.

Building can become faster. Knowing what not to build may become more valuable.

So I don’t think product management disappears. I think the centre of gravity moves.

From requirements → prioritisation → coordination → execution

towards problem selection → system design → scenario analysis → orchestration → execution → adoption

In other words, product leadership moves upstream.

The PM is no longer just responsible for helping the organisation build something correctly.

The PM increasingly has to decide: what is worth building, what system should exist around it, what could break, what should be automated, what should remain human, and what the world should look like after the thing is built.

That is a much bigger job.

And, frankly, a much more interesting one.