Monetizing SaaS: Episode 16 with Brian Rinaldi of LocalStack

Ryan, thank you so much for being here. I've had the pleasure of getting to know you over the last 4 or 5 months or so. You have been an engineer, you've been a developer advocate for a host of great companies from Adobe to LaunchDarkly. You're also a founder of various developer communities. Can you tell us about your journey? What are the steps along the way and how did we get to now?

Yeah, so I mean, thank you. Thanks for having me, Fynn. So I've been a developer, so, I, you know, it's when you reach a certain point in your career where you start losing track. It's somewhere like, I'd now just say 25+ years. You know, I got my start back in like the dot-com boom days, you know, so like it was really easy to kind of get into development. But I've always, you know, I didn't have a computer science background. I kind of self-taught really. And my background was more in like writing and communicating. Stuff like that. So when I got into being a developer, I started doing things like, oh, I'm writing articles for these journals, and I'm running conferences, and running meetups, and all kinds of things like that. And then so suddenly, it kind of led me into being a developer advocate. It was almost like I was already doing the job, but it was all kind of outside of work, and the stuff I really enjoyed doing. And then I transitioned to doing that first at Adobe and done it for numerous companies since. So yeah, I love doing this because it gives me a chance to both have an opportunity to learn continuously because that's part of the job, but also the opportunity to teach. And that's even— I love to learn, so that's why I start those developer communities. It's like, oh, I want to see these people speak, and I want to hear what they have to say. So like I start them somewhat selfishly, it's like I want to hear this stuff, but I know other people do too. So that's where it leads me to kind of do things like the CFE.dev site that I run, things like that.

What's changed about developer advocacy over the last, let's say, 10 years or even 20? I mean, how has developer advocacy changed based on what you've seen?

Yeah, I mean, God, so much. Back when I got kind of started in it, you even would often hear it called like evangelism and stuff like that, but we kind of dropped that term. I think it's gotten like— back then it was really just about kind of going out and speaking, and you wanted people with big names that could draw big crowds. And it was like, I'd say, um, it really was the evangelism kind of thing. Like, it wasn't so much as focused on teaching and on like, um, kind of those, those core like enabling developers and things like that. It was more about getting the word out. And it's still part of that, right? But I think that the role has changed a lot. And even now, I often see startups who like their first non-engineering hire is a developer advocate. They're like, okay, it's marketing, it's everything, right? Like, and it kind of is, though, that those can be challenging roles, I'll admit. But I think it's just, it's encompassed a lot more. So there's even multiple roles now in developer advocacy, where it's like, before it was really just this one role. Now there's people who focus on writing, people focus on community, people who are those kind of road warriors going from conference to conference and speaking. So it's really changed a lot. And before it was like only a senior engineer could really transition to it. And now you see like, whole wide range of, of roles that fit different experience levels. And I think that's brought a lot of like new kind of different approaches to how we talk about things, you know, being able to kind of give that, you know, oftentimes that kind of junior developer perspective to like really help people get started with the product or people who are kind of new to programming and get comfortable with it.

You know, it really is interesting to kind of think about how it's evolved. I love what you said. I'm curious if there are any techniques or frameworks that you've picked up that, you know, maybe if you were imagining, you know, a startup or, you know, kind of early growth stage company listening to this, frameworks or techniques that you've picked up that would help them think about their own developer advocacy programs and how to structure those departments, those organizations in ways that can be really effective for them.

