Monetizing SaaS: Episode 6 with Steve Bussey, Co-Founder / CTO of Supered.io

All right, Steve, so good to be here with you. Thanks for doing this. Um, it's been great getting to know you over the last year. You've been a developer, you've been a serial founder. Can you tell us a little bit about your career and the steps along the way?

Yeah, thanks for having me, Fynn. Uh, happy to talk with you here. So, uh, serial founder, I don't know if I like the sound of that or not. Uh, uh, maybe one day I'll be a serial founder and make some like Kellogg's or something like that. But, um, So I'm a software engineer and sort of turned founder now, I guess, in the technical world, but actually like all things business, which I think is part of the story. So when I was in college, I was like really gung-ho on like continuing education. I actually liked school a lot and I was like, you know, would a PhD or something like that be cool? You know, you go to school for longer. Yeah, weirdly, I like, I really liked school, so it was, it was actually on the table for me. And I got this internship at a web agency my sophomore year, summer going into junior year, something like that. And I was building WordPress sites and stuff like that. But at some point in time, and I was like pretty good. So at some point in time, he was like, hey, how about, how about we start building? I have this idea where I want to track people on the website. So do it. So for like you know, like lead analytics and tracking so we know the value we provide. And I built this SaaS product and it was actually really successful. It was like an internal SaaS product that they gave to all their clients, but it was a huge value add. And, you know, we had like 500 clients on this thing and it was just me working on this basically then through the rest of my graduation. And that actually changed. There were several things that happened along the way of doing that where like in particular, we got an email that was like, like you helped me close more deals that I wouldn't have gotten otherwise. I was like finally able to get a dog that we had been like budgeting for basically because I had more revenue coming in and that made me just change and be like, what is like the SaaS stuff and the power of SaaS? And so after that, I just like, hey, let me, I'm actually going to go full into this and go into the SaaS world. And I was lucky enough to get a job at Salesloft, which at the time was one when I started talking to them was probably 6 people and probably 10, 12 people by the time I joined after I graduated. And I stayed there for 7 years or so, was with them from basically $1 million up to close to $100 million in revenue. And the whole time that I was there, like the decisions that I made and the way that I prepped myself were like, I'm going to be a startup CTO. I'm go— and what that means is I need to be able to build product. I need to be able to lead teams. I need to be able to do things very self-sufficiently in terms of like design and building and developer operations, all these different things. And that's like, I just learned as much as I could. And then when I finally left Salesloft, it was to start my own thing. Failed at that for about 18 months and it didn't go too well. But the, the next startup I did, which is where I'm at now called Suprd, we've had a good amount of success so far and And you know, I'm finally able to use a lot of those lessons that I picked up from all those years of basically like prepping myself.

It's so awesome. Such a good story. Um, what an incredible journey with Salesloft and now a great start at Superd. Can you tell us about Superd? So what's the, what's the insight behind Superd and what's your vision for the business and for the product?

Yeah, so the co-founders with me at Superd, they actually, uh, were running a HubSpot Solutions partnership, which is basically a company that provides professional services on top of HubSpot. In particular, revenue operations was their sweet spot. And so I worked with them to spin Supard out of that and as a separate company, but with one of their co-founders, Matt. And our, our big thing was just focus on this idea of adoption of HubSpot. And that's sort of what we built around. But as we built the product, we launched it, we actually realized there's a bigger market in helping partners deliver their professional services, both like very tactically, like giving them a tool that they don't have otherwise. So that's one of the pieces that we build. But then also this whole idea of adoption, sort of, it is maintained as adoption. That's the end state of it, but it's really about delivery. So they're delivering trainings and education pieces. They're delivering their work through the HubSpot app to their end users, the people that they serve. And we provide things for those end users as well. So it's this nice little, um, it's been this nice little play where we can basically give tools to the partners that they pay us for, but they're also bringing in their own clients because we give them tools and we help them, you know, do things better in HubSpot. And so that's been the sort of the interesting play that I think is not that common to have these like two different people that sort of are, you know, feeding into each other as, as your clients.

Very cool. Where does it go? Where do the next five years look like?

