Monetizing SaaS: Episode 46 with Mandy Sidana, Sr. Product Manager, Plotly

Mandy, thank you so much for being here. I've gotten to know you over the last year and I learned a lot from you. We've had a lot of great conversations. You are an experienced product leader. You're also an entrepreneur. You have a very diverse background spanning SaaS and AI-powered analytics, DevSecOps. You're currently a senior product manager at Plotly. You're working on platform services like their Dash Enterprise product. Previously, you led the launch of security tools at Sonatype. You've developed crypto trading solutions. You've built AI-powered business intelligence tools. You have this very fascinating career. So I'd love it if you could just tell us your own story in your own words. How did we get to now?

Yeah, thanks, Fynn Glover. That was a very generous introduction. No, I think it's, it's just all stems from the love of building stuff, of creating things that can change things. My journey into product management started with me developing my own software for doing social recruiting. The idea was in 2015, you know, Facebook would allow you a lot of data. And so would other social medias on like things that I would now be seen like too private, but back at that time it was just a vice, west, west wild. And so we had to, and so that's where I kind of started and using it for purposes that I thought were really useful for getting a psychometric profile on people and understanding that for like fitment in terms of jobs and companies. And so while that initial startup only raised a few rounds of investment, I realized that my forte is in building products and The work that you do as a founder is very close to that of a product manager. And that's— then I kind of wanted to build product for other people. And that took me to some public companies like EXL to work part of their innovation labs and some really small startups. I personally just enjoy working in a smaller team where you can get shit done and get things really moving and get the needle moving in a really small amount of time. So yeah, happy to deep dive into any specifics, but that's kind of That's kind of my journey. I really like to think of myself as I would say, like the user owner, as opposed to like the product manager, because that kind of comes with a lot of project management connotations and really what product management is like knowing your user in and out and being a champion for them in every decision that gets made at the organization.

That's terrific. I want to go deep into that idea and also what you're building at Plotly. But before we do that, Take us back to when you founded the company, and we've talked about this in the past, but I think you grew it to over 100,000 users. So you had, you had some real resonance in the market. When you think about building your first product from scratch, what's a lesson or a habit that you'd wish, kind of looking back on it, you wish you had developed earlier as a founder?

Yeah, I have a lot. Just as, as a first-time founder, you do make a lot of mistakes, but that's the, you know, that's the only way to learn. Just to capture a few, I think developing a sense of your industry, think of it from a macro level is very important that I don't see that I didn't do. And it really helps you understand like the dynamics between vendors and suppliers, especially if you're in a B2B space. So for example, we really struggled with the, you know, while the product was great, everyone kind of loved seeing the demos and they were like super excited about it. Once the push come to shovel, we were not able to like integrate with some of the players because they had like more bargaining power with those customers and they didn't want to integrate with us. And so kind of understanding that from the start to help define your strategy is kind of like really important. This was like a similar play when I was doing, let's say, DevOps at Sonatype, wherein some of our competitors kind of understood better at where developers are and meeting them there and strategizing all of their product features based on getting to that customer journey quicker. And so did we, but it was, it was something that I kind of thought was an afterthought as opposed to like starting your strategy from that macro understanding of your industry. Interesting. Yeah. And another thing which is quite common, I'm sure a lot of people say it is like, you know, not focusing on business model from like day one and not validating those assumptions. So one of the things I like that I've learned over the years is like, yes, product market fit and is this really important, but at the same time you really need to iron out what your monetization strategy is and then And then on that model, just like figure out which is the riskiest assumption here and how can we quickly learn and validate or invalidate that. And that's kind of like super important because personally I struggled with monetization from B2B companies, getting the revenue and proving it to a point that, you know, that they can come up for renewal.

One of the biggest mistakes that I felt that I made in my first company was I never went out and asked my customers prior to having them, you know, what their willingness to pay was. And so my understanding how to price and package over the course of a long iterative journey was always felt very unsophisticated. And looking back on it, I feel like that's one thing I wish I had done much earlier.

Yeah, 100%. Just talking to— because that's, that's part of product market fit, right? Like they might say like, we love the product, but then until you put a price tag on it and validate that they're willing, that they're willing to pay that price, you really don't have product market fit. And that's, that's kind of like a detail that you— that we need to understand.

