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

By Deane Barker on February 21, 2013

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?

Gadgetopia
What Links Here

Comments

  1. The shift towards more effective targeting, personalization, and engagement tools is definitely happening, but I’m not sure a dev-to-stakeholder power transition is at the heart of it. In healthy organizations, implementation teams have always been servants to core business goals.

    Young technologies hit the world with big dreams and (comparatively) meager capabilities. IT teams, either the vendor’s or the client’s, are needed to bridge that gap and most projects have to make do with the work-arounds and patchwork fixes you describe.

    The problem is that those work-arounds and jury-rigged solutions impose real cost on the organization. Developers and PMs — the implementation folks — spend time and money to work around functional shortcomings and maintain those workarounds over time. If a feature is actually needed, it’s because it reduces the resources needed to implement or maintain a solution. If features didn’t matter at all we’d still be hammering out static, hand-written HTML files and using one-off CGI scripts to drive our interactive sites. Those oldschool tools, after all, are capable of delivering just as complex of WEM functionality as the hottest new platforms, given sufficient manpower and determination.

    What we are seeing is an increasingly higher floor of baseline functionality as product categories mature. Just half a decade ago, a Web CMS’s ability to handle UGC efficiently was a huge differentiator that high-level stakeholders and caused buzz in pitch sessions. UGC hasn’t become less useful in the years since then, but it has become mainstream. Today, CMSs that focus on it as a selling point feel as dated as car manufacturers bragging about a car’s automatic transmission.

    Since stakeholders understand that those capabilities are assumed to exist, they want to know what else differentiates a given platform, product, vendor, or service. They look for other business pain points that need solving, and ask what can be done to to help. The kind of conversion-driven tools you’re describing are definitely one of the forms that differentiation can take, but I think it’s a sign of ecosystem maturity rather than shifting power.

    I suspect we might be saying the same thing in different ways: if this comment gets any longer, I’ll just have to invite you to another podcast to hash it out. ;-)

  2. I think you’re referencing a specific example of a broader social change towards what’s broadly “data science”. Data-based decision making in business seems like a redundant phrase (“of course we use data in our decision making”), but I’d argue that it’s a relatively recent development to base everyday business decisions on results of data (as you do in, say, A/B testing).

    As data and data processing have become more widely available (and easier), it has become harder to justify arbitrary business priorities (I want that text to be red because red is my favorite color), and easier to justify goal-directed ones (that text should be green because it resulted in 75% more sales).

    So I think you’re right that the next generation of CMSes need to be “conversion-minded”. There’s a risk in over-focusing on the income side of the equation, however. Web sites still cost a lot (in terms of percentage of annual revenue) for many kinds of businesses. In those cases, a change that makes developers 60% more efficient in building the site may have a bigger impact than any “income side” change. If you’re building a site with lots of repeating-field problems, the CEO-apparent impact is much more immediate.

  3. What you’re saying is true, up to a point. The problem is, as Jeff notes, it ignores or trivializes the connection between developer capabilities and conversion. It’s isomorphic to the idea that “clean code” doesn’t matter, only user experience matters. That’s true to an extent, except inso far as cleaner code makes building a good user experience easier (and crappy crufty code makes it more difficult).

    I don’t hire a contractor to bring a saw, I hire him to create a hole in the wall. However, if that contractor has a power saw he can give me a much more precise hole much faster than someone with a handsaw. To ignore “how the hole gets made” entirely is to short-change yourself, and end up with crappier holes.

    A marketer may only care about A/B testing, but in order to A/B test a given design element you need to have some way to define the different versions of a design element, control what is different/the same between them, and then swap them out in a way that doesn’t destroy performance. A CMS that offers A/B testing through, say, a per-request regex on the markup may get a faster time-to-demo, but they’re going to end up with a site whose performance suffers severely (due to broken caching) every time you try to test something and setting up a new A/B test requires a $200/hour engineer. That’s rarely a good trade-off in the long run.

    In short, yes, results are what matters. But if you focus only on results, and ignore the tools that get you those results, you’ll still end up with pretty crappy results in the long run.

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.