Monetizing SaaS: Episode 29 with Harker Roslin, Product at Hubspot

Harker, thank you so much for being on our podcast. You have had one of the coolest careers of anybody that I've talked to so far. I think you got your start in tech implementing an online preorder system for a bookstore and then 4 years as a paralegal. And then I think that kind of launched you into a big project around global cannabis law. And then you moved into software with systems work, with implementation work, and you did some really interesting stuff for Magento, Adobe. Eventually you moved into product leadership roles at some very interesting software companies like Simpleforce and Crossbeam, and now you're at one of the greatest software companies of all time in HubSpot. Tell us about the journey. How'd we get to now?

So the way we got to now is that I actually used to teach philosophy. So at West Chester University, I was a philosophy graduate student. I ended up with my terminal master's from West Chester, emphasis on terminal at times. And so when I graduated in 2009, 2009. Um, we all know what everything looked like in 2009. Academia was collapsing. Um, I went for my paralegal cert thinking that I would be a lawyer, which is like not an uncommon move for people coming from philosophy, economics, history, kinds of backgrounds in the humanities. I was a workers' compensation and medical malpractice defense side paralegal for 4 years at a firm in Wilmington, Delaware, and I decided I definitely didn't want to be a lawyer. And so I began my transition into ology. So I began the project with Leafly doing proposal and price negotiation on— it was global cannabis research. So it was actually doing legal research into what the situation was with cannabis worldwide. That was my side hustle while I got Salesforce certified and eventually started picking up freelance gigs doing things like data cleansing for theaters and things like that in the Salesforce ecosystem. And from there I became a systems administrator a Salesforce admin, and that was my real entry into what I would call proper tech. Um, and from systems administration work, I did move pretty quickly into implementation in the edtech space, and then eventually into legal tech, which made a lot of sense with my background as a paralegal. Once I was in implementation, I knew I wanted to be in product, and I think that implementation is a great path into product because if you're implementing systems, you know where all the gaps somewhere, right? Like anything that's manual, hard, the migrations are wicked bad, you're going to see them on the ground. And I think, you know, there's lots of paths into product work, but mine for sure was yelling at product managers. Um, and so one of the things that's wonderful about that, to bring it into my current role, is that now my end user for the group that I'm in at HubSpot is in fact CRM super admins and the people that they support. So, it allows me to end people who are doing implementation work and how can I make their lives easier. So, I feel like I've had this wonderful opportunity to take different threads of my story and sort of pull them forward into the work that I've done after that in a way that's worked out really beautifully.

But so, most recently you were at Crossbeam, which is a really interesting company focused on how companies can effectively build partnerships together and market together. And then, and now you've come to HubSpot, and they're just such different companies from a scale perspective. So maybe tell us a little bit about the opportunity that you saw at HubSpot. I mean, besides the fact that it's just a globally renowned, well-run— what, what the opportunity?

A lot of what it— I will say that HubSpot's culture attracted me from the jump. Their culture is amazing. They consider it one of their products. They consider applicant experienced one of their products, and it really shows in the, um, like the vetting and interview process in a way that was— I was just so touched and felt so human the entire time. And like that carries forward into onboarding, it carries forward into how the individual teams do their work. So right now at HubSpot, there's a really big focus on ease of use and time to value. And I think that's really interesting coming from a place where I was doing a lot of pricing and packaging work. Because the early journey in your product, especially in B2B SaaS, is this invisible fulcrum for monetization. The faster people get to, the more in love with your products they're going to be. And if you can make those really early experiences, which tend to be arduous and hard— people who are setting up a CRM or setting up data connections for the first time, it's not fun or pleasant or delightful work. And the ways that you can make that easier for them, a little bit less of a mental load, explain what they're doing really well and educate, makes them advocates for your product, which I think has a huge part to play in the overall culture of monetization in the B2B space. Ultimately, if you make your customers successful, they will love you for it and they will eventually make their success your success. So I think that's sort of a very similar line. You'll see that same, you'll see that same trend, across Market, across Beam, HubSpot, most companies are really revisiting sort of like how customer obsessed are we and how does that play out in the way that our application functions, especially early journey.

So tell us what you're working on now.

Right now I'm part of the data model management group, which sounds so deeply boring, and I'm here to tell you that it is not. And what the data model management group does primarily is focus really deeply on delivering solutions for for HubSpot super admins who are just getting their data model spun up to make sure that it meets their needs both right this second and for their industry as they grow into the future. As I said before, I have such a, a soft spot and so much empathy for people sitting in that seat, especially since people don't always come from a technical background, right? Not everyone who's in the first seat available in HubSpot has a background in database administration. So there's a big focus in the data model management group to to not only educate those folks so that they can make good solid decisions about how they choose to develop their business out, but also to do so in a way that's flexible enough that it accommodates and facilitates their growth over time.

What, what are the biggest categories of friction that they're running into that have kind of come across your desk already and that you're thinking about?

