Including Marketing Teams in Headless Architecture Planning

Sam Brace: [00:00:00] Welcome to MX Matters. This is where we talk about all things related to the visual economy. That could be trends, that could be best practices, use cases and more, and of course, visual economy. All things related to images, videos, the way that these are displayed on the web, mobile and more.

My name is Sam Brace. I am the director of customer education here at Cloudinary. And joined with me for this episode. And actually this is wonderful because she’s back. It’s Maribel, who is our technology partner manager at Cloudinary and it’s a wonderful thing to have her here because she brings so many insights to the ways that partners work with Cloudinary in terms of integrations and the benefits that we can provide between each other.

And of course, she’s an amazing asset for many purposes, even past the partnerships details that she brings to the company. So you are in luck that she is here for this episode as well. So Maribel, thank you for being here again.[00:01:00]

Maribel Mullins: Hello. Hello. Thank you for inviting me. This is so exciting. Thank you, Sam.

Sam Brace: Of course.

Yeah, and, and of course we have a great guest with us too, and that is Elad who happens to be handling developer growth at a company called Stackbit. Now, what’s important to know about Stackbit from my perspective, and actually Maribel, I’d love to get your opinion on this too because your understanding of Stackbit definitely exceeds mine.

But one thing that comes up a lot in conversations about headless architecture and those that have listened to previous episodes know that we have been talking about headless, at least for the past few, is that one thing that happens a lot is you have developers or people that are tied to the engineering side of companies and they’re very excited by this move towards headless architecture.

We can have lots of different ways to compose the architecture we want, which is very API focused in many cases. And of course, developers work with APIs regularly, but what can sometimes happen is the team that has to [00:02:00] ultimately author and deliver a lot of the content on content management systems and other different systems that are focused on external outputs. They sometimes get lost in the area. They don’t see the benefit of the headless architecture or the flows and the processes and the workflows that they used to be able to do suddenly had been all disrupted. And what’s nice about a company like Stackbit is they’re taking over a space called Visual Experience or a visual experience platform that kind of marries the two needs together, where now they can create the process and the workflows that really accommodate the content authors, but also ensure that the developers that want to be working on swappable composable architecture have the ability to do so.

It’s almost acting like there’s this nice middle man that makes everybody feel needed. It’s the mediator in the room. It’s a wonderful thing that these companies can provide. Maribel, have I said it well? Is there anything to add or is there anything I got wrong?

Maribel Mullins: No, that’s absolutely correct.

Yeah, I’m definitely hearing that across the [00:03:00] board. I see marketers want a bigger say on what’s being put out on the webpages and they just don’t wanna fill out a form. They want to be hands in, to give direction and whatnot. So yeah, I think you’ve covered it. Yeah.

Sam Brace: So Elad, let’s have you come in here. So tell me a little bit about yourself. Tell us a little bit about Stackbit, that way we understand all the details before we get into what you guys are helping to solve with this headless conversation.

Elad Rosenheim: Very glad to be here and get this introduction. My title is at Stackbit is Developer Growth. So it’s product and it’s product marketing and documentation and creating examples and thinking about inspiration and how to tell that story and how to relate to content teams and their trouble.

And I’ve been for the last maybe 20 years, like mostly working with R&D, but I would say being more and more open to the challenge of other teams, which is, I think a big part of, you know, what I think about nowadays. And in just a few short sentences, concretely about Stackbit, you [00:04:00] can think about Stackbit as a visual editing or a visual layer over today’s modern decoupled websites, meaning it used to be that you had a monolithic CMS, you had a lot of constraints, but it also had all these tools and all these backend interfaces for the content teams. And now we’re see in this race, like to have a CMS and React and all these frameworks and something it was maybe lost, you might say. And we’re trying to bring back this visual layer, but in a sense also bring other tools which are part of this, like decoupled architecture, so Cloudinary being one, but also search and personalization and a lot of other tools.

Bring them back into something that’s visual and really centered on the agility of the marketer. Nowadays the term is content ops team. I really like this term because it brings together, if you’re doing marketing, doing personalization, you’re doing asset management or creation, it’s all under [00:05:00] content ops.

Sam Brace: I actually really love that. I love the idea of having a content ops team and because in a lot of cases, when you think about like a marketing operations team, they’re focused on not always the content on it. So like I’ve seen marketing ops teams where they’re pulling data on how many people signed up for something or it’s tied to more metrics and reporting and making sure that certain tools are talking to each other, but it’s not always content focused.

It’s about like Salesforce or Zendesk or Gong as a good example of where you see a lot of marketing ops teams being like, make sure we’re analyzing all the data that’s coming through these phone calls. Right. But like, I love the idea of the content ops team that you put out here because with a headless architecture move to your point, there’s lots of things that are tied to content.

