Rippling CEO Parker Conrad's Theory of the Compound Startup: Disrupting How We Think About Software

One of my favorite Parker stories is, uh, I joined in late 2013, so my first full year was 2014. And about a quarter in, we were shooting for a revenue target of $10 million by the end of the year. We started at something like half a million dollars of ARR. We were going for $10 million. And one quarter in, Parker sat down, myself and the head of marketing at the time, so the go-to-market team. He was like, all right, nobody panic. but I just want to do a quick thought exercise of what it would look like if we switched the goal to $20 million in ARR this year. So we're gonna double it, but just like throw stuff up against the wall, see what sticks. And so we went through this, what started as a thought exercise, and I think within 24 or 48 hours we changed the revenue target to $20 million in ARR. And so one thing that was just super motivating for me, having Parker as a leader, was that type of push and motivation, and I know that was happening within the go-to-market organization alongside all of the different departments that reported into Parker. This just sort of like, how can we be better? How can we move faster? How can we deliver more? With that, Parker's gonna be talking about the first rule you know about building software is wrong, his theory around the compound startup. Parker's probably the best person in the world to deliver this talk, now being the founder of two compound startups. Each valued at several billion dollars. So Parker, come on up, and I'll join you momentarily for the fireside chat.

If there's one rule that almost everyone universally agrees with about building software, it's that focus is really important. So two of my favorite Silicon Valley characters here are Bill Gurley and David Iwas only CEO of that company for a very brief period of time, Saks. Both, both agree that focus is really, really critical. And even sort of way beyond that, you know, this is sort of a consistent truism, very strong conventional wisdom that focus is really important and you want to narrow what you're doing so that you can go really deep. And I think that this conventional wisdom is wrong, or at least extremely limiting. And there exist a set of companies that could be built that are often not built that break this rule. And so there are a few things that, that are problematic with this. One is that it sort of limits you to problems that are contained within one sort of vertical or one sort of type of business system. And a lot of the deepest problems that we face as companies are problems about, you know, collaboration across the business, how different, different systems interface with one another. That that sort of strategy of narrowing what you do doesn't really lend itself to solving those kinds of problems. It's also been picked over. Like at this point, like, you know, 15 years ago, you could start a SaaS company in any vertical and you'd be the first one and it would probably be pretty successful. But now like every, every space has got 2 or 3 things in it. And so the focus narrow point solution approach there's not a lot of opportunity left. And then you get to this issue where like, how do you, how do you go to product number 2 if everything about your company is oriented around just having one product in it? And so the alternative here is something that I call a compound startup, which is a company that is building multiple products in parallel that are deeply integrated and seamlessly interoperable with one another. And I think there are a few advantages of this. One is that the area is relatively unexplored. There are a lot of places where, because the conventional wisdom is so strong in the idea that you shouldn't do this, there are these undiscovered islands of product market fit that are sort of just beyond the horizon line, that if you can sail out and sort of make it there, everything else about your company will work. There are some critical advantages from a product perspective of building a compound startup. I think it's obvious and very well understood what the product advantages are of building a really focused, narrow point solution. The product advantages of building a compound startup, there are really, really 5. The first is that most compound startups, the products are much more deeply integrated with one another. The second is they're usually really deeply integrated with some underlying system of record. So in Rippling's case, that would be employee data. There are a bunch of ways in our product that employee data allows for many new product capabilities. There's a lot of functionality that's unlocked because all of our products are deeply integrated with employee data. You get to abstract out a lot of stuff. You can find elements of your product or elements of these products that end up being repeated, you can build them once and then build them really well, go really deep on these concepts. So at Rippling, these are things like reports, reports and analytics, workflow automations, role-based permissions, custom policies. There are a few others. And like on those things, on these critical pieces that end up being used across every single product that we build, what we can do is we can go 100 times deeper on those capabilities than any of our competitors can afford to go. And so whenever we're going up against a point solution competitor that only builds in one area, we know that we're going to win in those areas. We're going to have better permissions, we're going to have more sophisticated analytics capabilities, etc., etc. You also, for clients, You get a shared UX, which means that your clients already know how to use your product. So when they buy the next thing, if they buy it from you, they already have superpowers in your system that don't exist for them if they buy the standalone system. So one great example of this that you see is with Salesforce. Anyone that's in sales operations, the next product that they build, that they buy, whether it's like CPQ, or any of the other SKUs that Salesforce sells, people in sales ops who use Salesforce are going to want to buy that next product from Salesforce because they're going to already going to know how to use it. And then lastly, you have this pricing advantage, which is that compound products can optimize pricing over the entire bundle of SKUs, and they don't have to make it all back on one specific product. And that allows you to run circles around competitors from a pricing perspective in a lot of cases. You see this like Microsoft is the classic example of a competitor that uses this to great effect. That's why Slack is owned by Salesforce now, because like Teams is free in the Microsoft bundle. And the knock on this is always, well, how do you, you know, if you build a lot of things, how can you be good at any one of them? Aren't you gonna end up building superficial versions of each of these products? And the answer is like, that doesn't work. And so the challenge of a compound startup is that you need to be good at parallel execution across all of these different products, because you're never, you're only as strong as your weakest link. And so if you have one crappy product, and a customer is buying 7 things from you, and 6 of them work great, and one of them they're dissatisfied with, they're going to churn. And so you can't afford to build something bad. And that's hard for sure. That makes execution very challenging. So I want to talk a little bit of an example. Rippling is launching this week into the UK market. So we're now offering our full system, payroll, HRIS, all of our different products. In the UK to UK companies. And the UK market is actually a really great example, in my view, of what happens when competitors and companies get too focused, which is that if you look at the way companies run payroll in the UK, there are— payroll ends up being sort of like a hash function of all of the changes in your company since the last time you ran payroll. Like almost anything happens in a company And like you, then it has some implication for payroll. And so when companies are managing all of this in all these different systems, it ends up getting really difficult to do this. And so companies today in the UK, some will have an HR system, but sometimes we're doing stuff out of spreadsheets and sometimes, you know, they'll usually have a payroll system, but then pensions and hours and annual leave is all managed often in separate systems and then You got to sort of upload a file to your bank at the end and get your employees paid. And anything can go wrong at any point between any of these systems, which makes it a tremendous amount of work. And so what does that look like? Well, there are a bunch of disadvantages to managing this stuff in spreadsheets, obviously. But then once you get stuff over into payroll, you've got to deal with all of the change management in the payroll system as well as in HRIS. All kinds of stuff can go wrong. My favorite example of this is with annual leave. When people go on annual leave, you've got to pay them out at an hourly rate that's based on the historical average rate that they've had over the last year based on net of overtime and things like that, which means that whatever system you're using to track leave has got to be aware of overtime and what you paid out over the last year. And then that's got to flow into payroll. And then you've got to, like, deal with this, like, bank file. And there's a whole bunch of challenges with that. And the alternative to this is you have one system that just kind of does all of this together. And that's effectively what, what Rippling is and what we do. And by the way, one really interesting proof point on this is Rippling is a 2,000-person company. I am the only admin for our system in Rippling. So I personally run payroll for our 2,000-person company across about a dozen different countries around the world, natively in Rippling. And I do that, you know, as a part-time job. And in the UK market, we did a sort of a quick study recently and found that a lot of even like SMB companies in the UK, someone spends 5 or 6 days a month just dealing with payroll. And so it's an enormous amount of work that can be just dramatically compressed when you take this sort of compound all-in-one approach to the problem. And it also helps, you know, you really see this in stark relief with new joiners. When you have new joiners in your company, because everything's managed in one place, everything happens in one place. You click this button, says you want to hire someone, we send out employment agreements, we collect all of their details, we get them, enrolled in all the right systems, and, and it takes you 90 seconds and then they're ready to go. And a lot of you will see, if you don't see the pain viscerally of managing all these different systems in separate places, you probably see it when you hire someone because that's when you see all of this all at once. And actually, Rippling, interestingly, our broader product is much more than just what you think of as traditional HR and payroll software. And so this idea of a compound startup and focusing on employee data and everywhere that employee data lives within your company has ended up bringing us into a bunch of other areas. And so right now, Rippling has actually 3 separate clouds. We have our HR cloud, our IT cloud, and our finance cloud. And so when you click that button to hire someone, we don't just manage everything related to HR and payroll. We also set them up in all of your different apps, Slack, Dropbox, GitHub, email, Salesforce, and so on, and get them their new computer and ship that out and manage it for you going forward. And then we also separately have our finance cloud where we manage expense reimbursements, bill pay, corporate cards, things like that. And so, and everything sort of then, you know, operates seamlessly. And then beyond that, companies end up— this problem gets multiplied by country. So most businesses are a lot more remote or a lot more distributed than they used to be. And I'm sure many of your companies are hiring people outside of just the UK. And so you end up replicating separate stacks of software to do this in the UK where maybe you're using Sage, and then in France where maybe you're using Silae, and in Germany where you might have a system like DATEV and a whole bunch of other associated systems around it. And the nice thing about Rippling is we've actually built sort of global payroll, global HRIS, all of these capabilities into one sort of native system. So that you sort of combine all that into one. So to sort of summarize here, like if you're, if you're thinking about building a compound startup, the most important thing to start with is like that the integration is the product. You want to build in a space where there are problems because of disconnected systems or business process, and that you have these advantages where if you combine everything, you can unlock a lot of new product capabilities. Really simplify things for the user and find areas where you can, you can pull out functionality that you build once because you end up like so many companies end up— how many, you know, probably a zillion companies in the audience here have all had to build some version of reports and analytics for customers of different permissions or workflow automations or things like that. So if you can find those things that you can pull out, you get these incredible efficiencies for product development. You wanna, you wanna try and find ways to help customers save money, where you can charge more overall, but per product, they're saving money because they're sourcing multiple SKUs through you. And then there are a lot of organizational challenges where you've gotta often organize the company into business units with sort of strong entrepreneurial leads that can run individual products relatively independently to sort of parallelize execution. Execution. So thank you. I'm going to— Sam's going to step up and join me now. Sam and I actually were on stage for the very first SaaStr with Jason, I think like 10 years ago now. It was really cool. I have very fond memories. And so it's good to be back. Good to be back here.