Data literacy is so important and is so difficult to communicate in ways that are visual and fast. And so there's a lot of, um, there's a lot of movement towards like, how can we make this be an easy button for you? Is there a set of questions that we can ask or things that we can learn about your business that we can get the framework set up for you, for you to develop on top of and sort of learn as you go and to treat the application as a teacher for people sitting in those seats so that as they begin to make decisions, they can test them out see if that's what's really going to work for them, see if there are ways for them to walk it back if it's not working for them, and then allow them to become more confident as they make more of those decisions.

Yeah. When you, when you zoom out and you think about the next 10 years at HubSpot or in B2B SaaS broadly, where does your energy go?

Absolutely. It's connected to what I was actually just saying about like trying to anticipate what a user's— what we know about and make more proactive suggestions for what you could or should be doing next based on what we know. So that idea of the application creating more autonomous and educated users and to take that opportunity to, instead of plastering your application with calls to action and third-party tours and knowledge-based articles, it's like, how can we bake this experience into the app so that you're naturally learning as you go? And you're building confidence based on those decisions. I don't know that I would call myself an LLM skeptic, but I am an LLM, like, questioner. And I do get excited about some applications of that technology. And one of them in my mind very easily could be like, what industry are you in? Okay, here's what we know about the object model that a lot of people in that industry need. Let's ask a few more questions, make sure that this fits your needs. And then like boom, set it up for you. You can test it out and if you don't like it, maybe roll it back and we'll start over again to allow people to experiment with a little bit lower stakes while also really focusing on if you are on a deadline because the software that you're leaving is going to be sunset, right? That's hugely stressful. Let's get you set up as fast as you can so that you can start educating your user base and they can be using the tool.

What do you think HubSpot is thinking about and most interested in over the next 10 years as a business?

The growth of our customers, for sure. How can we get them there faster? How can we be their biggest ally? How can the application take the things that they're trying to do and make them faster, more seamless, more well-lubricated? How can we hand off between one, one team and another and in a seamless way that's easily captured and trackable? So really, it's about the acceleration of our customer base.

Where my mind's going when I'm listening to, to both of those answers is towards this idea that B2B software, like there's this movement towards it is, it is more consumerized. It feels more like consumer experiences that we may have become more accustomed to with the iPhone and with digital media and things like that. Is that, is that a, is that a relevant conversation? And when you kind of think about those two answers, I do.

There are some really delightful products out there that are B2C focused that I think really nail this and that B2B SaaS has lagged behind on, right? Which is like you open up an application or a tool for the first time. And you're automatically being taught how to use it in an often really delightful way because you don't have an implementation consultant. You're just some guy who bought this thing, right? And so we want you to use it. We want that stickiness. We want the weekly—

I think something just happened. Okay, we're good. Can you still hear me, Fynn Glover? Okay, we are off my headset for some reason, and that's fine. So taking those lessons learned from B2C SaaS, which is like you're sitting in this chair You don't have anyone to help you. It's our job to teach you how to use this tool. B2B SaaS picking up that lesson and thinking, okay, well, how could we do that? And often those systems are much bigger and complex because they are serving a much larger market or a much larger user base. And I think that that lesson being learned is focused on user autonomy. If you want the white glove experience, you can have it, but you shouldn't have to need that, especially in the small to medium business market.

It is a good segue into monetization, which gets at the heart of the user experience, but you're someone who's lived and breathed pricing and packaging and B2B SaaS, I think with a level of depth that is more than most people, like you've certainly had your MBA in it. And so talk a little bit about the state of pricing and packaging in B2B SaaS. Many companies, many companies appreciate at a theoretical or conceptual level that pricing and packaging is this really important lever. But building a practice around that lever feels like it's something that lags behind and it's not, it's often not until the company has become quite big that you see real maturity around price and patching as a practice. So I wonder if you think that's true based on what you've seen as maybe a starting point.

I do. And I've seen this not only in my work life, but also vetting other people, like looking at vendors and things like that, where it's like lots of people don't quite have this figured out. And that's often like the earliest move tends to look a little hasty. They're not thinking about this as a discipline. Maybe some people are, but they're thinking about what they need, which is ultimately money for the business. And so, there's an urge, I think, to stand up something very quickly in ways that don't necess— that create a culture without intending to, which is one of the more risky things that we can do as a business is every time you make a large business decision and figure out how you're going to deliver that thing, you've already kind of created the culture and the discipline, whether you intended to or not. And so, if you're not being intentional about that, it tends to put these invisible bars and barriers around future development efforts, which are going to need to be happening. And so, I feel like there is a tendency, once you've stood up whatever your initial solution is, there's either an overreactivity to it not being successful enough, and to be like, "Well, now we gotta change it," or there's this, like, we need to wait longer and see. And a thing that I wish happened at that first moment when a company says, we need to stand something up in the pricing and packaging space for the first time, to sit down and really have a talk about risk tolerance and what those windows of risk tolerance look like. And if there are any contingency plans, if this doesn't go well, what would our next move look like? If this lever that we've chosen isn't the one, What would our other options be? And what that does is give product design and engineering some idea of what the future could look like and to build with that in mind. And I'm not sure that that happens as frequently as it should.