Tell us what attracted you to Plotly and give us a little bit of a sense for what the, what the business does and the type of customers that it serves?

Yeah, for sure. So Plotly is in the space of business intelligence, data visualizations, but we have a different approach than most traditional vendors in the space like Power BI or Tableau, where they focus on like analysts and kind of have a drag and drop UI. So Plotly is like very code-based data visualization. So think of it as, you know, your popular Panda, like your popular Python libraries like Pandas, and it's Plotly is this one. We have like 20 million downloads per month for our open source libraries. And it's really this notion of developing BI as code. So you can, what you can do with that is you can make a fork of your code base. You can go back into your version history. You can collaborate better with other developers. You can annotate. Along all the different versions that you create versus, you know, those are problems that traditional BI products have. And, and that seems to be, you know, where, where our customers feel it too. Like they love the product for being able to, being able to scale in terms of, because it's just, it's just Python at the end of the day. Right. And Python can really give you the power, horsepower that you need to run like complex models. And, and also like the whole region of like connectors and databases and that, that's kind of goes away because there's like a Python connector for pretty much everything out there. And so it's, it's really kind of relying on that power to allow it to extend to data visualization and business intelligence in general.

Was the original insight that the existing BI tools were not serving developers that well, or was the insight slightly different than that?

Yeah, I mean, I came in quite late in Plotly once we had like a popular data, uh, you know, open source libraries. But I do believe like a lot of this, this came around the same time when let's say infrastructure as code was becoming the prime time and we saw a lot of movement in DevOps in the space of getting to this stage where, you know, developers kind of took over the operational roles of maintaining production code. And that kind of brought with it a lot of practices like GitOps, etc. And I think a very similar kind of thing was happening with BI in that time. And that got the founders to work on developing this approach.

Cool. You mentioned earlier one of the things that you've you've really tried to bring to product is a deep understanding of the customer. Can you walk us through, you know, you enter a company like Plotly, there's quite a bit of traction, there's quite a bit of potential. How do you literally get off the ground with learning who this customer is and really understanding that customer very deeply?

Yeah, so I mean, obviously, like, there is, you know, the first and the easy approach is just using data, right, to basically go into your Salesforce system and kind of like Creating a bunch of reports and starting from there to understand, you know, the size, the segments, and kind of understanding like how, what dollars are they paying for what features, the conversations kind of reading through that. But that's kind of like just by proxy and that can be done fairly quickly. I think the other one is that when you start going and talking to customers, you do want, you'll hear a lot of feature requests, right? And you'll hear a lot of like, we want this and we want that. And I think. Getting them to put money where their mouth is, is kind of like an important thing that I use, wherein I would say like, okay, we really want— you really want this feature. Would you like sign up for us as a reference customer and spend a bunch of time with us to figure out how you would want to work out this feature set? Sometimes I would find that that specific customer, especially in B2B space, because it's not super easy for a lot of customers to kind of voice their concerns in a single way. And you might have like 100 few hundred customers instead of like million customers. And so like data itself is not very large enough to just make data-backed decisions. So you really need to rely on these conversations and long-term engagements to A, feel the customer valued, make them feel valued, and B, really help them champion how the feature is going to come out, right? How was the positioning? What's the packaging? And sometimes the customer might not be a good fit for that specific feature set because most of your other customers' needs are not being— they don't need the same feature as a specific customer. Customer would need. And so I think a lot of product sense kind of comes there in terms of understanding whether this is a common, you know, if this need is actually going to be similar. So selecting that reference customer for a feature is, is really kind of, I think, where it can be done quickly, but that's where a lot of benefits are to be reaped at a later stage, if you have a good fit of finding that customer. So it's almost like a feature reference customer fit. Dictates your product market or feature market fit at a later point.

When you joined the business, was the primary sort of challenge slash opportunity, you know, the thing that, you know, kind of what I'm ultimately trying to understand is like when you joined the company, what was your charter? Was it to help the business evolve from this really successful open source project into a real business and really commercialize it for enterprise B2B use? Or was it, was there a different charter?

No, that sounds right. So this is more of like, you know, growing in terms of revenue. So we have some early market fit. We have some revenue. It was a profitable company when I joined, but the scale of, you know, the revenue and the growth is still something that we have higher ambitions about. And that was my charter to develop, to scale the processes, to really kind of get us into that growth phase in the product.

