Crossing the Enterprise Chasm


WorkOS CEO, Michael Grinich, and Sanity CEO, Magnus Hillestad, discuss the evolution of Sanity, starting with its origins as a PLG company focused on developer advocacy and open source, and transitioning to a product-led sales strategy that better serves enterprise customers.

What is Crossing the Enterprise Chasm?

Crossing the Enterprise Chasm is a podcast on how high-growth startups prepare to build with enterprises and Fortune 500 companies. Each week WorkOS founder Michael Grinich is joined by founders, early-stage team members, and product leaders who lead the charge to go upmarket. In every episode, you'll find tactics, strategies, and actions on how to successfully sell to and serve your crucial early enterprise customers.

Michael Grinich (00:02):
Welcome to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving up market to serving enterprise customers.

(00:10):
I'm your host, Michael Grinich. I'm the founder of WorkOS, which is a platform that helps developers quickly ship common enterprise features like single sign-on.

(00:19):
On this podcast, you'll hear directly from founders, product leaders, and early-stage operators who have navigated building great products for enterprise customers. In every episode, you'll find strategies, tactics, and real-world advice for ways to make your app enterprise ready and take your business to the next level.

(00:39):
Before we jump into today's conversation, I wanted to take a moment and thank Freepik. We are in Freepik's office and they've sponsored this episode of the podcast. Freepik is a marketplace where you can find everything from images, icons, vectors, to extensive AI designed specifically for designers. Their AI tools focus on the design aspect of the creative experience and help you create things faster, easier, and better. Check them out at Freepik.com.

(01:07):
Today I'm joined by Magnus Hillestad, co-founder and CEO of Sanity. For those of you unfamiliar, Sanity is a headless CMS, a content management system, that's beloved by developers. To give you a sense of scale, they have over 500,000 projects built on it, with over 50 million documents created, 20 billion API requests per month, and a petabyte of content served per month. They were founded in 2018, and have a number of marquee customers you might recognize, including Cloudflare, Anthropic, and Netlify, as well as consumer brands you might know, like Arc'teryx and Puma.

(01:42):
Really, really excited to have Magnus here on the podcast to talk about Sanity's growth, early days, and into the enterprise. Welcome.

Magnus Hillestad (01:48):
Thank you for having me.

Michael Grinich (01:49):
All right, so starting off, let's go back in time. Talk about the founding of Sanity. What was the problem you were trying to solve early on? Bring us back to those early days.

Magnus Hillestad (01:57):
Sanity was founded out of my co-founder's agency. I was a private equity dude back then, it's a different story.

(02:03):
But if you focus on the company, it was founded with the idea that, or was founded on the base of a project. A famous architect in Rotterdam, in Holland. He wanted to move out of WordPress over to some site, and my co-founders were not really a web agency, but they were building bespoke technology, built a social media network before Facebook came to Norway, et cetera. This was out of Norway.

(02:23):
And they reached out to my co-founders to build this, and they built this amazing ruled-based, assign-driven, React-based website and they're like, "Okay, let's find somewhere to have these files." And there was nothing out there that satisfied the need for the kind of content they wanted to use. So the alternative was just to put flat files on GitHub, is when they came up with the idea to, "Okay, let's build a content management system that enables you to build amazing things, web, as much as other things, where you can take the content, approach it programmatically, shape the content models exactly how you want to have them, and really shape the experience on the content side so that it's easier for people to work with content, both on the content product side, but also on the developer side that you could use it whatever."

(03:11):
And our MVP was actually used on a website as a corporate database and even printing books. This architect Rem Koolhaas, he's so big, he don't go with PowerPoint. He prints books, and he has an in-house printing shop. They were printing directly from Sanity to that, obviously some PDF converted in between.

Michael Grinich (03:28):
Wow.

Magnus Hillestad (03:29):
This is 2016.

Michael Grinich (03:31):
Wow. Okay. I know that you've talked a lot about how Sanity's growth is through this PLG motion, bottom-up motion. People are very familiar with PLG. We've used Dropbox, and Slack, and Airtable and stuff like that. Sanity's pretty different, though, I think, in two ways. One, it's a developer product, so it's not like Dropbox a consumer product and second of all, it's in this category of headless CMS that didn't really exist back then. So, I was wondering if you could talk about how PLG related to that. As you got started and started growing the business, what did that look like?