Yeah, I mean, I'd say for me, I think when, especially when you're talking about early stage startups, a lot of times it's really, it's kind of getting down to like the core value things that developer advocates do. So content is, in my opinion, it's always key. So like, as an example, I could, as a startup, I could spend a ton of money on travel and conference sponsorship and things like that and actually it's hard to really gauge what the value I get out of it is because those metrics are hard to track. But like content has a long life. It can really do— it's great for building awareness. It's not expensive really. I mean, you have to have somebody writing the content, but it's not like I have to pay for travel and meals and all this other stuff to get that done. So to me, like focusing heavily on content And then on building your community, depending on what you're building, I mean, if you have your developer advocates to engage with the community and really give them the opportunity to get more involved and to amplify that voice, because you're not going to have a big team that a larger company would have, but you can take people who are passionate about your product and with the right team in place, kind of engage them and give them opportunities to become kind of advocates for your product that are, are just not part of like the employed by you, but out there giving authentic like kind of endorsement of what you're building.

A lot of sense. Um, this is just a side anecdote, but I'd be curious to know how you would think about it. I mean, when you say content, do you mostly mean docs and blog articles Or do you mean other types of assets? And the reason I ask is because whenever I interview developers, I feel like I am always talking to a group of operators who have such different preferences around content types. Yeah, I wonder, I wonder if you can riff on that.

Yeah, I mean, I have some opinions on that. Uh, I'm old school. Uh, I'm old, as I guess I as well.

So like, uh, I'm old and I am old school.

Yeah, I tend towards like the, you know, I think written content is, is, I prefer it. That's the way I learn. I do understand like not everybody learns the same way. So I think, you know, you need to kind of have a, a strategy that, that addresses both like written content and video content and things like that. Like whatever other kinds of content, whether it's like short-form social media and things like that. That being said, you know, it's, I think written content tends to have a much longer tail because it's Video content is great, but it's hard to make. It's expensive to update or difficult to update. And so you end up stuck in this cycle where it's like, okay, I put out this video, but especially if you're early stage, hey, our UI changed and we added these features and that's not in this video. We spent a bunch of time and money creating. We need to redo it or how do we fix it? And so Video's tough in that there's challenges with video that I think make it a little bit easier. Like, I tend to just push for written stuff because I can go back and update an article really easy, even get new screenshots, not a big deal. But a video can take a lot more work. But not to say I'd ignore video. Video's still really important. And I mean, I know a lot of younger developers who are relatively new, that's literally the only place they learn. They're like, They don't even go to Google, they go to YouTube and they search. So, you know, you can't not be there, but you have to just choose wisely, you know.

I love it. What about community? Like, so what is the intersection between content and community and what have you learned about actually building real communities?

Yeah, it's, it's— you have to be patient.

That's the key.

You have to be patient because it just really takes like I, I, what I found building communities is that you reach a point where you're like, oh my God, I'm like, I'm clearly speaking into the void and I'm putting lots of effort and it's just not paying off. And then all of a sudden it's like, whoop, oh, it took off, you know. Um, as long as you're doing, doing things right, it will eventually take off. It's just largely a matter of persistence. Um, you know, finding, you know, kind creative ways to engage community. And honestly, I wish I was an expert at it. I'm not like the best at it, um, just partly because it really does— like, uh, if you can afford to have somebody dedicated to like community management, then you should, because it really is a full-time job to— because especially in the beginning, getting people engaged is just a matter of consistency. It's like, I need to post regularly, I need to kind of come up with creative questions to get them to like maybe engage in, in Discord or wherever I'm trying to get them to, to participate. It's, it's, it's— I think there's this misconception that it's all organic, and it's really not. It's just a lot of hard work.

Agreed. Can you talk for a minute about what you're focused on now?

Uh, so, you know, I literally just starting at a company called LocalStack. Um, so I'm gonna— we're basically a drop-in replacement for like AWS to test locally. So you can run like all different kinds of AWS services, but on your local machine without the complexity of trying to push that out to the cloud. So I am like right now deep in number one, getting to know the product as well as I can and really getting the opportunity to be very focused on AWS, which is one of the things I'm excited about. You know, I've kind of done a lot of AWS stuff lately, particularly, you know, with LaunchDarkly, I did a lot of AWS stuff, but now I'm really focused on it. So I'm excited about doing that.

