a16z Podcast - a16z Podcast: Product-Market SALES Fit (What Comes First?)

Episode Date: February 3, 2019

with Jyoti Bansal (@jyotibansalsf), Peter Levine, Satish Talluri (@satishtalluri), and Sonal Chokshi (@smc90) 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.

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 Bunzel, 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 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 Satis, 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 double shooting solutions for complex software apps. So if you have 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. Yeah. 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 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 metrics without that good UI, UX and really be the open source strategy or the close source strategy doesn't matter, but user adoption is what should be driving the pre-product market fit. Now, the challenges completely change after you have your initial product market fit. They become all about sales and learning sales and scaling sales.

And, you know, it's almost like the companies go through that journey, right? You know, the pre-product market fit, the challenges are different. Then the 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, 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, you know, 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 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 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 these days it's all very tightly coupled together. You don't have like a sales is different and marketing is different than product is different And then all of 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, you know, is it SaaS, is it on-premise, is it hybrid of it? Is it going to be lend 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 Abidynamics, I used to say, like, it's a little bit misleading. leading 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 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, you know, we're going to build a premium strategy, you know. But the problem is if a product is too complex, freemium 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, the design may be completely. 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.

AR is the annual recurring revenue. The annual recurring revenue, which is like, you know, do you have a product? Someone will buy and it's solving some pain. Then you're like, you know, a million to the 10 million in revenue. That's where you're trading on the go-to-money. 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 it's a, 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. It has to be 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 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 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 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 what exactly, 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 with 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 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, you know, 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, you know, 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. So it's not a foregone conclusion 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, their 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? So ours was a combination of both. You know, in AppDynamics, you call it the sandwich strategy. The sandwich strategy.

You go from the bottom. You go from the top. We 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, you know, where we will create air cover and like, you know, 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 licenses, we call it land and expend. The land deals, which are like, you know, say a $20,000, $30,000, $50,000 deal on phone, we can.

can sell that, and then will expand into like half a million million dollar, two million dollar, you know, now these days, when $10 million deals. So that will, that you need traditional enterprise sales 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 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 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, it bottoms up developer adoption, 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, if 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 is not good for you because you're building a likely 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 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 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

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 if we were 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 if 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.

So 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 economic standpoint 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, $2 million license. It's just expected as part of that.

And the renewals. Like, you know, the year two, year three, year four renewal offer. 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 of financial aspects, even from a product aspect, it's good in the sense that we hate shelfware. 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 minds. 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 fit, pre-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 customer. 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 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're competitive pressures you have to catch up to competitors on some features sometimes and so you have to make sure you're winning enough in the market

you can get enough revenue and you prioritize that also. But then there's the 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 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 some 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 rule 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 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. Tell us why. That was a hard way. 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. And 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 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 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 it's 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. 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.

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 evangelicals, that you mentioned and the different sales learning curve for each. They're kind of all the same thing. That makes a lot of sense. 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 higher 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, that's like phase one, which is very, very almost the founders are selling. That's the initiation phase. Yes, there's the 25 to 100 customers. And then after 100 customers, a mature product. We can, our salesperson.

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 sales force. even not everyone. And once we hit that first 10 salespeople, they are cracking it, they are making more money with better incentives, then the rest of the sales force is like,

oh, there is something big there that I also need to sell. So we had to do it in stages, but we literally did a 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 salesman,

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 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, 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 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 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. Now, 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 a hundred-term, 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 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 we 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 never know that if we want to get to a billion dollars of revenue from 100 million in like seven years let's say or six years our plan was we need to have like at least 40% of our revenue coming from these new adjacent products otherwise we would our growth would not

get there and then we have to build this like that's 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 drop down to get to a billion dollar revenue right it's working backward to provide the focus and you need to do both you know 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? 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 like 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 you acquired something, we probably could cut it down from two year, 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? 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 a customer is going to ask a simple question, so how do you price your product?

And if you can't describe it in half a sentence, that 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 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. right so and that'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 track like you know how many they're using it that's a problem as well right so so if we can describe our pricing in half a sentence that's one Second is it's measurable that people can measure pre-sale and people can measure post-sale. We have a good pricing system. The question after that is, okay, what is the price, like the dollar price of it for that model per license, how much you pay?

That ideally, to me, it comes on to business value. And enterprise software, especially are selling to large enterprise, I argue to most founders is that they should price more than you think you should. Oh, we always say raise prices. That's our mantra 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 air vents your server has, right? Let's just say. You have to come up. 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 buyer, they're going to be like, well, we don't, you know, 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 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 1,000 alerts? And if it's two variable, then suddenly if it blows a budget, he cannot manage it. So that's why they've won 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, but they don't know how to budget for it. 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 auto I 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 AbDynamics 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. 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 pair, 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. So what I'm hearing you say is that sales enablement created, it smoothed the road, kind of grease the wheels for you, but then on top of it, you played back and made sure to

playback 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 in the, 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 it 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 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.

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 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 descry 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 where 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're going to always charge higher than them. We actually said the- 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 the value until an organization comes in to actually promote those pieces that may not be self-service.

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 were a piece. 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 ideal way to essentially architect the product management or product org functions in this framework? Are product manager 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 DevOps, 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 then 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.

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, if 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 adoption curve and what's the, you know, is the pricing working? So 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 phases, the empathy to understand that customer, to define your product. And the second aspect is the business aspects of, okay, how is it going to work with the sales? So literally, the product managers, they travel with the salespeople and understand how do you position that value. okay, now how do I price it and so on and so forth. And the third most important thing is execution. Once you defined it, product doesn't come out of thin air, 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. 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 variety of skills. 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 $1 million of revenue, find the product market fit, one to $10 million, find the product market sales fit, it rate on it, let's say $10 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 starts. So, you know, anyone listening 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.