Monetizing SaaS: Episode 5 with Rob Eanes, VP Product at WorkLeap & ex-Co-Founder/CTO of Pingboard

Rob, it is so good to be here with you. I've known you for, I don't know, like the last year, year and a half. I was introduced to you by my co-founder Ben, who you've worked with before, and you have given us such great feedback and advice on the product that we're building. You've been a developer, you've been a founding CTO, you've been a VP product, probably more than that. Can you tell us about your career journey and the steps along the way?

Yeah, of course. Um, first of all, it was a pleasure talking to you guys. I always enjoy the early stages of a startup, uh, maybe even more hearing about them. And helping out from the outside than living them. Although it's fun, it can be very stressful. But yeah, so as far as my career, you know, I got out of college around the time of the dot-com crash, to date myself, but I was able to find an engineering job at a company that was kind of like an agency-type model. So I think that was actually a really fortunate way to start out because I got to work for Fortune 500 companies on projects as well as really tiny companies on different projects. It was a small company environment. So I was able to basically right out of college step in and if they had stuff to do and somebody raised their hand, that person would go do it. So there was that opportunity to kind of like see and be a part of all different kinds of aspects of these projects. You know, from the very beginning, I had exposure to other things besides engineering, right? So I was an engineer, but I was working very closely with project managers. You know, for a time I was a de facto sales engineer. You know, I would go out on calls and, you know, talk to potential customers. So it was great. It was a great first experience. I stayed there for, you know, little less than 10 years. And, you know, at that time tried my hand at, you know, basically just being an independent contractor, you know, building on what I learned. I thought maybe I could do some good business on my own. And while that kept it afloat, I learned in that experience of being a solo, you know, consultants with things I really did not want to do. So I did not want to do accounting and, and all these sorts of things for, for running a business, at least not on my own. So I was looking for kind of in between there. And I knew a guy down here in Austin. I was living in Cambridge, Massachusetts at the time, but I knew a guy down here in Austin who was really plugged into the startup scene, Josh Baer. He had known him forever. And he was running basically a company that helped out startups. So that got me into the Austin startup ecosystem, moved down here. And I met Bill Babel, who's good friends with Ben. And he was at a point where he was looking to start a company. And that became Pingboard, which we started about 10 years ago. So about the last 10 years. We've been building Pingboard as, you know, a org chart company directory tool that helps you know who's who and who does what at your company. In December of last year, we were acquired by a company called WorkLeap. And WorkLeap has a few different products in its offering suite. Some of which had a little bit of overlap with Pingboard. And so it was kind of like a natural fit. Like there's a little bit of overlap and a whole lot of complementary functionality, customer bases, you know, culture. So, you know, most recently in the past 6 months or so has been all about kind of figuring out how to and executing on vision of, you know, Pingboard and WorkLeap. And, you know, WorkLeap itself is kind of a new brand that is growing and establishing itself.

Um, thank you. Such a cool journey. And building Pingboard for 10 years, then being acquired, a huge milestone. Um, 10 years is a long time, and that's— I think a lot of founders like just don't appreciate that that's often how much time it takes. So, can you talk a little bit more about sort of the vision now, the vision for the two companies? Like, what are these combined companies? What does WorkLeap want to be over the next 5 or 10 years?

Yeah, I mean, WorkLeap's mission couldn't be simpler. It's to make work simpler, right? So, Pingboard, I talked a little bit about, is designed to help you know your customers, know your coworkers, sorry. To make connections between the people that you work with and to really communicate, you know, with them in a more natural and better way. And I think everybody can kind of relate to the fact that things are a whole lot simpler when you have that shorthand with people, when you know more about them. Like it's always, there's that feeling out period with like new coworkers or just new people in general. And we help ease that transition by helping you make those connections. You know, WorkLeap has a very mature tool called OfficeVibe, which is the piece that kind of overlapped a little bit with Pingboard because Pingboard also has features for employee engagement. So being able to survey your employees, see how they're feeling, Officevibe's features in that area were more advanced, you know, more mature. And so it's kind of like naturally like Pingboard customers were working towards kind of a level up there so they can integrate with Officevibe and get some of these employee engagement features that Pingboard either didn't offer or, you know, offered a kind of a less mature level of functionality. But it's all about the, you know, it's about a bigger employee experience as well. So there's also an LMS system, like a learning management system under WorkLeap. There's some interesting new products that are coming to market on onboarding, specific to onboarding new employees and helping you with like skills management. Really helping career development, those kinds of things. And the original, WorkLeap is a name that was a brand that was established last year. Before that, it was Officevibe and this other company called ShareGate. They were the same company, but kind of sort of separate from a brand perspective. And ShareGate is really interesting because they are very deep in the Microsoft ecosystem. So, it sounds a little bit, less related at first, but they help you manage your Microsoft 365 in so many ways in terms of migrating data either into it or helping within Microsoft, making more effective use of Microsoft Teams. So, they know IT people really, really, really well. And Pingboard and Office 5 and LMS and some of those other things, we know HR people really, really— and between IT and HR, there's a huge amount of impact on how simple and good your employee experience is. And so that's really kind of like the big picture is how can we help companies with these two fundamental areas? Become better places to work, right? So that's the really exciting thing to me is that, you know, we're all working on something that we all want, right? So yeah, that's it in a nutshell.