Like you have content management systems, you might have a digital asset management system, DAM. There might be PIM systems that are involved with e-commerce aspects of some of that content. So being able to weave them together and make sure, do [00:06:00] they have a single source or a place where they can kind of all live and make sense together, like a Stackbit, I like the idea of having that. It’s an interesting idea that I never even thought about.

Elad Rosenheim: Yeah. All companies want their team to be more data-driven, more insight-driven.

So if you have analytical tools, user journey tools, personalization tools that also bring insights into the system, you want this team to be open, to be driven not just by your own hypothesis, but also by the data. So think about a team that also has access to all these tools and makes better decisions.

Sam Brace: It’s one of those things where if you did have a good content ops team, then situations like what possibly could happen if someone isn’t doing a headless architecture plan properly could happen. What we were saying when we were introducing you is that it could happen where the development team isn’t talking with the marketing team or the content team.

They can create this whole plan like, oh, we’re gonna do this headless architecture. We’re gonna go ahead and blow up the monolith. We’re gonna make everything [00:07:00] microservices and then the marketing team’s like, but I just wanna publish a blog post and you just made that really hard for me to do.

So how do I get around this? That’s where like acting as the middle man helps a lot here. But I think to your point though, if you have a content ops team that can say, Hey, did you consider all of these different stakeholders that are involved in the content authoring or content delivery process?

That can be a great way to help bring in all of the stakeholders for a headless architecture move.

Elad Rosenheim: I’ve been tackling this issue for almost a decade now, a long time before joining Stackbit. I’ve been on the side of talking to a lot of prospects as a vendor and seeing that it’s not that one day developers woke up and decided to really revamp the whole architecture just out of spite or technical curiosity. That’s part of it. But it was driven by the business end of a company or an organization that’s been saying, Hey, the systems are too [00:08:00] limiting, they’re too slow. It’s hard to find people that are willing and knowledgeable enough to maintain them. We need something different. And the engineering organization, which grew, I think, really grew much in importance since a lot of these organizations have said, okay, we have just the tools for the job.

And like gloriously they went into adopting all these tools. And what happens is, like along the way, they built something that is really like healing technologically, but kinda they kind of forgot to bring… you know, when you build a React website, for example, it doesn’t come with this backend interface.

It doesn’t come with all the considerations about, Hey, what’s the content editor experience of it? So developers, you know, it began with a business need, and then things evolved on their own, I might say. And you get this like wonderful technical architectures, but a lot of the experience, which is the [00:09:00] point of the whole exercise was kind of lost.

And this is something that I’ve seen for a decade. As I’ve said, like part of the reason I joined Stackbit about a year and a half ago was that I really emphasized with pain and I thought, Hey, this is a problem that is worth solving. It’s worth money. You know, in the end, to an organization that sometimes harder to quantify, sometimes it’s easier to quantify, but there is a pain here. That’s actually why I joined.

Sam Brace: I think one thing that you’re saying that I’ve definitely experienced as well is that when you’re trying to make these business plans and you’re saying like, we need something that’s new, we wanna make sure that we’re cutting edge. Maybe we’re trying to gain more profits or become where we’re bringing more revenue, whatever the reasons are for change, sometimes it’s easy to chase the buzzword or the shiny object. And what I think is interesting, because we’ve probably seen different shiny objects over time. Like, I remember if I think back to 10 years ago, everybody was saying to me, we need a responsive website. [00:10:00] I’m like, do you know what that means? And they’re like, we don’t know what that means. Now of course, responsive websites are defacto, everybody has a responsive website.

But there was a period of time where there was a desktop site and there was a mobile site, right? And so you had all these different things, but to me, 2022 has shown headless in some situations is a buzzword, it’s a word that not everybody fully understands. They’re like “We wanna go headless!” And we’re like, do you know why?

And there’s not a lot of detail to it. I like what you guys are doing because you’re showing, okay, you can, but it allows for people to still get what they want out of it, where it hits the business needs, but it also doesn’t hit an area where we bought this thing and it’s not manageable, or it was just a shiny object without any value to it. So it’s like you’re adding a lot of value to the move or the need for headless architecture, which I think is a really big thing for. But to my point also, marketing teams shouldn’t just go down a headless hole and be like, oh, we [00:11:00] wanna go headless and they don’t do the research in time to put themselves into that project too.

Elad Rosenheim: Even before we dive even further into what the challenges are, how can we start to address them, even from like the purely business perspective, if you are a vendor, so, you know, we’re both working for a SaaS vendor and obviously, we develop a tool.

