The Power of Clear Pricing and Repeatable Processes

Michael Grinich (00:02):

Welcome to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving upmarket to serving enterprise customers. I'm your host, Michael Grinich. I'm the founder of WorkOS, which is a platform that helps developers quickly shift common enterprise features like Single Sign-On. 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.

Today I'm joined by Zee Yoonas, former CRO of Netlify and, I'm excited to announce, has just joined WorkOS as our COO. Before Netlify, Zee held business leadership roles at Sift Science, Twilio and this little upstart you may have heard of called AWS. Netlify likely needs no introduction to this audience. It's a really well known developer platform for building dynamic websites, e-commerce stores, web applications, and grown in mass popularity over the last few years. Zee spent more than four years there during a period of their explosive growth leading go-to-market strategy and execution and really scaling their business into what we know it as today. We'll dig into Netlify's journey as well as WorkOS' roadmap ahead in this episode of Crossing the Enterprise Chasm. Zee, welcome to the podcast.

‍

Zee Yoonas (01:24):

Thank you Michael. Glad to be here.

‍

Michael Grinich (01:27):

So take us back to when you started at Netlify. Back in 2018, the company was just a few years old. I think it was growing mostly with this bottom up freemium motion. Describe the state of the business then and when you came in, what you saw.

‍

Zee Yoonas (01:41):

Probably the best way to characterize Netlify at the time was: they had a fantastic product, they had fantastic early traction, but we didn't yet have a fantastic business. That was the part that we needed to figure out. But in terms of the raw ingredients to build a great business, a lot of those were there. And so really Netlify, like a lot of earlier stage PLG businesses, had very healthy top-funnel traction, had an early set of customers and users that loved the product. They were very eager to share feedback on the product and they, in essence, formed the foundation for guiding what would eventually become a very good business. That was the early entry stage when I came into the organization.

‍

Michael Grinich (02:31):

Was there a sales team? What did that look like? What was the buying motion for customers?

‍

Zee Yoonas (02:36):

We did have an early sales team, but what I'd say is the bulk of the business strategy at the time was, "Hey, we have this freemium oriented product." A lot of developers, a lot of customers were using the free aspect of it at the time. We hadn't quite figured out what were the mechanisms. I'm a big fan of this notion called ‘fair exchange of value’. And so really what that's about is, how do you match your pricing mechanisms in a manner that is fair for you as the business, as well as compelling to the end customer. So we hadn't quite figured out our fair exchange of value metrics for heavier users of the platform.

What we in essence had was, we had a free product. We had a very low price point on the initial swipe your credit card scenario, and then anything else that required more complexity, more scale, more engagement, we in essence asked those type of leads to talk to our sales team. And so in the early days, I'd say the operating motion was characterized by probably more of a business development type engagement where you're a little bit nimble. You're doing a lot of learning, You're doing a lot of hypothesis testing, all with the goal of figuring out what would be one of your fair exchange of value could look like and hopefully that gives you foundation to then do things at a broader skip.

‍

Michael Grinich (03:57):

We had Chris on a previous episode of this podcast, one of the founders of Netlify. Matt's also a friend of mine. I'm curious if you can talk about the culture of Netlify at that time. I think a lot of businesses are like this where they get that initial traction, the bottom up motion and the momentum that shows that they have product market fit and they're looking to transition to really activate the business, really build the go-to market function. Obviously there's a lot of things you change around pricing or packaging or hiring a sales team, et cetera. But culturally, an organization also has to change when this happens. Where was Netlify and how did it evolve in that first year as you came on board and things changed?

‍

Zee Yoonas (04:36):

The healthiest part of our early culture was a maniacal focus on the web developer. That was the primary persona we cared about. Every morning, we woke up thinking about how to improve the life of the web developer and ultimately the web development team. So there's an interesting balance that needs to play out as you start to commercialize, which is, hey, we can have a maniacal focus on the end customer, in this case the web developer, but now how do we start to introduce a more balanced perspective on ourselves, Netlify as a business? And what are the things we need to do to create a more healthy economic situation for us? And once we can get to that fair exchange of value to where you can still delight a customer, still delight your end customer, your developer, but also build a fantastic business.