Magnus Hillestad (04:02):
So when we started Sanity, and I joined was still an agency and we shifted it into a software company in '18. That's why we say we founded it in '18, although the product was started to be built before that. We didn't know about this headless CMS category and honestly I don't like it. It's very reductive. The reason for that existence was that developers were starting to use JavaScript and the old CMSs didn't work anymore.

(04:23):
Now, then naturally there were multiple tools being built to give an API with the JSON payload so you could pull up that in React or some other JavaScript that you were using. That really was a reactive way to build a software based on some other trend, which can work. That also led to a lot of these tools needing to be easily accessible for developers.

(04:42):
When we built it, our idea was that developers are really central in order to control the content models and the experience. And if you use developers in the right way, you could get tremendous powers and velocity into what you're doing. And then when we were launching Sanity, it was very natural for us to let people just pick it up.

(05:02):
I think also it comes from… you should meet your customers where they are and build a business that suits the market, but you also build a business that suits yourself. I truly believe in that. So if you don't think it's going to be really fun to build a business that way, maybe you shouldn't do it. And we think it's really fun, things that can scale orders of magnitude, that could be approached programmatically as much as possible, that could be exponential instead of linear.

(05:27):
And back then I think we called it like we're going to go to market programmatically. We didn't know the word product-led growth. We didn't know what headless CMS. We were in Norway, we didn't know these things. But the whole idea was that if you do it in the right way, let people try it, then they become much more picky. They need to get a dopamine rush very quickly and say, "Oh, this solves my problem." That's a higher bar. You can also get a lot of people that give you feedback. So from the beginning we always loved free users. We had a self-serve plan, we still do. And then we had an enterprise offering. Without kind of putting too much thought into that, we already had SSO and some of the core things that you need to have to have an enterprise offering. And we just put it out there, but it is different.

(06:06):
This has been done with developer software before, for example, Heroku was like that. There are a lot of developer software that has just put out like that. Now, part of the difference, I think, in the CMS space is that you often have a buying committee. It's not up to just one developer whether to buy it or not, and very often it’s a big project. CMSs tend to last 3, 5, 7 years before they just change them and change the design. We're going to change that. So we say Sanity is the last CMS you ever install. But, naturally companies expect to pay quite a lot for it, hence there is a buying committee.

(06:39):
So already from the beginning we needed to have a sales motion. This isn't true for everybody. I think if you look at Heroku, it was like 80% self-serving over time. That would build on an enterprise motion. Sanity has always been 80% enterprise sales and 20% self serve, but it's all been inbound.

Michael Grinich (06:58):
And percentage of what? Percentage of revenue or?

Magnus Hillestad (07:01):
Of our revenue. But it's all been inbound and I think that's the PLG motion. So if you look at the experts, they call it product-led sales, because it's product led, but you still need to have a sales motion on top of it. But why did we do that?

(07:12):
I think our idea was that there is a better way to build something that can really scale and become really large. I think that's one of the things that, when I met my co-founders, that made us want to work together is that we think the same way. We care about trying to do something that can become really big, and we're happy to fail. We've come a bit since then, we haven't failed yet, so it starts looking better. But if you really want to try it hard.

(07:36):
Do you want to have a sales team that you have to scale linearly and BDRs, et cetera? At some point you need that. We have that now they're great, but in the beginning, do you want that? No, we wanted people to pick it up online to figure out the software, start using it, and if they get benefit from it then they come back again, well then you're onto something.

Michael Grinich (07:53):
That initial motion of having the developer sign up, or anybody, free to use, get started, play around with it. I think this is a comfortable place for a lot of entrepreneurs to get started. I talked to a lot of founders that even believe that's the way the product should be forever. "We'll never need a sales team" and all that.

Magnus Hillestad (08:11):
I think we didn't think that ever, but there was certainly a time where we thought that the self-serve motion would be the dominant motion

Michael Grinich (08:18):
In terms of revenue?

Magnus Hillestad (08:19):
In terms of revenue. So this is how it worked. We started, we just put it out there. There was a price plan, but it wasn't super well thought through. It worked pretty well, we iterated over time.

(08:29):
And then it's always been a really generous free plan. Sanity is half open source. Our studio, the actual web application, is open source and the database is closed source. And we wanted to have a really generous free plan so everybody could use it. And, in the beginning we thought that people would then come, and then they will upgrade, because they need some more and they'll pay us a little bit, but it would take a long time until we get these enterprise things going.

