Written by James Richards

There was a time when technology companies were run, quite literally, from the top.

The early mythology of the sector is crowded with founders, visionaries and technical prodigies - charismatic CEOs sketching futures on whiteboards, CTOs architecting vast systems in their heads, leadership teams issuing grand declarations about platforms, paradigms and revolutions. Decisions were made in boardrooms, cascaded through hierarchies and handed down to engineering teams to be executed.

This was the age of waterfall development: long planning cycles, fixed requirements, linear delivery. Products were conceived in advance, specified in detail, and then built in sequence. The assumption was that the world could be understood well enough at the outset for a plan to be written, signed off and followed.

It was a model that made sense in a simpler technological landscape. Software was more contained, user expectations were lower, and the feedback loop between building and learning was slow. Crucially, authority was clear. The people with the titles made the decisions. Power was positional, visible and, for the most part, uncontested.

The CEO set the vision. The CTO determined the architecture. Everyone else implemented.

This model was not always efficient, and it was often wrong, but it was at least legible. Influence could be located. Responsibility could be traced. If a product failed, it was usually obvious where the decision had been made.

As systems grew more complex, however, and as software shifted from discrete projects to living services, the limitations of this model became harder to ignore. Plans aged badly. Requirements drifted. Users behaved unpredictably. Markets moved faster than governance structures could follow.

The Old World was built on the assumption that certainty preceded action. The modern digital environment, it turned out, did not share that assumption.

The Agile Revolution

Agile is often described as a methodology. In practice, it was a reorientation. Where waterfall sought to eliminate uncertainty through planning, agile sought to absorb it through iteration. To quote a recent McKinsey report, agile is a way of working that seeks to harness the inevitability of change rather than resist it.

Long cycles gave way to short sprints. Fixed requirements gave way to backlogs (evolving lists of everything a product team might build, including features, fixes, and tweaks). Delivery became continuous, not terminal, and software stopped being something you finished and became something you tended.

This shift was not cosmetic. It fundamentally altered how decisions were made. In an agile environment, direction is not set once. It is renegotiated weekly - priorities are fluid and scope provisional. The organisation is in a permanent state of adjustment, responding to user behaviour, technical constraints and commercial pressure in near real time.

Which raises an immediate question: who, exactly, is now responsible for deciding what matters?

This is where product management enters the story.

What Exactly is Product Management?

Strip away the job descriptions and the jargon, and product management is a remarkably precise function. It is not design, not engineering and not marketing, though it intersects with all three. It is the discipline concerned with deciding what gets built in what order, and in service of which outcomes. In other words, product management is the arbitration layer between possibility, value and intent.

It exists because the Old World could not cope well with ambiguity. When requirements were fixed and authority was centralised, there was little need for continuous negotiation. Once the plan was signed off, the organisation moved in one direction. But in a world of perpetual iteration, someone has to continually adjudicate between competing demands.

Product management emerged to resolve this tension. Not by eliminating conflict, but by containing it. The product function became the place where competing priorities were weighed, sequenced and translated into action.

Way More than a Trend

This is why product management is not, as it is sometimes framed, a fashionable role that drifted in from Silicon Valley. It should be seen instead as a structural response to structural complexity. As software became more central, more interconnected and more exposed to human behaviour, the need for a dedicated decision-making layer became unavoidable.

In fact, the agile approach did not just change how software is built. It created a vacuum where authority used to sit - a vacuum that was filled by product management.

In doing so, it quietly became one of the most consequential functions in modern technology companies. Not because product managers are more visionary than their predecessors, or more technically gifted, but because the system now requires someone to continuously decide what is worth doing.

In the Old World, power was exercised through instruction. In the New World, it is exercised through prioritisation. And prioritisation, in an agile organisation, is the domain of product.

The New Power Brokers

In most modern technology organisations, the product manager does not sit at the top of the hierarchy. They are rarely the most senior person in the room. They do not usually control budgets, hire teams or sign off on strategy documents. On paper, their authority is limited. In practice, their influence is pervasive.

This is because product managers occupy a structurally privileged position. They sit at the intersection of business ambition, technical reality and user behaviour. They are the one role expected to hold all three in mind at once, and to translate between them without collapsing the system.

The product manager’s day-to-day work is not, as it is sometimes caricatured, about writing user stories or running ceremonies. Given that requests are coming from multiple stakeholders - leadership, marketing, customers and so forth - the role is more about continuous arbitration, about deciding what should be built next, and what can wait. What must be dropped. What needs reframing. What will never happen.

This is where the backlog becomes more than an administrative artefact. It is the concrete expression of organisational intent. The ordered list of everything the company could do, and by implication, everything it will not.