One thing I'm always interested in is like the first 90 days, like you enter a business, how do you, how do you kind of figure out this is where I need to spend my time. This is where the leverage is, right? Are the questions you ask? How do you go about that?

Yeah. So just, just in the first 90 days, I think like it's, it's very important to kind of spend that time to just learn and absorb for like at least the first maybe 30, 40 days and kind of like not just going in with like some ideas and being like, oh, this is what I want to do. Because strategy has to fit the context and, you know, it takes time to understand the context of business that the company is in and the type of customers. So specifically in case of Plotly, we have strong like developer advocacy. We had like great developer relations. We have a great community around developers. I think like, and a lot of like our sales is inbound where it's customers just calling us, hey, we love like open source. We want to like now, you know, host your apps and get into productionalization. You know, you have a product. How do we get started on that? And so really the challenge was for us to, to build out more, in my time, like it was a simple pricing structure when we had like one tier and it was like, we were kind of like scaling on that. And so the big focus for me was just getting into understanding how that can be tiered up into like different pricing tiers and driving customers through that journey because one size doesn't fit all customers. Right. So this pricing was like, it was too high for certain customers. It was too, and sometimes too small for larger customers. They're like, oh, we are, this is too cheap for us. And that's not something you want to hear as a business.

You know, one thing that I'm hearing you talk about is you spent time and you continue to spend time on pricing and monetization. And was that the charter has come in and serve in some ways as like a growth product leader? Or did you realize this business has an opportunity around pricing and packaging and monetization? And it's, it's lacking some ownership, there's an opportunity to establish ownership and direction around?

Yeah, interestingly, that was the charter that brought me in, wherein they realized that they don't have a really good understanding of their segmentation, positioning, and pricing. And it was just very general when I came in, it was like, okay, we want you to like look at, you know, the customer's case and trying to understand what those are. But then giving me or empowering me to actually go in and, you know, work with sales and customer success because yeah, those are kind of like the customer-facing functions that get really finicky about any change that you want to make to your pricing and packaging. And so just developing, I think like that's another thing that I wanted to speak about in the first 90 days is like developing that relation with like sales and CS. And it might be like showing your competence, it might be, you know, kind of figuring out the things that they care about and really kind of showing your passion for that helps in developing and building that relationship from an early on. So that kind of helps you get insights that otherwise would remain a lot more time to uncover.

Building the relationship with the market-facing side of the business is A, essential, B, hard to do. It's not easy to do. How did you do it actually? Can you tell us a story where, like a literal story where I felt like I won trust in this moment and we started to collaborate in a real way? Yeah.

Yeah. So I think like early on with the ideas of this notion, especially with like sales that, hey, this is like, we have a lot of features that are for free versus like for paid, right? And then a lot of, I think like sales organizations feels that and they don't Maybe sometimes they don't have complete visibility into like why product thinks that way. And that kind of is a point of friction. And in this specific scenario, like we were kind of like having those discussions wherein do we have too many features, too less features in our free offering? And sales was of the opinion that we have too much. And that's, and that's something that I kind of understood that they really cared about. And so I really kind of started from understanding, you know, just, it's just building out those reports from like Salesforce, which is a tool that they really use. I had a lot of interactions with like the analysts and people who were, you know, on the sales ops side, kind of like how our data was being collected and put into like Salesforce. And I personally kind of like championed putting in like more structured data and like the reasons and, you know, like why a certain deal got lost and why a certain deal got won was kind of like, you know, just championing that and like the sales leadership loved that. Like, this is kind of, you know, you're trying to understand what our pain points is and just like, and then developing that into like a, you know, like a bimonthly or a monthly meeting that goes around like just doing like win-loss analysis and trying to understand that. But I think more importantly, just going back to that discussion around like what's in the free product versus what is, what's, what is in the paid product. I think that development of, development of like proper reasoning, like at which stage the deal got lost and for what reason was super instrumental in like figuring out like, do we need, do we actually need more features for the open source and free Tiers versus for our paid products, because then that could qualitatively like demonstrate that, yeah, we are losing a bunch of deals because the customer is like losing value at this particular stage versus the opposite, which might be like, yeah, we have like, I mean, it's, it's usually never the case that you have like too much functionality in your paid product and also like highlighting the pipeline. I think the other concern, like, you know, sales has is, is usually like if customers kind of, if, if there's always this motion from like sales-led to product-led. And that's, that's never usually an easy transition and kind of demonstrating to sales that, hey, this is, this is going to increase our pipeline. Like this is not really, you know, like customers going in and signing up themselves, but, but this is going to like help you increase a sales channel and, you know, just getting some early validation of that, like wherein we have some free features and getting users to sign up and being able to demonstrate that to them, like this is contributing pipeline. And is this really kind of helpful in that sense?

