Monetizing SaaS: Episode 19 with Tim Olshansky, CPTO & Founder

Tim, thank you for being with us. Uh, it's so fun to have you on the podcast. You've been a serial founder. You've been a technology leader across a number of really great companies and startups. I think you got your start in derivatives trading, which I'd love to hear about. And then you worked, um, at Switchfly as an engineer. You co-founded Worksite, which was acquired. Uh, you eventually served as the CTO of the acquiring company, which I think was called Econics. Hope I pronounced that correctly. And then you joined Zenput. And you helped lead Zenput through a great acquisition as Chief Product and Technology Officer. You're working on a new startup, as I understand it, which I hope we can hear a little bit about. But can you tell us your career journey and in your words, how we got to now?

Yeah, no, Fynn, great to be here. Nice to see you again as well. It's been a little while. Yeah, that's, I mean, that's a great summary, at least of the most interesting things I guess I've done. But I started off, you know, like many graduates, particularly with a kind of a law background as well. So I did the silly thing of getting a JD, thinking I would pursue that path. And, you know, in my final years, I was doing some part-time paralegal work and some summer internships and that sort of thing and realized that wasn't for me and ended up pursuing finance. Ended up as a derivatives trader at a firm called Optiver, which was one of the largest market makers in Europe, doing some algorithmic trading, which was a ton of fun. And throughout college, I was actually flirting with some entrepreneurial ideas. I actually had a tiny little exit in a marketing-related— you could call it a startup— because a bunch of friends and I used to throw parties, but we sort of— we built up a great list of of people who would go to these events. And anyway, we, uh, we had a great time doing that. Uh, I, with some other friends, tried to build some stuff that never ended up working out. And so I ended up trying to do the traditional thing, ended up in finance career. That was great, but it's also not the best time because I was sort of, uh, in the peak of the Great Recession or the financial crisis or whatever it is we call it these days. Decided I want to get back to building. Had some great friends from college who I, you know, had tried to do things in the past, convinced me to move to the Bay Area and work on a startup called Topguest, which is what ended up getting acquired by Switchfly. And that's how I ended up at Switchfly. So that was the start of the journey. That was back at the end of, you know, I moved out here at the end of 2010, uh, and, uh, and haven't left since in 14 years. You know, I thought I'd only do a year or two just for some fun.

Did your, did your wife, I believe you're married, did your wife move with you at the time or did you meet her in the Bay Area?

We, we were together. We'd been together for about 2 and a half years before moving here together. So she, she'd never been to San Francisco. She had no idea what she was getting herself into. She was similarly in her career., you know, kind of going down a more traditional path and wanted a bit of a change and do something, you know, radical when you're a bit younger. And so she, you know, foolishly agreed to come with me to San Francisco. And, uh, yeah, we got married, we have a kid, um, he's a little American. So here we are.

Very cool. So Switchfly was a— take us, take us further.

Yeah, so Topguest got acquired by Switchfly. I stuck around Switchfly for about 18 months through the acquisition, met some great folks who later on became co-founders at Worksite with me. We built a construction technology software company specifically focused on an established problem around what's called project controls, which is some of the kind of more complex change management, cost management, and project management, aspects of like big, big enterprise, like enterprise, you know, the really big construction projects, multi-billion dollars and beyond. Um, and we saw a great opportunity to go build something in that space, uh, which didn't exist at that time. Um, we got started a bit too early. So we started this in 2013, uh, we built a wonderful product, we won some RFPs, uh, we were kind of on the ride, but, we need to raise more capital and VCs weren't really interested in construction tech. I remember going to one VC meeting and at the end of it, the VC asking me, so explain to us again why a construction company would ever pay for software. Um, uh, like when that's the starting point, okay, where do you go from there? Right? Yeah.

Maybe not the right VC.