Yeah. So when we launched, I was, um, I was optimistic, but I'm even more optimistic now as we've grown in terms of what we can do. With the product. And so I think this idea of delivery for partners is really impactful even outside of HubSpot, like in Salesforce ecosystem or, you know, uh, Monday, these other, you know, sites that have professional services on top of them, helping those companies actually deliver their service better. So I think that's like really interesting. I think there's a huge market there because obviously professional services is a huge industry. And education is specifically a large part of that. But then I am also very optimistic about what we call process enforcement. It's this idea of like, you can document your processes, but unless you're enforcing them, the document, like you need to have both. And so we have this whole play that I think is potentially competitive with much larger apps that are $100 million plus revenue businesses that are focused on enforcing processes. So I think those two things, like we'll see where it goes if it skews to one or the other, if we'll just like push both as far as we can, but I'm very optimistic now that we could build a $100 million revenue business.

Awesome. Yeah. And it's like, it seems like some of the dimensions here of expansion are like into new ecosystems like Salesforce, but also into like business process management, which at scale is like huge, huge revenue potential, huge market.

Yeah. We, we haven't even touched like the Salesforce ecosystem mainly. It's like a go-to-market play. Like our, our focus is on HubSpot, but everything that we build is built with that in mind where it's like I could go and build our process rule engine in Salesforce in like 2 weeks.

Yeah.

Because it's built for that. And, and a lot of our product actually does work in Salesforce or other, other apps. We have partners that use it for monday.com and HubSpot together. And that's because it works on any, any website.

So, and if you were to poll some of your customers and just say, hey, why do you buy Superd? What do they generally say? Like, what's— how does the layman who may not understand sort of exactly what you're doing, but just wants to understand why your customers perceive value. What are the, what does the customer say to that question?

Yeah. So for partner, I'll focus on partners here instead of end users because partners is our main revenue source today. So the biggest thing for partners, every single partner wants to be more than a one-off relationship. I want to actually create recurring impact with the people that I deliver to because that's how I mean, they're businesses and they're trying to grow and you grow especially by having recurring customers instead of just one-off projects. And it's, it's very difficult for them to do the recurring impact. It's like, like what is the recurring impact for these, for these companies and how are they actually making themselves known to more than just one or two people on the team? Because if only, If the RevOps manager and the, and like the sales manager know who you are, but none of the other people do, you're going to be quick to get cut, right? Because you're not having impact across the whole team. So with Super, they're able to do basically like leave-behinds and trainings and delivery to all users of the team. Uh, and we also, this is fairly unusual, I think, for startup our size, like being very small still, we let them fully brand our product. Mostly fully, like there's some things that aren't brandable, but most things are. So like the logos, the colors, the title, the, like we, we hide, we let them hide certain things that, you know, remove some of the super-ness and have their own product because it creates this leave-behind effect where those people on the team actually know and they can start forming a relationship with that partner. And that's how they create the recurring impact where now, you know, before they would have been a $25,000 project. Now they're that $25,000 project plus, you know, a $5,000 a month retainer to do, you know, everything RevOps related for them powered through Superroot.

Super cool. Um, you've been building SaaS for like more than 10 years. Like you've, you've lived and operated at this very interesting time in SaaS. I'm curious when you zoom out, when you think about building software companies today, are there market inflections or big, big changes that you yourself are particularly interested in?

Yeah, so I don't know. I mean, a lot of these things are hypotheses. Like, I don't know if this is right, but one thing I've noticed is in the past, the advice from founders that had exited, you know, successful founders, was basically like, do one thing and do it very well. Find your niche, like find your buyer, focus on them. I think that more and more companies, not necessarily like the individuals, but companies as a whole want to buy larger suites of software that are easier to procure are ultimately cheaper if they're, you know, if they have 3 softwares at $50 a user versus 1 software at $80 a user, like they're, they're actually saving money if they're able to deliver the same experience. So this consolidation of apps, I think that I'm curious to see if successful founders in 2029, 2032, you know, like 5, 10 years from now will be saying, oh, actually build a consolidated app. And they'll be wrong because there'll be some new trend then. But I feel like that consolidation is a big thing. The other, one of the other big trends is building companies with less funding, you know, through 20, like 2012 through 2022 with the way the funding environment was. And like, like Salesloft was this way, right? Salesloft raised probably $240 people say $250 million over the lifetime of the company and exited for like $2.2 billion or something like that. So it was like they, they did the playbook and it worked for them. But I think more and more that playbook, it's still happening. There's still companies that are bringing in that sort of funding, but I think there's almost this expectation that companies will do more with less funding. So I think that'll be important. And then there's, you know, tactical trends. Like I think there's always some sort of like innovation or trend of a 3-year period. And I say it's innovation, it's more than just a trend. Cause like AI is not just a trend. Like AI is an innovation. It's able to do more things than it then could be done, but it is like very trendy right now. So there's those sorts of things as well. I think those are very tactical and probably have like multi-year waves of popularity, but.