It's so cool. I mean, it totally resonates with me, this idea of a bridge between IT and HR. Like, that is 100% resonant. And the IT experience is so crucial to the employee experience. The HR experience is so Makes complete sense. You've transitioned, I think, from being a co-founding CTO to now leading product. Can you talk about that? I mean, those are two really discrete, distinct roles within a company. One is often considered more the why, the other is more considered the what. But talk about what you've kind of learned. What's it been like to kind of make that transition?

Yeah, it's been really interesting seeing things from the other side. I've worked quite a bit at smaller companies, so that fence was very low, right? The other side of the fence, it was a very close relationship with our product people at Pingboard. So I think that's the reason why I took on this role is that within WorkLeap, the product leaders are kind of the leaders of the entire function, right? And as the co-founder coming over, it made sense for me to kind of take on that role. But it's still, it is very different, you know, like the lines that you draw in terms of, hey, this is my primary responsibility versus this is something that I'm very involved in, but, you know, I can leave it to somebody else to make the final decisions and and actually be responsible for. That's been kind of the biggest difference for me, like trying to step back a little bit from my engineering leaders and not micromanage them. I was always trying to not micromanage them, but I was very often giving a lot of advice in that area and providing direction, which is appropriate for a CTO.. And so I've been trying to find the right way to continue providing value to them without not overstepping in terms of socially, but more in terms of like setting them on the right path for future growth and for the entire organization, the larger WorkLeap organization to work effectively because there's a reason why you have these different areas of responsibility.

That's great. You know what, a question that I'm always really interested in is how trust is developed, built, maintained, improved upon between product and engineering. Are there any techniques that you feel like you've found to be really successful for you?

Yeah, yeah. At the basic level, it's kind of generic advice, the communication methods that you just have to have to work for your team. They're going to be different for different organizations. Some are very documentation-heavy, some are very meeting-heavy. But whatever it is, there's asynchronous communication and there's synchronous communication, and making sure that you're using them appropriately is, in my mind, the most important thing. I'm pretty even-keeled, but nothing will send me off the deep end more than somebody dropping a bomb in Slack and then kind of like running away, you know, using an async channel and like not saying, and let's talk about this, you know, because it's obviously something that we need to talk about. It's kind of like dropping a bomb or an open-ended question and being like, boom, done. And most people don't do that on purpose. It's, you know, it's just one of the problems with async communication sometimes is like the intent is not always as easy to read. And so, that's where I feel, you know, if you want something that's sort of the right blend of generic and high-level and still actionable, you know, think about how you're using async and sync communications and make sure that it's working for you.

That's really good. When you zoom out and when you think about building SaaS companies generally and more specifically WorkLeap, are there any market inflections or just big changes in B2B software that you're particularly interested in or that feel particularly top of mind?

Yeah, I mean, it's kind of an ongoing evolution with SaaS. And I mean, I'll be honest, I don't know for sure where it's going to go, but like SaaS has been so successful. Successful and so, you know, good for both, you know, owners of SaaS companies and customers, you know, on demand for customers. And there's so much, it's still very difficult, but it's so much easier to build value with like a subscription-based business than it is with, you know, like packaged software back in the day or any kind of one-time Salesforce, you know, Salesforce, it's just, you see the entire giant ecosystem that's grown up around it. And, you know, for a while now we've seen the weight of its success, I think sometimes causing problems. I mean, now there's SaaS tools to help you manage your SaaS tools because everybody has too many and it's a legitimate problem. And, you know, I think even that's even kind of informed our strategy with WorkLeap. You know, I guess I didn't really make this clear before, but you don't buy WorkLeap, right? The vision is you're going to buy Pingboard. And if you have a need for some of those other pieces, if you have a need for Ops5, it works even better together, but we're not trying to force people into this, like, hey, buy this one giant thing that does everything for you.

