Building tech and product for marketplaces (with Rover cofounder Phil Kimmey)
50:35 Share

All right, Limited Partners, welcome to another episode of the LP Show. And today we are going to be talking about...

the early days of Rover.com, and how to build a marketplace business, and really the technology and the engineering behind building a marketplace business with dear friend of the show, Phil Kimme. So Phil, thank you for joining us. Thank you for having me. I'm excited to be here. Yeah, me too. Phil is the co-founder and director of software development at Rover, which he started in June of 2011. And as such, you would have been a junior in college? I just finished my junior year of college.

So did not return after that. Did not return as my mother frequently reminds me. Many, many fun conversations with Phil's family that summer. Yes, I bet. I bet.

Phil, you've gone on to, of course, grow the team at Rover. How large is engineering and product now? All of engineering and product together, I think, including design and analytics and other things are around 200 at this point. Cool. Don't call it a unicorn, but right on the edge. As reported, Phil, of course, should not comment on this, but as many news outlets reported, somewhere in that range. Phil has been named 30 under 30 by both Forbes and Inc. There were some pretty sweet

pictures of you and a cute dog floating around the internet. Multiple cute dogs. And of course, Phil is a super close friend of both David and I, and we are lucky to have him today. So Phil, I want to dive in starting Rover. We got to hear a lot of the Rover story from Aaron when we had him on for the dog vacay episode last season, but we didn't really dive into the first six months of the company. And

this time period is particularly informative to a lot of our LPs who are working on a startup of their own in kind of that pre-product market fit era of a startup. And so you got to work for real the Monday after startup weekend. So what was the first sort of work that you did? How did you

plan where you were going to dive in and what were you kind of trying to prove after that? Totally. So, uh, David can keep me honest here cause he was, he was there for much of this. So, um, well, so a little bit of background, I came back home for summer after my junior year of college and I went to this thing called a startup weekend.

which is basically a weekend hackathon. So people pitch ideas on Friday, you work on them over the weekend, and then Sunday you pitch them to a panel of judges. Greg pitched this idea of Airbnb for dogs. So I walked up to him and said, you know, I think I could build that. I like dogs. That sounds like fun. Worked on it over the weekend.

Over the course of the weekend, I learned that Greg did this professionally. And I had come back from school and intentionally didn't find an internship or anything to do. And for listeners to know, Greg was Greg Gottesman, the founder of Rover, and at the time was one of our partners at Madrona, and was a multi-time, was and probably still is a multi-time startup weekend champion. Yeah, and I think maybe cheating a little bit as a board member, but is

is now my co-founder at Pioneer Square Labs. Yeah. So anyway, so at the end of the weekend, he goes, you know, Phil, what do you think of doing this full time? And I was like...

That sounds amazing. You know, it's summer, just very least working over the summer and see what happens. So I came in Monday. I didn't actually start on Monday. We started on Tuesday. So I came in Monday, talked to, met with Greg, met with Aaron, which I didn't actually remember until he told me later, and David. And we worked out the details. And then on Tuesday, I brought my desktop computer in and set up in an office in the Madrona offices. So at the beginning, you know, the first thing I focused on, which I think now is pretty...

kind of expected but the very first thing was set up cicd so continuous integration continuous deployment i think you know if you're gonna move quickly that's kind

kind of the basic thing you want to have under your belt. It's gotten a lot easier as well and has become kind of industry norm. This was relatively early days of AWS, so... Yeah, this was summer 2011. Summer 2011, yeah. So we got some infrastructure set up, very simple stuff. Jenkins for CICD and just some basic EC2 instance type things. You know, the initial scope was basically Airbnb for dogs. So literally it was...

homepage, search page, member profiles we call it, or listing page, and then contact, messaging experience back and forth, and a transactional engine to actually handle the booking and payment.

And did you feel like you needed to do all of that to sort of be able to get something off the ground? Or did you ever think about like, oh, maybe we wouldn't handle payments or we shouldn't facilitate messaging just yet? Or did you say like all that actually needed to be in scope in order to do anything? So we did initially start to have some transactions occur, quote unquote, in the sense that I somewhat famously sat a dog through over in the very early days before we had messaging or actual booking capabilities that did quite a number on the...

second floor of madrona offices at the time i think we talked about that in the uh episode but yeah there were a number of transactions happening after that startup weekend of people because we had gotten some press for the startup weekend and people and just friends and family that we had in the area too were were using it and i think we did a pretty good job in those early days of of

having those transactions happen just so we could prove like, hey, this is something people like to do, even though it wasn't on the platform while you were building it, right? Absolutely. Yeah. So we got to the point of having, you know, very, very rudimentary search and kind of profile experience and then a contact experience, but didn't actually have all the metadata, you know, dates and dogs and pricing type calculations initially, but could actually get some volume flowing through the platform. Very, very minute amounts of volume, but

some demonstration of the basic concept. And so as you think about sort of the work that had to go into that era of the company, what stuff necessarily required engineering to do and what were some other things you were trying to prove that you were like, you know what, there's other ways to sort of get a good proxy for this information without actually having a dev team work on it?

I think, you know, I don't think... You guys at PSL now have gone to great lengths to try to, you know, figure out how to kind of MVP your way to something viable. And I don't think we were as sophisticated about it at the time. You know, I think...

