Product pitfalls from 0 customers to the messy middle and IPO — Eric Berg on Okta, Intel & Fauna

[00:00:00] Where a lot of people use the phrase, product market fit. I think you really have to think about it and expanded perspective and think about product market sales or product market go to market fit because it's through that end-to-end thread. If you will, from what you build to how you market it, how you sell, it really defines the company or the motion that you build.

And when you pull on that thread and you look at product and go to market and the market and the target customer, you can see completely different companies being built depending on which one of those threads they're pulling on.

[00:00:35] Welcome to in depth, a new show that surfaces tactical advice, bounders and startup leaders need to grow their teams. Their companies and themselves. I'm Brett Berson, a partner at first round, and we're a venture capital firm that helps startups like notion, roadblocks, Uber, and square tackle company building firsts through over 400 interviews on the review.

We've shared standout company, building advice, the kind that comes from those willing to skip the talking points and go deeper into not just what to do, but how to do it with our new podcast. In-depth you can listen into these deeper conversations every single week. Learn more and subscribe today@firstround.com

today's episode of in-depth. I am thrilled to be joined by Eric Berg. Eric is the CEO of fauna. Which is an adaptive operational database platform in joining fauna as its CEO in the summer of 2020, he brought a wealth of experience as a product leader. Most recently, he was the chief product officer at Okta scaling the company from 10 employees and zero customers to its eventual IPO in 2017.

He started his career in product at Intel, working under the legendary Andy Grove, as well as a five-year stint as a product leader at Microsoft in today's conversation. She opens up his executive playbook as he weaves together each of those experiences. And we cover a lot of ground along the way. We start by talking about early, go to market lessons and the keys to honing in on an ICP to get Okta off the ground.

He also dives into the often maligned messy middle, particularly when it comes to moving up market and developing a pricing and packaging model that when done well. It takes a company to new Heights. We then switched gears and discuss more broadly about team building and company building, particularly the cultural lessons that stick with Eric from his time at each stop in his career.

His biggest include hiring folks up and down the org chart with the right ego to talent ratio and the tactical steps he takes to implement a disagree and commit value. So it's not just a long forgotten motto. Finally, we touch on the biggest surprises as he approaches one year of sitting in the CEO seat for the very first time today's conversation is a must listen to particularly for product folks, as well as others who want to more deeply understand the trade-offs that nearly every great company faces on the path to scale.

I really hope you enjoy this episode and now conversation with Eric. Well, Eric, we are so thrilled to have you. Thanks for joining us. Thanks for having me. So the place I wanted to start is around figuring out early, go to market going maybe from zero to one customers, one to 10, 10 to a hundred. And I'm curious, what are some of the frameworks or things that you've learned around getting go to market right.

[00:03:44] Yeah, it's a great topic. And when I spent a lot of time talking to companies about today at the highest level where I'll start with that is I think the most important thing is to think about this as an integrated connected strategy. Meaning I think sometimes I see people think about product market fit, separate from go to market.

And it's certainly been my learning that. Having to think about what you're building, who you're building it for and how they buy is really critical. Especially early on. I think as product people and technical people, sometimes you might get oriented around the fact that, Hey, if I build it, they will come and then you can pick the go to market model that you want.

But in fact, it's really important to understand what is the problem you're solving? How is that purchase of your product made and therefore what your go to market muscle needs to be. So where it starts really, I think is a, is an understanding of the segmenting in your market for all early customers, typically for great businesses.

There's huge opportunities. The trick is where do I start? And so a framework for getting some way to segment the market that really helps inform and focus both. What do I build? And then from a sales and marketing perspective, who do I target? So I think that's the most important thing first, which is really developing some level of segmentation of your customer market.

I'll give it a great example. You know, early on at Okta, we were looking for customers that had three or more SAS applications, because that was a great indicator, that they would be a great target for us from a product perspective. And that also informed how we looked at the market in terms of it probably wasn't relevant and good for us to go after large enterprises, that they might've had a couple applications in the cloud, but relative to their overall infrastructure, it wasn't very important versus sort of smaller mid-sized businesses who had made big investments in the cloud.

