The diminishing returns of traditional CMS publishing

Bye, bye push button publishing in minutes. Hello developer queue :(

To meet the demand for more sophisticated websites and digital experiences that span phones, wearables, digital signage, AR/VR applications and more, developers have to customize traditional CMSes until they are barely recognizable. The result is an amazing digital experience for customers powered by a nightmare on the backend.

Overly customized CMSes have lost their stability and ease of use. Editors can enter content, but they can’t publish changes without a developer. Wait! Wasn’t the power to publish content without a developer the whole purpose of having a CMS? When you lose that core function, what is the CMS really doing for you?

I clearly remember the first time I lost the ability to publish content myself. We had just installed a new CMS — one I had used before to publish entire sites myself. The developer walked me through the “publishing process” with the familiar options to publish or schedule content to go live later. But that wouldn’t actually publish anything. What? He went on to say that I would need to message him with the title of the page, a link to the content and my desired publication date. I would then need to check to see if the content actually went live and repeat the process to make any edits.

Overnight, publishing content had become a significantly slower and more convoluted process. What’s worse, the CMS caused the developer tons of headaches. His time was alternately spent troubleshooting the CMS and publishing content. The big projects he was excited to deliver, had to be pushed back.

As the power of publishing swings back to developers, it creates a massive backlog of “quick fixes” that hang over the heads of the development team. Each fix or publishing request seems small, but it takes time for a developer to come off the project they were working on, understand the request, implement and test the change, run it past the requestor, push it live, troubleshoot if something goes wrong and close out the request. Even typing that took longer than I thought!

Editors are annoyed that developers can’t push content faster (after all, we used to be able to do it in minutes), and developers are frustrated by constant interruptions.

Pushing a CMS past the point of diminishing returns

In a talk at JamStack, Justin Watts of Loblaw Digital explained how they had gone so far out of the box to work around CMS limitations, that they were no longer getting the value the CMS provided out of the box. As part of a larger effort to accelerate development, they replaced their CMS with Contentful and restructured their groups to focus on parallel workflows for content, components and features. This empowered their content group to take charge of creating, managing and publishing content, while developers worked in parallel to build new components and features. In one month, they built a new digital campaign that previously would have taken them a year.

This is a common story among Contentful customers. As traditional CMSes reach their limits, organizations ramp up the customizations and start adding more CMSes to meet their needs. Eventually they hit a point of diminishing returns where the CMS (or often CMSes) become a roadblock to publishing and a burden to developers.

Contentful helps them unify and streamline content operations into one flexible content hub and empowers editors to own content management and publication again. This frees developers to focus on building and shipping digital experiences. With the CMS roadblock removed, content and development flow faster.

3 myths that keep content creators from demanding a better CMS

Using traditional CMSes to deliver sophisticated digital experiences, slows developers and content creators down. Despite this, many organizations keep adding CMSes. A single organization might have a small army of CMSes to manage content for multiple products, channels and geographies.

Why are content creators burdening themselves with all these content silos and redundancies? To publish content faster we need to dispel the myth that the CMSes we have grown familiar with are still meeting our needs.

Myth #1: Our CMS helps us deliver a better digital experience

As a marketer, I want to be able to do new things in the digital space and CMS vendors tend to focus on how their CMS makes that possible. In reality sophisticated digital experiences are built by developers, who typically work better and faster without the limitations imposed by cumbersome CMSes.

Myth #2: Editors need a CMS to publish digital content

Editors and marketers want a CMS so they can create and publish content across digital channels. But in many cases it’s the developer who pushes content live. The CMS is just a means of getting that content to the developer; it isn’t really helping editors publish content at all.

Myth #3: All CMSes work the same way

For a long time, this was true. Despite variations in programming languages, server configurations and other features, traditional CMSes are at heart a publishing tool designed for web pages. The farther you push them beyond that function, the less helpful they become.

But the CMS market is changing. Headless CMSes are designed to push content out to any digital product or channel. Editors can manage content for multiple products or channels from a central hub and developers have more freedom in how they ship content.

Contentful’s content infrastructure takes headless even further by combining features that help editors and developers work faster. This empowers developers to build more sophisticated digital experiences faster without taking power away from less technical users that need a CMS to publish content. Our editorial app lets editors spin up new pages and publish content in minutes, putting the power of publishing back where it belongs.

So does your CMS really help you publish faster? If not, maybe it’s time to try something new.