Right?

Which some SaaS products are, you know, or you could go the other way and cause a different set of problems. If you're just a giant list of à la carte features, you know, that puts a lot of, you know, cognitive load and difficulty on a customer to figure out what they need and, you know, you put it together a package that actually helps them. So, You know, those things could lead to, I think, an inflection point in the market just because it's so common. It's so common to see those same problems of like either the pricing packaging to the point of maybe, you know, what you guys are seeing, like being difficult for the customer or for various reasons, or just the sheer number of tools and the complexity of using them together being a problem that doesn't get effectively solved, right? At some point, like a new model itself might have to come into being to handle that if it's unsolvable.

It's so interesting. I think maybe to kind of take this sort of in kind of Well, if I were to play back a little bit of what I'm hearing you say, it's SaaS is becoming more complex. It's more and more complex to operate a SaaS business and to monetize. And I think what you were describing with WorkLeap was this idea that we're supporting a multi-product offering and we're going to market with a land and expand strategy. Is that a good way to think about WorkLeap? I think what's really interesting, you know, when I think about like the complexity that SaaS companies are having to support, is that it often seems like there are kind of 3 big pillars. It's like, I'm going to try to support multiple go-to-market motions. I'm going to try to support different types of billing models, sometimes seat-based, sometimes usage-based, sometimes one or the other. I'm also going to try to support multiple products, as you're doing at Worklete. That's a lot of complexity. It's a lot of permutations. Do you think that those are the right pillars to kind of like help operators ground themselves as they think about kind of monetization and SaaS? Or do you think that there's something about that framing that's missing or incomplete.

Sorry, could you repeat that one? I think I lost the thread. The pillars.

It seems to me that there are 3 pillars of complexity. One is the need to support multiple selling motions. One is the need to support multiple billing models, if not hybrid billing models. One is the need to support multiple products. Do you think that that is a correct framing of sort of the core pillars of complexity, or do you think it's incomplete and you would describe it differently?

Yeah, that makes sense. That is, you know, at every level. So, we're a multi-product offering, as we talked about. There needs to be some things that are centralized, and then there needs to be some things that are specialized for each individual product. Right. And that leads to this situation where there is a lot of complexity, but managing it, you know, I think on those dimensions, as you described, helps to make it all make sense, right? As opposed to just leaving it in this sort of, well, this works like, you know, Pinboard works like this, OfficeSwag works like this. And they're completely different. There needs to be some level of, okay, here's the things that are specific to a given product and here's the things that are consistent across those different products.

Yeah, makes sense. Something that you and I have talked a lot about is sort of the systems complexity around how a business, how a SaaS company is monetizing. So for example, like it seems to me that WorkLeap is obviously supporting this multi-product offering. There's a land and expand motion. There's probably a free trial. There's probably direct sale. I can't quite tell from the website if there's usage-based billing as well, but maybe there is. Supporting all that complexity comes down to lots of different systems interacting together, um, as well as the application. And so I'm curious if you could kind of talk a little bit about how you guys have built and approached your own infrastructure for monetization and for supporting all that complexity from a go-to-market perspective.

Yeah, and it's a little bit of a journey because like most companies, it's grown up organically, right? When we first started, you know, our first customers, we literally automated an email to ourselves, you know, that's just like, hey, remember to go charge these people, right? We have a break instance. And I was like, hey, that email got more complex, right? It's a, here's how much they owe., right? We didn't have to go look it up each time. We had it in the email. And, you know, that went into like a homegrown simple billing system, right? Where we would manage the accounts and do some of the charging automatically into, you know, we would go out and purchase a solution. For subscription billing management, right? But each of those things, to your point, was driven by the application. So, you know, the application is always kind of like the entry point for the customer. That's where they say, I want to purchase a subscription or I want to change my subscription. You know, we didn't we didn't want to send them somewhere else to put in their billing information. Some companies do that. So if they put in payment information, we had to make sure that it was delivered securely and correctly to the billing provider. So all these interactions came through the application. One level up from that, I don't know if you want to go as much in this direction, but, you know, our sales teams, our go-to-market teams, they're using HubSpot, right? Like, to manage all of their work. And that has information in it, which is really relevant. So you've got HubSpot information and you've got a team working there. You've got the application with the customer. You've got a billing system, which is used by support teams. And although it didn't directly lead to this, there's also internal, you know, that old billing system didn't become this, but we also have like internal tools that help people manage it, you know, across those things, right? So you can see some information from these different tools that's relevant for you know, a support type use case. And, you know, if you can even break those down, you end up in a situation where there's even more complexity. So there's a subscription billing management tool and it has a different payment processor, right? That's a different company doing that. So what we tried to do to kind of manage all of this organically is is try to create the clearest possible path for how data should flow. So rather than have like HubSpot talking to Zora, which was the billing system in the application, like try to have that be like, okay, there's something in HubSpot that we need, it flows through, you know, to Zora. It doesn't go to Zora and the app, right? So trying to identify those places where we can have a clear flow of information. And we're not always successful in that, but when we were, it definitely simplifies things. So drawing, you know, clear lines of what the responsibility of each piece of that system is and how data flows in and out of it. Helps people to understand and also helps you to build things that are going to be a little bit more robust and consistent.