Is there an example you might be able to share around when a company did do that, they kind of spoke to the risks?

I think it has happened for me later in the journey. So, there was already sort of some friction and fighting with the initial unintentional culture that was sort of stood up at the beginning. But there was definitely, there were definitely times, I know when I was at Crossbeam, where we did do a full pivot from one model to another. And there was much more power placed in the hands of product design and engineering ICs specifically to say, well, here's our wishlist, given the constraints of the system that we've developed, can we have these things? What would it cost? And if the answer is the cost is too high, or the answer is no, What are our alternatives? Which I think was a really healthy move.

So I spoke to a former VP of product the other day who said, in my experience, pricing and packaging is owned by the founders until like Series B or C. And that after that, there's like an ownership hot potato game, like who's going to own pricing and packaging. And he described how at a couple of his prior companies, he ended up raising his hand and taking pricing and packaging, which in some ways is what I— sounds like you did at Crossbeam. And it's made me think ever since I heard that story, as well as your story, that there is some like very interesting opportunity for product leaders to take pricing and packaging and really grab it and lead it. And I wonder how you'd reflect on that.

So I feel like from an IC perspective, I was considered the product owner for pricing and packaging, but ultimately most of the decisions that were being made were at least one level above me in the org chart, and primarily, the executive sponsor was in marketing. And so, from a product perspective, the ownership was about accountability and not always about the decision-making itself. A lot of my role was to interface with our executive sponsor, who was bringing the information from the other executive stakeholders, from the board, from customer, you know, interviews that were being done and take that information to me and say, "This is what we believe that we need." And for me to say, "If that is what you want, here are the things that we need in order to deliver in the timeframe that we've been afforded." So, there was a lot of collaboration in that space. And it absolutely does become a hot potato because it's high risk, it's high stakes, it's high stress, and it can be a real grind. Ultimately, at the end of the day, bringing money into an organization, especially particularly in the socioeconomic climate that we're in right now, is one of the most important things that everyone in the company needs to be focused on. And if you're the face of that effort, whether it's from an IC perspective, where I was seated, or an executive sponsor, or a set of executive leadership making those decisions, it can get uncomfortable. And I think that there's a real push to create change and get the engine moving. And if it's not moving fast enough, there can be ego involved, there can be embarrassment involved. There can be feelings of failure. Like, these are big human emotions that are very difficult to tackle. And so, I think that you see a high level of burnout, you see a high level of hot potato, you see people wanting to step back and take a break. And so, but also, everyone has such a stake in how successful the project is that it can be a lot of push-pull in that way.

Can you paint a picture? How does it happen? Go-to-market comes and they say, we want this.

Absolutely. So I can speak to my own experience, which for background is I was the product manager who brought pricing and packaging at Crossbeam from 0 to 4. And that effort happened over January of 2022 to just a month before my exit. So I want to say like March, April of 2024. 0 to 4 is a big effort and it was basically quarter over quarter iterations that were substantial. So, moving from a really common move that you'll see is, hey, you get 5 seats for free and you can buy for free for the, you know, plan price, a couple thousand dollars, and then you can get add-on seats after that if you need them. And, you know, you get a couple of integrations and it's fine. These things are all packaged up really nicely. There's not a sense of à la carte. That early in the journey. And that motion tends to come from people like the board and executive leadership. You monitor. As soon as it's out, you start monitoring. How are we performing? Who's converting? Are they doing it in the product? Is it competing with our enterprise? Like, for self-service, you don't want to cannibalize your enterprise business. That's a really big lever that you need to be able to fine-tune. Once that initial push got stood up, it became very clear, very quickly, that we needed to pivot to a truly seat-based model. Not every team has 5 people that they need to be logged into your tool. So, we start talking about what I've called the fundamental unit of value in your application. The fundamental unit of value in your application is the thing that people pay for that puts money back in their pocket. Because if it's not doing that, they are not going to pay you. And so, for a lot of organizations, that's seats. And you can see this across B2B sales. Salesforce sells seats, HubSpot sells seats. Seats are ultimately people in the application doing their jobs and making money for the customer. That tends to widen the room of stakeholders. Enterprise sales executive leadership is going to have a stake in this because they want to protect their team while also making self-service successful. That means we need better differentiators between enterprise and self-service. Great. Marketing is going to become more heavily involved because now it becomes about messaging. We have to communicate about the fundamental unit of value in application in a way that is going to make sense to our users. We're also making a fundamental change to our existing pricing model, which involves a lot of preemptive and proactive communication, both with the folks who are already paying and maybe overpaying, and the folks who are thinking about converting between now and when you release the new package. So, that widens the number of deciders in the room. It widens the number of voices who have a stake in the success of the product. By the time I left Crossbeam, we had not yet gotten to the place where it was like the fun part, where it's like, okay, let's, let's experiment with this. If we present this in this way versus this way, is that more compelling to our users? Are they able to appreciate the value of the thing that they would be paying for? What about a trial of this specific feature as opposed to a plan-based trial? Which one of these is a conversion lever and which one is an expansion lever? Are trials leveraged for conversion or expansion at all, or are they actually about churn reduction? So like, those questions tend to come much later in the process, and there's very rarely time earlier for us to be having those discussions. And it's such a shame, because if those discussions were happening— how do we think about trials as an organization? Let's all just sit around and talk about it. Why would you trial a— those kinds of conversations can help shape the delivery effort and the implementation decisions that get made in a way that can save so much time and so much heartache later on down the road. But often the wheel is moving so fast that those sort of fundamental conversations at least aren't happening in rooms where someone like me, a senior product manager, is going to be seated.

