Moving from PLG to Enterprise Deals with AI

A lot of people think about pricing as a sales tool, but it's really product strategy. Pricing is never final, right? It's always iterative. Packaging is as much about the actual structure of the product itself and how you go to market with it as it is about designing adoption paths.

Daniel is— if you're building AI, you should know what Daniel's building. He's building an incredible product. He's going to talk about it. He's also got a really interesting journey with pricing and packaging, and he's gonna talk about what he has been learning as he's been building and monetizing Zep. So if you're interested in how to leverage limits to land and expand deals and to close enterprises, this is a good session.

What I'm actually gonna tell you about is all the mistakes we've made. So, oh, so I'm the founder of Zep. I am an engineer turned founder. Zepp is my second startup, second open-source startup as well. In between, interestingly, I have taken on marketing roles, so spent a lot of time doing product marketing, but also ML engineering and other technology leadership roles at the same time, and ended up doing corporate development and actually evaluating companies and their pricing models and the like. It's kind of stood me in good stead, not always, as I've built Zepp. And so what Zepp is, is a context engineering platform. We help agents solve big problems by ensuring that they have the right context available to them at the right time. When agents don't have the right context available to them, they tend to hallucinate and make up stuff, and that's just not great. And so with Zepp, you can build fast, accurate, and very personalized agents. And we started life— well, I'm gonna be talking to you about using limits to land and expand enterprise deals, and I'll be really using Zep as kind of the case study here. And my hot-ish take, 'cause we've heard a lot of really good hot takes today, is that pricing and packaging is both product strategy, and it's a sales tool. A lot of people think about pricing as a sales tool, but it's really product strategy. But I think a lot of speakers today have already spoken to that, so it's not much of a hot take. I went too late in the day, damn. So when we started Zip, our endgame was to build an enterprise software company. And we want to solve solve mission-critical problems for large customers who are building in this brave new world of agentic applications. But the problem is, like all startups, we started off with a PLG sales motion with a plan of less than $500 or several plans of less than $500. And bridging the gap between a PLG sales motion— well, PLG go-to-market— and a sales-driven enterprise sales go-to-market motion is challenging. So we started off with a PLG structure, pricing structure, and packaging, having a free plan with very generous limits on free. And, you know, it's great because it's low friction for developers. And our thinking here was, hey, you know, it's a land grab. We want as many developers using ZEP as possible. And cons, tons of low-quality signups. We have in Schematic today tens of thousands of accounts, and that's not always that useful. And so, you know, we came up, well, let's add some prepaid plans where you can pay us $99 or— $275 or $499 a month, and you get a certain number of credits. So you can load N units of something. And again, it's low friction, but the problem was it created anchoring as we started enterprise conversations. Start enterprise conversations, "Oh, but I see that you charge like $499 a month. Are you an enterprise software company?" or, "Hey, we're growing, but I don't see how it can go from $499 a month to several thousand dollars a year, or, you know, tens of thousands of dollars a year." And that anchoring is very, very painful, going from free to low-dollar monthly to $50,000, $100,000, $150,000 a year. Very challenging. And so, We moved to a way less generous free plan. Again, when you're selling business software, you don't have to give it away. The objective with the free plan really is to support experimentation, reduce some of the friction in engaging with your software. And thanks to Schematic building out a metered billing offering, which for AI developers is very familiar, right? They're very familiar with purchasing tokens, for example, as a utility-type product. And the nice thing about metered billing is it also avoids anchoring because your buyer understands, hey, you know, if I'm going to buy a million units from you, it's going to be a very large number. So I get how that pricing progresses from the smaller number to the bigger number. The other thing is that metered billing is very self-limiting at scale for larger enterprises. It becomes very expensive. And so there's a natural limit in terms of how larger companies are willing to grow on a metered billing plan. There's an expectation over time of some volume-based pricing. What this really has helped us do is build out an enterprise proposition that packages for using ZEPP at scale. A lot of the time when you think about enterprise offerings in infrastructure software or dev tools or other enterprise software type offerings, It's, well, we're gonna throw in the SOC 2 Type 2— access to our SOC 2 Type 2 documentation. We're gonna throw in signing a DPA with you or an SLA, et cetera. Now, of course, you put all of that in, and those are important because those are table stakes often for engaging with an enterprise, but this movement from metered billing to enterprise allows you to also start talking about volume-based pricing. Because they'll, they'll look at this very expensive metered billing price, and then it's easy to negotiate from that as volume scales up. Not only that, but the way we've approached enterprise pricing is there's a soft limit. You purchase a contracted amount from us, whether that's an annual contract amount or a monthly, on an annual contract, depends on how we structure it. But we're not gonna stop you going over Notionally. You can keep sending us your data. You can keep retrieving your data in the form that you need it in so that your agent can continue to add value to your customer's solution for your customers. But at some point or another, we're gonna go, hey, So you contracted at $15 million a month. You're now at $30. What are we gonna do about it? And I had exactly that conversation this morning. And these contracted limits allow you to really structure sales conversations. They're a natural opportunity to engage again with your prospect. And it's amazing when you're able to turn around to your prospect and say, "Okay, well, in the contract we said your overage would be X, but actually you've gone way over that. We can give you X minus 20%, but we want X— we want something else in return." Which is, for us, a customer I was chatting to earlier, unfortunately had talked us into a quarterly contract, which is just bullshit and terrible. So what we're getting in return is an annual contract. And so these limits that I've been talking about at both the meter billing level as well as enterprise, they're all negotiation surfaces. They're all opportunities to engage with the customer and start talking about how you can get a win-win off— something win-win in place. You know, there's always opportunity for you to increase the size of your— well, increase your revenue with the customer if they're a growing customer. And there's always opportunity for them to seek additional value from you. And so when we think about this move from free to metered billing and then to enterprise, the limits that we put in place be they limits around the type of functionality that we offer, the self-limiting pricing of metered billing, or the limits that we put in place with contracted usage for enterprise plans, they're really the connective tissue for building out a coherent cross-market pricing strategy. Where we can support both startups, high-growth startups, as well as larger enterprises. And it's very interesting because if you're working with the right startups, hopefully they turn into enterprises pretty quickly. And that's the conversation I had this morning, which was wonderful. Their growth is your growth. But, you know, another day, more problems. And so we've been conducting Customer interviews with folks who've signed up. We doubled the number of sign-ups we had August to July. And we wanted to know, why is our conversion rate not increased? And so, new day, more problems. Interviews with folks who did not convert. And we have perceived pricing issues. Our pricing is too complicated. It's— you know, we selected— we thought we were selecting clear, metrics, but it appears obfuscated to customers. It's difficult for them to understand when they're trying to size their usage how much they're gonna pay us. It's also difficult for them— you know, they see a very clear metric. We thought megabytes was pretty clear. But developers don't necessarily think in terms of how much text is this in megabytes. And so— It also just felt very expensive, megabytes, when we were so used to MacBook having 500 gigabyte or a terabyte hard drive. And now we're talking about megabytes. That's a very weird metric. So we're now thinking about moving to token-based pricing. And actually, after having listened to some of the conversations today, I think we may need to rethink this because maybe we need a blended pricing model where we have a base pricing plus some usage built into it. Because one of the issues that I did notice when implementing metered billing— and we knew going in it might be a risk— the bottom end of our business is now— rather than charging $99 or $200 or $375, it's now $2 or $3. And that's inherent to metered billing. And we need to fix that. So now I'm thinking that maybe we need to take some approaches here to solve that. Thinking about all these different experiments that we've run over time and how we've had to move thousands of customers between plans, Schematic has really accelerated this for us. It's allowed us to run very rapid pricing experiments. It's also allowed us to quickly sunset pricing plans and move existing customers to new plans, make it simple to grandfather pricing for a limited period of time, et cetera. So some of our learnings over the last while. Pricing is never final, right? It's always iterative. Packaging is as much about the actual structure the product itself and how you go to market with it, as it is about designing adoption paths. So how do you drive adoption between a free to metered to enterprise? And packaging needs to be implicit in that. And that limits— enable this kind of structured growth, enables growth from both within tiers as well as between tiers, like a meter billing plan and enterprise. And also very easy to get anchored in your pricing, which screws up positioning. And so if you have an advertised price on your website that is too low, it becomes very difficult to sell to an enterprise. So these are, you know, a few of our learnings from the last year of building Zepp. Thank you.