Yeah, I think you've painted a really good picture of why this is so complex. I mean, and you also used the word homegrown. I think most of my conversations with people, they're always describing kind of like a homegrown system that sort of starts out with like maybe a feature flag system, then hard-coded entitlements, then admin consoles, and then of course, the integrations with the business systems you've described, often a billing system, a CRM, maybe a CPQ product, maybe eventually an ERP. This is, this is a ton of complexity to go kind of both build and maintain these systems. And what often occurs is pricing and packaging gets really tightly coupled in the code. And I'm curious if that feels like a correct sort of observation in your experience and sort of what the ramifications are.

Yeah, completely. I mean, the application is the place where you end up managing that in my experience first, just because it's the thing that has to consume those entitlements, right? And do the correct thing with them. So it's natural that it kind of gets built on top of that. It's also the place, like I said, where we're collecting that subscription information. So it has that, you have this place where both of those live. At least in our case, it was just like, okay, well, these are really the same thing. So if you were to dig into our code, you would find a lot of pricing and packaging are in the same place in the code, essentially. And, you know, that works, but, you know, one thing that you will find as you make contact with reality is your well-defined plans don't work for everybody. And to close a deal, to get that customer, you've got to make an exception. And then sometimes the easiest place to make that exception is maybe in your billing service. And so the application doesn't know about it. The application that's very tied into pricing and packaging has no idea that this customer is paying slightly less or has access to a special feature unless you go and like customize your code. Right. And so to make that work, that's what you do. And it quickly becomes a mess, which, which has no easy way out of it other than, you know, so many people will just be like, well, let's just re-architect it from scratch based on what we know now.

It feels like an enormous tax on businesses, like that engineering is having to go support these types of refactorings and like support, like it almost feels like engineering is always having to try to reinvent the wheel on monetization and the business gets stuck.

Yeah. And the second time you do it, or even sometimes the first, you're trying to, you know this and you're trying to build something that's going to work no matter what they come up with. And you always fail. Like, I mean, to our engineering team's credit, like we have, we were like, well, they're going to want to do like per user pricing. At some point they want to do like tiered pricing. They're going to want to do these things. So let's build something that we think will work for all all that. And some of that did work for all of that, but a whole bunch of other stuff didn't, you know. And so you can't predict it. You have to be able to adjust to what's happening in the marketplace. And it does come back a lot onto engineering, basically having to do that instead of building actual value for the customer, right? Like, yeah, there's certainly value in a customer having right-sized pricing and packaging for them, but it's not the core value that they're paying you for, right?

You know, another thing that comes to mind for me is this idea of misconceptions. And like, sometimes when you talk to people and sort of like, let's say more predominantly kind of go-to-market, you'll hear sort of, well, pricing and packaging changes should happen every year or every 18 months or some sort of increment. But it feels like what that misses is that the reality is that when an account is sold on a basic plan and then a limit is reached and then a rep increases a limit and then a rep renews a customer and then a customer activates an add-on, these are daily jobs that are happening on this, on kind of these packaging systems, these pricing systems that we build, that always pull engineers back into the fold to support modernization. Um, and it's to— you've lived that. I mean, like, do you agree, or do you feel like that's overstated, that that ends up being a huge tax on engineering productivity?

Yeah, I mean, it's, it's either, um, there's, there's It's either got to be the engineering team or somebody else, right? There's also, there could be a huge amount of manual processes that you build and execute on. And I think everybody, there's like a balance between that, right? We certainly saw that where some things were just like, well, we don't want to invest the engineering time in this. Can you do this defined process? Monthly, you know, and you can, but then you open yourself up to like, it's more fallible, right? And, you know, the people that, you know, certainly engineers are highly valuable, but so are your support people. So are your, you know, salespeople and your customer success people, like their time is really valuable. And none of that stuff is what they should be doing. It should be done in an automated way, right? It should be done by the computers, the type of task that, you know, they— that computers are good at, right? So, um, yeah, it's, it's, it's, it's, it's a mess either way. And the, and the thing that kind of compounds it is it doesn't even matter how big you are, it's always going to feel like it's a giant tasks. So if you're small, you just don't have the people to keep up with the small number of customers you have. And you're like, oh, we'll get bigger and we'll have a team dedicated to it. That team is going to be slammed from day one, right? There's never a time where you're just like, well, we have people who could work on the billing system just sitting around doing nothing.