If we, I wanna see if I can play it back a little bit because I think, sure. I think this is, this gets to kind of, I think the meat of what a lot of operators struggle with on a daily basis when they have to operate in and around pricing and packaging. So marketing leader comes and says, you know, we've got a lot of pressure from the board or from sales or whatever to introduce a free trial. We need you to help us implement that. You start to say, okay, we have a lot of people to think about here because we've got existing customers who will be affected by this. We've got our sales reps who may be affected by this. We've got, I would imagine, engineering who's going to be affected by this. And so maybe paint a little bit, go a little bit deeper, double-click into like, what are the requirements that you come back to that marketing leader with? And you say, this is what I need you to kind of understand because it's going to inform the timeline that you're looking for.

Absolutely. Often that conversation comes down to trade-offs. So typically when I'm speaking to executive leadership about a pricing decision, what I'll present them is 2 to 3 scenarios of like, okay, you've said you want trials. Do we know the, like, Fundamental questions: do we know the length of the trial? Are we basing the length of that trial on data that is known and visible to us? Is 30 days appropriate, or can people not make that decision in 30 days? The next follow-up question is, will we need a way to manually extend trials when people ask for it? How often? Who's going to do that work? And where does it need to happen? Okay, we figured that out. How do trials end? Do they auto-convert? Do they not auto-convert and just simply end? Do we want to have a seamless, beautiful process that allows them to downgrade out of the trial and remove the things that they would have if they were paying us, but will no longer have access to? Or do we want to have a customer success person logging into our backend to turn off those features? What do you want and when do you want it? And so people think of trials, you and I experience them all the time. I could trial most products that you can sign up for as a consumer. And we just think of trials as this thing, it's like coupons, right? We think of, oh, it just cuts an amount off my price. It's so much more complex under that because what about when the coupon runs out? Okay, what if there's a problem with the coupon? What if people want a custom coupon?

What—

and so getting into those whatabouts can get really annoying for all stakeholders who've ever had to deal with me. But knowing the ins and outs of what the expectations, those unspoken expectations are, because we take this for granted. We live in a consumer-driven society. And so things like coupons and trials and demo experiences, it's like, how hard could it be? And the answer is often very— and the decisions that we make, we are stuck with.

Just as a quick—

No, go ahead.

Well, as a quick interlude, I mean, your background in systems administration makes you so perfect to think through the details of these types of changes because they are so myriad and so complex. And I think my experience is often when you have like an executive go-to-market leader kind of trying to think through a go-to-market pricing and packaging change, they're often starting at a higher level place. And it's so essential that you're able to come in and like say, well, here are the trade-offs and here are the many, many questions we should consider here.

Yeah, it's a very strange combination of of knowing that people will want things that you can't ever possibly anticipate, which means going through a lot of scenarios, signing up for a product, and then sort of asking yourself the questions of like, what will happen when these 14 days run out? What will my experience be like if I want to convert early? Will I auto-convert? Is this going to be like a Planet Fitness situation where I have to call 18,000 people and argue with, I don't know, the Almighty to get my Planet Fitness, you know, promotional deal rolled back. And so do we need frictionless debooking? How do we handle that contraction? Has anyone talked to finance about that? Because revenue reconciliation is an entirely different process when you are an ARR-driven business. And so working out all of those details of who isn't in this room who needs to be, And what are all of the unspoken expectations that we have as consumers about the way that this could look? Tease those out and then ask, okay, is that how we want to do it? Okay, now given the timeline, can we afford to do it that way with the resources that we have? And if the answer to that is no, what are the other alternatives that we could provide that might provide us a little more flexibility, a little bit more wiggle room to change our minds later, something that makes the conversion process smoother, nicer, more transparent. And so getting down to those fundamental questions of what even is a trial and what is its purpose probably doesn't make me very popular, but the answers do. So that makes sense.

That, that to me is like maybe the title of this episode. It is such a good reminder for product managers who find themselves in this position where they're like responsible for operationalizing and executing the business's decisions around pricing and packaging and are they willing to ask the hard questions?