Both because this kind of startup incubator type model was not then the norm to the same extent. And I think also just because, you know, this is the first time I'd done it and the first time Greg had done it, right? It wasn't like this was a process-sized kind of manufactured commodity in that sense. So I don't think we were thinking about it in those terms really. And I think, and beyond that, a lot of the kind of

landing pages and then testing via Facebook interest and stuff like that just had not, well, to a large extent it wasn't possible, right? Because this is an era before Facebook advertising was, I think there probably was some very limited notion at the time, but barely. And the landing page generator type things. Certainly no mobile app. Rover didn't have a mobile app. I don't think Facebook's, at that point,

I think we'll talk about dog vacay a bit, but free in those days was the primary way you got people on Facebook. So in other words, I think we just jumped in and started building stuff. I think for this type of marketplace, it is very... Something viable is pretty far from where you start. And so demonstrate basic demand characteristics or demonstrate that there is demand out there and then demonstrate there is supply. I think you can do that

Without building all the product, but you can't really have demonstration that's an end-to-end product without building something more substantial. Yep. Yeah, it makes total sense. And also, it's interesting thinking about every time a new business model is sort of made possible through technology, there's sort of this land rush of...

Yeah.

there's probably not that much validation work we need to do. There's a lot of available white space here to start this. Well, I think it was, at this point it was really Airbnb was the model, not Uber, so it wasn't really even on demand. It's this kind of travel use case, multiple weeks out likely. So it really predates Uber for X and it is kind of Airbnb for X era. So this was, Airbnb I think at that time probably was kind of one to five billion type

business. This is also an era before unicorns were ubiquitous. So at that time, Airbnb was, despite being small by modern standards or current standards, at the time that was a big successful startup. And I think it would have been hard to demonstrate. I think Getaround had also been started at this point. I'm pretty sure. Getaround was definitely, yeah. Yeah.

Yeah. I mean, Airbnb, or I'm sorry, Uber would have existed, but it was... Totally different. Early. Black car, yeah. So thinking, you know, we're talking now about sort of the supply-demand characteristics, so I want to get into that. Like, what was harder to stand up, and what was harder to actually get on the platform? Was it sort of the sitters or dog owners, and Facebook ads are in their nascency or infancy? How did you go about doing that?

I think both are hard in different ways. Speaking of Greg, you want to do a cameo? It's audio only, so you have to say something. I was waving. We're talking about the early days of Rover. Oh, yes. You're here with the... Sorry, I'm just talking to the microphone. You're here with the...

The reason that Rover exists, which is Phil. And I told him if Phil had had a proper summer job, anyone wanted to hire him, then there would be no Rover. That's the end. That's exactly right. That's exactly right. So supplier demand. So I think in the early days of a marketplace, you have to balance the two. And I think for us...

We weren't initially sure where the supply would come from. We actually started out with this overnight boarding business as our first line of service, which is kind of what you think of as our primary or what is our primary business model, which is non-professional, although many are professional, part-time typically business.

person who wants to watch dogs in their home for a weekend here and there. Obviously, we have people who span the spectrum, but we didn't really know if there would be enough supply for that. So we actually pretty quickly, really before there was a real business, we added overnight traveling services. So the notion there being there was already this concept of overnight traveling sitters who would come to your home and typically you could go to a pet shop and ask behind the counter and they'd have this book of business cards that you could just rifle through.

So we added that for the supply side initially to try to ensure there was actually going to be sufficient supply. That's fascinating because that's not an obvious, like, oh, this is how we'll get them on the platform. Well, and really in retrospect, I'm not sure. On the one hand, when you're building a system like that, having multiple

use cases or multiple service types forces some design decisions that make that at least possible. But in retrospect, that was a tiny fraction of the business for a long time. We've made progress there, but even now it's a pretty underdeveloped segment. For the first five services we did, especially traveling and sitting, it was really kind of a, hey, let's apply all the same functionality as with our boarding business. So for example, one of the things we talk about now is

For overnight traveling, does it really make sense to have your search experience be location oriented? So like our search experience for both boarding and traveling overnight are very similar to Airbnb, right? Listings on the left, panable map on the right side. And if you're looking for somebody to come watch your dog in your home overnight, you really shouldn't care where they are, right? As long as they're willing to travel. And there is some factor there because they're only going to actually accept the request if you are

are close enough to them that it's, you know, cost-fiable. Right, but that's not relevant to the dog owner. Exactly, it's not relevant to the dog owner. So we should be, you know, ranking our results based on the sitter's propensity to travel, but the dog owner searching for service, you know, it's really just not a, doesn't make sense. And so, you know, it really was just a plug-in to our other service line. And only now are we coming back around to really focus on that as a discrete and differently structured service.

Eight years later. So I'm curious, Phil, I lost touch with

your whole side of the house of the business pretty quickly. But looking back on these early days from a technology standpoint now, as you were standing up all the tech that went into the platform, the payments, the messaging, the profile, the search, the homepage, A, which pieces of those like original, you know, lines of code that you've written and services that you used are still part of Rover today, if any of them. And then conversely, are there any huge mistakes you feel like you made in