Yeah. Maybe not the right VC, but at the time there were actually no construction tech focused VCs. Interesting. So, um, suffice to say, we, we decided to approach strategic players in the industry. So some incumbents that were doing something different to us, right? Those that we were not competing with and didn't at least appear to be competing with foreseeable future. And so we, uh, we went to, uh, Aconex. Aconex is an Australian-founded company, publicly traded, listed on the Australian Stock Exchange. Although had a very large presence in the US and was as big as, if not bigger than, Procore around that time. And of course, many folks in the US are probably familiar with Procore. Aconex was the sort of the top end of town. So it was the company that your, you know, Bechtel or Department of Defense or Army Corps of Engineers was working with. And so we met with them. We had partnered together on a series of RFPs. They knew we were fundraising and we discussed them investing. And then we ended up on a call with the two founders and they instead offered to buy us, which is, you know, not atypical, I suppose, in that sort of scenario. So it was a great result. It was a great team to join. We had a wonderful time at Akonex, integrated the product, became a meaningful part of the platform. I ended up being asked to take on the CTO role there., and I spent about 18 months in that role before we were acquired by Oracle, and that was in 2018. Um, Oracle, uh, has a big construction-focused business unit, although I think it's gone through some different iterations, you know, up and through to today. Ended up, uh, leaving there at the end of November, uh, or in November, end of October, and joined Zenput, which is a food tech related software company for a very, very good friend of mine was the CEO and founder, co-founder, built a great business in the food tech space. You know, we amassed 100,000 restaurants and grocery stores around the world, frankly, using us, which is bigger, or more, I should say, in terms of usage than, say, like Toast or some of the other really well-known restaurant tech-related companies out there. And then in 2022, we got acquired by a company called CrunchTime., and Crunchtime, also fairly well-known industry player, inventory management, labor management, sort of the bread and butter of running a restaurant. And, um, I stuck around there for a year as the CPTO as well. So I led the product and engineering org there for 12 months or so. And then I left, uh, in June of last year. So it's been, uh, a 12-month sabbatical for me for the last little while, working on something new, getting into cybersecurity. We're still in stealth, so I won't talk too much about it, but I'm excited by it. And my co-founder and I will be getting back to the grind, which is a lot of fun.

Such a great story. You know, before we go kind of into how the world's evolving and your point of view, which is probably kind of what's driving kind of how you're thinking about the new company.

Yeah.

There are not many CPTOs. Are there? And maybe that's kind of a question.

Yeah, um, so there's, there's CTOs that own product, there are CPOs that own engineering, um, and so there's a decent number of those across a number of different companies at different stages. And so I think while the title might be a little bit new, uh, I don't think that that role is necessarily that new. That said, I do think that also that role is becoming more common or prevalent the last 3 or so years, because why pay 2 very, you know, expensive executives to run, you know, either side of the same coin, frankly? And I think a lot of companies have sort of made the decision that— well, the CEO is actually— somebody said this to me, um, that I met with who really struck a chord with me, and that is, which, which fights do you want to arbitrate? For you as a CEO, if, uh, if you care about product and you care about engineering and you care about those things separately, that you want to adjudicate the fights between those two executives, then you should probably have one of each. If you just— as many CEOs, particularly non-technical CEOs, don't care about those things, then put it under one person. Let them sort out the fights amongst their direct reports, and you kind of set the goals and move on to doing other things. And I thought that's really articulated it in a great way for me over the last few years. And that's why you're probably seeing that a little bit more as people realize, you know what, I really don't care about this technical debt fight or this other, you know, deeply esoteric engineering topic. Uh, as CEO, are we gonna hit our deadline and am I gonna be able to sell the hell out of this thing and make a ton of money? For the business tends to be the more common consensus.

That's really interesting. I mean, one of the— so to the idea of fight, like one of the areas of software businesses that I've found myself interested in is just the natural friction that kind of ensues as product gets abstracted out of engineering and how that relationship builds in a really successful and positive way. And it feels like it's one of those relationships a little bit like marketing and sales where it can like really just not be all that productive for a business, kind of depending on the leadership in place. So maybe what have you learned about how to lead both sides of that organization, given, given their nuances and their differences and, and their habits?

Yeah, what I think it's, uh, become apparent to me throughout my career and, and being responsible for both organizations is that it really depends on who you're holding accountable for deadlines. And who ultimately has to bear the brunt of the questions around when something will be available and who is responsible for actually delivering on that. And, you know, that's the classic sort of, where does project management live in an organization? Classically, product managers in many organizations are glorified project managers. You know, they're given a feature that's been scoped and defined by somebody outside of their organization, and they're basically, you know, told to break down this thing into a series of user stories, which is, you know, nothing more than basically task management at that point. And then they're babysitting engineers and constantly, um, you know, pestering them and annoying them with, why is this taking so long, and challenging every decision they're making. And inevitably, that's what I've seen drives conflict in most organizations. And so where you can draw the line between who is accountable for the when and who is accountable for the what, the more effectively you can run those two organizations separately and ensure that they remain in some form of harmony. There's always, like in any kind of, you know, big deliverable, there's a trade between how long you have and how much you want to do. Of course, it has to go back and forth, and that's Okay, 10% attention. That's the thing that a product leader and an engineering leader can work out between themselves. But if you're putting all of the blame and responsibility on the, for the what and the when on the product leader, and the engineering leader is responsible for it, sorry, accountable for it, but not necessarily responsible for it, that just drives really bad behaviors. And so for me personally, and sort of managing that effectively, make it clear product managers are not responsible for project management. That's engineering, engineering management, right? And the more that you can separate that, the better. And at a certain point, you know, you've got many— if you're large enough, you've got many different streams of work. Somebody needs to integrate it across the org. And so then maybe it makes sense to have some, some kind of project management capability. But my point of view, that should live within an engineering or technology organization, not within a product. Conversation so the product can focus on the customer.

