Spanning the Gap from Feature to Conversion: Are We Building the Right Bridges?

What’s the ultimate purpose of a CMS in your organization? Is it to manage content? Or is it a tool to drive revenue?

The answer to this necessarily depends on the organization. If your organization is built around content – a museum, for example, or the technical documentation of a product – then the purpose of the CMS is clearly to manage all that stuff.

But for a lot of organizations, the existence of the CMS is almost incidental – it merely exists to help drive conversions, to increase revenue, to impact the bottom line. If it contributes to those goals, then it’s successful. If it doesn’t, then it’s not.

You don’t buy a power drill because you want a drill. What you really want is a hole – the drill just happens to be the most efficient way to get that. Same with a CMS – you don’t want the CMS, rather you want a conversion of some kind. The CMS is just an tool to help you do that.

But, to what extent can a CMS actually drive conversions? Meaning, to what extent can a CMS be the sole difference between a conversion happening on your website or not? To get more granular, what is the effect of one single feature of a CMS on the bottom line of an organization? And are CMS vendors concentrating on the right features?

To break this down, let’s put the people affected by a CMS into some buckets. This is going to be a coarse grouping, but bear with me on it for a minute.

We’ll put them in four groups.

1. First, we have CMS Developers. These are the folks that work with the architecture and templates to make the CMS do what an organization wants it to do.

2. Then, we have CMS Users. These are the editors and content producers that use the CMS to manage content for the organization.

3. Then, we have the CMS Consumers. These are the people that come to your website to consume the content that the CMS manages – these are your customers, subscribers, or the general public.

4. Finally, we have what I’m going to call the CMS Stakeholders. These are the people who benefit from the results that the CMS enables. This is your CEO, CMO, or ultimately your shareholders.

That last group might seem strange to you. But if we concede what every CMS is implemented for some reason, we probably need to trace that reason back to a net benefit to the organization. At the end of the day, a big expense like a CMS has to impact the stated goals of the organization in some manner, and for most organizations, that’s profit.

This means that the CMO is clearly a stakeholder in your CMS implementation. They need to derive some benefit from the fact that you spent umpteen thousand dollars and several months buying and implementing the thing. They are accountable for the results of it, and those results would logically mean impacting revenue and profit.

With these four groups in mind, let’s consider a single feature for a CMS vendor –

Say the people behind CMS X are trying to decide whether or not to include a new content modeling feature – the ability to repeat fields, for instance. So, instead of a single field for “Author,” for example, we can now have multiple fields to gracefully handle situations when we have more than one author. (I can tell you from experience that this would be a fantastic improvement for many systems.)

Let’s look at our four groups and see which ones would benefit from this:

CMS Developers? Absolutely. I can think of so many instances in so many implementations where this would have been extremely helpful. Additionally, as a former developer myself, I just love the idea – being able to repeat fields represents freedom from constraints, reduces the need for code hacks, and makes the data model more pure.

CMS Users? Sure, in some cases. There might be some situations where it would be helpful for me to have this. I might be working around something, and this would remove my need to do that. It could make things easier for me, and while I’m not excited about it on a visceral level or anything, I’m certainly all for it.

CMS Consumers? Um…tougher, but perhaps. If we examine the needs of our audiences, we have probably found places where the ability to repeat fields might result in a better interface and experience. However, knowing implementations like I do, we probably found a workaround to make this happen anyway, even if it would be kludgy from the backend. Perhaps our editors have to do some backflips, but whatever. In the end, the CMS Consumer might benefit incrementally.

CMS Stakeholders? Well, not so much. In the end, there’s probably not much of a benefit here for the CMO, and if there is, it’s pretty far removed.

For evidence of this, let’s define the sequential chain of events that would have to occur for our new feature – the ability to repeat fields – to have an end benefit to the CMO:

1. There would need to be some uncreated aspect of the site which is standing in the way of a conversion.

2. We would have to know about this aspect of the site, meaning we would have to be aware of this deficiency that needs correction.

3. There would have to be no workaround for this (or else we would have likely done it already, kludge be damned).

4. Our new CMS feature would have to allow this missing site aspect to be created in a cost-effective way.

5. This new aspect of the site would now have to be found and used by potential customer.

6. The use of this new aspect of the site would have to be the single thing that pushed the customer over the edge and caused them to convert. Meaning, they would not have converted without this new thing we build with our new CMS feature.

This “chain of causality” may seem contrived, but taken down to the absolute bottom line, it couldn’t be more true. The CMO doesn’t care about technological elegance, content modeling purity, the absence of workarounds, or anything else. A good CMO cares about the bottom line. And if your shiny new CMS feature doesn’t improve the bottom line for the CMO, it’s probably not worth doing.

I will concede there are some other ways to impact the bottom line –

The ability to repeat fields will likely lower implementation costs in the short term, since workarounds cost money.

The ability to repeat fields will also probably result in some happier editors, since they care about elegance too, and they would likely be happier with the end result of their content. I can tell you from experience that a bad CMS can have a devastating effect on morale.

Additionally, it’s not quite fair to look at this one feature in isolation. A CMS is a bundle of features, all working together, and it must be evaluated with regard to their synergistic whole, and their ability to vault that CMS over a tacit “bar of functionality.”