in setting up those services in the early days that really cost the company that you would have for sure do differently if you could go back now. Yeah, so I think, well, to answer your first question, I don't know that there's anything, you know, the nature of code is such that much of the structure is still as it was from the very beginning, but much of the actual, you know, lines themselves have changed in some way or another. Right, right. So I think much of the structure has persisted. We've had the luxury of,

we can collectively pat ourselves on the back all we want, but I think we had something that worked and to some extent we're lucky. And so it really is very similar. I mean, the whole funnel is structured the same way. A lot of the data model is structured the same way.

We still until we recently are in the process of changing payment providers, but it was the same Braintree account I set up, you know, seven and a half years ago for the longest time. I still occasionally get somehow somewhere deep in PayPal system. I can't change my home address. So I still get the some of the like, you know, let's upsell them more services through PayPal. And, you know, as we do many tens of millions of dollars a month through PayPal and like it's still just getting the letter at my parents house. That's amazing. Yeah.

So, yeah, so much of it still is there. I think, you know, there has been a ton of movement in the last...

10 years, really, especially the last five years on the web side, on the web technologies, you know, really V8, Node, Chrome. You know, if you think about where web browsers were eight years ago, it was a very different environment. Yeah, we've been through like 15 or 18 front-end JavaScript frameworks since then. Yeah, exactly. So the front-end stuff has changed a ton, but the underlying technology for the rest of it, you know, it's changed some, but honestly...

MySQL, Postgres, Python, Django, those things are pretty durable and haven't fallen out of favor in a way that a lot of the front-end stuff has. Was there anything easy to grab off the shelf when you were getting started where you're like, yeah, we're not going to build our own messaging system. We're going to use Layer or that probably didn't exist at that point. So was there any nice off-the-shelf stuff? I think our bias is, or certainly my bias, is always use

third party things where you can. We're now at a stage where things are starting to get expensive enough that it doesn't necessarily make sense to always buy instead of build, but where possible, that's certainly my bias.

I think in those days, you know, certainly for credit card processing and especially storage vault, you know, that stuff's really unpleasant to yourself. So that was relatively available at the time. But even that, Stripe was not yet the dominant player. Anyway, no, for the other things like messaging, I mean, now there's things like PubNub and certainly there's a lot of push notification services, but most of those emerged a couple years after. So we have our own things and that's...

For better or worse, you know, it's on the one hand, you get a lot for free when you pay for those, but also even just raw SMS costs now are pretty shockingly huge. And so if we had another layer of indirection, there would almost certainly be, you know, three, four or five times more expensive than it is. And it's already pretty painful. You mean like using Twilio instead of... We primarily use bandwidth, but... So I'm curious on the...

The question of if there's anything that mistakes you made, like as you think back now, like architecturally or service-wise. Yeah, mostly architecturally. I just, we've worked through a lot of these issues, but I think what we're calling our booking engine issue

which is now eight years later, we're finally forming a team to own that from a platform perspective, which is kind of the core. We refer to them as conversations or conversations and messages and requests which carry the metadata for a given transaction. And those pieces really haven't changed much. There are a couple of things we did that were really egregious mistakes that to go from just as an inexperienced engineer, to go from two services to five, we had to restructure some things, but only now are we really

We've paid down some of that tech debt, but certainly only now are we actually forming teams to specifically own some of those core components. If you were starting a marketplace business today, would you create it as a ton of tiny little microservices and have 100 microservices? Or how do you think about what the right balance is there? Because I know that's come in and out of vogue a little bit. Yeah, I think, I mean, this is my personal view, but I don't know that

there's a lot of opinions on the subject and I'm not sure mine are especially well formed. Um, but I've always been very skeptical of the services thing. Uh, and my, the more people I have come from other bigger tech companies or even equally, actually, especially equally sized tech companies that have gone really hard down the services path. I think it almost always ends up being a mistake. We, uh,

We really have one big Python monolith and it is very easy to get your dev environment working. And when you talk to engineers internally who have worked other places, our environment's pretty consistently the easiest to get set up of anywhere they've worked. They can be productive quickly, which is really what matters. I think we're right now at the stage where we have to or should be starting to think about those things or at least increasing modularity of the code base. So just the size of the code base is large enough that it is

it probably does need some more explicit boundaries to be drawn within it. So for a lot of reasons, but that's really interesting. It's only now that you're at, you know, 200 ish people on the engineering and product in the engineering and product organization that you're now starting to feel like a modular service based, uh, technology stack is worth it versus, uh,

versus being monolithic? Yeah, so I think that comes down to, well, the rough rule of thumb that I've heard is kind of 50 people working on the same code base is probably about the threshold where you start to feel those pains. But I think, so things like contention for deployments, things like reducing the blast radius so that a given incorrect change of some kind impacts only some subcomponent of your overall product. There's a bunch of benefits to be gained, but they all come at pretty great expense in terms of

increased complexity in how your system is deployed as well as increased complexity in how different components interact. If they can interact over an in-memory Python call, which is what they're doing in the case of Monolith, I think that simplifies a lot of assumptions you have to make. I think the