So I think the thing we had to introduce was operating systems, operating models, feedback loops internally that allowed us to measure our success on top line, on traction with certain customer segments that we believed would be more monetizable over the long run. And so we had to start to introduce some muscle there. And so that transition, it's one that's necessary, but it's one that takes time. It doesn't happen overnight. It's one that you have to start to hire people who have that competency who can bring that perspective into your organization. And leadership teams also need to think about how do I reorient some of my thinking to be more inclusive of some of the business side of the equation?

‍

Michael Grinich (06:03):

Big changes over a big amount of time, I guess, a long amount of time.

‍

Zee Yoonas (06:07):

Well, I'd say incremental changes. You don't want to introduce something very drastic. Let's just give an example. So let's say you have a PLG, long tail self-serve product that customers can spend a few thousand dollars a month with. It's a fairly common situation. First enterprise motions, you probably don't want to orient seven figure type deals as your first few motions. You want to figure out how do I go from a few thousand dollars a month to potentially mid to high six figures as you start to build those first few phases and then ultimately build the mechanisms to go much bigger than that. And so the idea is incremental steps, small steps. You slowly bring a more balanced perspective into a business as you start to think about commercializing.

‍

Michael Grinich (06:51):

I want to ask you about pricing. I remember in a chat when we met many months ago. You had mentioned that Netlify changed its pricing a lot over that time as you were evolving. Tell me about the first pricing change that you made or you thought about when you were at the company, because you were mentioning there was this self-serve credit card and then everyone else was, kind of, “talk to sales”. How did you navigate the very first one as you were trying to discover how to package the product and really align the pricing with the value for those bigger customers?

‍

Zee Yoonas (07:21):

Pricing is important to have a hypothesis. You test the hypothesis and you learn. So early, early days of Netlify, I think I certainly brought in some preconceived notions on what could work for our business based on my experience at AWS and Twilio. One of those preconceived notions was the idea of, "Hey, we're a developer platform, we can do utility billing and we can do utility billing around the context of raw infrastructure use." So you think in the context of a web application, it's like how much bandwidth are you using, how much storage are you using, et cetera? It turns out that that pricing hypothesis for Netlify’s business at the time was actually a disconnect from the value customers were getting from our platform. And what I mean by that is at the end of the day, Netlify, our north star was, we were a productivity tool for developers. And when you think about how do you pay for productivity or how do you justify the investments against a productivity vendor, it's less oriented around raw infrastructure units as relative to a per seat model.

And so we went through a few iterations of this, but ultimately what we realized is our early version of pricing, which was exclusively usage based, off of basically raw compute usage, wasn't going to be the right long-term fit for us. It wasn't the right long-term fit for us because one, it wouldn't allow us to create that balanced fair exchange of value. But then also it wasn't the right fit for the customers in that it distracted them from what the core value of our service was. It got them more thinking around underlying infrastructure as opposed to the big picture, which is productivity for their teams. And so that's one of the key learnings when you think about pricing. Pricing is just not a way for you to figure out how to monetize your business. It's also a way for you to signal to your target customers where you believe your value is. And that's something we certainly learned early days at Netlify and if you look at the model today, there's definitely a more balanced view, which is around the productivity of the developer.

‍

Michael Grinich (09:19):

Yeah, it sounds like what you're saying is that pricing really is this holistic piece of how you designed the product value and the way it fits into the business function, not just an afterthought. I think a lot of founders think it's kind of build the right product and then we'll just slap some price on it and hope it works out.

‍

Zee Yoonas (09:35):

Yeah, yeah, it's an absolutely integral part of what you might define as your product experience. I think most folks, this will probably resonate with them, if you put a pricing page up on your website, it tends to be one of the highest click through pages, the most visited pages. And you got to think about that. It's like, wait, why aren’t my customers going to the product page more than the pricing page? Because folks want to know at the end of the day, what could this thing cost if I use it? And so you got to be mindful of like, "Hey, what is the signal you're sending through that pricing page? What is the signal you're sending through the ways you choose to price?"

‍

Michael Grinich (10:09):

So a bit of a spicy question around that. What about pricing pages that say contact us? That's pretty common for enterprise where you don't have price transparency and you really don't signal anything.

‍

Zee Yoonas (10:20):

Healthy businesses are ones where you have things that can be repeated. So when you think about if you have a scaled out sales organization, you hopefully aren't in a situation where you're doing custom pricing per customer, that's a very difficult thing to scale. So “contact us” is very natural. There will be things, “contact us” should be a signal by the way, to the type of customer segment or to the type of buyer that is looking for more handholding. So I think the “contact us” in itself is a very healthy thing because most of the world is not going to be in a situation where they just sign up and immediately use your product.

