Monetizing SaaS: Episode 31 with Jon Sadow, Co-founder & CPO of Scoop

John, thank you so much for being on our podcast. I've had such a pleasure getting to know you over the last year. Um, always great to meet another founder in Atlanta. You, you, uh, I know, I know, and I've learned about you that you're someone that loves to build products. And I think your story to becoming a builder and becoming a product leader is so interesting. You started in construction, you dabbled in finance, you got into account management and sales at Google, and that kind of catapulted a career in not only product but also founding companies. And so in 2015 you left Google, you and your brother started, you co-founded Scoop, and you've grown that through incredible adversity over the last 10 years. And so can you tell us your story in your own words?

Yeah, I appreciate that. Likewise, it's been great to get to know you. There's only so many of us building companies here in Atlanta, and so it's always fun to get that connection. I love what you guys are doing. Our story is one of many eras, as you know. And so I think it all starts with, I was a product manager at Google and really wanted to see what it would be like build a product where I was sort of responsible for my own outcomes, right? I wanted to be a decision maker and see how much I could really envision and build and bring a product to life. And for the first 5 years of Scoop, we were building what ended up being the country's largest enterprise carpooling and commuting platform. And by most startup measures, we did pretty well. You know, we grew the team pretty substantially to a couple hundred people. We raised a good amount of money. Revenue was looking good. And then, as you know well, everything kind of crashed. When COVID hit. You know, when you think about the business we were in, all of our money, the way we priced and built our business was around trips to the office. And so pretty quickly, I think it was like within 10 days of the beginning of the shutdowns, our business dropped by like 99.9%. I always joke that, you know, you have a government mandate to not use our product for a period of time, which I guess isn't such a funny joke, but I've come to terms with it at this point. And then And then since then, we've had a couple iterations of the business as we've kind of pivoted our way through COVID and then really jumped early into the hybrid work world and thinking about how do we take our expertise and what used to be the core challenge of mobility, which is getting to the office, and evolve that into how do companies and employees feel productive and energized in this sort of post-COVID flexible hybrid universe that we're now in. And that's what we've been building since, you know, early '21. And it's been, it's been great. I mean, The silver lining in our story is what you learn through hardship and failure and, uh, rebirth, so to speak. And that's where we're at today.

Yeah, it is amazing. I mean, very few people that, at least that I know, have gone through what you guys went through, and it's just a remarkable story. And so I think founders should get to know you guys if they're running into like major inflections that kind of obviously complicate the entire premise of the business. So subsequent to COVID, you guys have shifted into productivity, shifted into how people manage hybrid work. Can you tell us about kind of like what the product is today, what it does, about Flex, where is the focus and where is the energy going?

Yeah, so, you know, the last couple of years the focus has, has been in two main areas. The first was where we spent a good chunk of our time in '22-'23, which is really thinking about how do we give tools and capabilities to the sort of the end employee, the hybrid worker if you will, to be the most productive they could in determining where they wanted to work, what they wanted to be doing, and whatever location location they were in, who they wanted to be doing it with. So really, as simple as like, who am I working with, who am I meeting with, what am I working on, and how do I do the right thing when I'm at home and the right thing when I'm in the office. In practice, that looks like a Slack application. We really wanted to root our product in the collaboration stack that a lot of people are already using, which sits in Slack from a day-to-day communication perspective and does all kinds of things like understanding what meetings are on your calendar and coordinating days in the office and daily updates and sort of aggregations of your schedule. And that's been great. And we've been really excited primarily around the fact that that's just a very organically driven product in terms of how it grows, which I think speaks to the fact that this is an unsolved problem. What is interesting is sort of the secondary product that we built, which is now frankly our focus as a business, is something that we built called the Flex Index. And the storyline of the Flex Index is, it's quite an interesting one where it really started as a marketing effort, right? We wanted to collect data about return to work and flexible work policies, with the premise being that if you think back maybe 18 months, there was a lot of tension between employee and employer. I mean, there still is, but it was really in full swing around employers wanting to bring employees back and employees not wanting to go back. And we really wanted to be part of that conversation and figure out how can we bring sort of truth and data to that dynamic, right? What are companies actually doing? And we started collecting that data, and then sort of the momentum just sort of organically picked up where we started getting more data and more interest and people became really interested in our reports. And from there they started to ask us for more data and say, well, could you get us this? And can you provide benchmarks on that? And what if you helped us understand office utilization? And like most good startup stories, you kind of follow where the demand and the problem is. And we realized that there was this really significant challenge facing sort of the decision makers at companies, which is they were flying blind. They don't have data, they don't know what other companies are doing, they don't know whether their policymaking is performing or not, whether their office decision-making is optimized or not. And so we've started to release a variety of different products, a benchmarking product, a GPT-powered sort of policy bot product as well. And that's, I think, going to be the focal point for us going forward.