The starting point, I've recently taken over management of our platform group, which is basically the teams focused on some of these infrastructural components, not the actual true AWS infrastructure, but some of these shared software components. And the big focus for me is just getting to take what we have and make it fast and efficient without...

major modifications like going to services, but increasing modularity then sets us up to later go towards services when we think that we're ready for that.

We want to thank our longtime friend of the show, Vanta, the leading trust management platform. Vanta, of course, automates your security reviews and compliance efforts. So frameworks like SOC 2, ISO 27001, GDPR, and HIPAA compliance and monitoring, Vanta takes care of these otherwise incredibly time and resource draining efforts for your organization and makes them fast and simple.

Yep, Vanta is the perfect example of the quote that we talk about all the time here on Acquired. Jeff Bezos, his idea that a company should only focus on what actually makes your beer taste better, i.e. spend your time and resources only on what's actually going to move the needle for your product and your customers and outsource everything else that doesn't. Every company needs compliance and trust with their vendors and customers. If you're a

It plays a major role in enabling revenue because customers and partners demand it, but yet it adds zero flavor to your actual product. Vanta takes care of all of it for you. No more spreadsheets, no fragmented tools, no manual reviews to cobble together your security and compliance requirements. It is one single software pane of glass that connects to all of your services via APIs and eliminates countless hours of work.

for your organization. There are now AI capabilities to make this even more powerful, and they even integrate with over 300 external tools. Plus, they let customers build private integrations with their internal systems. And perhaps most importantly, your security reviews are now real-time instead of static, so you can monitor and share with your customers and partners to give them added confidence. So whether you're a startup or a large enterprise, and your company is ready to automate compliance and streamline security reviews like

like Vanta's 7,000 customers around the globe and go back to making your beer taste better, head on over to vanta.com slash acquired and just tell them that Ben and David sent you. And thanks to friend of the show, Christina, Vanta's CEO, all acquired listeners get $1,000 of free credit. Vanta.com slash acquired.

Well, I want to move us into sort of, and we've been here a little bit already, but marketplace technology. You and I have kicked around this business idea a few times, and I think it was one of the things that originally made me think, oh, this would be a super interesting episode about building a white label marketplace platform. And you've made the point to me that with a business like Rover, there's so much specific nuance that is tailored for the use case that there's not actually value enough in generalizing it. And so...

How do you think about the problem of, oh, there should totally be a white label marketplace service so anybody could start a rover for X versus actually every single marketplace develops its own unique set of features such that that thing wouldn't be customizable enough to be valuable?

Yeah, I think there's probably subcomponents that could be really valuable, and you've seen this emerge. Like in the form of, it was a company that eventually went out of business that was offering this service, and I think now Stripe also offers it, which is a marketplace payments product where... Yeah, Stripe Radar, I think. Or no, Radar.

I don't remember. I don't remember. Yeah. I don't remember what it's called, but Stripe offers it and other companies have offered it over time. But basically the idea that you take a hundred dollars and, you know, subdivide it between the people delivering service on the platform and the platform itself is

Stripe Connect. Stripe Connect. Yes, that makes a lot of sense. And there are pieces like that that can naturally be decoupled. But I think in the general case, it really tends to be vertical specific. So even for us, right, thinking about our on-demand dog walking product versus our browse overnight boarding product have very different just inputs and outputs, right? So what time do you want somebody to come walk your dog? Where do you hide the key? What is the combination for the lockbox? That makes a lot of sense for the on-demand dog walking case.

Those aren't really relevant information for the overnight boarding case, right? We're going to come to somebody's house and drop off your dog. And I don't doubt that you could build something, but I don't know that there's enough value add that you'd... You could imagine companies would launch on your platform, but certainly by the time they get to a certain size... They graduate off of it and build their own. Yeah, they're going to graduate off of it. And I think most companies...

For it to work, you have to get companies to be small and medium and then grow on your platform and keep the pricing such that the value add exceeds the pricing. And I think that's hard to do in something where it's open source software. It's such a good point. It's a huge fallacy in startups that you think, oh, we should make it really easy for people to start XYZ. Like build this platform company that...

ultimately, when your most successful customers have a business that's working, they move off of you. And I think it's really... Generally, it takes talking to an investor or talking to a friend who's sort of been there before where that hits you like a ton of bricks for the first time and you're like, oh yeah, that actually would be a material problem in our business. And you see that for us in all these big software contracts, SaaS contracts. It's like...

you're paying N engineers salaries per year to have some service and you're like,

You're not going to be able to rebuild that thing with two or three people, but it's still painful because it seems like a ludicrous amount of money. I'm curious, what are the areas where you used to be using a third-party service and you've since decided at some milestone it made sense to bring it in-house? Was it analytics? Analytics is a good example, actually. We used Kissmetrics for many years and we brought that mostly in-house. We still use all sorts of third-party software to make it work, but it's

um the bolt you know the the key components of it are building dashboards in sql i remember we were using a periscope for a long time right and we still are we still are but it's that's really a pretty broad dashboarding solution that covers

Is that one of those things that clones your production database and makes it queryable? I think that's one of those feature sets that makes a lot of sense at a slightly smaller size. Periscope does do that, and it's a really powerful capability. You give it a relational database and it will just mirror it into Redshift, but we're past the point where that makes sense because the tables involved and size of data is large enough that you can also point it at your own Redshift cluster, basically.