(08:56):
And that may be the case, and every business is different. But again, because there's buying committees and some of those things, we didn't see a lot of people start paying for self-service. We had a bunch of free users, and that picked up really fast, then we started to have people calling us like, "Hey, we're seeing what you have built. We've been looking for this for a long time."

Michael Grinich (09:14):
And what kind of customers were those? Talk about that.

Magnus Hillestad (09:16):
First that called out German company Bosch, it's like Milwaukee Tools here in the US...

Michael Grinich (09:21):
They make the wiper blades on my car.

Magnus Hillestad (09:23):
And then Electrolux was another one reaching out. Burger King was reaching out six months after we launched. This took, pretty precisely, seven months or something after we launched. So Sanity has always been very developer centric. NPM install in order to use it. Was always, has always been the ways you could look at the product without, but you have to have NPM installing.

(09:44):
And because of our very rich content modeling affordances, and our customizability affordances, which is our strong points, people were seeing, "Oh, I can actually build with this." Most CMSs are marketing tools and there's one size fits no one, and then you can do some adoption to them, but very different. We're an engineering tool. And they saw that and they said, "Okay, I need to talk to these people."

(10:04):
So Electrolux didn't come through. They were looking at a app framework or a framework for content for all their apps that manages all their, not the wiper blades, I don't think they are IoT yet. But Burger King was looking at how do we redo our content backend so that we can serve the same content to our web, to our mobile app, to our in-store ordering kiosk, and even we do today that became a customer, and still is a big customer of ours, onto the point of sale system. So their desktop menu components, the desktop menus, and then send them out through Sanity. It's very different. This is not a traditional CMS use case, it's much more thinking in a product sense about content.

Michael Grinich (10:44):
Does that mean you're selling to a different person than previous solutions?

Magnus Hillestad (10:48):
Yeah.

Michael Grinich (10:49):
You were talking about the marketing solution and probably selling to the marketing team.

Magnus Hillestad (10:53):
So it's a mix. We do still sell in quite a lot to marketing teams if they have engineers, or very technical people who then go hire agencies, but we sell a lot into product people and engineering teams. We do that partly because the kind of users that want to use a CMS in a more traditional sense that like Sanity is more engineering centric. And a lot of the marketing teams historically have been like, "Let's have less developers. Can we do this without? Can we have no code?" And there are solutions for that. Webflow is doing that great, just another segment of the market that we're not in.

Michael Grinich (11:23):
I want to go back to that enterprise conversation. So those people start calling you, you start talking to Bosch and Burger King, I'm assuming it's you and the other early team doing these sales, doing discovery, trying to figure out what they're looking for. What did they need that was different from what you had built on the self-serve side? How did you need to adapt to those types of customers?

Magnus Hillestad (11:41):
Nothing. We were lucky we didn't have to. They didn't come. And this is probably luck and I got one data point right, because we did this only once.

(11:49):
But, when Burger King reached out, what we had to do... And yes, it's true, I was the sales guy. One of my co-founders was the, or actually on this deal, two of my three co-founders were solution engineers, but this was also natural because I'm a pretty new developer, so I'm not the hardcore technical. I'm a finance guy. It's also very natural for me to have the commercial discussions and the whole sales process. It's very natural for my co-founders to be the solution engineers.

(12:16):
So we just sat down, it was a couple of consultants, both of them became CTO of Burger King, so it ended up being a big thing, a team of 200, but it was just them when they reached out. They really understood technology, and they understood what they wanted to build, and they needed an engineering tool.

(12:30):
So what we did in the beginning was really about helping them build out their content models in Sanity. Sanity was rich, my co-founder spent a couple of years inside the agency to iterate on it, and they had three bootstrap cases inside the agency. So we didn't need this feature or that feature, we already had some of the security things taken care of that was important for them. But, also, I think, Burger King at that point was very experimental.

(13:00):
So it's not Burger King, it's Restaurant Brands International, it's a parent company at Burger King. So this also means it's Tim Horton's and Popeye's. They launched Popeye's new website and app on Sanity on our GraphQL API. It was then launched in beta, without telling us, just our servers went hot, or our TCP instance went hot.

Michael Grinich (13:19):
That's product market fit.

Magnus Hillestad (13:20):
That is probably that.

(13:21):
And that happened six months in. I think it took us three, four months to sign a contract. We signed a contract, I think it was like $89,000, but it was structured in a way it would grow as their need grows, and need did grow, and it did. And typically we sell between a hundred thousand dollars, but we also have larger customers in seven figures, and some of them really grow over time.

