Episode 21

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

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.

Headshot of Eric Berg
Subscribe with your favorite podcast app


Eric Berg: [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.

Brett Berson: [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.

In those early days. 

Eric Berg: [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.

That's a good high 

Brett Berson: [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?

Do you have any 

Eric Berg: [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. 

Brett Berson: [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.

Or a go to 

Eric Berg: [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 

Brett Berson: [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 

Eric Berg: [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 

Brett Berson: [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 

Eric Berg: [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 

Brett Berson: [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. 

Eric Berg: [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 

Brett Berson: [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. 

Eric Berg: [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. 

Brett Berson: [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 

Eric Berg: [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. 

Brett Berson: [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 

Eric Berg: [00:26:27] products.

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.

But it mapped to sequence in terms of how people use the product similar here at fauna, but for a very different audience, we have a free product for developers in our philosophy for that is that, that free product, because we're a hundred percent SAS. Has to be the equivalent of our open source download because we are a closed source company.

And so we want to make sure that anything that a developer has to invest in to learn about fauna is available and accessible in that free forever plan. And then as they have different functionality or from an administrative or management perspective, or they want access to some of our global regions and they're expanding the usage of fauna, they have different versions that they can buy into basically up the stack in terms of, of our offering.

So a different use case, but really going back to that, thinking about how usage expands over time. And this is an area that I will say specifically that I've seen, especially today, when people are talking about product led growth and enterprise, and trying to bring the two together. I think it's important that people get the pricing and packaging, right?

Because I think I've seen in several examples where the two motions are not thought in an integrated fashion, you end up leaving customers and alerts. So I've seen companies, for example, who started. On the product led growth and had tremendous traction and then wanted to introduce an enterprise motion and would create packages to drive larger ARR, but they hadn't thought through, Hey, if someone started in that product led growth packaging and then expanded over time, do my enterprise offerings make sense?

And is it a, is it a nice smooth line or have I interjected some big disruption that makes them think about whether they want to stay with my product? So I think it particularly in today's day and age, where people are thinking about different. Pricing and packaging promotion. I think it's super important to be thinking about a continuous line between how people get started.

For example, if it's in a product lead, run your credit card and get going, and then by the time they start talking to your enterprise sales team, do you have a set of offerings, pricing, and packaging that are consistent and don't interject disruption that causes a customer to rethink whether they should be continued to invest in you or look for an alternative.

So on that point, are there 

Brett Berson: [00:33:16] other traps or, or mistakes that you've seen around pricing and packaging at some 

Eric Berg: [00:33:21] frequency? Yeah, I think that the next one is, as I mentioned earlier, we went through a big transition at Okta that I think a lot of companies do is they start scaling, which is initially when you start small, you have less functionality.

And in our case, we had shallower functionality across a broad range of use cases. And then as you develop your product, you obviously have deeper and deeper functionality in these particular areas. And at some point in time, it probably makes sense to break those out. And in our case, it kind of goes back to again, understanding how customers use your product and the thing I think I see people sometimes get mixed up on.

And we certainly had to iterate on this at Okta is making sure that you define those break points in your product in terms of how you package various features together, not just in how you think it might make sense logically, but how it aligns to specific use cases. So really understanding where do your customers start and if their first deployment is to solve a particular problem.

And then what's typically a phase two deployment, what's typically a phase three. And so you get a sense of what the market maturity model, if you will, of the usage of your product is. And as close as you can try to align up the packaging of your different additions in that way. And then ideally people can start in a lot of different locations.

And so you have, depending on their use case, they can pick up particular one of your additions, if you will, and then add on functionality. So we did that specifically with Okta. When we moved from that simple configuration that I mentioned, where we had our free product, our single sign on, and our enterprise edition two, we moved out to a suite of products that were deeper functionality around particular use cases.

So we had our core directory offering. We had a single sign on offering. We had a multi-factor authentication offering. We had an identity and life cycle management offering, and these were oriented around specific use cases that we saw customers using so that they could get started with a smaller spend to solve a specific problem.

But it also allowed as they used more of often these areas over time, we could sell them more. Our packaging was aligned with the evolution of those use cases. So I think that's an important thing that I think sometimes people think about a little bit about, more about maybe their roadmap and what logically makes sense for them.

Instead of again, taking this customer first view on how usage of your product evolves over time and therefore how you should think about slicing and dicing. And this gets really tough with technical products in particular gets into another topic. I know you, and I've talked about before, about skillsets and product management and product marketing and where this pricing and packaging sits and the skillset you need to have, especially with these technical products.

It's really important to understand how the customers are really using your product features and functionality and how that spans these different use cases in order to do a good job of operably packaging and pricing. 

Brett Berson: [00:36:22] Building on that. This gets into one of my favorite topics, which is moving up and down market.

And I feel like it's one of those things that it's a little bit like the grass is always greener. You have a more transactional sale downmarket, lower ACV, and you and your board are like, oh, it's not that hard to do half a million dollar deals. So why are we doing all these 20 K deals? Let's just move up market and increase ACV.

And in the reverse you have companies I think with longer lumpier sales cycles. And they're like, look at all these new companies doing product led growth. Let's do that. Let's slap that on. And for a whole host of reasons when this is not done well. And I think most of the time, it's not, it's a very efficient way to like blow up your company.

And I think there's a bunch of examples of companies, for example, that were doing quite well in the mid market. And did a very poor job of trying to go up market and you ended up just burning a tremendous amount of capital doing that. And so I'm curious if you have thoughts about maybe why that is or what it looks like when it's not done well.

Or what it looks like when it's done exceptionally 

Eric Berg: [00:37:24] well. Yeah. I think it's a fascinating topic and one that's super relevant to today because I think like you mentioned, I think the trend that you see out there probably most strongly today is because of the rise of the popularity of product led growth.

I think you see a lot of. Quote, unquote enterprise targeted companies who are trying to do that. And, but I mean, these patterns repeat themselves, right? I remember back in the late nineties, early two thousands, there was always the complex enterprise product that would try to come out with the SMB edition that would just repackage and price something for the channel and hope that they would expand their capability down there.

And I think the patterns are the same that if your product is too complex, no matter how hard or different you price and package, it's going to be impossible in a cost-effective way to penetrate those kinds of markets. So if I step back, my philosophy on this is number one, I think both ideally or are very important to have if you're going to build out large, substantial enterprise SAS company, but they are also both very different all the way through meaning from what you build to, how you go to market.

To serve both markets very effectively. It is almost like two separate companies. You know, actually a great example of this it's just played out in the market. Recently, my former Alma mater Okta made a great acquisition of, of auth zero and while some of the technology is somewhat similar, huge differences between the go to market and very, very complimentary Okta having an extremely strong enterprise sales motion and auth zero, having grown up selling identity for developers and all of the product functionality, as well as marketing and sales mechanics associated with that.

So. I think that's a great example of the fact that there's two completely different companies that were built relatively speaking in the same space with some similar technology, but with dramatically different go to market motion. So I think having both is important, I guess, as a product person and having gone through, we looked at some point in time at Okta, you know, we made an acquisition in this space and we expanded into that market, but it was always hard when you had.

A primary go-to-market motion that was enterprise focused to be able to natively build out that bottoms up product led motion, both technologically as well as from a go-to-market perspective, you have a huge market need and your company is growing very fast, servicing the existing need with the resources that you have.

And so building a second company within a company is difficult. When you look at, I think some organizations that have done this well, I think that the perhaps easier way is to start with the product led growth. Again, it goes back to, are you in a market and solving a problem with a buyer that can consume that way?

Stripe is a great example of that. I mean, clearly they've been wildly successful, but they started with smaller organizations and solving a much more narrow use case. And a lot of their customers will, all of them started by swiping their credit card and using that service. But then today you fast forward, they have many, many organizations paying them millions and millions of dollars.

And they have what would look like a very enterprise sales and customer support and service organization that manages the relationship with those customers. And so I think about that here at fauna, and that was certainly right. One of the things that I thought about when I was looking for an opportunity from a CEO perspective, was looking at a company that's investing in and is focused on this product, led growth and really irony.

Now the use cases around people adopting and using and deploying your product initially, but then ultimately as your relationship matures, and those enterprises are spending more money. You need people, both sales support, customer success that are managing those relationships at scale. And I do think it's a little bit easier from a product and go to market perspective to layer on that enterprise approach on top of the product led growth.

But you have to be aware that it is different and you have to be thoughtful about investing appropriately to make the two work together. I think you've got 

Brett Berson: [00:41:35] a really important idea, which is that. A lot of people, I think trick themselves into thinking about, oh, we'll just move up market and take the same product and just charge more for it.

For example, they work 200 person company. Now they're 2000 and they forget that in almost all cases, there's a really strong interplay between pricing and packaging product end go to market. And if all of those things aren't really singing and working together just generally doesn't work. And it doesn't turn into sort of a scalable, repeatable motion.

And I think then to your point, you start to have multiple product orgs building for different types of customers. And it can quickly, I think, turn into a mess, which is, I think why in a lot of markets, you do tend to see a striation right between a down-market player, mid-market player and upmarket player, as opposed to just sort of one monopolist that can take a 10 person company or 10,000 person company as a 

Eric Berg: [00:42:25] customer.

Totally agree. Like you said, they can be two very different companies where you're going, I think is a hundred percent accurate. And, uh, we're a lot of people use the phrase, product market fit. I think you really have to think about it in an 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 as, as you mentioned, when you pull on that thread and you look at product and go to market and the market and the target customer, you, you can see completely different companies being built depending on which one of those threads they're pulling on.

So to round 

Brett Berson: [00:43:04] out this idea, do you have any thoughts around like what that internal org structure needs to look like? Maybe you're moving up market. Do you have a separate, in many ways, a separate org across those disciplines? Or what have you learned about how like the actual internal org should map to that work?

Eric Berg: [00:43:21] We tried a couple of different things at Okta. And I think what we netted out on as we expanded into these new product areas, especially if they required a different go to market investment, you almost need to incubate and have a separate team, even if it's a lot smaller from a resourcing perspective that is maniacally focused on product or go to market expansion.

And that, to some extent, what you're trying to do is you're kind of trying to recreate the amount of focus that you had when you started the company, but kind of the amount of focus that we have here at the size that we are at fauna. Or the amount of focus that we had early on at Okta, where we were maniacally focused on a segment of customers with a particular use case, and we would do anything.

It took to get those customers successful and build the features that they needed, et cetera, what you tend to see the trap companies that are super successful in their current market and are trying to the band is the natural thing, which is you try to get into this new area. And if you need functional heads to invest appropriately in it, they're always torn because there's so much need and demand from the core business for them to invest that they can't really justify giving you a head or two or some time to invest in this very small nascent business.

So I think getting focus and incubation of an effort is super important on two sides. One is to ensure that you have that focus as an organization, that you can be successful in nurturing this and growing it. And secondly, also to, to make sure you don't distract resources in the main line of the business ahead of time, there are some situations where we release some products early on that weren't quite ready for the entire sales organization to take and sell at scale.

And so you risk distracting them by something that's quote unquote, not ready for prime time because you haven't matured a complete understanding of. Why is it the customers buy? Do I really understand the right pricing and packaging for this, et cetera? So my learnings tell me that the best thing that you can do is get into a focused level of incubation.

Now, there are some practical constraints to that obviously cost. And then structurally does that mean you have just a product and product marketing and maybe sales, incubation, but engineering is still within engineering and you carve off a feature team that has some capability. I think the nuances of that, depending on the product, you're building, the architecture that you have and how you can slice and dice that.

But I do believe that there is some level of incubation and focus that you need that is maniacally focused on this new opportunity and that you get that team, the resources that they need to be successful, get them thinking like they are a startup and then appropriately introduce that to the rest of the company when the timing is right.

In the last 

Brett Berson: [00:46:14] bit of time we have together, I wanted to switch gears and talk a bit more broadly about team-building and company building. I was interested in maybe starting by talking about some of the ideas that you've taken from the cultures of Intel and Microsoft, and potentially woven into the way that you've thought about building teams and companies that Octa now fauna, Intel's probably a little bit more well understood because Andy Grove was such a prolific writer and high output management and only the paranoid survive and his other books had been sort of read and continue to be read.

But I also think that Microsoft is a bit underappreciated in Silicon valley in so much of what they got, right. From a culture perspective. And when I use the word culture, I mean very broadly, like. Behavior the way things are done, how people work together, internal systems sort of that stuff. And so I'm curious when you reflect on those two, I think they were roughly five-year chunks of your career.

Are there ideas or behaviors or ways work was accomplished that is woven through kind of the last 10 years of your company building experiences? 

Eric Berg: [00:47:23] Yeah, absolutely. Coming in as a CEO of a company like I have here at fauna. When I had assembled the majority of my new management team, we spent a lot of time on this topic in particular, because I feel it's very important that you set the stage in terms of the culture that you want to build and the kind of people that you want to attract.

And so we spent a lot of time as a team working through what we call our core principles. And I found through that process. Absolutely. I drew upon a lot of learnings from both those two organizations and, and frankly also my experience at Okta in terms of some of the things that I think worked well there.

So from Intel, I think there was two absolute things that were very strong. And one that I think was consistent with Microsoft as well. Probably one of the strongest ones that Andy Grove was the CEO when I was there. So I had a chance to work with him and be in meetings with him and see him operate. And one of the strongest things that I remember from the culture there was around this concept of disagree and commit, and the fact that.

Hey, you're going to get into a room and your going to, as they called it at Intel, at that time constructive confrontation, the idea was really to bring the best ideas forward. And then once the team picked that idea though, was very important that people would disagree and commit and nothing would happen outside of that room to damage the progress on that, on that new direction.

So that concept of disagree and commit is something that's certainly front and center. As we think about here, we have a principle, we call it seek the best idea than commit, which is all about that. We want to make sure that people are coming to the table and that we are listening to all the best ideas, but then once we pick one, we want to make sure that everybody gets behind that and moves forward.

And so that idea of. Constructive confrontation or being able to bring the best idea forward was something that was also fostered at Microsoft. I think they were very strong about people speaking their mind and bringing their perspective into a conversation, but then rallying around the right thing.

And then moving forward, we have a core principle around stay hungry and humble, and I always would tell people that I think one of the things that we did really well at Okta, and I think we do well here at fauna is we look to hire people who have big, bold aspirations. They want to build something big.

But I say they're easy to T ratio. Their ego to talent ratio is in whack, meaning that they're have a great talent, but not a huge ego that fills up the room. And so we encapsulated that with this stay hungry and humble, which is no matter how successful we are. We out always go back to focusing on the customer and making them successful.

And knowing that we have a lot more to achieve, uh, ahead of us. And frankly, I think it just makes a better environment to work in because I think the climate and the kind of people, you just want to work more with those kinds of people from a cultural perspective. So those are a couple of things have been very instrumental in us thinking about the culture that we want to set here at fauna, which for me is infused a lot of the background and learnings that I've picked up from a variety of companies over the years, in the 

Brett Berson: [00:50:29] last example of hiring folks that are humble, or at least humble relative to their abilities and talents.

If you're sitting down with, let's say, you're thinking about hiring a COO and you're trying to get a sense. In the meeting of how humble they are. What are you looking for? What are you asking to increase your conviction? That this person actually is humble? It's it's obviously something that's easier to reference, I think.

Um, but I'm curious if you have thoughts about when you're spending time with the individual, what that looks 

Eric Berg: [00:50:56] like. You are right. I think ultimately our, on that one in particular, certainly talking to folks, who've worked with that particular candidate and kind of the culture, but both people that they work with from a peer perspective, as well as on their team.

I think that's critical when you listen to a person talk about, and you ask them about some of their accomplishments and their achievements, and that there's a balanced tone there between both. You want to hear about what they specifically drove and were responsible for in their contribution, but also how they achieve things as a team and as an organization and, and an understanding of.

How some of their success was a factor of they or their team's contribution and how much was context for the market or competitive dynamic or situation that we find ourselves in. I mean, I think a lot of, a lot of people will talk about this frequently that you can control a lot of things about a company around its product, go to market strategy, all those things that we were talking about, but at some level, the market has to line up with you as well.

And so I think an understanding of the things that are within your control and, and outside of your control, what contributes to overall success. And you get a sense of that for how people talk about the things that they've achieved and what has contributed to it. Another sort of 

Brett Berson: [00:52:12] area I wanted to follow up on is at the beginning, you were sharing some of your values and the first one was tied to Intel about getting everyone's best ideas and then have a discussion debate.

And then the outcome. Everybody commits to. And so there's no sabotage or a second guessing my thought is that obviously you're not coming to work and saying, listen, everybody with great ideas, I want you to shut up. I don't want to hear them. And after we decide, I want everybody to scream at each other.

So there's an intuition that you would want these things to happen, but in a lot of companies, they don't. And so I'm curious if you just take maybe that value and you think about maybe your experience at Intel or at other companies. How do you actually get it to manifest other than maybe talking about it or reminding people about it?

Eric Berg: [00:52:54] It's something that we've spent a lot of time thinking about here, which is basically what you're asking is how do you operationalize this? How do you move beyond just words on a piece of paper? And so there's a couple of things I can tell you what we've done and what I've seen be successful. So one is on the front end.

I E as people are coming in, we are absolutely doing what you just asked me about, which is how are we making sure that we evaluate people along these axes as they come in. And so we'll ask specific questions that we've developed for our interviewing process, that map to these core principles, so that we get a sense.

And we make sure that someone on the interview loop is asking about some portion of these. So that's one thing which is evaluating it on the way in. The other thing that we're doing is we have recognition process in place so that we have regularly quarterly awards across the company where, when we nominate people.

Around these core principles to demonstrate that value. And so we're sort of reinforcing that in terms of finding where it exists in the wild, if you are, will, and then holding that up for the rest of the company to see, is that something that we think is great behavior and that's in line with our principles.

And then finally on the review side, as we manage performance and, and encourage people to grow and find paths for them in our performance reviews, as we go forward, we're implementing a view on not only how is this person in terms of the, what did they perform, but the, how they performed it, which is really where the principals come in.

And so those are three concrete examples of things that we're doing. And then, you know, other things that were when we went through the wording, for example, Of some of these core principles that we rolled out, we wanted to make sure that some of the words were short and memorable so that people could start adopting them on a day-to-day basis.

I mean, as I mentioned, we've hired a few folks from Amazon and AWS. And one of the things that they've all commented on is that there is a lot of the day-to-day vernacular, which is a reflection of the core principles that Amazon holds. And so we're looking for ways that we can bring that in on a day-to-day basis to make it real, because yeah, you definitely have to go beyond just a laminated card or a poster and really try to inculcate it into culture on a day-to-day basis.

So I wanted to wrap up 

Brett Berson: [00:55:13] by talking a little bit about your experience and reflections now on being a CEO, you've spent so much of your career working with spectacular CEOs as an executive, and I'm curious, what's been surprising. What's been a bit counterintuitive or unexpected. Now that you're the CEO of your own company.

Eric Berg: [00:55:36] And I get a little, a lot of people would ask, why do you want to do this? This is crazy. And I think, you know, I start out that conversation in an honest fashion, much how I'll start this answer is which I think, like you said, I've, I've had an opportunity to work along some really good CEOs. Who've built very successful companies.

And I think you either go through that, like I have over the past 10 to 15 years and say, oh my gosh, I don't want to have anything to do with that. Or you look at that and say, Hey, that's really interesting. I'd love an opportunity to try that myself. And so that's certainly where I netted out as I thought about what I wanted to do next after Okta.

So it's interesting. I had thought about it quite a bit. And like I said, I had worked very closely on an executive team. So there was a lot of the things that I. I guess had sort of anticipated and were not as surprising, but some of the things that we're, it's very interesting. It's hard to put them into specifics right now, but there are certainly things that I will say now, looking back on decisions or ways that my CEOs that I worked for before spent time or how they made decisions, that didn't make sense to me.

Now make a lot of sense when I see it from this other side and I can kind of look back at some of those decisions and say, okay, yeah, I understand why. Cause their time and their focus was somewhere else where I was very deep in a particular area of the business. I can understand now why they acted that way or made a decision that way.

So I think that it's hard to understand until you get to this position in terms of the breadth of things that you have to think about. And so an art that I'm just learning is you can only pay attention to a few things at once and make sure you focus on them and other things, even though they may need work or help, whether they're people, organization, technology, et cetera, they have to be lower on the list.

And so you've got to prioritize those small number of things that are going to make the biggest impact. So I think that's something that I've been learning and navigating through. I think also for me, a new thing, and for every CEO, a new thing is the relationship with your board. I have a fantastic board.

They're very seasoned operators and good investors, some of which I've known for many years and figuring out that balance of how to properly use them from an advisory standpoint and when to take the lead on that. And when to ask for advice and navigate that, as well as understanding that at the end of the day, it's important to get advice and counsel from outside of that board of directors.

But that's been an interesting area for me to navigate and get accustomed to. Again, I think I've been fortunate that I have a very good board. That's very seasoned that has a lot of operators on it. And so they understand the demands of day to day and how to step back and think strategically. So I think navigating that board relationship and figuring out what that looks like and how to make it most effective has been another area of learning for me.

If you were to go 

Brett Berson: [00:58:27] back at some point in your career to being an exec instead of a CEO, in what ways do you think you would behave differently or operate differently? Having been in the CEO seat and maybe the answer is you wouldn't do 

Eric Berg: [00:58:40] anything differently. I think it gets back to that first statement.

It's maybe a popular word. These days is empathy, but just having an understanding of the number of demands and the breadth of things that you have to think about and consider in this role and how that may or may not line up with any particular functional role and what they see as the priorities and important things in the business, if anything, it's probably understanding that and knowing that there's things going on, that you probably don't have visibility into and understanding of that may be driving the behavior of the CEO or where they're spending time or how they're thinking about particular things.

Yeah. I think that's probably the number one thing. If you asked me off the cuff, 

Brett Berson: [00:59:23] so to wrap up, you touched on this a little bit, but I thought it would be interesting if you think about. Maybe what you observed or learned from Andy Grove or maybe more recently taught at Okta. Are there specific lessons or ways in which you changed your mind working with or watching either of them or ways that they've influenced the way that you behave, operate, manage?

Eric Berg: [00:59:47] Then your current role. Yeah, absolutely. I think every professional is influenced heavily by all of their things experiences. Right. And so I think I could go through my career and all the way back to an internship I had at Intel when I was an undergraduate still. And so I think there's lots of influences you named a couple of them.

Andy Grove was amazing in terms of his. Ability to integrate both an understanding of the technology and the market reality. And so their go to market obviously was very different and that it was going to market at that time through a very small number of OEMs who were consuming, you know, the large majority of their, their Silicon, but just that facility and ability to bounce back and forth between technology and business was something that I admired tremendously about Andy and I had the privilege of seeing that for a short part of time when I was at Microsoft, when bill gates was still CEO.

And then, you know, Todd is a great example and the maniacal focus on customer success that I think he picked up in his time at, at Salesforce. And I just really saw the power of that in both, and also walking the walk around that the decisions that he made in the prioritization around customers and how that was driven throughout the entire organization and how powerful that was and building a culture.

Uh, that's something that absolutely has followed me here at fauna. So I think, you know, as I go through each one of them, there's a different set of skills. Sunny Gupta was the CEO of Aptio prior to that, Sonny was a multi-time entrepreneur and he was really strong at managing the business, managing expectations, managing the board.

And so I got to see him navigate as a multi-time entrepreneur who had navigated that situation in terms of early stage companies and board dynamics and, and setting expectations and how to manage the business. I can kind of go down the list. I try to pick the best that I can from all of my experiences and put those learnings to use as I go forward.

Brett Berson: [01:01:49] Awesome. Well, thank you for spending all this time. This was such a great wide ranging conversation and we so appreciate it. 

Eric Berg: [01:01:56] I really do Brett. Thanks for having me on the podcast.