Really cool. And speaking to writing and to AWS, you've written, I think, incredibly important content around entitlements and SaaS with Bill Tarr of AWS.

Yes.

Can you talk about that writing? I mean, the name of the article was— the title of the article was Simple and Flexible SaaS Entitlement Management. Can you talk about why you wrote the post and tell us what entitlements are and why they matter?

Yeah, so I mean, Bill and I had been chatting quite a bit. And one of the things that even he helps SaaS startups who are building on AWS. So he's part of SaaS Factory at AWS. And that's kind of his whole goal is to help SaaS startups. And one of the struggles, like entitlements is always a bit of a struggle. So, you know, speaking specifically to SaaS, I mean, entitlements are like, I have access to X feature because I'm on, why plan, right? Like, that's the gist of it. Pretty simple conceptually, but then how you implement that can be problematic. I mean, so many companies end up dealing with the fact that, hey, you know, I put lots of if statements and other things in my application code to, like, deal with all these different things. And then, oh, hey, we need to adjust those entitlements. I need to actually go change my code. Redeploy and all kinds of things like that, which is just, it's just complicated. So the idea that we were trying to kind of propose is that feature flags, and then whether they're on LaunchDarkly or elsewhere, like feature flags are kind of a really easy way to almost to build that out to be able to kind of gate what features are available to whom, because you can use targeting to say, hey, this feature goes to these people on this plan, but also like not have it hard-coded in your application. It's actually managed in your whatever platform you're using for your feature management. And it also kind of keeps that separation from like, I don't want to have to have necessarily everything regarding like, I may already have an existing like application for managing like billing and who's on what plan and, you know, so on and so forth. And I don't necessarily want to have to have that all in one place, I can actually then tie that in easily with feature flags to where I'm targeting based on that data, but I'm, but it's, it doesn't, it doesn't necessarily, it's not tied to a specific system, right? Like it's just, I'm passing in metadata that's then used for targeting to determine what features you have access to. So it gives you a ton of flexibility and like the other key thing that was there is like any kind— there's two aspects, I think, to any kind of entitlement program that will really make it work for your business is number one, again, by taking it out of the application code, you're now giving that to the business where you can be a lot more flexible and say, hey, you know what, we need to adjust this plan and it's not going to be a huge cost, right? Like, literally somebody could hop into LaunchDarkly or whatever you're using and just make those adjustments of how you target something and suddenly this feature is now in that plan without any redeployments, any changes to the application code and so on. So it gives you that flexibility to really kind of toy with your pricing and packaging, which especially early on is going to be something you need to be able to do kind of quickly to adjust to things you see in the market. You know, so That to me is key. But then the second thing is, is that even then, once you establish, okay, here we have these set of pricing and packaging, but you always are going to have exceptions, right? It's never going to be like a straight everybody is going to be that way, especially when you start selling to enterprises where it's like, okay, we're going to throw in this feature for so-and-so, or we're going to give them access to these beta things we're working on, or things like that. So you need to be able to kind of override baseline packaging and say, hey, this, in this contract we wrote in that this feature, even though they're only on like our business plan, not on enterprise, we're throwing in this enterprise feature because that was part of the deal that we negotiated with them. Right. So you have to have flexibility. You can't, it can't, none of it can be very rigid. So feature flags allow you to do that. You can say, hey, here's my targeting for that. That says if you're on plan A, you get X, you know, this list of features, but I can also override that with like individualized targeting, say also if you're coming from this company, you know, you get access to this enterprise feature that wasn't in your plan. Kind of makes sense.

A big takeaway for me when you wrote the piece, and obviously I probably share the belief given what we're building with Schematic, but was the idea that if we extend the idea of feature flags beyond traditional development use cases like deployment and rollout into entitlements. And into pricing and packaging, you can remove a lot of what would be kind of engineering work that has to go into supporting monetization evolution over time, and you can empower the business to be really agile. Why do you think more companies haven't seen that or don't do that? Given many companies are now using third-party feature flagging tools or have built flags themselves, why has there been that disconnect between what a feature flag could be when extended into the entitlement use case?