And so that also informed what we built and thought about their infrastructure, their environment. What we'd built from a product perspective. And then for our sales reps, it gave them a way to think about discovery, questions up front. They would ask a customer, Hey, have you invested in identity system before?

How many cloud applications you have, how strategic is cloud to your it strategy going forward. And so it worked left to right, both on how you thought about building the product, as well as how you would target it from a sales perspective. And then even in the marketing area, we were always looking for events or opportunities or lists that would sort of approximate to that view of who's a customer that has three to four SAS applications or greater.

So I think the first start is around that segmentation model. And then as I mentioned, I think it's taking that segmentation and that customer profile. What a lot of people call the ICP, the ideal customer profile, and then orienting both what you're building. And how you're selling around that. And then obviously as anyone grows over time, you get that one foothold and then you expand over time to various different segments and various different types of users.

[00:06:37] level framing to start the discussion. I'm curious how you think about really zeroing in, on what your ICP should be. And how narrow or broad that is in the early days. And then to your point, the interplay between product and sales for those first few customers or the thinking around, are we going to try to do something a little bit more bottoms up or tops down or getting the right go to market motion to fit that ICP?

[00:07:09] other thoughts on that? I think best way to do it is provide a very practical, real world example. I'll pick Okta again. It's very fresh in my mind in terms of what we went through back in 2010. So we built a very easy to use product. Almost assuming that our business would be. A little bit more bottoms up that people would be running their credit card and, and starting to use the product and grow.

We had a free trial from very, very early on. And so that's how we oriented in terms of what we build, assuming that we would have a go to market like that. And then I mentioned who our ideal customer profile was. Those. Small to mid-sized businesses who were heavily focused on cloud applications, but the real learning for us became that when you thought about the problem that we solve for that initial use case, right, because it's always about that initial use case and what are people buying you for?

We would be going into a customer who was taking their identities and moving those into the public cloud, which was in 2010, was a relatively risky proposition. And at the same time, because we were changing the behavior of every employee in the organization, and they were going to a different location to get access to their SAS applications.

All of a sudden that was a very disruptive purchase and rollout from an organizational standpoint, which meant that the decision process and therefore our sales and go to market process was more complex. It was more of a sophisticated, you know, sort of security cell, if you will. And so for us, that meant that we had to change in terms of what we thought about the skillset.

Of the sellers early on that we had to have in order to navigate that kind of a sale. And so I think that's a great example of you can intend to build one thing, but when you get focused on that initial entry point and the problem that you're solving, you really have to understand and orient yourself around who is that buyer.

How are they buying your product and what is that decision making process? And then, and then that can then tie to a go to market motion. I'll take fauna is another example where I am today. It's very different. We're targeted developers who are out looking and building new applications and looking for a new database.

And so these developers are very, hands-on, they're very technical in nature. They don't want someone to talk to them. They want to have great documentation, great use cases, great examples. They want to see people in their community who have evaluated and use this technology as proof points. And so that go to market motion.

And what we're doing from a sales and marketing perspective is very different because the way this is consumed and who consumes it, and the decisions that they make are very different. 

[00:09:43] That's a great illustration. So a related question is when things aren't clicking together, do you have thoughts on how you diagnose, if it's a product problem.

[00:09:53] market problem at some level. There's a question about how fungible one versus the other is, or how easy it is to change. Like for example, in the Okta case, what we had built around that use case, and we had really good validation from lots and lots of early prospects, that this was a pain point that a lot of people had about using multiple SAS applications and having issues with single sign on and identity.

So we had really good, strong validation that okay. Solving that problem was something that was a high pain point for people and that they were looking for a solution to solve it. So that part we were pretty firm on. And so I think we felt good about the product that we had built on the go-to-market market side.