We believe that it’s a good solution. And we find champions at prospects and manage to make the sale. Like, we get them excited, they pitch the product internally and they get it adopted. If we’re fortunate enough, we make the sale and we believe that we have a good solution for them.

So, something that I realized, you know, it’s a very small startup. You think about, Hey, let’s make our first sale. But then as you grow up as a company, you begin to think about lifetime value and churn, upsells and all that. And then you realize that if you sell to a champion within the organization who is part of a discipline like engineering, so you’re [00:12:00] selling a technical product and they’re like going crazy for it and trying to pitch it.

If you are not mindful of other teams in the organization who might not be as happy about the tool or the changes that come with it, there’s gonna come a time where it’s gonna start to generate friction, like a tectonic shift within the organization. As a vendor, you have to be very, very mindful of these things.

It’s gonna generate friction. And then, you know, something that might happen and happened to me in the past is that you see like a change or a change in the balance of power within this customer. And then someone else will have the upper end and they’re gonna say, oh, no, no, no. This time, we’re changing everything.

We’re moving to my tools that are gonna serve my teams because my content ops team needs something different. And then you find yourself in a situation of churn, even if you had this great champion. So I would say even from thinking just in a purely like how do you succeed as [00:13:00] a vendor, you have to be mindful of these points of friction.

For me, it’s a lot about empathy and listening, but even if you think about like purely from a business perspective, it’s something that you really have to be mindful of.

Maribel Mullins: So would you say that people who are buying visual editors today, you’re trying to get the buy-in from both the marketing team and the technical team, but more so, not just one group and ensuring that both groups are aligned in wanting this tool?

Elad Rosenheim: I would say like we have this, and you used this phrase, which is I think kind of new and gaining more traction, I see it with analysts now, like visual experience platforms. At this stage, there is a challenge here because there are multiple stakeholders. The pro and the cons are the same thing. You’re trying to sell something that appeals to multiple stakeholders, but you need all of them engaged. So it’s not just about selling to X and then having Y disgruntled and in the background. It’s an emerging concept and when it gets popular, when you know, [00:14:00] companies are talking about it, more and more analysts get to start talking about it more and more. It’ll be maybe easier for people to, to have their head around right now. I would say like admittedly, it’s a bit like educating the market or trying to explain and trying to show what it could be like.

People are not used to this idea of, Hey, multiple teams can actually benefit from this. Let’s show you how.

Sam Brace: I’m hearing this interesting term popping up when we’re hearing headless conversations take place or things about MACH architecture is that there’s this concept of content orchestration is what they’re calling it. And it, what I see is that’s kind of almost like a personalization type of conversation that I see happening there.

But with you, I still feel like these visual experience platforms are doing some form of content orchestration, where we’re bringing in all these different sources to be able to have a stake or a portion of the content authoring [00:15:00] flows or the content authoring experience. But am I misunderstanding these terms?

Elad Rosenheim: I would say like content orchestration might mean different things to different vendors. But for me, one of the interesting things that I see… when we talked about headless, something that came to mind is we make sure as an industry that when people think that, like now they understand like, okay, we understand what headless is, we immediately come with a different buzzword like composable, and then people are again like, Hey, what does this mean? I was on top of headless. Now you’re saying composable, so. But it all points to this like multitude of tool. You have the CMS, you have this kind of visual editing layer.

You have an eCommerce platform that maybe, you know, you have to do some work with. And then you have the consolidation vendor and the search solution that you’re working on. And depending on the vertical you’re on, like a whole host of other tools. And something that I see often, and I can give an example. So think about Cloudinary, what I see in [00:16:00] Cloudinary is, I mean, nobody’s gonna argue that it’s a very feature packed, powerful platform that there’s a ton of things it can do. And it’s okay that, you know, some customers are gonna use it for X, some are gonna use it for Y, but I can safely assume that each and every one of your customers have features that they’re not aware of because it’s not maybe in the daily workflow, maybe for them it’s hidden away somewhere.

So there’s a lot of power when we talk about composable architecture and you think about all these tools that you’re bringing together and all these features that they have, and a lot of them are not as exposed, as immediately accessible to the team members as they could be.

So for me, a lot of what we’re doing, a lot of what we’re pushing for is not just visual editing of let’s say content or a landing page, it’s also about bringing the best of what Cloudinary can do [00:17:00] for you and what a lot of other tools that have their own admin, have their own analytics, bring it into your hands.

When we talk about orchestration or composable, for me it’s about how do we extract like the best out of each tool? And it might be different things for different companies. Like it’s not everyone wants the same subset of features, but it’s like exposing these capability and exposing this power, right to the marketer’s hands, let’s say.