Question. Sorry. Yeah, uh, you mentioned acne as an issue, which makes sense, especially when you, you democratize the KIs. And then you were thinking about a hybrid model of like a base versus a usage-based or try to at least— Don't you think the anchoring would come back again?

Yeah, I think that's a risk.

Okay. And how are you guys doing price testing? Are you doing A/B or is it just mostly rolling it out and beginning it out?

Price testing for our meter billing plan was a lot about looking at our cost of service, a lot of looking at comparables. We don't have substitutes, really. I mean, we do. You have to build it yourself. But it's quite difficult to price that. So it really was comparables. And the comparables are around perceived value. So if developers appear to be deriving value for this price for X product, which is very similar in ICP and— close to our space, adjacent to our space, then maybe that price will work as well for us. And so it's not as scientific as having user interviews. For enterprise pricing, it's the comparables and has some deep linked.

As you know, ICP is primarily developers, and they're like trading on Fyn Glover. Responding to surveys and all that? How did you do pricing?

Well, we haven't done surveys. Our ICP isn't necessarily a developer. They're actually VP of Engineering folks, CTOs, et cetera, with the user being a developer. But still, they don't like filling in surveys. We're trying to run interviews right now. It's not that much fun. Any other questions? Other questions for Daniel?

I like sort of the challenge on the converting pieces, kind of the awkward element where people are saying, oh, I need this, but haven't used it to seem value, and are doing the cost calculation to sort of— is that your command? But his point around like— People can go in directions, but if they're trying to optimize before they see what they can take, it's harder to pull back and have a real conversation around it.

