Monetizing SaaS: Episode 12 with Bill Tarr, SaaS Evangelist at AWS

Bill, thank you so much for being here. I've had a great time getting to know you over the last, I would say, half year, maybe year, since we started Schematic. And you've had this just really interesting and textured career in software. You've been a developer, you've been an evangelist, you've been— I think you've been developing for like 20 years, correct me where I'm wrong. You've been an architect, you've led teams, you're currently a solutions architect for AWS. Can you tell us about your journey and the steps along the way?

Yeah, it's, it's a great question, Fynn Glover. I think the way I would contextualize my journey is a series of jumps or steps where I sort of had revelations about what I wanted to do and maybe revelations of what I didn't want to do and what I really wasn't good at. I think over time, as you're a developer, you start to realize either, hey, I'm the best developer on earth and I want to be the best developer on earth, or Hey, I'm really not. This is something I'm pretty good at, but there's other things that I think I might be better at. There's always that sort of journey for me of thinking, okay, I really like what I'm doing, but then there'll be a moment where you have a conversation, you're like, oh, but I like doing it because of this specific thing. And that sort of took me from being a developer into an architect fairly early where I loved doing— I loved developing, I loved building, but then I started to see the ability to affect much greater change. Simply by becoming an architect and leading teams of people. So that was sort of the middle part of my journey. Loved doing that. Ended up staying at one company for almost 8 years, just being an architect and really enjoyed that. And then I took and had another revelation. I started talking to some of my friends who were working for startups in San Diego, and I just was really intrigued by all the things they were talking about— the agility, how fast they were developing, the type of customers they were working with and their interactions with them., and I made the jump, uh, to become a VP over at a startup. And absolutely, it was really only like 3 years of my journey, by the way, that this— my startup career didn't last that long, but it was so influential on everything that I did. I think you can relate to this. You're working with a startup, you're founding a startup right now, and really love your story about how you guys got started and, and where you guys are at. It's so different from working in enterprises. And I swore when I joined my first startup, I would never join another big company. And as everybody probably realizes by now, I work for AWS. Uh, this is one of the biggest companies you can possibly work for, but I never lost that passion for startup. And the ability to join a team like the SaaS Factory and work with startups has really enabled me to, to make that next jump in my career, to go from somebody who likes working in a startup to somebody who wants to start to influence more companies and be in a more consultative role and work with a lot of different companies. And that sort of has morphed into not just the companies, but the community and working with all of the people in the community, you know, like Gwen Shapiro, who has the SaaS developer community and like yourself, who, you know, as a founder of companies out there speaking to people. And this has sort of been the, this has been the last part of my journey is becoming an evangelist. And I give myself that title, by the way, no one's giving me the title of SaaS evangelist. I decided I was a SaaS evangelist. And I'm just going to keep saying it. Eventually, maybe someone will give me the title, but I call myself a SaaS evangelist, even though I'm a principal solutions architect. And I work with maybe up to 100 customers a year in different conversations, some one-off hour conversations all the way up to working with a customer from the beginning of their product all the way until they launch. And really love that, that ability to do that and really am happy where I am at this point in my career. But it has been this series of jumps along the way of figuring out like, oh, I actually want to do this. This is what I want to do. And it's evolved into this and I love where I'm at. So no complaints.

Thank you so much for sharing it. It's really so cool. And so now at AWS, say more. I think you're working in SaaS Factory, but what is SaaS Factory? How should people think about it?