You know, based on my experience, it's largely, sometimes it's hard to break out of that, what you're used to in a sense. When I talk to a lot of companies, even though they're like, say they're using LaunchDarkly and I can do all kinds of different kinds of feature flags and I can have all kinds of targeting, it's like, there's often a mindset of feature flag is either just on or off for everybody. Like it's true or false. It's just pure Boolean. And so it's hard to think about, number one, you typically think about feature flags as being temporary. In this case, they're not temporary. They're permanent part of your application infrastructure. So you have to change your mindset about how you use them in that way. You end up building feature flags that are not typical like, oh, hey, this feature is released. It's like I have to get into the targeting piece, which I've noticed a lot of companies struggle to get into like using targeting beyond like just, oh, I'm going to target my, you know, this environment or things like that. It's, you know, they tend not to think about it in terms of all the capabilities that that opens up when you are actually using that in your production application. And so I just feel like, yes, companies are moving to— have actually started to adopt feature flags en masse. You talk to most developers, on some level or another, using feature flags. They may not be using a feature management system, which will limit their ability to do this, because most homegrown systems aren't going to be able to do that kind of targeting, number one. But then also, they haven't yet gotten past— I wrote an article ages ago about stages of feature flag adoption, right? And they haven't gotten past stage 2 or something where it's like, I'm just using feature flags for release. I haven't really gotten past thinking like, whoa, what? All of a sudden targeting opens up that these don't have to be temporary, that we can manage. I can give, say, a product manager the ability to create beta groups for beta features and say, you know, work with customers and say, oh, you know, you suddenly get access to these beta features and I'm going to manage it that way. You know, and those kind of things really haven't entered their mind yet. And I think partly also because it's a developer tool and we're talking about entitlements as a business problem. It's not a developer problem, like in the sense of, like, you know, they'll build it whatever they need to build, right? Like they're not thinking about the pricing and packaging and the kind of complexity that comes with being able to like needing to make changes to that or who should be making changes, right? Like it's, so I think that's the other piece of it as well.

It's, I'm just, I'm smiling a little bit because it's uncanny to me how similar what you're saying is to a manifesto that my co-founder and CTO Ben wrote like a year ago where he effectively said, you know, look, there's this disconnect between feature management as a term of industry and the actual feature management that goes on in a business.

Right.

And, you know, he kind of goes on to say like, look, we're all kind of used to the traditional DevOps use cases, but don't we do a lot more managing of features than this? Like every time, you know, you do a custom override on a custom bespoke enterprise deal, isn't that feature management? When a customer success rep enables an add-on, isn't that feature management? And he kind of goes on to posit We have to kind of think about feature management in the context of the business we're operating in. And if we do, it can be a really kind of like the power of feature management and feature flagging can become so much more.

Yeah, absolutely. I would totally agree with that. I'd love to read what he wrote because it sounds like I'd be like nodding in agreement the whole time.

I think you're right. I think it was called his manifesto or feature flags theory versus reality, something like that. How did you, you know, one more question here, just, but how did you identify entitlements as a problem and/or opportunity for companies to know and understand with Bill, you know, as you guys produced that content together?