Where has that demand been coming from? Is it enterprise businesses with HR leaders, or is it more diffuse than that?

It's, it really, I mean, it definitely is felt most strongly from the larger companies with the most offices, right? I mean, I love to use this example of one company we work with who has, I think it's 77 offices across 24 countries. And they're trying to figure out how to manage policies and attendance rates and desk utilization and office design across all of these different locations. And even just to get their data into one place to pull into our Flex platform to get access to Office Benchmark, parks, it took them about a month, right? And they're, they're figuring out how to work with local office managers and building systems and all this stuff. And so I use that as an example of obviously this problem is going to be magnified the more offices and the more space, the more teams and units and geographies you're in. But really what we find on the sort of on the smaller end is as soon as you get to like 4 or 5 offices, this problem becomes quite substantial, right? Because you're spending at that point a significant amount of money on leases or in some cases purchase. You're really thinking about office utilization, you're thinking about building teams locally. And so the idea for us is to be able to offer something that can scale up or scale down in terms of its overhead and its impact. But the problem is so ubiquitous. I think in some ways, like as a founder, as a product builder, one of the challenges is how do we not get carried away with the idea that everyone feels this problem, right? And still stay narrow and focused because everybody is trying to figure out how to operate effectively in this world because it's so new.

So I'd like to dig into how you actually talk about the problem with customers.

Yeah.

Because like, is the problem hybrid work is something that is complex and we're still trying to figure it out? Or would you describe the problem differently than that?

Yeah. When it comes to the Flex Index specifically, the, the problem that is most top of mind for us and our customers right now is built around our first real commercial product, which is called Office Benchmarks. And the general context there is that as a VP of real estate or an HR decision maker, or maybe a finance decision maker, I need to consistently make decisions on how I invest in the office, right? What is my work workspace? How is it being used? What is the relationship between my flexible work policy and attendance and office space, et cetera? And what we found is that in most cases, companies at best are asking friends, maybe talking to another company down the street. At worst, they're just making decisions in a vacuum, right? They're making a policy decision and trying to figure out what those stats are. And what they've come to us saying is, hey, can you help us understand what else is happening? Like, what are other companies doing in our space? What's the competitive landscape? What do the benchmarks say is good attendance or good office usage? Or we look a lot at, you know, like relative square footage and relative desk count to employees. And we always liken it to, if you think about like compensation, very standard thing in industry over the last few decades has been compensation benchmarking, right? And it wasn't always that way, right? It used to be like company would pay whatever it would pay and it would, it would figure out if that was good enough. And then over time it became a secondary industry of, okay, well, what are companies paying, right? What is market rate? For a given role in a given geography. And now it's sort of standard. I think any company more than 50 people is paying a PAVE or a Radford or an Option Impact for compensation benchmarks. And in many ways, office benchmarking and real estate benchmarking is sort of the emergent version of that exact same thing, which is, hey, we're spending a substantial amount of money on our real estate. We're trying to engage and optimize productivity around our workforce, but we have no idea if we're doing this right, wrong, better, worse. The same or different. And so as a result, there's a real hunger to say, okay, help me understand what we're doing relative to the competitive landscape in the market.

Really helpful. Very clear. So tell me a little bit about how you go to market with this product and how you think about monetizing this. Yeah.

So the nice thing for us when it comes to benchmarking products is there's sort of a, especially in the HR-related or tangential space, there's kind of a known approach here, right? Like it is ultimately, we are a data product. We have data. We sell that data. And so it's, it's pretty typical for companies to expect that they're gonna purchase that in some type of subscription. And over time that, that'll probably stratify depending on what goes into each type of subscription. Are there certain tools or certain sub-datasets or filtering capabilities? Right now it's pretty basic. You know, you have one price for, if you have one office, you have one price for more than one office. Obviously most folks who are interested in our tool are using more than one office and we give them full access to the benchmarks as a result. And as we build, we'll start to roll out tools and things that add more functionality and sort of stratify that a little bit more. The interesting sort of economic consideration for us or sort of go-to-market consideration for us is when you are building a dataset where benchmarks are involved, it's really more like a marketplace in its infancy. And what I mean by that is you've got demand for data, but you need supply of data. And so you're trying to figure out how do I get this data in to be able to develop the benchmarks that then provides value back to the company that wants to subscribe. And so we're fortunate enough to work with a lot of early partners who are, are assisting us in helping build that core dataset, right? Who have such a vested interest in helping us get to scale in our underlying benchmark data that they're interested in sharing their 50, 100, 200 offices worth of data to propel the overall infrastructure forward. And then when it comes back around, that means we'll have enough scale to really provide value to a company, ideally of any stage and any geography.