Or—

You have to.

Or are they not? Because if they're not, like, it's just a world of trouble down the road. One thing I want to try to spend a little bit of time on is the relationship between these pricing and packaging changes and the product roadmap itself. And I wonder if you can comment on the extent to which you have seen those two things, like the pricing roadmap and the product roadmap, be aligned, or are they often not really aligned and pricing is not—

In a product-led growth organization, the pricing roadmap is, is the product roadmap. And the reason for that is no matter how your teams are split up, no matter how you've defined them and what parts of the application they're responsible for, let's say we deliver pricing and packaging v2. Everybody's excited, it's performing great. Some other team wants to add a feature that everyone agrees should be a pricing lever. Guess what they need to know all about? Or the team that delivers pricing and packaging infrastructure has to be able to deliver the gating against that feature, which means splitting that work and that QA and that delivery over to teams who are gonna have code collisions. Like that work is very difficult to do in tandem, or can be very difficult to do in tandem, especially if the pricing team is working on the next iteration of pricing and packaging while you're developing a lever for the pricing and packaging version that we have now. So, the roadmap has to be aligned, and if pricing and packaging and monetization is the A, You know, it's your P1, it is the most important thing at the company. Everyone is laser-focused on it. And I think that's true at a lot of organizations right now. The product roadmap is going to heavily feature pricing work. And that was for sure my experience. Now, the trade-off there, depending upon how your teams are split up and what they're responsible for delivering, every quarter you spend working on pricing and packaging, you are not delivering features that act as force amplifiers for your pricing and packaging. And so that trade-off can feel very painful when you're doing quarterly or half or annual planning to say, okay, what, what can we afford to not deliver in order to optimize this beast? And so not having it on the roadmap ends up being, yes, it is. Yes, it is. Because if suddenly pricing and packaging is taking a nosedive, conversions have plummeted, No one has converted in 5 weeks, you can bet your bottom dollar that your roadmap is going to be disrupted and you are going to have a late entry into your plan. And that's as it should be, right? If money is the most important thing in an organization, and a lot of times it is, your roadmap should be disrupted. That's why we, we build in the space for the plan to change. What really sort of like a stranglehold on it though, is if you have delivered a pricing and packaging infrastructure that is so rigid. That major changes take entire quarters or quarter plus to deliver against because you're having to rip out existing or hack around existing structures that didn't anticipate the kind of changes that you'll need to make, which is painful and hard.

Go deeper into that idea of rigid infrastructure. What is rigid infrastructure around monitoring?

Some of it has to do with the tooling that you choose. Who's your payment processor? Did you roll your own? Are you using another company? What are their constraints exist around their product? Are you using a tool for revenue reconciliation so that all of your revenue reporting can occur in one system? Your enterprise deals are happening in Salesforce or HubSpot. Order forms are being filled out the same way the enterprise work has always happened, but your self-service tier happening in, you know, Stripe or whoever is doing, you know, your payment processing. What's creating the invoices? So usually there's going to be some other second-party tool, and there's a ton of them out there, and all of them have things they do really well and things they do less well. And if your pricing and packaging is not aligned with what that tool can do, it's gonna hurt. And sometimes you'll procure a tool to do that job where it's like you build out your product catalog, it looks beautiful, you build the API connections, everything's going great, You know what's terrible is updating APIs. It's just not fun work. It's really hard. There's lots of testing. And so trying to figure out how to get those systems to all speak to one another under the paradigm of what you have been asked to deliver and then to find out what you have delivered and what this tool was chosen to be able to do is wrong. It's not actually the lever that we need. And so now you're fighting with a tool that's not designed to do the things that you're trying to do with your pricing and packaging.

Can you share?

So, one of the answers there is choose a more flexible tool and think about what are the different pricing scenarios that you're vetting and could this tool do all of them? Could it do all of them well?

What's an example of where, like, you've run into a tool that was too rigid for the job you needed to do?

For sure. So, there's a push in B2B SaaS that you don't see as much in B2C. And some of that is the way that revenue works, like finances work in the B2B world. If I sell t-shirts on the internet, the thing that I need for my pricing and packaging tool is really different than if I'm selling SaaS subscriptions. And if I'm a B2B SaaS company, my world revolves around ARR. Monthly payments against a 12-month subscription is not a thing that I have seen any tool that I have vetted do well, and people want it really badly. I have my own opinions about monthly payments against an annual subscription in the B2B SaaS world, that we can unpack if you want to. But ultimately, most tools are not designed to understand this is a 12-month commitment, and we have divided up your pricing so that you are paying in monthly installments, but your commitment is that full 12 months. It's not how consumers think about things, and therefore the tools that support a lot of pricing and packaging don't think about them that way either. And so if you want to stand up this monthly payment system, You are hacking around a tool that is not designed to do that thing. And anytime you're doing that, you're creating technical debt, probably a lot of it. And additionally, you are fighting the friction that, like, the tools that you're using and your own codebase don't want these things to happen together. And so, the hack tends to be really inflexible. So, if you wanna change the price of monthly subscriptions at renewal, it's a whole nother product catalog. You know, like it's just, it's not designed to do that. And I think that the choice of tool you make plays a big part in how rigid that system has to be.