Got it. Well, I'm curious, you know, you've had to build a lot of things in the last eight and a half years. Like what are some things where as you're building them, you think it's like going to be a total no brainer that this makes a lot of sense to build. And then ultimately you launch it and it's just a complete flop and it's counterintuitive to what your initial conception was. That's a great example. That's a great question. I should have, you sent me these earlier and I should have given that one more thought. Yeah.

So I think we've been fairly cautious. I'm sure I could come up with some examples if I probably need to think on a lot harder. We've been pretty cautious about launching new businesses and new service lines, in part just due to team size. So I don't think there are many examples where we've really gone way out of kind of the coloring book, as it were. You know, an example of this is we added daytime services and people were really working around our system to use our boarding service to book people.

dog walking. A lot of the time we're literally just doing what the customer has clearly demonstrated through our platform they want to be doing on the platform. I think

We've had a lot of attempts to do just the nature of doing an A-B test-driven consumer-oriented business. If you're really lucky and you have a really good hit rate, maybe you hit 40% is a success rate. And 40% being, is that search to book? Oh no, I'm sorry. For running a given A-B test, at best 40%, more typically 30% are successful and the rest are neutral or negative. I see, got it. So we've launched tons of features that have flopped and

I think we've had varying levels of discipline about rolling them back. Oh, because someone might be very excited about a feature and even though it doesn't perform that well, there's these qualitative reasons why it might make sense to keep using it. Yeah, exactly. And the qualitative thing, sometimes it's pretty plausible. Sometimes it's people struggle to depersonalize the features in a way that I think is a pretty important thing for PMs to be able to do.

I'm curious, one of the interesting parts of River's history, I think, is that we spanned...

two technological eras. You know, when Rover was started, as we were talking about a minute ago, it was web only. There was no mobile app. And it was probably, what, two years into the business before there was a mobile app at all. And then now fast forward to today, and I can't tell you the last time I interacted with rover.com on a website. And you were running mobile in those early days as it was beginning. How did you think about...

translating rover into the mobile environment and then getting adoption within uh buy-in within the organization that this was the future yeah so well so it was not only mobile it was not only web it was desktop web so one of our biggest metric improving events was rebuilding our core funnel to be mobile responsive i mean it was now that's kind of the obvious thing to go do is make sure you have mobile support right you wouldn't even think about not doing it but uh

But this was you pull up Rover.com on Safari on your iPhone or whatever on your Android browser, and it just wouldn't even be formatted for the screen. Not formatted well. Zoom, zoom, zoom. And so there are kind of three things I think that actually... I'll come back to your mobile-specific question, but at least...

And this is also possibly my fallible memory, but I think there were three things that really led us. We had a big focus on marketplace efficiency, unit economics, which ultimately is what led us defeat Dog Vacay. But I think the three specific things we did were one, focus on search algo, ensure, maximize conversions and LTV by ranking providers.

Number two was pushing messaging towards SMS, which causes a decrease in response time, which is very strongly correlated with booking rate. The number three was rebuilding the member profile page, that profile page to be mobile responsive. And I think...

You can really, it's hard to tell, right, month over month, but it sure seemed like that was the, that last one, which was one that was never on my radar, frankly, was the one that really pushed us. Interesting. So not even shipping the app version of Rover, but just making profile pages for sitters mobile responsive on web. To answer your original question, I basically went to Aaron, you know, at this point it was maybe four or five, four or five engineers. And I was just like, went to Aaron and Jason was like,

mobile app, we need a mobile app, everything's moving to mobile, everything's going to be moving to mobile in the next several years, we need a mobile app, right? And I want to work on it. So, you know, that said, I think even now, the acquisition model tends to be web, right? I mean, Facebook actually

ads are notoriously ineffective and expensive. And so we spend a significant amount of money there, but it's still hard to make it work. Whereas the web is, you come in the door and you're already on the platform. Like an intent-driven Google... SEM, but also SEO, also other online word of mouth. You see a TV ad where you go, you probably go to the web browser first. The App Store is not the discovery channel.

So I think you need both. And that was certainly always the intent is for the sitters, for service providers on the platform, mobile is really important, especially in the daytime services where you might actually be not at a computer or even near a computer when you're delivering services. And then focused on the repeat case. So...

who are, like you, David, using the dog walking service or any of our other services, overwhelmingly are booked through the mobile apps. But that new customer acquisition is disproportionately... You still need the web, yeah. And I think it always will be. That's just where people first investigate a product. Well, it's like the framework we use when starting new businesses when we're trying to decide is it mobile or is it web and what's your initial vector is...

If it's something you're going to commit ahead of time to using multiple times per week, then you're willing to download an app. Otherwise, you're not. And so when you're looking for a dog sitter for the first time, of course, you're not going to go download an app to use it for that one use case. But if it becomes clear like, oh, I'm making money through this thing as a sitter or, oh, this is the thing I do on a regular basis because part of my lifestyle, then of course you would download the app. Exactly, exactly.

Alright, so I foreshadowed something mostly because I wasn't paying enough attention and just spouted out search to book. But then I think you talked about it a little bit. What are the different sort of KPIs? And I, spoiling search to book is a big one. And why is that sort of the lifeblood of...