I hadn't actually put two and two together, but I should have. You're building a data product, but you're really building a marketplace product, which is interesting because now, you know, your career has spanned building surveys, building carpool ridesharing apps that are sold to big enterprises, but also, you know, have to be like incredibly easy to use for consumers. And now you've built a data product marketplace. So I'm just interested in kind of understanding kind of maybe the 2 or 3 most surprising things you've learned as you've shifted into marketplace slash from a product perspective.

Yeah, you know, it's interesting. One of those learnings is actually on the, you know, for whatever reason, my bent on learning or any questions tends to be like things that we did wrong or failed at. But in fact, the first thing that comes to mind is what's been interesting for us is, you know, before we had a consumer marketplace between riders and drivers in a corporate context. Now when we use the word marketplace, we're talking about data providers and data subscribers basically, right? Like demand and supply of data. And what's been interesting, one of the learnings for me is how similar it was.

Right?

At the end of the day, some of the core sort of the first principles around optimizing marketplaces holds no matter whether you're talking about consumers or customers or enterprises, where number one rule is like go after where the scarcity is, right? And be very careful not to get tricked into working on both sides of the marketplace. There's a lesson we learned the hard way in the early years of Scoop Commute, where we were trying to think about drivers and riders at the same time and liquidity and the balance of the two. In this case, when we think about Office Benchmarks, we are extremely focused on the supply side, right? Like the long-term value of Office Benchmarks comes from how much of that data we can compile because it allows for more functionality and more granularity and just overall greater capabilities in evaluating your own data against someone else's. And so that's been one learning is just like in some ways how well equipped we are to manage that marketplace aspect just because it's in our DNA. Now on the flip side, one of the learnings for us is very specific to our business. Taking a step back, when you think about data products, they tend to manifest in one of two ways. Either a company is collecting data through sort of systems at scale, like it's primary data, but it's coming from, I don't know, API aggregation or log aggregation or stitching together secondary data sources, or it's provided data, right? It's give to get, right? Those are kind of the two core models, right? I use the example of Well, the first one would be like definitely processing and the second one would be what we're doing, right? One of the things that's been interesting to me is what both makes a marketplace data product valuable and difficult is the fact that in most cases, the supply side of the market barely even knows how to get their data together for you in the first place. And so what's been, I guess, surprising to us or a learning for us is difficult it is for companies to even get the office data. Of their own data together in the first place, right? This goes back to my story of the folks who had the 70+ offices, but that's the case in almost every one of our conversations with like a Fortune 1000 company. And so as a result, a big part of the product strategy is how do we make it easier for them to collect their own data, right? Through first-party integrations and things like that. And so I don't think I expected that. You kind of think that folks will just sort of have your own business data available, and that is definitely not the case.

It's super interesting. What is the incentive for the supply side to share the data right now?

Well, right now, I would say it's twofold. I think in the, in the very near term, I think there's a lot of sort of altruistic demand. And what I mean by that is like, there's a lot of companies that are desperate for other competitors and other companies to provide benchmarks. And they are so interested in that, that they would like to provide their data as a way of accelerating the overall growth of the dataset, right? In some ways, one of the sense The not sensitive element to this is there's no instinctual upper hand in keeping your own data and not providing it to benchmarks, right? Because in most cases, while the data is critical, every company would tell you the competitive nature of this is how they make decisions based on that data. So there's not been a lot of resistance. Not a lot of people are concerned about sharing that data in an anonymized aggregated form, especially if it means that it'll help other companies do the same because there's more incentive and that flywheel starts going. Yeah. So that's really the biggest one is that they want that. They want the data themselves. Now, in the long term, there's also value in them sharing that data because of the immediate insight that we can provide to them, the tools that we can build around that. There's certainly, even from our early users, as they give us data, they want us to provide analytics and insights. We had one customer who was looking at the array of metrics around their own office portfolio, and even that was surprising to them in terms of how much of a range there was in like desk utilization and office capacity and things like that. So I think that difficulty in collecting the data often translates to frankly a lack of visibility into how their portfolio is performing. And so even our ability to say, hey, we're going to take your office data and give you some immediate insight even before we get to benchmarks has really profound value to them in just understanding what's going on in their own business.

Yeah, so interesting. I love the idea of like in a marketplace you attack where the scarcity exists. That's the place to spend your time. Otherwise you can, you can waste all your resources. Back to how you think about pricing and monetization for this product. It sounds like what you're saying, and correct me if I'm wrong, is Initially, we're selling a data product and then we will build tools that we can bundle in on top of the core data product offering. Do you think about the initial offering as like a one-time download or do you think about it as a subscription initially?

