a16z Podcast - How to Find Product-Market-Sales Fit

Episode Date: September 3, 2022

In this episode from February 2019, Jyoti Bansal, founding CEO of AppDynamics and co-founder of Unusual Ventures, joins a16z general partner Peter Levine, a16z partner Sateesh Talluri, and host Sonal Choksi to discuss how product and sales evolve together for enterprise go-to-market, including key milestones for both product development and marketing, frameworks for how to think about pre- to post-product market fit, the role of additional levers like services or pricing, and more.For the show transcript, you can go here.

Getting to product market fit is one of the key milestones for any startup, but for enterprise and B2B founders in particular, and especially those who are more technical or are most comfortable when focusing on product features, finding product market fit often requires a strong strategy around how you sell that product to the market. And in this episode from February 2019, Joe T. Bunsell, founding CEO and founder of App Dynamics, joins A16Z general partner Peter Levine, A16Z partner Satish Talurie, and host Sonal Troxie to discuss how product and sales evolve together for the enterprise go-to-market, including key milestones for both product development and marketing, frameworks for how to think about the phases from pre-to-post-product

market fit, the role of additional levers like services or pricing, and more. Hi, everyone. Welcome to the A6 and Z 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 boat 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 guest Joti Bonsal, founder and founding CEO of App Dynamics. He's also a co-founder at Unusual Ventures and co-founder of Harness. Joining me to

interview Bunsell, we have general partner Peter Levine, who also put out a series of 16 short sales videos for founders, which you can find at A6&Z.com slash 16 sales. And then we have A6&Z Enterprise Deal Team partner Satish the Lurie, since he too came from App Dynamics, where he was last as 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 It's 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 Jotis, followed by Sathes, talking about the initial insight behind app dynamics, which was acquired by Cisco last year for $3.7 billion the night before it was set to go public. 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 in the, 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 monitoring, building monitoring and troubleshooting solutions for complex software apps. So if you are online banking and something goes wrong in your online banking, you will use AbDynamics to figure out the root cause and fix it. Or if Delta reservation systems are down

and everyone is stuck on the airport, someone needs to find tools to troubleshoot what's the root cause of the problem and fix it. That's what AbDynamics build 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 AbDynamics,

so you had to go and figure out 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, even including myself, we get obsessed with the technology. I'm not so much about the user. At the end of the day, if the user adoption is not there, it's no good.

I mean, there's no market without the user. Exactly. You got the product side, but not the market fit part. I see a lot of engineers, to be honest, struggling about understanding that customer and user adoption and the engagement matrix without that good UI, UX, and really be the open source strategy or the close source strategy, it doesn't matter. But user adoption is what should be driving the pre-product market fit. Now, the challenge is completely changed.

you have your initial product market fit, they become all about sales and learning sales and scaling sales. It's almost like the companies go through that journey, right? You know, the pre-product market fit, the challenges are different. Then after product market fit, the challenge become about selling

and scaling sales organizations. 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.

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 have these features and 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 you know self-serve or whatever thinking about that up front along with the product requirements and technical requirements maybe maybe a good thing to go and do like i think we 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, you know, in order to do this, you've got to go figure out the go-to-market as well as the product features and don't eliminate that or push that off. 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, where would, you know, 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. And 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. You know, to me it was that people are building this complex software apps and they need to monitor them well. And 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.

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 broad and then we started narrowing down a bit of the focus. But after that, once you identify it, then it's very, important that you marry the go-to-market model in your product thinking. Because it's, it's, it's, it's, it's all very tightly coupled together. You don't have like, you know, sales is different than marketing is different than product is different than all of it. It's all together in many ways, right? So if you, if you, if you have an open source model or you have a freemium model, or if you have a, you know, is it a SaaS? Is it on-premise? Is it hybrid of it? Is it going to be land and expand? And you have to engineer a product with that in mind. 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, reflect the go-to-market attributes that need to be considered. So in Nabonomics, 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. Oh, I love that.

It's like, have we found the right, you know, there's the right market and you have the right product and we have the right sales or go-to-market strategy for it. That works for it. 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. So it's a thing of phase one is like, you know, where is the most pain? And where your product or your unique approach or whatever it is solves the pain, you know, 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, you know, we're going to build a premium strategy, you know. But the problem is if a product is too complex, premium doesn't work. 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 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. And some of it you can also break into, say, revenue goals. Like, you know, I would roughly think getting to your zero to the first million error, you are in that phase one of product market fit.

AAR is in the annual recurring revenue. annual recurring revenue, which is like, you know, do you have a product someone will buy and it's solving some fane? Then you're like, you know, a million to the 10 million in revenue, that's where you're trading 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 where like, you know, you're, you got the product market and sales fit as well. Yeah. And then you can, you know, press, you know, the guests and go from 10 to 100 from there or like, you know, but you got to get that iteration on the, that sales fit to it.

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, quote, 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 I be like Steve Jobs and