Yeah, it's a great team. It's the team that I joined AWS for a little bit by coincidence because one of my friends from one of the startups in San Diego actually joined AWS and joined the SaaS Factory. I don't think I would've found out about the SaaS Factor if it wasn't for that. But their mission's really cool. And as soon as I heard about it, it resonated with me. This whole team was set up simply to work with AWS partners. We're a partner team. And differentiating partners and customers is a little bit of like industry jargon, but partners are basically customers who are more leaned into what you're doing. Customers who said, hey, yes, we want to partner with you. We want to do more with you, join the programs you're a part of. So we're a partner program who helps customers who are building SaaS to build better SaaS on AWS. It's a complimentary program for partners. So we're, we're not a, like a consulting agency. We don't have to bill for our hours and we're not charging customers. Rather, I think early on the team realized there's a lot of benefit to simply getting customers to build good SaaS on AWS. You know, customers who build on AWS tend to stay on AWS. And there's good reasons to. If we help them to build it right, it will be operational efficient, it'll be cost efficient, and they'll want to stay on AWS. This is where a lot of their customers are. So the recognition that that was real value to AWS and to our partners naturally led to this team, and it grew over time. So we started off, I think Todd Golding started by himself almost 10 years ago in AWS. He had the seed of idea for a team, started pulling people in, and over time the team grew to about 40 or so people. And so our team can work with, you know, probably in a direct manner where we actually work with the customers from the beginning of the project, no more than 100 customers a year across the team. But we're able to touch maybe thousands of customers with the thought leadership that we're publishing, you know, community stuff like this where we get to talk directly to our, to the community, those one-off conversations where we're able to do what we call, you know, specialist requests and we come in and just you have a specific SaaS problem. Hey, how do I use feature flags? How do I calculate cost per tenant? And we come in and talk to those customers about that. And oftentimes it's just an hour, but those are some of the best conversations I've had is you can just drop in for an hour, you know, sort of like a, like a Marine behind the lines and like, all right, this is what you're going to see in the future. Let me map this out for you. And they're able to run with it from there. And sometimes we come back to those customers much later and it's amazing to see how far they've come.

Is it fair or unfair to say that the SaaS Factory is actually kind of moving into a role where it's helping to evangelize sort of an architectural standard for how we develop our software?

It's very fair. You know, we started off with these direct engagements. We started to develop very strong opinions about how we thought SaaS should be built. You know, we use very specific terminologies. You know, people like to say, this is a very trivial example, but people like to say single tenant versus multi-tenant. And very early on, our team realized there's some ambiguity to saying that in the cloud. Really what you're building are silo stacks versus pooled or shared stacks. And so we started using that specific terminology. And now Todd's published a whole book out there about SaaS and how we should speak and how we think of the language. And it's not like everyone has to adopt it, but it provides an interesting framework for us. And we became very opinionated. We started to build community efforts like this one. We've got a great tool called the SaaS Builder Toolkit that we're working on right now. This sort of provides a nice baseline for people who are looking to build SaaS. It's free, open source forever. One of those tools that you can use to simply take a look and see, hey, this is what a control plane might look like on AWS, or we've implemented reference architectures for serverless that show you how to use Lambda-based architecture, EKS for our Kubernetes architectures. So we've got all of these highly opinionated frameworks. We spend a lot of time you know, going to public events and speaking and meeting with people in the community. It connects a lot of the dots. And we're also publishing whole learning frameworks as well, SaaS Builder learning framework for people who are getting started in SaaS as well. So you're right, I think the team started very much like, hey, how do we help individual customers? And it has transformed into how do we help them, but help them at scale? How do we help all of them instead of helping 100 of them a year? And those motions have been pretty successful and well received by the community. So I'm happy we've been able to make that transition.

It's really cool. And I can see why it kind of fits what you ended up really loving and wanting to do. It's this combination of like helping startups, helping growth companies, helping to evangelize software, but more than helping to just evangelize software, like evangelize best practices around architecture, which to go back to kind of what you really fell in love with early on, it makes so much sense. It's so cool. So I want to— this may be kind of very related, but when you think about building software today, are there trends or major inflections that are particularly interesting to you that really kind of, they pull a lot of thinking from you and they pull a lot of curiosity from you?