We think about the initial offering as a subscription because the data is live. And so our view is like we're, you know, in the last, even in the last, I think, 6 months, we've gone from 6,000 companies worth of data in our, in our just Flex policy database to over 10,000, right? We've gone from a handful of offices to hundreds and thousands and soon will be tens of thousands of offices, right, over time. And so for us, we think about that because this is a living, breathing dataset and they're going to want to be checking this every time they have a lease that's coming up or they're thinking about new space or maybe they've got a major human capital decision coming up. And so, you know, they're subscribing to get access to the evolutionary benchmarks, right, as opposed to like a dataset. Like they're not buying it a static dataset. We think about that as annual, right? Like, one of the things that we decided in building out this product is there's no real logical use case where this is like a monthly product. And the main reason we think about that is I think oftentimes SaaS businesses gravitate quickly to like monthly subscriptions and sort of this ongoing, but without thinking about usage patterns, right? One of the things that we understand about our, about Office Benchmarks, much like compensation data, is it's atypical. It's not a daily or weekly product necessarily. Like, I don't need to check my office data benchmarks every day. On a monthly basis, yes. On a quarterly basis, definitely. And then really, it's a milestone-driven business, right? It's, you know, I use competition again as an analog. In competition, it's performance reviews or compensation cycles or annual raises or whatever it is. And in our world, as I mentioned before, it's lease terms and new office space and global expansion. Where those events are going to happen and they're going to need to go to our dataset. And so the idea of subscribing yearly is this sort of consideration of like, they're going to want that data when they need that data, whether it's on a Tuesday in May or quarterly planning in October.

Right.

And so that's how we think about pricing it in terms of access. And as you said, as we evolve functionality, I think we'll have more pricing tiers. And frankly, why we're excited about what you're doing with Schematica, because it allows us to think about the different composition of what someone wants to buy. A good example of that would be something like a scenario planner. What happens if I, you know, one of the cool things we can probably do is actually provide scenario analysis based on policy changes. What happens if I require people to come into the office more? What would that do about predicted space utilization or number of desks I would need based on what we see in benchmark data? So there's this really powerful opportunity and something like that I think would command additional investment from a company if they're going to use that to do more powerful analysis. Analysis or decision-making.

Yeah, makes a ton of sense. What about like the actual price and the price metric? I mean, is this a seat-based model and that's sort of the metric of value, or is it— is there another metric? And I'm also interested in like how you think about sort of like different types of customers.

Yeah, you know, it's interesting. Those are things— and this actually probably goes to the fundamentals, my fundamental opinions on pricing in the first place— those are things that I think we are perpetually trying to learn and optimize, right? And I think you know this better than I do, but the real challenge behind pricing in any business, especially a business that's evolving in software like this, is what people want and how it should be priced changes, right? I think, you know, we, we certainly started with this idea of like really trying to keep things simple. I would say if there's anything we've learned over the years, it's that, um, in almost all cases, simplicity is the better answer when it comes to pricing. So we really started with just two flat prices where the idea is that you're paying for the dataset as a whole. Right? And that's the baseline is I want to pay for access to this dataset. And our job over time is to increase the core value of that dataset in terms of functionality around filters and different— and obviously the expanse of the dataset and continuing to sort of enrich that core product to earn that price or potentially greater price over time. The original and current sort of slice is between like one office and many offices. In reality, the value of that really skews toward many offices, right? That's where you're going to find value in what we're doing in the first place. And that's where I would say over time, I think we expect it to be more package-driven and more driven by like what types of features and capabilities you want. Now whether that becomes like a basic, advanced, and pro, or whether that actually just becomes a sort of à la carte, what are the different things you want to have access to, uh, it's a little early for me to tell. I think the biggest priority for us is building our billing system and infrastructure in a way where we can flex in any— no pun intended— in any direction we want to so that we don't get sort of backed into a corner.

Yeah, I'm curious to get your take on this. So I think many companies appreciate that pricing pricing and packaging is this like crucial lever, like it feels obvious at a conceptual level, but many companies struggle to establish really good practices around, to your point, how they evolve pricing and packaging as they learn from the market. And, and maybe kind of up until a certain point when they can afford to like build some muscle around pricing, maybe they hire a price analyst. So we're kind of largely talking about startups, Series C, D companies. I wonder if you think that's true. If it's not true, can you, can you say what's Talk about why that might be overstated.