I want to dig into this. Product and engineering leaders that I speak to feel like they're having to reinvent the wheel when it comes to monetization. I feel like I'm hearing you describe, we select billing tools and we try to get our billing tools to manage product catalogs and subscriptions. But we also have software tools that we use in our code to manage what people have access to.

Yes.

And often there's a disconnect between those billing tools and those, for lack of a better term, feature management tools. Can you help us make this very visual and tangible by, by talking about like, what is a product catalog? Where does it live? Where should it live? What are the billing tools that we should be using? How should that interface with the code? Like really try to like paint a kind of an architecture map for it?

I can certainly try. In an ideal world—

You're the one that's solving the world's problems right now, so—

Okay, let me, I'll give it a shot. If I'm wrong, don't come for me. So in an ideal world, as a product manager who is not an engineer, to speak of, the thing that I found myself desperate for doing this work was a place, whether it's a tool or a framework. Something that I could map out what we needed. These are the requirements that I have. These are the specific pricing levers. This thing's metered, this thing's gated, this thing you have to purchase à la carte, whatever that looks like. I need it versioned that I can seamlessly move people like, okay, take everyone whose subscription ends on date and make them opt in to the new pricing model because that's going to save my customer success, my renewal specialists, It's going to save us on churn. Make it easy to say yes. We can design that experience in the application. It'll be beautiful. But the ability to move people from one version of pricing and packaging to another and to be able to track who's in each bucket. The product catalog, it should be in my mind, everything you sell at all the prices that you sell it at. So whether you have a Pro, a Pro Plus, and then an Enterprise plan, or you have far more offerings than that. And then the ability to say, okay, here's the plan, here's what you get, and have those entitlements and those gates and those meters be able to be enforced in your application, ideally in an API call that is performant.

Got it.

That's helpful. So, what happens when you're in a business? I mean, you've already described kind of like Crossbeam, who has had sales reps selling enterprise deals, but it also sounds like it wanted a product-led motion. And so, I could imagine you were storing a product catalog in both the CRM and the billing tool. Yes. How do you deal with multiple product catalogs? Like, what's the right way to think about multiple product catalogs?

So the right way to make multiple product catalogs work is to choose your system of record. One system needs to be the authoritative source of truth on everything that you sell and everyone who bought it and for what amount of money. In the case of the projects that I was on, The total source of truth was the overall revenue tool suite, which I believe is called Maxio. And Maxio was two different companies that merged. So the self-service product had a different name. I can't recall it right now, but essentially Maxio became— Advanced Billing was the name of their, you know, self-service tool. Maxio is the total source of truth. And I think that's correct because at the end of the day, finance needs to be able to do their job. And we need to be able to report on revenue to the board. That's the most important thing that happens at the business. It's how we all get paid. Then the CRM where the order forms are generated needs to match exactly. And Advanced Billing, which is where the product catalog lives for the self-service tiers, needs to match exactly. And then ideally what would happen is if someone subscribes in your tool, that goes to your billing software The billing software ideally should be able to speak to your CRM to generate what we need to report on revenue internally and also creates what we need in the finance tool overall so that you can see your self-serve next to your enterprise and everyone is speaking the same language. If there is a simpler way to do that, which is probably to roll your own, that's awesome. But to me, that's a whole separate company, right? Like rolling your own ability to reconcile and recognize self-serve and enterprise revenue side by side, that's an entire, I don't know, 50-person team.

Yeah. We also heard you describe several, like I heard you describe this RevRec for a couple different types of customers, honestly, a self-serve or a direct sale customer. We could add complexity on that. There could be a channel customer.

Yeah, absolutely.

So there's, there's a RevRec job, then there's like a fulfillment or provisioning job.

Exactly.

And then there's a coordination job. There are deep, there's kind of data between these systems, between application code or a database between the CRM and between the billing system. And all of that has to be kept in sync. And usually it's going to be your engineers keeping all that in sync, I would imagine.

Yes.

Which is often in cooperation with sort of the CRM, like someone in finance, someone in CRM administration. There's pretty tight teamwork that needs to happen there.

Yeah.

Which, and which kind of harkens back to your earlier point, which is it's why you often have product engineering teams spending a lot of their time on billing-related jobs rather than new value.

Yeah, it can turn out that way because the more connection points, like the more connective tissue needs to exist. For your billing, for a customer to be able to pay you money, and for you to be able to tell your board or your investors, "Hey, this person and all these other people paid us money." The more connective tissue there is there, the more brittle that system becomes.

Yeah. So, you've used the word brittleness, and you've also used the words technical debt a couple of times. Can you share a couple of examples that show how this impacts a company?

Absolutely.