Round 2.

Yeah, round 2.

Awesome job.

Thank you.

So I'll probably comment this from the go-to-market lens, given my background. So lots of questions sort of stemming from potential customer, growing revenue, those sorts of things. From the customer standpoint, 2 slides ago you talked about International Payroll, which is just one of the SKUs that you offer. If I'm a customer and there are big companies that have been built in that specific category and probably multiple categories where you are offering SKUs, And so if I'm a customer, I need international payroll, what are the advantages or why would I go with a company like Rippling where I'm one of 22 SKUs that you're focused on versus a point solution that's potentially a big company, a Deal, a Remote, something like that, that is more of a point solution that already exists in this space?

It's a good question. I think it, it's actually because of the ways that we can simplify the problem for you by being a compound company. And in fact, many of the problems with those systems relate to this central original sin that they have, which is that companies like, like Deel and like Remote actually have not built underlying global payroll or payroll really of any kind. And so those companies are sort of secretly running on other payroll systems country by country. You know, I think, you know, Diel uses Silae in France and probably Sage in the UK and Hume at one point in Canada. Diel was actually until very recently a Rippling customer in the United States. They ran, you know, in fact, their global HR on Rippling because they didn't have all of these other systems in place. And so the problems that you have as a company, if you're using one of them, is first, that it's a very poor foundation to build on from a product perspective, because what they're doing is every time you submit payments in, you know, Deal or Remote or one of those systems, there's this army of ops people that are like loading it into all of these other systems around the world and then like running payroll and then getting the data back to you. And that's why you have to run payroll like, you know, 15 days in advance or 30 days in advance or however long it is right now. And of course, that comes with a lot of problems. Stuff goes wrong, it's a pain in the butt. And you also, you don't have the depth of systems that you need to run your business in those countries. You don't have full HRIS, full compliance, full time-off tracking, all of these other things that sort of surround payroll. And so if you want to run a report and be like, well, how much did I spend on engineering last month? There's no place to do that because you've got, you know, one place for your employees in this country and another system for your employees in that country. Or, you know, maybe you overlay it with a completely separate HR system that actually, like, is never up to date because actually it's not connected up to the system you're using to pay your employees. And so you run into the problem of having disconnected systems when you use these focus point solutions, and that causes an enormous amount of administrative pain. Paid within your company.