I think it's a really good story. And what I take away from it is part of what you did to build trust is you provided a service to sales and the service was useful and the service built trust and then the service helped you begin to have more exploratory conversations again based on data. But that could be in some ways a bit open-ended. Like, is this the right way to maximize growth? Can be like a question once you've established that first bit of trust through the service.

100%. Yeah. And that service was just as data layer or that layer of knowledge that we needed to speak the same language.

Yeah. Yeah. When you look at Plotly today, what are the kind of the most important opportunities that you see for the company going forward? What do you, if you were to fast forward 2 or 3 years, what have you done for the business that you feel very proud of or excited about?

Yeah. So I think like as you kind of scale, you do tend to like accumulate some baggage and some, a lot of like tech debt. And that's kind of like this always ongoing notion between figuring out how do you step in between launching shiny new features versus like being able to like take tech debt. And one of the indicators for me always has been, you know, if it's taking too much time to ship new features, you probably have a lot of backlog and tech debt that you do need to clear up. So while it might seem like counterintuitive, I think some of the most important decisions that I've made at Plotly is to like, is to reduce feature set or to kind of act in a way where we were like, we're not going to offer this SKU anymore. We are not going to work on developing this feature set, specific feature set, because, you know, while some of our customers love it and they champion it, it's not going to contribute to our long-term strategy. And putting that out to the leadership and, you know, getting that buy-in is kind of always interesting, especially if you have like dollars attached to it, because you don't want to say goodbye to those customers and so on. And so. I think that's kind of one of the critical decisions that have helped Plotly like really streamline its portfolio and being able to like stay focused on the future of where, where that is. So the other thing is that I think that I've helped champion some way internally is kind of like the focus on personas and going back to my answer around, you know, being the user champion is this idea of like, who are we targeting? Right? So there's the, as, so we do sell an enterprise product, which does with the hosting, right? And then the user there is like essentially the DevOps manager who's trying to, you know, get the, get these apps productionalized. But at the same time, the, the early user of the product is the data analyst who's just kind of, you know, just building charts and they don't really care about the productionalization and they just want like one-click deploy and auto-scaling and things like that. And so having that Clarity and being able to like make products based for those specific personas, like different products, is kind of, is kind of really key. So, you know, just, just that focus on persona led us to start a new product line, which was, you know, Plotly App Studio. And that's something that I'm super excited about the future of, wherein we are like really simplifying the flow for like data analysts to being able to like come in with their their Jupyter Notebook and just, uh, with a few clicks create a production app that they can then deploy and use within the company.

I feel like one of the, one of the most common and difficult decisions companies have to make as they begin to scale is what revenue to let go of and what customers to let go of, what, to your point, what SKUs to let go of. And it's obviously a very emotional decision because it's real revenue and often you have to persuade board members and persuade different members of the executive team. And it's a tough argument, right? Because you're making a bet on the future. The bet is if we let go of this, we will have the resources to do this better. And this better is the future for the company. What have you learned about how to make a persuasive argument in that context? Has it been easy? Has it been hard? What have you learned about?