Michael Grinich (13:45):
Tell me about when you started building a sales team. Was it still all inbound? The sales was just engaging with that? Did you start going out and hunting for customers?

Magnus Hillestad (13:52):
No, we've been experimenting. The first real quarter when we got, what we called outbound leads, was last quarter.

Michael Grinich (14:00):
Wow.

Magnus Hillestad (14:01):
As you know, we're post series B. We did our series B in 2021, so we're quite far post series B. We're in the tens of millions of ARR.

Michael Grinich (14:08):
And how big is the team right now, to give a sense, like sales team or engineering team?

Magnus Hillestad (14:12):
Total company's about 160 people. I think sales team right now is about 30, with a goal to grow to 60 by the end of the year. That is all sales, BDRs, account team, et cetera. We could go through some of that.

(14:26):
So the way it started, we took all these discussions, my co-founders and I, it started working, people liked it, people started buying it, and then it was too much demand so we needed someone to come in and help us with this. And of course we spent a lot of time listening to podcasts, and hadn't yet moved to San Francisco then, but started talking to others. We understood we needed to have people coming side-by-side with us to learn. And I still only got one data point, but that seems like a really good way to do it. It worked for us.

(14:55):
So we hired a salesperson and a little bit later we hired a solution engineer, and we just started teaming up with them to let them learn it, and then after some months when we saw that they have learned the way we talked about it, and what we saw, and we were kind of building the process at the same time. This we did about a year after launch. I think roughly a year after launch is when they started maybe a little bit longer, one and a half years maybe.

(15:20):
And then we hired them both in Norway, because we were in Norway at the time. We moved, one and a half years in, I moved to the US and we started building here. And it was really just prototyping. How is the sales going to work? There were two really strong guys, one of them is still with us, the other one just left to start his own company, but they were doing really well. So we were very lucky with those hires. We actually had one iteration of one of these positions before we landed there.

(15:48):
But the key was, do we trust them to talk to our customers? I think that's often been the feeling. Do I trust someone? Not because they have bad intentions, but do I trust that they can have a conversation? Do they understand the selling points of what we're doing? Sanity is very technical. The solution engineer is very technical, but the sales guy was a bit more like me, like a finance guy. He came from a tech investment banking position, but he wasn't technical, he was just very inspired to do it and to learn.

(16:17):
We saw pretty quickly that that started to work, especially in Norway and then Europe where we started from, and then maybe half a year after that, one of my co-founders and myself, we moved here and he was the prime solution engineer and I was the prime salesperson. So then we did the same over in the US, and then that also took us some time, and we moved, actually, the solution engineer from Norway, we moved him to the US also. He lives here now, he's Norwegian.

(16:42):
But the sales person in Norway, he was working crazy hours. So he did a lot of US sales as well. I think that's how we did it in the beginning. And we were a bit scared of hiring people in the US in the beginning, being Norwegian, we didn't know the culture. And then after our series A, which was May 2020. So that was like another two and a half years in. We started building the team, the sales team, in the US.

(17:07):
And what we did then was that we hired some more solution engineers, but we also hired, I hired two account reps. So the advice is to hire two so you could AB test them. And I also took an advisor that was really good, taking a company from zero to 10 million, and he helped me and I said, "Okay, I'm going to be the VP of sales."

(17:30):
So I moved from being an account executive to be a VP of sales. I'd like to prototype the positions when we're building out, and then help me, how should we do this thing? And then I was trying to teach these account executives the motion that we had used in Norway, and what we've used in the US, the pricing models, and how we're thinking about, and the key benefits and see if they could replicate that. And they could, both of them were great. One of them left after a year, less than a year, and turnover of course you should expect in this. The other one stayed in and is now a sales manager and does the most of our US sales and his team.

Michael Grinich (18:05):
I want to ask about the open source stuff. We haven't covered that.

(18:08):
So you talked earlier about how early on in Sanity it was PLG, sign up, NPM install, use the service. Sanity Studio is open source. How is this different and what have you had done around the open source side?

Magnus Hillestad (18:20):
So Sanity Studio is open source, because it's React application that is MIT licensed. It has never built on external contributions. We've had external contributions, but we don't necessarily encourage it. We have bug fixes and stuff, but not features being built on it. So it's not an open source product in that sense.

