Monetizing SaaS: Episode 3 with Rob Truesdell, CPO of Pangea Cloud

Rob, so good to be here with you. It's been so fun getting to know you over the last few months. You've worked in some incredible companies— Netronome, Phantom Cyber, Splunk, and now Pangea. You're a product leader, you're a founder, you're a startup advisor. Can you tell people about your journey and the steps along the way?

Yeah, yeah, for sure. Um, I, uh, I started definitely with like more of a hardcore technical background. Um, I grew up around computers writing code. Fell in love with computer networking. Super fascinated about just back in the day, being able to get like two devices to talk to each other. I thought that was one of the coolest things in the world. And then I was lucky enough to get hooked in with a group through an internship and my first job that were oriented around network security. So secure routing, firewalls, VPNs, things like that, network protection. It was, it was Yeah, I was just grateful to be like kind of brought into that group and introduced to the security. And then, and then that kind of transitioned into moving over to more of like the building product side of tech to where instead of being a practitioner or deployer of the technology, it was, okay, how do we start actually building these type of products? And what's been cool about at least my journey is that it started with almost like hardware and like hardware appliances. And then of course, software layered on top of that. And then it's, I've kind of gotten to live through the transition all the way to SaaS products, right? And everything in between, including like pure software, but software that's deployable on-prem and managed by the customer. And then of course, you know, that, you know, bringing us to where we are now with SaaS platforms. But yeah, I've been lucky to work on a ton of different security use cases throughout the way in a lot of different ways for users to consume those as well. So it's been pretty awesome.

So cool. When you zoom out and when you think about building software companies, but also security companies, what are the big market inflections or the big changes that you're particularly interested in?

Yeah, so, well, I talked about the software consumption model that we've all lived through, right? Where like, even if you think back to like there was a point in time where it was ridiculous to even think about paying for software, right? Because it wasn't like a tangible thing you put in your hand all the way to then, you know, perpetual licenses to now renewable licensing models. And I think like what, what's interesting about that are like that, that transition, I think you being able to deliver product in that type of way, was a value prop in and of itself, but the whole world's SaaS now. Like everybody is building SaaS. So it's about now how quickly can you deliver value that packs a huge punch, right, with your SaaS platform? Because I think the SaaS space is, I hate saying the word noisy, but I mean, everybody's building it. So it's like you, and the attention span is small. So it's, you have to have like a really, really, really tight, really tight use case that again packs a huge punch that somebody can try and get the value out of like immediately. So I know with security, a lot of it is about obviously like trying to make your infra or your application or whatever it happens to be more secure. But I think there's also a time element to that as well on like how quickly can you activate it. At Pangea, we're focusing a lot on developers. I know not all security companies are doing that. More and more are though. And so it's, you know, for us, it's like, how do we shave down the amount of time it takes a developer to have a more secure outcome for their application? So I think time is like a huge element of it, of just reducing time to value across the board. Again, for us, like we're focusing on developers, but that's a major, I think a major piece of it.

I feel like that's a huge shift. And like, you know, maybe one way I think about that is like at the same, and this is kind of maybe kind of particularly interesting for being a security company, but security software company, but it's like at the same time that you need to lift the security confidence of the customer, you need to reduce the time to value through some type of product-led experience where the aha moment comes faster. And that is coming from a customer that's way more empowered than they were, you know, 3, 4, 5, 6 years ago.

Yeah, yeah, no, I completely agree. Yeah, that aha moment. And I mean, if you look at any of the, well, this type of material or podcast material or textbooks around like building these type of products and companies, it is, it's how do you hit that aha moment? Like as quickly as possible. And yeah, there's, there's techniques to do that for consumer-facing products. But then on the developer or highly technical side, it gets difficult because these are difficult technical problems at times. And that's, you know, it's like part art, part science and a lot of customer research and discussions to like figure out how do you get to that, that aha moment as quickly as possible.