So that for me goes a long way to… how should I put it? To make this bunch of tools, you know, connected together loosely into something that feels more coherent. So in that way it goes back to an experience that maybe you once have as a marketer of like one tool that does like a lot of things, I want to recreate this experience, but this time you get to choose what the components are.

Sam Brace: To me, it feels like that actually would be a benefit for using microservices that you are bringing it [00:18:00] into a visual experience platform. Because to your point, like let’s say that there’s a microservice that can do 500 things and you’re saying, well, we’re gonna make sure that the things that the content team team needs to do, we’re going to expose 10 of those things, then that’s where then those 10 things are used very, very well.

But it’s tied to a very clear need. But that means that as time goes on, if the development team says we’re gonna expose other things, it’s always given to them in the layer of what they can do or what is going to be impactful for their content delivery. Am I understanding that correctly?

Elad Rosenheim: Yeah, I think you can see that in multiple aspects.

So first of all, think about the design of a website. A lot of the times you have this situation, and I’m using an analogy here, but it’s also very, you know, pertinent to what we’re talking about. A lot of the time you find that the content management system or the way people build websites, either it’s like too inflexible and it’s very, very hard to do anything.

Or it’s completely [00:19:00] easy to just screw up everything with one little change, or make it at the very least completely inconsistent between pages. And in the worst case, like, you know, break things. So you’re trying to think how do I provide an experience to the content ops team? Will they have enough flexibility, agility, you know, a freedom to change things, but also they have like the right guardrails.

And these guardrails are not gonna be the same for all organizations. And even like within the organizations you have, it’s very common in bigger organizations to have many, many people touching the website and they need different things. And so in the same way, if I’m thinking about as a content team, what do they need from Cloudinary?

What level of control do they need? Or think about many other tools also that come into play. You’d want to have an environment where it’s kinda like, let’s say, let’s call it tailormade. I’m an organization. As a manager or the, let’s say director of multiple content teams.

I know what I want my people [00:20:00] to be agile, to be independent on. And I also want to set up the right guardrails. So in a sense it’s like build your own or tailormade content editing environment where you have these guardrails and you have the flexibility.

Maribel Mullins: Yeah, and I can definitely see challenges with that from like you working with other partners and trying to ensure, like you would have to learn all of the search capabilities and all the image capabilities to be able to know what to pull into your product to give that marketing experience like the best it could be.

And I know also if you give too much, you might be overwhelming people of what the possibilities are and then they wouldn’t know, you know, how to use the editor whatnot. How do you find the balance? Like how do you, I mean, is it just like learning every single component that can work or microservices that can work and, and then customizing to that? Or listening to the customer’s feedback or…?

Elad Rosenheim: It’s an excellent question because also I can relate to my own journey. So I come from a technical engineering background. When I started working with marketing automation tools like [00:21:00] way before Stackbit, my initial inclination is, okay, I’m gonna work with marketers and I’m gonna show them how to be extremely data driven and insight driven and completely agile about everything they do.

And I started getting some pushback because at the time I didn’t realize that people have, first of all, they have like the core jobs to be done, which they have to be mindful of, and it’s easy to get overwhelmed by all these choices and all these capabilities. So I was preaching something that didn’t relate very well to what people perceived as, first of all, I need to get my job done, and then I want my job to be, you know, to be recognized, to be more visible. I want the quality of my work to be recognized.

My father was a clinical psychologist and professor of psychology.

So I always get like this, these moments where I’m like, okay, let’s think about the psychology of these people. What do they need? What do they want? What are they fearful of? And start from there. Like, restart the way I’m thinking about the tools they need. [00:22:00] And so if I’m thinking about what to expose to people.

You have to start with, hey, okay, so one level is, first of all, do they have the tools to do the job? And then when I’m exposing more capabilities, how does that connect to them feeling… okay, I have more control, but I could start taking gradual steps. I can improve, let’s say how image assets look.

But I don’t have to go all overboard. Like I get, you know, I get more control. I can go a step at a time, for example, with Cloudinary, you know, let’s say a classical thing that you would do is like, you can decide how you wanna crop images automatically. So you might do like this little step and images become better, or a little transformation.

Everything looks a bit nicer. You don’t have to take everything at the same time. When I think about how to expose things, it’s really about, how do I make it clear that you don’t have to go all in? You don’t have to. You can take it in your own pace. But then also there’s a bit about you want to challenge people or you wanna make them [00:23:00] curious.

If you’re working with a new website and I’m starting to gradually, you know, you have these bits where you have more analytics, like, hey, this is doing a bit better, this is doing worse. You get them curious about, Hey, let’s do something about that. Oh, I have this tool, let’s start to play with this.