Yeah, definitely. I think especially, and I'll put this in a more recent lens, uh, you know, with the, the net knowledge that it might be a little bit of recentism bias, right, to say like some of these trends that we're seeing right now are, are most important. But things have changed a lot, uh, you know, during the pandemic we saw a lot of pressure, a lot of rethinking about how we think about the valuation of SaaS, right? VCs started to look and say it's— we always said it was a growth model. You know, the one of the bases that we were talked about SaaS is this is a model for creating growth. And like, great, we want to capture that growth, so let's focus on the top-line growth and eventually profits will come. It didn't always happen, right? We saw really large SaaS companies get bigger and bigger and bigger and never really figure out how they were going to make a profit. And that focus has shifted. And that really happened over the last couple of years where people investing in SaaS companies started to ask very specific questions. How are you going to make money doing this? You know, what's the end game for you as you're building the SaaS product? How do you focus in and say, you know, year, year 4, we're actually going to have a profit because we can see it costs us so much to operate each of our tenants or customers, right? So I think that's one of the big trends that we've seen. And then maybe just even a little bit more recently, we're starting to see a little bit more focus on understanding the costs of operating your product, right? You're starting to see people focus in a little bit and say, hey, you know, some of the bigger SaaS customers out there are still struggling. I mean, I'm sure a lot of people have seen Salesforce's latest earnings report. It's not great. It's been a rough year for a lot of people in the SaaS industry. So there's been a little bit of shift from, well, okay, you have to be profitable to also what are customers asking for in terms of SaaS pricing, in terms of how we package these products up. And even for the best of us in the SaaS marketplace, are we doing it well enough? Do we have to keep innovating on these products? Do we have to shift even more towards consumption-based products? Or is it something else? Do we need, you know, what does that look like? And I think that's the sort of the conundrum we're in right now is exactly where is SaaS pricing going? And as much time as we spend doing this, I think everyone's still evolving the ideas of what SaaS means to be, uh, not just be SaaS, but be successful SaaS. Um, so this is one of the areas that I think I'm most interested and focused on. I probably have a very specific lens on this, but, uh, to be fair, you know, when companies like Salesforce, when these larger customers are doing this, they have a tremendous amount of knowledge of what they do and how to do it. Um, but everyone, the customers are also evolving. It's not just the SaaS companies that are evolving. So it's kind fun to watch this in real time unfolding.

If I were to play some of that back, it, it, it sounds to me that one of the things that you get really interested in is how, how SaaS companies monetize is very influenced by the evolution of the actual SaaS buyer, and there is a lot of flux at that intersection right now.

Yeah, and, and I'm sure you're seeing it too, right? And you guys are developing a product, you're, you're trying to get to product market fit and, and really hit that growth curve and explode And we've seen this over and over again, right? It's very challenging for SaaS customers in any market to find that product-market fit. But with this flux in SaaS buyers and SaaS buyers saying some very specific things like, hey, we love your software, but I don't want to use it in a really a SaaS model. I want you to deploy it into my accounts. What does that mean? How do we respond to that? There's intellectual property concerns about doing that. There's certainly compliance concerns for your customers that you want to deal with. Data privacy is becoming more and more of an issue. And those needs are all happening again. They're happening continually and we're continuing to iterate on what that means. I do. I love the aspects of that because, you know, just to wax for a second about, again, the role and not to make this all about me, but, you know, I've never been bored doing SaaS. I've been at AWS 4 and a half years now, and I've never reached a point where I was like, oh, another conversation about SaaS. Is this the same old thing? Keeps evolving. Uh, you know, it's, it's affecting every single industry and vertical out there. There isn't a vertical where people are like, yeah, no SaaS. You know, when I started off finance and health tech and some of the more traditional industries, yeah, they weren't all that interested. Uh, but we had leaders doing it, and now across the board we're seeing penetration in those markets. At the same time, you know, some of the, the models that we thought were, were, you know, baked and successful, like, you know, having all of your SaaS in your own accounts, now are being challenged by new changes. It's a constantly shifting marketplace, and I do it makes it so attractive to work in that space and to try to be an, quote unquote, expert in it. You know, what you knew yesterday and was the right strategy may be challenged by what's happening today. That makes it really fun to work in.

