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

One of my favorite Parker stories is 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 1/4 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 going to 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 with 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 going to 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, 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. I was only CEO of that company for a very brief period of time. Saxophone Both agree that focus is really, really critical and even sort of way beyond that. 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 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 collaboration across the business, how 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 two or three 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 go to product number two if everything about your company is oriented around just having one product in it? 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 five. 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, et cetera, et cetera. 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, 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 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 and 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 going to 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 seven things from you and six 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, you know, 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, 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 gotta 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, you know, there are a bunch of disadvantages to managing this stuff in spreadsheets obviously. But then once you get stuff over into payroll, you know, you've gotta deal with all of the change management in the payroll system as well as an hrs. 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 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, and then you've got to deal with this 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 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 2000 person company across about a dozen different countries around the world. Natively in ripplane. 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 five or six 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 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 ripplane has actually three separate clouds. We have our HR cloud, our IT cloud and our finance cloud. And, 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, you know, Slack, Dropbox, GitHub, Email, Salesforce and so on. And you know, 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 everything sort of then 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 like 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 Sile, 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, 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 pull out functionality that you build once. Because you end up like so many companies end up. How many? Probably zillion companies. 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 want to 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 got to often organize the company into business units with sort of strong entrepreneurial leads that can run individual products relatively independently to sort of paralyze 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 Saster 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 two.

Yeah, round two.

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. Two 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 or 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's actually because of the ways that we can simplify the problem for you by being a compound company 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 Deal 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, Deal uses Clay in France and probably Sage in the UK and Humi at one point in Canada. Deal was actually until very recently a rippling customer in the United States. They ran in fact their global HR on Ripplane 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, 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 Deal or remote or one of those systems, there's this army of ops people that are loading it into all of these other systems around the world and then running payroll and then getting the data back to you. And that's why you have to run payroll 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. You know, stuff goes wrong, it's a pain in the butt. And you also, like, you don't have the depth of systems that you need to run your business in those countries. Like, you don't have full H R s, full compliance, full time off tracking, you know, 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 one place for your employees in this country and another system for your employees in that country. Or maybe you overlay it with a completely separate HR system that actually 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 payments within your company.

That makes sense. This, this has been a bit of, a, bit of an evolution for you, I think. You know, many years ago you were a co founder at Sig Fig, which was probably a point solution. And then you were founder and CEO at Zenefits, which was, 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 Sig Fig, back in the days of benefits that, you know, now, you.

Know, the biggest thing is, I think even, even when I started Rippling the, you know, I hadn't, 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, it 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 and one est, and that was the way to win. But when, 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. Why, why won't it work? Or what's the. Why are you going to lose? And for us, it was always like, well, it's this thing. The knock on us is that maybe we're doing too much and we've got to overcome the fact that our strategy is very specifically and purposefully taking on all of these things in parallel. And actually what I realized over the course of doing Rippling is that 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 the cross sell motion that we have that, you know, our NDR stays extremely high. And again, that's all, all a function of like our whole compound approach and the different products that we have. You know, the, 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 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 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. You wanted to be all in one 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 automatically across all of your HR systems in Zenefits case. And we just had like this strong belief that people wanted that button but they wanted it to work for everybody, 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. 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 revstack solutions for like knowing what you know now and maybe for folks in the audience that are founders of a company that is a point solution. How would you think about like adapting from being a point solution into to 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 re found the company or you know, sort of like rewind and reverse and start over and go in this different direction. Tactically the reason that big businesses, it's really so hard for them to launch like a second product is there are 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 how your product marketing, your product teams are aligned. It's, it's very hard to just suddenly have like two things where there was one before. But the bigger thing is like almost by definition compound startups are solving like different problems than point solution products. Like if you, if you take the example with Gong, I mean, I don't know the company super well and I'm speaking, you know, off the top of my head, but you know, 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 business process problem on 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 gonna do the compound startup for this sales stack and do, I don't know, something like CRM, but also call recording and lead routing and you know, calendaring like Chili Piper and Calendly and like a whole. And did that all together like, 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, there were a couple of 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.

Okay, so. 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 like not very good at. Like, we're generally like not great at like PR and like, you know, tend to sort of like not be sort of like really seeking the limelight. From a press perspective, what I think has gone well for us with launches is focusing on like what comes after the launch and just sort of sort of like 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 two or three 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 elements to it for us. One is an account management organization that is focused on selling 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 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, like our ATS product that's coming soon is to 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 like ads and promotions inside of our product. And we have a lot of I, I hate myself for using the term AI or machine learning because your valuation just went up. But we have like some AI and some, 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, decision about sort of what, what to optimize for and what to show the customer and they're what are they most likely to convert on and that's what then drives a lot of like leads across to the account management team. And so getting those pieces right, like the, the sort of internal cross sell advertising, the sales organization for the product, the account management organization, that's what makes it you know, like it doesn't do anything for you in the first like three weeks but it gives you like a consistent cross, 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 22, you said two dozen so I don't think you have 24 dedicated or specialized sales reps that are selling each individual skill. 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, at Rippling, we launch, we aim to launch five new SKUs a year. So five new products every single year. And it's just too much for like one set of people to like absorb and still be like 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. Like you get some of the 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 three or four 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 co 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 five to seven 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, probably help you get better at the other thing. And then over time you'll sort of one of your, these muscles will start to weaken and you'll need to sort of go back the other direction.

Makes sense. The way that I framed it earlier today when somebody asked the question was a bit of solving for the outcome. If the goal is to generate the most revenue for the company, try and construct the team with 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 team that 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 way to make the decision or framework to use. When you were talking Parker about, you know, 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 same thing is probably true for the market. And so if you are offering 25 different products and 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 obvious.

IT and finance. Mr. 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, 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 Ripplane 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 A rippling. They're looking for, you know, a subset of what we do there. 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 solved 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 seven 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 are stem from the same underlying condition. And if you, 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, 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 end up somewhere in between, and that's fine. And over time there are opportunities for them as they grow more confident with the product to add things down the line.

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 real thing that I think about is there are these five advantages. There are many disadvantages, many hard things about building a compound startup, but there are these five advantages that you have. And generally speaking, you want to build products where those five 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 of lot, lot of other areas outside of hr. Like one of those examples being things like finance products like, you know, expense management, bill pay, corporate cards, or actually an understanding of who your employees are and you know, who should be on what policies and who needs to approve for who else. And like that actually matters tremendously in those areas. You want to build products where the middle we, 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, like those matter a lot for that new product. You want to build a product where generally speaking, 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 could do with pricing that allow you to sort of run circles around competitors from a pricing perspective. And that's sort of roughly how we prioritize things.

Makes sense. We have about five 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. That is, 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, they, they very rarely get to the next thing. Like the first thing just sucks up more and more time and energy and effort. You go deeper and deeper and it's never really done. So we actually started very purposefully at Ripplane with three things. So on day one, we had like literally like two or three people working on building payroll and HRIs, two or three 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 and identity. So setting people up in apps and single sign on and that sort of stuff. And so even like before we launched, like our launch set included like all three of those things. And we thought it was really important for the story to be able to tell customers like, you know, that we're not. It's not just like 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, 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 those, we started with those three because they seem they were the deepest reservoirs of employee data that we could find within the company, like the payroll and HR side for obvious reasons. But actually 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, 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 going to 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 team teams and their start date and 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. Thank you. So much, Parker. Thank you so much for everyone that attended. Take care.

Thank you.