But, the core principle is this: the “distance to benefit” for any one CMS feature is much longer for the CMS Stakeholder than it is for any other group.

A CMS Developer can look at that feature and say, “Hell yeah, let’s upgrade!” because the distance from feature to benefit is very short, from their perspective. A CMS User can also be convinced of the same thing – though probably not quite as quickly because the distance from feature to benefit is a bit further removed.

But the CMS Stakeholder – our CMO – likely doesn’t care about the elegance of the content model. He or she cares about conversions and the bottom line. And the distance between this feature and those goals is much greater. For the CMS Stakeholder, the chain of causality which allows that feature to provide actual, tangible value is long. It can be a real stretch to envision a scenario where all the dominoes line up and fall in such a way that we can say – incontrovertibly – that this new feature of our CMS clearly resulted in an appreciable impact to the operating numbers of the organization.

So, what’s my point?

This “feature disconnect” is where I see clear divergence in the development curves of the commercial and open-source CMS offerings. In the open-source world, you often see features added to systems for their own benefit.

Why are we adding the ability to repeat fields? Because it’s the right thing to do, dammit! Data needs to be pure. Workarounds are bad! Let your neckbeard fly!

In the commercial world, the process of adding features is a little more…mercenary. Why are we adding Feature X? Who wants it? Does that person make the decision? In what way will this encourage that person to buy our product?

In many cases, the answer is no. With a commercial CMS, the buying decision isn’t going to come out IT, but out of marketing. Immediately this has muted the influence of our first audience – CMS developers. The CMS Users may still have some influence here, but if we’re dealing with the marketing group then we’ve vaulted right up to the CMS Stakeholders. They’re not thinking about content modeling, they’re thinking about conversions, and how is our CMS going to help them with that?

Here’s a current trend illustrates this: the rush into marketing automation.

More and more, commercial CMS systems are abandoning traditional notions of content management – content models, permissions, and workflow – and are charging headlong into higher-level marketing features. We’re seeing the lion’s share of development being spent on all the things that happen after someone hits the publish button. The “management” portion of the CMS suite is almost incidental now – it only exists to serve the marketing side.

I’ve given several conference talks about this trend. In researching it, I interviewed the CTOs of many commercial content management companies. To all of them, I made the following statement:

Content management is largely a solved problem. Almost all of the advances in the field are happening in the delivery/marketing space.

All of them agreed that this was true for their product. Here are some of their quotes on it:

Development on our repository is strictly to support our delivery services.

[…] The majority of our development effort is focused outside our core management product.

[…] The focus on the management side is now on strictly reducing implementation costs.

And, perhaps the most incendiary of all:

We build our product 100% for marketers. The idea of a ‘content editor’ is an antiquated notion.

Yet, the open-source world is very slow to embrace this side of the equation. The commercial CMS vendors are falling all over themselves in a mad rush to own this space, while on the open-source side you hear crickets chirping. There may be some module or plug-in development, but contrast this to the commercial side where marketing and post-publish activities are all they care about right now. In the last year, entire product roadmaps have been thrown out and rewritten to accommodate this trend.

You see, commercial content management companies know how their bread gets buttered: they have to sell the product. And the person making the decision to fork over the money is not gonna be impressed with its content modeling capabilities. Overwhelmingly, the decision makers are not in the CMS Developer or CMS User groups. They’re CMS Stakeholders.

Sure, core management capabilities might be part of an aggregate set of capabilities which demonstrate some required proficiency. But that playing field is getting more and more level by the day. Hell, if Drupal or WordPress can do something, then that thing is a commodity, and you can no longer pitch that thing as a feature.

Perhaps the most telling: I sell CMS for a living, and no competent CMS demo these days begins with “Here’s how you edit content…” These days, demos start with “Here’s how you can segment users…” or “Here’s how you can run an A/B test…” If editing a page is the high point of your demo, you have a very big problem.

Why is this so different in the open-source world? I think it’s because decisions in adding features to open-source CMS are driven much closer to the CMS Developer group. Generally speaking, open-source CMS projects are developer-driven, not consumer- or stakeholder-driven. They’re projects that originally sprang forth from a single developer (a marketer does not build a CMS, after all), and that developer-centric vibe has stayed with the project and hasn’t been eradicated by a driving need to sell licenses.

Thus, features are included because they make development easier. These features then to contribute towards things like elegance, orthogonality and modularity, which developers love. Developers see these features as logical and sensible to the task of managing content. Sadly, they’re often not logical and sensible to the task of driving conversions.

So, what’s the purpose of your CMS: is it to manage content, or drive conversions? If you’re a museum, or the Library of Congress, or some other content-driven organization, you might honestly say that managing content is your number one goal. Wonderful.

But for most organizations, the answer is clear: the CMS only helps us inasmuch as it can drive conversions. If a feature cannot help us – directly or indirectly – get a website visitor to convert, then it is not worth doing, technical sophistication be damned.

So, CMS vendors, developers, users, buyers, and everyone else, you need to ask yourselves: this cool feature I’m looking at – what is the chain of causality that bridges this feature with a conversion? How long is that bridge and how easy is it to cross?

And perhaps most importantly: are we building the right bridges?