As I mentioned, there was just a different way for that to be purchased. And so we were able to adjust because that was a skillset difference and that was quote, unquote, easier to change. Then obviously it would have been to just go, try to solve a completely different problem and build a different product.

So I think it depends on which is more flexible in which you might have more conviction around. Typically I see in these early stage companies, that conviction is around hopefully a problem that you're really solving and you're convicted that that's a problem that people have and they're willing to pay money for it.

And so then it becomes a matter of turning the tables the other direction and saying, okay, now that I solved that problem, how does an enterprise or a, or a consumer discover that tool and that solution and what is their buying process and how do I map to that? What are your thoughts 

[00:11:20] on you sort of mentioned this a little bit earlier, but how you think about expanding the ICP over time?

How long should a given ICP last. If there's only five people that fit the ICP, unless it's super, super, super high-end enterprise software, that's challenging. And then if your ICP is too broad, it's not really an ICP. And then maybe you exploit that for a year or two, and then you move out and sort of, what is the process ultimately 

[00:11:47] locally, you know, when it comes to businesses and markets, especially in B2B, SAS and B2B software, where I've spent majority of my career, it's certainly easier.

To build a more scalable business and to get started on a problem that a large number of smaller customers have because you tend to find that their requirements are more consistent and it's, it's easier for you to hone in on a smaller feature set that works for a larger number of people. And so if you're product centric, which a lot of these organizations are, it becomes easier to build something that will work for a large number of people.

And then as you start to expand beyond that initial ICP, the good news is in a lot of cases, these markets are sort of like layers of an onion where the initial customer profile that you have in that use case and pain point you solve for them is also found in another customer segment. But then there are some additional requirements above and beyond that.

And so if you start in call it your ICP one, and then you move to ICP two. And in ICP two, they both have the requirements of one plus some additional ones. Then it gives you a more balanced way to expand. And it typically gives you even an initial use case that you can solve and sell into. And that second ideal customer profile.

I'll give you a very specific example. Again, going to follow a thread on Okta. I mentioned that first ideal customer profile. Of someone who is strategically investing in SAS, SMB sort of customer that's heavily involved in that. So as we expanded into larger enterprises, you still had a set that use case was still relevant, where they were growing their SAS portfolio.

And we were integrating into their corporate directory to extend the capability of their identity system, to those SAS applications. And so that initial use case was very familiar and very similar to our ideal customer profile that we started with. And so happened as we expanded our relationship with those customers.

Right? Then there were a lot of additional requirements that were around the size and the complexity in their environment around integrating to more on-premise resources, et cetera, that were unique to those larger enterprises. But you could both start. With an initial value proposition, because you had built up a product that solved a particular problem very well.

And then you could incrementally expand into it as you built out those relationships with that new ideal customer profile. Can you 

[00:14:20] share a little bit, and maybe we can just keep using Okta as a case study how that early product and feature set loop worked with these early customers and how you chose what to build and what order, even if you have a pretty narrow ICP, you get a lot of different feedback about a lot of different features.

You have potential customers that are at your doorstep, and they say, if you build this, we'll do it, but then you build it and they don't do it. And there's a lot of nuance to that. I'm curious if you frameworks or ways that you thought about what to build in what order, or was it more 

[00:14:54] intuition based. To get very specific.

Like I still remember back to the first customer that we deployed to. It was here in the bay area called live ops and it was a 300 person company at the time. And it literally was as specific as we had built a fairly robust Corpus of our product at that point in time. But it got to the point of, Hey, if you build these three or four features, we will go live on this certain date.

Certainly you don't want to be building features that are specific to a particular customer. But at that point we had talked to so many prospects. We had a very good sense that the requirements that they had in their particular use case to roll out were ones that were representative of a larger set of customers.

So we felt very confident that, Hey, if we built these, not only would this enable this particular customer to be able to go live, but would be representative. So I think that's something that's very important early on is balancing that of there are going to be things that you're going to build, quote, unquote, specifically for customers to get them live and to roll them out.

