How to Find Product-Market-Sales Fit

Sonal: Hi, everyone. Welcome to the a16z podcast. I'm Sonal. Today's episode continues our Enterprise Go-To-Market podcast series. The theme of this episode is for founders and product managers to consider the tight relationship between product and go-to-market, one informing the other in both directions. What are the key milestones that go into both, and in different phases of company building, especially pre- to post-product market fit?

Sonal: The conversation features special guest Jyoti Bansal, founder and founding CEO of AppDynamics. He's also a co-founder at Unusual Ventures and co-founder of Harness. Joining me to interview Bansal, we have general partner Peter Levine, who also put out a series of 16 short sales videos for founders, which you can find at a16z.com slash 16sales. And then we have a16z enterprise deal team partner Satish Dharmaraj, since he too came from AppDynamics, where he was last a senior director of product and growth operations, pre-sale to post-sale.

Sonal: Speaking of, we go beyond the typical discussion of product-market fit into the concept of product-market sales fit and what that means for product design, to services, to pricing and packaging, to product management, and more. But first, we quickly begin with the fundamental shift in mindset for technical founders. The first voice you'll hear is Jyoti's, followed by Satish's, talking about the initial insight behind AppDynamics, which was acquired by Cisco last year for $3.7 billion the night before it was set to go public.

Jyoti Bansal: I was working as an engineer in a company, and this was before the phrase you guys coined, "software is eating the world." This was 2008. But it was clear that software is eating the world. To me, it's like, okay, if everything is going to be software, something goes wrong in software, someone needs good tools to troubleshoot and fix it. So that was really the insight. AppDynamics was building monitoring and troubleshooting solutions for complex software apps. If you have online banking and something goes wrong, you will use AppDynamics to figure out the root cause and fix it. Or if Delta reservation systems are down and everyone is stuck at the airport, someone needs tools to troubleshoot what the root cause of the problem is and fix it. That's what AppDynamics built.

Jyoti Bansal: When I jumped into it, I didn't know anything. I didn't know how to raise capital. I didn't recruit anyone before AppDynamics. So I had to go and figure that out. I didn't know how to have lots of customer conversations or even find customers to talk to. At least during the pre-product market fit, a lot of engineers, including myself, get obsessed with the technology. I'm not so much about the user. At the end of the day, if user adoption is not there, it's no good. There's no market without the user.

Satish Dharmaraj: Exactly. You got the product side, but not the market fit part. I see a lot of engineers struggling with understanding that customer and user adoption and the engagement metrics. Without that good UI, UX, and whether it's an open source strategy or a closed source strategy, it doesn't matter. User adoption is what should be driving the pre-product market fit. Now the challenges completely change after you have your initial product market fit. They become all about sales and learning sales and scaling sales. Companies go through their journey. The pre-product market fit challenges are different. Then after product market fit, the challenge becomes about selling and scaling sales organizations.

Peter Levine: You're saying on one hand that you have to sell after product market fit. But on the other hand, I've heard that for a lot of enterprise businesses, part of the act of selling is finding those users in the first place. It's a bit of a chicken and egg thing.

Jyoti Bansal: Well, a lot of us start our careers as engineers. A lot of our construction of a business is around the features and around what the product does. It's all technically oriented. We often say, okay, well, if we have these features, then people will come and buy it. I find that some of the go-to-market is an afterthought once you've built something. I would argue in today's day and age, if you're going after small businesses versus large enterprises, or self-serve or whatever, thinking about that upfront along with the product requirements and technical requirements may be a good thing to do. To sequentially order those probably results in an efficiency issue. We go build something and then, oh, who knows how to go sell this?

Peter Levine: Might it be useful to say to technical entrepreneurs, in order to do this, you have to go figure out the go-to-market as well as the product features, and don't eliminate that or push that off?

Jyoti Bansal: I would totally agree. The way I mentally think of this is two phases of product market fit. Phase one is really figuring out where your target market is. For that one, you really want to start broad and then segment. If you don't know where your idea or your product would fit the most—is it large enterprise, is it SMB, is it financial services?—then I would just go and interview all of them and not narrow yet, and start building the product a little bit wider.

Sonal: How did you guys come to that? Where did you start? You had this wide aperture and then it narrowed to what was the first thing?

Jyoti Bansal: To me, it was that people are building complex software apps and they need to monitor them well. I had the technology idea that if you can instrument the code and trace everything, then it would be a good product. But I didn't know who would buy it. I started like, okay, let me go and broaden it. Let me go and find people in larger enterprises to talk to. Let me go and find people in startups to talk to. Let me go and find people in mid-sized companies to talk to and see where it sticks the most or where the most pain is. What I found was that the most pain is where there are medium to large companies building complex distributed Java applications. So let me now focus more on that. I started broad and then we started narrowing down the focus.

Jyoti Bansal: After that, once you identify it, it's very important that you marry the go-to-market model in your product thinking. These days, it's all very tightly coupled together. Sales is not different and marketing is not different and product is not different. It's all together in many ways. If you have an open source model, or a freemium model, or if it's SaaS, on-premise, hybrid, or if it's going to be land and expand, you have to engineer a product with that in mind.