marketplace platforms, in particular this one? Yeah, I mean, I think for any business, right, we focused on unit economics. And the example, so when maybe 2013, maybe 2012, when we were competing with Dog Vacant, they had a pretty sizable lead and really driven primarily by effective PR as well as Facebook marketing. They had a pretty big lead in this. And honestly, Aaron would say,

focus on union economics. The classic example is kayak.com, where they had better union economics because of better conversion rates, which in turn meant they could pay more upstream on advertising as well as just generally grow the business faster. Because traffic on the site was worth more to them because they could convert that traffic. Exactly. And that's true. So I don't think it's specific to marketplace businesses that union economics focus. So how efficiently do you convert it? And then ultimately, how efficiently do you

maximize LTVs through you know the long range uh value of the customer but you know that is the lifeblood of product engineering right if you're certainly the off-site stuff will usually be marketing driven in some form or another but the thing you really can move and the thing that has the biggest impact in the long run the flywheel is that those uh core on-site metrics so to answer your question though I think you know for us we always thought about it in terms of how many people do you get in the door

How many people from getting the door to the first metric is how many people do we get actually contact sitters? And that is all sorts of...

All sorts of things drive that. So for example, until a market reaches a certain density, it's hard to get people to actually contact a sitter because if the nearest sitter is 10 miles away, you'll probably just bounce and go to the commercial facility or call up your mom. You launched basically everywhere that wasn't Seattle in the United States all at once, right? We did. Yeah, so initially I think we actually opened it to a couple markets to start or kind of had a nominal launch, although it's not really that meaningful.

But whereas with Uber, which although it was still early, it was still kind of on the radar with Uber, you need pretty significant density. I mean, in the early days, Uber was probably five to eight minutes was kind of the expected pickup time. And now it's like two or three. But if it was 30, right, you don't have a viable business. Whereas for us, if you're going out of town for vacation and you have to drive 30 minutes even to drop your dog off, that's actually probably fine, better than the existing options.

So you get back to the metrics, you know, for us it's what are the, what's the probability you come to the site and contact somebody once you've contacted somebody or, you know, multiple people, what's the probability you actually turn that into a booking, you know, transact, uh,

put dollars to the system. And then ultimately, the most important thing is how many times do you come back? Because we lose money on the first transaction. It's the only way we're successful is if we find you a sitter that you're satisfied with and want to continue to transact with on the platform. So those things, what is your CAC? What is your cost of acquisition? Customer acquisition cost? And what is your LTV? And those are certainly the metrics I'm sure you guys talk about a lot and ultimately define the unit economics. Yeah.

Yep. Yep. I'm curious on, um, on the tech standpoint, I think we talked a lot on the main Rover dog vacay episode about everything that goes into instrumenting and optimizing the, um, transaction in the LTV funnel. But one thing I don't know as much about how much technology have you guys built for marketing, uh,

Rover, as you've said, spends a lot of money on Google ads, on Facebook ads, on other types of advertising. Amazing Hulu spots. Right. And I think it's very poorly known out there in the tech community how much technology can improve that spending. So how does Rover think about that?

So I don't know that I can speak to, I mean, you know, Aaron, who you interviewed last time, spent, what, 15 years in display ad tech specifically. So he probably can give you a more nuanced view here. But we haven't really spent anything on internal time in terms of technology investment. So we certainly, you know, inevitably, if you're doing, you know,

any kind of bidding. Obviously Google behind the scenes is a technology platform, but we're not doing anything ourselves from a technology perspective. I think it's been something that's always been on our radar and I think we'll inevitably end up doing something significant there. I think the industry trend you're seeing is more and more companies

Certainly, they're kind of automated bidding type stuff. SEM and any other things that lend themselves well to that type of automated bidding strategy tends to become an entirely engineering-driven activity. We're not there yet. I think the philosophy to date, but literally we talk about that every once a year or so, is the question of, is now the time to do that? I mean, given the volume of dollars that you're putting through these platforms, hiring...

an engineer, even a team of engineers to help optimize that could see some ROI pretty quickly if you can make an impact. Yeah. I mean, the ROI, the numbers seem pretty hard to dispute, right? I think we're, uh,

I don't know that I could come up with an exact... We can do some rough back-of-the-envelope math. I think the optimizations on the platform that impact all channels are still probably higher ROI than doing... Depending on how much you think we can make our SEM, say, volume larger or efficiency higher, I think the on-site stuff just ends up being... It flows to your direct. A lot of our customers come in through word of mouth. It flows to every channel equally, and it...

Yeah, investments in increasing efficiency on the product amortize across both your paid and your direct traffic rather than accruing just to your paid traffic. Exactly. So I think there's definitely an opportunity there and relative to our size. I would be surprised if we doubled the team size and didn't have a team focused on that specifically. But where we are today, I think we're still at a place where

Some of these relatively small percentage improvements across the new customers we're acquiring can be a really huge impact, likely more than we could see in just improving the efficiency through automated bidding strategies and things like that.