I'm going to give credit. It was Bill who reached out, who was like, hey, you know, he's, I think, you know, I know, I knew somebody from his team. We'd worked together way back and, you know, he knew I was at LaunchDarkly and he was preparing something for for re:Invent a couple years ago. And so it started with just like, can I help him kind of think through the problem of like how you would manage entitlements with feature flags from a very, very high level? So this, we hadn't even dug into like the article and things like that. This was just a couple slides. Like if you're building SaaS, here's things you might think about, like, and how you might manage entitlements is kind of a, basically every SaaS company is going to think about entitlements at some point or another. So it's something that was on his mind and then he reached out. We just kind of continued the conversation from there. And then once we felt like it really fit nicely, it just seemed like this makes a lot of sense. And so it just was like, okay, let's kind of play it out. Like, how would you really start to put this thing together? The tricky part, of course, is like, entitlements is different at every single company. So like, you know, it was like, you know, we went and we initially presented this at a conference and it was like, okay, we're presenting a method. Like, this is not the solution, right? Because entitlement, your entitlements are going to be different than the entitlements we're talking about. We're just kind of taking a kind of generic use case of like a typical entitlement setup. But it's really interesting when you talk to companies that there's always tons of nuances in how they handle it based on the type of application they're building.

At this point, do you think it's valid to say that feature management is at the root of a lot of modern monetization complexity in B2B SaaS?

Yeah, so I mean, I think it should be. It's, um, I think you, you know, you can you can definitely simplify your entitlement setup and simplify the way you kind of reduce the complexity in general terms, in terms of how you build out entitlements and how you kind of release those, how you adjust them as your business goes along. So, I mean, if you do adopt feature flags for this, I think it's really going to find it's incredibly powerful. And I think to me it's like I can't think of a better solution to it. I mean, honestly, there's— it makes a lot of sense. I mean, feature management is all about gating features, and entitlement's all about, well, how I release certain features. So the two things seem to just fit together perfectly.

So yeah, it's like a really, really clean architecture.

Yeah, exactly.

Brent, thank you so much for doing this. It's been so much fun. Can you One question I always like to ask at the end is, what's the experience or moment, and really the moment, that has had the most important impact on your career or most formative impact on your career?

So I'm going to say it's really interesting because sometimes insights come from the oddest places, right? It's not always like, oh, I had this great experience at this wonderful place and this mentor who taught me these great lessons. And I think the lesson I learned was I was actually at a terrible job that I hated with a terrible boss. And but she said to me one time that, you know, and that basically I came back with a lot of why we can't do something. Instead of coming back with like, I'd say, no, we can't do that because of this and that and whatever. And it wasn't like I didn't have a solution. And so I'd pose all the difficulties without posing the potential solutions. I think changing that frame of mind for me was like, it took a lot of practice because I was so used to kind of, I'm a skeptic by nature. And so it's easy for me to pick apart an idea and figure out all the potential pitfalls. Instead of basically being like, you know, okay, I see these potential problems, but I may hear it like, yes, we could do this. What if we thought about it this way? What if, you know, like just present an alternative or even, you know, just, you know, present solutions potentially. It's like, okay, I see these potential problems, but I think with some thought I might be able to solve them kind of thing. So just being a little more open to finding solutions and presenting them and not being kind of fighting off that natural skeptic nature got me a long way. So I think I'm a much easier person to work with because of it, to be honest. But I shortly, thankfully left that job because despite learning that, it was still a terrible job.

It's a really great story. I think it resonates with a lot of people. I certainly have found myself, when you're kind of like not being solution-oriented enough or not being positive or optimistic enough, you can really like affect the energy levels of teammates. Where can people learn more about you, reach out to you, get involved with some of the communities that you've helped to grow and catalyze and nurture?

Uh, you know, I think the best place to find me is I'm running like I run presentations and all kinds of other shows and conferences, all virtual on cfe.dev. So that's like, I would hope people come join that community. It's like, it's all free. There's like hundreds of videos going back like 7 years of presentation. So, you know, it's all like completely free, something I do for fun and to kind of give back to the community. But you can also find me on my blog is remotesynthesis.com. Um, and, you know, has all my contact information. I'm like on Mastodon, Threads, whatever. Um, you know, you can find me on most social media, not The Bad Place. I mean, I'm technically still there, but you won't— I won't ever check it. So, um, yeah, anyway, thank you again, Brian.

So much fun. Really appreciate it.

Yeah, thanks, Fynn. This was great.