That's excellent. You know, I think one thing that I think is so interesting about you is having been at Salesloft for the 7 years you were there and now having started 2 companies, one that didn't find product market fit, one that has, you've, you've had to learn how to build alignment and deliver value to customers through a ton of complexity and through a ton of business evolution. So I'm curious, you know, what are the techniques that you have found to be most effective for you personally to go build trust and alignment? Maybe first between product and engineering, always a really interesting dynamic.

Yeah. So maybe it's a hot take. I don't know that it necessarily is. I don't think the idea of like product should necessarily exist in like really small startups. I think maybe founders are doing that role. So when I think of it, I think of like, well, I don't have product, but really I do. Like my co-founder plays that role. Product in addition to myself. Um, cause I, I'm not the best person when it comes to product engineering relationship. I think those, I think it's a very, it can be a difficult relationship and it has been difficult for me in the past. I think product people have product in general, like not product people, but like the idea of product. And I've even seen this with Super is difficult for a few like specific reasons, which is backlog always grows. Like, I mean, it was this way at Salesloft where it was just like, it felt like nothing you do, you would ever make a dent in the actual backlog because there's so many ideas coming in, so many asks. Um, everyone wants to get things done ASAP. Uh, there's often, uh, stakeholder shifting and there's often power imbalance. Like if, if me, the engineer talks to my product person, but the CEO of the company comes in is telling the product person something directly, like who's gonna win? Obviously the CEO's gonna win that, right? So it's like there's this power imbalance also that makes it then I think that is it, it can create this difficulty in the product engineering role. I think communication is probably the big thing there, right? Like Engineers are the doers, like they are building things tactically, like hands on keyboard. I think it's easy to fall into the trap of like, oh, just go build this, just go build this. Don't really think about like why I'm asking you to do it, just go build it. And then it's like, as soon as you get pushed back, it's like, why? Like, there's so much stuff to do. Why are you pushing back on this? We just need to go build, build, build. I think, you know, keeping that communication good and remembering that both sides, there's human beings that have feelings and thoughts is important. And it's easy to forget about that when the backlog is always growing and everything wants to get done ASAP. But then, you know, having, having the process where engineering and product are working together to solve the problem, because it's really easy to start working against each other to prioritize their own interests. Like engineering has their own backlog that they need to work on and product has a separate, but it's like all these things add complexity. So I think just keeping that open communication. So. Um, the product engineer relationship, not good for me. Uh, but I do think GTM, uh, and like when I say GTM, sales, marketing, just people that are interacting with customers, I actually think that's really important for engineers to have a relationship with those people, especially at small startups. Like I tell salespeople that are starting, like, I expect to work with you on things. Like I want to hear feedback from customers. I want to make changes based on your expertise. And one of my like secret weapons at Salesloft. Was just having relationships with salespeople. Oftentimes because I worked with them for many years, like as the company got bigger, but even new salespeople that would come in, um, you know, you would get people that, you know, try to put together a coffee with an engineer or something like that. And I think leaning into that is really useful as an engineer because those people often had good ideas. Um, they often would raise issues about downtime or bugs because they were on like a demo and something bad happened. And I would often get things from them before automated systems even picked it up that if I didn't have that relationship with them, it wouldn't have happened. So I think forming that is really important.

