Content operations aren’t fixed with a headless CMS

Headless CMSes won’t solve your content problems.

How the headless trends move content complexity upstream.

When you do a Google search on the term “content operations”, the first page of results is overwhelmingly made up of ads from headless CMS vendors. To be clear, the vendors themselves have heads; it’s their content management systems that don’t come with a way to present content. The vendors are claiming that content operations can be achieved by licensing the software that the particular vendor happens to promote.

I hate to be the bearer of bad news, but a headless CMS is not the answer to a company’s content problems. It’s a little like a guy buying a car to fix his marriage. When there’s a breakdown that involves logic, emotions, household friction, romantic shortcomings, or whatever other family dysfunctions may be contributing to the relationship breakdown, buying a car won’t fix it.

Content problems that need attention

When organisations start looking for a headless CMS, it’s usually because there’s some sort of operational friction that is slowing down the effective management of content. Some of the common reasons I’ve seen during the last couple of years:

• Inability to scale. The organisation won a contract that requires a sudden surge of product content. The product owners had muddled along with subpar ways of producing content but without even knowing what best practices are, let alone aspire to follow them, they decided to look for a technology-based fix. Because they believed that technology fixes things.
• Regulatory compliance. The organisation operated within a regulated industry, and an audit revealed that there was a non-compliance issue. The organisation realised how poorly their content was being managed, and started to look for a way to control how their content gets delivered.
• Reducing time to publication. The organisation had a particular window of time in which to update its website content. They had had gotten into an expensive and inefficient cycle of contracting, onboarding, delivering, and then offboarding contracted services to deal with these surges. The organisation wanted to be able to publish within the required time period while containing costs and started implementing a headless CMS without looking at where the bottlenecks actually occurred.
• Production efficiency. The poor operating model for content production started to slow down the development of the software itself. In one team, a separate set of code had to be maintained for each language variant because content was hard-coded into the app. The product manager realised where the blockage was and looked for ways to merge content into the product in more efficient ways.
• Better user experience. The organisation needed to produce more content, for various stages of the user journeys, but couldn’t keep up. They were searching for ways to deliver the right content to the right audiences at the right times, and tried to use a tagging function in a headless CMS to get the job done.

The headless CMS doesn’t fix content operations

In each of these situations, the problems are not something that a headless CMS – or any other technology, for that matter – can fix. Remember the analogy of the guy who buys a car to save his marriage? Well, it’s actually a step worse. This is like the guy having a middle-age crisis who sells the family car and brings home a sports car.

Not only is he not going to fix his relationship problems, he now has to do multiple school runs each morning and evening, he needs to rent a more appropriate car when they want to go somewhere as a family, and his wife wavers between asking for a divorce or having him committed.

The problem in all of the organisational problems is that the problems didn’t originate at the delivery end. If no one looks at how the content is created, manipulated, stored, reviewed and approved, then fixing the “delivery service” won’t fix the source problem. Because, after all, a CMS is a type of vehicle that delivers publication-ready content with varying degrees of sophistication. The problems originated with the operating model for producing content.

Let’s to back to our analogy of the unfortunate purchase of a car. How does a rational guy buy a car? They look at what the family unit needs – number of children; ski rack; wheelchair carrier; a dog, perhaps. They look at what the driver needs – automatic or manual transmission; seat that raises?

They look at the operational needs – does the car need to fit in a tight parking spot; transport bins to the recycling centre on a regular basis; drive through mud or snow? They look at the content of the vehicle itself – how important is are parking sensors; back-up camera; heated seats; heads-up display; back seat leg room; fold-down seats?

Then, the last step is to choose the car that will get the job done. The guy (I don’t mean to single out men, though statistically, I’ve only worked with one female CTO in the last 20 years) will match the requirements to the vehicle, eliminating the ones that aren’t suitable.

They won’t expect the vehicle to make the driver taller or widen the parking spot or eliminate the need for a wheelchair. But they will recognise the boundaries and work within them, to get the best outcome possible.

The content problems described here have one thing in common: they seem to be delivery problems, fixable by technology, but digging a little deeper reveals that the problems begin further upstream in the production process. The content is hard to locate and hard to work with. The way that content developers naturally work is not accommodated.

There is no central repository, no automated workflow, no efficient way to track comments, no way to compare versions or track approvals. The headless CMS is the “fast fix” – buying the sports car – with the hopes that automating delivery will do the trick.

Does a headless CMS serve a purpose?

Could a headless CMS fit within the content ecosystem?

Perhaps, if the requirements point to the need for one. More often than not, the headless CMS doesn’t fix the problems with content operations experienced by the content teams before publication-ready content reaches the headless CMS. 

What the headless CMS likely will fix are some of the problems of the software developers and other technologists concerned with the delivery side of the equation. It’s important to distinguish between these two areas, and know what you’re trying to fix.

---

---

Learn more about headless CMS and ContentOps:

• Listen to my conversation with Jeff Eaton
• Learn about the first principals to ContentOperations
• Learn the basics of Content Operations

---