(18:36):
The reason that we made half of our product open source is because the whole idea of Sanity is that companies should be able to encode their business logic into their content model and into their content workflows, and the best way to do that in their content models is to actually give them the code. So anything that can be represented in React can be represented in Sanity, all the workflows they need, and we focus on giving them the first principles to build that and to do that fast. So it's extendable by design and that has given us a big edge in the market. Obviously there are customers who don't like that, but that also gives us the niche of who liked that. If you're ideological about open source, you wouldn't like what we do, but we got a lot of benefits from developers who want to be in control.

(19:20):
So we're often talked about as an open source software. And one of the first hires we made, this was not in sales though, we made two hires after we raised our pre-seed round. We already had a team of developers from the agency that we closed down and opened this new company, but we hired a head of DevRel who's still with us, Knut Melvær, who's always been central in building a community and building the developer movement. And then we hired a SRE person to actually run it, and then building that, one of the first things that Knut did when he started, or probably even before he started, because he was so eager, he started setting up a Slack community.

(19:53):
And what we did when we launched is that we emailed each and every one signing up, and in the beginning it wasn't that many, so that's fine. We emailed everyone and we had one simple thing we said, "Can we have some unvarnished feedback from you in an email or if you want to, we could jump on a call." And we did that independent of who they were. So we were talking to someone who was running a church website in Milwaukee, and that was important product feedback to us to understand how did they think about using it. And we were talking to people working in enterprises as well. A lot of these bottom-up groundswells that we always loved, which is also why we're not trying to squeeze our self-serve users. When we make revisions of our pricing plans, which we have done every year and a half, maybe on the open pricing side, on the enterprise side is easier, because you could just change without people seeing it.

(20:43):
We never changed the historic pricing, what people have had, we just grandfathered those prices, and we try to make a change that is meaningful for us and meaningful for the community while always being very generous to the free users. So we got a lot of that bottom up. We now have, I think, monthly active 30,000 people. No, that's probably not monthly active, but active people, 30,000 people in that Slack community that come in. So that open source component also means that people can build plugins very easily. They can add on and share with others. We have a Sanity exchange where people do that. That has been a huge part of our success.

Michael Grinich (21:19):
What is a DevRel developer advocate? A lot of people have different titles for a similar role in companies. What were they doing early on? You mentioned getting feedback, but was that driving additional user growth for you? Were they going to events and conferences, speaking at stuff? How do you see that fitting in?

Magnus Hillestad (21:34):
In the beginning we called it DevRel and then at some point we felt that wasn't fully fitting, so we cut down on the efforts. We never cut down on developer marketing and the actual developer advocacy, we just changed the composition and now we're building more of a developer experience team. And I think it's slightly different of what are you trying to do.

(21:50):
In the beginning it was all about signups and it was all about getting people's attention around it. We went to conferences. We were big at attending Jamstack, and around Vercel and Netlify, we've always been friends with them and fans of that. We had webinars, and we showcased, and we built examples, and of course that team naturally gravitates towards documentation. So for a long time they unofficially own documentation, now officially that's a team under Knut who runs developer marketing.

(22:19):
And then there's a lot of debate in that do developers want to be marketed to and how commercial... Developers are more commercial than people giving them credit for, but they're also picky, which is fine. They like to be marketed to, just not bad marketing, and they're probably more picky than others. But if you give them value and if you show things that is relevant for them, they love it and they have no problem with things being transactional, as long as it's not cringey.

Michael Grinich (22:45):
More about that. What do you mean? What's cringe? What's not?

Magnus Hillestad (22:47):
So if you reach out to someone with an alternative motive where you try to disguise it as something, they hate that, but if you reach out to them, it's like, "this is what I'm trying to do..." What we actually did with this team, that is still under Knut, then is that we made it more focused for a period on people actually building for work.

(23:07):
In the beginning we were focused on anything. So if you just build for fun, and that's still a very welcome user-base in Sanity, but our starter kits were always: make a blog post for yourself, which is helpful just to get started. But what we realized is that we need to give the users building for their business or organization, not necessarily only enterprise, it could be people not paying us a lot, we need to help them be rock stars in their organization and help them go along.

(23:34):
So we started building out more of a Sanity Learn that we launched now in May, but we had some iterations of it before, which is just better learning materials, better training materials for building real things with Sanity. Well, in the beginning it was much more focused on just like, "Hey, come here and look at this cool thing." Because there are a lot of things you could do very easily cool with Sanity. Works for both.