It's really cool. So build relationships with frontline sellers with go-to-market, but also when you're crafting relationships with folks on the product side, it's like, how can both sides communicate with more empathy and maybe with more why? Am I, am I hearing you correctly?

Yeah. Yep.

Yeah. That's great. You know, you have a ton of experience, not only building SaaS, but like building monetization systems within SaaS companies. I'd love to talk about monetization as a topic. I mean, it's something that I think a lot of companies are thinking about. It's increasingly really complex to support the way we monetize our SaaS companies. I'm curious, what complexity do product and engineering leaders need to understand as they build? For example, earlier you mentioned one of the big trends you're thinking about is, you know, multi-product suites. So what are the real kind of levers of complexity that product and engineering leaders need to understand and consider as they think about monetizing their SaaS products?

Yeah, this is hard because Um, this is what I tell the team when they bring like suggested pricing changes, for example, is that most things in the business I can go like build in a couple days and have like a prototype and have it working. And if we need to like change something, it's not that big of a deal. I think this is one where that starts to flip a little bit where I actually say, hey, we need to be really careful about changing it. Because it's going to be pain— like, I don't want to change this now and then a month also change it and then change it 2 months from then. Like, because it's, it's painful every time we have to change it. It's very cross-cutting. Um, especially if they want to switch from like a per-seat model to like a usage-based model. Um, because then I need to add in all the different triggers for calculating usage and how, you know, what do you do when people are over? It's just like a lot of complexity goes into that. So I think being aware that like changing it can be difficult is important and that you should really spend some time making sure that you're happy with the thing you're putting together and, you know, don't change it every month. Having like, I actually think one thing that's interesting is Matt would do this all the time and it never bothered me is like he would change the price, but do it through like different means other than like changing the actual pricing, whether that means like giving certain discounts or like some way of structuring it. But he would come in and basically be like, all right, I'm gonna, I'm experimenting with pricing. I'm doing XYZ and doesn't impact you, but just know I'm like changing. So I think having abilities to do that at a high level, and that could be as simple as having like coupon, like arbitrary coupon system where you can like change the price for things on the fly. That was really useful because he was able to play with the pricing. Like every call he'd be like, all right, let's see how they respond to this price versus that price the next call. And basically the goal is obviously to like work up the number as you get customers. So you're increasing that.

Um, so it's interesting. I mean, you've built, I believe you built, you built kind of pricing and packaging infrastructure early on at Salesloft. And I assume that you have, you have architected how Suprid will support monetization.

Yeah.

You know, a bunch of product managers and engineers are listening to this and they're thinking about monetization. Like, what are the architectural components that dictate and govern monetization and B2B software that other operators should be aware of to kind of paint a picture of how to do this and how to build this and how to think through it?

Yeah, the just thinking like from that perspective, from like a product and engineering perspective, it's very cross-cutting. It's sort of like in the same realm as like a permission system is cross-cutting. Like if you have a permission system, pretty much everything needs to be aware of the permission system. So this is similar to that where it fully cross-cuts your app, which means, um, you know, you just, uh, You don't want it to be like, it's okay to be a little hacky, but you don't want it to be hacky. Like you want it to be something that, um, people can use easily so that when they're adding a new feature, they can hook it into the billing system easily. And they know how to, um, display different UI states to the customer based on whether they have billing or not. And like, not every feature will usually be affected by it, but like, let's say like 75% of features will probably touch. Billing in some way. It could be as simple as like an access check. Do they have access to this feature? Yes or no? Um, or it could be something more complicated. Like they get 20 of these things and we need to make sure they don't go over that. And what's the solution going to be? It's very, it's very cross-cutting in that way.

Well, just, just there, like, I feel like I heard you list out at least 3 components. Like there's the feature, there's like the metering system, there's the billing system.

Yeah. There's invoicing, like, give me my history of it. I need to submit my receipts for taxes or whatever.

So is that like roughly the commercial content, like the contract?