I totally agree with all of that. I'm curious. So, I mean, we're talking about in some ways how SaaS companies monetize and how they monetize in the context of, let's call it, increasing complexity. Maybe that complexity is driven by the evolution of a buyer or a buyer who is more empowered. But in your experience, maybe can you take us even deeper? Like, what do you think makes monetization so complex for software companies as they grow?

Yeah, and it's a hard question because there's a lot of factors to this. I'll start with maybe, again, when you're a hammer, the whole world looks like a nail. And one of my favorite topics is talking about cost. In SaaS. I think when I talk to SaaS customers, when I talk to SaaS providers out there, one of the biggest challenges I see is an understanding that they need to understand their cost, but a lack of ability to connect the dots to what that actually means. And there's two cross-cutting— there's an intersection of two different points that I want to talk about when I talk about cost. And I usually try to sneak the second one in when I'm talking about the first one, because everyone understands cost per tenant. Needs to be calculated, right? That's almost a given. You know, it's basically COGS, right? This is Business 101 in terms of understanding how a business should run. The cost of your goods sold should be less than what you're selling them for. Everyone kind of gets this already. But the calculation of that in the clouds was elusive to people for a long time, especially as we get into shared software, right? I mean, there are, you know, again, silo SaaS out there where every customer gets their stack. Relatively easy to go and calculate. Well, this customer's AWS account gave me $800 bill. I need to charge them more than $800. Well, that kind of makes sense, right? But then packaging this up and saying, okay, what does a tier look like? How can I create a pricing tier that creates at least an average where I'm on average, I'm making money on the, despite the cost of goods sold for all of these customers, thinking about that packaging and what the underlying costs are. And just to contextualize this, by the way, because sometimes this can get confusing to people, uh, we're not talking about cost plus in SaaS. I don't want people to get into the mindset of it costs me $800, so $800 plus $100 is how much we should pay, charge for our product. That's not the best way, not the optimal way to think about a SaaS product. Uh, I want, you know, how we want people to think is what's the value of your product? That's what you're pricing on. But this cost component still needs to be calculated and we need to zealously manage what those underlying costs are, which brings us to the other part of that intersection, which is cost per feature. This is the one that I never have people coming to me asking about, but I think is perhaps more important than cost per tenant in a lot of ways. Uh, what does it mean to actually build a feature in, in a SaaS product? What's the culture that you have to create to anticipate that cost, to plan for that cost, and decide how we're going to package that new feature into whatever type of packaging we have, whether those are pricing tiers or whether we're adding add-on charge for every feature that we've added onto our product. All of those packaging types require a strong understanding of the cost of the use of that feature. And speaking of changes that we've seen over the last few years, the ubiquity of GenAI is a given now. Nobody's asking, like, is GenAI going to be a thing? Generative AI is here. People are using it. People are finding clever ways to include it into their products. That said, people aren't necessarily starting from the, what does it cost for us to support a GenAI feature? Training your models is expensive. Even the inference side can be expensive. So we have to be thinking through the lens of what's it going to cost if we're adding a new generative AI feature into our application. But I still see people sort of cart ahead of the horse. We need to use GenAI. We're going to build a GenAI feature because we think it's cool, or even if our customers are asking for it. Without asking that next, next question. How do we package up this feature that we're creating? How is it going to become a profitable feature, even if not right now? How do we understand the cost of operating it? And even if it's a loss leader for us, understand that we're not just shooting ourselves in the foot. One of the first conversations we had around GenAI was, uh, with a legal firm that was scanning documents for all of their, their law firm customers. And they were taking a beating because as they started, people started to use it and realize that they liked the feature. They had just baked it in as a cost. Okay, you know, you get this feature, it's, it's in, in the, the premium tier. Great. Well, this law firm has 10 million documents, and hey, look, all of a sudden they're in Japanese, and we're spending all of this money doing these transform transformations into, into text and then scanning them and trying to gain intelligence out of those. And that wasn't baked into their cost model, so they had to actually go back and revisit their cost model, their, their pricing model again, and how they packaged up that software and put some limits on that. So, so in terms of monetizations, those are some of the struggles. I know that's a lot. But there's a lot of struggles that we can have, and they're also very specific to the industry and the types of customers you're selling to, which adds even more types of complexity to SaaS packaging pricing.