That makes sense. This, this has been a bit of an evolution for you. Um, I, I think, you know, many years ago you were co-founder at SigFig, which was, uh, probably a point solution. Um, and then you were founder and CEO at Zenefits, which was, it was more compound startup. And now you're Rippling, which is sort of like the ultimate compound startup. So you've probably learned a lot as it pertains to point solution compared to compound startup throughout this evolution. What are some things that you've learned, just generally speaking, maybe that you wish you had known back in the days of Sigfig, back in the days of Zenefits, that you know now?

You know, the biggest thing is I think even when I started Rippling, the— you know, I hadn't started using this word compound startup, but we were we were always kind of a little bit apologetic about sort of how much we were doing. Like, there was always, there was this deep conviction that this was what needed to happen, that the market, this is what the market needed, and customers didn't just want all-in-one, they wanted the all-est in one-est, and that was the way to win. But when we would talk with investors, you know, one of the questions you get from investors is always like, if this doesn't work, why does it work? Why won't it work, or what's the, you know, if you, you know, why are you gonna lose? And for us, it was always like, well, you know, it's this thing, like the knock on us is that, you know, maybe we're doing too much, and like we've gotta overcome the fact that our strategy is very specifically and purposefully taking on all of these things in parallel. And actually, like what I realized over the course of doing Rippling is that like, Everything that's great about the company, like all of the company's biggest strengths come from this. Like it ended up, ended up being like the source of our greatest enduring advantage. It's why the company has really unusual growth persistence, you know, like highly anomalous in terms of how much our growth rates have persisted year over year. Really high NDRs. We have like a lot of companies This year we went from our customers hiring tons of people and getting tons of free seats because they just are constantly adding new employees in the system to a 10% drop in our, you know, annual NDR cohorts from a seat basis. But our NDR stayed at like 130%. And the reason is, is because, you know, those cohorts buy so many new products because of the cross-sell motion that we have. That, you know, our NDR stays extremely high. And again, that's all a function of like our whole compound approach and the different products that we have. You know, the cross-sell business at Rippling is, you know, now over $5 million in net new a month, you know, even before you get to like new logo sales. And so like really all of like the things that make our business really incredible come from this this thing that started out as something that, you know, we were kind of like, like, I know this is like not what companies are supposed to do, you know, sorry, but, you know, and that, that, that was sort of a confidence that developed over time.

