What are the challenges of non-technical marketers using headless CMS and are there potential disadvantages to the headless API approach?

Let me answer this directly, and then I'll do a more indirect answer as well.

Directly, the biggest trade-off is that, for CMSs that were built as API-first and aren't focused on non-developer use cases, you lose some things that you might be used to if you're, say, a WordPress developer. You don't get instant previews, you don't get some of these more “table stakes” things for CMSs that a marketer would be looking for. They'll be like, “Where is my ability to look at this before I publish it? Where is my ability to share this with somebody to get feedback?” Those sorts of things do exist, and they can always be built, but with certain tools, you find yourself having to implement your own.

Now the more roundabout answer here is that I think what we saw in a pre-Jamstack world was a constant tension between the marketing team and the development team. Depending on who was higher up in the food chain that made the decisions, you would see a tool get optimized for whichever team they aligned most with. So if the CMO was making the decision and they came from a content marketing background, you're going to see somebody in Sitecore or in Adobe Experience Manager -- one of these really CMS-focused things, but when the developers get into it, they're just sad. They're frustrated all the time. They have a hard time working with it. There's a lot of hoops to jump through. Then vice versa, you would see companies that say, “Well, we're run by developers, so we're going to build a developer experience,” and the marketers get thrown into GitHub repos and into working with APIs directly. You've got marketers trying to write SQL queries to pull things that they need, and it's like, “This is maybe not the best way to solve this problem.”

What I like about the Jamstack approach is that we're making it less of that trade. You can go use WordPress as your headless CMS, so the developers get an API-based “do whatever you want, build the way you want to build,” but the marketers still get that really good WordPress admin situation. You get to pick and choose your tools to best match what you're doing.

You also lose this other trade-off that I think is really frustrating for people, where you've got WordPress, which is a really good CMS, and you've got Shopify, which is really good for ecommerce, but you don't really want to use Shopify's blogging tools and you don't really want to use WordPress's ecommerce tools, because they're both kind of bolted on to the main core feature. In a headless world, you can just combine the two. You have a store page that pulls from Shopify APIs, you have a blog page that pulls from WordPress, and everybody's happy. Everybody gets that really good admin experience on the CMS side for both Shopify and WordPress, and the developers get APIs with data, and they get to build with whatever frontend in a really consistent and predictable way, despite pulling from two completely different systems. I think that's really beneficial and helpful.