Yeah, no, I think that's definitely hard in terms of, especially, you know, because For the reasons that you just mentioned, you know, it makes it super difficult to get that buy-in across the organization, right? There will be some part of, yeah, try telling that to the AE who has that as its primary customer that, hey, we are not going to build out features for supporting your customer base. And I think so just kind of something that has been instrumental in getting that leadership buy-in is being able to understand the cost of supporting that business versus like the kind of really diving into the opportunity cost into like the things that we could be doing. So I had a lot of meetings where we were talking things about like we can developing this feature and this would like cost us maybe one team for the next 6 months to support that line of business. And this will bring in X dollars versus, you know, this one team could be working on this future strategy that will help us like drive, open up a new new growth channel for the company, but also like position us competitively from a strategic point of view, position us in a way that we are able to define a moat in the long term and not become like a commoditized business. I think that's kind of like really speaks to the board members and really speaks to the leadership in terms of understanding that, yes, you have to make difficult decisions. And I think it's easier if you do get that buy-in from the top and then kind of, you know, obviously you have inform it ground up, but then the rollout of the strategy has to happen from the top. It's also about how you're going to take care of those customers, right? So for those customers that you are saying, like, these features are not coming out, being sort of like transparent and honest about certain number of— in your communications and saying, you know, this is what we're doing instead, right? So that's kind of the key, what you're doing instead. If people see value in that, then they kind of see like, okay, we, you know, it's It's, we don't have infinite number of people and we can only focus on certain set of problems and this kind of seems really important. And then it really becomes about selling that this is the, why this is the problem that we want to solve.

Yeah. Yeah.

Having field enablement.

Sorry. Go ahead. Finish with that.

Yeah. Just, you know, on the tactical side, like having field enablement, like Q&A battle cards and collaterals and things like that, because a lot of it will be like, well, our competitors do it and why are we not doing it? So just kind of thinking that in while you're making the strategy sort of super helpful from like sales perspective, because if those feature set is not coming out, then what is it that also needs to be translated into those sales collaterals?

Yeah. One of the lessons that stands out to me about what you just described is like, first you have to really understand the resource trade-offs. And if you don't understand that, you can't present a very effective argument or a persuasive argument. If you do understand that, then, then you need executive top-down even board-level buy-in. If you don't have that, you might get stuck again. If you do have that, then you have a bunch of downstream sort of long-tail execution tasks. For example, battle cards. That's, that's the complex organizational process of actually letting go of a legacy customer or legacy revenue and like moving towards the future.

100%. And, um, just one thing I, I, I want to touch on again is like being super more mindful of those customers' needs and how CS kind of approaches communications with those customers with like regular check-ins and how, what's the plan for them is super important as well.

Yeah, the customer comms is a massive piece. You know, one thing I always love talking to people in your role because there's this relationship, right? Pricing and monetization, it touches literally the entire business. It touches product strategy, it touches the customer You are obviously playing like a very sort of connected role within the company. And I'm curious, kind of, how has that role evolved? You know, and how do you, how have you seen the role evolve in terms of the relationships that you're building with engineering, the relationships that you're building with ops and finance, the relationship that you're building with sales and success, the relationship that you're building with the, with the customer? How are you triangulating all of that on a daily level, on a weekly, on a quarterly level?

Yeah. That's a great question. I think like pricing is definitely one of the most underutilized lever in the company. And I think it was Warren Buffett who said like the, one of the key inputs for me to value a business is to understand its pricing power, like how much power they have to change the price and still have customers pay for it. And I think like I kind of lead from that within it's seen like this black magic, like box where like it gets made, the decision gets made in like at a board level., and then it's just rolled out and then nobody touches it because it's like too scary. And from, from there to like being able to like constantly communicate this value that pricing can have for like those different stakeholders. Like, for example, you mentioned like engineering. In my experience, oftentimes like engineering sees this as a non-functional requirement when like, they're like, oh, this is not a shiny new feature. Or, you know, this is not like the next big thing that we're doing. It's just like, we are reorganizing packaging. I literally had one of them. One of the GitHub tickets that one of my developers created. And in the section, like, why are we doing this? It was like, just make more money. And that was super interesting, but it was insightful for me to, you know, where we're kind of understand that this is really not about money. This is just making sure like our customers and we are aligned on what is the value that we're providing them. Right. And how much they value that value. I mean, price is kind of of what we measure with that. And so it's really more than, more than just making money. So, so you're absolutely right. Like this, this role in, in terms of like has changed a lot. And I think it touches all of those different corners. And I think like the key there is to, to have these opportunities for like packaging and pricing changes come in more often. So with every feature launch or with every feature planning, I would say like, you know, you should be thinking about how does Does it change my packaging? Is there opportunity for me to monetize this? Is there opportunity for me to create a new tier where I can charge higher? And that leads to conversations with these stakeholders like sales, CS, or engineering to say like, okay, yes, this can— if we were to bundle these few features, we can create a new tier and that'll bring in like maybe X more dollars, or this will like really open up this journey for the customer in terms of being able to like grow between different levels of size of the company, like different demographics, right? So, so I think it's, it's really having that conversation often, like maybe like 4 times in a year might sound, might sound a lot, but I really believe and stand by that, wherein, you know, you should be like really evaluating your packaging multiple times a year as opposed to just do it and forget it.