Yeah.

They're not like you. Yeah.

Question here was, how much— can I just paraphrase you a little bit here? Yeah. So how much is a conversion inhibited by time to value, where there needs to be some onboarding? People just don't use it adequately to see value. Okay.

You mentioned you had a lot of signups.

Yes.

They were computing the pricing in their minds and saying, oh, it's not for us.

Yeah. Yeah. And they hadn't actually seen value.

Yeah. Yeah.

Or maybe they just were like, oh, it's too expensive. I'm not going to try.

Yeah. Yeah. So there are a couple of things that we're doing to address that. In fact, we started a multi-month initiative called Time to Wow, where we recognized that Zep had grown into a very sophisticated enterprise product, which made it difficult for developers to immediately see value from. So how do we now simplify it while still retaining the capabilities of the broader platform? And so we spent a lot of time with that. And some of that is perception as well. So how do we make things look sexy and pretty from the get-go, wow you with very impressive-looking knowledge graphs and cool walkthroughs, et cetera? Because we know that developers actually, they have to code something. They have to find some data to send to you. They have to think through what their problem is and try a prototype solving that.. And that's a much higher level of effort than many other products. And as a consequence, thinking about ways to just sell it to them before they've even built something. Any other questions?

Yeah. So tell me about what you're running into now with the billing threshold stuff. At the lower tier, what happens?

Yeah. So we have an unpaid bill problem with metered billing. We have folks run up $200, $300 bills and disappear. They delete the Stripe link connection and a bunch of other stuff. So that's on one end. And on the other hand, you have people using cards, and they're just— you have a dunning issue where they don't have credit on their cards. And it's a growing problem for us. So we went to the schematic folks and had a conversation with Gio about, well, I want to almost immediately charge a card. So rather than— 'Cause we have these thousands of meter billing sign-ups a month. And what's happening is we've done a good job of basically incentivizing people to put their credit card down by giving you a little bit extra free if you put your card in versus the free account. So you can go from the free plan to the meter billing plan. You get a little bit extra free. And so lots of people put credit cards in. But what we want to now start doing is if you get to $10 or $20 of usage, We want to bill you immediately. We want to make sure that your card is okay so we can start to terminate your account if we can't bill you before it runs up to a few hundred dollars. Is that the answer you were looking for there? Yeah, it's a good answer. Yeah, and Geo is very responsive, so thank you for that.

It's launched actually. It's out there. Oh, you can do it now? Oh, I did.

We haven't configured it, I don't think.

I don't think so, but it's ready to go.

That's good.

Yeah.

All right. Thank you, everybody.