In theory, the backlog is collaborative. In practice, it is curated. Items rise and fall. Some are championed. Others are quietly starved of attention. Very little is formally rejected. Most things simply sink.

This gives the product manager a peculiar kind of authority. Not the authority to command, but the authority to sequence, to decide which problems deserve oxygen, and to determine which ideas encounter resistance and which find momentum.

Because in a world of infinite possibility and finite capacity, sequencing is power.

Product Manager as Gatekeeper

This is why product managers often find themselves acting as informal gatekeepers. Not in the sense of blocking progress, but in the sense of controlling flow. In practice, a great deal of organisational ambition passes through the product function, where it is translated into their language and tested against their prioritisation logic.

It is also why the role is so politically sensitive. Product managers are expected to be neutral, but they cannot be. Every decision they make advantages one constituency over another, whether that is engineering stability over commercial speed, user trust over revenue extraction, or coherence over experimentation. These are not technical judgements so much as value judgements.

Yet they are rarely framed as such. They are framed as resourcing issues, dependency chains, delivery risks, capacity constraints. The language is operational, but the consequences are strategic.

Over time, this produces an interesting inversion. Executives continue to speak in terms of direction, announce priorities and define goals, but it is the product function that interprets those goals into reality, determining what they mean in practice and which parts of the vision are emphasised or quietly diluted.

In many organisations, the product manager is now the only person with a panoramic view of the system. The only role that sees user behaviour, technical debt, commercial pressure and design intent in the same frame. The only role forced to reconcile contradictions rather than choose sides.

This does not make product managers omnipotent. It does make them influential. And influence, in complex systems, is often more consequential than authority.

Analytics as the Language of Legitimacy

If the product manager is the new power broker, analytics is the currency in which that power is exercised.

Modern product organisations are saturated with data, with dashboards glowing on screens, funnels monitored, cohorts compared, retention curves interrogated and conversion rates optimised, as every interaction is tracked, aggregated and rendered into insight.

This is usually presented as progress - a move away from intuition and towards evidence, a triumph of rationality over guesswork. Decisions, we are told, are now data-driven.

There is some truth in this, but it misses a more interesting point. Data does not remove subjectivity so much as reframe it. Analytics does not tell organisations what to do, but it does shape what they feel able to justify, providing a language in which decisions can be defended, contested and legitimised, and in which preference is gradually rendered as principle and instinct as inference.

In the Old World, authority rested on seniority, experience and technical mastery. A CEO could say “we are doing this” and expect to be obeyed. A CTO could veto an approach on architectural grounds. Power was personal and explicit.

In the New World, authority is more procedural. It flows through metrics, experiments and evidence. Decisions are expected to be supported by numbers, and arguments are expected to be framed as insights and illustrated through charts.

Data and the Reshaping of Influence

The increased role of data in corporate decision making has a democratising veneer. Anyone with access to the data can make a case - hierarchies appear flatter, debate appears more open. But it also creates a new asymmetry, in the sense that those who control the framing of the data control the framing of the decision.

Product managers sit at the centre of this dynamic. They decide which metrics matter, which signals are meaningful, which experiments are worth running, and which outcomes count as success. In doing so, they do not just interpret reality, they shape it.

A feature that improves engagement or retention while increasing dependency can be framed as a win, just as a design change that reduces friction but erodes deliberation can be framed as optimisation, and a monetisation tweak that boosts conversion while damaging trust can be framed as performance. With the right lens, the numbers will support all of these.

This is not a critique of analytics itself. Data is indispensable in complex systems. It reveals patterns no human could reliably intuit. It surfaces problems that would otherwise remain hidden. It can, at its best, check bias rather than amplify it. However, it is far from neutral.

The choice of metrics reflects underlying theories of value, dashboards elevate certain outcomes above others, and A/B testing often treats what can be measured as a proxy for what matters.

Product management, in this context, becomes a hybrid discipline - part strategist, part statistician, part behavioural economist. The role is no longer just to decide what to build, but to decide how success will be defined.

This is a subtle but profound shift. When strategy is expressed through metrics, and metrics are curated by product, influence moves again. Not upwards, not downwards, but inwards. Into the machinery of prioritisation. Into the logic of experimentation. Into the architecture of choice.

It is here, in the interplay between backlog and dashboard, that much of modern technological power now resides. Not in grand pronouncements or charismatic leadership, but in the quiet accumulation of small decisions, each justified, each reasonable, each defensible, and together transformative.

Engine, Constraint or Both?

There is a tendency, particularly in technology discourse, to treat product management as an unqualified good. As the professionalisation of intuition, the rationalisation of chaos, and the discipline that finally brought order to the messy business of building digital systems.