You’re trying to be friendly, you’re trying to improve their lives because it’s so easy. I would say as a technologist or as a vendor that has a technical product, develop this notion that you know better, you know, what’s the ideal state?

How should everyone work? Here’s my product. And if you’re not using it to the fullest, you’re like missing out. Maybe it’s true, but the people on the other end, they have their own mindset and you know, it’s our job if we want to be successful to try to hook into that mindset and, you know, expose them to the right things at the right time.

Sam Brace: So let’s focus on the clinical psychology part of this. Cause I feel like you bring a lot of this because as we said, you’re taking two people that may look at the world [00:24:00] very differently, but they have to work together to be able to produce content, the development teams, the engineering teams, and then also the marketing teams in a lot of cases, content teams.

So if you’re saying, okay, a visual experience platform. And in my opinion, it, it’s almost seeming to be a very vital aspect to headless architecture because if I don’t have it, one of those two audiences is going to feel like they’re not getting what they want out of the experience, no pun intended by using that word experience either, but in, in a sense, what are the things that you feel like a development team should be asking questions about or should lead them to be able to understand the need for a visual experience platform, and then subsequently the same for the marketing team? What questions should they be, or pain points should they be saying we’re feeling before they decide to go down this path?

Elad Rosenheim: You have to realize that when there is friction, everyone suffers. When marketers are not independent and they have to depend on developers, it means developers have to do these chores, which they don’t wanna do, [00:25:00] so they’re pissed off as well.

If you are a development team, you definitely as much as marketers, you don’t want to be locked in into legacy or monolithic tools. You don’t want to depend on others or have to serve their needs like constantly for any chore that they might need. And one of the signs that things are not as they should, is when every little change feels like you get into a defensive mode.

Within an organization, if people are asking for something and instead of like lighting up , you are kind of like defending your resources and starting to argue and rolling your eyes. That’s not a healthy situation. And sometimes it’s hard, a lot of times is that people don’t realize that both sides are frustrated and you kinda have to reset its relationship. So I think marketers, when they hear like the technical team talking about this new tool or this new opportunity that they can get cynical very quickly. And it’s the same like on the [00:26:00] other end. So you kind of have to break the cycle somehow.

Sam Brace: So thinking about the marketing teams though, one thing that I’ve heard, but I don’t know is true, and I’m not questioning it, it’s more of just like maybe looking for validity here is, are marketing teams looking for a WYSIWYG style experience when it comes to being able to edit content?

Or are they looking at things that are more tied to things that our developer audiences are naturally inclined to? Example I would give you is like, do they wanna have a tool where it’s very much like the WYSIWYG editors we’ve seen through content management systems like the WordPresses of the world where you can hit the bold button and bold your texts, that type of stuff, or is it where you’re finding that more of these marketing teams are inclined to start using like Markdown or are they getting more comfortable with JSON, which kinda leads them into this development territory? Like what’s the mindset of the common marketing teams that you’re dealing with when they’re saying, I want a visual experience platform, or I want to start using [00:27:00] Stackbit?

Elad Rosenheim: I would say like even before talking about like, do they like JSON? And spoiler, the answer is no. But I think the reason… if you really think about you know… consider myself, I consider myself a technical person, you know, intelligent to an extent, and when I’m using a headless CMS, you have to wrap your head around like the logical, deeply nested structure.

And as humans, it’s not comfortable for us. It’s not easy for us, it’s not easy for me after all these years. So when I think of, Hey, where am I? Am I in the right place trying to stay in context? As you navigate like an nested product structure, I think about our customers.

And I’m like, no way. So usually what you’ll find an organization that have to, you know, use these tools without any layer above is there’s gonna be this one brave person who knows what she’s doing and she’s brave enough, qualified enough to do the changes for everyone else. Everybody’s like coming to [00:28:00] her asking for her to make the actual changes because she can go in and then find a way.

So it’s always good to have this kind of like innovator or, you know, one-stop shop person within the team. But in general, people think visually. It also applies to developers. We all have this trait. We think about the end results. You wanna have this landing page, or we wanna have this post or this, or the listing page, and you immediately visualize how you want it to be.

You don’t want to think about how things are logically organized. And I’ve seen like in my distant past, like very large systems where we thought that we could project from how the content was organized. And structured directly into how the UI is laid out. And it was a disaster. With a CMS that really focus on content structure, that’s exactly what we’ll force and think people to do, which is get away [00:29:00] from what you visualize what you want to achieve into the intricate byzantine world of references that we’ve laid out just for you.

That’s how I feel about it, even as a deeply technical person.