Peter Levine: Right. The features of the product almost have to inherit part of the go-to-market within the product itself. A lot of product design, I think, reflects the go-to-market attributes that need to be considered.

Jyoti Bansal: In AppDynamics, I used to say it's a little bit misleading to just call it product-market fit. We should call it product-market sales fit.

Sonal: Oh, I love that.

Jyoti Bansal: Have we found the right market, and we have the right product, and we have the right sales or go-to-market strategy that works for it?

Satish Dharmaraj: So when you said two phases of product market fit, the first one was where, like either the small, big enterprise, different domain or industry, and the second one was the sales motion?

Jyoti Bansal: Phase one is where is the most pain, and where your product or your unique approach solves the pain in a way that people will pay for. You're also validating your technology: does it really work? Can you really build the product? Does it really solve the pain? Then you have to figure out what the sales strategy or go-to-market strategy will be that will work and scale. And does your product support that? Because if your product doesn't support it, many times people say, "We're going to build a freemium strategy," but if a product is too complex, freemium doesn't work.

Peter Levine: Just to drive this point home, which I completely agree with, the product, the features of the product need to inherit part of the sales motion itself. If you're going after a certain motion or certain customer, the product needs to be reflective of that. I think we often miss that. We build a product, and even if we define a go-to-market, the product features or the interface, the design, may be completely misaligned with the target audience or target go-to-market.

Jyoti Bansal: Some of it you can also break into revenue goals. I would roughly think getting to your zero to the first million ARR, you are in that phase one of product market fit. ARR is the annual recurring revenue. Do you have a product someone will buy and it's solving some pain? Then from a million to 10 million in revenue, that's where you're iterating on the go-to-market strategy and getting the product to be aligned with that. If you get that right, at 10 million, you should have the product market and sales fit. Then you can press the gas and go from 10 to 100 from there. But you have to get that iteration on the sales fit.

Sonal: I have a question for you here. In your case, you had a product where you knew the tool was solving an existing problem. Does that calculus change if you're creating a category and you're going into a market where the problem does not already exist? Because then you don't actually have the ability to necessarily know where or how to figure out the sales motion yet. Or is that not true? A lot of founders might argue, "Why can't I be like Steve Jobs and invent the product that people all go to?" What would you say to that?

Jyoti Bansal: You're always creating. Either you're solving a problem significantly better than others have done in the past. The dimension of what "significantly" means could be different. It could be 10x more scalable, 10x easier, 10x cheaper, whatever it is. It has to be 10x better in some dimension in an existing problem. Or if it's a new problem that's emerging, the problem still has to be there. Either there's a problem with existing vendors, or there's a problem because there is no solution. But it has to be there, otherwise you don't have anything to sell. In enterprise more than consumer, there's a certain budget dollar that you're going after. Maybe it comes out of the development budget, engineering, marketing, sales. There's something for which you can at least start to frame this new thing, this new market.

Peter Levine: One of the questions to ask is, who's the potential buyer for this? Even if it's a totally new market, it's an enterprise product somewhere. It doesn't exist before. Still, who's the buyer and what budget does it come out of? A lot of products where there isn't a market yet may span multiple buyers. In fact, they may come from multiple different departments and span budgets. You need to think about that. "I'm creating this new market, but perhaps the buying motion and what the customer is used to doing from a buying behavior is so complicated, it's never going to happen."

Satish Dharmaraj: Even for the product managers or the founders, it always helps to do a sales kind of play, wherein how exactly you are going to sell and who is the actual buyer and who's the actual user. What are you going to say to the user? What pain points are you going to solve? And how exactly is the user going to use your product? I think working with the salespeople who are actually on the front lines to go and sell, for the engineers and the product managers, it really helps. In fact, at your company, you made a lot of engineers go on those calls to literally understand who exactly is buying that product, how much is he going to pay, and for that, what exactly you need to build. That connection for the engineers to go on those sales calls really helped them to understand that sales motion and how to incorporate it into the product. That's one of the best practices I loved.

Jyoti Bansal: We had that strong belief that we have to break the barriers between engineers and customers. In the startups I worked at before AppDynamics as an engineer, people would say, "Engineers don't know how to talk to customers, so keep them away from customers." But we are selling to engineers. Our products are technical. That just doesn't make any sense to me. In the early days of finding the business case, finding where the budget will come from, one of the questions we always asked—my favorite question to ask any customer was, "How would you make the business case to your boss to buy this?" That's when you would start hearing, "Okay, this is my business case. Every time we have an outage, we normally spend six engineers in a room for five hours to try to figure this out. With you guys, I can reduce it down to one engineer for 15 minutes. That's my business case." Once you start hearing the business case, then you know there is a business case. You can monetize it and convert it into dollars at some point.

Sonal: How do you navigate that though when you have multiple budgets and multiple decision makers inside the enterprise? Different groups or departments have different problems or itches that you're scratching. How do you up-level it so that you're selling into getting the big bucks and not just the incremental budget?

Jyoti Bansal: It all depends, again, on this product market sales strategy. A lot of companies that start with bottoms up only go after an individual user. Then they get enough use on individual users and propagation from the bottoms up. I call that self-serve. There's no complexity there. There's no multiple buying centers. It's not a foregone conclusion that that is the way to go. After enough people are using the product, then you can come in with tops down and say, "Hey, did you know everyone in your organization is already using the product? You ought to have a corporate-wide license so we can provide the support and all of that." That would be an example of bottoms up and then coming in on tops down.

Jyoti Bansal: Many other products, though, are designed to be tops down as a starting point because it may go across departments, it may be more complicated, there are security needs, whatever, where a bottoms-up design just doesn't work. In which case, you probably need to start with a more traditional direct sales organization. It could be an inside sales organization or direct, calling in and actually getting the customer. Complex sales often requires multiple buyers, multiple parts of the organization to come together. That's a skill set that a well-honed sales organization will know how to do.

Sonal: How did you guys do it? What was your sales motion at AppDynamics?

Jyoti Bansal: Ours was a combination of both. In AppDynamics, we called it the sandwich strategy. You go from the bottom, you go from the top. You go to the developers and DevOps engineers directly. It was done through a freemium kind of model so that they could start for free and use a light version of our product. Then we would start going from the top, where we would create air cover. When we have multiple users in an organization, then we'll go and sell them more. The sales motion was built on the end users starting for free. Then we would sell them some licenses—we called it land and expand, the land deals—which are like a $20,000, $30,000, $50,000 deal. On the phone, we could sell that. Then we would expand into half a million, million dollar, two million dollar deals. Now these days, $10 million deals require traditional enterprise salespeople.

Peter Levine: Right, so inside sales versus field sales, basically in that context.

Jyoti Bansal: Yes. In most of these companies today, you would probably need both. If the model is only top down, you probably need only field sales and you're selling into large enterprises. But if your model is this kind of land and expand, you want to do the land through inside sales and you want to do the large expansion with field sales.

Satish Dharmaraj: Off late, we are seeing scenarios in which once you go to the top and if there are big enterprises, services has become a very important component of it. To be honest, bottoms up developer adoption, great land. But once you expand and once you get into multiple product portfolios and into complex integration, services is an essential component of the enterprise sales.

Peter Levine: So tell me the takeaway on services. I've always heard, and this is not correct, that services are the things that reduce your margin. So you don't want to have too many services. How do you balance that one?

Jyoti Bansal: It reduces the margin from the perspective of you as a vendor. But think from the perspective of a customer. If they spend a million dollars on your product and they're not getting the value of a million dollars because they didn't have the right people in place to implement your product, that's not good for them. Eventually it's not good for you because you're building a recurring revenue business in some kind. When we started, we were like, "We're not going to sell services." Not from a margin perspective, but because we wanted our product to be easy enough that no one needs any services. That was true for a long period. For the first four years, we had zero services. Then we started getting into larger and larger enterprises and larger and larger deals where people were spending millions of dollars with us.

Peter Levine: You want to save that money.

Jyoti Bansal: Yes. We figured out that if they don't buy any services, sometimes no fault of our product, they just don't get the adoption that we want. So we said, yes, if we have too much services, then the margins are low. But we found the right balance was about 10 to 15%. If people are spending a million dollars with us on the software and they spend $100,000, or 10 to 15%, on services, their adoption is much better and much faster.

Peter Levine: So ideally, you actually make more money on the upsells and cross-sells and more feature expansion based off that 10 to 15%.

Jyoti Bansal: Eventually, if your users are getting adoption and are happy with the product, the money will come. The margins will come. You have to figure out if people are getting value or adoption. Margins will come.

Peter Levine: I like that phrase. If you think about it in that example, services in that case leads the buyer to purchase a million dollars of license. The blended margin on that is extremely high, much higher than it would be on a $20,000 no-services deal. So while services from a unit economic standpoint may be a little more expensive from a margin standpoint, if it drives very large deals with software margins, you come out way ahead. You have to think about blended margin and the idea that services are often a leader into a company buying the million-dollar, $2 million license. It's just expected as part of that.

Jyoti Bansal: And the renewals. Year two, year three, year four renewal. If for the first year, because you sold services, your margin may be lower. But because of services, the adoption is higher. So your chances of renewing in year two, year three, year four, year five are much higher. The margins for those will go up. At the end of the day, adoption is what counts for a product. Services help.

Satish Dharmaraj: Also, keeping aside the financial aspect, even from a product aspect, it's good in the sense that we hate shelfware. What good is it if some enterprise bought a million dollars and they're not using it? Just sitting on the shelf. It's really bad. From a product standpoint, there are lots of these minor features which are custom. They don't fit in the product. They actually fit well for the services. So having a good combination of what's going into the product versus what should be left in the services, that's a good play for the product manager or the CEO to make that call so that the product adoption goes well. Services is a necessary component after some time.

Sonal: I'm really glad you brought that up because I want to segue to talking about the company building side of this. You're describing the sales motion to customers and the product market fit, pre-product market sales fit and post. Now, let's spend the rest of the time connecting it back to what happens inside the company. You're describing the product. How does this affect the product roadmap? When you get all this feedback from customers and you have the sales motion in place, how does this drive back inside your company to further developing more features on the product, making those balancing decisions for what goes into the core, what goes into the custom, what goes into the next iteration? Tell us about those trade-offs.

Jyoti Bansal: It depends on the different stage of the company. When you're in the very early stage of building the V1 product, you really want to use the customer feedback to figure out what you want to build that will sell, that will get your first 10 customers, first 20 customers. You have to listen to customers. That's the product market fit exercise, the customer validation exercise.

Sonal: Are they paying for this thing too?

Jyoti Bansal: Yes. Once you have customers, how you prioritize becomes what you are hearing from customers. What will it take for them to be successful and adopt the product more and buy the product more? You want to make sure that the product team's ears are open, listening to customers, listening to customer support, customer success. They are watching the tickets, watching what's working and what's not working. Then sales is trying to expand and get more customers. So you have to work with them as well because there are competitive pressures. You have to catch up with the competitors on some features sometimes. You have to make sure you're winning enough in the market to get enough revenue, and you prioritize that also.

Jyoti Bansal: But then the third part is you also want to keep expanding your product. These are things that your current customers are not asking for, but you need them for expanding your addressable market for new customers. From a product perspective, it's a balance of those three things. What do we need to win more revenue today? What do we need to keep our customers happy? And what do we need to win more revenue two years from now?

Peter Levine: So win and keep now, to what do you need in the future to win?

Jyoti Bansal: Yes. The rule of thumb that I followed there was two-thirds of our engineering investment should go with our existing TAM, the core base. And one-third of our engineering investment, we should keep putting on expanding our TAM always. TAM is total addressable market. When we started with our initial V1 product, it was application monitoring for Java applications. That was our TAM. Once we had that, we started putting one-third of our engineering on expanding it to the next adjacent market, which is application monitoring for .NET applications. After a year, that became part of our product: Java and .NET. Then we looked at what is the next adjacent market where I can put another one-third of my engineering. We kept doing it systematically for seven, eight years, and we just kept expanding our TAM. The two-third, one-third rule.

Satish Dharmaraj: The interesting aspect, even during that expansion, is that the target buyer, because we had an existing sales motion, target buyer and user, we didn't change that drastically. The sales motion is already oriented towards it. Whether it's .NET or the end user monitoring and so on, it's still targeting the same buyer and user so that you can leverage your existing go-to-market sales motion. That didn't cause too much distraction on the go-to-market side. That really helped expand your product portfolio, but at the same time leverage your existing sales motion to go and attack and expand the market. Understanding that if you change both product and your sales motion suddenly, then it's almost like building from scratch. That causes lots of disruptions in the company.

Peter Levine: That's exactly right. If I go back to the sales videos that I did, there was a concept in there called the sales learning curve, which says that at different stages of building out a sales organization, there are different people you need. When a new product comes out inside a company, you often need to start a new sales learning curve. It's not just the old one that you follow. You may have a new customer. It may be a new market motion. The old organization may not be capable because they're at a mature level of selling an existing product. Now you start out with a different product. You may have to have the evangelist salesperson start that new sales motion and not have the bigger sales organization take on that product in a new market. They may not be able to do it. A lot of companies fail at that because they assume just because they have scaled with one product line that they can introduce another one for a completely different market and nothing happens.

Jyoti Bansal: We learned that at AppDynamics the hard way.

Sonal: Tell us why. That was a hard way.

Jyoti Bansal: We built our first product and it was selling and the sales process was mature. We had a mature sales organization. Then we started building our second product and said, "If you have a mature sales organization, let's give them the second product to sell." They started selling the second product and they failed at it. I was like, "These people are so good at selling. They're being so successful at it." But the challenge is, when you have 100 customers and you have 50 references and you are in the magic quadrant for something and everything is well refined, how you sell is different than when you have a brand new product with zero customers. They just started struggling and they said, "Your product sucks. This new product is not good. We should throw this away. We should not build any new product." I was like, "If you're not going to build new products, our growth will slow down. So we have to learn how to sell."

Jyoti Bansal: So we internally structured it. We were good at selling a new product. So what changed? Maybe we should build a model which used the same thing that worked for the very first product. So we reorganized ourselves in a model I call "startups within a startup." We are a startup, but we'll form new startups inside it and we'll sell the same way we sold our first product in the beginning.

Peter Levine: This is a well-known problem. Often the second product never takes off because it doesn't get the visibility or attention or expertise that's required when a new product is released. And there's a sales compensation aspect to it also.

Jyoti Bansal: Absolutely. Because the salespeople can sell the mature product, which is easy to sell at that point, and make their numbers by doing it. Now you give them something, a new product, which is much harder to sell. You're not going to make your numbers.

Peter Levine: So how did you adjust the compensation accordingly?

Peter Levine: So you almost have to create a separate, almost evangelical new sales team. Just like you do in the beginning. Just like you start out. You don't even know what the productivity is. You don't know a lot of things. And you learn that across that new product line, just like you would do at the start of a company. So this connects the dots between the idea of a startup within a startup, the evangelicals or evangelism that you mentioned, and the different sales learning curve for each. They're kind of all the same thing. That makes a lot of sense.

Sonal: I mean, quite frankly, the analogy that came to mind for me as an ex-developmental psychologist is that when you're doing some kind of a research study, you can never know the effect of variable X if you're manipulating too many variables at the same time. What you're really describing is isolating one variable in order to diagnose what problem, so you can then sell, in this case, that is a solution. However, it's expensive to go do that, to have a startup within a startup. Like here I have my sales organization. Now I have to go hire more salespeople that are different than the ones I already have to go sell this new thing. And at what point do you say, okay, we have to, for every new product, do you have a new sales force? Well, what's the answer? I'm asking you guys.

Jyoti Bansal: Well, I'll tell you what we did. So what I broke into AppDynamics was that we said the sales learning curve is three phases. One is my first 25 customers for the product. That's like phase one, which is very, very, almost the founders are selling. We call that the initiation phase. Then there's the 25 to 100 customers. And then after 100 customers that match our product, our sales force can sell. That's the execution phase. So for the first 25 customers for the new products, we actually got the product management team to really sell it the way your founders will sell in a brand new startup instead of hiring a new sales force for that. But after that, our sales force could take it. The phase two, they could take it. The phase three, they were good at it anyways.

Satish Dharmaraj: So for our fourth product line, which we call real-time business monitoring, this is exactly what we observed. The existing sales force was a lot more tuned to selling the existing product because it was a well-trodden path. For the fourth one, we literally constituted what we call a SWOT team. It constituted the product management, a couple of engineers, the best sales engineers, and one solution architect. We literally went and sold some of the top deals and created the sales enablement material, the market positioning. And in fact, once we created that, then we used it to train the rest of the sales force, even not everyone. And once we hit that first 10 salespeople, they are cracking it, they are making more money with better incentives, then the rest of the sales force is like, "Oh, there is something big there that I also need to sell." So we had to do it in stages, but we literally did a SWOT motion for like eight months. It's kind of like a flywheel. You have to get it going. And once it has some momentum behind it, everyone picks up on it.

Peter Levine: I would also say that as the regular sales organization starts to sell this new product, as managers, you want to make a big deal about it. You want to promote it and say, "Hey, did you know in the East region we just sold new product X and it was for $150,000 or a million dollars or whatever." And that gets everyone excited, especially if it comes from the CEO. Salespeople, I mean, everyone loves to be recognized for their success. And if it's important to the company, then doing something as simple as that from a leadership standpoint also has very beneficial upside for all the other people who want to get that recognition. It's an easy thing to do, but you often may forget about it as a CEO.

Jyoti Bansal: Yeah, literally what Peter said. Once we did this SWOT motion and created those initial amazing sales, the big dollar sales upwards of a million and so on, literally we did internal sales. We had to sell to the rest of the salespeople. We got our CRO, our CEO. They literally are the brand ambassadors of this new product and say, the message is simple: the best new product, you can sell higher, more in a short time and make more money. For our annual sales kickoff, that's the big message. And we got our customers in there and we got the best selling sales reps. And the rest of the sales team sees and...

Peter Levine: They want to get on board.

Jyoti Bansal: Exactly. I want to get on to the train.

Peter Levine: You know, one of the things that I have seen on the sort of down, the negative side of this is companies release too many products. And so then every week, a new product manager is out there trying to rally the team. So it's very important to make sure you're focused on a few things that are really going to work well. And don't let it, from a leadership standpoint, get out of control. It's great for people to try experiments and all that. But don't let it get mainstream until you know it's going to be mainstream. Otherwise, there's 50 products on the price list. And everyone's fighting for visibility. And it's very distracting.

Satish Dharmaraj: Very distracting. Because the sales force is expensive. So if you take your sales force that's doing and you try to give them too many immature products to sell, you're reducing their productivity. Your expense goes up. It's not good. So you do want to get to that level of maturity before you give it out to your broader sales force.

Sonal: Right. So tell me, though, as a leader of the company then, because you have these processes inside, I'm hearing the broader context of the tradeoffs of both approaches. How did you strike the balance and figure out what to focus on and then what to sort of keep off the list? I mean, you have a lot of interesting rules of thumb so far. Steve Jobs and the Walter Isaacson biography made the entire team list all the best things that they were learning that they could do. And then they crossed everything else off the list except for the first top three. Like what was your process for that?

Jyoti Bansal: Our process, I would say as a startup, most of it in our case came from that two-third, one-third rule. One-third of our engineering investment we can put on expanding our addressable market. Two-thirds we put on serving our currently addressable market, which is like improving the product, adding features, capabilities, all of that. And one third, we improve on new use cases, new adjacent markets, new adjacent users that we are currently not serving. So whatever will fit into that will define that. Another system that we use is working backwards from a longer term goal. We put in this plan called our path to 100 million revenue. And we say, "Okay, we want to get to 100 million revenue and how would our business look like? And how much can we do at a fast pace with our existing products? And what would we need to add to the new products to get there?" And then we also have sort of a rough timeline with it. But once we got there, we put a new plan together, which is our path to a billion dollars of revenue. So which was like, "Okay, from 100 million to if you want to get to a billion dollars of revenue, what would our business look like?" And we realized, when we did that math, and this is again a rough math, you never know, that if we want to get to a billion dollars of revenue from 100 million in like seven years, let's say, or six years our plan was, we need to have at least 40% of our revenue coming from these new adjacent products. Otherwise, our growth would not get there. And then we have to build this. So there was the part of what you can do from a bottom-up investment perspective, like engineering resources, and what you need top down to get to a billion-dollar revenue.

Sonal: Right. It's working backward to provide the focus. And you need to do both.

Jyoti Bansal: Right. And find the intersection of what you can do bottom-up. You can't build 10 new products. So what you can build and then what you need to build to get to some kind of revenue long-term goal you have.

Peter Levine: And at that point in time is probably when you start to have a M&A function in the company to start looking at outside. Why? Well, you have organic growth, which is using your team to go build whatever needs to be built. And then you have inorganic growth, which is basically buying or licensing technology and teams that are not inside the company. Because I would argue if AppDynamics was growing to be a billion-dollar company and you had the capacity to support from an engineering standpoint, $200 million or $300 million of product design, how are you going to build 10 new products if that was the envelope or even three products?

Satish Dharmaraj: Right, right. So at that point in time, it's a build versus buy. Do you raise more money and go build a team to go build something or do you go buy something and integrate it in? Both have their challenges. But that's another function inside the company that usually comes about that point in time.

Jyoti Bansal: Like we acquired three small companies as we did that for different things. But sometimes it's just accelerating the time to...

Sonal: I was about to say, it seems like it comes down to speed to market and what the competitors are doing. Like if we built from scratch, from zero lines of code, it would have taken us two to three years to get a reasonable product in the market. By the time we matured it and found the product market sales fit of it and all that. But if we acquired something, we probably could cut it down from two or three years to half of it. Or maybe even 75% in some cases. So that was always a factor.

Sonal: Okay, so why don't we then just talk a little bit about pricing and packaging? Because that's such an interesting subset of this. So we've so far talked about the product market sales fit, the go-to-market and the product as a part of that, obviously, because those are the two things you need. How does pricing and packaging come into this? Because that's a really top of mind question for a lot of founders.

Jyoti Bansal: Pricing and packaging is a complex thing. Pricing is probably more complex than packaging in some ways. I look at pricing as more a function of what is the business value. If someone buys your product, is it worth $50,000? Is it worth $100,000? Is it worth $300,000? How would people justify? So that's definitely one function. Second is, the rule that I've used for pricing is, can your salespeople describe it simply? If a customer is going to ask a simple question, "So how do you price your product?" and if you can't describe it in half a sentence, you have too complex of a pricing. And yes, there could be nuances to it and there could be details to it, but you have to be able to describe it. Like in AppDynamics, we are monitoring all kinds of different systems. So the pricing was complicated, but we said, "Okay, the simple pricing philosophy that our salespeople can tell is we price by how many production systems you have." And that was kind of the rough unit of pricing. And we can measure production systems in different ways, but that's how we price it. So that's at least simpler, your pricing philosophy is simpler for people. So that was my rule number one. The rule number two there was that whatever the pricing is measurable, because if it's not measurable and the customer says, "OK, how many licenses do I need to buy?" Our salespeople cannot even tell them very clearly, "OK, this is how you measure how many you need to buy." However, it will create a lot of friction or once they buy it, we can't measure and track how many they're using it. That's a problem as well. So if we can describe our pricing in half a sentence, that's one. Second is, it's measurable, that people can measure pre-sale and people can measure post-sale. We have a good pricing system. The question after that is, okay, what is the price, the dollar price of it for that model per license, how much you pay? That ideally, to me, it comes down to business value. And enterprise software, especially you're selling to large enterprise, I argue to most founders is that they should price more than you think you should.

Peter Levine: Oh, we always say raise prices. That's our mantra around here.

Jyoti Bansal: Exactly. So price higher, you can always discount. If there's not value, you can always discount. And customers are not going to pay more than what they think they should pay anyways. So you can always discount and then go there instead of pricing low.

Sonal: I love the idea of this pricing framework. A lot of companies try to come up with a new model of pricing. So instead of price per user or price per application, it's price for the number of air vents your server has. Let's just say you have to come up with pricing that the customers are used to actually paying for. If you start to create something that is totally new, it creates friction in the system. So it's typically users or capacity or numbers of something. I love the measurable piece. A lot of companies try to get overly cute and it gets overly complicated and then salespeople can't explain it. And even if it's simple, if it's not understandable by the buyer, they're going to be like, "Well, we don't, like, what does that mean?" So I'm hearing you say founders out there, be creative with your product, but don't get creative with pricing. Do what you need to do that makes sense to the buyers.

Jyoti Bansal: Yeah, exactly. There's a difference between consumer purchase versus enterprise. Enterprises, they need a little bit more certainty. You're getting it from a budget. They're already pre-planned. That's one. And they want certainty in the sense that, "Oh, is it one alert or a thousand alerts?" And if it's two variables, then suddenly if it blows a budget, he cannot manage it. So that's why they want that certainty and visibility into that pricing.

Sonal: So by certainty, you mean they don't want surprises?

Jyoti Bansal: Exactly. They need to be able to be reasonably predictable on this to not have surprises at the end to say, "Well, it's free and then we'll measure it in the future," but they don't know how to budget for it.

Sonal: How do you as a founder know that you're not leaving value on the table when you're giving that certainty or surety that this is what you're going to get?

Jyoti Bansal: If you put in a good ROI process as part of your sales process, that's how you guarantee you're not leaving money on the table. We had a very structured sales process. And in the sales process, we would look at what is your current state of doing this? How much is it costing you roughly? What would be a new state with AppDynamics and what would that cost you and how much money are you going to save? And then price is a little bit of a function of how much money are you going to save and what's your ROI. And if we are charging more than what's going to save them, they're not going to pay for it anyways. Most companies I see make the mistake of, especially when you're selling into large enterprise and you're asking for half a million dollars to someone, you don't back it up by a business case, people are not going to pay you. And then you leave a lot of money on the table. If your business case is strong, you would not leave money on the table.

Satish Dharmaraj: Yeah. We had a process called Business Value Assessment, BVA. It went along with the sales process in which we always had that premium positioning. And we enabled our sales to convey why we are premium. And secondly, we had those steering committee meetings in which the big check payer, we literally read out the ROI value use cases back to them so that they can justify internally as to why they are paying that premium. So giving that message so that they can repeat internally and justify it, that's what helps the part of the process and the premium that we can extract from the customer.

Sonal: So what I'm hearing you say is that sales enablement smoothed the road, kind of greased the wheels for you, but then on top of it, you played back and made sure to play back the ROI so that then your internal champion could continue advocating that this has value and keep moving that forward. One question I have is the third element you mentioned, Jyoti, in your framework, the value, that's the big kind of gray goosey area because that's the least measurable one. How do you know the value to the customer? Did you just say like the simple, what would the opportunity cost if their systems went down? Or did you think bigger than that? How did you figure that out?

Jyoti Bansal: The best way is to ask the customers. And this is something I would do in the product market fit phase. You don't have, a lot of people say, "What is product market fit?" It's a very philosophical question. What is product market fit? It's such a vague question. My simple definition is if you understand the business value of your product, that's when you know. And so the question that I used to ask in the product market fit phase was, "How would you justify the business case to your boss?" So like I'm talking to a director of DevOps. I'll say, "Okay, how would you make the business case to your boss if you have to buy AppDynamics?" And he'll say, "We had one outage a month. Every time you have an outage, you put six engineers there and this is how much it costs us. And because our users have bad experience, we lose this revenue. This is how much it costs us." And once I start hearing it, I know this is what I would like to teach our sales force how to make the business case. Because this is how the customers are articulating. And unless you understand the business case, you don't really have a product market fit. Because that's what you have to engineer your product around.

Sonal: Right. So you're saying the value is defined by the customers. Do you guys have any thoughts on how to define the value? That sort of loosey-goosey, vague thing of you want to make sure you're selling value.

Peter Levine: There's a couple of things which I've used in companies that I've run. If you look at competitive products, what are they, what's the chart, how much do those cost? There's an overall stack of technology. And if you're providing a certain solution, what is that stack in general? How do people, how have they budgeted for that? And then I always like this concept of charge more than you think in there. And you can always discount back to make sure that you're not really leaving value on the table. I didn't say money. I said value on the table, which I think is very important. The thing that is also I learned along the way is customers actually like to spend money for value. It's not a problem. We all do, even as consumers. And to come in with the low cost, like if your value is "we're lower cost" or whatever, that tends to be as soft as not standing up for the value that you're actually producing. And if you have the proper go-to-market, you have the proper product, and you have the proper positioning, then you can basically get the maximum dollars that customers are willing to pay. And everyone feels like it's a very fair transaction, that the value being delivered to the customer is very reflective of the price that they pay.

Jyoti Bansal: I think that the fair part is important. The customer will feel it's fair and you have to help them feel it's fair also by making that case. Yes, the competitive dynamic will also describe some of the price. If a competitor is selling for much cheaper, there may be some pressure on you to sell for that price as well. But in AppDynamics, we had a bit of that challenge. One of our primary competitors was priced much lower than us. And they were designed more for SMB. Their product wasn't as strong as ours for enterprise. And so internally, sometimes people will come in, "Hey, our competitor is charging much lower. Shouldn't we decrease our price also?" And I'll tell them, "Okay, do we really believe our product is superior? If our product is really superior, why would we not charge higher?" So we made a rule that we can always charge higher than them. We actually said that we always...

Sonal: So you resisted the downward pricing pressure.

Jyoti Bansal: Yes, because we can't get, if our product is superior, the customer is getting superior value. Either we are lying about it or we are misguided about it or whatever, that we believe it is, but it's not. Or we are not articulating the superior value. That's our problem. If our product has superior value and we know how to articulate and make the case about it, why won't we charge superior than that? And we always priced higher than our competitor because of that. And people are fine paying for it.

Peter Levine: And I think that to further that point, the articulation of value often comes with having a sales organization. That's what they do. And so when we often think about, "Hey, let's don't have a sales organization so we can build more product," often what gets missed in the whole product adoption cycle is the idea of selling value into the customer where value is not necessarily felt through a self-service product or whatever. You just can't see the value or appreciate the value until an organization comes in to actually promote those pieces that may not be self-evident.

Satish Dharmaraj: At the end of the day, it's all about marketing, getting products to the market. For that, you have the classical four Ps. Product doesn't go in isolation. Product, the pricing, promotion, and the place. At the end of the day, it's the customer. With an intimate knowledge of that customer and what exact pain process today and how you want to change it in the future, understanding that customer dynamic literally helps you define these four aspects. And that's what a good founder earlier on or a good product manager literally defines these metrics by understanding the customer.

Sonal: So those four Ps. That's what a good product manager should be doing. I was running the product line, the newest business IQ product line, both product and business operations. Is that an unusual model? Because you're an engineer who's doing product. Like what is the ideal way to essentially architect the product management or product org functions in this framework? Are product managers salespeople? Are they engineers?

Satish Dharmaraj: Depends on who your audiences are. To me, the product manager's first job is to understand the customer and the classic definition being the voice of the customer. So at AppDynamics, the product was technical. Our users were engineers in many ways. So all our product managers had an engineering background. But if I had a consumer product, I'm building a fashion app. My product manager probably would be very good in understanding my consumers as someone who's experienced in fashion.

Sonal: So it kind of matches the profile of your target customer.

Satish Dharmaraj: Exactly.

Sonal: Did you guys have different product manager profiles though for the one third of the organization that was doing the more evangelical startup within a startup next product line types versus the ones that were doing the core? Because I would imagine those are two different sensibilities and they may or may not transfer.

Satish Dharmaraj: Yes, we had, I would say the profile is a bit different. The product managers, once you have a V1 product kind of going from there, the profile could be a bit different. But at that point, you need multiple product managers. So you still want the product managers who could go and help create something disruptively unique feature set. But you also want product managers who are very good at understanding how is it working out in the market? And what's the adoption curve? And is the pricing working? So the product management skill set also has different things to it.

Sonal: What are the qualities to look for?

Satish Dharmaraj: We typically look for three aspects. During the initial phases, the empathy to understand that customer, to define your product. And the second aspect is the business aspects of, okay, how is it going to work with the sales? So literally the product managers, they travel with the salespeople and understand how do you position that value. Okay, now how do I price it? And so on and so forth. And the third most important thing is execution. Once you defined it, product doesn't come out of thin air. You need to work with the engineers, literally track your schedules and really execute it and deliver it to the customers. So these are the three aspects: the empathy, those business aspects, and finally, that execution. So these are the three skill sets that I typically look for in a very strong product manager.

Jyoti Bansal: They're very creative parts of product management: trying to come up with creative solutions as the second part and then scaling the operation behind it which is like a machine that can process the requirements from customers, from sales, figuring out the right pricing, packaging, all of that. So you want different skills.

Sonal: Seems like a bit of a unicorn to be honest.

Satish Dharmaraj: And many times it's not just one person. It's your product management then becomes a group over time and you want different people with different skills. That balances out the variety of skills. You complement each other's skills and that's the composition of an ideal team, why you have more than an individual contributor.

Sonal: Okay, so any parting takeaways? I'm sure you have a million takeaways, Jyoti, but any big message for our founders and other founders out there trying to do this, whether enterprise or not?

Jyoti Bansal: It was a good discussion on the product market sales kind of fit. But my primary advice I will give to founders listening to this is don't overthink too far ahead in many cases as well. The skills you need to master: zero to $1 million of revenue, find the product market fit. 1 to 10 million dollars, find the product market sales fit and iterate on it. Let's say 10 to 75 million dollars, scale the sales organization and your go-to-market. Then 75 million plus is when this "how do you build out product number two and product number three and product number four" starts. Anyone listening to this, I don't want them, when they are in the 0 to 1 million stage, trying to figure out how to do product number two. There's no point spending time on that. So the skills that you have to learn as an organization and also as a founder, they change as you go. And my advice to people: focus on the thing that you need to learn the most to get to the next milestone and excel at it. Then worry about the next one when you get there.

Sonal: That's a great piece of parting advice. And it brings us full circle to where we started in terms of how founders evolve as their companies do. And that's a fabulous framework. Thank you for joining the a16z podcast, Jyoti.

Jyoti Bansal: Thank you all for this wonderful conversation.

Peter Levine: Thank you, Jyoti.

Satish Dharmaraj: Thanks, Jyoti.