And you were, when you said that you didn't, I don't know, I think you said, I didn't know the term compound startup when I, when I started Rippling or used that term, but I think you knew that you wanted to be not a point solution. Wanted to be all-in-one.

And conviction, that was, that was the thing that I walked away from Zenefits with, was like that, you know, when, you know, when Zenefits was really working, it was that you had, you could click this button to hire an employee and they would show up automagically across all of your HR systems, in Zenefits' case. And, and, and we just had like this, this strong belief that people wanted that button, but they wanted it to work for everything across their business.

And I talk to companies regularly from sort of the investor seat that they are starting as a point solution with aspirations to evolve into what we're talking about as a compound startup. But they may just call it like a multi-product offering. This happens pretty regularly in the revenue stack where I get pitched. And it's like, you know, we're going to start with— let's just take like a Gong-like version that's a bit of a point solution. And then they want to transcend and become, you know, take over Salesforce, take over a lot of the other, uh, uh, RevStack solutions. For like knowing what you know now, and maybe for folks in the audience that are founders of a, a, a company that is a point solution, how would you think about like adapting from being a point solution into a compound startup? Is it possible to do that after day one? Just what comes to mind?

It's really hard. I mean, there are sort of two sets of problems. One is there are so— and the answer is like, I'm not sure that you really can. I think you kind of have to almost like refound the company, or sort of like rewind and reverse and start over, and go in this different direction. Tactically, the reason that big businesses— it's so hard hard for them to launch like a second product is there's so many built-in assumptions that they have around there being a single product. You have everything from just like the way your Salesforce instance is set up to the way your sales team is compensated to all of your, the way all your training works to, you know, how your product marketing and your product teams are aligned. It's very hard to just suddenly have like two things where there was one before. Before, but the bigger thing is almost by definition, compound startups are solving different problems than point solution products. If you take the example with Gong, I mean, I don't know the company super well, and I'm speaking off the top of my head, but if you start with this thing that you're solving this problem around call recording transcription, and sort of like insights about, for management about how reps are doing, and now you want to take on Salesforce, you've kind of got to step back and be like, well, what we're now solving is this problem, this like business process problem on like, how do you put your customer-facing teams on rails to sort of deliver a consistent experience to customers? And like one part of that may be like the call recording experience. And it might be that a company that actually started out that was like, hey, we're going to do the compound startup for the sales stack and do, I don't know, something like CRM, but also call recording and lead routing and calendaring like Chili Piper and Calendly and like a whole, you know, and did that all together, like, mm, like maybe, yeah, I can see how that would be way simpler for a lot of go-to-market teams to not have to deal with all this crap in different systems because for whatever reason, Salesforce has never gotten around to sort of rolling up their ecosystem. But you kind of have to start from that, I think. It's very hard to like, you know, pivot from one of those things into like the full suite.