Do you think that, I mean, to the, to the point on consumer, do you think that what's happening is like B2B software, enterprise software is sort of being consumerized in the way it's purchased?

Being consumerized in the way it's purchased. Not, I mean, I'm seeing that, here's what we're observing at Pangea, or that I think that when you're trying and getting familiar, it is, but when you end up, when you start buying at serious levels for like enterprise level consumption, you end up going down classic enterprise buying paths where there are contracts and things like that. But I think that kind of the dipping your toe in the water and trying something out and playing with it a little bit follows consumer-style buying until it becomes something very serious that you want to put into production or run at scale or something like that. Then it moves down, I think, more of a classic enterprise buying path.

And the implication then is that as the builder of the SaaS, you've got to support multiple go-to-market motions, which adds complexity to everything you're doing.

Yeah, it definitely does. Yes, 100%.

What was the insight that led you guys to founding Pangea?

So what was interesting is that Phantom Cyber solved an incredible problem for security operations at exactly the right market time. And that product was a security automation orchestration platform And what it did was it integrated with all of the different tooling inside of a security operations center. So when we were building that out and we said, wow, what are all the connectors that we have to build to all of these different tools? There were over 300 different connectors, or we called them apps at the time, but over 300 different vendors, products, different types of APIs that had different authentication methods and things like that. That we had to integrate with. And we're like, wow, this is, I mean, it's just, there's a lot there. Right. And then at the same time, a lot of things around cloud security posture management were coming up and understanding cloud security and then application security. And so like all of those things were just kind of stirring around. And our founders, Oliver Saurabh, or sorry, Oliver Friedrichs and Saurabh Satish, and I was talking with them at the time as well, they were just like, how do we simplify how developers can access this type of technology and not have to go down traditional enterprise buying paths to get access to security tooling? And that comes back to a little bit of the questioning I think you had before on how to transact or how to get the product into users' hands and buy. Developers are used to being able to get something very quickly, try it, kick the tires, and if they want to integrate it, that's great. They use it. And if not, they move on to the next thing. Well, that type of usage model, security has not been set up for that. And that's really like the core vision and the core vision and objective of Pangea where we could say, let's get all of these security capabilities and make them available to developers in a way that developers want to consume it and try it. And that's, so it's taking a lot of the things that, if you think about developers and PLG, companies like Twilio and Stripe are like the darlings of that. Like they've done a great job at it and we want to do the same thing for security. And that was a major gap that we saw, which, which led to the founding of, of Pangea.

It's such a great story. It reminds me of just like how many great businesses are built on simply removing friction for a customer.

That's right, that's right.

Yeah.

And shortening— back to that, like shortening the time to getting value, um, make— making it, making it easy for a developer to utilize these things, um, shortening the amount of code they have to write. Uh, yeah, it's, it's, it's trying to kind of just make, make security as frictionless as possible for developers.

I want to get your thoughts on how you've learned how to build alignment across an organization to deliver value to the customer. And so maybe could you, could you talk about techniques that you have found to be really effective that you like to deploy to build trust and alignment between specifically product and engineering? And then maybe I'd love to hear if there's any differences between those techniques when you're trying to build trust between product and go-to-market.