I really love that. And is it, is it a fair playback for what you just described? Part of the evolution of the role has been a really intentional focus on aligning the core product roadmap with a pricing and packaging roadmap. I mean, they're two distinct roadmaps, but it seems like you're intent on aligning the two.

100%. Yeah, I think like it's all about aligning why we are building to how it's going to impact the top line of the company. And that's super important. And it gives— and this is super helpful for product as well, because a lot of times you'll So they're like intuitive decisions being made, but once you do the numbers and you kind of understand the modeling, you might realize like this is probably not as great as I thought it is. So it's also super informative for product leaders and for managers.

As it relates to sort of useful guides for product, I mean, I'm curious to kind of talk through what you've learned about like a framework for thinking about different product investments. Like, is it we're going to have some number of our sort of focus, some percentage of our focus will be on kind of table stake's functionality, some percentage will be on, let's say, sort of new value that we can sort of add to a top tier as sort of a little bit of a heuristic, and then some will be sort of innovation that could be new product, or would you approach that differently? Is there a different mental model that you use?

No, I mean, yeah, just thinking in cost, it literally boils down to, let's say, developer costs, right? So if you think of it, we have X number of developers, we have X number of weeks in a year, and that's a finite resource. And we could be like spending them on all the things that you mentioned, like building out the shiny new feature that sales wants or reducing our tech debt and so on and so on. And I think the model that I have in my mind is sort of like a layer cake. And, you know, you can, you can decide how much do you want the cream layer to be thick, or you can decide, you know, you can play with those things when you, you set out with some intentionality saying like, okay, I want to spend, you know, 20% of my budget on reducing tech debt. I want to spend 20% on customer commits and it And that, those, the decision around those numbers is, is in fact being, is coming from your basic product metrics, like your renewal rate, your churn rate, your growth rates. And all of those will inform like, yeah, if I'm trying to, as a company, I'm trying to improve my retention, I probably want a thicker layer in my cake for customer commits, right? So I'm going to spend like 20% of my engineering this year, just making sure like whatever commitments we make to customer to sell them are being delivered. We can improve their retention and, and go about that. Does that answer your question?

I think it makes complete sense. And it's, I think it's a great reminder for people that maybe the starting question is, what is the constraint on the business? Is it churn? Is it new logo? Is it something else? If we can isolate the variable, that'll inform sort of the percentage allocation towards new innovation, new features, burning down tech debt, base functionality.

100%. Like I think most companies have like an annual operating plan, right? And, and you have a pretty good an understanding of what your resources are going to look like in the next year and kind of starting from there because bringing in like new people is always hard and you know, you don't want to make your plan based on that. That should be like maybe Plan B or if you really identify an opportunity that's like a 10xer, then sure, go in and like hire a bunch of people and expand. But for the most part, it's like within— if I have 20 weeks to develop the innovative new feature this year, then really kind of thinking through what are the 5 features that are the best utilization of those 20 weeks that I'm getting this year.

I wanted to touch on sort of what you mentioned about engineering. Engineering often, in my experience, doesn't want to work on the latest pricing initiative or the latest billing initiative. It's not viewed as core. It's not viewed as revenue generating in some ways. It's not a new— it's a new revenue generating feature, for example. And yet engineering is like largely critical path. Code changes are almost always required to evolve pricing and packaging. What have you learned about that reality?

