The Role of Product, and What Comes NextA 2017 argument about why product exists to balance technology and commercial forces, with a postscript on how AI is dissolving the boundaries entirely.
Steven Gerson · January 2026
Context: I originally wrote this as a presentation in 2017 while working at Racing Post. I refined and presented it more widely at Tracr (De Beers Group) in 2018, where I contributed to shaping how product ways of working would develop, as the first permanent product hire.
The argument below reflects how I was thinking about product organisations at that time. A 2026 postscript follows, reflecting on how the landscape has changed since.
1. Two Valid Forces
Every organisation that builds software has at least two competing forces inside it. There are more, but two dominate. Technology teams want to build things properly: good architecture, scalability, doing it the right way. Commercial teams want to make money: the next deal, the next client, the next quarter. Neither is wrong. Both are necessary. The problem is that without something balancing them, each one causes damage in its own way.
“He communicated well at both product and technical levels allowing much improved communication between both sectors which is [a] very difficult skill to attain.”
2. Lead with Technology
In a technology-led organisation, engineering sets the direction. The architecture is ambitious, the tooling is modern, and the team takes pride in building things the right way.
The problem is twofold. First, the right way to build something and the right thing to build are not the same question. A team left unconstrained by business reality can end up over-engineering solutions, optimising for elegance rather than for the problem at hand. Second, technology teams can also build the wrong thing entirely, drawn to what is technically interesting rather than what the customer actually needs.
If a customer needs to get to the local shops, they need a bicycle, not a rocket ship. The rocket is more impressive. The bicycle solves the problem.
This is a dramatic example, but the principle applies to quieter ones too. Maybe the rocket can get them to the shops. Pragmatism means recognising when good enough, delivered on time, is better than perfect, delivered late.
3. Lead with Commercial
In a commercial-led organisation, revenue drives everything. Sales commitments, client demands, and quarterly targets determine what gets built. The advantage is obvious: the work is always connected to money.
The problem is what accumulates over time.
Every new deal, every bespoke requirement, every urgent request from a key account adds another piece to the system. Nothing is removed. Nothing is consolidated. Each addition is valid on its own, meeting a real commercial goal. But the cumulative effect is a platform that collapses under its own weight.
One thing gets hacked together to meet a requirement. Then another. Then another. Each one solves the immediate problem, but the underlying system becomes brittle and tangled. Only the person who hacked it all together understands how it works, and even they may not remember everything. Changes that once took days start taking weeks. New features break old ones. The architecture was never designed; it just happened.
Commercial-led organisations always ship. The question is whether what they ship is getting better or just getting bigger.
Eventually, the people building the product are too busy to stop and think about what they are building. Everyone is pedalling as fast as they can, but nobody is steering. The system is unsustainable, but there is no mechanism to pause and address it, because the next deal is already in the pipeline.
4. The Displaced Product Function
Both forces are valid. Both cause damage when unconstrained. So you need something to balance them.
In many organisations that struggle with this balance, product teams do exist. But look at what they actually do.
Commercial defines what needs to happen and hands it directly to Technology with a high-level plan and an expectation of delivery. "Do this. Here is a high-level plan. Don't ask for detail." Technology then turns to Product for the detail that Commercial did not provide, asking them to do the business analysis work to make it buildable.
Product ends up squeezed from both sides. Commercial asks: "Is it done? Give me visibility." Technology asks: "What are the requirements? Is it defined yet?" Product is filling in the gaps and chasing status, with no say in direction over what to build, when, or why.
In this model, the business has taken on the role of product. It is defining solutions, not just requirements. The actual discipline of product management, understanding users, making trade-offs, prioritising ruthlessly, has been absorbed by the commercial side, often without anyone noticing. What remains is delivery coordination with a product title.
That is not a reflection on the people in those roles. It is a reflection on an organisation that has not understood what product management is, or has chosen to label something else with that title.
This is not the only dysfunctional mode, but it is one I have seen repeatedly.
“[He] quickly gained a deep understanding of some very complex system and could comfortably work and communicate with everyone from business stakeholders and hard core techies.”
5. The Product-Centric Organisation
A product-centric organisation puts the product function in the centre as the balancing layer between commercial and technology.
Commercial still defines new requirements, evolving priorities, and expectations of delivery. That input is essential. But it is not the only input. Product is also gathering insight directly from customers, from usage data, and from the market. All of these inputs flow into the product function, where they are weighed, shaped, and prioritised before anything gets built. Product defines what to build and when, taking a pragmatic view from both a business and a technology standpoint.
Consider a concrete example. A key account asks for a bespoke integration by the end of the quarter. In a displaced model, that request goes straight to the engineering team as an instruction. In a product-centric model, the product team raises the questions: does this serve one client or twenty? Can we scope it so the work is reusable? Is there a simpler version that meets the need without creating technical debt we will be paying off for the next two years? The answer might still be "build it," but the decision is informed rather than reactive.
Crucially, engineering is part of that conversation. They are partners in shaping requirements, discussing trade-offs and feasibility before anything is committed. Product shields engineering from the noise of competing direct requests, but keeps them fully involved in the decisions that matter. This works when the product function understands enough about the technical landscape to hold those conversations meaningfully.
When product is in the centre:
- Commercial input is heard, but it is weighed against user needs, technical constraints, and strategic direction before becoming a commitment.
- Technology receives clear, prioritised, well-defined work, reducing waste and rework.
- The organisation builds fewer things, but the things it builds are more likely to be the right things, built in a way that can sustain future change.
“Steven brought a new and dynamic way of thinking to Racing Post and during his time here challenged convention, with the outcome of genuine business improvements. [He] also managed to demystify technology to a level where the commercial team could understand and capitalise accordingly.”
6. Pragmatism, Not Theory
This is an argument for pragmatism.
Technology teams are right that things should be built well. Commercial teams are right that things need to generate value. The product function exists to hold both of those truths at the same time and make the trade-offs that neither side will make on its own.
Most organisations that say they want to become "product-led" are trying to move from the displaced model to the product-centric one. The mistake is thinking this is a cultural change. It is a structural one. You cannot ask a product team to balance competing forces if the organisational structure routes decisions around them.
Becoming product-led is a structural change.
Postscript: What Has Already Changed
I wrote the above in 2017 and presented it widely in 2018. Since around 2024, the landscape has changed in ways that make the model less complete than it once was. The boundaries between product, design, and engineering have been dissolving. Agentic AI tools now allow a single person to do work that previously required a team of specialists: conducting discovery, writing requirements, generating and iterating on code, validating with users. The separate functions described above are merging, and the org-chart separation of "product people" and "technology people" is becoming less meaningful.
The question shifts from "which function should lead?" to "does this person understand enough of each discipline to direct the work well?" That requires breadth across product, design, and technology. It also requires getting stuck in: using agentic tools seriously since they became viable, building real things with them, and developing a feel for what they can and cannot do.
I have shipped products recently where I did the commercial thinking, the product thinking, the design, and the engineering. The tools made that possible.
What Might Come Next
What follows is a structural vision for where things could head, based on trajectories that are already underway.
If software becomes genuinely cheap to produce, cheap enough that almost anyone can generate a working application, then the value shifts. Building software stops being the hard part. Knowing what to build, and building it well, remains hard. The ability to produce code does not guarantee the judgement to produce good software.
At that point, software starts to look like user-generated content. Today, platforms like YouTube and TikTok let anyone publish, and anyone else can pick up what someone has made, remix it, and publish their own version. Software could follow the same pattern. Not everyone writing code from scratch, but everyone able to pick up an application, use it as it is, or adapt it into something better and share that version with others.
Imagine a platform that hosts a broad ecosystem of software, open to anyone. Users can access any software on the platform, benefit from it, or adapt it using AI. Each change creates a new version, a branch. Every fork shows its children. You can use your version, or you can browse what others have built and use theirs.
The ecosystem attracts innovators because it rewards them: the economics work through attention. The versions that people actually use generate revenue, and that revenue flows back through the lineage of contributions that made the current version possible. The more people use a version, the more value flows to it and to the shoulders it stands on.
For standalone applications, this is relatively straightforward. Someone builds a budgeting app. Someone else forks it, improves the interface, and their version attracts more attention. Value flows to the improvement and to the original. The tree grows.
Shared platforms are harder. Think of something like a global marketplace, a shared Amazon where anyone could innovate on the store itself. Different people would settle on the version of the shop they prefer, but the underlying product catalogue, the transaction data, the inventory, all of that needs to remain consistent and unbroken regardless of what someone does to the experience layer above it.
This is the harder and more interesting problem. Current platforms like Shopify, WordPress, and Salesforce handle it through plugin and extension models that are heavily constrained. The vision here is more radical: anyone can change anything on the surface, with the shared layer beneath protected and governed.
The way I imagine this working is as a separation of concerns, taken to its logical extreme. At the bottom, narrow data products, each focused on as small a concern as possible: a product catalogue, a payment ledger, an identity record. Each one atomic, self-contained, and shared. At the top, varied experience layers where the forking and versioning happens freely. Different versions of the experience adopt whichever combination of shared atomic elements they need from underneath. It is the same principle as atomic design in UI, where shared components are composed into different interfaces, but extended downward through the entire stack. The data layer can still evolve, but changes need collective approval, more like editing a Wikipedia page than pushing to your own branch. The experience layer stays fluid and open to innovation.
Even in this world, many people will not build software, and many who do will not do it well. But the attention-based model means value concentrates naturally on quality. The people whose iterations are genuinely better attract more use, which generates more revenue, which flows back through the tree. The reward is not for producing code. It is for producing something worth using.
This is an early vision. The economics are heading in this direction. The infrastructure to support it is yet to be built. But the trajectory from "software is expensive to build" to "software is cheap to build" is already underway.
The economics of software will keep shifting. The tools will keep improving. But the underlying principle is the same one this essay started with: build things that solve real problems, and give the underlying architecture enough attention that it can support what comes next.