How I Pitch Headless CMS to My Clients
this article originally appeared on Nordic APIs, the world’s largest community of API practitioners and enthusiasts.
Introduction
Throughout the years I have spent a lot of time conversing with CTOs, CIOs, CMOs, and Directors, helping them understand the choices that they have with implementing their next major web initiative or rebranding. They often come to the table with questions on how to best build their website in an efficient and cost-effective way, maximizing their ROI.
The question of which platform, technology stack, or type of CMS to work with, is usually one of the top questions that I get asked. It is never an easy one to answer. I’d argue that in 2021, the decision on which platform to stay in or move to, for that next digital project, is harder than ever to decide. There are many valid options. Do you go with the traditional CMS that the organization has been in for years (and maybe struggling with)? Do you go with a new CMS (the grass is always greener, right)? Or is it time for something truly different, as the idea of Content-as-a-Service powered by a headless CMS is becoming more and more popular, especially in enterprise sized organizations.
This is usually how the conversations starts:
"We are not sure if a headless CMS is the right fit for us versus a traditional CMS, how do we decide?" - CMO
This question is very common. I thought I would share my thoughts on this situation and how I help my clients choose between traditional CMS and headless CMS. This is basically the methodology I use for pitching headless CMS to my clients, which I thought could be equally helpful for others pitching, or those being pitched to!
Helping to Choose between Traditional CMS vs Headless CMS
Below I am going to detail out the methodology that I use when entering a CMS selection process. While it is not exactly rocket science, I do believe it is important to cover these primary steps.
1. Listen to the Client First
It would be an easy way out to go into a conversation with a favorite CMS solution in mind. I would try not to have a preconceived notion of what is the best for the client before listening to them first hand. Even if you have received an RFP stating one specific solution is the best fit, I still would prefer to have the client give the background / context of why they feel that way. Let them explain their needs and describe the new project as detailed as they can.
It’s important to hear that need in the client’s own voice. You can pick up gems of information that an introduction email and/or RFP might not have included. For example, I was recently in a CMS selection process with a large enterprise organization, and I heard this:
“I want my team out of the business of maintaining and upgrading a CMS platform. I need them adding value to the application and ultimately the organization itself.” – CTO
That’s a pretty important talking point that wasn’t in the initial introduction email. That comment shows that this scenario should take immediate consideration into reducing the amount of time, resources, and cost around running and maintaining infrastructure and servers that a traditional CMS might require. Hearing this statement was a "tip". I now had a pro for a SaaS based solution (hello headless CMS).
Listening to the whole story, noting the details, and adding those details to the RFP or original request can be quite helpful.
2. Get a Lay of the Land
If the project involves a migration from a legacy version of the application or platform, you have a chance to review what is working and what isn’t. I always try to get some sort of walkthrough of the existing application as a way to compare what the application currently does versus how the new world needs to function for that application.
In fact, one of my clients called me out a few weeks back on loving the terms “old world” and “new world” and how I use them in pre-sales or discovery conversations. It made me smile, because she was totally correct, I do use those terms often.
I think that saying “old world” helps to frame the conversation when you are reviewing a content model, screen layout, or third-party integration requirement. It also starts setting up how things could be different in a “new world”. Getting the lay of the land can help you catalog what features are most important. It can also give you the reverse, what is just a “nice to have”. While learning the lay of the land I’m also looking for pain points that editors have with publishing content or that developers have with making certain functionality work correctly.
Knowing that this project needs say real-time information from a PIM or DAM as a priority requirement may allow you to scope out if the CMS media/asset library is robust enough to cover that need, or not. Or knowing that a requirement like the site having content available in different global regions and where that content is fully translatable into 3 or 4 cultures, might clue you into looking for a CMS that has ways to group content and a default language fallback which makes it easy to manage such content.
Walking in the client’s shoes for even just an hour is hugely insightful.
3. Describe the Benefits of Both Options
Once, you’ve listened and got up to speed on the project it becomes time to map the client needs to what the CMS platforms can do best. I think it is easy to start here (mapping the top benefits to the direct largest needs) because this is basically the low hanging fruit.
For instance, if the project is to build a B2B commerce site, then a traditional CMS is typically going to have some advantages. Things like user/customer management, e-commerce abilities (checkout, shopping cart, payment gateways), and email marketing (abandoned shopping cart processes) could all be “in the box”. It could be nice to have one CMS that does all those things well. Even smaller things, like a built-in search engine for the site, is included in about 99% of traditional CMS platforms. There are many good points to bring up about traditional CMS and the value that type of CMS can bring.
With headless though, the benefits are not just about the features of the CMS. The benefits also extend to how you can now deal with the entire project as a whole. It is very freeing to not have to worry about maintenance and infrastructure over time. For instance, another contact I was talking to in a conversation like this mentioned:
"How can we do more with less. I really don’t want to run another CMS upgrade ever again." – Application Development Manager
Since the headless CMS vendor is handling the service availability for you, there is a world where CMS upgrades are a thing of the past. Your team just doesn’t have that responsibility any longer.
I also educate my clients on how the project schedule and project phases can be sped up. Content modeling can take place right away instead of waiting for the traditional CMS to be provisioned, installed, and configured. Content can be created and collaborated on from day one. It’s just a bit different.
Then there are the technical benefits around the freedom of developing a site or application in any technology that the dev team wants. You are not tied to any one single technology stack. As long as your project can consume an API you are good to deliver on any channel you need (web, mobile, smart watch, ad, display board, …).
My goal is to match as much low hanging fruit as possible to see if there is a natural edge to one versus the other.
4. Provide a Comparison Matrix (Headless vs Traditional)
After the low hanging fruit is out of the way (which is the easy part), then it’s time to dive into the next level of comparison. I am a big fan of Pro vs. Con matrixes when it comes to comparing software platforms. I like to summarize the biggest Pros and Cons for each side of a comparison and then dive into the details and document those details (instead of just talk about them in theory).
In fact, I couldn’t resist. I am publishing here a template that can be used to compare different CMS platforms. I have stubbed out the example comparison to look at Kentico Xperience on the traditional CMS side and Kentico Kontent on the headless CMS side. This isn't just another CMS comparison matrix where we are just checking boxes for this feature or that feature. It is intended to compare the "types" of CMSs and different approach - microservices and Content-as-a-Service, versus all-in-one / monolithic traditional CMS platform. Feel free to download it below and let me know what you think about it.
The tool itself is broken up into three main sections. The first being a summary of annual cost (trying to get to the estimated total cost of ownership). The second section is the top-level summary of overall strengths and weaknesses of traditional and headless CMS platforms. Finally, the tool ends with a deep dive into feature-by-feature comparison that is broken up in the categories of:
- Content related features
- Technical related features
- Infrastructure related features
- Security related features
- Digital Marketing related features
- E-commerce related features
- Your Project Specific related features
It adds up to a comparison of over 60 different features and which platform has a strong case for that feature. Also, to be clear, the last section of your project specific related features should always be taken into consideration and added to the list if you want to make it a fair comparison.
I would encourage you to modify the tool to represent your scenario as well. For instance, if you are using a microservice architecture and have a service that handles your PIM needs or your email marketing needs, then delete that section out of the comparison as it shouldn’t count. If you find something that is missing, add it.
5. Be Clear on What Could Go Wrong with Headless CMS
It's not all perfect, no solution is for every scenario. There are common challenges to a headless API first approach that makes developers happy. The challenges tend to come from the marketing / business side of the project team.
Some marketing teams expect and still desire use WYSIWYG text and have an immediate preview capability. Even though many of us wish that WYSIWYG could be killed off forever, I still hear this:
“Why doesn’t my embed html work and I’m still having issues with this thing right here in the CMS and how it goes to that thing [on the design].” – Marketing Director
If you are not used to structured content, then let’s not sugar coat it. There is a learning curve. The WYSIWYG text conversation is best approached by showing the value of a content model and what structured content can allow you to do, which is write and manage content in one spot, and use it everywhere on your site.
The preview point does have a very valid argument. It really brings up that to have preview ability you do need a developer to tie the headless CMS to a presentation layer or “head”. It is fair to say that in headless there is a high dependency on having a development team. You need them for every step of the way most times. Some marketing teams are very savvy in a traditional CMS and can produce quality work without the need for a development team.
Then there is the next challenge, when it comes to the “Wait there’s no out-of-the-box integration for XYZ third-party platform or tool?” point which inevitability comes up. Yes, this is said often in a headless project solutioning session. That is again up to you to provide in a headless world. Good headless CMS have source plugins for static site generators like GatsbyJS, or Statiq in the .NET world, that makes this somewhat easier. But chances are you will be rolling your own integrations and migration tools, which will have an impact on the implementation fee of a project. You may find yourself often reminding the client or dev team that "...remember, there is no A/B testing module, you will need another tool for that".
Basically, to provide a fair comparison you should alert the client to both sides of the story.
6. Paint a Vision of the Future
Once there is clear understanding on the project needs, a comparison has been created, and the winner is starting to become clear, I like to paint the picture of what the future will look like. To do this I create a diagram of the solution and review it with the client to make sure they understand the big puzzle pieces of the system, and how it will ultimately fit together.
The diagram helps show the connections between systems, where integration points are, where failure points could be, and even typically goes into which resources have which costs associated with them. It can also be useful to contrast the “old world” with this “new world” and allow everyone on the team to visually critique the new plan if needed. This is a good way to make sure nothing was forgotten in the new solution. Typically I use free tools like diagrams.net, or lucidchart.com to do the diagraming. Heck I’ve even been known to fire up a quick excel diagram when the situation calls for it. My PMs love that one by the way ;)
And speaking of costs…
7. Review the Costs
The solution that you end up choosing could be the best technical solution in the world with the most ultimate level of performance and scalability. It could be a lean mean content generating and personalization machine. It could include the fanciest of add-ons and the best bells and whistles. But if it costs as much as this year’s NASA budget to get some astronauts to the moon in 2024… then none of the technical ability matters. Budget is always a consideration even when someone says it is not. In fact, it’s often more than just a single number. Another comment I have heard recently:
"I need to be able to calculate my CapEx vs OpEx costs for budgeting purposes." – CTO
Larger organizations have a need to know fine level of details on costs. I know it is quite a bit of work, but breaking apart a project into small chunks and estimating each chunk has been a successful technique for me to show clear and transparent pricing to my clients. There’s no reason to hide any costs in my opinion.
In these breakdowns, I’ve been asked to represent the CapEx vs OpEx amounts. This is a grey area to completely divide up and does depend on the organization. Generally, initial spin up and configuration of the CMS can be broken down into CapEx costs, licensing falls into OpEx, and the main implementation of the site I’ve seen placed in both categories (depending really on how the CFO sees that organizations website as a pure expense or as a tool to generate ROI).
8. Pitch It!
That’s it. Time to pitch it! You have covered the primary steps for building a recommendation. Again these steps mimic my methodology for building a solution for a client. Take all the knowledge you have learned, and hopefully documented, and walk into that pitch meeting knowing that you have more than just a feeling on what the client should do. Also, the steps are not written in stone, skip some, add some, make it your own process. That's all fine.
Common Headless CMS Concerns / Discussion Points
I also thought it was appropriate to state a few common questions, and my responses, that come up in these conversations:
Q: Where Does my Data Live / What about Data Sovereignty?
This does depend on the vendor, but most modern headless CMS options have the ability to give you a choice of where your data resides. They have setup the CMS so that the data is bound to that data center. Kentico Kontent for example has the ability to choose between 3 different global regions for your project data: North America, Europe, and Australia. Any personal data is also handled with GDPR compliance as a nice bonus.
Q: Can I Bring the CMS On-Premise if I Want to?
Short answer here, most of the time no. We have touched on many benefits of a headless SaaS based CMS. There are a few headless CMS out there that you can run on-premise, but at that point, maybe traditional CMS is a better fit if you really want to run it on-premise.
Q: What about Search / How do I Provide Search Results of My Content?
Search is always a fun one. Again, a short answer, Search is on you as the developer / owner of the website. Most headless CMS offerings will not include this out of the box. It is very likely you will be looking into external Search as a Service options like Azure Cognitive Search, Algolia, or ElasticSearch and using your CMS’s API to index the content into those Search services.
However, I do not see this as a downside. These Search services have come a long way and provide excellent search experiences. In fact, even if we have a traditional CMS project these days, we almost always connect it to a Search service like Azure Cognitive Search anyways.
Q: What are the SLAs like?
Most headless CMS come with a Service Level Agreement (SLA). The various pricing tiers might include higher or lower SLA options based on where you buy into the product at. However, most of these are run in Azure, AWS, Fastly, or some other cloud powered CDN. In my experience they are all pretty good. Guaranteed SLAs and options for different infrastructure support with most likely put you into an Enterprise pricing tier though. It is something to keep an eye on for sure when looking at signing up for a subscription to a headless CMS.
Q: What about data for my Store Locator, Mortgage Rate Calculator, or Student Application Form?
These are all examples of tabular data requirements. Honestly this is one not so nice part about headless CMS that define everything as a content type, there really isn’t just a database like with traditional CMS. Therefore, you might need to get creative with pitching solutions that require this type of tabular data. There are options out there like serverless functions to connect to data, external storage of json data, or other APIs from other services that can return to your app what it needs to make that Store Locator show location-based results.
Q: It Seems like a Somewhat Expensive Monthly Subscription Cost?
At first calculation, yes it can seem like an expensive subscription. However, when you add up the alternative traditional CMS costs (hosting, maintenance, patching, upgrading, etc. etc.) with the services and support of the team working on it, the costs start to become pretty compelling. Overall, in my experience, because of the benefits of headless CMS, the development team and marketing team can be able to execute faster than in a traditional CMS sense (again given the right type of conditions) which makes the major work, the implementation, cost less. All of this, including training, services, and support options should be considered at a wholistic view before just thinking of the one number without the full context.
Conclusion
If you are considering the question of traditional CMS vs headless CMS then hopefully this post has helped. If you love the CMS comparison matrix I have created for Kentico Xperience and Kentico Kontent let me know via email or on twitter via @mcbeev.