Let's talk about product launches. There were a couple questions earlier in my session about launching new products. From your perspective, I think you've done this, how many SKUs do you have?

It's like probably about two dozen now.

OK, so 24 different products that you've launched. You've probably launched them with varying degrees of success and fanfare. Any takeaways in terms of things that have gone well with launching a product versus lessons on the flip side?

I mean, I generally think that product launches are something that we're not very good at. We're generally not great at PR and tend to not be really seeking the limelight from a press perspective. What I think has gone well for us with launches is focusing on what comes after the launch and just getting through the launch. Because the launches, you get this thing where you get— a lot of attention for like 48 hours. Sometimes it lasts for like 2 or 3 weeks, and then it's kind of crickets. And so what we've done, I think, reasonably well is building out everything that happens after the launch. And so for us, that means building out a cross-sell motion for a product. And the cross-sell motion is both about having an account management organization. I mean, there are actually a couple of elements to it for us. One is an account management organization that is focused on selling, you know, new SKUs to existing customers. They obviously do a lot with customer success, but unlike a lot of customer success organizations, I mean, they're a real sales organization that's quoted and that is able to make customers successful and solve their problems by bringing them like Rippling solutions. Another piece of it that I think is actually really interesting is what we found is that in a lot of cases, this is about building standalone sales organizations. So a lot of our products, like our global team, has a standalone sales organization. Our Finance Cloud has a standalone sales organization. Some of our upcoming product launches, you know, like our ATS product that's coming soon is going to have a standalone sales organization. And then the third that's really interesting is we have an internal, effectively like an in-house system that is effectively like an ad system that we use internally that basically individual product teams can place ads and promotions inside of our product. And we have a lot of, I hate myself for using the term AI, machine learning because your valuation just went up. I value— yeah, but we have like some AI, you know, there's like, you know, sort of assessing like for this specific customer and this specific contact at that particular customer at this moment in time, which, you know, all of the sort of individual creatives are competing with each other and the sort of machine learning system is making a decision about sort of what to optimize for and what to show the customer. and what are they most likely to convert on? And that's what then drives a lot of leads across to the account management team. And so getting those pieces right, like the internal cross-sell advertising, the sales organization for the product, the account management organization, that's what makes it— it doesn't do anything for you in the first 3 weeks, but it gives you a consistent cross-sell motion in the period after launch. And that's what we tend to focus on.

And one of the questions that was asked to me this morning was around determining when to specialize salespeople on specific product lines versus allowing the existing team to sell. And I think you do a bit of both. I don't think you have 20 to use, 2 dozen. So I don't think you have 24 dedicated or specialized sales reps that are selling each individual SKU. So some of those are sold as part of maybe a bundle or a sales rep can sell multiple. Products at once. How do you decide which products are specialized versus which don't have dedicated salespeople?

