The Commerce Platform Running Your Marketing Team

One of the more revealing questions I ask early on when we're talking to a product brand is: what does it take to update a page on your site? Nothing complex. A seasonal landing page refresh, a new lifestyle image. Who does that, and how long does it take?

The answers tend to follow a pattern. The marketing team raises a ticket, the ticket joins a development backlog, and the campaign that was ready two weeks ago goes live when the moment has already passed (if it goes live at all). The marketing team builds buffer into every project timeline. They've learned from experience that the platform will need it.

In my experience this is almost never a people problem. The development team is doing their job. The marketing team is doing theirs. The platform underneath everything was designed to handle transactions, and handling transactions is what it does well. Content, brand storytelling, campaign management: these were afterthoughts at the architecture stage, and they tend to remain afterthoughts.

The platform your commerce team chose and your marketing team inherited

Most ecommerce platforms get chosen for the right reasons at the time. The decision tends to sit with engineering or IT, which makes sense: integrations need to work, the back-end needs to be reliable, the checkout needs to handle load. Marketing teams are consulted but rarely decisive. The result, very often, is a platform that handles the commerce side well and gives the marketing team a working environment that gets harder to live with as their ambitions grow.

This matters more now than it did five years ago. For established product brands, particularly those with a trade or wholesale heritage, the move into D2C has changed what the website actually needs to do. Trade buyers make rational decisions based on spec sheets and lead times. Consumers need to feel something about a brand before they buy. The content job is entirely different, and the platform needs to support it. Most don't, at least not without development resource that has other calls on its time.

What the friction actually looks like

In practice, the day-to-day friction for a D2C marketing team tends to look the same regardless of what they sell. Getting a seasonal landing page live requires a development ticket. Editorial content around a product launch arrives on the site two weeks after it should. When a sponsored athlete places at a major event, or a product gets featured in the right publication, the ability to respond on the same day simply isn't there.

All of this requires touching the site. On a transaction-optimised platform with no CMS capability, touching the site means going through development. The campaign that should take a day takes two weeks. The reactive content that would have caught the traffic arrives after the moment has gone. The marketing team learns not to expect otherwise, and stops trying.

This is the friction that doesn't show up in your analytics. It shows up in the opportunities you didn't take, and in the gap between what your brand could be saying online and what it's actually saying.

What this looks like when it's sorted

ROLA make cycle carriers, have a clear outdoor lifestyle identity, and came to us with a well-established B2B wholesale operation. Going D2C was the logical next step and the products were right for it. The obstacle was that their parent company's ecommerce platform had been built for transactions with no meaningful CMS capability. The marketing team couldn't build the kind of content a consumer audience actually responds to, and responding to seasonal moments meant waiting on developer resource with other priorities. The brand identity they'd built in the trade had no way of reaching a consumer audience because the platform had no tools to express it.

We decoupled content from commerce. Contentful came in as the headless CMS, completely separate from the parent platform's commerce layer, and Laravel sits in the middle as the orchestration layer, feeding catalogue data into Contentful and powering dynamic components without a developer needing to touch the code for routine updates. We also built a component library designed around ROLA's lifestyle identity, so the marketing team were working with content tools shaped around adventure and the outdoors rather than product specifications.

The result was a marketing team that could run the brand on their own terms. Campaign pages and seasonal updates became manageable by one person in a content editor rather than via a development ticket queue.

The multi-brand version of this problem

For businesses running more than one brand, everything above plays out simultaneously across the portfolio, and the compounding is real.

Each brand has its own seasonal calendar and its own visual identity. The content requirements for a brand selling cycle carriers and a brand selling roof racks are genuinely different, even if they share a parent company and an ERP. Their audiences are different, their buying moments are different, and the stories that earn trust for each of them are different. Treating them as a single content operation because they run on the same platform is the wrong call. But when the architecture forces everything through the same development bottleneck, genuine independence per brand becomes difficult to maintain.

What I find most telling in these situations is not the platform itself, but the workarounds. Marketing teams that can't touch the site directly tend to build their own: external landing page tools that aren't connected to the main domain, campaign microsites that sit outside the platform, product content that lives in a spreadsheet because updating the PIM takes too long. These solutions work well enough individually and create a real mess when you try to understand what's actually happening across the portfolio.

The businesses I see getting this right are the ones that have separated the question of brand experience from the question of commerce infrastructure. The commerce layer can be shared and probably should be. The brand expression on top of it needs to be genuinely independent per brand, with the marketing team for each one able to move without waiting on a shared development queue.

Research into headless commerce adoption found that businesses making the switch reported 50% faster launch times for new digital experiences, and 77% reported greater operational agility in making storefront changes. Those figures reflect something most marketing teams already know from experience: the platform either supports the pace of the work, or it absorbs it.

If your development team is regularly in the path between a campaign idea and the site, it's worth understanding what that gap is actually costing you across each of your brands.