Maribel Mullins: No, I I love that you’re saying that. Because I’m working with a lot of headless CMSs, I definitely see where people can get caught up in the whole content structure and how deep rooted it can really get and complicated. So, love this visual editor piece where you can actually see what you’re building and understand the components that are involved. It kind of overlaps. I’m trying to envision that maybe even with the visual editor, you kind of run into the same problems. You still kind of have to have content mindset too.

So I’m trying to figure out like how it really, truly differs from like content management system and the visual editor. You mentioned that you don’t need, you know, the different mentality, but I’m like, but how true is that, I guess?

Elad Rosenheim: Part of what we’re doing, like specifically at Stackbit, to address this[00:30:00] is really going from, Hey, here are a bunch of components, and there’s like a whole bunch of properties and you can change everything and everything is into your fingertips, into emphasizing like presets, like let’s build, let’s start to build out a library.

It’s part of the product. Like there’s a view where you see like all the different presets. It’s much more visual and you can imagine with a hero section or with a feature post, it’s like an ideation library or a library of opportunities. So you can get back to that and say, okay, now I have a much better, more visual, immediate view of the different looks that I can achieve.

It’s like opening this IKEA magazine or think of like the old fashioned catalogs and you see people in like in different settings using these products or wearing these things because that’s so much easier to imagine instead of just having each product or each feature like separately.

So [00:31:00] as time goes on, like, when you build a product, you think about like the necessities. So you build the tools, but then you realize people don’t understand where all these things are. So you start focusing on, let’s make a central place, for example, within the product where people are going again and again into, to look at, here is the inspiration, here are the different ways in which I can use these components.

You’re very much correct. It’s never gonna be completely dumbed down because there is a structured content beneath, and it was probably never easy. Like there is a level of understanding. What we’re trying to do is kind of mitigate this initial shock of working with structured content.

Sam Brace: As we know there’s lots of fun ways to talk about headless, right? As you said, like we call it composable, we call it headless, we call it modular. One of the other things that gets mentioned when we talk about this is this term swappable.

And of course swapping means I’m taking [00:32:00] something in and I’m moving something out. I’m swapping it in and out, right? One of the pros that you hear mentioned about moving into MACH architecture is that if you find a great microservice, you can easily swap it in for the previous one and swap it out.

And for everybody here selfishly in this room, that means that we could easily be swapped in and out too, right? So I wanted to get your take on this, like as you’ve been dealing with people that are now saying, okay, I want to be able to weave this experience in for search, this service end for the video component or the image component, do you see that as something that’s people getting really excited by that swappable part of it?

Do you see that as still as a real benefit for the headless move or the headless planning? Or is it more of that’s something that gets people excited from a marketing sales standpoint, but isn’t what they actually do when they get into the nuts and bolts and the build process of their headless systems?

Elad Rosenheim: [00:33:00] It’s kind of interesting because it’s ambivalent or it’s a double-edged sword, both from the vendor perspective and also from the customer perspective and from the vendor is like, it’s easy to visualize. Like why is it frightening? Because the part that you can go in so easily also means that, you know, you could be swapped easily if you are just like this again, anonymous component of this composable stack. People could swap you in into a different source solution and no one will know. That’s part of like being, what being composable kind of means, but then it’s, it’s a danger.

How do you make yourself shine as kind of, no, this is the search solution, this is the experience that you want. These are all the features. So a lot of, you know, we’ve been talking about how do I expose, like, the best of a tool? So if I have this environment where I have all these tools, I wanna make sure like that the best of each of these tools really shine through and people don’t want to swap them.

So as a vendor it’s frightening. You know, when I started my [00:34:00] career, it was still the nineties because I’m, I’m that old. And there was like an tremendous transaction cost to swapping basically anything. It was a long sale cycle and, you know, you stayed with pains for a decade or two. It has to be said, like it’s, it’s much easier to build right now.

It’s much easier to adopt technology, but you have to be so much on edge to make sure that your value shines also the noise. So it’s, it’s part of the deal, but also I think from the customer perspective, there’s the classic paradox of choice. Customers are uncertain about a lot of these choices.

So they’ll start with, let’s say, okay, we settled on, have the CMS X. And we know this part of the stack and we know we’re gonna use React or use something else. But then again, there’s all sorts of tools, which now I have to make a decision about. And all these vendors are coming and, you know, showing those shiny stuff and promising the good integration.

It’s a [00:35:00] confusing moment. Consider yourself at a bigger enterprise making choices for a big re-platforming moment. When I sell Stackbit, it’s not just for the customer. I have to realize it’s not just Stackbit.

It’s a whole re-platforming effort that they are typically making. I have to be a trusted advisor, be as honest as I can, as helpful as I can during that time because people are uncertain and I understand them. So that’s our challenge, I think, when as a vendor is being part of this, let’s say, I would call it like a distributed selling process.