And maybe I would add, those are great. I would maybe add there's sort of a business stage dependency there too. And maybe there's sort of a business maturity there in terms of like the context of the founder. Like I know I've interviewed early stage founders who are building generative AI products and, you know, pre-revenue, you'll talk to them about COGS and like they don't care. Um, and then you talk to a $10 million ARR business where they've, they've kind of, they are alive and they have a great shot at building a really meaningful company and it's becoming something that they absolutely care about, um, because their board is applying pressure on, on, on that, on the COGS side. Um, does that seem right to you? Is it's, it's also got some stage dependency to it?

Absolutely. And it's, it's one of the things our team's getting a little better at talking about. But, but I think even our team still struggles in terms of, of talking about SaaS in terms of phases. Like, I mean, we, one of the reasons we're putting together the SaaS Builder Toolkit is to sort of accelerate the best practices of SaaS into earlier stages. But still, if I'm talking to an early stage founder who hasn't found product market fit, I don't want them focused on all those details. I want them focused on making a great product that their customers love, because if you don't do that, you don't get anything else. You're not, you're not, it doesn't matter if you built the best SaaS and have the best understanding of your cost model. If you don't have the customers, it doesn't matter. So there's what that line is for product market fit and how we understand it, of course, varies a great deal. But up until that point, we thought about it. I usually counseling customers don't spend too much time trying to optimize SaaS and understanding everything about it. Some analytics, of course, to understand how your customers are using it, some other pieces focused focus on those. Don't get into the business of optimizing before you've even found out if you have something yet. So I think it's a great, it's a great point. And focusing on, on what the stage is of the customer is something that I think a lot of material out there— for anyone who's watching who is from a startup, be really skeptical about the material you're watching. It may be we're talking about best practices for a $10 million company, and we don't really contextualize that that isn't what you should be doing right now., but really think about what you're doing, really have a laser focus on building that product market fit and landing those early stage customers.

Makes, makes a lot of sense. You know, one of the reasons talking about monetization is in SaaS is so interesting is because it impacts basically everyone in a business from engineering to sales to marketing to CS to product. And everybody kind of thinks about the challenges differently. And one of the things I've so enjoyed talking to you about is like when we start talking about monetization, very quickly it ends up becoming a conversation around features and feature management. And, you know, it's not always the case when you're talking to like a pricing and packaging consultant or, you know, somebody on the growth side. Do you think that it's, is it fair or is it reductive to say that a lot of the technical and architectural challenges around supporting monetization as a business goes from single product to multi-product stem from how we manage features?