So is it— is a good way to play it back? In an ideal world, product is thinking about what we might build and why based on the market, and engineering is thinking how to build it and when we will deliver it.

Exactly. Yeah.

What, what about the role of— so this role of CPTO, but also the role of CTO, is a role that I've heard many growth stage software CTOs describe as one of the loneliest in SaaS. And I think that the reason they describe it this way is often the CEO is not someone that can actually help that person, like on the kind of core functional questions that they're asking on a daily basis.

Yeah.

How does that strike you, that observation? Does that feel valid? And if not, why? And if so, what can CTOs do with that?

Yeah, I mean, I think it's a very valid statement. I don't know that it's unique to, frankly, any role or function. Like, I hear the same thing from marketing leaders and growth stage companies. It's the CEO expects us to build this huge fantastic brand, but it's giving me absolutely no budget to do it, and, uh, is constantly questioning why we're doing these different types of campaigns because they believe themselves to be, you know, the best marketer out there because they have 1,000 followers on Twitter. So, so that's, that's sort of where I call the bluff a little bit, that I don't think it's that unique. That said, it is lonely, but I think that's true of most executive roles, right? There's usually you're in that position as the, you know, sole, in quotes, person responsible for that function. You don't have lots of peers who understand your day-to-day problems. And so you can't really, you know, rely on your CEO who, who doesn't get it. Obviously has a different viewpoint. And your peers in the rest of the organization, specifically like a CMO or a CRO or whoever, have their own battles to fight, right? So they don't have the same perspective. I do think though, all of that said, you can go a long way with building a bench of leaders in both engineering and product within your team that while they may not themselves be accountable for the big strategic decisions that an executive level individual is responsible for, they can have very good insights and often, uh, help take a lot of the strain away from you. So for example, in, you know, two different organizations, I once had a stronger, let's just say, engineering leadership than I did product, which freed me up to spend more time on the product side. And I had more of a, you know, call it, uh, peer-like relationship on the engineering side. And vice versa in a different organization, which I think that's where if you end up in this kind of role where you're responsible for both product and engineering, and mind you, product in many organizations also encompasses design, right? So you've really got 3 functions you're overseeing. You need to have a bench strength that covers you where you're weakest.

Yeah. Where do you feel like you lean strength-wise across those, that kind of, that trinity?

Probably strongest on the engineering side, just because my mind is probably more analytical and technical. And frankly, in terms of like raw hours spent doing building, that's where I spent the majority of my time. And the weakest, I would say, is on the design side, although I tend to have some of the strongest opinions on design with none of the ability, sadly. But I don't know that that's unusual.

So I think one of the things that's so fascinating about your career is you've seen the economy from a bunch of different perspectives, from derivatives trading and finance to law to construction technology to restaurant technology. I mean, these are lots of big components of the global economy, and you're doing this, you know, in kind of the last 10+ years have been largely through SaaS. Um, and so I'm curious, like, as you think about this next chapter and this next company, I'm curious to, to kind of hear you explore the big changes in the world of business and economy, or even just SaaS, that have captured a lot of your curiosity and a lot of your, your energy. What, what are the inflections that you pay attention to?

Yeah, yeah. So I, you know, it's interesting just going through the ideation process, uh, over the last 6 months or so in comparison to the ideation process I went through maybe 8 or 9 years ago. And you know, that, that phrase, uh, software is eating the world is very true. Every vertical now has something, and not just something, it has many things. So I do think that it's become a lot harder in the last few years to build, uh, meaningful or big solutions, I should say, in areas that didn't have anything. That said, I don't think opportunity has disappeared. I think there's still plenty of opportunity, and you can see that in many different industries. Like, you know, I always like to pick on Linear, and I don't mean to pick on Linear specifically negatively, but project management is an incredibly, incredibly crowded market, right? Everybody's built some kind of project management solution. And I once said this to a friend, I feel I sometimes think that a to-do list or a task management tool is sort of the engineer's equivalent of designing a chair for an industrial designer. If you know folks in the industrial design, everyone has to design a chair at some point. It feels like that's where things end up. So that's sort of my back, my kind of viewpoint here is that everything is harder and everything is easier at the same time because of some big paradigm shifts. You know, I've been fortunate or unfortunate to spend time working in industries that have historically not had truckloads of money to set on fire and not think about good business practices. And so it actually brings me joy to see some semblance of a return to sanity, albeit there's still some areas where that's not true. And so that helps me personally because I think I can thrive in that kind of environment. I think some of the big paradigm shifts that folks see negatively, like AI, are actually big positive, you know, momentum builders for every vertical, SaaS included. And in general, like talking about software and SaaS broadly, I think things like AI are actually going to lead to far more software than less. And so I think that every vertical that exists today, there is going to be a new round of innovation. There's going to be a new layer of solution. They're going to be new paradigms. And my, my preference has always been to go after reasonably established markets or markets where problems are known, where there may not be a lot of spending yet, as opposed to trying to do something so radically different where there is no market whatsoever. And I think because of this maturity that we're kind of getting to now, uh, that helps me. That's, you know, I see, okay, these things are now well-defined. We don't have to work so hard to educate people on why they need these things, right? Now we just need to do a good job. And maybe this is my arrogance or overconfidence, but feel like I can do a much better job doing a good job than trying to educate everyone.