So, I think that the ultimate source of technical debt, this is a hot take, The ultimate source of technical debt is, are the early foundational decisions that you make, which we know inherently because we're the most nervous about making early foundational choices. So, whether that's a vendor, or a tool, or a particular architecture that you have in mind for a given solution, those decisions are gonna constrain what's possible. For those of you who are philosophy fans, that's called the hermeneutic circle, the kinds of questions that we ask. Shape the kinds of answers that we can get, which then shape the kinds of questions that are possible after that, right? And so foundational, foundational choices are the things that constrain us, which is why we get nervous about making those choices. So an example of this is, I've seen this both as a consumer— I use a product called You Need a Budget, it's a great little budgeting app— being generous with your early existing loyal free or low-cost tier customers and allowing them to have feature-by-feature exemptions from your product catalog or discounts if they convert to the new price point within a particular period of time. Making the decision to give things away for free because someone is special is a human urge that I understand so deeply, but it does two things. One of them is, is largely sort of philosophical, which is you are teaching your user base that what you produce is low value. Because you can afford to be generous. Additionally, what it does is it makes the engineering and infrastructure work have to account for all of those exemptions, which almost always are going to require human intervention and human error. You're not going to be tracking everybody who's getting the discount. You're not going to be tracking everybody who's getting the exception to this particular— like, you can keep your seats for another 6 months before you pay us. This is expensive to maintain. It's expensive to build. It's expensive to track. And eventually, it becomes expensive to roll back, both from a technical perspective. How do we sunset all of those perks? How do we sunset all of those, you know, gratuities, if you will? But additionally, it's expensive for the company because when you take things away from people that you originally gave them, they're going to have a sour feeling about it, and they're going to have something to say. Now, will that stop them from using a tool that's valuable and creates money for their business? Not necessarily. Are they— is their net promoter score going to be great? Probably not. Probably not. So YNAB, You Need a Budget, changed their pricing not too long ago and said, don't worry, everyone who already pays us, you will be paying us the price that you pay us forever. You are permanently— I don't like to use the word grandfathered, it has a terrible history, but like you are permanently given this special status as an early adopter of our product, and we're never going to charge you more money again. And lo and behold, 2 years down the road, they were like, JK, we for sure need— we for sure need that money, actually. And people were really upset.

Yeah.

And what was funny about this, Fynn, it's a budgeting tool. The whole premise of you need a budget is you should be able to plan for your expenses that are annually occurring and be able to save up for them over the course of the year. So that $90 subscription that's annual hitting doesn't feel like $90 because you've been putting $3.50 into the bucket this whole year. And they gave their own users less than, I think, 3 months notice that they were going to be charging them a substantially bigger price, which is like against the spirit of the thing that you do and the product that you make. Do I still use You Need a Budget? Yes, I do, because they solve a novel problem that I haven't found a better solution to, and I'm happy to pay the money to do it. But things like that where you make these early, either generous decisions— an example at Crossbeam, the original pricing model was you get 5 seats for, I think it was $6,500, something like that, for 12 months. And if you paid annually, there was— it was— or if you paid monthly, it was a larger surcharge. Lots of people weren't using all 5 seats, which makes it hard to justify the $6,500, right? But they did want other things that we could make them pay for. Setting up your product catalog to say the first trench of users is included in the plan and then pivoting to every seat is a seat that you pay for is a foundational change. And it doesn't feel like it should be from someone who didn't have to set the system up. You're not looking at the product catalog to see how it's built out or any of the APIs that go to grab this information. So, things as simple as, "We want to raise the price from X to Y," can be colossal under the hood, especially if you also want people who are on your current pricing to be moved up to the new number upon their renewal date. These are the things that, as consumers, we take for granted because we interface with them all the time. But from an engineering perspective, they're actually quite hard if you made foundational choices that exclude that change. At the gate. Does that make sense?

I'll just tell you where my mind was going, because part of what you were describing is like, how do we deal with a legacy customer set? And part of the implication of that story is you end up with like cohorts of one. And you know, you could have a business that has like hundreds of cohorts of one.

Yep.

How do you deal with that? That's really, really taxing operationally.

And it's not a question that people know that they need to be asking.

Yeah. Yeah. Yeah. I mean, it's so good. You know, what was the word you used for the philosophy question earlier?

It's called the hermeneutic circle.

Hermeneutic. Okay. I want to talk to you. That's another topic.

I want to say it's Husserl, but like, it's been a minute. It's been a minute since I was in school.

Is the root cause of technical debt the fact that you've got a bunch of customer exceptions to manage, or is the root cause that you've like hardcoded what they have access to in your product? Or is there's really no root cause. This is, this is just a, this is a systems problem with a bunch of complexity that could have come from different places.