Yeah, it's funny you mentioned that because I've had experiences with like engineering leaders who feel that at that point, like, you know, when you're trying to like roll out these changes, I heard one of the leaders kind of come out very strongly around like, hey, what really matters is like product market fit, right? And we are still like evolving on that. And they're absolutely right. Like it does, right? It supersedes your pricing and other packaging decisions because is, you know, that's, that's the first thing you want to establish. But I think like companies typically have an inertia around like being able to move from finding that product market fit into like being able to then cater their packaging according to the different segments of customers that they have. And that's kind of— and they stay longer in that mindset of achieving product market fit than they need to. Yeah. So your question around like, you know, kind of really is important to address in terms of how do How do you communicate that value to engineering and how do you make the changes? I think it's also like understanding that yes, this is like, you can't have a lot of, a lot of asks from engineering, right? So you gotta like pick your, pick your moves and pick your battles, so to speak. So within like packaging, try to think of like packaging and pricing backlog as its own bucket of things. And you would want to, I try to intuitively in my mind, I try to understand like, what is the little change that we can make that help us really get pricing and packaging along as opposed to like we need a lot of effort and engineering behind. So for example, like if you want to differentiate between like different, let's say production servers, right? So we want to like do like that micro entitlement management at different like server levels. That might be a lot of work, but if you do want to simply like simply have some entitlements at the start where in like features are mapped to certain tiers and based on license, you just check that, and, you know, certain features can be put behind a feature flag. If those features are not locked down, then that's kind of like something simpler. And so just understanding the ROI on those pricing initiatives within engineering is super helpful and taking a long-term approach. So you don't have to like change things every quarter. So that's where I believe like most companies would value from bringing in like an entitlement product that they can rely upon. I mean, I know we do at Plotly rely on external products where we don't want to spend a lot of time figuring out, because this is not core of the business, right? Like this is another thing, which is, I think, super important to understand that even though pricing is like super close to the business, your capability to do entitlements management and to do metering and things like that is not a core competency for your business. And so just, just use the product to do that and be empathetic with your engineering. And they really have a lot of stuff to do and try to do as little of their time as you need.

Manny, this has been so much fun. I have two more questions I want to ask you, and the first is about the future and the second is about the past. I'm curious, as you kind of think about the next 5 years in B2B software, what trends or what changes or what inflections attract a lot of your personal curiosity and energy?

Yeah, yeah, that's a great question.

Okay, we're recording again. Sorry about that.

No worries. Yeah, no, that's a great question. And I think in my experience, some things that have come up is just looking at the future of pricing is going more towards like outcome rather than consumption. And so just at my time with Sonatype selling security products, you know, it was known across the board that, hey, customers care about being secure. They don't care about like how many open source components they ingest. And, you know, how can we have a pricing model that, that solves for that? Like your outcome is to not have security breaches and to prevent that. And I think like that will continue to shape the world of pricing and packaging because one of the key things in pricing Pricing is also like reducing friction of your pricing model. Right. And we've seen this a lot where, especially in B2B companies where you have like these 4 tiers and they have like this abstract value metric that nobody understands, like X units and how many units do I need and when will I need them? And, you know, all of that you really have to think through. And then, you know, just reducing that friction is kind of like super important for, I feel like for actually for a company to be able to monetize the way to scale. So I think outcomes kind of like playing to that where you're like promising for each tier, like this is an outcome that we can get you, right? That might be like, we can secure your development pipelines with this. You can like assure that, you know, you're also securing your build systems and things like that. So you can really prioritize the outcomes. The other thing I want to briefly touch base on is I'm super curious on how AI will change a lot of the software SaaS consumption model. And I think there might be an opportunity there to move to more flatter pricing. Like this kind of seems counterintuitive because, but if you really think about like outcome-based pricing and how, you know, AI is able to really help and help. So for example, like any product, any tool that you use, I'm sure like the audience for this podcast, like product managers and, and they use a lot of product tools and imagine like if, you know, Aha or Productboard had a lot of like AI features that that kind of became like the core value driver, then you would want to price more or less like flat based on the outcome. Like, can we help your product managers? Achieve a certain level of competence and then kind of supporting in that way. So I think that's, that's going to be super interesting. One fringe thought that I'm having is like also, you know, this movement around right to own and, you know, the right to repair. And I think like that's kind of more B2C play wherein, you know, for companies in that space, I think it's going to be, there's, there's going to be some challengers who are going to come in with that pricing model where they allow owners ownership of the software product in some way, and they're able to then displace the incumbents because of the superior pricing model. So that's, I think, another B2C opportunity that's waiting to happen.