Yeah. Yeah, good question. So I try to keep it simple with myself, my team, and the engineering team. And to me, it's really overcommunicating. And that sounds so like obvious or cliché or whatever, but I mean, really, that's what I think it is. Like usually when things break down, it's due to some sort of communication breakdown, not necessarily like a technical fault or anything like that. So communication can come in the forms of, you know, obviously writing like really good epics and requirements, things like that. Making yourself available to meet and just talk through things. Like we do that as much as we can. And especially for a startup, when you're trying to move very fast and pivot quickly, sometimes development can outpace the rate at which you can write the requirement, which is a pretty cool thing, but it just requires a lot of communication. So I think, like we try to make a really solid effort in overcommunicating and just being in sync like a good team would be. And then when you think about product engineering and then product go-to-market and even like the, I guess that triad, to me, I always think of like, I want to be able to draw a straight line through all of those. So like when we think about a product strategy or a product capability, let's not add levels of abstraction or translation throughout it. Let's keep it as simple and straight line as possible. And even operate off of like things that we wrote in epics and utilize that for go-to-market material. Like to me, that's like, that's gold. You're right. When you have everybody literally operating off the same sheet of music or epic or whatever it happens to be. And that's again, a form of communication, but I was like saying, it's like, I want to be able to draw a straight line through all of those things, you know, from the customer, the customer needs, the product requirements, engineering execution and design, all the way through to what are we saying in a blog? And those things should have like a really nice mapping through all of them without indirection, abstraction, or translation.

I love the single thread. I love the single sheet of music. That's such a good analogy. How do you bring the customer's voice into that sheet of music? Literally, like specifically, how do you kind of weave the customer in?

Uh, it's not, again, trying to keep it simple. I wish I had like a, an amazing, you know, response to that, but it's like just talking to them again, like communicating what, uh, get meetings, uh, uh, have meetings with them, even bring like engineers in on those meetings and, and, and so that we are all in sync with the, with what's being said. Challenging things are good as well, right? So when like a customer wants something, obviously we want to note that and build to it, but there might be other ways we can build to it as well and satisfy that need as well as other things. So not just like just taking exactly what a customer says and saying, okay, we're just going to blindly go do that, but like, let's talk to other customers. Let's figure out, are there alternate ways to solve this problem? And then feed that back to them, of course. But yeah, I like trying to get as many people as we can involved in those conversations, or at least in the artifacts that are generated from them so that everyone's on the same page. But to your original question, I think just picking up the phone and calling, right? And trying to talk to as many people as you can and just keeping it simple.

Makes a lot of sense. Yeah. I'm curious to see if you agree with this idea. One thing that feels apparent to me is that B2B software companies are having to support a lot of different complexity at this point to grow. And I've tried to understand what that complexity really means. And I've started to kind of say to myself, there are kind of three pillars. There's this idea that you have to support multiple go-to-market motions to your earlier point, product-led, sales-led, maybe channel-led. The second pillar would be you've got to support Um, maybe hybrid billing or a customer that prefers usage-based or consumption-based billing. And the third, um, selling multiple products. I mean, inevitably you're going to launch more products as you scale. Do you think that those are— is that right? Is that the correct synthesis of the core complexity that businesses, B2B SaaS businesses have to support? Or is it missing something?

Um, I think that, um, I think those are the core things that you have to hit. I mean, those are certainly what we're encountering as well at Pangea. And it's multiplied by a lot. We have, I think, like 19 different services or products. Don't quote me on the exact number, but it's around that. So when you factor in, you have freemium, you have pay-as-you-go type billing and like utility-style usage and billing. And then you have like a subscription base and then you have enterprise motions. And yeah, so like to your point, all of those things, it could get, it can get pretty interesting. And then you multiply that by the, again, the number of products that you have. And it's a lot. It's definitely a lot. And I would just say one, one other thing out of that are maybe it's, maybe it's implied in the categories that you mentioned, but things like revenue recognition, CFO reporting, I've had to spend a lot of time on that surprisingly. Like I didn't expect to, but had to spend a lot of time on that as we were building all of our pricing and packaging and billing and metering out at Pangea. So yeah, I think that you hit the core components. Those need to be, definitely need to be considered when you're building this out. And the sooner you can do it, the better. We're lucky at Pangea. We took those things really seriously early and built them early, almost thinking of it as, even though it's not a value prop of the product, it's something that's a value prop of the company. Meaning like we can operate very efficiently and then extract great insights from building the right system that supports all of those components that you, that you mentioned. So whether you're building or buying those, like for other people who are listening, I think definitely taking those into account as early as you can. Is important because it's just like any other problem. The more it sits there and grows and the more customers you get, it's going to be harder to solve later.

