October 2020 Digital Governance (DG) Release | Watch on Demand

Hi, I am Darren Guarnaccia. I am the Chief Product Officer here at Crownpeak

I am Paul Taylor, VP of solution engineering

So Crownpeak has been around for almost 20 years and we are one of the only CMS vendors that started and was born in the SaaS world. What does that mean? The ability to actually manage all of your web experiences, privacy experiences and really the quality of those experiences all without ever having to do an upgrade in your life.

Back in 2001 we realized that marketing teams and IT teams didn't want to own all this hardware. 

We thought that by making this simple that anyone can do this and really build and deploy these solutions, we can actually accelerate how quickly people get to market. And over the years we have been working with some of the biggest brands on the planet to really allow them to do that. 

And I think again with this uncertainty around where the market is going, especially when you introduce the Internet of things, having something that just allows you to deliver dynamic content into those experiences regardless of the channel is giving development teams, and ultimately marketers, the flexibility they need to embrace this challenge.

We can't as marketers just choose to deliver a digital experience via web or via mobile. We really have to consider how is a customer or consumer going to use this content and what channel does it make the most sense to them? 

But either way, I am communicating with that single brand and you need to be able to deliver content in a headless way in order to service the same content from one platform into all of those different experiences in a consistent manner which, as a consumer, makes me loyal to that brand even more.

I was asking earlier about why we got here and this idea that maybe this was a part of the frustration that developers had with some of their legacy systems. So how is this whole headless movement helping that? How is it helping developers?

I think it's giving them their flexibility back. You used to have platforms that were quite structured and quite rigid and when you were trying to deliver content across those, it wasn't giving the developers the flexibility that they needed.So I think the movement of delivering content in a headless way gives that flexibility back to the developer and they're now free to choose how they want their content to be presented and by which channel they then want to be able to deliver that.

That sounds good. Is there a downside to that? Are we giving up anything?

The downside of course is when everything is delivered headlessly, everything becomes a software development lifecycle task. So while changing the content is very, very simple, because content is now being delivered by API, if I want to change the presentation or insert a banner where a banner wasn't before or maybe have a drop-down appear in front of my experience, that has to get in the queue behind every other piece of development that that development team is building and testing. And of course, the marketers can't wait for that to be finished. They have to react multiple times a day to changing market conditions. And so this backlog gets longer and longer and longer which ultimately impacts on their ability to communicate with their customers.

So what are our options? How do we find this balance between what the developer needs and what the marketer needs? There has to be a middle ground here, isn't there?

Yeah, I think so. I think you take the best of both worlds. You take the best of the platforms when they used to deliver static content, 

And then take all of the best-of-breed stuff you have around headless where you are now delivering content dynamically. And in that middle ground lives the ideal solution that is going to keep that marketer agile.

Could you consider that Headless 2.0 is that where we are evolving?

I think so, yeah. I think we have many platforms now delivering headless and answering the problem space for the developer. I don't think any are correctly addressing the marketer's need right now and certainly not doing that without creating more challenges for the developer. And so I think that's a great way to position it.

Let's say that headless 2.0, if we were to define it, you'd say that the developers can still build things using the frameworks they love, but marketers would regain their ability to actually structure some UI elements, maybe within some boundaries. They'd be able to preview their content, they'd be able to even edit their content in the context of how it's ultimately going to be delivered.

That's right.

But not necessarily interfering with how a developer would work?

Exactly right. I think right now in the world of headless 1.0, you have content authors who can manage the text that appears in a certain set of data and you have the developers who manage the presentation and the business logic. And I think there is a way to split that up differently in a headless 2.0 approach where both sets of the organization win. You now have the developers who are able to create how the presentation looks and how the logic fires, but then you don't only give the content itself back to the marketer, you then give the use and reuse of that again. So now the marketers have the ability to perhaps drag on content blocks into a page and then consume the content that they want and move those around inside the experience. But the developers still maintain actually what happens inside that component and ultimately that page-based experience.

A couple of other things I think we can take from the CMS playbook too that needs to be brought to the headless world are things like multilanguage. The idea that you are going to have these experiences in many languages across many cultures, and actually the idea that I want this content to be the same content that propagates across many places, the idea of content relationships and that this thing is connected to that thing. So, again, as a marketer I can manifest those things and then, when I change it once it ripples across many places. 

I think so, yeah. As experiences are being managed across more diverse cultures and globalizations across the world and countries, you have to be able to deliver that content in a way that is optimized to get to those users. Not just translation, but localization as well. And how do you communicate to different markets in a way that is sales centric which is ultimately what a marketer is trying to do. Having the platform that enables you to create those relationships between those content fragments, while still delivering that headless content behind where it matters does give you an advantage as a marketer.

And I think if you look at what the future holds in a headless 2.0 world, rather than working on how to shift the content around a page, they are now just focusing purely on what other capabilities does my organization need that is totally reusable to then help extend their message. 

We've also talked about customer experience. Part of customer experience is this idea of optimizing. Testing, learning, personalization. How does all of that technology fit into this headless world? 

I think if you look at how we deliver content in a headless 2.0 world, and again maintaining that flexibility for your authors to deliver content and your developers to deliver functionality, that then gives us a greater ability to consume content from other third-party services. So personalization services, CDP platforms, commerce tools. Delivering that content asynchronously at the edge via data-driven services that have been configured by the development team means that the marketers are going to be able to deliver those experiences. More importantly they're going to be able to preview and have version control and all of that as those experiences, but will also then be able to consume that content as well as those experiences they deliver to their customer.

Boil this all down. Why are we doing headless at all? It is all about speed and agility. It is all about moving fast, iterating quickly, getting value incrementally. And that is what we have to solve for at the end of the day. And I think headless 2.0 gets us there even faster, but headless 1.0 is really why we started that in the first place. Marketing teams and development teams wanting to go faster, tired of being frustrated by their old CMS tools and technologies. And so that is the problem that we all need to solve. How do we help our customers go faster?