Those are amazing. And I've noticed a couple of things that you've said today around pricing. One is the Warren Buffett reference and pricing power, and the other is competing, you know, with sort of counter-positioning on price. And I think that they're both really cool that you've mentioned them because they speak to just how strategically influential pricing can be as the lever when it's well understood, when it is a practice within the business. So thank you for that. The past question I want to ask you, and this is the closing question I always like to ask, is, is there a specific moment that has been most formative for you in your career?

Yeah, um, just reflecting on that for a minute, I would say like I do feel like coming from like the startup world where I was like then kind of working with large enterprises and then going back to, you know, startups is, is like just seeing the level of approach wherein a lot of startups kind of start from a low point. They base their pricing based on completion and are really not thinking about like, what is the high bar that we can start from versus really being focused on like, this is a value driver for our customers and putting in a high bar to start with, to allow for like discounting to happen over time and to allow for you to have With that wiggle room for you to over time to being able to like come down on your prices, but still maintain a good amount of profit is something that took me a lot of time to learn. One example that comes to mind, or if you're looking for like a specific moment was aha moment was again, going back to my time at Sonatype, wherein we took this capability, this AI capability to like to detect malware that, you know, we were just developing and rolling out to our existing customers, packaging and packaging it and reselling it at like a 40% premium to, to, um, to what it was being shared with the customers at was kind of like monumental in terms of like how much, how much value that that suddenly brought in for the business. And we were able to like spin up whole teams that were dedicated to this product now because it was like generating specific revenue. And so I think it's very easy to when you roll out new features and capabilities to say like, oh, this is going to help reduce return and this is going to like help us, you know, stronghold our existing base. But like I said, to evaluate those in terms of not looking at your competitors, not looking at the industry, but just in your own understanding of your customers, being able to do price and packaging changes. Price changes are not always possible, but packaging changes are. And so showing that value to the business so that then those, those resources can be directed towards completing, like laying this out into a stronger team that can fully focus on this and growing and expanding that team is super, um, was, was like a learning moment for me that has been kind of defining in my career.

That's really, really cool. You know what, I've now done 50 of these conversations and the more people I talk to, the more that question is answered with some version of the first time I got to really work on pricing and really see the impact. Impact. And same for me. I mean, like, the first time I really started to like work on pricing, it was just eye-opening in so many ways around just like business, right? Because pricing is this— it is this sort of like crucial kind of communication between a product's value and a market. It's—

yeah, this is like just bringing up a short, uh, thing I wanted to share, which was, um, when, when we were like going through that 40% price increase, we, we didn't have a pricing committee, and they were like stakeholders all across the business who had very strong opinions on like, you know, what this— like, this this is too high or this is too low. And in the end, what I ended up doing, and this was something new and I was super nervous about it, was getting the most important people who were like to that decision in a room and assigning them votes. So they can like basically say like, this is where I vote. And then kind of like picking two. So almost feels like a decision by committee, but I think like it was, but it wasn't that we were trying to get to that decision by saying you know, this is what the maximum number of people agree on. It was more around like trying to understand like, why would they vote that way? And then seeing like how if certain people were on, you know, certain side, then it really kind of changes the buy-in. So I think we, I wouldn't call it democratic, but it kind of like starting from that place of like, okay, all of you get votes. Even if you're like a board member or a CEO, you just get one vote and you have to like decide. What do you want to do with that? And using that to enable decision-making between these very impactful charismatic leaders was super fun and challenging at the same time.

I love the idea of, you know, tell me a story where you had to overcome nerves. And that's a great one. Mandy, thank you so much for this conversation. It's been so much fun. I'm grateful to you for doing it. And where can people reach out or learn more about Plotly?

Yeah, that's plotly.com. And you can always just reach us there if anyone wants to reach me specifically, I'll, you know, I'll drop my email in the comments, but I'm available on X or LinkedIn or Medium. I have a blog on Medium. If you search in for Mandy Sidharna, you should be able to find that. And yeah, I'll probably send you some email addresses at the bottom.

Excellent. Thank you so much again.

Thanks, Fynn. Always a pleasure talking to you. Have a great day.