Is an out of the box CMS a viable option for your business?

So, what does out of the box technology actually mean? How do you assess your needs? And what are the pros and cons of out of the box technology? Here, I will answer these questions and help you identify the factors – based on your end-product goals – that should ultimately steer your decision.

The following chapter is excerpted from my book, "Things You Should Know: 25 Lessons I’ve Learned About Selecting Content Technology and Services". Download the full version of the book.

Lesson #21: The lure of “out-of-the-box” functionality is usually misplaced and illusory

“Out of the box” (OOTB) is the marketing phrase I probably dislike the most. These are things a system supposedly does with no development or configuration, as in “How much does the system do out of the box?”

OOTB isn’t inherently bad, it’s just misunderstood and frequently misrepresented. If a vendor is honest about their product’s capabilities, and customers know and understand what they’re getting (and, more importantly, what they’re not getting), then some OOTB functionality can be positive. But, sadly, that’s rare on both counts.

Having a lot of OOTB functionality is invariably marketed as a good thing. If a system does a lot “out of the box,” then that’s great, and supposedly the sign of a competent system. If the system arrives “unassembled” and has to be developed, then this is a sign of a bad system, like when you’re having to assemble toys until the wee hours of Christmas morning.

I was initially tempted to say the phrase is dishonest, but it might not be – the software being advertised might actually do a bunch of stuff “out of the box.” Everything does something out of the box, the question is really one of quality and applicability. Is the OOTB functionality that’s offered any good, and does it apply to what you want to do?

Is out of the box CMS functionality applicable to your situation?

The truth: What a CMS does OOTB is probably not specifically applicable to your situation. It’s usually very general, and there’s only a slim chance it works the way you want it to work. A system can’t be instantly good at everything. So it’s either poor at a wide range of functionality, mediocre at a smaller range, or actually good at a narrow range. 

I’m reminded of the Danish physicist Niels Bohr, who said: “An expert is a person who has made all the mistakes that can be made in a very narrow field.” To be really skilled at something, you have to narrow your field dramatically.

Why is out of the box CMS functionaly popular? 

A lot of allure of OOTB is for customers who had a bad experience with whomever was integrating their website, be it their internal team, or an external integrator. This was often manifested in long delays between request and delivery, and therefore the customer mindset is that the end user should be able to do everything without having any external help – we just push some buttons and everything works...

...until it doesn’t.

Out of the box features only adress "patterns"

Beyond very basic websites, I’ve never seen the OOTB story end well. As mainstream as your use case is, I promise there’s something that will be different than whatever was “in the box.” 

Pre-built features can only address “patterns.” These are common usage scenarios that the vendor can predict in advance, and develop pre-built solutions for. The value of this depends on the strength of the usage pattern – is it something that everyone using this genre of software wants to do, all the time? 

For some types of software, this might be true. Consider accounting software – there are a lot of patterns baked into accounting that are true throughout that industry. The patterns in accounting are so strong they’re built into a set of guidelines that students learn in college called the Generally Accepted Accounting Practices (GAAP), and sometimes they’re even legally enforced by organizations like the Federal Accounting Standards Advisory Board (FASAB). Large swaths of accounting practice are factual, non-debatable, and enforceable.

Strong usage patterns are rare in digital marketing

There is absolutely no equivalent for GAAP or FASAB in digital marketing. A “best practice” in digital marketing is a glorified opinion, perhaps qualified by “this worked for me.” 

Occasionally, you see strong patterns in certain applications of CMS. Intranets, for example – employees interacting with company data fall into common usage scenarios (searching an employee directory for a phone number, for example). The “intranet-in-a-box” market is quite strong because the usage patterns in that space are relatively well-known. They’re narrow and deep.

When considering a mainstream CMS – which is a generalized framework for managing an open-ended repository of any kind of information with the intention to deliver it through myriad channels to a wide variety of audiences – the patterns are much weaker. Every client wants to do something a little bit differently, because they think their customers are going to interact with their particular organization and information in unique ways. The usage patterns are broad and shallow.

The Last 10% Trap

You’ll usually always have to modify the system to an extent that requires a technical resource – hence our usage of the word “integrate.” And systems that have gone out of their way to build a lot of OOTB functionality will usually have many built-in paradigms and methodologies that differ from how you want the system to work, or how your developer thinks it should work. Working around how a vendor built an OOTB feature always takes more time and is less functional or stable than if the vendor just provided the tools for a developer to fine-tune it from code to start with.

This is called “The Last 10% Trap.” The first 90% of functionality is handled OOTB, but trying to get that last 10% of what you want ends up taking twice as long as that first 90%, because you’re working with things that weren’t designed to change. But by that point, you’re in too far to back out – you’re trapped.

A mobile home is a way to get shelter quickly, but when you need to add two bedrooms, well, good luck with that. You either live with the limitation, modify it foundationally so it doesn’t much resemble what you started with¹, or throw the entire thing out and start with something built in a more foundational, expandable way.

"It's just the way the software works"

Every feature decision is based on the opinions of the developer who designed it. Systems that can only work as-designed are said to be “highly opinionated.” These opinions can be rigid, and you might not agree with all of them, but they enforce their opinions, whether you agree or not.

Unless you’re totally on-board with the opinions of the feature, the tail is going to wag the dog. You’re going to compromise your requirements because “that’s the way the software works” and it’s just too hard to change.

A balance between OOTB and custom developed features

There’s a balance, of course, and I’m not advocating that you develop everything from scratch. Competent systems, however, have common-sense boundaries around what has to be built from scratch, what can be configured from code, what can be configured from the interface, and what they claim “just works” OOTB.

When you remodel your house, you can move furniture around and paint, and maybe knock down an interior wall or two. At some point, you will run up against a load-bearing wall that holds the roof up. You can’t knock this down yourself, and you’ll have to call a contractor to perform a more complicated building project.

Different CMS systems have different numbers and placements of the load-bearing walls. You need to find out where these are. If a system claims it has none and you can “gut the entire house” if you want, be skeptical.

A decade ago, a particular CMS advertised itself as having a library of pre-built components, and all you had to do was “drag them out on the page.” In reality, the widgets were horribly designed, generated terrible HTML, and could not be changed – all the HTML code was compiled directly into them. I did 25+ implementations with this system, and never used the OOTB components even one time. I spent most of my time – and my client’s budget – working around the limitations these components imposed.²

Should you choose an out of the box CMS?

If you’re still convinced you want a system that’s promoted as having everything OOTB, then know you’re agreeing to this statement:

I completely trust the opinions of whomever designed and built this feature, and I swear I will use it only in the way it was intended and mercilessly suppress any desire to ever customize beyond the specific options they have built into it. I promise to be happy with what I got.

Put another way: What is driving the final product you are launching – your vision, or the features in the CMS? If the latter, then sure, buy something that works only one way and let it define what you release. But if you have a specific plan you want to execute to arrive at a specific final product, then you need a framework on which you can build.

^{1. A friend once explained this by saying they could technically win the Indy 500 by modifying a 1973 Ford Pinto. But by the time they were done, their Ford Pinto would look and function exactly like an Indy car. Also, there wouldn’t be any single part of the Pinto left remaining.} 

^{2. I went to this company’s annual customer conference once. Every session seemed to be a lesson in how to rewrite massive sections of the CMS to do what you really wanted to do, to the point where the original CMS was almost unrecognizable.}