Oh man, it's a whole ball of wax. But yes, like I think when I started a couple of years ago, I was doing a re:Invent talk about making SaaS products extensible. How do we think about them and repackage them and make them partner features, other things? I started diving into feature flags and we've always talked about feature flags at SaaS. This is nothing new. And I kind of, I have to admit, I thought we'd had this conversation. When I started, I was like, oh yeah, you know, feature flags. And I started talking to people about feature flags and realized people understand feature flags about an inch deep. It's a boolean. You turn things on and off and that's it, right? Great. I can do that in code in a database in 5 minutes and we're done. I don't have to think about it again. And I started digging into, you know, some of the larger feature flag providers and seeing the features that they were building and why customers liked them so much. And even then, even when I reached that point, I was like, okay, you know, these are the 2 or 3 biggest feature flag providers. I started thinking about them in terms of SaaS and realizing they're even not saying what I would want to say about SaaS and talking about how you turn on what I sort of crudely call entitlement flags. I don't really like the terminology there. We don't really have a perfect terminology for how we describe features in SaaS because as soon as you say features, people are like, oh, just feature flags. This is just, you just mean, you know, turning things off for releases. This is a whole nother ballgame of long-lived flags that manage how your software behaves, how it's configurable to your end customers and what it looks like beyond simply, you know, a release where we're actually introducing a flag and then removing it later. These live throughout the lifecycle of your product and change the way you think about how you develop your products. Those features and how we encompass those features and how we want to package those features. Like you said, that's a conversation across many teams. You know, how does your— what does the finance team think about how much it's going to cost to support this feature? How do we bake that into our product? Has our product team thought about what tier, if we have tiers, this is going to live in? You know, as they understand the cost and as we start to do estimation, do they think it can be profitable? Do we want to focus on this feature if it's going to cost us $100 every time someone executes it, but our customers really aren't willing to pay for that? And this is where feature flags really start to sing and dance. They become a piece of a cost culture inside of an organization. You change how you develop. You start to think in terms of features and what they're going to look like in the final packaging instead of just, hey, we're adding more and more and more. Into this ball of software that we've created. We hope our customers will pay enough for the whole package. Instead, we get to get more granular on how we think about them. And it's not revolutionary. This is nothing new. Feature flags are not new. I tried at one point to find who first started talking about feature flags, and I got back to Martin Fowler in like the '80s, and he was talking about it as if his great-grandfather was using feature flags. It was like, yeah, everybody knows feature flags already. You know what I'm talking about. I'm just documenting that this exists out there. So it, it's, it's such an old concept. It's been so baked into how we think, but the use of it and how it applies for SaaS is still in some ways revolutionary because I'm just not arriving at many SaaS providers who already have this in mind and understand what they want to do with feature flags beyond just release management, which, which by the way, use feature flags for release management. Like, don't, don't, don't get me wrong, keep doing that. That's, that's exactly what you should be doing. Blue-green testing and everything else. But this is a whole nother aspect of feature flags that I think, Fynn, you guys are very much on the cutting edge of. And I'm very excited to see where you guys go in terms of feature flags and how you help to help SaaS organizations evolve feature flags as well.

Well, thank you for saying that. I mean, I think you've written about entitlements. I mean, you've, you've really kind of gone deep on entitlements, why they matter. Why they are complex. And, you know, before we started Schematic, I think, you know, we interviewed 100 CTOs and we, what was so fascinating about the conversation is we would say, why is it so difficult to support pricing and packaging evolution as the business grows? And they always said entitlements and they would use different words for it, right? But like the key concept was entitlements. And what was often happening is they were either hard coding the entitlement into the application, tying it to a plan ID. Or they were using feature flags as entitlements, or both, and often both, but either way, they ended up having to build all of this homegrown glue between the application and these business systems downstream, which, you know, control packaging and pricing. And so entitlements are very important, but I think that they are, to your point, like, they're in some ways misunderstood, and they can, you know, they're talked about with different words. It's a really interesting complexity in modern SaaS, and it's such a such a huge opportunity in my mind for feature management to extend into this use case that can be so, so hugely valuable for companies from an agility perspective. But I'm waxing now.

I love it. And I just, I mean, a founder's passion is one of the things I love about startups, by the way. Like, I, any, any founder conversation I have, I want to turn the interview around and start interviewing you about why you did this, like how you got into this mindset. But maybe on another time we'll do that because I do think you guys are doing some amazing stuff and even taking the conversation up to the next level. So I am really excited to see where Schematic goes with this, by the way. So we will have that conversation, I promise.