They're going to want to speak to a human, do an evaluation, understand, make sure that they're working and engaging with an expert of the area that they're exploring. So a lot of value in having that “contact us” process, and that's a lot how upmarket tends to buy. But it's important when you do that engagement, that high touch engagement, that you have a very clear value prop, a very clear path for different customer profiles and what they could be buying that you have repeatability on your pricing, as well as a well-built out sales process and customer engagement process. But that's a journey, right? Maybe day one, “contact us” is a way for you to do that and in that effort, figure out what can be scaled, test your hypothesis.

‍

Michael Grinich (11:39):

Yeah. Do those things that don't scale. Yeah.

‍

Zee Yoonas (11:41):

Right. And then over time you “contact us”. Hopefully you can bring more transparency into your pricing model, but then “contact us” is more of a way for you to engage with customers who need more hand-holding.

‍

Michael Grinich (11:51):

I could talk about pricing for hours with you, you and others. We could do an entire podcast series on it, but I'm going to move on so we don't get trapped in it. I want to go back in time a little bit. 15 years ago, a younger Zee, joining this crazy idea of a company that sells books that started selling compute, met AWS with this product called EC2, which has done pretty well. Tell us the story of that, your role in that early on, what that was like to build as a business. Today, that's obviously a tremendous company and really fundamental infrastructure that a huge amount of cloud technology is built on. At the time, it was an outlandish idea from a company that didn't seem like an infrastructure technology company in that way. Tell us that story.

‍

Zee Yoonas (12:34):

My personal journey at AWS actually starts with the experiences I had as a field rep at IBM. IBM, very classically known as a traditional enterprise top-down seller. I spent a few years in that business, did fairly well. But what I realized is that the way most businesses were buying IT at the time was fundamentally broken. They'd spend 12 months evaluating a vendor. Once they selected a vendor, they'd spend 24 months implementing and then there might be a 30% in the best case scenario of success, for most enterprise organizations. And you just think about all the amount of time and money that's wasted in that process. I thought there had to be a better way to offer mission-critical software infrastructure to businesses. And so at the time AWS had two services in market, Mech Turk and S3, Simple Storage Service. And so while those products were very early at the time, the promise of what they offered: transparency, ease of access, developer friendliness, volume-based pricing. These were attributes that resonated with me.

And so the promise of building a very interesting business behind that was too good to pass up. So I ended up joining AWS and then ultimately ended up leading business development for EC2. Now within AWS, the things to learn, the things to keep in mind is, yes, it did sound crazy at the time, but this is the value of putting something that's compelling into the marketplace because developers at the end of the day are doers. They will get past the optics or maybe any preconceived notions and they'll look at the substance of what you're offering. And the substance of what AWS was offering was extremely compelling, especially for a class of businesses that historically did not have massive budget pools, startups, that's obviously where AWS got their start. But then the name of the game was how do you quickly scale with your fastest growing customers and start to move upmarket? So that was the rest of the journey there.

‍

Michael Grinich (14:38):

What did that business model look like early on? Was it mostly focused on startups? Like that idea of selling really Elastic Compute. It's in the name, is fundamentally different than racking machines and having to actually have infrastructure hardware that you're appreciating over time. It's a totally different model.

‍

Zee Yoonas (14:57):

So I think there was a couple things. One, we were maniacally focused on serving the needs of our neediest and most challenging customers of the time. And those were really fast-growing startups. I remember back in the day, one of the breakout use cases for cloud computing was Animoto and Animoto went viral around the time Facebook first released their developer platform. And that was the aha moment where we realized, "Hey, we could scale a customer to thousands of servers very quickly." That wasn't something that was done easily. It took a lot of work, operational work behind the scenes. It earned us the right to go into upmarket conversations, larger enterprise conversations, and then we could have a more substantive discussion beyond the promise of the business model, which was we have proven we can, in a high performant way, in a reliable way, serve customers that need thousands of servers being provisioned overnight, as an example. And let's talk about how that type of scenario could match your business. And so the way I think about moving upmarket is you got to earn the right a little bit before you just start aggressively attacking upmarket segments. And the way you earn that right is by maniacally serving and addressing your existing customer base really well. And then really looking for those outlier scenarios that you can use to leverage into the next market segment up.