But as long as you're constantly interacting, you know, through your sales channel or marketing or customer advisory boards to have a good sense of what the. Larger representation of your ICP needs. And even if that means you might sequence some feature and you might do it sooner than you maybe had planned to in your roadmap, as long as you're confident that it's going to serve the larger market, then I think that makes a lot of sense.

Then I'll give you a counter example or sample where we had to say no is we had a very large social networking company come to us and was very interested in what we were doing. But their primary use case was probably 18 to 24 months down. Uh, our roadmap in terms of something that we would be building eventually, but was not where the rest of our ICP was focused and where we really felt we could get more scale from a go-to-market perspective on.

And so. We turned that company down and that was hard to do. We were a very small company and we said no to them. That would have been a great company with a great logo. And we could have shifted our roadmap around completely and made them successful. But we had to balance that with the fact that, Hey, that's not where we're focused right now.

That's not where the larger need in our ICP is. And we'll get there eventually, but the better path for us from a company perspective is to stay focused in this area. So when things are too far off and you don't feel that they're representative of what you're seeing from a larger market perspective, then it doesn't make sense to make that trade off.

And that goes back to my earlier statement about, I think if you, um, in general, it's certainly an enterprise markets, you'll see a more consistent set of requirements across SMB or mid-market companies than you will. If you're dealing with five or six super large global enterprises, it's more likely that their requirements will be very diverging.

Whereas if you had five or six, uh, 1000 to 5,000 person organizations, their requirements are probably much more consistent. And so that's, it's easier to build a more consistent product targeting a segment like that early on. So in that 

[00:18:01] case, you know, you talked a little bit about this first. Customer and willingness to build a few things that were obviously going to be built for your second, third, fifth, seventh customer.

And then you talked about somebody that was asking for something that you were going to build, but a couple of years later. And so you said, no. Can you share a little bit more about that in-between phase? And so when you think about customer to 10 20, and when you're designing and building out your product roadmap, is it like the most requested thing across the most number of early customers gets prioritized and we're building that.

Or what sort of your framework for figuring out everything past the first or second customer, but maybe in that first 12 months and first 20 customers kind of phase. 

[00:18:46] Yeah, it's interesting, but I will definitely say it's an art, not a science. I think that's, it's one of the fine arts of product management at these early stage companies.

But in particular, one of the great things about a SAS company and a SAS business is you are very tightly coupled to your customer success. And so you, and especially when you are rapidly growing venture backed startup, you have two very strong input channels, right? You have one, which is your sales organization in terms of net new customer acquisition.

And so again, if you're in a, you know, a business that is targeting a larger number of smaller customers, you have a lot of data points, right? Because you, you have reps talking to. Multiple customers. And so you start to see a real pattern there. And at the same time, because you're a SAS business and for Okta, as an example, our growth was dependent on the number of users and applications that a person would deploy with the service.

And so we had a very acute focus on making sure that those folks were successful, got deployed youth doctor more broadly. And so you have another set of inputs there, which is what are the things that customers need 30, 60, 90 days into their deployment to use more of Okta and to go broader. So I think the number one thing is just making sure that you have.

Good channels of feedback from both the front end, I E new customer acquisition, as well as customer success. And it's a fine balance obviously early on in a company's life cycle. If you just look at the practical reality, the net new revenue is usually much more than your renewals business, obviously is the life cycle of the company expands and the installed base of your customers.

Increases then that renewal factor, which is why we all love SAS businesses looks that layered cake and the bottom of that layer looks more and more attractive and becomes more and more significant. And so you've got to be thinking about that as a business centric product person is how do I then use that feedback that I'm getting about new customer acquisition versus customer renewals, and how do I weight that feedback if you will, it's going to be weighted more probably to, to new customer acquisition early on.