I know we're getting close to time and I have a couple more questions, but, um, I'm curious, you know, if you were talking to a room full of, you know, product and engineering leaders at early stage and growth stage SaaS companies today, what are kind of 2 or 3 things that you would suggest would be valuable for them to do as it relates to understanding and improving their ability to help an organization evolve monetization?

So early stage, so this is, you know, early stage founders, I think I have been trying to focus this conversation. We did some talks with the SMB program about thinking about things in different phases, and I tried to break down some of those thoughts. I think there are a few points and some of them can be somewhat pedantic, but I want you to think about isolation. As the, the foundation of what you're building. Even if today, uh, that means we're just creating a silo, uh, solution that goes through AWS account per customer, and we make sure those accounts are truly secure from one another. I think that's something— it doesn't necessarily tie directly to monetization, but it's the first thing I want you to think about because it, it means you have a more stable cost structure in the beginning, right? If, if you really have the ability— so Fynn Glover, you know, if you become a serial founder, which you, you know, many startup founders end up being serial founders, your second or third company, uh, maybe starting with a pooled strategy because you've done it before and your team has done it before, uh, might be on the table. But unless you've done that, I think keeping things really simple in the beginning where you can easily understand your cost structure, easily understand how your customers are using your product, uh, even though it's not— isolation isn't necessarily an input into cost It helps us to keep a simple understanding of cost and helps us to, you know, to simply evolve what we're building without getting bogged down in the details about what's going on under the hood and how it's being used and trying to tease things apart, which you will need to do later. So keeping that simple, that's probably one of the pieces. Understanding your customers is the other part. I do this through the lens of identity. You know, what— who are the customers we're targeting? Is it large enterprise customers where they've already got thousands of customer— thousands of employees and they're not going to want to recreate all of those, that identity management in your solution. At which point, you have to think about single sign-on and what it means to integrate with your customers' identity stores, right? And that could be an expensive proposition and can be a big input into what your pricing should look like out of the gate. So having that type of understanding as well, even though, again, both of these don't seem like purely cost points, but they can be some of the bigger wags in terms of what it means for packaging and pricing your product, especially early on. Developing some understanding of features, believe it or not, and not just because we're talking about feature flags today, this is one of the things that I do talk to early stage founders about is don't, don't have to start with entitlement flags, but start thinking about what you're developing in terms of features. Actually take a, take a moment and think, okay, if I'm going to repackage this, because there's a pretty good chance whatever you initially package your pricing out at, it's going to evolve over time. And to actually get to that evolution, you might have to take things that you consider features and move them around between tiers or consider adding extra costs for them or putting limits on them. If you don't develop those as features out of the gate, at least looking at these things and saying holistically, this group of services make up a feature, it's going to be very difficult for your business to have that evolution over time. So those are 3. I know we're coming up on time, but I have a couple more. But I think those are 3 of the ones that are sneaky inputs into cost that I want you thinking about as an early-stage founder.

Those are excellent. And Bill, pause. Are you good for 1 more minute or 2, or do you have a hard stop?

Yeah, no hard stop.

Okay. Those are great. You mentioned that the 2 or 3 years that you spent at a startup is pretty formative, but I wanted to— one of the closing questions I like to ask is What has been the most formative or influential experience on your professional career?