sort of invent, like create the product that people. all go to? Like, what would you say to that? Well, you're always creating, you know, either you're solving a problem significantly better than others have done in the past. And the dimension of what does significantly mean could be different. It could be your 10x more scalable, your 10x more easier, your 10x more cheaper, whatever it is, right?

Right. 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'll still have the problem has to be there. Either there's a problem with existing vendors or there's problem because there is no solution there. But it has to be there. Otherwise, you don't have anything to sell. And I think in enterprise more than consumer, there's a budget, there's a certain budget dollar that you're going to 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 enterprise products 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 going to happen. Yeah. 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 is the actual user. What are you going to say to the user? What pain points you are going to solve and how exactly the user is 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.

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 into that product. that's one of the best practices I loved. So that's how engineers always got to understand that sales motion.

We had that strong belief, is just that we have to break the barriers between engineers and customers. In the startups I 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 are 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 question that we always ask, like, you know, 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, you know, every time we have outage,

you know, we normally spending six engineers on the, 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 it into dollars at some point, right? 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? I mean, I would say it all depends, again, on this product market sales stress. 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. So it's not a foregone conclusion that 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 or 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, you know, a well-honed sales organization will know how to do. How did you guys, what was your sales motion at App Dynamics? Ours was a combination of both.

In AppDynamics, you call it the sandwich strategy. The sandwich strategy. You go from the bottom, you go from the top. We'll 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,

you know, where we will 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, you know, the end users can start for free. Then we will have sell them like some, license, we call it land and expand. The land deals, which are like, you know, say, a $20,000, $30,000, $50,000 deal. On phone, we can sell that. And then we'll expand into like half a million million, $2 million, you know, now these days when $10 million deals. That will, that you need traditional enterprise people. Right. So inside sales versus field sales, basically in that context. Yes. But you, in most of these companies today, you could, you would probably need both. Okay. So you, like, you know, depends on like, you know, if the model is only top down, you probably need only field sales. And you're selling into large enterprises. But if a model. But if a model. is this kind of a land and expand.

You want to do the land through inside sales and you want to do the large, the expense and do with field sales. Yeah, and off-light, we are seeing scenarios in which once you go to the top and if there are big enterprises, services has becoming a very important component of it.

To be honest, bottoms up a developer-ed option, great land, but once you expand and once you get into multiple product portfolios and into complex integration, services is essential component of the enterprise sales.

So tell me the takeaway on services, because I've always heard, and disillusioned me of this, I said, this is not correct, that services are the things that reduce your margin. So you don't want to have too many services. Or how do you balance that one? It reduces the margin is from the perspective of you as a vendor. But a thing from the perspective of a customer, like 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 enough the right people in place to implement your product, that's not good for them

and eventually it's not good for you because you're building a likely a recurring revenue business in some kind, right? When we started, we were like, we're not going to 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, you know, for a long period. Actually, for the first four years, we have zero services. And then we started getting into larger and larger enterprises and larger deals where people were spending millions of dollars with us. Yeah, you want to save that money. Yes. And we wanted, we figured out like, you know, if they don't buy any services, sometimes no fault of our product, they just don't get that option that we want. So we, what, and

And then we were like, yes, if too much services, then the margins are low, right? But we found the right balance was about 10 to 15%. So like if we, if in our products, if like, you know, people are buying, let's say, they're spending a million dollars with us on the software and they spend like, you know, $100,000 or 10 to 15% on it on services, their adoption is much better and much faster. So ideally you actually make more money on the upsells and cross sales and more feature expansion based off that 10 to 15%. You know, eventually if your users are getting adoption and 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. Margins will come. I like that phrase. 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, may be, you know, a little more expensive from a margin standpoint. If it drives very large deals 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, two million dollar license.

It's just expected as part of that. And the renewals. Like, you know, the year two, year three, year four renewal offer. Like, so if you spend, if, you know, 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. At the end of the day, adoption is what it counts for a product, right?

And services help. And also keeping us head the financial aspect, even from a product aspect, it's good in the sense that we hate shelf fare. What good is it if some enterprise bought one million and if they're not using it? Just sitting on the shelf, right. 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 we 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 isn't necessary. It goes hand in hand. 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 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. 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 the 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 tradeoffs. It depends on a different stage of the company. When you're in the very, very early stage,

you're 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 customers. That's the product market fit exercise, the customer validation exercise and all that, right?

Are they paying for this thing too? Yes. And once you have customers, And then you then you're, like, you know, what, 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 you're, as a, as a product team's ears are open, listening to customers, listening to customer support, customer success, they are watching the tickets. They are watching like, you know, what's working, what's not working. Then, you know, sales is trying to expand and get more customers. So you have to work with them as well because they have competitive pressures.