And then that balance flips a little bit more to customer success and renewals, you know, as you go forward, but it's always a balance. One of the things you mentioned 

[00:21:10] a few minutes ago is this idea of acute focus on customer success. Can you share more by what you mean by that? And maybe kind of give us some examples or some of the things that you did that felt maybe weird or strange if other people were looking at it, but.

When you really talk about instantiating, this acute focus on customer success, I assume it must mean more than we're going to have some customer success folks that are helping onboard new customers. 

[00:21:36] It means early from top to bottom from the executive team on down as we onboard these customers. And ultimately in, in every situation, there's always some, it's not that someone made a mistake or forgot to ask something, but ultimately there's always some situation where in order to make this customer successful, there was some integration that wasn't known about, or there was some way that the product integrates with their environment that was unforeseen.

Or something that's unique about their situation or they're pushing the product in some way that we didn't anticipate. And we very much had a philosophy at Okta that we were going to drop everything and prioritize that, and let's go make those customers successful because their initial success and building off of that was hugely useful for us from a market perspective, because there's nothing more powerful than your customers out there talking about what, the value that they've received from your product.

And so at some level that's even more important than new features because you want to fill in all the gaps and the cracks that are really necessary to make those customers successful. So it was that the DNA that we had very early on and then the shift that's interesting for product leaders and CEOs alike to think about.

Is, we always would talk about, at some point in time, you have to shift from every customer and the success of every customer, every new customer being, being the primary motivator, to focusing on the things that make the most customers successful. And that's an art that you have to navigate as you start to scale.

But at some point in time, the heroics of let's make this customer successful. And then this next one, and then this next one, and this next one starts to come at odds. If you have a very large and growing customer base that you may need to do a couple other things, for example, 50, 60% of your customers who are complaining about XYZ versus something that one customer is complaining loudly about.

And so you have to figure out how to prioritize that. So that's the other thing that I think that shifts over time is that focus on making one customer successful and then focusing on the things that make the most customers successful in those early days. 

[00:23:47] Did you set up the team or set up a process to make that work.

Or was it a little bit like whack-a-mole and whoever was around drop everything and go work on this 

[00:23:57] thing? Yeah, I think in the early days it was very much the culture that we set around. Hey, if an important customer was going live, that's significant to us and they need additional. Functionality from a product perspective or help from our professional services organization, et cetera, it was more about, Hey, let's, let's do whatever it takes to make these customers successful over time, obviously is that number got greater.

Uh, we had regular sync meetings with our customer success organization with our professional services organization, because then you'd have more basically runway where a customer had signed a deal and their go live date was maybe 30, 60, 90, 120 days in advance. And so you had a bit more visibility into the pipeline and as you got.

Deeper into the deployments for these customers, you would have visibility into some of the gaps, and then we could collaborate as a team and figure out, Hey, are there things that we need to change in the product? Is there some work around that professional services can take care of? So it starts to get more systematic.

You have to, as you get to larger scale, but very early on first 10, 20, 30, 50 customers, it literally is all hands on deck as you get these customers alive and successful. And again, going back to the theme early on, it typically very much is the case when you're focused on a consistent segment of the market, that it's the things that you do to make those first 10, 20, 30 customers successful are very likely to be things that are going to make the next, you know, 50 or a hundred customers successful.

So you're always had that view of. Making sure that what you're building at least I'll say from a product perspective is something that's going to be useful from a repeatable perspective. You always have to keep that filter on. Um, but it's certainly the case that, again, when you're focused tightly on your ICP, you have a higher level of confidence that you're going to be building something to, to make those folks successful.

It's going to be useful to a lot more customers down the road. 

[00:25:59] A related idea that we haven't touched on yet is one around pricing and packaging. And I'd be interested to learn more about some of the frameworks that you have or approaches that you've developed around pricing and packaging, and maybe some of the mistakes you've made things that you've changed, or kind of your general thoughts about how you approach pricing, how, you know, if it's working or not, and maybe how that evolves along the life cycle of a product, and then set up 