Well, so that's even a set. So we sort of punted on the idea of a contract, to be honest with you. We do what I don't even know what to call it. I mean, it's technically binding, but it's, it's not a, it's not the same thing as a full contract where we say, you know, check the box to agree to XYZ. And there's sort of an implied contract by using it as part of the acceptable use policy. But that's not— I mean, we don't— I've just chose to not even touch that because basically like my billing system now, I just did it through Stripe. I was looking at a tool to decide whether to use it or not and ultimately chose not to. And when I looked at Stripe, it did a lot of the stuff I needed, but then there's certain things that were just like I couldn't do, like I can't do signature capture through Stripe. So I just chose to punt on it basically. Yeah. But that's a challenge, right? It's like if you're product engineering, you might have a lawyer or the CEO saying, no, we need to have contracts and we need to, we want to make it automated. Or, you know, most, I think maybe most people end up making the contract separate from billing because it's, it's really hard to like put them together that way.

But right, often the contract like lives in the CPQ product or the CRM or something, which is how Salesloft evolved to in the end.

And, and, and the challenging thing with this is like, I mean, I'm thinking at Salesloft, like I probably, I worked on at least 2, maybe 3 billing systems. And one of them was a standalone billing suite that like largely myself and like the team that I was with built from scratch. And that system, what supported multi-product packaging, could change packages, could— it had terms in it. It did all this different stuff. And then like the business just completely changed how they were selling the product. Like literally, literally every single thing that we build in that became moot because they just completely changed the selling motion. That was a year of work, right?

So a year of work where engineering built a homegrown billing system and then it became obsolete.

It had a cool name. It was called Billio. That was the best part about it. But yeah, I mean, it was, it was like effective at what it did.

Yeah.

Until it became obsolete. And then it would have been, it would have involved, it wasn't even really that the way that they build became obsolete either. It was like, oh, we need to make, we need to completely change our CPQ process to make it sales-driven. So if we need to change something, sales can change it. Like a sales leader could change it or the deal desk could change it versus having to ask engineers for changes. Like if we want to add a new product, engineer has to put it in. And so it was more of, I would say, aligned with the business decision. It sucked, but I mean, I didn't feel like too hard about it, but I was like, man, that was a year of work that sort of just got lost.

But it feels sort of like representative, right? Like it's almost inevitable that pricing and packaging and how you monetize will change all, you know.

Oh yeah.

Forever.

And it should, it should, right? Like maybe not, you know, completely changing everything about your product pricing every 2 years. But like in a 10-year lifespan of a company, I would probably expect like 2 major shifts of their billing infrastructure. Like, yeah, like just completely like being like, oh, we're going to shift from seat-based to like multi-product, multi-suite, you know, multi-seat-based. And, and we want to have different seat allocation across different products. Like I think things like that are pretty inevitable to happen as a product expands.

Right. It seems like, you know, you're inevitably going to try to support multiple go-to-market motions. You're inevitably going to try to play around with different billing models. Maybe you end up in like a hybrid billing model and you're going to go multi-product if you're scaling. What are the sort of like most important lessons that you would try to share with engineering leaders and product leaders who have to think about building these systems to support monetization?

Yeah, that's a good, good question. I guess the biggest thing as I'm thinking through it is there needs to be in the room discussion discussing how the billing system is going to work. There has to be some type of revenue leader there. I think specifically it was sort of, it was after I left, but I know for a fact that there were times where people were working on a billing system and then it got to the salespeople who were like, what the heck is all this? Like, I don't even, this doesn't do the things I need to do. And that's because oftentimes when we do products, we're conditioned to accept requirements from stakeholder, formulate the plan, maybe you've shared back to them, take it to engineering, but things inevitably change in that whole process. Like, like software does not work that way. And so that, that stakeholder and, and playing games of telephone of going through two different people to get to the stakeholder. I think like that's just, I would not do that. I'd be like, all right, stakeholders, like involved in the process to make sure that the outcome is what the business needs. Otherwise it doesn't matter how good your architecture is. It doesn't matter even what tool you're using. Like you're going to then build something that you cross your fingers, hope that meets the needs of what revenue needs.

Yeah, that's great. By the way, pause. Are you good on time for like 3 more minutes?

Yep.

Okay. Um, back into roll. What are the biggest mistakes you feel like you've made around building and maintaining monetization at the companies that you've been a part of?

It's a hard question. I don't make too many mistakes. No, I'm just kidding.