What do you think are the biggest mistakes that you've made building pricing and packaging and monetization infrastructure? At Pingboard for 10 years and can other operators learn from those mistakes?

Yeah, expecting— the one that comes to mind right off is expecting too much from your billing system or too much from— actually, you could expand that to any given piece. I mentioned earlier, kind of like trying to figure out what areas of responsibilities there are for each of these different tools in the stack that you're using. And I think that's where that thought came from, is if you're gonna be like, hey, we're not gonna re-architect this thing this time, we're gonna buy this tool and it's gonna solve all our problems, it's not, it's not. It's too many, you know, there's too many things that are customized to your business. You need to take responsibility for owning those, right? Making sure that the tool you buy does the job it's supposed to do and you're not putting something on it that it's not supposed to do. Looking at how they all fit together, you know, looking at them individually, hey, these things might be great, but if you don't know how you're going to tie them together, or if the answer is, well, I guess we'll write custom code to tie these things together, like it might work, but you're taking on a lot of risk if you don't have a plan for that before you jump.

One more question just for the benefit of operators listening to this. What are the components of modern monetization infrastructure that people should think about? You know, for example, like product catalog or billing? Like, what are the core components that people can kind of start thinking about when they're in the beginning days of trying to think about how they're going to build this or kind of outsource some of this?

Yeah, that's a good question. So we've talked a lot about these things, but just listing them out, you know, there's certainly your application itself. It's a key piece of whatever you're doing. And then there's this area of, okay, how are we going to go to market with it? How does that affect the application in terms of entitlements, in terms of like, okay, how does the application get broken apart and have the ability for people to use, to consume different parts of it depending on different plans. And then there's, you know, the product catalog. And I think those are slightly different because your product catalog could be— there could be overlap between different features. You could be offering different packages. You know, we're speaking in the abstract. So it could be any business, right? Not necessarily one exactly like mine, but you need a way to be able to say, okay, this grouping of entitlements, this package is something that we want to offer with these sort of terms, not so much legal terms, but like, you know, this is how the billing works. Is it metered? Is it per user? That kind of thing. And what are the ways that you charge for it? And then you need to think about the support aspect of it, right? So how are you going to support your customers, whether it's self-serve support or how is your team going to be able to support them? Having the right data for customers when they have questions or just want information about what's going on makes a big difference. The one of the, you asked before about mistakes, sorry to go back to that question, but one of the bigger mistakes I think we made is when we did have to do like custom pricing or something unusual, we just basically were just like, okay, well, we don't know how to tell the user about this. We're just going to put a thing that says call us if you have questions. Like that's not a great experience for people. Right. And so don't, don't, don't do that if you can at all. Avoid it. But that's just why I think it's so important that you think about how you're going to support these things and how you're going to make sure customers aren't confused. Everybody wants clear, accurate information about pricing, packaging, all that stuff.

Yeah, it's like, how are you going to handle subscriptions? How are you going to handle metering? How are you going to handle entitlements? How are you going to handle the product catalog? How is that all going to interact between the application and the CRM and the ERP and the billing system, like cancellations, updates, yeah, changes to your plan, all those.

What are their options, right? Like they want to know how to, you know, how to change their plan, how to get access to something new, how to downgrade or cancel, you know, sometimes, you know, making all that easy is a benefit.

And maybe kind of all the while trying to do all of this work and support all this work for the customer, like to deliver a better customer experience, a more transparent customer experience. I think that's often lost too when we try to like end up supporting all this complexity is we forget we're trying to give the customer a way to buy the way they want to buy, be billed the way they want to be billed, and buy the products or the features that they want to buy.

Yeah. I mean, if you're only building for yourself, you're very likely to wind up hurting your customer experience.

Rob, you've lived and breathed all of this stuff for a long time. So thank you for sharing the experiences. It's so good to be here with you. Where can people learn more about you and learn more about WorkLeap?

Yeah, so workleap.com, easy to find. I'm on LinkedIn, also easy to find. I'm not always on there, but if you drop me a message, I'll get it. So yeah.

Great.