(23:54):
So that's how we changed it and do it now. Always been extremely out there in our community with these 30,000 people. We try to encourage everyone in the company to be there, answer questions, say hi. We have an introduction channel, and if you have five minutes, go and say hi to a couple of people there, and welcome them to the community, like you're standing in the door saying hi. So really care about them. And it's not because we want something from them, or we're going to lure them into something. I think developers are often a little bit afraid and paranoid if there are these alternative motives and looking for that.

(24:30):
As long as you're really true, and I would always be the biggest developer advocate in this company. The moment we don't focus on the developers to really love the product, and understand the product, and be efficient with the product, then our biggest edge is done. And I think a lot of companies, when they start selling enterprise, the reality is a lot of enterprise companies have developers who are a little bit less motivated and crazy in their thinking, and have less expectation from software, because they get less good software very often. And so they have different expectation level than smaller companies, often. So I think driving that has been one of the key successes.

(25:09):
We've never stopped doing that. And as long as it's real, we love their feedback. We love people using it for free. I don't love an enterprise using it for free, but if they are, then A, it’s our fault. ABC is our fault anyhow. Maybe it's the product that's wrong, maybe it's the pricing that is wrong, we're doing something that doesn't give them more value, so they should jump up to their right tier.

(25:30):
I look at pricing as segmentation, not as a journey, but it depends on the product. For many companies, like a journey, you always start here, then you buy more and more, and once you go to production, you should go up here. Sanity is much more of a segmentation. It could be as a journey for some, but if you're a big company, if you're AT&T is one of our customers, AT&T.com, huge thing. They do the iPhone launches, super secret and all those things, they're not going to start self serve. They're just not. So they're going to start talking to you, and they expect a big apparatus to talk to, and that's a very different approach than a company that just going to use this. Are you guys using Sanity?

Michael Grinich (26:07):
I think we are using it for some stuff.

Magnus Hillestad (26:09):
You're probably a self-serve customer. You probably don't pay us a lot. Maybe you contribute some back in the community and...

Michael Grinich (26:14):
We'll talk about that later.

Magnus Hillestad (26:17):
I wouldn't push you up. But that segmentation, I think, is really important on pricing. Free users are there to create and then self-serve users are there for collaboration, and some more scale features, and the enterprise plan is for mid-market and enterprise companies who have higher scale, who need more security, auditability, et cetera, et cetera.

Michael Grinich (26:37):
And you're saying they land there right at the beginning. They don't necessarily move from... AT&T doesn't put in a credit card and it eventually becomes an enterprise user like they might with Dropbox, or Asana, or something like that.

Magnus Hillestad (26:48):
Exactly, because they know they're going to buy. You can't scale your efforts either you have that as a CMS system or you don't. And if that is your product, there's a high likelihood that people want advice on how they put it in. So we don't do professional services, but we have really good solution engineers that give advice and help with architecture.

(27:05):
You want that from the beginning, and then you can easily pay maybe a hundred, which is what you need to run a sales team anyhow, like those kinds of levels.

Michael Grinich (27:13):
You can build so many things with Sanity, you mentioned a few of them. A lot of different types of teams can build things. You even talked about the print exporting from Sanity printed material. What are some of the more creative things you've seen, your favorites, that people have built with Sanity that maybe have been surprising? I think with developer products, you always get surprised by your customers.

Magnus Hillestad (27:33):
That's a good question. There's probably a lot of things, also, that I haven't seen. Do you know the video layered app that's called mmhmm?

Michael Grinich (27:40):
Sure.

Magnus Hillestad (27:41):
Have you used the Electron app? That's Sanity.

Michael Grinich (27:44):
Really?

Magnus Hillestad (27:44):
Not, of course the Electron scaffolding, but all the content that comes in there, both the metadata and actually the content.

Michael Grinich (27:51):
So you're deep in the product, you're really deep in that.

Magnus Hillestad (27:54):
This is not the normals. Now we're talking about the cooler things, but it could be.

(27:58):
In effect, a lot of applications need some user interface for manipulating content that is going to be used in an application. So why shouldn't you have a CMS? Because historically CMS has been marketing software, but once you give people a database with a really flexible user interface, people go like, "Hmm, I could use this for a lot of things." It works as a PIM, it has a lot of the fundamentals of a DAM, but most importantly as an engineering platform to build on.

