In this interview, Scott Mitchell discusses Salesloft's evolution from a prospecting tool to a full‑platform enterprise solution and how that strategic shift required a new approach to pricing and packaging. The company introduced a provisioning system that treats pricing changes as metadata—using SKUs that map to platform capabilities—so that pricing updates no longer require lengthy engineering projects. Mitchell emphasizes the need for rapid, A/B‑style experimentation in pricing, the importance of decoupling pricing and packaging logic from application code, and designing pricing as its own bounded microservice context. He critiques the broader software industry for often neglecting systematic pricing optimization, arguing that flexible, data‑driven pricing mechanisms are essential for capturing the value of continuously shipped product features.
Chapters
make sure I understand. So effectively, the business— I mean, at this point it's surpassed $100 million in ARR. It's looking to really reconsider next-generation pricing and packaging. It brings in a consultant, and the reality is that whatever the consultant comes back with from a recommendation perspective, the business may not be able to operationalize it.
Yeah, at least not efficiently, right?
And is it fair to say that the answer is this provisioning system because now the business can sell different bundles with different add-ons with different configurations to support a bunch of enterprise customers, or is that sort of a bad, a bad way to frame it?
So, so yes, that was absolutely the reason to do it and the goal to do it. In turn, the goal was to turn pricing changes into a metadata exercise, right? You shouldn't be running an engineering project for 6 months to do pricing changes. You want to be able to say, these are SKUs, these are how they map into the capabilities of the platform, and be done. And so the why behind the pricing changes, you mentioned enterprise and yes, we were moving into enterprise. We don't really feel like that was the change. It was really the strategy change and a positioning change of the product, right? We started off as Prospecting tool, we started off as building the category of sales engagement, right? That had not been a branded thing. And we spent months of evangelism making that true.
We're no longer a prospecting tool. We're now a full platform. And yeah.
But it was really driven by that product strategy change.
Software companies are always shipping new value. There's always more and more value coming out. But given pricing and packaging often changes at a slower rate, companies are often not capturing that value in a really consistent way. So I'm curious what you've learned about the extent to which companies do a good or bad or neutral job of aligning those roadmaps.
In my experience, companies don't invest enough time finding the right levers for pricing. Right? And I think some of that is because it's hard, systems-wise, not just business-wise. It is so challenging to— I think about this. In the software industry, we've gotten really good at A/B testing software, right? We can deploy the software with flags. We can choose for 10% of the customers to see it this way, and then 90% haven't seen a change. And we can learn from the feedback and very quickly pivot. Right? That type of flexibility really needs to exist in the pricing world. Right? You need to be able to experiment. You need to be able to put different offerings out there. You need to be able to get feedback about what's working and not working and make changes quickly. And so, yeah, pricing is super complicated and you need to do it in a way that you're allowing for a ton of flexibility. So, but I do think just generally speaking, companies don't. Don't spend enough time to get enough value of finding the optimal.
In pursuit of that flexibility, is, is one of the actual bodies of work decoupling pricing and packaging and from application code?
Absolutely. Exactly. What should the, what should your application worry about? Your application should worry about delivering the right, a ton of high quality features, delivering the right ones. To the right users based on what they've purchased.
I see.
And then, and then probably some sort of opportunity for the platform to, to engage in cross-sell, upsell, right? Some teasers. Oh, hey, you don't have this. So, you know, click here for a free demo or something. Yeah. It does not have it, generally speaking, in its domain, at least in my experience, what should the user pay for that feature. And so decoupling those, it's it's just good application design, right? If you go think about, we were very microservices-based, right? You want a well-bounded context for each thing you're building. And pricing and packaging is a domain that should be in its own, its own context, well integrated. Yeah. That makes sense.
Yeah, totally. So the application should care to provide great functionality and correct access. It shouldn't care about the price.