Great topic. And I think it varies a lot, again, like everything, depending on the age of the business and also the type of business. So I'll talk about some examples. Through different various life cycles of Okta. And then I'll bring some great examples of some work that we've done here early on at fauna as well at Okta.

And I think it had a lot of early stage companies. You might have a perspective on what the pricing should be, and then you sort of meet the market reality and you have to balance those two early on. For example, at the very early stages of Okta, before we were aggressively acquiring customers, we had a perspective that was aligned with our vision at the time, which is what we were building was a centralized cloud service to help you manage and secure your SAS applications.

And so we thought about the value of that as a percentage of your SAS spent and said, Hey, from a value perspective, the way customers should think about this is they have a fair bit of spend per head per user. On their SAS applications. And so if they were to spend five, 10% of that on a solution to manage your secure, that seems to be a very reasonable budget.

And what we found out while I think that was logical in nature, if you will, what we really got compared to was our initial use case, which was single sign-on. And there were single sign on solutions, obviously in the past, they weren't, multi-tenant a hundred percent cloud-based like Octa was. And so there was kind of a market rate around which people were accustomed to paying for single sign on solutions.

And then of course, obviously there's always competition in the market as well. And so one of the most practical things that we did very early on, especially if you have a direct sales organization like we did, we just had to trust that the sales organization was going to find the market clearing price.

At some level, they're obviously motivated to close deals at the highest price possible to retire their quota. And so you loosen up some of the constraints there. And you start closing some deals to get a really good understanding of what's the market closing rate for this product. In our case at, at a 500 seat organization or a thousand seat organization, or a 5,000 seat organization.

And then it gives you a sense of where the market is, and then you can use that to build a more structured discounting schedule. And then as you scale, obviously you need to tighten up the amount of flexibility you have there as you hire more reps, et cetera, but it gives you a nice, solid starting point from which to price take something like fauna.

We don't have that situation because we're much more product led growth. We have a customer success organization. That's very technical in nature. That's dealing with developers as they sign up for the service and are hitting roadblocks, and then helping them blow through the roadblocks as they integrate their application with fauna and then continue to scale and use the product.

And so we were able to look a little bit more at competitive alternatives. And in our case, we also have a very different pricing model to what we had at Okta. This is very consumption-based. And so you get a sense of what is that market competitive clearing price look like as a customer. If I'm looking at alternatives, what's my total cost of ownership and therefore what's a reasonable price to set for fauna.

And then obviously as a business owner, you have to always see, look at that relative to your costs and make sure that your gross margins are acceptable. So that's kind of like where to get started. I think the other thing is not just on the price point, but the packaging, so pricing and packaging and making sure that you are packaging in a way that aligns with how customers are consuming and how their consumption grows over time.

So at a, at a very simplistic level, very early on, we had a single sign on solution and a enterprise solution at Okta. Well, actually we had three. We had, um, what we call the Okta cloud connect, which was our single app connecting to your directory that we gave away for free. And then you had your basic single sign on package.

And then we had an enterprise package and that sort of aligned with primary use cases. We'd saw a lot of people who were deploying one big SAS application and wanted some of the Okta like functionality. We had a high degree of comfort that once they deployed one, they'd probably want to come back for more.

And so we gave that single app connection away for free. The primary use case was single sign on. And so we had the features and functionality in that package around single sign-on. And then we had an enterprise product that had more sophisticated functionality in the early days. It had around multi-factor authentication and, and broader things around energy and your identities across their life cycle and integration with HR systems, et cetera.

Today’s episode is with Eric Berg, CEO of Fauna. Before joining at the helm of Fauna, Eric was a product leader at some of the most interesting companies around. He shares his executive playbook, weaved together from his experiences at Okta, Microsoft and Intel — including his lessons on pricing and packaging, moving upmarket, and hiring folks with the right ego to talent ratio.