That's a tough one, Fynn Glover. Uh, you know, it's, it's been a lot of different things over the years. Um, I would say that first startup was the most influential for me. Um, switching gears from, you know, doing enterprise engineering and thinking about the long play. Um, I think the biggest change for me there was we had spent the last couple years at this enterprise travel insurance company I was I was at trying to get to the cloud. We're very slowly building things in the cloud. And unfortunately, this, this will give people a window into just when I— how long I've been developing. Cloud development still wasn't ubiquitous, right? Uh, we were using AWS, but we were using it for all these sort of things, backups in S3, some multi-region stuff we were doing. As soon as I moved to the startup, uh, you know, we didn't have a data closet. There was no non-cloud. Everything we were doing was in the cloud. We were born in the cloud and it was just a transformational change for me. Just thinking about everything is as how is this going to play out in the cloud? How is this going to play out for our different customers? How did they want to receive their software? And also, I mean, some of those same challenges of SaaS existed then. I would have said we were not a SaaS provider at the time. We were instead somewhat of a managed service provider and that we were building stuff. We were thinking of SaaS as SaaS., but then creating bespoke implementations for customers, which in the end, uh, was the, the, the death of that company. You know, it, it really had an opportunity to grow and become successful. Another company with almost an exact same product ended up turning into a unicorn. But the, the sort of lack of vision in terms of, of thinking about how to operate SaaS and become SaaS, that was also another stake in the ground out of this first company that I worked for in the startup world. It, it opened up my eyes to how important your relationship with your customers are, how you price your product, what it means to have recurring revenue instead of one-time revenue. We had lots of million-dollar customers who paid us $1 million to use our software one time. And when we went to gather up money and go out for our next round of funding, someone said, "Well, what's your recurring revenue model look like?" And we're like, "Well, we've got all these customers who will pay us $1 million for our product." There's no guarantee that anyone else will do that in the future. Just because they've done it in the past. Recurring revenue is incredibly important. And working for a startup, you know, in the enterprise, you don't necessarily get visibility into all those different pieces. What it means for the company to be born in the cloud, what it means to package and price your product, you know, what it means to raise funds and go out to the market and, you know, hat in hand and say, you know, who wants to buy this? Who wants to invest in what we're doing? You don't get that visibility. And if it hadn't been for that first move and then the ones after that that helped me to grow and learn more about the the environment, I don't know that my career would have gone in the direction— I certainly don't think I would have ever landed in AWS. And given the fact that I love what I'm doing at AWS, given the fact that I'm happy with where I am, I would say that was the most pivotal moment for me. To mark it down to a moment when one of my coworkers actually took me out to lunch and talked me into joining her company because I was very much on the fence and it's like, you know, I'm stable here. Got kids, this is a great place to work, they treat their employees really well, and I like where I'm at. Uh, going from that and, and taking that plunge and, uh, getting like a, a million shares that turned into wallpaper later, but, but actually accepting the model, like, you know, the, the risk and saying, yeah, I'm willing to invest into this startup experience, turned out to be a big investment in myself, even though that's not how I was thinking about it at the time.

It's so, it's so true how the investment in going into a startup is such an accelerant, such a formative thing, such a bet on oneself. Where can people find you and where can people learn more about SaaS Factory?

Well, yeah, I mean, lots of great resources for SaaS Factory. For me, you can usually find me on LinkedIn. I do most of my posts there. I do have a Twitter handle, @SaaSTar. I just don't spend much time on Twitter. Unfortunately, this probably also shows my age. I never really embraced Twitter as much, but I do spend a lot of time posting on LinkedIn. The SaaS Factory team, you can Google AWS SaaS Factory, of course, and come up with a number of our sites. You can also go out to GitHub on AWS Samples. Our team has published many different SaaS repositories. If you're interested in serverless, we've got a serverless reference architecture and a workshop. Same for Kubernetes with EKS or ECS, Elastic Container Service, our AWS version. Of containers. Got tons of blogs out there. If you search for any of our blogs on the APN, you can also use my name. I've published a few myself, including a couple of the ones we were talking about today in terms of each of entitlement management. We've got lots of material out there. But yeah, I'd love if anyone wants to connect, always happy to talk to any AWS customer or partner, but especially early stage if you're interested. I love the conversations you and I have had, Fynn, about how you're growing your company. And I just, again, love founder conversations. So if you do want to reach out, uh, feel free to connect.

Awesome. Bill, this has been so much fun. Thank you again. Thank you so much.

Thanks, man. Really enjoyed it.