Yeah, there's— it's so much more in your control at that point. Exactly. Like, if you're trying to category create, maybe the category doesn't come to fruition even if you've done a great job marketing. Um, kind And so effectively is a good way to think about the way you're looking at the world is if I can go kind of find a vertical that is ripe for a new wave of innovation and I just go in and reduce a lot of friction in that vertical from a, from in the context of software, I've got a really good shot.

100%.

Yeah.

It's surprising, you know, I, at one point and I think, I think many, you know, exited founders go through this journey where they think, oh, I'll just roll up a few different you know, companies and I'll go buy something so I don't have to go through zero to one again and then make it work.

I think every founder does go through that. They like go through some slog and then it's like, I should just start buying companies. Yeah.

It's like, why would I build this again from scratch? It's so painful. I should just go buy something and, and skip that. I went through that journey. I went on acquired.com to look at some, you know, different software businesses for sale. And it's just, it's shocking to me How many companies get to hundreds of thousands, if not low million dollars of revenue in such well-established, incredibly noisy, highly competitive markets, uh, by virtue of the fact that they just build a good product? Yeah, right. It's not the only thing, of course, but that to me signals that there's actually still plenty of opportunity, um, rather than this belief that 'Oh, because big incumbent exists, now it's tough.' Yeah.

Well, so reducing friction gets sort of to the heart of some of what we wanted to talk about today around monetization. Yep. Maybe you could just kind of kick us off with when you, when you think about reducing friction and whatever market you guys end up selecting, um, what's the framework there? Like, where must friction be reduced to, to have the best shot at winning?

Yeah, there's, I mean, there's a few different ways of framing it that I tend to look at. So I think there's, um, call it the, the product friction, or I should probably better to phrase it through the lens of like jobs to be done. So there's friction in the work being accomplished that the customer is buying the solution for in some way because of software bloat, because of complexity, because of old, old ways of working. If you think of, say, pre-remote, post-remote, right? And trying to take what we do in the office and digitize that, that wouldn't work, right? So where there has been some kind of transition, um, and that has introduced some friction, or the friction hasn't been removed yet, that presents an opportunity. I think that's one. Is there friction in buying in some way, right? So is, is there, you know, if you're trying to accomplish again something for your business and you have to go and buy 11 different tools and you have to figure out how to integrate all of them and you have to figure out how to manage all of them and you're buying them all at different times. Now you've got all this like contracting and procurement pain, uh, multiple vendors to manage, and not to mention your own time investment to accomplish the task you're looking for. So there's like a buying challenge there, or there's frankly just a commercial challenge, right? The, the pricing. And I think, you know, we're obviously going to spend some time on this, um, but in, in the simplest sense, you know, there are companies making 95%+ margins on something, uh, and so there is an opportunity to reduce the cost for the consumer in this market, um, where you as a new, not incumbent entering the market has some opportunity to do it at a much, much lower cost. That's where things like AI come in today, right? Where you can really reduce the costs and improve your margins to a certain extent to be able to do that more effectively. So I tend to look at it, is there some kind of product friction you can eliminate, some kind of buying friction you can eliminate, or some sort of commercial friction that you can address?

I think that's a great, yeah, I think it's a great framework. I cut you off. Are you going to keep going?

No, no, no. I mean, and that's, that's the essence of it.

Yeah, I think it's a great framework. When, um, in B2B SaaS businesses, pricing and packaging ends up becoming very complex for product and engineering inevitably. Um, and I think I have two questions for you. I mean, first question is, it doesn't seem like there's a standard or a pattern that exists that engineering and product can rely on to implement pricing and packaging in a way that maximizes for flexibility and that removes them from sort of critical path in the context of monetization initiatives.

Yep.

My first question is, is that true and is that valid? My second question is, why is pricing and packaging in B2B software so complex kind of architecturally?

