DXP for Marketers

The most crucial stakeholder for the success of any DXP is often overlooked by organizations. It isn’t the security team, the governance team, the IT team, or even the web engineering team. The most crucial stakeholder for the success of a DXP is the marketing team.

I can feel the collective “That’s pretty obvious, Justin” coming, and you would be right, but even if it’s obvious, I challenge you:  Are you really prioritizing the marketing team or just giving them the ability to edit content?

Are you really prioritizing the marketing team or just giving them the ability to edit content?

Marketing requires slick content editing, but also a platform that supports a healthy collaboration for all teams. Choose a DXP based on these three considerations, and you will have a healthy digital platform that strengthens all team members.

Marketing is directly impacted by development velocity

Not focusing on development velocity is like being in charge of a NASCAR pit crew and insisting your team focus on replacing the appropriate Little Trees (yes that one) air freshener that hangs on the rearview mirror, but not to worry about tire pressure. We all love a fresh-smelling car, but you have to optimize for the right goal: winning the damn race.

The latest Marketing Technology Landscape set a new record by counting more than 7,000 different solutions for digital marketers to move the needle with online engagement. Compare that to 2,000 solutions in 2016, and you realize there has been 350% growth in tools alone.

The greatest need for any marketer in this landscape is speed. Speed to innovate, to experiment, to learn, and to try. And the funny part about marketing speed is that it’s all about developer speed. Without a development team that can push changes quickly to a production website, a marketer is completely hamstrung and lacks freedom to maneuver.

You’ll know a DXP is focused on developer velocity by how effectively the platform embraces cutting-edge approaches to front end experiences. These cutting-edge approaches are built with the JAMstack—an acronym for JavaScript, APIs, and Markup—which is a broad term that describes site experiences that use a traditional content management system in the backend for editors, but use a modern, cutting edge approach using popular frameworks like React and Angular on the front end .

If a DXP platform is excited about these new, disruptive approaches to the front end experience layer and shows that excitement through a commitment to making their platforms compatible with these approaches, then the platform is likely to have better development velocity than those that do not embrace change.

Balancing editorial flexibility and fragility

Go play around with the latest inline mode of the new CKEdtior 5, the next generation version of the popular rich text editor used in many CMSs.

Remind you of anything? It sure looks a lot like Medium.com, the publishing platform startup whose most notable innovation is the stunningly simple, powerful, and intuitive rich text editor it employs. The editor itself is an absolute marvel and immediately upon release, created a noticeable gulf between what editors enjoy (Medium.com style-editing) and what was available in most content management platforms.

If you are thinking, “Damn, I wished my CMS interface worked like that,” I instantly know two things about you: 1) you are a marketer 2) you are using a DXP that hinders you more than it helps you.

The Challenge of Rich Text Editor vs. Structured Content

The challenge with offering this kind of rich text editor experience in a DXP is that organizations often have a need to break content into fields, to make it highly-structured so you can personalize, display, search, embed, and feed that content to a website, a mobile app, a kiosk display, and any number of other uses. If you use a pure Medium-style editor, like CKEdtior 5 inline mode above, you can’t use structured content, you have to store all of your content and layout in a single text field. This limits how well it can be used in other systems.

Essentially, the more highly-structured your content, the more powerfully it can be used, but the harder it is to maintain. Simpler content models, say with just one field to store everything, have far better ease-of-use when combined with a slick rich tech editor, but are fragile and don’t interoperate well.
So… Rich Text Editor or Structured Content?
The first important consideration is to decide whether you need structured content or not. This may seem as simple as asking, “Do we have more fields than just a title, body, and perhaps a category or term taxonomy?” But this is like asking an army if they have the right weapons to fight a war, but not telling them what kind of war they need to win.

Take a step back: You need to have a clear understanding of your overall digital strategy, or more specifically, what your overall objective is, and then broadly, what your approach to achieving that is. Once that is clear, then the tactics to achieve that become more self-evident, as should your content strategy, and, more crucially, what fields you need on your content to achieve your overall strategy.

A second important consideration is to know if your content is multichannel or not. Will this content only be used on your site, or will it also be used on social channels, smart devices, internet-connected devices, email campaigns, etc. If the content will likely only be used on the site, you don’t need much content structure. But if you intend to reuse this content, in part or in whole (like with microcontent), a lack of content structure if going to make it very hard to reuse elsewhere.

DXP tool lock in can hurt your marketing team post-launch and years down the road

Every DXP exists somewhere on a spectrum where at one extreme, the platform embraces an open framework, with a collection of best of breed products, and a highly-opinionated framework where a set of tools are tightly coupled.

AEM is on the far end where tools are tightly coupled. Acquia is on the opposite end where the platform embraces and open framework. Sitecore and Bloomreach are somewhere in the middle.

Based on that spectrum, your ideal DXP is a reflection of your comfort level with knowing everything you need about your platform before launch. There are two cases that explain where you fall:

1) The future is largely unknown. For those of us, myself included, who readily acknowledge that there is a tremendous amount we don’t know before a new platform launches, more open DXPs are going to resonate more.  Instead of presenting a suite of tightly-coupled components from one vendor,  more open DXPs offer a platform that allows you to integrate the best-fit tools you need for each category, whether that means they come from one vendor, two vendors, or 20. This kind of architecture is hugely helpful when you know that once the platform goes live, at least one of your assumptions will be comically wrong and the only way to fix that will be to swap out one of the tools that make up your DXP. In an open platform, this will be far easier.

2) I know exactly what we need, now and later. Alternatively, if your confidence level is high in knowing all of your needs and challenges before the platform goes live, a closed platform is going to be more compelling, as it offers a set of tightly0coupled tools with baked in assumptions that are ready for immediate use.

The future is largely unknowable, but conversely, organizations of sufficient size tend not to change. If a marketing leader understands their organization and overall business strategy, it may be very clear that the future is known, at least in regards to the digital needs of an organization. In these cases, a closed DXP will not have many drawbacks. 

But for many organizations that derive demand generation or direct sales from their sites, experimentation and shifting strategies are commonplace. How can these marketing teams possibly know exactly what they need? Even if they did, how could this same stack be relevant in two or three years? In these situations, a closed DXP is going to be problematic, expensive, and reduce the ability for teams to adapt to new internal and external market realities.

We side with Field Marshal Helmuth Karl Bernhard Graf von Moltke on the idea that, “No battle plan ever survives contact with the enemy.” That’s why we always side with open DXPs rather than closed.

When was the last time your payroll system innovated? 

The U.S. government passed a law in 1996 to mandate that every federal employee should have the option to be paid by direct deposit by 1999. The last great innovation in payroll systems arrived more than twenty years ago. Since then, there has been essentially no innovation in payroll systems, because there wasn’t any innovation needed.

The same cannot be said for digital marketing. Railroads have been a crucial component of the U.S. economy for more than 150 years, but most of the rail miles that exist today in the US were built in just a two-decade period more than a century ago, from 1870 to 1890. What the loaded marketing term “digital transformation” gets right is that, like railroads, we are in the middle of perhaps a 20year digitization of a large portion of the U.S. economy. As we have all experienced and are well aware, there are frequent innovations improving how people engage, consume, and purchase online, and the pace of innovation is unlikely to slow.

When this pace slows, the considerations for a DXP will change considerably, but in the meantime, it is crucial to leverage a platform that can accommodate the inevitable innovation that will continue to occur.