I think my answer is maybe a little bit of both. I think, you know, my core, my experience here is that there's different archetypes of companies that, that kind of manifest in terms of their attitude toward pricing and packaging. I think a lot of it, I might be taking a step too far here, but I think a lot of it goes to what type of founder they are and what their background and discipline is, right? Like in my experience, more technical founders tend to undervalue pricing. They tend to think that pricing is a price and not a construct. I think that the other main archetype is the folks who are a little more familiar with pricing or have oftentimes been buyers of things. And as a result, they think like their historical buying persona as opposed to their prospective buying persona, and they overcommit to a certain direction. So there's this sort of like underappreciation category and this sort of like overconfidence category. When in reality, like, the only thing I think I believe to be true is that flexibility and evolution are the only things that are certain when it comes to pricing and pricing mechanics, right? And I think almost every stage of business, the natural sort of trap to fall into is to think about pricing as about price. And I know that sounds a little like cheeky, but like the dollar figure is often not even one of the two, three most important things, as opposed to understanding— I, I mean, for me, most important is almost always meter, right? Like, what is the thing you're pricing against? What is the incentive? Like, where does value get derived? Um, and there's real exercises that companies need to go through. And I've seen small companies that do this well, and I've seen large companies that do it poorly. So it's not necessarily, in my experience, correlated to size and stage of companies so much as like understanding of, of the market and the power of pricing if done right.

So we both very much agree that maybe the only thing that is for sure is that pricing and packaging will change, assuming a business is successful. And in the real world, that ends up being actually difficult to support for a lot of businesses. And I'm curious to kind of understand like why you think that is the case.

Yeah. Yeah. It's a, it's a great question and a heavy topic. I think, you know, what's ironic is if you break this down and you think about the nature of go-to-market or sales orgs in most companies and how they evolve through the stages of company development and scale. And the same with product. It really doesn't make any sense that people then treat pricing as a sort of static thing that they're not either— they're not prepared for or don't expect to change as much as other things. And I'm going to go into that in a second. And then the second piece is just the pure, like, technical infrastructure behind pricing, which I'll come to. And so like to use me to use an analogy, it's like I have 3 kids and I think about it as like it's almost like buying a house and furnishing their kids' rooms and then buying a single size bed and just expecting that that bed will last forever. It's like, you know, the kids are going to change in size. You know, the things they're going to want to put in the room are going to change. Maybe the house wouldn't change, but it's like being like, oh yeah, but the twin bed will always work. It's like, well, no, at some point a twin bed's not going to work, right? You're going to have a bigger kid with a bigger space. And I think a lot of the time startups and even business units think about pricing as like, oh, we're just going to commit get to this twin bed, right? And even if we decorate the room, my kid gets older. And so, so what does that mean? And, you know, to step away from the analogy for a minute, well, as a product builder, first and foremost, um, most certain thing I know about product is that like you're constantly building and refining and building and refining, right? You're building something, getting reaction from your users, taking that insight to build something better, constantly driving at exploring more product market fit or how to drive greater value. That's a moving target, and pricing was meant to be the the amount that a person is willing to spend to derive that value, right? It's an implied ROI calculation. So the idea that pricing is static while your product is changing, pretty illogical when you think about it, right? Same thing, you can go through the exact same exercise on the go-to-market side, right? It's like, I'm gonna go out to market and over time my job as a company, a startup, an organizational unit is to figure out how to better present, position, evolve the product that I am selling so that I can help speak the language of my customer and get them to understand and be interested in the value that I can provide them with my products. As you get better and better and better at that, the idea that your pricing is going to stay the same or, you know, let me take a detour here. When we talk about pricing staying the same, there's a difference between the price changing and the pricing mechanic changing. Plenty of companies will say, now this is a better product, so we're gonna charge $5,000 instead of $3,000.

$10,000.

But that's not what I'm talking about. I'm talking about the nature in which a person or a company wants to buy a thing, how they think about spending it, how they think about calculating value and ROI. And so while the product evolves or the go-to-market motion evolves, we stick with the same pricing mechanic. What exacerbates that problem, in my experience, is the technical side of things where unequivocally, and I have now built I think 6 of them, billing systems are without a doubt the single worst technical thing to build. They are the most complicated.

They are often the most under-resourced when first conceived of.

And for whatever reason, working on billing sucks. And I have said this at Scoop since we started it 10 years ago. That comes from a guy I used to work with at Google, Brett Slatkin, who's, you know, kind of a prolific engineer at Google. And we used to talk on our team all the time around how like billing was the worst thing to work on. It's a combination of overcommitting to certain constructs and how much logic is built into it and all these other things, right? And then modern software stacks, it's often where you're heavily integrated. And so as a result, you've kind of built a certain integration pattern. And so all that is to say the product and the sales motion evolve, and then you have this inertia where changing the billing mechanism is hard because you didn't plan for that. And as a result, you say, okay, I guess we'll change the price, right? Or worse, you wake up one day and you're like, well, fuck, excuse me, sorry, we need to do a rebuild. Like we need to go spend the next year rebuilding our billing system or migrating our billing system. And anyone who's ever touched that stuff knows that that's like death to a company. Money, right? In terms of just like productivity.

