After my presentation at the Boye & Co CMS Connect event in Montreal, Akshay Sura of Konabos and I discussed the session including the complexities and challenges in the acquisition and evaluation of Content Management System (CMS) software:
Difficulty in CMS Acquisition (1:16-2:00): Mark highlights that evaluating and acquiring CMS software is surprisingly difficult. This difficulty stems from vendors often selling capabilities that need to be assembled into software by system integrators (SIs) or the clients themselves, rather than selling a ready-to-use product. The majority of the total cost of ownership is related to implementation, not the software itself.
The “20/30/50” Rule (3:26-3:56): A tweet from 2011 is referenced, stating that choosing a CMS is 20% about the system, 30% chemistry, and 50% integration competencies. Mark redefines “chemistry” as “philosophy,” emphasizing that vendors have different approaches to tackling the same problems, which is a crucial aspect for buyers to consider.
Shift from RFP to Proof of Concept/Value (6:20-8:06): There’s a significant change in how vendors allow evaluation. Unlike in 2011, many vendors now offer trial accounts and extensive documentation, enabling buyers to conduct Proof of Concept (POC) or Proof of Value (POV) themselves. It’s recommended to involve prospective vendors in POVs to assess their support and responsiveness, as some vendors are more willing to help build custom solutions than others.
Vendor Size and Responsiveness (9:06-10:17): Buyers need to determine if they prefer a smaller, more responsive vendor capable of greater flexibility, or a larger vendor offering more stability but with potentially less flexibility in product roadmaps and APIs.
Buying Products vs. Ecosystems (10:30-12:21): Buyers must clarify what they are prioritizing: a product, features, enabling capabilities, or a community/ecosystem. Examples like Drupal and WordPress represent buying into a community, while Contentful is more about buying a product and its API performance.
Opaque Enterprise Pricing (12:27-14:50): Enterprise CMS vendors often do not provide fixed prices, as the value a client receives may not correlate with the vendor’s cost. Factors like consumption-based pricing (lack of cost certainty) versus feature-based selling (disconnect between cost and value) make pricing complex. Additionally, the extensive time and effort vendors spend in procurement, legal, and product roadmap discussions to mitigate buyer risk needs to be recouped, leading to opaque pricing structures.
Sustainability of Vendor Relationships (17:17-17:53): It’s important for buyers to ensure their relationship with a vendor is sustainable. If a vendor is not making a profit, it might lead to their demise, forcing the buyer to find a new vendor.
Impact of Gartner/Forrester Quadrant Climb on Pricing (18:41-21:11): Pricing typically increases as a vendor climbs in industry quadrants (Gartner, Forrester). While vendors argue this is due to product improvements, it can lead to customer churn if the new capabilities don’t align with the customer’s evolving needs, especially for those who bought the product when it was smaller and mid-market focused.
Buyer Persona vs. User Persona (30:08-32:26): A significant source of frustration is that the team evaluating and buying the software is often not the team primarily using it. Vendors tend to cater to the buyer persona (e.g., procurement, IT, leadership) who make the purchase, even if the user persona (e.g., content authors, casual contributors) represents a much larger group that uses the software daily.
User Retention and Vendor Responsiveness (33:26-35:04): While the buyer persona drives the initial sale, the user persona drives retention. If users become frustrated over time, it can lead to calls for platform changes and eventually churn. Vendors need to be proactive in catering to casual contributors to prevent this silent attrition.
Monolithic vs. Composable Architectures (36:41-42:20): The industry has shifted towards composable architectures. Many monolithic vendors have broken down their offerings into more modular, API-driven components, and composable vendors are adding more capabilities to become Digital Experience Platforms (DXPs). This shift allows for more flexible front-end development (e.g., React, other JS frameworks) and faster implementations. faster implementations, separating front-end from back-end development. The old criteria of matching organizational skill sets (Java, PHP, .NET) with specific CMS vendors is no longer relevant.
Challenges of Cloud Transition (43:18-44:17): Older monolithic vendors transitioning to cloud-based or SaaS models face challenges with existing customers. These customers often struggle with the need to completely rebuild front-end and refactor back-end customizations, leading some to consider entirely new headless vendors or sticking with on-premise solutions.