Web Content Management

Maslow’s Hierarchy of (CMS) needs

A lot of people are familiar with the concept of Maslow’s Hierarchy of Needs:

In a nutshell, it means that in general, basic needs must be met first before moving to higher needs. But the concept can also relate to a Content Management selection and practice within an organization.

Basic needs: This can be thought of as the IT function in CMS buying/implementing. There must be a solid understanding of security and performance of the system. If these needs are not met, you can’t move to the next level of actually addressing the business need.

Psychological needs: This can be thought of as the business or marketing function in CMS selection. It relates to the concepts of actually using the software. Does it perform the function assigned? Is it easy to use? Do I enjoy using it?

Pretty much every CMS vendor understands that dichotomy of continually needing to meet both those marketing or IT needs separately in function (and marketing material).

What is less understood is this idea of self-fulfillment needs. I would consider this to be the C-suite. What this means is that once the basic functions of security, performance, etc. are met, and the marketing functions of usability are met, an organization starts looking at meeting strategic functions. This means software that is capable of not just solving the task at hand (i.e. your website in this example), but also some capability of addressing the big topical issues;

  • Breaking down information and cultural silos
  • “Content Intelligence”
  • Content supply-chain / Content lifecycle

And while I classify this third function as being a “C-suite” in terms of the fact that it crosses departmental silos by definition, in practice the actual implementation is carried out by people who are classified in various ways as enterprise architects, CIOs, or information architects. It’s this latter group of practitioners that I want to focus on.

I was originally going to write an article on identifying Information Architecture as the “third (and largely unsung) CMS persona”. This came about from my time at Sitecore looking at VOCalis surveys and doing a lot of follow-up of our best implementation partners (with the amazing Bill McCulloch). One of the things we discovered is that customers who were happy with the partner had an outsized effect on their perception of the effectiveness of the software – in other words, if customers had achieved “self-fulfillment”, they would rate the software highly. The second key learning was confirmation that one of the key differentiators of Sitecore (as understood by these consistently uber-successful partners) was the ability to model complex concepts within their CMS, and do some very interesting things such as the ability to build intelligence (or rules) in relating content items to each other and within the tree hierarchy, and larger content supply-chain requirements, which often enabled their clients to move beyond mere Web Content Management.

We discovered that the better partners understood this value from an early point in time and were able to grasp that advanced functionality in information architecture and content modelling enabled them to build some very “self-actualized” functions for their clients. In other words, it wasn’t just the quality of the code in the implementation, but the “philosophy” of it as well – namely, was the combined project and product meeting the “self-actualized” needs of the organization?

Headless Content Management systems like Contentful and Contentstack specifically call out content modelling as one of the key concepts. An analyst I know and respect once joked: “If Contentful and Sitecore are in the same room, someone is in the wrong room” meaning that they don’t really hold a lot of architectural and product similarity, so it would be strange to see a company evaluating them side-by-side. Now that I’m on the outside, where I can freely experiment with other systems and have extensive conversations on the state of the industry with vendor leadership, partners, and clients (with none of my questions or responses are being seen through the “Sitecore lens”) my view has changed completely:

I now see both Sitecore and the likes of headless systems being capable of helping organizations reach that C-suite “self-actualized” tier, but in very different (and somewhat opposite) ways.

I still see Sitecore as having an amazingly capable product – to this day, the possibilities for structuring and re-using content still outstrip headless vendors. This includes things like;

  • Complex rules for creating content in a hierarchy (i.e. content must follow Product > Feature hierarchy, no more than 3 subitems on this node, etc.)
  • Hybrid models for sharing (i.e. you can have different sites in a tree that can consume content from each other “as native”) including the ability to do complex URL rewriting (i.e. if you link from one site to the other, automatically change your URL context)
  • Ingestion of content in (literally) various ways
  • Cloning of content (with notifications)
  • Structuring content
    • (Optional) Content Trees are useful (so says Deane Barker and I still agree)
    • Ability to pre-populate fields based on context
    • Ability to provide complex rules in reference-type fields
  • Very granular permissions for any multi-channel re-use (which can also be applied to search)
  • Proxies, snippets, tokens, etc. – this document on Reusing and Sharing has a good overview.

But unfortunately, most these are features which have existed for almost a decade within the product (that document above is more than 6 years old and has not been updated) and the current leadership within Sitecore doesn’t fully understand these are really the differentiating features of the platform to reach that upper-tier (even if the Platinum-tier partner base largely still does) especially as the product has moved from what was a lightweight and flexible “framework” and “building block set” to what is now a larger and more expensive product suite (aimed almost exclusively at marketers).

Headless vendors are in the opposite situation, their leadership teams fully understand the value of structured content and information architecture (especially as a way to get into the C-suite) but are working to build up on the product side (while being careful not to move away from being a useful, infinitely extendable, “building block set”). They are working towards making content and content supply chain functions key parts of any “self-actualized” organization. Which means not just web content, but actively working to have universal standards for sharing and collaborating across the enterprise.

If we want to see where these worlds are starting to collide, take a look at this presentation by John King at ThoughtWorks to see how they are using Contentful at BMW. This is the type of high-level transformational project which you would have seen as being the ideal Sitecore customer in the past, including many of the same requirements around multi-lingual, pipeline processes and consuming/acting from external data sources.

And while Sitecore is aimed at marketers, headless vendors started with IT/development and have somehow managed to leap above marketing to be interfacing and selling directly towards the C-suite – in other words, both approaches can address the entire pyramid, but have different approaches to how they do so, both in terms of product and go-to-market.

Moral of the story:

  • As per my earlier notes: Market messiness will continue. System integration partners will have to start providing “strategic/philosophical” advice, rather than just architectural and implementation services (as mentioned, many great partners already do so). I’m going through a similar evaluation where both headless and “traditional” WCM systems are in the mix and comparing apples and oranges is not at all easy and many folks are just starting to build up this skillset (hint to developers: Information architecture is transferable and a great starting point!)
  • Headless and traditional vendors will be seeing more of each other in RFP processes (despite the apples and oranges problem above) – vendors will probably have to move from merely answering the RFP checklist to getting to the core of what the client is trying to solve and providing a better story about why their product is the best platform and philosophy to solve it. Similarly, clients need to think more holistically about the nature of their needs to accurately weigh the options and advantages/disadvantages to either approach and probably look at doing some detailed Proof-of-Concept work to move beyond feature checklist and truly internalize the differences in approaches.
  • Content will continue to become more mission-critical to the organization and will continue to get more buy-in at higher levels. This is one area that I’m happy to say we got right – acquiring Stylelabs and their Content Hub product allowed something of a re-discovery of many of the things Sitecore was already doing well (strong content modelling, tooling around content lifecycle), but with new and added functionality around Content Marketing Platforms and SaaS delivery.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.