Content Platform, not CMS

My team builds digital products for some of the most well-known brands in the world. We usually support multiple channels and markets at scale. Think mobile, Web and WeChat apps used by tens of millions of customers in China, Japan and the US.

All these touch points need content and media that is created by many different individuals and teams, in multiple languages and presented in a variety of formats.

Answering well to all these specific needs is hard. Very hard.

When my team gets involved, most clients have a solution that tackles one specific team, channel or market well enough, but scales poorly to other use cases. This also means there are multiple competing solutions used by other teams.

With that approach, it’s impossible to have a consistent and sustainable content strategy.

Let’s have a look at how we solve this with a proper content platform play.

What’s wrong with CMS

Most organizations still use a traditional CMS. Think Drupal, Sitecore, AEM, Salesforce CMS, etc.

These platforms are pretty good at tackling low-hanging fruits, but they break down quickly:

• Costly. These systems require a team of experts to set up, customize and maintain, especially since they’re responsible for the entire experience from content contributors to end users. Don’t think that Open Source solutions will make this less true: you’re saving on license cost but need to account for the cost of hosting, security, updates…
• Poor user experience. Traditional CMS not only enable content management but are also in charge of generating the end user experience (e.g. website). It can’t do both well. Most of the time it is optimized for content editors, at the expense of the experience for your customers.
• Siloed content. These systems are almost always designed with a single channel in mind (e.g. Web) and with the assumption that all content is created and managed there. The reality is that you will need to support many channels over time (mobile, 3rd party apps, etc) and many data sources (e.g. PIM, DAM, etc).

These shortcomings almost always lead to the same outcome: many different teams adopting multiple solutions that best fit their needs.

That’s wasteful and costly, sure. But it also means you can’t build internal best-practices for content management.

That’s why a new approach emerged.

Going headless…

The key difference of a Headless CMS is that it doesn’t have a built-in presentation layer. It is purely focused on offering a tool to create and manage structured content, and then making it available to others via an API. The end-user apps are usually responsible for the rendering.

This approach has many advantages, but above everything else it allows us to build systems that are:

• Lean. There is none of the complexity related to generating a front-end experience. Most, if not all of what you’ll customize can be done via configuration, with little to no dependencies.
• Focused. You get a system that is optimized for a single use case: managing content. This means a much simpler user experience and a much better out-of-the-box setup that will fit most content teams.
• Omnichannel. By definition, a headless CMS is able to support any channel. You can feed content to mobile apps, websites or 3rd party apps (e.g. WeChat mini-program).

Beyond headless: the content platform

We’ve been using a headless approach for about a decade now.

But we usually talk about “content platforms”, with a few key characteristics:

• Structured content first: defining the content structure first (content types, single types, components, etc) based on the organizational needs and information architecture, rather than dictated by the design of your front-end, like you would with a traditional CMS.
• Reusable data structures: a well thought out content platform should maximize the amount of reusable structured content. Between channels, teams, projects… If you need to perform the same data change more than once, you’re probably doing it wrong.
• Unified content hub: a content platform should be the same for all teams, making all content available at once and allowing you to override or enrich it. This usually means integrating other data sources with your content platform (e.g. PIM, DAM, etc).

What does this look like?

I’ll use the example of one of our long term clients.

We work with them in multiple markets (APAC and US) and across many different channels, including Web, mobile, WhatsApp, WeChat, LINE and KakaoTalk.

When we were brought in, content was scattered across multiple CMS (SaaS and bespoke) managed by different teams. We had to deal with lots of duplicate and conflicts, lack of documentation, no standard on data structure, on top of the complexity of dealing with opaque translation and editorial workflows.

A lot of our time was spent trying to figure out where the content was, how we could retrieve it and what were the business rules for it.

Any change or extension to the data structure we had access to was slow, if possible at all.

Over the course of a year, we deployed an APAC content platform that integrated all of these fragmented content sources, accounting for their specific logic, and offered a unified interface for local teams to manage, extend and modify content for all channels: marketing campaigns, product descriptions, channel-specific content…

A few highlights:

• Open Source headless solution: we deployed and configured Strapi, an Open Source CMS, into their cloud environment integrating with their corporate login system. This translates into a much better Developer Experience thanks to the wealth of resources (documentation, tutorials, plugins, etc) made available through the Strapi community.
• Structure first: content structure was priority number one. We designed content types based on an audit of their global product and content structures, which we extended with data relevant to local teams or specific channels (e.g. mobile apps).
• Data integration: we set up data pipelines to synchronize data from global and local systems to our content platform.
• Advanced features: we integrated third party platform, offering search and translation services directly on top of our content platform, making it available to all channels and markets.
• Security: we put additional effort on securing data access to the content API by putting it behind an API gateway, allowing first party apps to access the content directly.
• Agile expansion: we’ve seen a gradual adoption of our content platform as the canonical source of truth, even from local teams that now favor it over local systems as its content is reliable and complete. This in turn means we have regular requests for extensions to our initial data structure, which we’re able to accommodate for in a matter of days.

Part of an agile MarTech strategy

While a content platform still relies fundamentally on a headless CMS solution, it’s important to understand the nuance. A well executed content platform strategy will yield benefits beyond the technical team, allowing your entire organization to rely on and invest into a single repository of content that supports all customer experiences.

Most organizations underestimate the impact that a poor content strategy has on costs, teams and products.

Similar bottlenecks exist in other parts of the MarTech stack. We’ve talked about CDPs for example, but data pipelines and marketing automation in general play a major role in the success or failure of a digital transformation. We’ll cover some of this in our upcoming “Omnichannel Blueprint” ebook (subscribe to our newsletter and we’ll let you know once it’s out).