It's hard. So I would say that, I mean, first of all, there's actually— this is— there's a tremendous amount of disagreement internally at Rippling about how to do this. I am like personally on team every product should have its own independent sales org. And a lot of other people are on the other side of this question. I think what you get— the issue with having one sales team is eventually you run out of like training capacity. Like the team cannot learn like yet another product and they get like really frustrated with being like yanked into training sessions for each product launch. You know, Rippling, we launch— we aim to launch 5 new SKUs a year. So 5 new like products every single year. And it's just too much for one set of people to absorb and still be effective at all the others. And so it's kind of driven us to sort of need independent sales organizations, and we're increasingly doing more and more of that over time. But the other benefit that you get is that the individual sales orgs can just go way deeper on that individual product. You get some of the advantages advantages of being a focused point solution company when you have, you know, when each of your individual product sales organizations can have a VP of sales. And that VP of sales is going to think about, you know, that product and their point solution competitors all day long, and they're going to figure out like how to beat them and how to attack the market in the right way. Versus like, you know, if you have a VP of sales that's got you know, 25 SKUs that they're selling, they're going to pick like the 3 or 4 that are the easiest to sort of help them get to quota. And inevitably, you get products that are just not going to be as material an input to your sales number that year, but still like could be like really successful, that just get ignored if you don't sort of break it up and have individual people that are responsible just for those things. And so I'm a big fan of, of separate sales organizations for this. I think it kind of bounces back and forth. And so like the knock on this is like, I think like Salesforce internally like struggles a bit with having sort of, you know, the sales experience for customers, having multiple sales teams going after customers and not having like a coherent and cohesive experience for customers on this. And so like a lot of things, I don't think there's one right answer. And I think what happens is like your company will probably go back and forth, you know, every 5 to 7 years or so between these two extremes of one sales team versus, you know, individual sales orgs per product based on like what you're bad at as a company at that moment in time. And sort of reorganizing will probably help you get better at the other thing. And then over time, you'll sort of— one of these muscles will start to work weaken and you'll need to sort of go back the other direction.

Makes sense. Um, the way that I framed it earlier today when somebody asked the question was, uh, a bit of solving for the outcome. If, if the goal is to generate the most revenue for the company, try and construct the team with the, the, the construct that you believe delivers that ultimate outcome. If it's like, you know, usage based on a certain product, try and design the, the team that, uh, solves for that outcome. And again, it's a bit subjective, but if you start from the outcome and then work your way back from there, maybe a, a way to make the decision or framework, uh, to use. When you were talking, Parker, about, um, you know, it's, it's hard for a sales rep to understand and learn and go very deep on 20 different products. Where my mind went was the, the same thing is probably true for the market. And so if you are offering 25 different products, Rippling is known as sort of like all-in-one HR and IT. How do you handle that from a brand standpoint? Like, how do you— when you're a point solution, it's like very obviously—

IT and finance, mister. I went to Brex.

Well, sure, let's forget about the last one. But how do you, like, how do you establish a brand so that when people are looking for one of these 25 products, they know to come to you and not sort of like muddy the water with all the different campaigns that you're doing, whether it's payroll, IT provisioning, international payroll, again, 25 of these things?

I think it's probably the thing that we have found to be the most challenging about our business is like the sort of brand question of like, what is Rippling and how do we describe it? Because there isn't something, there isn't another analogous, thing like this. And so what happens in practice is customers tend to come to us. Nobody's like really looking for Rippling. They're looking for, you know, a subset of what we do. There are, you know, maybe there are companies in the audience that are like, oh man, yeah, I hate dealing with Sage and, you know, like process there is super broken. And so we want to talk to Rippling about that. And maybe there's a separate company that's like, I would never switch payroll, but I'm interested— like, man, it's a lot of work, you know, when I have new joiners in my company that need to— they need to get up and running with, you know, all these different apps and systems and computers. And I heard that you guys solve that problem, but not interested in switching payroll. And so what we see in the US is people tend to come to us with one of those problems. And what we do in sales— and by the way, Customers very, like, almost no, people almost never buy just one Rippling product, and they almost never buy all of them upfront. And so usually customers are buying, like, call it 7 SKUs. And so there's this opportunity to sort of cross-sell them things after the fact, which is where that cross-sell motion comes from. But usually our job in the sales process is to convince customers, like, hey, look, You think that you're coming to us with this one problem, which is like setting up new joiners in Slack and email and Salesforce and GitHub, and solving the administrative pain around that, but actually the problem that you have is the fragmentation of employee data across all the business systems in your company. And like, let me try and convince you that the problem that you're seeing here is a symptom of this deeper underlying disease and I can point to like 20 other problems that you have in these other areas. You know, maybe it's like in payroll and HRIS, for example, that stem from the same underlying condition. And if you are willing to solve this problem at a slightly more fundamental level, Rippling can actually solve all of that for you. And so a lot of times we get customers in who come in with a very opinionated view of what it is that they're shopping for, that end up buying a much larger suite. And sometimes they, they, you know, they end up somewhere in between, and that's fine. And over time, you know, there are opportunities for them as they grow more confident with the product to add things down the line.