So there's a, I'd say that it's a kind of a timing issue. In, in many cases for most B2B SaaS companies, you know, the zero to one stage, getting started, you're just trying to convince anybody and everybody to use your product and pay you anything you can convince them to pay you in any form that you can convince them to pay you in, uh, in order to get enough life to maybe raise additional capital or extend your own sort of life by a few months, right, by winning another customer. And so I think what ends up happening and probably rightly so, is there's no structure. Uh, and because there's no structure, there's no way to implement no structure in code, right? Or complete arbitrariness. I mean, that's the purpose of coding itself, right? So I think that's often the starting point for most SaaS businesses. Not all, but for most, there isn't a strong sense of how they're going to break up their product, whether into modules, collections of features, perhaps multiple products themselves, early. And because it's not clear early, and, and because things like schematic didn't exist for many, many years, and feature flagging, frankly, and the whole, you know, separating your deployments from releases and all of the workflows that we've now introduced that have become standard practice, those things weren't present. And so the entry points or the injection points for this didn't really exist. And because of that, and I've seen this countless times where there is no structure or framework at the beginning, lots of short-term decisions are made. Hey, let's just, you know, find a way to separate this one thing for this one customer in this one case., right? Goes and creates this whole table of, you know, toggles and flags that some poor ops person has to try to remember, uh, and product person has to try to remember how it all relates to everything, only to then get to a point of maturity, maybe when they're at their, you know, $5 million, $10 million in revenue where there seems to be some sort of repeatability to sales motion, the unit of, uh, value to the customer, whether that's a per seat or some kind of consumption-based pricing or Maybe it ends up forming into some kind of marketplace, whatever. Once that's become very clear, you then know how to bake that back into the product. But by then you've got a lot of product to bake it into. And so there is this hurdle you now have to climb to go and introduce it. And so just like in, in many cases, these are the things that if you could implement something early on, the cost down the line would be trivial. But how do you justify the time to implement that thing early on when you really just need to build feature X in order to survive another day?

Yeah. Yeah. How did you approach building out this type of infrastructure at Zenput? I think you got to the company 4 or 5 years into the company's lifecycle, right?

Yeah. Yeah.

Yeah.

So fortunately, when I joined Zenput, the company had already established a couple of good things that I think are kind of essential for anybody trying to manage pricing and packaging as they're growing. The first was a fairly tight integration in data flow between Salesforce and the product. And so there were things that were identified, I should say, not just Salesforce and the product, but also user analytics tools. So those 3 things together made it a lot easier to see what customers were using, which features they were using, and how to correlate all of those together. What they were paying for and where there was some kind of gate, you could kind of manage that in one place.

And that visibility is actually not so common, is it?

Oh, not at all.

Like that, that's like a relatively proactive move from Zenput to have had that when you came in.

Yeah. And at least in my experience, I've only really seen that at companies much further along, right? Talking $25 million in revenue, right? Thousands of customers at that point, hundreds of employees. So that already exists. So that's one, which I thought was pretty impressive. And then the second thing that was present mostly for the benefit of the engineering team. It wasn't being leveraged organizationally quite so holistically yet, and that is deployment flags, feature flags, however you choose to phrase them. But this ability to separate different components of your system from different categories of users or customers with some of the infrastructure to make itself serve. And so because those things were present, you know, LaunchDarkly and companies like LaunchDarkly and whatever else obviously didn't just show up in the last year or two. So it's not like we invented it at Zenput, but I do think it was a bit ahead of the curve to introduce it. And we, I think I was probably the one that pushed most strongly in favor of using it more aggressively to decouple our deployments from our releases, to more closely partner with the marketing organization so we could launch things more effectively, be a bit more hand in glove with, say, like our customer success or support organization so that we could manage which customers are getting which features at what time, train ourselves internally to manage that more effectively, and then think through the commercial aspects of all of that as we're playing with it to figure out, okay, how do we adjust pricing? Is this an add-on? Can we do different things down the line? Mind you, we were still terrible at it. Like we had a hard time, but that made it a lot easier. So I think the visibility into who was using what and what they were paying for, that was fairly accurate. It was maybe lagged by about 8 hours in terms of the data pipeline we had, but that's good enough, right? Especially in more enterprise-like B2B, you know, your customers aren't buying with credit cards, or at least ours weren't. So things weren't changing that radically that it needed to be always accurate. And then being able to separate chunks with a little bit of effort, not with a lot of effort, made us, I think, move a lot faster on various commercial things.

And so were you using LaunchDarkly for basically kind of, we're going to use LaunchDarkly's flag service for deploying and releasing new features?

No.

Rolling out new features?

No, so we actually, so we're, the application was built on Django and we built, it was a fairly homegrown feature flag system. It was fairly naive, fairly vanilla.

Got it. So you're using homegrown flags and then were you, I'm curious how entitlements worked within that system between, yeah, tell us about how entitlements work and maybe start off by saying what are entitlements too for those that maybe aren't familiar with the term.