‍

Michael Grinich (16:16):

For those customers, the bigger ones, did you find it was more about them saving money and getting this elastic resource and just, "Hey, we don't have to have machines in the basement anymore." Or were you selling this new idea? It feels like AWS is transformative in really this totally different way of thinking about compute and IT, not just cheaper, not just faster or something, but really a different conception of it. How did that get into the sales? Was that in the sales process early on or did that come later, or how did that fit in?

‍

Zee Yoonas (16:49):

So there's probably a couple things to keep in mind. So one is there's the promise of what you can do with the platform. So you think about the world of architect and cloud native applications and what does that mean? It means like, hey, you build a system, you architect your software in a way that's resilient to any single instance failing, as an example. That's an example of cloud native application architecture. While that might be the promise, the reality is, to get started, to help customers start to see immediate value, there's just a much more pragmatic way to start your cloud journey, which is, "Hey, maybe I need a server. I need three servers to run my basic three tiered web application architecture. Let me just do a lift and shift." And they're really just optimizing for the ease of access and potentially the promise of being able to provision very quickly. That's a very pragmatic start.

But then once you start there, then over time we have the ability to work with those type of customers and we have the ability to help customers do things that are more cloud native. How do you fully optimize building things from scratch for the services we had at the time? It's just an important lesson, I think for businesses as they think about scaling. You can have the promise of your platform that in the fullness of time will be extremely compelling. But how you start today and how you execute today or how you execute over the near term, you got to sometimes be a little bit more pragmatic. Maybe a customer's not going to be using us in the full context of what they could be doing, but it gives us a valuable user, it gives us valuable learning, it gives us valuable revenue, which you can start there. So it's about stepwise building towards the full promise.

‍

Michael Grinich (18:24):

So have that big future in mind. But it sounds like you're building a bridge to get there with that pragmatic... It's one of the things I loved about AWS. Nowadays, it's all serverless and lambdas and all this stuff, but at the beginning, it's just a server. If you've had a server before, you know exactly what this is.

‍

Zee Yoonas (18:39):

Exactly. In the early days, it didn't require, for example, we weren't necessarily creating a new category. You could explain to an engineer like, "Hey, where's your server today?" They'd say, "Oh, it's in our data center in Austin, Texas." I'd say, "Okay. Well, what if that server were on the East Coast? Would it make much difference?" Like, "No, I know how to use a server." "Okay, great, but what happens if you could provision that server in three seconds with a single API call as opposed to filing a ticket waiting three days?" They're like, "Oh, okay. Sounds promising." And that's how you start.

‍

Michael Grinich (19:11):

Last question for you before we wrap up. A lot of people I think listening to this podcast are earlier stage founders or people building product, going through that transformation moving upmarket. What advice would you give them based on your experience really in cloud infrastructure and dev tools in the last 15 years. For people just starting to develop their business models and think about how to scale their business, what advice would you give that audience?

‍

Zee Yoonas (19:35):

First and foremost, have a very clear picture of who the customer is you want to serve. And when I talk about customer, think about the human and what that human does day to day. Once you have clarity on who that human is you're serving, then you can have a maniacal focus on improving their life and it becomes very personal at a point. And if you can improve their life, then you're going to have at least a much more obvious path on how you can improve your service, how you can message your service, how you can sell your service because you have a very concrete example of one person you're trying to please. Now, if you've chosen that persona well, if you've chosen that customer well then ideally there's going to be hundreds if not thousands, if not tens of thousands of those type of people in the world that you can then continue to build for, get beyond the broad, top down market sizing, I'm going to attack this opportunity because the spreadsheet says it can be a compelling opportunity. It's like, we try to narrow it down, make it a very human equation, and focus on that human to start and then iterate quickly.

‍

Michael Grinich (20:39):

Zee, I'm totally thrilled to have you at WorkOS, to have you have joined the company to build a business for today and beyond. And thanks so much for joining today to share some of these insights with our audience.

‍

Zee Yoonas (20:51):

Thrilled to be on the team, Michael, and looking forward to the weeks, months, and years ahead.

‍

Michael Grinich (21:00):

You just listened to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving upmarket to serving enterprise customers. 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. 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. I'm Michael Grinich, founder of WorkOS. Thanks so much for listening and see you next time.

‍