I love the kid analogy because I have little kids, you know, and maybe because I think what you were kind of doing is you were dividing that answer into kind of two main parts. One is this idea that it is illogical as a product evolves, as a go-to-market evolves, for pricing to not evolve. And then it's hard for it to evolve because of systems problems, billing architectures, things like that. So I want to kind of look at both. And on the first point, I'm really curious to understand what you have personally learned about aligning a product roadmap with pricing and packaging initiatives or a pricing and packaging roadmap. What have you learned about that alignment? It's important, it's best practices, it's maybe mistakes, as you mentioned. What have you learned on that front?

Yeah, it's a great question. So, you know, I'll start with ironically what is sort of a non-technical learning or priority, which I think then manifests in a technical nature. And I mentioned this a little bit before, but number one most important thing to me, thing that I learned the hardest way possible, is that complexity is your enemy when it comes to pricing. And I think that is a— that feels very unnatural to most founders and product builders. Again, when I say that, it could also be like the leader of an organization, leading a massive company, because they have such a in-depth understanding of the problem they're trying to solve that they assume that the complexity they think with in solving the problem should manifest in the way the pricing is. And what's funny is oftentimes that leads to more elegantly conceived pricing, right? It is. I'll give you an example from my own experience. When we were doing— when we built Scoot, one of the first things we did was build a pricing engine, Scoot Commute. And one of the things for us is we really believed in a few things. We felt pricing in the car between rider and driver was going to be huge for market management. That turned out to be true, that pricing really needed to be tied to geography and mileage and cost consideration, et cetera. And then we were going to want to do that at a really granular level. The mistake we made is we took those hypotheses, hypotheses, and built them into the core of the platform. So we built this like complicated, super granular pricing mechanic that we basically every year for 6 years into COVID were like, should we rebuild this? Like, when are we going to redo it? And we just kept building against it and building against it and building against it. And then it at scale, it just destroyed us, right? Like, when we got to new markets, it would just— we'd have, I mean, thousands— this is not even exaggeration— thousands or tens of thousands of core units of pricing in terms of, like, geographic hashes with amount of pricing and mileage. And it just became incredibly unwieldy to the point where, until we sold off that business last month, still a problem, still a challenge. And it's probably— when I— when we sold it off, I told the acquirer, this is, like, one of the first things I would probably try to change before you try do anything else with the business. And so the mistake there being we understood the problem to be complex, but we allowed the belief that we might want to optimize things later to get built into the core product, as opposed leaving space to move toward those optimizations over time, right? Which goes to my second piece, which is as we build out Plex, the thing we've tried to do differently is not committing to anything rigid wherever humanly possible. And being able to really say, what do we think we might want to do in the future? And not how do we do that now, but how do we give ourselves clear path to evolve in that direction should we want to? If we want to change price or mechanic or billing unit or what have you, and trying our best not to back ourselves into a corner so that we have the ability to change price really quickly.

Let's go to the infrastructure and architecture part of this. Somebody recently said to me, and I thought it was really great, price is a number, pricing is an architecture. And I'd love to hear you talk about like what is— maybe there are kind of two threads here, but you mentioned you've built billing systems. I'm curious like why you built billing systems because there are billing systems that you can buy. Often people buy billing systems and set them up in a way that makes them very rigid. And so I'm curious, like, what is it about the billing side of this architectural equation that is so challenging for SaaS companies in your experience? And secondly, if you can extrapolate on it, what is the architecture that most companies should kind of try to have a picture of when they're thinking about pricing and thinking about being able to support flexibility in the long term without a ton of premature optimization too early?