Yeah. Well, I tend to think of entitlements and please Fynn correct me. Here as well in terms of how you think about it too. But I found, I find entitlements refers to what users can do or what companies, customers, your customer has access to within your product. And if you go to that next level of what level of access perhaps if there are multiple levels of access to a thing. So, you know, that actually the area we're probably weakest on at Zendesk was this notion of entitlements, but more in the authorization context or in the security context rather than perhaps a pricing or packaging context, a monetization context, in the sense that, you know, we had 3 hardcoded roles that you could choose from, and each of those roles had a fairly haphazard collection of things that a user with that role could do in the system. And then there was some configuration that was hidden from the end user that we could, you know, modify in the admin backend to grant certain capabilities to customers. And so because that was fairly disjointed, not structured, entitlement management was actually pretty hard. And so our feature flagging was very basic. It was either at the— we had, we call them companies, our tenants in our system, um, could do, could have access to X or Y. That was about it. Or users could have access to X or Y, and that was it.

Yeah, it's super interesting. I mean, it sounds relatively familiar because I think a lot of what I hear companies describe when they go sort of build monetization infrastructure is a relatively predictable homegrown path that often starts with, you know, like homegrown flags, maybe some, some kind of effort to build entitlements and admin console. And then a lot of, you know, work to build and maintain integration integrations with downstream business tools like the CRM or like the billing tool, or maybe the ERP as the business scales. And then kind of on top of that, like start to move into the audit logs and things like that. And so it ends up being quite complex and big over time to build all this infrastructure.

100%. Yep. And that's actually, you know, we at one point, probably halfway through my tenure, so about 2 years in at Zenput, we started to think about using something like LaunchDarkly, and we evaluated, I think, 3 other solutions. Um, and we ended up not going with any of them and just staying with our existing solution because the process of evaluating the other solutions helped us identify what the gap was currently, at least in what we needed to do. And we came to the conclusion that it was cheaper and faster and everything to just add that small sliver to our own solution than it was to move wholesale onto a completely different solution. But the other thing, um, I won't name the vendor, uh, but we actually had a couple of vendors who we work with that were in our kind of core request flow from a technical standpoint, right? So a lot of our traffic would have to also use this system, and we kept having outages. Basically, the, the only reason we really ever had outages was because this particular service from Svender would have downtime. And so we actually were very sensitive to that and thought, okay, you know what, let's just stick to our own internal software where we don't have a third-party vendor, third-party dependency that will bring our system down and crash everything for our users.

Yep. Yeah, it's super interesting. You know what, on, on kind of this vein of feature management, I mean, I think one of the things that's so interesting to me about this space is when you think about jobs to be done like entitlements that end up becoming really complex for companies. Um, you know, you can approach entitlements in a number of different ways. Like, you could hardcode the entitlement, tie it to a plan ID. You could, you know, go approach entitlements like with some token-based approach with like an auth tool. There are different ways to do it. A lot of people, you know, I think end up naturally using feature flags to do it. Uh, it makes a lot of sense. But the, the kind of well-known feature flag tools that exist sort of are largely sort of marketing a story and a job to be done that kind of starts with deployment and ends at rollout.

Yep.

And doesn't extend beyond rollout into entitlement management and kind of all the flexibility that can be accomplished therein from a pricing and packaging monetization perspective.

Yep.

I'm curious why you think that is. Is that simply because like we're still kind of captured or enraptured by the idea that we shouldn't keep flags in our codebase? Or is it something else? Because like when you really think about it, when a customer goes and upgrades to a more expensive plan, when a sales negotiation results in a bespoke enterprise plan, when a customer rep, success rep, like enables an add-on, these are all feature management jobs. Yep.

Yep. I, I think it's, I think it's the classic, uh, you know, speed versus correctness trade, if you will. I, I suspect if you survey the entire industry, everyone would agree that this, you know, this other thing is the right way to do it, but we need to get this implemented and ready to go and the customer ready to launch, you know, in 3 days because we just signed the contract. So we don't have time to go and build out this other infrastructure. And yes, I know this is the 900th time this has happened, and so maybe if we had just done this, you know, after the first 100 and invested in, it would be a lot easier by now. But that's obviously not how organizations often think. I'm guilty of this myself. I've made that trade. I think it stems from two challenges. One, it's the classic sort of, we don't have enough time, we have to make some hacks, we just need to get it done. And the feature management system, or I should say the feature flagging system, which is, you know, obviously different to the broader feature management and package management suite. Is just the easiest place because it's already there. And engineers have added, removed feature flags hundreds of times before, and they can do it quickly. They can do it with their eyes closed, and it's just easy and simple, and it's a drug, right? And it's addictive. And so people do it, and that's why I think the second piece is that you don't often you don't often know how you're going to break your, your product or suite of products down into different, let's say bundles or things or components, if you will, from a commercial perspective. And what I mean by that is, you know, you might have an application that you think of as modules, different modules. So your customers can buy these modules, but it's one product with different modules. You, how, how, how do you even define those things, right? There's no industry standard definition for half of these things. Other companies tend to think of them as different products entirely, right? And you've got a platform, right? Within each product, you then might have different, you know, collections of features that you can license. And I think a lot of this is all related to an earlier point you made where there isn't a lot of industry standardization to begin with. You know, I'd ask 10 people to define what a product means in SaaS and you'll get 11 different definitions. Like, I just don't think that there is enough consistency there.