Well, it sounds like, I mean, one thing I think that is unique about you guys is you've seen this game before. And so you built a system or an infrastructure for monetization that would let you scale and let you be flexible given all that complexity. Can you talk about the components that were core to the infrastructure that you guys built? I'd love to hear you kind of like explain it in a way that could be really useful to other product leaders, other engineering leaders that are thinking about this stuff.

Yeah, yeah, I would love to. And it was a fun project. We started Pangea when we were building the technology and building the concept. We knew that we wanted to go again, bottoms up PLG with a developer-led motion. And know that there are going to be some percentage of those power users that end up graduating onto an enterprise-style contract. And that's like the, again, the classic, I think, playbook that a lot of PLG companies want to realize. So we thought about that journey the whole time and built it from the ground up. Now, I went out to a few different product and marketing communities, uh, just like probably a lot of the common communities that some of your listeners are, are on, on like Slack channels and, and, uh, Discord channels, things like that. And I just started asking around like, how, how are other people doing this? Like, what's a good reference data architecture? And just kind of started piecing it together from interviewing other people out there who have done it, um, trying to read and research. And then of course, talking to our own engineering team. We found a great reference architecture, but what we actually ended up building was we said we have a microservices architecture in our product. Customers consume microservices and they interact with those services via APIs. We built our own metering system that is looking at all the APIs as they're being executed. There's no PII or anything like that, by the way, for anybody who's listening, but we We keep track of things like, you know, tenant identifiers, identification numbers, and then their APIs that they're using, the frequency at which they're using. And all that gets stored to a Postgres database. And then what we can do are run, build dashboards and build analytics, things like that using PostgreSQL queries against it. And then on the billing side, we utilize Stripe. So we said, look, we don't want to handle any of that ourselves. We just want to utilize Stripe for the billing. We can synchronize the billing data into that same Postgres database so that we can do things like, as API calls are being hit, we can look at real-time balances and ensure that there's sufficient balance to actually permit that API call. And that's one of the other interesting things about what we built, where that our API gateway is closely or tightly integrated with the actual metering service that we've built. So that like there are checks, is there, are there balance available before an API is permitted to be executed? So we store that information in a Postgres database. It's tightly integrated with our API gateway. We built the product, the actual, you know, the way to manage billing, at least from a bottoms-up perspective, you can put in a credit card and put in credits as you see fit and then even do auto-rebill., and then all of that's managed by the billing and metering service as well. So if a customer's balance reaches, exceeds a certain threshold and they have auto bill enabled, it hits Stripe, pulls it in, the credit balance increases, and then the API gateway can continue allowing APIs to be executed. So yeah, Postgres was a pretty central part of that. And then, And then we take that information and we share it with our CRM, right? So we utilize HubSpot for that. Hopefully I'm allowed to name drop some of the tech here. Not to get—

Yeah, I'd like you to. Yeah. Yeah, go ahead.