Um, um, maybe think about it less as like these were not technical mistakes, but they ended up being costly for the business or something like that.

Yeah.

Um, sounds like one potentially was like not forcing the issue of having a revenue leader in the room.

Well, we had a revenue leader in the room for that one, for that system. Um, at least when I was there, I think after is when it became more product-driven, but, um, it was the co-founder. I mean, the co-founder of the company was, was there, right? In the room attacking the problem with us. I think, um, and it's okay that it changed. But I think, you know, it's hard, like it wasn't a mistake at the time necessarily because we were operating with the best information that we had. But I'd say like, you know, I'd really maybe push back of like, hey, we're about to spend like potentially 6 to 12 months building this out. It's going to touch every part of the product, which means like removing it can be dumb, but it's going to be annoying. Is this something that we actually should be building? Like, or are we inevitably going to shelve it and buy something off the shelf anyway? In which case, should we just do that? So that was probably like a— probably should have more discussions. If it was me now, knowing what I know, I'd probably talk to the founder and just be like, hey, why are we building this? Like, let's walk through it. Like, have you looked at other options? And like, why, why are we building this versus like, should we buy? And, you know, having some type of like decision matrix of making that, helping to make that decision.

Because it is a buy versus build decision. And then the question is whether the off-the-shelf products can like support the actual complexity, right?

Yeah. Yeah. So that's, I mean, when I evaluated one, that was sort of my, my big takeaway is like, the buy didn't make sense. And so we built it ourselves. And it's the type of thing is like, once, hey, once I make that decision, we knew it as like, I'm not, I'm not going to change this for at least like 2 years.

Right. Right.

Um, and so I think having that discussion, we, I did that, we did that at Superbird as we were building is like actually thinking through, right, what, what, what do we want to do for this now? Um, and then I feel like, I feel like I was generally happy with the billing system. That we built as we were using it. So it's like, I feel like, you know, it wasn't like the worst thing or the most difficult thing to build, but it just cuts a lot across the app. And so having that be useful was— be fast and efficient was important. Um, so I feel like the actual act of building it wasn't too bad, but Um, just thinking it's the biggest challenge I have now is just like, all right, building yourself into like a rigid system where it's like, if I wanted to flip to a usage model instead of a flat model, like how much, how difficult is that going to be?

Right. And to your earlier point, like if I know that inevitably this will change and change and change, and I've got probably like daily exceptions to deal with as my customer base evolves. Do I have enough flexibility baked into the system or am I going to end up monetizing based on like my system's constraints rather than—

Exactly. Yeah. Yep. Yeah.

Yeah.

Basically being like, well, it'd be cool to do a usage base, but it's just not, it's just not prioritized. Yeah.

Right. Right. It's too hard. We can't do what the customer's demanding. We got to do what our systems effectively require.

Yep. Yep.

Yep.

So I think that's, that's, that's probably the big thing is just like being like, and like, that's just, I feel like that's just going to happen when you build. Like you will, like you should build things that are rigid because you shouldn't spend time building a completely flexible Stripe competitive billing system.

That's not what you sell. That's not your core competency. Yeah. Yeah. Yeah. Um, Steve, where can people find you and where can they learn more about Suprd?

Yeah. So we are all on LinkedIn. So that's probably for, for Suprd. That's probably the, the best place to find us. I'm personally in sort of a more in an engineering capacity, more on Twitter. And so that's— so maybe you'll put my handle in like the show notes or something like that.

But it's— yeah, what is it?

It's Yoda with 4 Os and 4 As. So it's like Yoda. There's a story there, but I won't share it here. But involved drinking Canadians, drunk Canadians, probably. So anyway, that's, that's where all my, that's sort of my engineering life is on Twitter. And then my like business life is more LinkedIn. I rarely talk about engineering stuff there.

Excellent. And where can people find out more about Suprd?

Suprd.io is probably the best place. And that's super ed dot io. So we, it's like, I think it's a word. I think Suprd is a word. I'm going to say it's a word. But most people are like, they don't grasp it. So, uh, we'll get there one day where people like know that it's a word.

You're making it a word and your branding is incredible. So whoever did the brand, give them my shout out. Um, so good to be with you.