If, if we were to try to create a standard, you and me right now— yeah, um, we're going to solve the world's problems here in the next 15 minutes.

Yeah, should we tackle the Middle East next? Yeah, yeah.

Um, what are obvious components architecturally that need to be in a standard for modern SaaS monetization infrastructure? Like what comes to mind for me initially is product catalog, like a clear component that must be there. What other components must be there in your mind that kind of come off the hip for you?

Yeah. This is like tear my hair out. So I think there's, you know, all of the billing, there's a lot of the billing related components I think are essential. Things like subscriptions or transactions and whatever else, right?

Okay, so yeah, subscriptions is a great one. That seems—

yeah, that seems fundamental, right? Because you need to know what people are effectively subscribing to or buying on a consistent basis. I think the tenant— and that's sort of the vague term— but I think a lot of software products don't actually get the notion of a tenant completely right. For their system. And, and a tenant to me is the boundary around which you're going to draw that separates data from one— of one customer to another. Okay, there's different ways to implement it, but like this, this boundary, this tenancy boundary is super important. Whether it's, you know, a single tenant system, a multi-tenant system, that doesn't matter. But what is the tenant? Is it the company? Is it a collection of customers? Is it users? Whatever. Get that right and make sure that's crystal clear. Because that's also heavily tied to your go-to-market motion, how people buy your software. Have you? The entitlements are also essential, right? I think conceptually, what, you know, I've implemented this in a more security context in the past and it worked quite well from, for that particular business. This was at Worksite. I'm happy to talk about what we did there. For the next 2.5 hours, but I don't know that we have enough time. I think the entitlement or what a user can do within the bounds of the collection, if you will, is super important. I, you know, it's, it's funny because I keep going back to the difference between a module and a product. And a product and a platform. And it's all different words for literally the same thing, which is basically some kind of boundary you implement in your product, uh, to gate different capabilities or to organize different capabilities.

I've thought about that sort of as the product catalog, and the way I've thought about it is like the product catalog has to be a unified policy file that that describes all products and entitlements. And so it should try to solve the problem of multiple and fragmented product catalogs that often end up living in a CRM, a CPQ, a billing system, and an ERP.

Yes. Yeah. Although policies and entitlements, I think, is things that, you know, product people don't often think about. Tends to be more the engineering lens, right? Um, I think the equivalent of sort of the, the more product-friendly or consumer-friendly language of those things is catalog for policy, right? As you absolutely called out. And this is me just spitballing, but like something like permissions or, uh, capability or something like that for the entitled case. Yeah, absolutely essential.

I mean, do you think metering is a big, is a core separate component or service?

I, it's a good question. I have found personally that I've all, even though that my experience has been almost exclusively effectively some flavor of seat-based SaaS, with one exception, but predominantly seat-based, there's still a need for metering even in that case, right? There is some, some plan level within the product where capabilities, entitlements within that level need to be metered to a certain point. So conceptually needs to exist, but where is it standalone and its own independent thing? It sort of sits across or is it every entitlement can be metered? And when you get to a certain level of scale, let's say you're like an AWS-style business or an infrastructure business where it's all consumption-based, you kind of have to flip it where sort of you have this general meter bucket, everything else is sort of on/off.

Yeah. I think, I think that was a pretty successful riff off the hip. On like what the architecture for monetization should look like.

Yeah, so it's a tough one because there's just so many different ways it can go depending on how you're selling. So one company I worked at, we had our pricing model was, um, a percentage value. This was Aconex, and Procore does this too as well. You know, one SKU of the product suite was based on a percentage of the total cost of your project. So if you're building a billion-dollar project, we would charge you a percentage, and so that would scale. So if you're building a billion dollars, it's X. If you're building a $10 billion project, then it's 10X, right? Um, and that was great, but because that's an unusual pricing model. You can imagine we had a lot of difficulty explaining to customers why that made sense to them. Now, in the end, they would actually accept it because of the way that the product worked behind the scenes. But you can get creative, and that's what's so hard about pricing, is that in the end, you just want— you want to find a way to convince the customer to part with their money, uh, and so you often will do crazy things to do it.

Yeah.

Yeah.