Yeah, I was going to say, I'm not trying to give preferential treatment to anyone. It was just we wanted to build something that would, I think like a lot of people think, we want to minimize the number of software components we had to put into it. We wanted to take this information and be able to synchronize it not only with sales activity, but then also marketing automation. So that, you know, the idea is when particular behaviors are happening in the platform, we want to be able to run automated follow-up playbooks on those things. You know, whether it be a, a balance being low or a user entering your product, doing a ton of things in it and then disappearing for a month. Like, or disappearing for a month, coming back for, you know, a couple days and then disappearing again. Like those type of behaviors, we want to make sure we can understand and trigger off of them. So yeah, the integration with the database, all of the API usage data, the metering data is absolutely critical to us. And then when I was mentioning before, like those things in and of themselves are not value props like to an end user or developer, but they're valuable to the company and the way that we operate. And I feel like it gives us an ability to operate a little bit more intelligently about, you know, what's working in the product, what's not working in the product. And, and be able to help users more as well, like identify where they're stumbling. That's, that's for me selfishly on the product side. That, that's, that's what I had tried to help architects for was, I mean, of course the flexibility on the billing, metering, packaging, everything like that, but then also the, the utilization of your product, like how, how is this being used? And what's cool are that if you do those things, you, if you build it the right way, you can serve both of those purposes where like the product team and the engineering team get the usage insights out of the product. And simultaneously you can do billing and metering the right way. And then the last bit of it are, and probably the most important, are price list management. So all of the, we basically built out price lists for each of the individual services that we have, and those get stored in a table as well. And then what's great are that when you, we've built it the right way where we can manage those price lists for enterprise-style customers who have high-end contracts, we can change the price list specifically for that tenant. Whereas the rest of the fleet is running off of like the standard pricing that's available on the website and everything like that. So, and then we want to start doing things like custom discounting. It's a matter of updating that tenant-specific price list. So there's some pretty cool things that we had done through that that are, yeah, just really useful both on the product and the go-to-market side.

Yeah, I mean, it's super interesting. And I think like what I kind of hear you saying is what we built enabled flexibility for kind of all this complexity we need to support, but it also enabled control. Like it sounds like you have the ability to control how you're packaging offerings, how you might be changing the way you're packaging offerings, how the customer experience might need to shift.

Yeah.

You know, for, to your example, on an enterprise customer who may want something very customer specific.

That's right. And I would just add one more thing on that is performance. So like for us, like being that I mentioned this being integrated with an API gateway, credit availability, doing those checks and then permitting an API call to be executed like that. The time to execute that is, is, you know, the customer tolerance for high latency is very low, right? Depending on how you're looking at that. So yeah, performance was a big part of that too.

Super cool. You know, if, if you feel comfortable, can you talk about how expensive it was, either in like developer man hours or your own time to build this? Because this is like real infrastructure with a ton of complexity.

Yeah, it's— it was an effort. Like, there's, there's definitely no doubt about it. It's a, it's a, it's a big endeavor. Fortunately, we have, we, we have some phenomenal engineers. I'm not just saying it to say it like we have a world-class engineering team. Who's done this before, they know how these things work, they're subject matter experts. So we were able to do it with a few development resources, but it consumed all of their time for a good bit. And I don't know exactly how many developer years it took, but it was a chunk of time. So 2 people on it for a 6 to 12 month period, 100% focused on it, something like that. And there's ongoing work, it never goes away. Like there were always things that we're working on with it. So for people who are thinking about those things, and really it comes down to like the build versus buy. I mentioned some of the requirements and things that we made our decisions on, but I think people should definitely be aware that to do it right, it takes a real concerted effort. Like your engineering team will have to focus on it, some subset of them. So it doesn't come for free. Definitely was a major, major effort and it never goes away. There's always things that we're working on.

Yeah. Yeah. Rob, this has been so much fun. Thank you for sharing all these insights. Where can people learn more about you? Where can they learn more about Pangea?

Yeah. Yeah. Thanks for asking. So first, Pangea. Pangea.cloud is our website. Again, we build composable security components. For developers, making it just easy for developers to build security features into their application. It's everything self-serve, PLG, they can go play with it, pangea.cloud. There's freemium model so that they get credits every month and they can play with the services. And of course, if they need more, they can reach out to me, rob@pangea.cloud. I'll hook you up with some more credits as well. Or you could pop in a credit card. As far as Yeah, getting in touch with me, I mentioned my email already, rob@pangea.cloud. If any of the listeners want to reach out and try to learn more about what it was that we were doing, LinkedIn as well. So it's just Robert Truesdell. If you do a search on LinkedIn, you'll find me. So I think those are the two best ways to get in touch.

Awesome. Well, thank you again. This has been great.

Yeah. Yeah. Happy to share. Awesome, Fynn. Thanks.