Yeah, I mean, you know, when it first— the thing when I talk about building billing systems, um, that looked a little bit different when I was at Google. 13 years ago building that system because that was sort of one, it was within Google. So you weren't using a lot of third-party services and it was either free or right at the beginning of Stripe and online payments. And I mean, that infrastructure is totally different now. And if I think about it in today's world, when I think about, when I use the word billing systems and I don't know if this is a norm or not, I just think about, I'm just thinking about logic, business logic, right? Like the foundation for me of like the technical infrastructure of billing is How do I keep track of something that happened? Or how do I keep track of a purchase of something to then provision what they're going to see? Like, where do I decide where sort of like money spent equals some type of behavior or usage or mechanic, right? And the challenge, of course, is that in most cases, at least until the last couple of years, every business has its own logic of what it's trying to do. This is also where the complexity gets you, because as you think about more complex utilization of your product that manifests in more complex complex business logic underlying the pricing, which then leads to more complex pricing and deeper infrastructural commitment. And the problem kind of compounds on itself. And so for me, when I say about building billing systems, I'm talking about things like what I talked about before, which is like, did we use Stripe to charge riders when they took car pools? Yes, that was easy. We ran their credit card, but we had to calculate how many miles and what was the price per trip and how many trips for, like, keep the ledger. So to speak, in that particular case. When we charged later on, when we built an enterprise billing model against Komoot, we needed to figure out how much does a trip cost you and how do we have decreasing price per trip tiers as more trips happen? How do we calculate that? And we had complex systems to roll up the number of trips per month and the rate table. And then to make matters worse, we started selling custom rate tables. And right now you're keeping track of rate tables. And so all of a sudden you're adding variation and complexity where it sounded like a great idea at first, but as you keep going, it gets worse. But now you're— now you have some costs, right? And so again, to maintain that flexibility, it's very similar to what I said before, which is like, you gotta stay simple because every increased complexity and how you want to price is going to translate into increased complexity in your system, period. Like, that is going to happen no matter what you try to do, right? Those things domino into each other. And then two is going out of your way to talk about how you might want to change pricing in the future and try to look ahead at the variations you might want to have, really try not to build in a way that would make doing that very difficult, right? And giving yourself that flexibility and freedom and having a little bit more like MVP-type attitude toward your pricing, knowing that if you put out a pricing model or pricing mechanic version 1 and it doesn't do great or you underprice or you can change things, it's better to evolve that as you learn than it is to overcommit to something you won't be able to walk back.

What is the role of entitlements in this kind of architecture that supports subscription monetization in SaaS?

Yeah, I mean, I think when I think about entitlements and pricing, I think about two things, and one is more closely related to, I think, how you're intending the question. The first is something my brother says often. If there's anyone, frankly, who knows anything about pricing, it's him. And he's my co-founder and our CEO. He comes from a management consulting background, has real experience in pricing strategy, and that's benefited us in spite of our own challenges over time. Um, and that is that benefits become entitlements really, really quick. And that is, once someone thinks that paying X gets them Y, they're really not so open-minded to paying different than X to get Y. And that just continues to compound this challenge of legacy. Like, everyone who's worked on any SaaS ever knows that they, if they did change pricing or pricing mechanic, they also had to deal with some type of legacy pricing issue, right? Where every time you're overhauling your pricing, you're having to migrate your customers and so on. When I think about where we are today, building a more sort of straightforward SaaS product in the sense of like you pay X to get Y software, we certainly think a lot around entitlements in the way that I think you mean them, which is, well, what are they paying and what do they get? What is historically very difficult about that from my standpoint is there's this desire or pressure to just sort of have packages, but packages are static. And so again, the theme of what I've shared here is like dynamism is good and static is bad. And so if you say, okay, I've got package A, B, and C, and then all of a sudden you don't really want a feature to be in package B, or a feature, a new feature comes out and you gotta fit it into a package. Or let's talk about AI, right? Like all of a sudden you add an AI feature and AI has a totally different cost structure and you're like, well, I had to use, I don't know, variable cost I have a cost rate that's much higher on this feature and I got to put it in package B or C, that's really challenging, right? And what you guys are working on, and frankly, I think the evolution of this space is how do you have more flexibility and sort of building the packages without it being complicated, right? And so this is where the tension becomes around how do you have more variability and more flexibility but without a billing system that becomes unwieldy.

I'd love to get your kind of point of view on the role product maybe should have as it relates to monetization and software.