Okay, two more questions here in marketplace technology. One, so I know of a feature that I assumed must be part of Rover. And of course, I haven't used it because I'm not a dog owner or a cat owner. But you were telling me, actually, no, like there's very data-driven reasons why sort of that continues to fall below the cut line. And that is two people having two different logins to a single account, like two people who live in the same household. Like, it kind of blows my mind that it's possible that eight years into a business, you're

when you're making decisions in sort of a very logical algorithmic way that that that feature wouldn't be a part of it it's like of course we co you know we both own this dog this is ridiculous because you don't know you don't know you don't know how this works ben

So, David, no, actually, I want to turn this around on David. How tell me about your actual experience arranging services for your dog? I don't know if I'm typical, but it's funny because I think I'm trying to remember, Phil, you might know. Was I was my Rover account the first demand side Rover account?

It was either number one or it was within the first like three. David, if you believe this to be true, you should just claim this is true. Yeah, okay, I'm going to claim it. You are sitting there with your dog on your lap right now. We can look. I can tell you I am ID number one. I can't tell you what ID you are. Well, anyway, if you go query the database, you will see that that account has not been active probably since the early days of Rover because I just log in on Denny's account and we both use her account.

Okay, but how about when you go to pick up the dog, say, or whatever, right? Do you have the who goes and picks up your dog or like? Oh, we just both message through Jenny's account. And I just say, hi, this is David, Jenny's husband, and I'll be there to pick up Danny. And for we mostly these days use walking for Rover daytime walking and it doesn't matter at all.

Yeah. So for, well, so I think the very common cases, as you alluded to is most of the time people are getting a dog as a couple and both people are involved in coordinating care. So, you know, one person will book it, but then the other person goes and picks up the dog and you have one SMS channel, right? So we have one phone number,

You can have multiple devices signed in the same account, but then you still have the little one person photo. It's a very basic feature that is missing. And I think a generous reading would be, Ben, as you put it, I think is being very data driven. It never bubbles to the top. But I think a less generous reading would be

that I think we have, well, A, we grew the team a ton the last year. So we're at 115 or something in various technology roles. And a year ago, we were at like 45. So when you're at 45 or a year before that, 25 or 15, you can't do a lot of these basic things. So the team's quite large now, but a lot of those things have always fallen below the cut line and I think are getting to a place where we'll end up doing them. But the point I'm trying to get at is I think we have...

For many reasons, in part because we've been successful and lucky to some extent in the initial service offering working. We've always done the small iterative things

sometimes at the expense of the things that are kind of the obvious gotchas. Another example of that would be the level of detail of the profile you can build for your pet is very poor. Basic care information stuff is kind of a free text field instead of structured data. I mean, things that you think are kind of foundational components of this type of platform that I think are foundational. I mean, I don't... I actually...

think we have failed collectively to prioritize this stuff. And I think if you talk to Jason, who's our head of product for a long time and there since about a year, less than a year into the company's life, I think he also is frustrated by the fact that we've never built those things because it's like you always have this

belief that if you do everything right and make the customer experience really sing, you have to believe that's going to show up in your growth numbers, even if you can't correlate any individual given feature, which is hard to go execute on, hard to go put a team against when you have all these things where if you just move this number by 1%. You know that that materially impacts the business. And actually, a really good example of this is

The impact that this can have when you're able to get to a size and resource standpoint where you can step back and do more ambitious product stuff, I think is Airbnb plus. So Airbnb plus launched, gosh, probably a year and a half, two years ago. Uh, and it's been a huge revenue contributor, uh,

Is that the events and activities thing? No, no, that's experiences. That has contributed less. But Airbnb Plus is exactly filled with what you're talking about, about more features about your dog's profile, is more structured...

for listings on Airbnb where you can see, you know, here are the photos of this bedroom and then they send a person to each Airbnb Plus listing with a checklist to verify, okay, this house meets our plus criteria, meaning it is of a sufficient level of, you know, comfort and luxury or whatnot and has these features. And so then on the demand side is booking, you're like, oh, I trust more. I'm willing to pay more for this and then the platform takes more. Yeah.

As someone who is a super host but is not plus, once they sort of commoditized the value of super host, plus became this sort of really premium tier. Super host plus plus. Yeah, you can search by it. You know, it has a bunch of special features as a very nice sort of like highly optimized layout that sort of

would really fall on its face if the photos weren't A+, but every single Airbnb Plus listing has these incredible photos. So I think even that is somewhat additive in the sense that it's like a value-add service on top of the listing, which presumably they take a higher take rate and that kind of thing. We have a service that's somewhat similar to that. I think the thing that we have started to do that's more kind of a structural change to the marketplace design, I think is where the biggest opportunities are to

With that type of thing, you can probably increase your take rate and have higher LTVs through that mechanism, through effectively pricing. We're about to convert our listing from regular to plus. I don't think it's a different take rate. I think it's just it lets you charge a higher price. So everybody wins. So the platform's making more dollars. The platform makes more money as well. And the hosts are making more dollars. Fair enough. Well, so for us, I think it's the... We modeled our marketplace on Airbnb. And I think...

A lot of the experience, especially for the overnight services, if the first person's not available, it's just not a very good experience. Which, I mean, frankly, in the Airbnb case, it's kind of the same thing, but they've moved away from that with Instant Book. But if you think back to the earlier days of Airbnb, you would often contact people and you'd contact multiple people before you'd get a booking, right? And so I think that's the stuff where we have historically...

