The Economist

I’m responsible for the CUE CMS and the CP2 content platform, which underpin everything The Economist publishes across web, app and syndication clients. That includes articles, homepage curation, index pages, podcasts, video, images, newsletters - almost everything The Economist puts in front of subscribers goes through us in some capacity.

This is mission-critical infrastructure. If it fails, publishing stops. If it is poorly structured, everything downstream becomes harder. We define how content is structured, how it moves through the system, and what the front-end needs in order to accurately interpret and represent the data. That means thinking at the schema level as well as the workflow level.

Owning this layer means setting direction within clear boundaries. I own the roadmap and structural decisions within the publishing platform, including metadata, workflows and sequencing of work. I do not control every downstream surface, but I am accountable for how content is structured and handed off. The role sits at the intersection of editorial needs, engineering constraints and long-term platform integrity.

Most of the time the starting point is friction.

Sometimes the problem shows up as a repeated engineering workflow. Sometimes it is editorial saying something feels slow or overly complicated. Sometimes it is me noticing that a piece of logic feels fragile or duplicated across systems.

I do not to jump to solutions. I want to understand what is actually happening. I will talk to the people doing the work, look at how the workflow currently behaves, and learn what the system is doing underneath. That might mean pulling data, looking at tagging patterns, inspecting a GraphQL query, or reading through a repo to understand how something is wired.

The most important step is framing the problem correctly. A solution is only as strong as the shared understanding of what we are actually trying to fix. If the framing is misaligned with the problem it is solving, the solution will be too.

Once a problem is clear, my focus shifts to scoping something we can ship that is realistic and can offer value to customers.

That usually means breaking the work into phases. For example, with podcast publishing we started with a single featured episode component before expanding into full show publication. It let us validate new workflows and reduce risk before going broader.

I work closely with engineers at a schema and data level. What fields do we actually need. How should this be identified. What needs to be stored. What can be inferred. What creates long term complexity.

From there it is:

• Making sure dependencies are clear
• Aligning with delivery to agree what we can do and when
• Learn what trade-offs may be required
• Breaking down work into more and more granular tickets
• Overseeing and supporting engineers during development
• Keeping stakeholders updated

Importantly, not assuming that just because we've done the previous activities before we can also assume it's all correct. We must constantly check our dependencies, check our delivery progress, & consider trade-offs.

Test & test it & test it & ship it

Shipping is not the end of the process. A product has to continually offer value to customers, and must be continually monitored and optimised.

A large part of my role is alignment.

I present the roadmap monthly to the CPO and CTO. That means explaining what we are prioritising, what we are not, and why.

On the editorial side, I work closely with the Digital Editor who oversees all of our Digital products, as well as leads and members of the teams which use our CMS and other dependant systems. This keeps us aligned with real publishing needs. Other editorial engagement tends to be project based - if we are changing video workflows, I will sit down with the people actually producing videos and learn their process.

I also work closely with other PMs. Platform decisions rarely sit in isolation. Any work we do requires work from other teams, and we are frequently an enabling team for the delivery of front-end initiatives. Scope and timelines are agreed collectively before engineering starts & relationships are vital for the smooth delivery of high quality products.

Alignment isn't just doing what people want. Where necessary, I push back. If something introduces long term maintenance cost for short term gain, we have that conversation. If the work is disproportionate to the user value, we have that conversation. In my experience, the best way to get people to align is when the reasoning is clear.

Earlier in my career I worked as a software engineer before completing the BBC's Software Engineering Graduate Scheme. That background allows me to engage with systems at a technical level and understand the implications of the decisions we make.

I read production systems to inform product decisions. Whether reviewing tagging logic, inspecting queries, or examining configuration, the goal is to understand how behaviour emerges from the system and where complexity, fragility or duplication may exist.

This context allows me to shape better decisions. For example, when defining identifiers and URL structures for games content, the choice affected how content was stored, queried and surfaced across multiple products. Getting that structure right avoided downstream inconsistencies, reduced future rework and ensured the content could scale cleanly across surfaces.

I think about which direction I see the platform is going short-term, medium-term, & long-term. It's important to not just think 'I think this is a good idea, so therefore we should be aiming to do that' - opinions should be based on facts, and data, and research, and the expertise of your colleagues. Long-term strategy dictated by responsible parties does not stick, strategy works best in my experience when teams and departments feel ownership of the goal and the plan.

For example we currently have content spread across multiple systems. I aligned our team around a strategy for a more unified model where articles, video, podcasts, and newsletters sit within a consistent structure. The reasoning coming about from slow editorial workflows, cumbersome engineering work, difficult alignment.

We can't achieve this overnight, but we make small decisions and big decisions towards an overarching goal state.

On a day-to-day basis, every decision is a balance. Sometimes we extend an existing data structure because the cost of building something perfect is too high. Sometimes we invest our time properly because we know we will pay for it later if we do not.

With podcast publishing, we reduced publishing time from days to minutes by removing the engineering dependency. That changed behaviour immediately.

On the homepage side, we made components reusable across different and surfaces. This reduced workflow duplication and on the technical side, makes new variants quicker and easier to spin up.