Yeah, look, I think in most organizations, irrespective of even getting— before we even get to pricing, I think the relationship between the go-to-market and product teams is often probably the most tense or frayed or challenging in terms of this idea of being on two different teams and working usually in two different directions. And so Obviously that's going to manifest where it happens in pricing, where my opinion is I actually don't think it matters how much of it sits in product or go-to-market or a strategy team. Good reason for it to be 70/30, 30/70, 50/50. It doesn't really matter in so much as the two work in harmony. Like this really goes back to at the end of the day, the goal of product and go-to-market is to communicate value and earn what someone is willing to pay for it. The pricing and pricing mechanic is a way of making it easy for a customer to understand what value they get for what they're going to spend. It goes back to like more complexity just means it's harder to understand what you're spending money on. Go-to-market has to understand a lot of the positioning elements of that, like how is pricing interpreted? How is it reacted to? How does the buyer think about what value is or who they need to communicate it to in the approval process, the logistics, whereas product is meant to understand how to augment the ROI calculation of, okay, well, what are they getting and how do we build to support that? And those things have to happen in symbiosis, right? So like, to go back to a different analogy, this is very, very similar to like front and back of the house in a restaurant, right? And even if you've never worked in a restaurant, if you've watched The Bear or any show, right? Or, you know, Restaurant Wars and Top Chef, you know that there is this relationship between the food being made in the back and how it is presented in the front. Right. And to go back to my point around, it doesn't really matter who owns the pricing decisions as long as they are in harmony in terms of understanding all the inputs. The example of that is like you may go to a fancy restaurant and they build a fancy dish, but then they have the server pour out the broth into your dish, right? Or you may go somewhere else and all the server's meant to do is put down the hot soup on your plate, right? It doesn't matter. Both can work, both can taste well. They may have different flair and feel. It depends with what the customer is looking for, right? Pouring the broth in front of the person might make it feel like you have an experience that earns a higher price for the quality of that food versus like, I'm just trying to order some soup at a ramen restaurant. Like, just put it down in front of me. This is like a more utility-driven experience for me. I'm paying X, I want my ramen, let's move on. All that matters is if you have the front and back of the house moving past each other, you're going to fail, right? If you don't pour the soup the right way, that's going to defeat the purpose of the exposition of value in the way that the customer is interpreting it, right? If you make the ramen entirely in the back and it tastes bad and and then you give it to the server just to throw it down, you're not gonna earn the price even for that ramen. And so the answer is like, it takes a little bit of humility. I mean, I think one thing we probably haven't talked enough about directly is pricing really, really requires an extreme amount of humility around your product and what you are buying, I mean, what you are building and what people are buying. Because it is the ultimate pressure point of you need to be listening to your customer and understanding how they perceive something. And the irony is, and maybe I'll close on this, is like one of the most salient things I've heard about pricing comes from a guy named Zach Weinberg, who's a real successful entrepreneur out of New York. And his thing is he thinks that most startups, especially like chronically underpriced from a dollars perspective. And what's funny is our lack of humility and asserting what we think pricing should look like from a mechanic and approach and complexity perspective actually tends to lead us to not actually price products at the premium that they deserve because we haven't stopped to really understand how the customer thinks about ROI and how we deliver it. It's a double whammy, right? You make it harder to buy and then you don't sell it for as much because you've, you've overcomplicated the situation or you've underappreciated the input of your customer.

Yeah, it's really good. One of the, one of the questions I like to kind of end on, one of the two, is when you zoom out and think about the next 10 years building products, building software, what are the big changes in the world that attract your personal curiosity?

I'm really excited by the way companies like Schematic and another company we work closely with, Orb, are thinking about building the billing stack in a way that goes beyond just like card processing or ledgers, but really allows companies to have the flexibility. I'm hopeful that by having more technical flexibility and less sunk costs, companies will be able to get smarter around the way that they price because the technical overhead won't be there in the same way. Opens the door to a whole other universe, which I'm sure you think about a lot, which is how bookkeeping and accounting and finance and FP&A are handled. I think that space has a lot of need, right? There's very few people, I'm not gonna call out specific software, but there's very few people who aren't really frustrated about the software they have for managing bookkeeping and accounting or the software that they've migrated to or need to migrate to. So that's definitely something I have my eye on in terms of of what's going to happen there. Like, is it really going to sustain over the next decade that everyone's just going to keep hating their accounting and bookkeeping and finance infrastructure? Because that's something about that feels broken. And so I think I'm just excited overall at how much the technical and intent evolution of pricing will bring us back to just delivering good value, right? Like as a product person, all I think about is like, how do you deliver value to a user? And I think there's an opportunity for the friction that's created through pricing to be reduced, which for me means you just have a more direct line to get better value to your user.

This was an incredibly instructive and useful conversation for a lot of product people, a lot of engineering leaders, a lot of founders. One last question is what's been the specific experience that was most formative for you professionally?

That's a great question. I think, you know, ironically, with all of the pain that came from it, I think what we've gone— what we went through at Scoop in terms of having the business kind of run off a cliff unexpectedly and out of our control. And having to navigate evolving the company, downsizing the company, regrowing, building a new market is, I think, the result of that is I think I'm a much, much more capable operator than I was before. And I think there's a little bit of that sort of forged in fire nature of it. As hard as it was and is to think back on, I think I'm a better manager. I think I'm a better operator. I think I'm a more shrewd startup thinker or product builder. And I remain optimistic I think that that has and will continue to provide value for me as I think about, you know, next eras of my career, which means that in turn, maybe, maybe all that we went through will end up having its silver lining and its positives, which I think it already has shown. So that's definitely for me the most formative and sort of meaningful professional experience.

Where can people learn more about Scoop and reach out to you if they've got questions about product and building companies?

Yeah, you can find me on LinkedIn. I'm John Sayedow. That's probably where I'm most communicative. I don't do a ton on Twitter. Scoop is at scoopforwork.com or check out the Flex+ index at flexindex.com. And those are, those are definitely our homes.

Such a pleasure, John. Thank you so much.

Awesome, man. Thanks, Ben.