I have two more questions before we run out of time here. This has been so much fun. I think I could keep talking to you for a long time about all of this. Just sort of on a kind of last note, if you were to be talking to a group of product and engineering leaders at growth-stage SaaS companies and you could advise them on how to sort of abstract themselves from all of the monetization challenges that they will inevitably run into if their businesses continue to be really successful. What are the 1 or 2 or 3 nuggets that you'd give them?

Yeah, I think one, um, try to be upfront and intentional about where you're going to draw your lines or boundaries, uh, in the service that you're offering as early as possible. And what I mean by that is sort of going back to the conversation we're having around like the catalog notion. Be very clear, are you going to have modules as part of one product that you sell different, you know, plan levels? Or are you going to have multiple products on a platform? And try to make that decision and make that commitment as early as possible. And I think that matters a lot because you can implement different things much more easily when you've picked that direction. If you try to sit on both sides of that, fence, you know, sit on the fence rather, then you're going to have a really hard time because you're not going to implement anything. You're not going to have clear direction. So you have to pick a path. Uh, and so that's one. And then two, I would say as much as you can, build that consolidated platform that combines billing, usage, uh, product data, and your CRM or equivalent. Build that data infrastructure as early as possible and find great products that can leverage that or plug into that effectively, right? So with, you know, what Schematic is doing and trying to incorporate, right? Find those things that exist and add them to your stack, but build that data stack early because that gives you a lot of leverage and power for every architect.

I think that's great. One, one question that I, that just came to me And I wonder if you'd agree with it is if you imagined a world where feature flags had pervasively extended into entitlements, all an engineer really has to do is do a flag check on what somebody might have access to. And it could be a metered feature, it could be a Boolean feature. Does that result in a world where engineering actually does not have to think about the separation, the, you know, the, I can't remember the exact terms you used, but the modules versus the add-ons, the bundling. Could you imagine a world where engineering does not have to care about that at all? Product would continue to care about it. And if that world did exist, would that be good? Or do you think engineering should want to care about those questions?

Yeah, I, at one company, was very intentional about not giving, the non-engineering part of the organization, uh, the ability to use Flex. And we did that very intentionally. We did that so that we wouldn't find ourselves in a situation where we introduced something that was meant to be very short-lived to make our lives easier, that somebody unbeknownst to us started using, and it became a crutch for a big, say, hole, gap, issue that existed in the way we were bundling our products or selling our products and so forth. So I don't, I don't know that it makes sense to live in a world where engineering is never responsible, um, and it's completely hidden away and abstracted away from engineering. And conversely, it doesn't make sense to not have a world in which a product or an operations or finance part of the organization, customer-facing part of the organization, can't control what the customer has access to.

As well.

Like, there needs to be a middle ground, I think. Yeah, yeah.

Tim, last question I think is, can you share, um, an experience— the experience that has been the most influential or formative in your career? And, and if you can, something really specific.

Yeah, um, most formative, um, I would say— so I think the thing that sort of jumps to mind, sort of the, the big story I remind myself of, is I had a manager, a mentor, back in my derivatives trading days where, you know, derivatives trading is a fairly challenging job and industry, and it's obviously very high-performance-oriented culture. It's super important. You know, you're gambling hundreds of millions of dollars, uh, that you don't own, right? It's not your money, uh, all the time. And, uh, one mistake could lose a lot, right? And so I, you know, at one point I had a $300, $400 million sort of investment, let's just say, on this mathematical ideal or relationship between two different securities. And you can imagine that, like, my stomach was in knots and I was very, very stressed out about, about it. Um, in the end, it actually worked out in our favor, uh, and so obviously we did well financially, etc., and it was the right decision. But the thing that really stood out for me during my experience actually as a derivatives trader is the necessity to separate your emotional reaction to things from the rational or the intellectual decision or component.

And it's so hard to do.

It's so hard to do. But the thing, the thing that I realized going through that job for a few years was that actually the processes, the rules we define for ourselves ahead of time before that situation actually pay off enormously. It's actually why you see a lot of these, you know, trading firms— and it's not the only, you know, some of the best companies in the Valley and in tech in general also do this— they're very clear and upfront, and they take a lot of the emotion away from the decision-making when that eventuality comes along. Because you need systems for these things, uh, in order to stop the irrational parts about human nature from taking The lizard brain would be pretty destructive.

Yeah. Tim, thank you so much for doing this. It's really useful. Where can people reach out to you or find you if they've got questions about what you're building or want to ask you questions about monetization?

Yeah, I, so I'm on LinkedIn and that's probably the easiest place to find me. I post there and engage with folks. You can also find my contact details if you Google my name and on my website. So folks want to reach out in other ways, of course. But Fynn, this was a pleasure. I had a really great time chatting with you, and it's good to be on here. Awesome.

Thank you again. Cheers.