optimized for that next one or two percent through algorithmic improvements or small kind of CRO improvements and never gone back to the drawing board and said, you know, it's the marketplace design here, right? I'll say as much as you're frustrated by it and Jason and the product team is frustrated by it, like it really does just go to show that your sort of intuition when you conceive of a product like Rover as a founder is, oh, well, it's certainly all these have to be structured fields and you have to be able to search by them. And it's really important. I mean,

there's a lot there that is sort of assumed necessary. And yet here you've built an enormous business without any of that. And it does go to show that like, you know, it's worth challenging those assumptions and sort of chasing that next gen or incremental growth because in a lot of businesses, especially real estate, like for a long time, there is that incremental growth in front of you. You just have to kind of keep cost effectively chasing it. Yeah, and I'm not even sure, you know, in the early days we could have done some of these different structural things. I mean, one of the,

I don't have any... One of the things we've seen when we've tried alternative marketplace models is you're implicitly putting more trust in the platform and less trust in the individuals. When you do a marketplace assign versus a marketplace assist. Exactly, because Rover is now the entity you're trusting to find you that person. The on-demand product that David uses, you're totally putting your trust in Rover. Yeah, we'll give you the same person wherever possible, but...

Rover is much more the trust entity there, whereas with the browse-based boarding business, when Rover was a much...

smaller and fewer resources kind of business, I don't know that we could have jumped straight to it. I just think now that we're at this point of maturity, it's likely that's the place we'll head. It also has to do with how commoditized versus unique is the supply side. In the case of Uber, and David, we've talked about this 11 times on the show, but I don't care what Black Prius picks me up. I'm going to

a mile or two miles or whatever it's raining i just need to get there and it's kind of irrelevant who you know who the service provider is and in the case of rover like

Oh my God, I'm hitting over my baby. And like, you are a unique and special thing in my life. But there's also different levels, you know, I think Phil, you're getting this point. Walking. Between walking. Much less that. Like walking, I want somebody who's not going to let Tani run away and is basically confident. But, you know, I don't care what the home they live in looks like. Whereas boarding, you know, Tani's going to live for a few days at this place. I care a lot about what the home looks like.

And what other dog is going to be there. Yeah, different service offerings dictate what type of business model you can have or what type of marketplace model you can have. Absolutely. Yeah, and you can find a good number of those kind of, you know, the inverted triangles type MBA models. The conjoined triangles of success. The conjoined triangles of success. You can find a lot of marketplace design framework type things out on the interwebs.

Well, Phil, one other question in this category. Let's say you're meeting with a technology team who's building a marketplace today. What advice would you give them out of the gate? I don't know that there's a ton of stuff I would advice I would give that's specific to marketplaces. I mean, I think most of the same fundamentals apply.

I think for the marketplace piece in particular, I'd probably, having talked to a bunch of marketplace people early on in a marketplace business, I think a lot of the time people go out with too much product. Like I would, I think we went out with a pretty lightweight MVP and I think that's definitely the right place to start. Yeah.

Yeah, wholeheartedly agree. I also think you need to start with a very narrow customer segment and customer use case. We're now eight years later and we just launched a grooming product, which is a very different product than the overnight boarding product we started with. But there's a lot more to do that's non-obvious when you're first getting started for each of those services to make them high quality. So I would...

say narrow your focus where a lot of people try to do these big broad things and you're like you know they and you hear them say things like oh you know well we're just gonna add this feature in this feature in this feature and you go like either each of those features is really not going to be actually very good or you're going to be looking at you know years of kind of sitting in your you know little studio building stuff and not actually out having customers have your product

Yeah. I just want to highlight this. Like Phil, you are so right. Especially now being an investor focused on specifically on marketplace businesses. Uh, this is the number one mistake is overbuilding the product, uh, to start the, the most recent business we funded, they built a product, uh, and then realized that the whole system, the whole market would work better if everybody just transacted on WhatsApp. So they basically trashed the product and like, it just runs on WhatsApp, you know? Uh, and, uh,

Another one of our companies we're working with is pivoting their product right now. And every week when we meet with them, basically the conversations are much more, what can we not do versus what can we do? And how can we take the core of this market and what's already happening out there and just strip away to the bare, bare, bare minimum of what this product is?

Yeah, I think there's often, and it's not just marketplaces, right? I think it's any software-oriented technology business is a desire to keep adding features because, you know, oh, wouldn't it be cool if we do this or that? And it really, you know, if a customer is spending five minutes with your product, they're only going to interact with a very tiny subset of your feature set. And so you're much better off usually improving something that 80% of people interact with that is really, really core than things around the edges that are more and more functionality. Yeah.

Well, with that, Phil Kimme, thank you so much. Thanks for having me, guys. LPs, if you like this episode and you want more people to, I don't know, also be LPs so we can find more Phils of the world, feel free to share on social media, tell your friends. And David and I will see you next time on our next main episode, which I think will be the Zoom IPO. And if that's already out, then it will be the Slack direct listing. Yeah, can't wait.

So, all right. Talk to you next time. Bye guys. See you Phil.