(28:25):
So, that is not surprising, but we don't market it as that. We don't run marketing on that, and that was because we were afraid of getting too different user groups that would pull the product in two different directions, and it'd be very difficult to manage. So be very focused on what works and continue doing that. I think you'll see us do more in the future, like Sanity as a content backend for an application. Another cool use case is those, what are you call these dolls that use for medical training?

Michael Grinich (28:51):
Sure.

Magnus Hillestad (28:52):
They are programmed with scenarios. We have a customer who built those scenarios on Sanity.

Michael Grinich (28:57):
Wow.

Magnus Hillestad (28:57):
There's not even a screen, as far as I know, but it's, again, it's just content or metadata. Content isn't just images and text. It's as much data and metadata, and it's really about having a real easy way to build workflows on that, and a really good way to structure that as data programmatically approachable, parsable, distributable to anywhere you want and that really works.

(29:22):
So we see most of our use on web, we see a lot on that on also applications. Anything like Volvo trucks is using us for some track application across... And there are a lot of those applications, but most of this is web. But then again, web isn't just a marketing website. It's a lot of applications, that is web applications need content, and that is a big market. There's often more engineers involved, you're more product minded. And if there are product people and engineers involved, they're not going to use a marketing tool that is a closed-source web interface with extension points to build that. They're just not, but they will use a software like ours.

Michael Grinich (30:00):
Last question for you. You guys have obviously done an incredible amount over the last six years growing the company, and even before that when you had the agency that became Sanity.

Magnus Hillestad (30:08):
We're just getting started, but thank you.

Michael Grinich (30:11):
What's a bit of advice you might give your previous self? Going back to previous Magnus living in Europe as you were starting to embark on this, I'm curious what advice you would give yourself, and maybe similar, what type of advice would you give the next generation of founders or entrepreneurs maybe listening to this podcast?

Magnus Hillestad (30:27):
This is an advice I got a couple of years ago, and I took it to heart, and then it was in a context of when you're a founder CEO and you have a management team, if you're letting someone go, or someone leaving, never use an interim, go and take that job. And I think that's an advice that I got at an appropriate time.

(30:47):
But if you translate that to the fact that early on when you're trying to build something, try to do it yourself and really try to understand what is the purpose of that job. Because there's so many great people out there, but there are also a lot of people who have experience in a job but are not good at it, and have experience in a job and do it ways that you may not think is the right way to do it, but eventually you probably need a function like that. You need something like that.

(31:15):
We iterate on a lot of different functions. I currently run product, I've been running the marketing team, and I did that, also, earlier. I don't think I spent enough time really thinking, okay, "Now I got to be the CMO." I have to take half of my time and be the stage-appropriate VP of marketing as we would have back then, and really learn what that job is, and figure out how does that then translate to who I need to hire into that job.

(31:42):
And I think especially for a first-time founder like myself, second time is probably easier, but for a first time founder that could enable you to skip some iterations that maybe take you a year because you hired wrong, because you didn't really understand. And when I say really, it's like really, really, really, because I thought I understood what I needed, but I probably didn't.

(32:04):
And then you hire something that isn't the fit, and then you lose a year, and you go like, "Ah, this was hard." Does product marketing have to be that hard? The answer is yes, but you could make it less hard, maybe, by really talking to other people who have done it, talk to people who are product marketers. But, I think the mistake I did in the early days, I was just talking to people who did it, I didn't try to go and do it myself always. On sales I did. That was easier. And I'm still on the first sales leader and we worked together now for three years. He's been working really well, so I was very lucky there. He's great. But, on other functions we've iterated, which is very normal, you need to iterate, don't expect to get it all right. Often, especially when you're new, you think you have something that kind of works, but something doesn't feel right, and then you change it and you get in someone else, it's like, "Holy, that was a different level. That's a new thing." That has happened so many times.

Michael Grinich (33:01):
Thanks again for joining us. This is really fantastic.

Magnus Hillestad (33:03):
Thank you for having me.

Michael Grinich (33:09):
You just listened to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving up market to serving enterprise customers.

(33:17):
Want to learn more about becoming enterprise ready? The WorkOS blog is full of tons of articles and guides outlining best practices for adding features like single sign-on, SCIM provisioning, and more to your app.

(33:30):
Also, make sure to subscribe to this podcast so you're first to hear about new episodes with more founders and product leads of fast-growing startups.

(33:38):
I'm Michael Grinich, founder of WorkOS. Thanks so much for listening and see you next time.