you have to catch up to competitors on some features sometimes. And so you have to make sure like you're winning enough in the market. You can get enough revenue and you prioritize that also. And but then there's a third part which is like you also want to keep expending your product, which are things that your current customers are not asking for, but you need them for expending your addressable market for customers, right? And that's where it's a from a product perspective, it's a balance of those three things, right?

You know, it's the what do we need to win more revenue today? you know, what do we need to keep our customers happy? And what do we need to win more revenue two years now? So win and keep now to what do you need in the future to win? Yes. And the rule of them that I followed there was 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, our initial V1 product was application monitoring for Java applications, and that was our TAM. once we had that we'll start putting

one third of our engineering on expanding it to the next adjacent market is which is application monitoring for dot net applications after a year that became part

our product became Java and dot net now we look at what is the next adjacent 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 time so the two-third one-third yeah but 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 because the sales motion is already oriented towards it. So it's like those agencies, be dot net or the end user monitoring and so on and 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 help 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. 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, but you may have a new customer, it may be a new market motion, whatever, and the old organization may not be capable 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 event,

Angeles 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, let's say for a completely different market in there, and nothing happens, right? And we learned that at Abdonomics in the hard way. Yeah.

Tell us why. A lot of companies do. Yeah, because we built our first product and it was selling and the sales process of mature, we have a mature sales organization. Now 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 in selling,

there's being so successful in it. But the challenge is like when you have 100 customers and you have like 50 references and you are in the magic quadrant for something and everything is well refined and how you sell is different. 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 we should 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 sell it. So we internally structured is like, we were good at selling a new product. So what changed? So maybe we should build, you know, a model which use the same thing

that worked for the very first product. So we reorganize ourselves in a model like all startups within startup. So, like, we are a startup, but we'll form new startups inside it and we'll sell the same way, you know, the way we sold our first product in the beginning. 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. And there's a sales compensation aspect to it also. Absolutely. Because the salespeople, they can sell the mature product, and which is easy to sell at that point and make their number of,

by doing it. Now you give them something a new product which is much harder to sell. Because you're not going to make your numbers. So how did you adjust the compensation accordingly? 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 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. And 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. Well, I'll tell you what we did. So what I broke into into AppDynamics was that we said the sales learning cover is three phases. One is my first 25 customers for the product. 25 to that's like phase one, which is very, very almost the founders are selling. We call that the initiation phase. Yes, there's the 25 to 100 customers.

And then after 100 customers is a mature product, we can, our salesperson can send. 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.

So for our fourth product line, which we call real-time business monitoring, this is exactly what we observed. The existing Salesforce was a lot more tuned to selling the existing product because it was 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 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 SWAT 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. 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 they and it was for a hundred and fifty thousand dollars 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 And doing something as simple as that from a leadership standpoint also has, you know, 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. 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, 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 the 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. They want to get on board. Exactly. I want to get on to the train.

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 promote their rally the team, right? They rally the team around this. 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. Like 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 also. 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. 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 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 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? 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. 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, you know, 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 call out path to 100 million revenue. And when you say, okay, we want to get to 100 million. 100 million revenue and how would our business look like and how much we can do at a fast pace with our existing products and what we would need to add to the new products to get there. And then we also have sort of a rough timeline with it. But that's 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 like, you know, when we did that math, and this is again a rough math, like you even 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 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 resources and what you need drop down to get to a billion dollar revenue goal. Right. It's working backward to provide the focus. And you need to do both.

Right. And find the intersection of like 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. 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. You know, 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 App Dynamics was growing to be a billion-dollar company

and you had the capacity to support from an engineering standpoint, two or three hundred million dollars of product design, how are you going to build 10 new products if that was the envelope or even three products, right? 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 and both have their challenges. But that's another function inside the company that usually comes about that point in time.

Like you acquired three small companies, you know, as we did that for different things. But sometimes it's like just accelerating the time to. Exactly. 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, like, you know, from zero lines of code, it would have taken us two to three years to get a reasonable product in the market. You know, 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 years, two or three years to half of it, right? So, or maybe, like, you know, maybe even 75%

in some cases. So that was the, that's always a factor. 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. pricing and packaging is a complex thing pricing is probably more complex in packaging in some ways I look at pricing is 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 what would how would people justify

so that's definitely one function second is like you know the rule that I've used for pricing is can your salespeople describe it simply like if customer is going going to ask a simple question And so how do you price your product? And if you can't describe it in half a sentence, you have two complex of a pricing. And yes, there could be nuances to it and there could be like details to it, but you have to be able to describe it.

Like in AbDynamics, we are monitoring all kind of different systems, right? 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 a rough unit of pricing. And we can measure production systems in different ways, but that's how we price it.

And it's at least simpler that 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 now the customer says,

okay, how many license 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 crack like, you know, how many they're using it.

