Future-Proof Your CMS: 5 Indicators to Go Headless

Headless is taking the content management world by storm—and rightly so. Splitting your CMS stack into best of breed platforms for the frontend (website visitors) and backend (marketers) can unlock a terrific amount of institutional value and agility when used appropriately. But headless is still a shiny new object, so take a step back to check if you’re solving a relevant problem, or just following the latest tech craze.

A variety of technologies today can support a headless content approach and the space is quickly filling up with a variety of players, many of which are tiny companies. Innovation is happening rapidly, and it isn’t clear who is going to win, but the leading platforms right now are Contentful, Kentico, WordPress, and Drupal.

For this article, we’ll focus on what you should look for in your own organization to know whether looking at headless is a smart move or likely create more problems than wins. If you encounter any of the below indicators, then headless might be a good approach for your organization.

Indicator 1: You have true multi-channel content marketing operations

Most marketing teams are either very small (one to two people that manage content) or they operate in a highly siloed manner, with teams that focus on digital, social, and other channels. However, there are organizations that truly manage content centrally for multi-channel uses like a website, various social channels, a native mobile app, a custom web application, and various internet-connected devices.

If your organization genuinely has a multi-channel need, a headless CMS, with its API-first architect and agnostic rendering layer assumptions built into the platform, is likely going to provide considerable technology-driven operational efficiencies and be worth the additional effort to integrate into your workflows. The entire marketing team can use one platform to edit, share, refine, mash up, and iterate content.

Leveraging a central content platform across your marketing team—both intra- and inter-business units—lets you build a single editorial workflow that integrates with downstream marketing needs, like translations and legal review, instead of having to support multiple workflows and platforms.

You should expect to realize cost savings in implementation and ongoing support costs, as well as potential marketing team benefits from system unification.

Indicator 2: Your developers are bottlenecked

One of the primary drawbacks of a monolithic CMS like WordPress or Drupal is that the frontend theming layer is tightly coupled with the backend data layer. That means that a developer working only in the theme layer must still be comfortable with PHP, a backend programming language. In a headless approach using JavaScript at the render layer, a themer only needs to know HTML, CSS, and JavaScript, the languages already in their toolkit.

In a monolithic architecture, one of two things happen:

• Most of the time, the frontend engineers are highly-dependent on the backend engineers to constantly be preparing and making tweaks to the templates the themers work on. The major downside is that the frontend engineers are often blocked waiting for the backend engineers to be free to assist them. This isn’t the fault of the backend engineers. It’s normal for needs to shift rapidly during theming activity, so it’s impossible to 100% accurately predict the needs of heading theming without actually starting.

• Alternatively—and far less often in practice—really daring frontend engineers begrudgingly learn to code in PHP so they can avoid having to ask the backend engineers.

What all this means is that development often gets bottlenecked when engineering teams are supporting the ever-changing needs of the digital marketing team. Not to mention engineering is also handling parallel work streams of different priorities for different business units.

If any of this sounds familiar, then you have a harsh reality to accept: Your process is not the problem; your approach is. Without fundamentally changing your approach, you will not be able to fix your bottleneck. Moving to a headless architecture reduces dependency on backend engineers and empowers frontends to get more done with the tools they already know.

The additional benefit is that you will have a wider pool of engineers to hire from instead of having to look in WordPress communities or Drupal communities or whatever CMS you are using. You can just look at the JavaScript frontend community, which cuts across all technologies.

Indicator 3: You want to be on the bleeding edge

If you ask a young web developer which technologies they want to learn, none of them will say a CMS like WordPress, Sitecore, or Drupal. They will all likely say they want to focus on frontend JavaScript platforms like Angular and React.

To future proof decisions, many organizations simply want to bet on bleeding-edge tech and are willing to make the investment to enjoy longer-term efficiencies. If this is a priority for your organization, then go headless. You will be skating to where the puck will be.

If your organization wants to move from waterfall project management to agile, then you should seriously consider going headless. If your team was previously excited about moving to continuous delivery, it’s the right fit for you, too. Look to examples of digitally-native brands that have embraced this architecture from their start, like Glossier in the cosmetics space and Casper in the mattress space.

Remember: Innovation doesn’t start at the enterprise. It ends there.

Indicator 4: You are experiencing brand consistency issues across business units or divisions

It’s not uncommon for a business to exist as a collection of disparate legacy decisions made by the different marketing teams that support the lines of business across the organization. Today these organizations are using different content platforms with different editorial workflows across multiple business units. The major pain points in this scenario are inconsistent brand experiences and inefficiencies in integrating different content platforms into downstream services.

If you have a mandate to consolidate and streamline content management across multiple business units, you have the challenge of enforcing standardization of technology across business units that by design have different needs and serve different markets. As a technology leader, you must find the right balance between standardization, and the cost of not addressing those unique needs.

Headless CMS options offer a potentially compelling compromise to standardize the backend—the editorial experience, the content repository—while leaving the frontend experience (the experience that needs to be optimized differently for each business unit) infinitely flexible to meet different needs.

Indicator 5: You use microcopy in your customer journey

Leading usability expert Jakob Nielsen defines microcopy as “a type of UX copywriting in the form of short text fragments or phrases, often presented with no additional contextual support.” Microcopy is increasingly being created by slicing off parts of website copy and injecting it into other digital channels like social, advertising, internet-connected devices, and mobile apps.

Traditional CMS platforms are designed to track the content of copy on a page-by-page basis, which implies that the copy is large. Headless CMS solutions make no such assumptions and serve both tiny copy and large copy experiences well in their architecture and backend editorial experience. For these reasons, microcopy is often better supported with headless approaches than traditional CMS platforms.

For more information on microcopy, I recommend Contentful’s great article.