There’s so many moving parts, so many solutions that they have to bring together. How do I make my ROI positive in terms of like, I’m contributing more in terms of like helping the customer realize what the stack is more than I generate noise in that process. So it’s definitely, you know, a lot of these things we’re talking about, the book is not yet written and sealed on how to do it correctly. It’s relatively new. The idea that you [00:36:00] can decide on instead of getting like 500 channels bundled together, from one big vendor and you get all the pros and all the cons together. Now you have your choice.

No one has figured out completely how to make composable look like one streamlined thing. There’s like the business aspect, so many contracts. I get reminded of this quote. I don’t remember who said it. If you wanna make money, one way is to bundle things. One way is bundling and the other is unbundling . So, you know, the nature of these things, like we’re seeing this trends change and every time, like you move to the other end, you immediately see the gaps. So we’re never gonna get to this happy place where everything is perfect.

This is one of the hardships with composable.

Maribel Mullins: Are you seeing a trend, if like smaller companies go with like the monolithic products and then as they get bigger, they start to unbundle and like start going headless. Or maybe because headless is a new thing that [00:37:00] more startup companies are like jumping to headless first because they know it’s scalable or are you seeing any trends in the market?

Elad Rosenheim: It’s even more nuanced than that, and not just with headless CMS. So what you’re seeing is at first, you’ll have like the legacy monolithic solutions, and then you have this wave of startups that, you know, take some portion of the pie and, and make it better. And then since you have this big behemoth type players, like SAP and Microsoft and Salesforce, they’re threatened by it. And they still have so much cash in hand. So they’ll try to, to eat up and create this like, new style, new package of like, the whole platform that has like, buy a lot of startups, but gluing everything together.

And as a startup, I remember in the previous company that I was at, at some point we got very scared that a very big player is gonna move into our field. And we were like, you know, let’s adjourn the [00:38:00] CEO’s quarters and see what we can do about it. And he said, you know, everything that we do today is gonna be a commodity tomorrow and everybody’s gonna bundle that.

As a startup, we just have to be one step ahead because all this is gonna be a commodity and it’s gonna come with the platforms. So what you’re gonna see is like, maybe ironically first like headless, let’s decouple it. But then, oh, but now we have to talk to all these vendors exactly what we talked about, different contracts, questionable integrations, and no one to no clear owner.

Like if Tool A doesn’t talk to tool B, I can, I can try and, and you know, shout at both of them, but it’s not clear like who’s responsible. So what do I do? I look for this big vendor, which will now say they have a composable headless architecture, but also they sell all the other parts. I can buy the whole deal.

This kind of cycle always happens. So with headless it’s new enough that you have a lot [00:39:00] of like independent players, but already you see these consolidations and it started like, let’s say Optimizely and Episerver and, and you start seeing like this, every time there’s like a new field of a new domain, you’re gonna see, you know, startups and then corporations trying to react by, hey, we are the same. We are composable, we are all these things, but we also offer everything. So it’s interesting. I do see that.

Sam Brace: When we’re talking about different microservices and all of that detail that’s tied to it in terms of consolidation and bundling and all of that, are there ones that you’d see as like typically brought up when you are talking to them about Stackbit?

Like when people are in their stages of saying, I think I want a visual experience platform, or maybe they came to you from a different conclusion, but it’s to say, are there other microservices that are typically mentioned in the same breath? Like is it some of the CMS [00:40:00] examples or is it some of the site search examples?

Like where do you see people also always bringing Stackbit into the conversation with?

Elad Rosenheim: Yeah, so first of all, you’ve mentioned CMS. You kind of have to appreciate it that headless CMS became a thing. It’s taking the whole database concept and putting layers on top of that.

And everyone that we’re talking to, I they’re saying, Hey, first of all, we need to have the CMS, like, that’s the base. So from a recognition of the field, the headless CMS vendors have done a very good job in making the claim that, hey, first of all, choose a stable foundation.

So that’s one. But then people are tied to their component libraries. One of the challenges, by the way, when you’re modernizing, think about you have a classic WordPress site and it’s like tons of customizations. And now you’re hearing about React. You hear about this and that, but you know that there’s like this big amount of like design system and brand and components. So that’s [00:41:00] something that’s gets really people really worried. And then you have all these things that are instrumental to website. You have analytics, people wanna know that it’s friendly to analytics. I mentioned personalization a lot just because my background has a lot to do with it. It’s one of these things like, you know, as an organization that you need to have an AB testing plan, you need to have a personalization plan. So whenever I’m talking to a prospect, I feel like, and I already know it by heart, there’s like this checklist of things that they, and some of these things, like they use on a daily basis, some of these things they know they should be using and they’re asking for it.