That's a problem as well, right? So if we can describe our prices, 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, like the dollar price of it for that model, per license, how much you pay? That ideally, to me, comes on to business value. And enterprise software, especially are selling to large enterprise,

I argue to most founders is that you should price more than you think you should. Oh, we always say raise prices. Sorry, Montra around here. 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 the thing they should pay anyways. So you can always discount and then go there instead of pricing low. 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 customers 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 body, they're going to be like, well, we don't, you know, 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. Like, do what you need to do. That makes sense to the buyers. 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, right? Right. They're already pre-planned. That's one. And they want certainty in the sense that, oh, is it one alert or thousand alerts? And if it's two variable, then suddenly if it blows a budget, he cannot manage it.

So that's why they want that certainty and visibility into that pricing. So by certainty, you mean they don't want surprises? 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. Right. 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 going to get? If you put in like the 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 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, you know, how much money are you going to save and what's your ROI? And that's, you know, if we are charging more than what's going to save them, they're not going to pay for it anyways, right? Most companies I see the mistake of, like,

especially you're selling into large enterprise and you're asking for, you know, half a million dollars to someone, 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 would not leave money on the table. 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. 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 just has value and keep moving that forward. One question I have is the third element you mentioned, Joti, 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? You know, 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, you know, a lot of people say what the, what is product market fit? It's a very philosophical question.

What is product market fit? In such a vague question. My simple definition is if you can, if you understand the business value of your product, that's when 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, say, a director of DevOps. So I'll say, okay, well, how would you make the business case to your boss if you have to buy AppDynamics?

And he'll said, we had one outage a month. Every time we have an outage, you put six engineers there and this is how much it cost us. And because our users have bad experience, we lose this revenue, this is how much cost us. And once I start hearing it, I know, like, this is what I would, 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. You know, it's, because that's what you have to engineer your product around. 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. You know, 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, you know, how much do those costs? There's an overall stack of technology. And if you're providing a certain solution, what does 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. You know, 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, you know, 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 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.

I think that the fair part is important. Customer will feel is 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, right? But in Amdynamics, we had a bit of that challenge. One of our primary competitors was price much lower than us. And they were designed more for SMV.

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, 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're going to always charge higher than them. We actually said that we always...

So you resisted the downward pricing pressure? Yes, because we can't get, like, if our product is superior, we are, 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 then? And we always priced higher than our competitor because of that. And people are fine paying for it. 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 it. the value until an organization comes in to actually promote those pieces that may not be self-evident. At the end of the day, it's all about marketing, getting products to the market, right? And for that, you have a classical four-piece. 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 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. So those four pieces. 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. Is that an unusual model because you're an engineer who's doing product? Like, what is the idea?

way to essentially architect the product management or product org functions in this framework. Are product managers salespeople? Are they engineers? Depends on who your audiences are. To me, the product manager's first job is to understand the customer and, you know, the classic definition being the voice of the customer. So at Adaptomics, 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, you know, I'm building a fashion app. My product manager probably would be very good

in understanding my consumers as a, you know, as 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. So it kind of matches the profile of your target customer. Exactly. Did you guys have different product manager profiles, though,

then for the one third of the organization that was doing the more evangelical startup or than 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. 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, 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, you know, how is it working out in the market and, you know, what's the, you know, what's the adoption curve and what's the, you know, is the pricing working? So it's, you really, you know, the product management skill set also has different things to it, right?

What are the qualities to look for? We typically look for three aspects. During the initial phase, it's 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'll 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 defined it, product doesn't come out of thin air, right? You need to work with the engineers, literally track 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, that execution. So these are the three skill sets that I typically. look for in a very strong product manager. They're very creative parts of product management, then 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, some customers, some sales, figuring out the right pricing, packaging, all of that, right? So you want different skills. Seems like a bit of a unicorn, to be honest, to have all three. And many times it's not just one person, right? It's your product management then becomes a group as a time.

And you want different people with different, like, that balances out the, Right. It's like a good team. You complement each other's skills. And that's the composition of an ideal team while you have more than an individual contributor. Okay. So any parting takeaways given your, I'm sure you have a million takeaways, Joati, but any big message for our founders and other founders out there trying to do this, whether enterprise or not? it was a good discussion on the product market sales kind of fit but my primary advice I will give to founders listening this is don't overthink too far ahead in many cases as well like you know the skills you need to master zero to one million dollars of revenue find the product market fit one to ten million dollars find the product market sales fit

it freight on it let's a 10 to 75 million dollars 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 starts. So, you know, anyone listening to this, I don't want them to like, you know, when they are in the zero to one million stage, they're 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 in the, you know, 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. That's a great piece of partnering 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 A6NZ podcast, Jotty. Thank you all for this wonderful conversation. Thank you, Peter. Thanks, Jadhi.