I think ultimately, uh, if my professors could hear me now, you know, I think ultimately the root cause is, is the hermeneutic circle, right? Like the question that you ask at the outset of a project, what is the fundamental unit of value in monetization? Right? What is the fundamental unit of value that we believe customers get money for investing in our business, essentially? Right? Because in SaaS sales, that's what we're trying to do. Everybody's trying to accelerate other people's ability to make money. And so, what is the fundamental unit of that in your application? Is it a seat? Is it an API call? Is it a set of API calls? Is it an interface? Is it an actual file? What is the fundamental unit of value? Once you answer that question, you have invisibly eradicated a field of possibility. And if you don't poke at that and ask the questions, if we make this choice, what will no longer be possible in the future without total rearchitecture, complete redesign, like literally rolling everything back and starting from scratch? What have we made impossible if we make this choice? If you don't ask that question, you have already begun creating technical debt because you're going to want some of those things and you don't know it. Not to put too much pressure on decision makers or anything, you should probably hire an in-house philosopher, just saying.

Imagine listening to this episode are a bunch of product and engineering leaders at B2B SaaS companies doing anywhere from a few million bucks in ARR to 50, 60 million bucks in ARR. And they're trying to figure out how to help their companies support and operate on pricing and packaging monetization more effectively. What are the off-the-hip top 1, 2, or 3 best practices you'd want to leave them with, given everything that you've learned?

Dig in, get very comfortable with discomfort, and do not relent when it comes to asking about scenarios that no one has thought of.

Be the clarity creator.

Yeah, absolutely. It's so important. And also, product people, I think, are uniquely positioned to do this because we often are already the universal conduit.

Right?

We speak every language in the organization because we have to. We have to be able to speak to marketing. We have to be able to speak to engineering. Engineering and marketing talking together can go wonderfully, but not always, depending upon the engineer and the marketer involved, right? Because their remits are completely different things. They're thinking about what we make as a business in completely different ways. One is going to be much more prone to storytelling. Because stories are what compel people to be interested in a product or a particular feature set, whereas engineers tend to be problem-based. This is the thing that I need this massive code to do. How do I make it do that? And so, product people are uniquely positioned to be at the center of that dialogue, to be able to say, okay, marketing wants to be able to tell this story, and sales has these particular goalposts and differentiators. How can I turn that into deliverable requirements that are testable for my engineering team? Also, engineering is having this set of problems delivering the thing that they've been asked to do. My job is to come up with a list of potential alternate solutions and then go back to marketing and sales and executive leadership and say, "Hey, we're hitting a road bump. This is what's happening. I'm not an engineer, so I can't go fix it, but like, this is what I'm being told." poke the holes, ask the questions, will this work for you? Getting very comfortable in that space is what makes you successful at monetization and pricing and packaging work.

I think that's a phenomenal answer, and I think it lines up with, um, other people that I've talked to in this world who often encourage people to be bold around this space.

You have to. You cannot be shy. If the idea of an executive, someone with a C in their title, handing you a list of things that they want, if your initial urge is to be like, well, I guess we have to do that, you'll learn that lesson one time and you won't, you won't do it again.

Harker, the closing question I like to ask is, um, for the specific experience that was most formative for you.

Yeah, taking self-service pricing from 0 to 4 over 2 years was the longest, hardest, most demanding, most sustained effort of my life. And that is saying something because I was hire number 1 started a startup prior to my job at Crossbeam. I cannot understate how intense it is. It is high stress, it is high visibility, it is high stakes. And professionally, I learned so much about the art form of scope reduction, about the importance of clarity. If I can't explain your pricing model in 5 minutes to someone in engineering, someone in marketing, someone in sales, and someone in customer success, I can already tell you we can't explain it to your customers. They're not going to know what they're buying. And the ability to look people in the face and say, I understand and I believe you that these levers are meaningful. But what I'm asking you to do is say, is it taking you 45 minutes to explain this? Because maybe then we need to prioritize. What are the most important levers? What are the most monetizable things here? And to be able to really push into those difficult conversations, be persuasive, because what is the thing that everybody says about product managers? We lead with influence and not with authority, and that's a fact. And so, being able to properly document, to do your diligence around documentation, if you come out of a meeting of pricing decisions and you literally can't capture it in a document, guess what? You're going right back into that meeting because you don't have anything to hand to your engineers to say, "This is what we're pivoting against," or, "This is the decision that got made." The ability to distill that information down, sit back and say, "So, let me make sure I got this right," and move forward from there is something that also serves me in my professional life and my life as a parent. And my, you know, like, I've got a kid in college, I have to negotiate all the time. And so, undervalue those skills. You are not a delivery machine, uh, is like a thing that I really had to learn and take to heart.

This has been so much fun talking to you. Where can—

anytime—

if anybody wants to learn more from you, where could they reach out?

Right now the answer is LinkedIn, as it is for all of us, whether we like it or not. And I'm in the middle of standing up a personal site. Once that's ready, it'll be available. My LinkedIn, my name is Harker Roslyn, my pronouns are he/they, and feel free to connect.

It's been so much fun. Thank you.

Yeah, I had a great time. Thanks so much, Fynn.