Of course, like image management and digital asset management is one of these things, and seems to me like people are pretty loyal. Like it’s one of these things, if customers are using Cloudinary, they’re pretty adamant that they wanna keep using it, which I’m, you know, totally happy about. But it’s one of these things, like, something that I realized like, with a lot of these tools, it’s [00:42:00] enough that you have one or two major features that are indispensable to the people using them. And they’ll want to use the same tool forever because they found these things, which are so much in their daily lives, the daily work lives that they wanna adopt this tool forever.

And I’ve seen this with, by the way, with Cloudinary, I can also honestly say, and with specific analytics tools, because there’s so much effort invested. Like think about, you know, if you have an asset library, there is so much effort over time invested in curating it. And if you have an analytics program, so much effort was invested in the reports and all these things.

So when people are talking to us, there’s the stuff that is, yeah, we also want to integrate this cool stuff, this cool stuff, but also does like the big pillars? With so much effort, knowledge, time invested that, you know, it’s really hard requirement. We like these tools.[00:43:00] And you have to figure out a way to, to integrate well, with them.

So I think the list hasn’t really changed and, but it’s, as we say, it’s decoupled now and it begins with the headless CMS and then it goes forward. And by the way, one of the things that, you know, If you have a visual experience platform, one of the things where you’re trying to, and it goes back to the start of our conversation, is saying, Hey, yes, a very trustable main pillar of like a headless CMS and all these things.

It’s very important. But if you want the daily lives of the people who are working with these tools to be healthier, faster, with less friction, you have to think about the front end you know, through which they interact with these tools. Cause it’s not enough to say, okay, I have this infrastructure, I have this all figured out.

If you think about just the basic experience of how you interact with this tool. So that’s why, you know, we’re putting this layer on top and [00:44:00] I think it’s kind of a new thing. And people are still wrapping their head like, Hey, it’s actually, you know, it relates to our experience as we work in such an intimate way.

Maribel Mullins: I definitely see even workflows are going faster. Imagine like as a marketing person, you’re putting in content, but to actually see it on a page, to actually see what it’s gonna look like, you can make decisions of, you know, the characters are too long or it doesn’t match the rest of the webpages or whatever it may be.

So I can totally see that, the benefit of everything being visual, as opposed to just filling out a form and, and leaving it to the tech team to, to figure it out. So, yeah, I feel like a content management system, as you mentioned, is the base of adding the visual editor on top.

Elad Rosenheim: I think people have higher expectations out of their tools. If you are a marketer, you’re used to working with tools that are in many ways, just irritating. But you’re used to that and developers have been vocal forever about what they want to use or not want to use.

And with marketing, you got used to mediocre tools for a long time. But [00:45:00] this gap between, you know, the user experience that you get with consumer software or just mobile phones and whatever to what you’re getting with enterprise software, it’s, it’s getting more noticeable. It’s more, you know, it’s more pronounced.

So you expect this great consumer-like experience in your working lives and when you don’t deliver this as a vendor, people will find a way around and, you know, you’ll be redundant. And I’ve seen this forever. Even working in the defense industry like years ago where you have like a captive audience because you’re developing this, I don’t know, classified system for a customer. And then you’ll find out that they don’t like the system and they found a way around it because some of the people have, they have some, you know, some technical background and they build something and they attach the two scripts together and they have their own system. And this is like in the most rigid environment.

And so people expectations I think are higher. So it, it maps to [00:46:00] that why. Why can’t we have nice tools in our work lives? Why are we still with…. I, I don’t want to bash any of the monolithic tools because that’s not what I’m about. But you can picture all these tools where it’s like a form of a data entry and it’s very, very nested and you lose moments of happiness, let’s say, in your workday.

Sam Brace: Well, Elad, this has been fantastic and very enlightening in a few different areas. For me personally, I’m sure for our listeners, hopefully we’re taking away some of the great insights that we’re able to talk about here today and helping us better wrap their head around what this all means if they just are going down this path of headless and more to learn about it.

So thank you for taking the time. It’s been an absolute pleasure. And of course, Maribel, I love having you as a guest host. I can’t wait to have you for more of these. This is wonderful. And then of course, for those of you that had a good experience, thanks for sticking around here till the end. And if you did get to that point, be sure to like and subscribe on all the [00:47:00] places that we are, and you happen to be listening to it on. So of course, we’re on many different platforms such as Apple Podcast, Google Podcast, our own Cloudinary Academy, and more. So wherever you happen to be, thank you for being there, and we’ll see you again for the next episode of MX Matters. Take care.

Elad Rosenheim: Thank you. Bye.