You, you have built 24 products. You also integrate with what, thousands, hundreds maybe? So you aren't building every single point solution that exists in the possible stack of products that you could build. What's the decision framework that you approach build versus partner with?

So the, the real thing that I think about is there are these 5 advan— there are many disadvantages, many hard things about building a compound startup, but there are these 5 advantages that you have. And generally speaking, you want to build products where those 5 advantages are maximized. And so, you know, the first one was like integration. So you want to build products where the integration with the other products that you've already built matters. Integration with employee data. We look for products where employee data matters. And that's not necessarily to say that we build HR products because the thesis of the company is that actually employee data matters in a lot of other areas outside of HR. Like one of those Examples being things like finance products, like expense management, bill pay, corporate cards, where actually an understanding of who your employees are, and who should be on what policies, and who needs to approve for who else, and that actually matters tremendously in those areas. You wanna build products where the middle, we talk a lot about middleware at Rippling, which are the sort of platform components the elements that we try and build once and then reuse across our products, things like reports and workflow automations and permissions and approvals, you want to find products where the middleware capabilities, the platform components you've already invested a lot in, matter a lot for those new products. So for us, it's like, what are the new products where, yeah, analytics, workflow automations, approvals, permissions, those matter a lot for that new product. You want to build a product where, generally speaking, you, you have a buyer in common. So this advantage of having a buyer that's already bought into, like, I know how to do stuff in Rippling, I don't want to buy some other thing, you know, that only works if you have a buyer in common. And all else being equal, you want to look for areas where there are things that you can do with pricing that allow you to sort of run circles around competitors. Competitors from a pricing perspective. And that's sort of roughly how we prioritize things.

Makes sense. We have about 5 minutes left. I don't want to monopolize all of the time and questions for Parker. If anybody has a question, please just come up to the mic and go ahead and ask.

You obviously have a fantastic compound business, but I assume that you obviously have to start somewhere, i.e., you probably start with an on-point solution and broaden into compound. Where do you begin that journey, or how do you think about that?

So I actually kind of disagree with that, because I think what happens is the companies that start with one thing, with like this plan, yeah, yeah, but someday we're going to build like the next thing, they very rarely get to the next thing. Like the first thing just sucks up more and more time and energy and effort, and you go deeper and deeper, and it's never really done. So we actually started very purposefully purposefully at Ripplane with 3 things. So on day 1, we had like literally had like 2 or 3 people working on building payroll and HRIS, 2 or 3 people working on device management, so like mobile device management and computers and the ability to sort of like order computers from us and have them ship out and then manage security on the devices. And the third was what would be called like identity apps identity. So setting people up in apps and single sign-on and that sort of stuff. And so even before we launched, our launch set included all three of those things. And we thought it was really important for the story to be able to tell customers that it's not just payroll and HR, it's this broader sort of thing that includes all of these different products that All are, in their own ways, reservoirs of information about employees within your organization.

Why those three, not the next three? Sorry, that's the last question.

Yeah, so we started with all those three, and obviously stuff started to come later, so we started expanding the product set a lot later on. But we started with those three because they seemed, they were the deepest reservoirs of employee data employee data that we could find within the company. Like the payroll and HR side for obvious reasons, but actually, you know, what the market that people call identity right now is actually fundamentally about employee data as well. It's just employee data in the IT department instead of the HR department. And so that's why we sort of built that as well, because we thought, look, you shouldn't have separate systems for employee information, because the user happens to be an IT user versus an HR user. Like, you should have one underlying thing, and that's what's actually gonna dramatically simplify this, because like, when you hire someone in the HR system, they get provisioned all the IT stuff, but conversely, when you're doing things in the IT world, you have full observability into all of the HR data, so you know like their department and their teams and their start date and, you know, who their manager is, and that actually ends up being really important for a lot of IT systems as well.

All right, with that, we are at time. I apologize we didn't get to the last question. Um, thank you so much, Parker. Thank you so much for everyone that attended. Take care.

Thank you.