There is truth in this. Without product management, most modern platforms would collapse under their own complexity. The sheer volume of competing demands - from users, regulators, internal stakeholders and technical systems - would be unmanageable. Continuous prioritisation is not a luxury in this environment; it is a necessity. Product management is the engine that keeps the machine running.

But engines also define the limits of the machine.

Paradoxically, the same structures that enable iteration can inhibit imagination. The same processes that protect coherence can discourage risk. The same focus on measurable outcomes can quietly marginalise ideas whose value is long-term, diffuse or difficult to quantify.

This is the less comfortable side of product-led culture. When everything is filtered through a backlog, novelty must compete with familiarity. When every initiative requires a business case, speculative ideas are disadvantaged. When success is defined by metrics, anything that resists measurement becomes harder to defend.

Over time, this produces a subtle gravitational effect. Teams optimise for what can be shipped, not what might matter. Roadmaps fill with incremental improvements, performance tweaks and feature extensions, while more ambitious reimaginings are deferred indefinitely. The system becomes very good at refining itself and less good at reinventing itself. This is not a failure of individuals, rather, a property of the structure.

The Radical Conservatism of Product Management

Product managers are often acutely aware of this tension. Many enter the role precisely because they care about users, experience and long-term value. But they operate inside frameworks that reward predictability. The safest decisions are those that can be justified with precedent. The easiest wins are those that can be demonstrated with data.

Vision, in this context, becomes procedural. Innovation is decomposed into epics, ambition is broken into sprints and strategy is rendered as a sequence of tickets.

There is something quietly revealing about this. The language of product management is the language of containment, of scope, dependencies, capacity, risk and delivery. These are necessary concepts, but they are also disciplining concepts. They shape what can be said, what can be proposed, and what can be sustained.

This could explain why product organisations can sometimes feel curiously conservative, even when they are working on technologies that claim to be transformative. The system is designed to reduce uncertainty, not to embrace it. To manage change, not to provoke it.

None of this negates the value of product management. It simply situates it. The discipline is extraordinarily effective at steering complex systems, but less effective at questioning their direction.

In this sense, product management is both the engine of modern technology companies and, increasingly, their ceiling.

That tension is not easily resolved. Nor should it be. It is the price of operating at scale in environments where mistakes are expensive and trust is fragile. But it is worth acknowledging, because it reveals something important about how influence now operates.

The New Locus of Influence

Power in the tech sector no longer expresses itself through grand decisions. It expresses itself through accumulations, through thousands of small choices, each defensible, each reasonable, each constrained by process, and together decisive. The future is not designed in a single moment. It is assembled, one sprint at a time.

And it is tempting, when analysing power in technology, to look upwards. To boards, founders, chief executives and public figures, to charismatic leaders and dominant personalities. These are the visible faces of authority, and they continue to matter.

But much of the real influence in modern technology companies now sits elsewhere: in roadmaps and backlogs, prioritisation meetings and planning sessions, in dashboards and experiment results.

This is not a conspiracy, and it is not a coup. It is the natural consequence of building complex, adaptive systems in uncertain environments. When certainty disappears, authority diffuses. When plans become provisional, power migrates to those who manage change.

Product management has become central not because product managers sought power, but because the system required a new kind of decision-maker, capable of mediating between vision and reality, absorbing ambiguity and converting it into action, and translating competing claims into a sequence of work.

In doing so, the role has become quietly political, not in the sense of ideology or partisanship, but in the sense of shaping outcomes, deciding whose needs are foregrounded, determining which values are encoded in the product experience, and influencing how users are treated, nudged, rewarded or constrained.

The product manager is not the only actor in this system, but they are a pivotal one. They sit at the junction where strategy becomes structure, and where intention becomes interface. They are where abstract goals are converted into concrete features, and where ethical questions are often resolved through design choices.

Another Version of Power

This is a significant shift. In the Old World, power was declarative. It announced itself. It was exercised through instruction. In the New World, however, power is procedural. It is exercised through sequencing, framing and prioritisation. It is embedded in tools and rituals rather than titles.

This makes it harder to see, and easier to underestimate. It also makes it more consequential. Because when power is distributed through process, it becomes more resilient, less dependent on individuals, and more deeply woven into the organisation’s habits and assumptions.

To understand modern technology companies, then, it is no longer enough to study their leaders or their products. We have to study their workflows, their planning cycles, their decision-making machinery. We have to look at who owns the backlog.

Because in the age of agile, influence does not reside where it once did. It no longer sits solely at the top, issuing commands. Instead, it accumulates in the middle, shaping reality through a thousand small judgements.

In modern tech, power no longer announces itself. It manifests.