Poor Editorial Experience Doomed the DXPs

Built in Google Docs and published with Pantheon Content Publisher

How often have we all heard questions/complaints like, “I submitted the copy but who knows when it will go live?” or “Will it look like this when it’s actually published?” or even “Are you sure this is the right way to post this kind of content?”

The reality is that most CMS (or “DXP”) implementations are not tools content teams use themselves with confidence. They’re not where real creative work happens, and they’re usually operated by a small group of specialists.

This bottlenecks organizations, and misallocates rare technical expertise to menial production work. It’s better than hand-coding HTML pages, but not by much. That’s a huge problem in our industry, and a huge part of why the category as a whole has struggled to build or hold market adoption.

Editorial User Experience Isn’t a Nice to Have

As we’ve pointed out, the data shows the original cohort of DXPs are in decline. But that doesn’t mean they weren’t after something useful. The value they wanted to deliver was real — organizations need to maximize the potential of their owned digital channels — but in hindsight the flaws in their hypothesis and execution are easy to spot. Though these may appear obvious now, it’s worth taking the time to understand what went wrong, lest history repeat itself.

The case for DXPs was founded on a prediction of market consolidation, similar to ERP and CRM. Though it seemed reasonable at the time, this turned out to be 180-degrees off from the reality of an exploding Martech ecosystem. This monolithic delusion was further disadvantaged by being tied to the legacy Enterprise IT delivery model, and the failure to adopt an agile approach put the category founders further at odds with a constantly evolving market. But finally, putting everything under one roof meant needing to own the editorial process, which these software companies were simply not equipped to do.

While the DXP’s all-encompassing vision let them pitch a comforting C-level story about “a single pane of glass” for the entire digital production line, out in the field nothing could be further from the truth. The reality is over a billion content creators use Google docs to collaborate on content, and the editorial experience provided by Docs and its kin is multiple generations ahead of what DXPs can offer, a gap that is only widening in the era of generative AI.

But the DXP playbook required corralling creative teams into a second (or third) rate Enterprise Software Experience for content, with predictable results: people went ahead and did their work elsewhere, and then copy/pasted into the “official” system. It’s a tale as old as the web, but the DXPs inability to change this dynamic severely undermined their value proposition.

Google Docs vs. DXP: A Content Workflow Comparison

The people behind AEM had the presence of mind to see this coming, and tried to head it off with Adobe Franklin (aka Helix), which was an attempt at deep integration with the Google Workspace. However, they appear to have faced and failed the classic “innovators dilemma" of swimming against the tide of the main line of business. Franklin never graduated from side-project status, and currently lives on as an obscure add-on, confusingly called “Edge Delivery Services.”

While Adobe’s effort didn’t meet the moment, at least there was an attempt. None of the other major players even tried, a contributing factor in their ongoing decline. When you are neither the place where digital experiences are created or delivered, you don’t have much of a claim to being a platform.

Web-Native Creativity Offers a New Way Forward

While the copy/paste air gap is a problem as old as the web, over the past decade something important has changed: the creative toolchain for digital production is now web-native. That means the preferred software for creative professionals of all stripes are fully online and internet-connected. DXPs missed the boat on this, but that doesn’t mean a better world isn’t possible.

With content teams working online in Google Docs (vs by emailing around Word attachments), it’s suddenly possible to meet them where they are and make their tool the source of truth for web publishing. Likewise, the fact that Figma has run the table in the design industry opens the door to a world where the design team’s outputs are no longer static “comps,” but rather systems of web-native artifacts that integrate directly into the production pipeline for end-user experiences.

Second-generation “composable” players seemed to be headed in this direction, but most of them ran aground on the rocky shoals of complexity well short of durable product market fit, and their long-term viability is also now in doubt.

The problem is that a fully disassembled toolkit requires too much work and too many decisions to put together. The lack of standardized playbooks makes ongoing maintenance too costly. Most of the market can’t afford bespoke systems, and is becoming just as disillusioned with the Headless craze as they were/are with the first-wave DXP monoliths. Doing a multi-year digital transformation only to end up still needing web developers for routine content operations doesn’t make anyone happy.

However, so far the moves from next-gen players are… regrettably unimaginative. Headless CMSs are doing M&A to stick on heads. Integration platforms are tucking in commonly required tools and slowly acquiring their way to yet another “suite.”

It’s the same tired Private Equity playbook. Never delivers real innovation; always ends in tears.

But if we mature beyond the naive ambition that ours will be the one tool to rule them all, and instead look for where people are doing their best work, and how that work can be best orchestrated and governed, a very different paradigm from the DXP comes into focus. Content Publisher embodies this approach.

It brings together the best of what web and content teams already use today, seamlessly integrating Google Docs and web CMS like WordPress and Drupal. We can finally end the charade that people sit down and crack open their CMS to start creating content, embrace the reality that these tools are really only for last-mile, and eliminate the tedious back-and-forth that inevitably ensues when content created in one place needs to get edited somewhere else.

Further, with its GraphQL API and Next.js SDK, Content Publisher also effectively turns Google Docs into a Headless CMS. The Workspace Extension lets content teams directly manage metadata and complex content elements natively in Docs, and connect to a preview/production pipeline that normalizes content into Markdown, ready for front-end consumption.

While most analysts now advise that headless is a feature, not a category, that DXPs are built, not bought, and that the future is composable (whatever that means), with Content Publisher, Pantheon aims to leapfrog even the current crop of “next-generation” platforms. Paired with the underlying power of our industry leading WebOps platform for WordPress, Drupal, and Next.js, this capability offers true innovation without the tool fatigue or excessive change management.

Stop Starting Over - Start Compounding Value

One of my most important decisions as a leader at Pantheon was not to enter the DXP category back in 2019. Since then we’ve made careful study of how things played out, and are confident today that ignoring the feature wishlist compiled by analysts, instead sticking with what our customers were asking for, was the right call.

By maximizing the effectiveness of the already existing tools in the team’s workflow, Content Publisher can simultaneously improve productivity and save cost, all without requiring a big lift to implement

For every dev team that thought it would be so simple to keep their content in Markdown, only to realize GitHub is an unfriendly environment for less technical team members, Content Publisher is a turnkey path to self-serve publishing (and an end to simple copy edits cluttering the dev backlog).

For every Headless CMS licensee wondering why they are paying six figures for an editorial UX from the 2000s that still requires specialist web jockeys to maintain a handful of pages, Content Publisher is a way to remove cost and friction from the equation.

For every CMS team tired of slogging through an hour or more of extra production work to take posts from where they’re created to the website itself, Content Publisher takes the headache and human error out of the process by replacing copy/paste with a fully automated API call.

For anyone feeling pressure to do more with less, Content Publisher offers a way to pitch a material upgrade in efficiency and productivity without throwing out their existing investment in their web platform. Whether it’s agencies looking to help their clients move forward, or corporate IT and Marketing teams seeking a way to build compounding value, this approach can deliver value in as little as a few hours, if not a few sprints.

The full vision is quite ambitious. Meeting developers where they are (in GitHub), content teams in Google Docs (and friends), and then plugging in Figma for design, all tied together with a data and analytics layer so teams get real and immediate feedback on how their work is driving outcomes. We’ve put down the cornerstones of the architecture, and today we can show the first steel thread of delivering content from end-to-end. There will be many more to come.

P.S. This post (the whole site really) is built with Content Publisher. If you want to see how I and my VP of Corporate Marketing Kevin Shively worked through the spice level on this post in real time, check it out below: