How to Find Product-Market-Sales Fit

One of the toughest challenges for founders — and especially technical founders who are used to focusing so much on product features over sales — is striking “product-market fit”. The concept can be defined many ways, but the simple definition shared in this episode is: it’s when you understand the business value of your product.

And that comes down to users, which is where the concept of “product-market-sales fit” comes in, observes Jyoti Bansal, founding CEO of AppDynamics (which was acquired by Cisco for $3.7B the night before it was to IPO). Bansal shares this and other key milestones and frameworks for company building in conversation with a16z general partner Peter Levine; enterprise deal team partner Satish Talluri (who was a director of product and growth operations there); and Sonal Chokshi.

So in that shift from product-market fit to product-market-SALES fit, how much should you optimize your go-to-market for product… and even the other way around? What does this mean for product design and product management? When should companies offer services? As for pricing, how do you know you’re not leaving value on the table? Again, it comes down to product-market fit: If your business case is strong, you will not be leaving money on the table, argues Bansal in this special podcast series on founder stories and lessons learned in enterprise go-to-market.

Show Notes

Discussion of product-market-sales fit, and developing products that can be sold [1:26]

How product and marketing strategy need to be aligned [6:52]

When a product has no existing market [8:55], and the importance of ensuring engineers understand the sales process [11:54]

AppDynamics’ approach to sales (top-down vs. bottom-up) [14:36]

Discussion of company building [19:33] and selling new products [24:28]

Prioritizing products, managing growth [31:15], and pricing and packaging [35:00]

Advice for assigning roles and responsibilities [45:28]

Transcript

Hi, everyone. Welcome to the “a16z Podcast.” I’m Sonal. Today’s episode continues our enterprise go-to-market podcast series. And 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? The conversation features special guests 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/16sales. And then we have a16z enterprise deal team partner Satish Talluri, since he too came from AppDynamics, where he was last a senior director of product and growth operations pre-sale to post-sale.

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 began 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.

Product-market-sales fit

Jyoti: I was working as an engineer in a company. And this was before the phrase you guys coined, on “software is eating the world.” This was 2008, right? But it was clear that software is eating the world, right? And 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. So if you are on online banking and something goes wrong in your online banking, you will use AppDynamics to figure out the root cause and fix it. Or if Delta reservation systems are down and everyone is stuck in the airport, someone needs to find tools to troubleshoot what’s the root cause of the problem and fix it.

That’s what AppDynamics built, those troubleshooting tools. So now it’s like, 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 you 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.

Satish: At least during the pre-product-market fit, a lot of engineers — even including myself — we get obsessed with the technology and not so much about the user. At the end of the day, if the user adoption is not there, it’s no good.

Sonal: I mean, there’s no market without the user.

Satish: Exactly.

Sonal: You got the product side and not the market.

Satish: Exactly. I feel a lot of engineers, to be honest — struggling about understanding the customer and user adoption and the engagement metrics without that good UI, UX. And really, [whether] it be the open source strategy or the closed door strategy — doesn’t matter — but user adoption is what should be driving the pre-product-market fit.

Jyoti: Now the challenges completely change after you have your initial product-market fit. They become all about sales and learning sales and scaling sales. And it’s almost like the companies go through that journey, right? The pre-product-market fit, the challenges are different. Then after pre-product-market fit, the challenge becomes about selling and scaling sales organizations.

Sonal: 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-egg thing.

Peter: Well, a lot of us start our careers as engineers, and a lot of our construction of a business is around the features, and around what the product does. It’s all technically oriented, right? Because what we often say is, “Okay, well, if we add these features, then people will come and buy it,” and I find that some of the go-to-market is an afterthought. Once you’ve built something, and 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 up front, along with the product requirements and technical requirements, may be a good thing to go and do. Like, I think, to sequentially order those probably results in an efficiency issue, right? We go build something and, oh, like, who knows how to go sell this and all of that. Might it be useful to say to technical entrepreneurs, “In order to do this, you got to go figure out the go-to-market as well as the product features, and don’t eliminate that or push that off?”

Jyoti: I would totally agree. The way I mentally think of this is, two phases of product-market fit. The phase one is really even figuring out where your target market is. So for that one, you really want to start broad and then segment. Like, if you don’t know <Yeah.> where would your idea or your product 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, which is a little bit wider.

Peter: And how did you guys come to that? Where did you start? You had this wide aperture, and then it narrowed. So what was the first thing?

Jyoti: To me, it was that people are building these complex software apps, and they need to monitor them well. <Sure.> And I had the technology idea that if you can instrument the code and trace everything, then it will 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 midsize companies to talk to, and see where it sticks the most — of where the most pain is.

And what I found was, okay, the most pain is where there are these, kind of, medium to large companies, which are building these complex distributed Java applications. So let me now focus more on that. So I started to broaden, then we started narrowing down a bit of the focus and — but after that, once you identified, then you — it’s very important that you marry the go-to-market model in your product thinking. Because these days it’s all very tightly coupled together. You don’t have, like, sales is different, then marketing is different, then product is different, then all — it’s all together in many ways, right?

So if you have an open source model, or you have a freemium model, or if you have a — is it SaaS, is it on premise, is it hybrid offered, is it going to be land and expand — and you have to engineer a product with that in mind.

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

Jyoti: So in AppDynamics, I used to say, like, 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: It’s like, have we found the right…

Peter: Oh, that’s a good one.

Jyoti: There’s a right market, and you have the right product, and we have the right sales or go-to-market strategy that works for it.

Sonal: 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: So, the thing of phase one is, like, where is the most pain — and where your product or your unique approach, or whatever it is, solves the pain in a way that people will pay for. And you’re also validating, like, your technology — does it really work? Can you really build the product? Does it really solve the pain? And then you have to figure out, like, what is the sales strategy or go-to-market strategy that will work and scale. And does your product support that? Because if your product doesn’t support it — you know, many times people are, like, we’re gonna build a freemium strategy. But the problem is, if a product is too complex, freemium doesn’t work.

Peter: But 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, right? And that if you’re going after a certain motion, or a certain customer, the product needs to be reflective of that. And I think we often miss there. Like, 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, I should say.

Jyoti: And some of it you can also break into, say, revenue goals. Like, I would roughly think getting to your zero to the first million ARR — you are in that phase one of product-market fit. Like if you have a product…

Sonal: ARR, as in the annual recurring revenue.

Jyoti: The annual recurring revenue, which is, like, do you have a product someone will buy and it’s solving something? Then you’re like, a million to the $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. And if you get that right — that, like, at $10 million, you should be there. Like, you got the product-market and sales fit as well. <Yeah, yeah.> And then you can press, you know, the gas — and go from $10 million to $100 million from there. But you got to get that iteration on the sales fit to it.

Products without an existing market

Sonal: So I have a question for you here. So 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? Because I think a lot of founders might argue that, “Well, why can’t I be like Steve Jobs and sort of invent — like, create the product that people all go to.” Like, what would you say that?

Jyoti: Well, you’re always creating — you know, either you’re solving a problem significantly better than others have done in the past. And that the dimension of what does significantly mean could be different. It could be you’re 10X more scalable, you’re 10X more easier, you’re 10X more cheaper — whatever it is, right?

Sonal: Right. All 10X better.

Jyoti: It has to be 10X better in some dimension. So in an existing problem, or if it’s a new problem that’s emerging — then it’s, you know — you still have — the problem has to be there. Either there’s a problem with existing vendors, or there’s a problem because there is no solution there. But it has to be there. Otherwise, you don’t have anything to sell.

Peter: And I think in enterprise more than consumer, there’s a budget — there’s a certain budget dollar that you’re gonna go after in enterprise. Maybe it comes out of the development budget, it comes out of engineering, marketing, sales. There’s something for which you can at least start to frame this new thing, new market, whatever. Like, one of the questions to ask is, “Who’s the potential buyer for this?” Even if it’s a totally new market, right? But let’s call it an enterprise product somewhere — doesn’t exist before. Still, who’s the buyer? And what budget does it come out of? And a lot of products, actually, where there isn’t a market yet, may span multiple buyers, in fact — may come from multiple different departments and span budgets. And you need to think about that, like, okay — I’m creating this new market, but perhaps the buying motion and what the customer is used to actually doing, from a buying behavior, is so complicated, it’s never gonna happen.

Satish: Yeah. Even for the product managers, or the founders, it always helps to do a sales kind of play. Wherein, how exactly you’re 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 you’re going to solve. And what exactly — how exactly the user is going to use your product.

I think, working with the salespeople who are actually on the frontlines to go and sell — for the engineers and the product managers, it really helps. And in fact, at your company, you made a lot of engineers to 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. So that connection for the engineers — to go on those sales calls — really help them to understand that sales motion, and how to incorporate [it] into that product. That’s one of the best practices I love. So that’s how engineers always got to understand that sales motion.

Jyoti: We had that strong belief is — just that we have to break the barriers between engineers and customers. In the startups I’ve worked at before AppDynamics, as an engineer, people will say, “Engineers don’t know how to talk to customers, so let’s keep them away from customers.” And so we’re selling to engineers — like, our products are technical and, like, you know — so that just doesn’t make any sense to me.

In the early days of finding the business case — the finding, like, you know — where the budget will come from — one of the questions that we always ask — like, my favorite question to ask to any customer was, “How would you make the business case to your boss to buy this?” And that’s when you would start hearing like, this is my business case. Like, every time we have an outage, we’re normally spending six engineers in a room for five hours to try to figure this out. Now, with you guys, I can reduce it down to one engineer for 15 minutes. And that’s my business case. And once you start hearing the business case, then you can know that there is a business case — you can monetize it, and you can convert into dollars at some point, right?

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. And how do you sort of up-level it, so that you’re selling into getting the big bucks — and not just, sort of, the incremental budget?

Peter: I mean, I would say 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 — and then they get enough use on individual users and propagation from the bottoms-up. I call that self-serve. So there’s no complexity there. There’s no multiple buying centers or whatever.

Sonal: Right. You just decide.

Peter: So it’s not a foregone conclusion you just — you know, that that is the way to go. Now, after enough people are using the product, then you can come in with tops-down and say, “Hey, did you know like everyone in your organization is already using the product? You ought to have a corporate-wide license so we can private support and all of that.” So that would be an example of bottoms-up and then coming in on tops-down.

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, <Security needs.> there’s security needs, whatever — where a bottoms-up design just doesn’t work, right? In which case, then, you probably need to start with a more traditional — I’ll say a direct sales organization. It could be an inside sales organization or direct, calling in and actually getting the customer. I mean, complex sales often requires multiple buyers, multiple parts of the organization to come together. And that’s a skill set that a well-honed sales organization will know how to do.

Top-down vs. bottom-up sales

Sonal: How did you guys — what was your sales motion at AppDynamics?

Jyoti: So ours was a combination of both. You know, at AppDynamics we call it the Sandwich Strategy. You go from the bottom, you go from the top, you will go to the developers and DevOps engineers directly. It was done through a freemium kind of model, so that they will start for free, and they can use a light version of a product for free. And then we will start going from the top, where we’ll create air cover and, like — when we have multiple users in an organization, then we’ll go and sell them more. So really, the sales motion was built on — the end users can start for free, then we’ll have — sell them, like, some license of it. We call it “land and expand.” The land deals, which are like, you know — say, $20,000, $30,000, $50,000 deals. On [the] phone, we can sell that. And then we’ll expand into, like, half a million, million dollar, $2 million. You know — now, these days, $10 million deals. So that — you’ll need traditional enterprise salespeople where you will do that.

Sonal: Right. So inside sales versus field sales, basically, in that context. No? Not right?

Jyoti: Yes, but in most of these companies today, you would probably need both. <Okay.> So it, like, depends on, like — if the model is only top-down, you probably need only field sales, and you’re selling into large enterprises. But if a model is this kind of a “land and expand,” you want to do the land through fee inside sales, and you want to do the large — the expand into — [with] field sales.

Satish: Yeah. And of late, we are seeing scenarios in which once you go to the top — and if they are big enterprises, services has become a very important component of it. To be honest, a bottoms-up developer option, 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.

Sonal: So tell me the takeaway on services, because I’ve always heard — and disillusion me if this is not correct — but services are the things that reduce your margin. So you don’t want to have too many services. Or, what’s — how do you balance that one?

Jyoti: “It reduces the margin” is from the perspective of you as a vendor. But think from the perspective of a customer — like, if they spent a million dollars on your product, and they’re not getting the value of a million dollars, because they didn’t have enough — the right people in place to implement your product — that’s not good for them. And eventually is not good for you, because you’re building a — likely a recurring revenue business of some kind, right? When we started, we were like, we’re not gonna sell services — not from a margin perspective — because we wanted our product to be easy enough that no one needs any services. And that was true for a long period. For the — actually, for the first four years, we had zero services. And then we started getting into larger and larger enterprises, and larger and larger deals, where people were spending millions of dollars with us.

Sonal: Yeah, you want to save that money.

Jyoti: Yes. And we figured out like — if they don’t buy any services, sometimes no fault of our product — they just don’t get that option that we want. And then we were like, yes, so — like, too much services, then the margins are low, right? But we’ve found the right balance was about 10% to 15%. So like, if in our products — if, like, people are buying — let’s say, they’re spending a million dollars with us on the software, and they spend, like, $100,000 or 10% to 15% on it on services, their adoption is much better and much faster.

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

Jyoti: Eventually if your users are getting adoption and [are] happy with the product, the money will come. The margins will come, right? So you have to figure out, like, people are getting value or adoption or not.

Sonal: Margins will come, I like that phrase.

Peter: If you think about, in that example — let’s say 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, right? <Right.> So while services from a unit economics standpoint may be, you know, a little more expensive from a margin standpoint, if it drives very large deals <You come out ahead.> with software margins, you come out way ahead. So 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: And the renewals. Like, the year two, year three, year four renewal offer, right? <Right.> So if you spend — 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. So the margins for those will go up.

Satish: At the end of the day, adoption is what counts for a product, right? And services help. And 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 $1 million, and if they’re not using it?

Sonal: Just sitting on the shelf, right.

Satish: 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 that’s why 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. Adoption and the product — services is a necessary complement after sometime.

Company building

Sonal: It goes hand-in-hand. That’s right, I’m really glad you brought that up, because I want to segue to talking about the company building side of this. So, you’re describing the sales motion to customers — and the product-market fit pre-product-market, pre-product-market-sales fit, and post. Let’s spend the rest of the time connecting it back to what happens inside the company. So you’re describing the product — how does this affect the product roadmap? Like, when you get all this feedback from customers, and you have the sales motion in place, how does this then drive back inside your company to further developing more features on a product — making those balancing decisions for what goes into the core, to what goes into the custom, to what goes into the next iteration? Kind of, tell us about those trade-offs.

Jyoti: It depends on different stages of the company. When you are in the very, 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 or so. And, you have to listen to the customers. That’s the product-market fit exercise, the customer validation exercise and all that, right?

Sonal: Are they paying for this thing, too.

Jyoti: Yes. And once you have customers, and then you, like — how you prioritize becomes what you’re hearing from customers, what will it take them to be successful and adopt the product more and buy the product more. And 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, they are watching, like what’s working, what’s not working. Then sales is trying to expand and get more customers. So you have to work with them as well, because [of] your competitive pressures. You have to, like, catch up to competitors on some features sometimes.

And so you have to make sure that you’re winning enough in the market, you can get enough revenue, and you prioritize that also. But then there’s a third part, which is, like — you also want to keep expanding your product, which are things that your current customers are not asking for, but you need them for expanding your addressable market for customers, right? And that’s where it’s — from a product perspective, it’s a balance of those three things, right? It’s the — 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?

Sonal: So win and keep now, to what do you need in the future to win.

Jyoti: Yes. And the rule of thumb that I followed — that was [that] two-third of our engineering investment should go with our existing TAM. <The core base.> And the one-third of our engineering investment, we should keep putting on expanding our TAM always. So our total addressable market, right? So when we started with, like, let’s say our initial v1 product was application monitoring for Java applications. And that was our TAM. Once we had that — like, we’ll start putting one-third of our engineering on expanding it to the next addressable market, which is application monitoring for .NET applications. After a year, that became part of the .NET — our product became Java and .NET. Now we look, okay — what is the next addressable market where I can put another one-third of my engineering. And then we kept doing it systematically for seven, eight years. And we just kept expanding our TAM.

Sonal: So the two-third, one-third rule.

Satish: Yeah, but the interesting aspect, even in — 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, because the sales motion is already oriented towards it. So it’s like those agencies — be it .NET, or the end user monitoring, and so on, so forth — still, it’s targeting the same buyer and user, so that you can leverage your existing go-to-market sales motion. That didn’t cause too much of — distractions on the go-to-market side. That really helps expand your product portfolio, but at the same time, leverage your existing sales motion to go and attack and expand the market. So understanding that if you change both product and also your sales motion, suddenly — then it’s almost like, again, building from scratch, and that causes lots of disruptions in the company.

Peter: That’s exactly right. I mean, 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’s 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, <Mm, interesting.> but you may have a new customer, it may be a new market motion, whatever.

And the old organization may not be — because they’re at a mature level of selling an existing product, and 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 might not be able to do it, and 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 — let’s say, for a completely different market in there — and nothing happens, right?

Jyoti: And that — we learned that at AppDynamics the hard way.

Sonal: Tell us why, how it was the hard way.

Peter: Yeah. A lot of companies do.

Jyoti: Yeah, because we built our first product, and it was selling, and the sales process was mature. We were a mature sales organization. Now we started building our second product. And, sort of — you have a mature sales organization, [so] let’s give them the second product to sell. They started selling the second product and they failed at it. And I was, like, these people are so good [at] selling — they’ve been so successful at it. But the challenge is, like, when you have 100 customers and you have like 50 references and you have — like, you are in the Magic Quadrant for something, everything is well refined. And how you sell is different than when you’re a brand new product with zero customers. So they just started struggling.

And they say your product sucks, and this new product is not good, so let’s just throw this away. We should not build any new product. And I was, like, if you’re not going to build new products, our growth will slow down. So we have to learn how to make [it] and sell it. So we internally structured as like — if we were good at selling a new product, so what changed? So maybe we should build a model which uses the same thing that worked for the very first product. So we reorganized ourselves in a model — like, all startups within a startup. So, like, we are a startup, but we’ll form new startups inside it. And we’ll sell the same way — the way we sold our first product in the beginning.

Peter: Right. This is a well known problem. Often the second product never takes off because it’s — it doesn’t get the visibility or attention or expertise that’s required when a new product is released.

Jyoti: And there’s a sales compensation aspect to it also. Because the salespeople, they 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.

Sonal: Because you’re not gonna make your numbers. So how did you adjust the compensation accordingly?

Jyoti: So you almost have to create a separate, almost evangelical new sales team whose job is to do that, like the way you…

Peter: Yeah, just like you did 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.

Sonal: So this connects the dots between the idea of a startup within a startup, the evangelicals or evangelism that you mentioned, and a different sales learning curve for each — they’re kind of all the same thing. That makes a lot of sense. 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 the solution.

Peter: 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 salesforce?

Sonal: Well, what’s the answer? I’m asking you guys. <laughter>

Jyoti: Well, I’ll tell you what we did. So what I brought into AppDynamics was that we said the sales learning curve has three phases. One is the — my first 25 customers for the product. 25, that’s like phase 1. Which is very, very — almost the founders are selling…

Peter: We call that the initiation phase. Go ahead.

Jyoti: Yes. There’s the 25 to 100 customers. And then there’s 100 — after 100 customers, a mature product, we can — our salesforce can sell it.

Peter: Yes, that’s the execution phase.

Jyoti: So the first 25 customers for the new products, we actually got the product management team <Exactly, yeah.>  to really sell it the way your founders will sell in a brand new startup — instead of hiring a new salesforce for that. But after that, our salesforce could take it. The phase two, they could take it. The same with phase three — they were good at it anyways.

Satish: So for our fourth product line, which we call Real Time Business Monitoring, this is exactly what we observed. The existing salesforce was, like, 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 SWAT 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 salesforce — even not everyone. And once we hit that first 10 salespeople, they are cracking it. They’re making more money with better incentives. Then the rest of the salesforce 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 SWAT motion for, like, eight months.

Peter: 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. 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, right? You want to, like, 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, like, 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 a 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 or whatever, as a CEO.

Satish: Yeah, literally what Peter said — once we did this SWAT motion and created those initial amazing sales — the big dollar sales, upwards of 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. Now, 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…

Sonal: They want to get on board.

Satish: Exactly, I want to get onto the train.

Peter: Yeah, 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 promote.<Rally the team.> They’ll rally the team around this. So it’s very important to make sure you’re focused on a few things that are really gonna work well. And don’t let it, from a leadership standpoint, get out of control. Like, it’s great for people to try experiments and all that. But don’t let it get mainstream until you know it’s gonna be mainstream. Otherwise, there’s 50 products on the price list, and everyone’s fighting for visibility and it becomes…

Jyoti: And it’s very distracting also…

Peter: Very distracting.

Jyoti: The salesforce is expensive. So if you take your salesforce 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 salesforce.

Prioritizing and managing growth

Sonal: Right. So tell me, though, as the leader of the company then — because you have these processes inside, I’m hearing the broader context of the trade-offs 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, in 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: Our process, I would say, as a startup — most of it in our case came from that two-third, one-third rule. Like, one-third of our engineering investment, we can put on expanding our addressable market. The two-third 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, like, new use cases, new addressable markets, new addressable 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 when we say, okay — we want to get to $100 million revenue. And how would our business look like? And how much we can do at a fast pace without our existing products, and what we will 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 it 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, like, when we did the math — and this is, again, a rough math. Like, you never know. That if we want to get to a billion dollars of revenue from $100 million in, like, 7 years, let’s say — or 6 years, our plan was — we need to have, like, 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, like, what you can do from a bottom-up investment perspective. Like, engineering the sources and what you need top-down to get to a billion dollar revenue goal.

Sonal: Right. It’s working backward to provide the focus.

Jyoti: And you need to do both. <Right.> Define the intersection of, like, what you can do bottom-up. You can’t build 10 new products, so you — what you can build — and then what you need to build to get to some kind of revenue long-term goal you have.

Peter: And at that point in time is probably when you start to have an M&A function in the company, to start looking at, outside…

Sonal: Why?

Peter: 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 in 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 gonna build 10 new products, if that was the envelope that you’re — or even three products, 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? And both have their challenges, but that’s another function inside the company that usually comes about that point in time.

Jyoti: Like, we acquired three small companies. You know, we did that for different things, but sometimes it’s like just accelerating the time to…

Sonal: As I just say — it seems like it comes down to speed to market and what the competitors are doing.

Jyoti: The speed. Yes. Like, if you build from scratch, like, 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. <Yeah, for sure.> But if we acquired something, we could probably cut down from two or three years to half of it, right? So maybe, like, maybe even 75%, in some cases. So that’s always a factor.

Pricing and packaging

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 they’re 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: 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, like — the rule that I’ve used for pricing is, can your salespeople describe it simply? Like, a customer is going to ask a simple question. “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, like, nuances to it, and there could be, like, details to it, but you have to be able to describe. Like, in AppDynamics, we’re monitoring all kinds of different systems, right? So the pricing was complicated. But we said, okay, the simple pricing philosophy that our salespeople can tell us — 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, right? And that’s at least simpler, that your pricing philosophy is simpler for people. So that was my rule number one.

Rule number two, there was — that whatever the pricing is measurable, because if it’s not measurable, and now the customer says, “Okay, how many licenses do I need to buy?” Our salespeople cannot even tell them very clearly like, okay — this is how you measure how many you need to buy. However, it will create a lot of friction. Or like once they buy it, we can’t measure and track, like, how many are using it. That’s a problem as well, right? So if we can describe our pricing in half a sentence, that’s one. Second is that it’s measurable, that people can measure presale, and people can measure post sale — we have a good pricing system. The question after that is, okay — what is the price, like the dollar price of it on — for that model per license, how much you pay? That really to me — it comes down to business value. And enterprise software, especially selling to large enterprises, I argue to most founders that you should price more than you think you should.

Sonal: So we always say raise prices. That’s our mantra around here.

Jyoti: Exactly. So, price higher. You can always discount. If there’s not value, you can always discount. And customers are not gonna pay more than what the thing they should pay anyways. So you can always discount and then go there, instead of pricing low.

Peter: 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, you know, air vents your server has, right — let’s just say. You have to come up with pricing that the customer is used to actually paying for. If you start to create something that’s 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, what does that mean?”

Sonal: So I’m hearing you say [to] founders out there, be creative with your product, but don’t get creative with pricing. Like, do what you need to do that makes sense to the buyers.

Peter: Exactly.

Satish: This difference between consumer purchase versus enterprise — enterprises, they need a little bit more certainty. You’re getting it from a budget, right? They’re already pre-planned. That’s one. <Right.> And they want certainty, in the sense that — oh, is it one alert or [a] thousand alerts? And if it’s too variable, then suddenly if it blows the budget, [they] cannot manage it. So that’s why they want that certainty and visibility into that price.

Sonal: So by certainty, you mean they don’t want surprises.

Satish: Exactly.

Peter: But you 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: But how do you, as a founder, know that you’re not leaving value on the table, when you’re giving that certainty — or, like, surety that this is what you’re gonna get?

Jyoti: If you put in, like, the — a good ROI process in your — as part of your sales process, that’s how you guarantee you’re not leaving money on the table. We have a very structured sales process. And in the sales process, we would look at, like, you know — what is your current state of doing this? How much is it costing you roughly, let’s say? 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 that’s — if we are charging more than what it’s gonna save them, they’re not gonna pay for it anyways, right? Most companies, I see the mistake of, like — especially selling into large enterprise, and you’re asking for half a million dollars [from] someone — if you don’t back it up by a business case, people are not going to pay you. <Of course not.> And then you leave a lot of money on the table. If your business case is strong, you will not leave money on the table.

Satish: 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 pair — we literally read out the ROI value use cases back to them, so that they can justify internally as to why they’re 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 it.

Sonal: So what I’m hearing you say is that sales enablement created — it 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 it has value and keep moving that forward.

Jyoti: And justify that premium pricing.

Sonal: 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 the opportunity cost [is] if their systems went down? Or did you think bigger than that? How did you figure that out?

Jyoti: The best way is to ask the customers. And this is something I would do in the product-market fit phase. A lot of people say what is product-market fit, even the initial one?

Sonal: It’s a very philosophical question. What is product-market fit?

Jyoti: Yeah. And such a vague question. My simple definition is, if you understand the business value of your product, that’s — then you know. And so, you know, 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, say, a director of DevOps. I’ll say, “Okay, well, how would you make the business case to your boss, if you have to buy AppDynamics?” And they said, “We have one outage a month. Every time we have an outage, we put six engineers there, and this is how much it costs us. And because our users have a bad experience, we lose this revenue. This is how much it costs us.”

And once I start hearing it, I know, like — this is what I would — I would like to teach our salesforce 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: There’s a couple of things, which I’ve used in companies that I’ve run, is — if you look at competitive products, what are they? What’s the chart? How much do those costs? 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, right? Even as consumers, it’s not a problem. And to come in with the low cost — like, if your value is that 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, and 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: I think that the fair part is important. <Yeah.> Customers have to 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 <inaudible> on the price. If a competitor is selling for much cheaper, there may be some pressure on you to sell for that price as well, right?

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’ve made a rule that we can always charge higher than them. We actually said that it would be always…

Sonal: So you resisted the downward pricing pressure?

Jyoti: Yes. Because, if our product is superior, we are — the customer is getting superior value, either we — either we are lying about it, or we are misguided about it, or whatever — that we believe it is, but it is 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 them? And we always priced higher than our competitor because of that, and people are fine paying for it.

Peter: 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.

Roles and responsibilities

Satish: At the end of the day, it’s all about marketing — getting products to the market, right? And for that, you have the classical four pieces. So, product — it 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 [they have] 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 P’s.

Satish: Yeah, 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.

Sonal: 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?

Jyoti: It depends on who your audiences are. To me, the product managers’ first job is to understand the customer and, you know — the classic definition, being the voice of the customer. So at AppDynamics, our 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 — you know, I’m building out a fashion app — my product manager probably would be very good [at] understanding my consumers as, you know, someone who’s experienced in fashion. So for any business I’m doing, I would hire a product manager who can understand my end users very well.

Sonal: So, kind of, matches the profile of your target customer?

Jyoti: Exactly.

Sonal: Did you guys have different product manager profiles, though, then — 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 might or may or may not transfer.

Jyoti: Yes, 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, you know, go and help create something — disruptively unique feature set, etc. But you also want, like, you know — product managers who are very good in understanding the, “How is it working out in the market,” and “What’s the adoption curve?” and “Is the pricing working?” So, you really — you know, the product management skill set also has different things to it, right?

Sonal: What are the qualities to look for?

Satish: 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 sale? 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, so forth. And the third most important thing is execution. Once you define it, product doesn’t come out of thin air, right? You need to work with the engineers, literally attract your schedules, and really execute it and deliver it to the customers, right? So these are the three aspects — the empathy, and those business aspects, and, finally, the execution. So these are the three skill sets that I typically look for in a very strong product manager.

Jyoti: There are very creative parts of product management. Then trying to come up with creative solutions is 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, right? So you want different skills.

Sonal: It seems like a bit of a unicorn, to be honest, to have all three.

Jyoti: And many times it’s not just one person, right? It’s — your product management then becomes a group at that time, and you want different people with different — like, that balances out the variety of skills.

Sonal: Right. It’s just like a good team, you complement each other’s skills. And that’s the composition of an ideal team — why you have more than an individual contributor. Okay, so any parting takeaways given your — 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: 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. Like, the skills you need to master, $0 to $1 million of revenue, find the product-market fit, $1 million to $10 million, find the product-market-sales fit, iterate on it — let’s say $10 million to $75 million, scale the sales organization and go to 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…

Sonal: That’s a great framework.

Jyoti: Anyone listening to this, I don’t want them to, like, you know — when they are in the $0 to 1 million stage, they’re trying to figure out how to do product number 2. There is no point spending time on that. So the skills that you have to learn and the organizationally — 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.

Jyoti: 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.

Peter: Thank you all for this wonderful conversation.

Jyoti: Thank you, Peter.

Satish: Thanks, Jyoti.