Speaker 1: Hey there, Product Lovers. Welcome to the Product Love Podcast, hosted by Eric Boduch co- founder and chief evangelist of Pendo and super fan of all things product. Product Love is the place for real insights into the world of crafting products as Eric interviews, founders, product leaders, venture capitalists, authors, and more. So let's dive in now with today's Product Love Podcast.
Eric Boduch: Welcome lovers of product. Today, I'm here with Jeremy Henrickson who is the VP Engineering& Product at Rippling. Welcome Jeremy. It's good to have you.
Jeremy Henrickson: Thank you. It's good to be here.
Eric Boduch: So why don't we kick this off by getting a little overview of your background?
Jeremy Henrickson: Sure. So I grew up in Sioux Falls, South Dakota. Just a shy kid there doing all my little technical things. I first got exposed to computers pretty young as my dad was super into them. And so I grew up in the early'80s with a Apple II Plus at home. And my first exposure to programming was way back then learning to write some adventure games by copying things out of another book that told me how to write adventure games. But that ultimately morphed into the career path that I took. Taught myself how to code and after my senior year in high school and ended up at college and fell in love with just building stuff. I found that after a year or so of doing that, what I really loved was not the engineering and isolation, but was rather how people interacted around computers or how people interacted with each other around computers. That interaction over time led me to product. I've been there for the last 25 years or so.
Eric Boduch: Yeah, it's interesting for me, it was an Apple IIe. That was the beginning of writing quote- unquote code though, I think I knew basic pretty early.
Jeremy Henrickson: I was a little jealous of people who had Apple Iies.
Eric Boduch: Yeah. I think for me at the time the IIe was a little old. I think a couple of my friends had Macs right around then. So it was like they were on the cutting edge. I don't think there's much they could do with them. They showed me things like word processors and stuff, but...
Jeremy Henrickson: Yeah, but they looked cool.
Eric Boduch: They did. They did look really cool. I was super close with my IIe because there was much better games on the Iie than there were on the Mac. Yeah. So it was definitely interesting. So talk to me about making that jump into product. What got you there?
Jeremy Henrickson: Yeah. So I think it really did start when I was in college and I had this insight that I really liked the people aspect of it. And that got me into programming graduate school in design, human computer interaction. I spent 10 of a number of years to be mad and then ended up at this company called Reactivity after finishing grad school. It was founded by a bunch of people that I'd gone to school with. It was really early there. This was during the Internet- 1, late'90s. We were both starting up businesses and doing consulting for companies that were trying to figure out what this internet thing was and how to build products for it. And so I would come in and help them with the engineering, but very quickly realized that my actual job was helping them understand the user and the product that they were trying to build and how that could work with this new set of technologies around the internet. So I ended up without knowing what it was really called or having any understanding of any formal definition, I was doing product. When I left there, I took a little time to figure out whether I wanted to go do something totally different. But when I came back to it ended up at a company called Guidewire and was officially in a product role and that's really where I cut my teeth in that function.
Eric Boduch: Awesome. Well, we'll get to Guidewire and some of your other career choices, past experiences, but let's talk about Rippling for a second. Tell me a little bit about Rippling, what you're solving there now with teams, you oversee, what the big challenges are.
Jeremy Henrickson: Yeah. So at Rippling, the problem that we're trying to solve is that every business in the world has a bunch of systems they need to run. They need to pay people, say the payroll system, they might want out for benefits. So they need insurance and benefits system. They need to manage people's identity and access. People's devices and so on and so forth. And all of these systems rely on a set of information about the employee and other people in the workforce. Sometimes it's as simple as a name might be an address where they live or where they work. So you can calculate taxes appropriately. It might be something about their organizational relationship. The problem is that there isn't a single system of record for all those, these systems, none of them is the source of truth. And so you end up with a tremendous amount of administrative and bespoke integration work to keep all these systems in sync. People whose whole job it is to sit there with and pull stuff out of one system, copy it into a spreadsheet, make sure everything's okay in that spreadsheet and push it to another system. And while on now you run payroll. Our thesis is that, that's just the wrong way to do things. The right way to do things is to have a single system of record and build on a first party basis, a whole bunch of products on top of that to do payroll and insurance and benefits and device management, identity management, so on and so forth. And in doing so, you create not just a single system of record, but you create a technology platform on top of which a whole bunch of these products can consistently run, which creates a better user experience, better vendor experience and then just overall more efficacious universe for companies who really don't want to focus on those systems at all, but they want to focus on their business and we hope we're enabling them to do that. So my responsibility is to look out over product and engineering for all of those products and it's a really fun job.
Eric Boduch: Yeah. I can imagine. I mean, it's interesting when you're talking about all of the disparate systems that use that same set of underlying data on the HR side of things, whether it's payroll systems, whether it's authentication systems, whether it's just joining the right Slack groups and list serves and that type of stuff, right?
Jeremy Henrickson: Right. That's exactly right. What I found is there's HR systems and there's these it systems and there are these finance systems and they all operate on the same data. And then you just pointed out that there's this whole constellation of other things outside of that Slack and G Suite and all the rest. Wouldn't it be great if/ when an employee started at a company, they just automatically got assigned to the right Slack groups and the right GitHub repositories and the right policy for being able to buy lunch from DoorDash without ever having to go to GitHub or to the Slack admin panel or to the DoorDash. It should just all happen.
Eric Boduch: Yeah. And it's just the hiring managers that pushes a button says hire and says hire for this type of role and everything else is just based upon the workflows so we're setup.
Jeremy Henrickson: Yeah. That's exactly right and it just happens. You get added to the right things and if you leave a company, well, make sure you get removed from the right systems as human being.
Eric Boduch: That's just a big fire button too. We've a higher fire button. I feel like that meme that's going around which inaudible for more higher fire.
Jeremy Henrickson: Exactly. Right. But a lot of the work is in the middle, right? As people change roles and move from California to Austin or to Florida wherever they move to, and all of these career changes in life changes, they're extremely burdensome to manage and track in a manual way. And so to the extent that we can create a single trustworthy place where all that can happen, we think it's pretty cool.
Eric Boduch: And you can have consistent application of policies, like in a lot of cases with promotions there's a concern of are you treating people fairly, both from a diversity perspective, but just frankly, from a fairness perspective, based upon the role, what they're doing, where they live, what they're doing for the company, maybe how they sit in some nine box or whatever you use for performance management. But then that can all be automated on the backend and then has a lot less chance of human error, less chance of bias in the system too.
Jeremy Henrickson: Yeah. And less chance of human error, less chance of bias and a single shared view. You don't have to ask 14 different people or three different people to get the information you need. It's like everyone is enabled to run the exact same reports across that full set of data. And the fact that everyone is operating on one set of data, on one report and can look at those things in a consistent fashion makes a huge, huge difference in efficiency if nothing else.
Eric Boduch: Awesome. We'll get back to some of the stuff you're doing at Rippling, but before then, Coinbase, right? So obviously in the news recently, huge offering. Big run- up in valuation, which says a lot about both Coinbase and crypto as a whole. Talk to me about your time as CPO at Coinbase.
Jeremy Henrickson: Yeah. Wow, what a ride? I feel incredibly fortunate to have been there at the end of the crypto winter in 2016, all the way through the unbelievable round- up in 2017, the next winter. And as we've gone up, it's incredibly fun to help invent a new industry and to provide some of the infrastructure to make that industry successful. We have this very long- term vision at Coinbase around open financial system for the world and that continues to be this incredibly long- term orientation on where things are going to go. And because that North star remain the North star the whole time, everything else, although the rapid movement and the change in the industry in the rise and fall of NFTs back in 2017, early 2018 and they're revised now. All of these things, and then trying to build a company in that context, right? One that is doing something valuable was just a lot of fun. You're doing it with a set of people who really believed in that future and a set of people who are signing up to do it in a way that we felt was morally and ethically right on the side where the regulators, helping people understand what this really was, helping people understand what the potential could be. And so it was a really, really fun ride.
Eric Boduch: Yeah. I have to ask you, what's your thoughts on crypto? And maybe there's different aspects too, to talk about because I think of Bitcoin is maybe just an asset class where I think of Ethereum as something that actually can be more transactional at least by design. I don't know. I'm definitely no crypto expert at all. If I was, I'd probably be a little richer than I am now, but I'd love to hear your thoughts.
Jeremy Henrickson: Yeah. So actually, I don't have a strong point of view on any single cryptocurrency. People sometimes ask me like, " What should I invest in? What should I buy? What should I not buy?" And I actually don't have a strong point of view on that. But you have a strong point of view on that.
Eric Boduch: Talking point to the move.
Jeremy Henrickson: Yeah. inaudible. I believe in the long- term future of crypto and the reason I believe in it on many dimensions, whether it's as a store of value or something that will ultimately be transactional or something that'll enable use cases that have never been able to be done before is that it is more efficient and long run, easier to use than the current financial system in many ways. So whether Bitcoin is the long- term winner or something else is, or Ethereum does really well, because it's amazing platform in which the top of what you can build things like NFTs and the like or something else entirely. I think of this in the same way I think of the metiche figuring out financial systems in 14th century or whatever, 15th century Italy, right? We're at the very, very, very beginning of what is a decades long journey still and how exactly it's going to shape out, I think we'll see, but that it is going to shape out in my view is inevitable on a sufficiently long timeline.
Eric Boduch: Hey, you can see my crypto expertise with those, your doggy. I don't know. I mean, you got a dog down there come on.
Jeremy Henrickson: It's got the dog. It should be doggy for sure.
Eric Boduch: So talk to me about NFTs and what you see in that space now. And frankly, I'd love to think about this from a product lens too, like the product managers out there. How should they be thinking about blockchain and their businesses today or should they be waiting? Is it something that as a product person, you think it's important for the product managers out there to have a stronger set of expertise around?
Jeremy Henrickson: I think that it is important to understand what it is and what it isn't. So a lot of people get into crypto. Well, that's not very great advice because crypto is a very subtle thing and you have to go all the way to ground to understand what's actually going on sometimes. And so my advice to people is like something like NFTs, which I think are this amazing ability to represent something that's unique on a blockchain and track provenance and track it over time is really extraordinary, and I think it's going to enable all sorts of interesting things over time. And so is it important for product managers to know it? Yes, if they think it's going to be meaningful to them, but what I wouldn't recommend is just jump into it and support. Like really find people that know more than you do on it and go deep. Understand what it really is and most importantly, what it really isn't. Understand the use cases that could be meaningful and those that are not. Like the fact that there's an incredibly expensive piece of art bought as a one- off as an NFT is. Super cool, but that's not the dominant use case. That's not the way in which this thing is going to grow and scale with the masses. And so I think if somebody's really into this, they got to figure out the details.
Eric Boduch: Now, what about ownership with NFTs too? I mean, I think of things like the MBA and what you're doing with top shots where it seems like you don't actually own anything. I mean, you own the digital representation, but you can't even, at least to my understanding, put it on your own website and point to it. Like you own it, but you can't do anything with it versus real digital ownership of the underlying asset where in theory you could monetize it, like have a digital art museum or what have you. What's your thought on how ownership plays a role in the whole NFT space? Not just ownership of the asset, but I guess ownership of the rights associated with the asset.
Jeremy Henrickson: Yeah. I think it's a tricky area and to be candid, I am not an expert in this area. I've been heads down in Rippling for over a year now.
Eric Boduch: I'll get back to that.
Jeremy Henrickson: No, it's fine. But I mean, my view on this is the same in my view in crypto is like a store of value, which is that it's really early days and we're sorting out these things like what's true ownership? I don't think ownership means one thing, you need to define it, right? Can ownership mean you have control of the asset, but not the rights to do a bunch of other things? Well, with an NFT you can make those rights really explicit, right? You can be really fine grained about the extent to which people have ownership and really explicit about it now in a way that with traditional, you can't. It'd be funny that ends up being adjudicated legally, as opposed to adjudicated and code. And I think that the ability to encode these things and have them have really clear rules that are like locked down is incredibly powerful, but it's going to take a lot of iteration. We're not going to get it right for everything upfront, there are going to be missed steps, there are going to be things that work well, there are going to be things that don't work well and over time, hopefully these mechanisms will become increasingly robust and increasingly well understood.
Eric Boduch: So are you bullish on NFTs?
Jeremy Henrickson: Yeah. I mean, I wouldn't buy a 67 million piece of art or whatever the price was, even if I could, but I think that the long run absolutely. I think they represent a really cool opportunity. I have a couple of little ones and myself from the good old days, the crypto kitty days.
Eric Boduch: Yeah. I have a friend who worked on open space, so yeah, I know.
Jeremy Henrickson: There you go. Yeah.
Eric Boduch: Back in the early days. Four or five years ago, maybe. Maybe more.
Jeremy Henrickson: Yeah. Ancient times really.
Eric Boduch: Yeah. Ancient times by the end of the two days, it feels like. Coinbase going back to your story there, hypergrowth. I'm going to assume you're going through the same, I won't say problems, but opportunities in Rippling now, too, right? Managing product teams when you're having a huge amount of growth. Talk to me about that process and how it's different than the linear growth or the slower linear growth, I guess.
Jeremy Henrickson: Yeah. So slower linear growth. I mean, Coinbase certainly had the most explosive growth in 2017. Our customer volumes went up like 40X and that was a pretty incredible ride. I think it's a question of focus and clarity, right? I think the thing that as you grow a team quickly, or if the scope of what it needs to accomplish increases dramatically, the thing that can break down very, very quickly is communication and focus. So one of the things we did a lot at Coinbase during those years of acceleration was just every couple of weeks for every major product initiative, we are in a room and rethinking on where it was that we were going. And we had to do that for two reasons. One is just, the team was evolving so rapidly that it was just very helpful to have those refreshers. But secondly, in crypto the external world moves extremely quickly and people's understanding of that world moves extremely quickly and you can't wait for a month or two months or a quarter to let that influence what you're doing. And so this much more rapid cycle was crucial, which meant of course, that when we were hiring product leaders, we had to hire people who enjoyed that world. You couldn't hire somebody who liked the stability of we're going to plan something now and six months later, we're going to look at inaudible. It just wouldn't work that way. And so you had to find people who loved the chaos, could embrace the chaos and bring just a little bit of order out of it and get to make the next step forward and then look around again and see like, " Okay, what do we need to do now?" And that created a pretty specific cultural aspect that I think is unique to companies that are in the crypto space.
Eric Boduch: So what advice would you give to product leaders at startups that are going through that hyper- growth or even the product managers there that are going through it? I mean, obviously you touched on communication and maybe over communication. Other advice?
Jeremy Henrickson: Yeah. I mean, I'd say first there's communication, but there's also alignment. So particularly at a relatively young company that's growing quickly and particularly one that has a product or vision oriented CEO, that connectivity has to be really, really tight. That person who is responsible for the product, whether they're responsible for an entire product line or for this feature down here needs to be an absolute lockstep with whoever the funnel final arbiter of product is. Whether that's Brian at Coinbase or somebody Parker at Rippling, both of whom were very product oriented leaders. And my job as the overall leader was not to get in the way of that, but it was to facilitate that and make sure we were always lined up and then of course have my own opinions. And so my advice to people is make sure that line is clear, right? Make sure that you whether you're a new PM or whether you've been around for a long time, that that full line down from CEO all the way down to local PM is as clear as it needs to be in order for that person to do their job maximally effectively. Because if it's not, what you have is a bunch of people on the ground, be they engineers or PMs or whatever who are all sailing in slightly different directions. And getting everyone back together, again, takes way more energy than keeping people aligned in the first place. So I think that's really the big piece of it for me.
Eric Boduch: Yeah. That makes a lot of sense. What about your biggest lesson learned at Coinbase specifically when it came to products?
Jeremy Henrickson: I think the biggest lesson I probably learned was that rapid iteration is king in a fast moving market. It was much more important to build something quickly, get it out in the market, get real market feedback than it was to try to get something exactly right ahead of time. And this is particularly true in crypto because everyone has a thesis about what's next. Everyone has an idea about what's going to be successful and what's not. And those theses are sometimes backed by a little bit of data, but are often incredibly anecdotal. And so the only way to know for sure is to actually get something out there and test it in the market and see if it succeeds or not. And so we got really good and I very much improved my own sense of rapid iteration to get that feedback in a reasonably quick way so we could react to it.
Eric Boduch: It's interesting you mentioned that too, because I was just talking on a podcast or a clubhouse the other day about rapid iteration, not just from the product standpoint, but from the marketing and the pitch standpoint. In the early days of Pendo, I just love giving demo. If you had a product in your title, whatever you were assistant product intern, I wanted to show you product. It didn't matter if you were running product at Microsoft or the dude just out school, that's stabling in product. Wanted everyone to see demo because it wasn't just about iteration for the product. It was iteration around how we pitched, how we told the story, what resonated. And it was just like you keep doing these repetitively over and over again, and you learn just a ton, way more than you're going to do from small datasets to filter up through like a salesperson. So it's interesting too, that you talk about iteration. I think it's so important across the business in general, when you're small to just get reps in whether it's product shipping reps, whether it's marketing reps or the sales pitches, get your reps in so to speak.
Jeremy Henrickson: Yeah. I think that's totally right. I think not only does it help the product and the pitch, but it creates a consistency within the org too, because with everyone actually demonstrating the product, you get a much stronger sense of where it's working and where it's not, What pitch works and what pitch doesn't, and particularly demonstrating to engineers to get them to understand what's really going on. Because they are generally speaking, not as close to the customer and it's really easy for their mental models to get out of sync with the customer. It's hard enough for a PM to stay in sync with the right market mental models should be. But for an engineer who's spending most of their day trying to figure out what's the right architecture for this thing? It's way further for them. So the closer you can keep them to product and demonstration and to design and to that user experience, I think the much better off the company is as well.
Eric Boduch: Yeah, we'd get some of our external engineers, even joining on some of the little road shows we do for the product meetups and just hear what customers have to say, what they ask, what questions they have. What they say when they see the product is super useful especially early. It's harder and harder as you grow and that's by as you have more and more product managers. They're filling that role for engineering to some extent, and then today's age, they can listen to Gong calls. So it's cool. " Hey board, on the weekend, you want to learn a little bit more about what customers are saying? Here's like 50 Gong calls that are all recorded. Feel free to listen."
Jeremy Henrickson: I know. Totally, and it's this great window that didn't use to exist in the past. You had to tell the engineer, " Okay. You're going to take Tuesday afternoon off because we're going to go visit customer X that at site Y. And now it's just like, " Nope, we were on Zoom. It's recorded, go check it out." It's not quite the same as being live, but it's certainly better than nothing.
Eric Boduch: Yeah. I mean, you can't ask questions, but you can hear what people have to say. It'd be good to go back there and easily ask questions, get responses. So what does the team look like at Rippling? You're running both product and engineering, what's the ratios look like?
Jeremy Henrickson: So the way we're organized internally is as I think you may know, we have like eight or so products in- market separate freestanding products like payroll, which competes against its own industry like insurance and benefits competes against its own industry and so on and so forth down the line. And so each of those is a team with a head of engineering and a head of product. And then of course in typical engineering fashion, we have the underlying core platform team and all the rest. And so I think the ratios depend on where you are in that spectrum. Obviously, our infrastructure team doesn't need PMs, but the product teams absolutely do. My overall personal philosophy here, which I think aligns well with what Rippling needs is that one is you keep PM pretty thin, not too high of a ratio, because what it does is it forces focus on the right set of things and also encourages the right sorts of PMs, right? Particularly for Rippling, it's an incredibly entrepreneurial place. And so you need product leaders who understand what it means to operate at that tempo and to operate with imperfect data and to make decisions quickly and all that stuff. So the ratio on a product team ends up being something like one to 10 somewhere around there. I think there's cases where it can be even lower. I think there's cases where it needs to be higher and it really just depends on the specific nature of product and where it is in it's lifecycle.
Eric Boduch: And how does design fit into the ratio?
Jeremy Henrickson: That's a good question. I think in my ideal universe, it's roughly one- to- one with PMs.
Eric Boduch: Because I understand PMs and then to 10 say on average.
Jeremy Henrickson: Yeah. And maybe the designer ratio needs to be a little higher than the PM ratio just depending on how user- facing the product is and how much work there is there. So, but roughly the same. I think in our case, designers are brought in extremely early in the process, like Parker as a incredibly product focused CEO, often the beginning of a new feature, it might be like an email from him to our head of design and then we'll mock it out there and try to figure out what we actually want. And then product gets drawn in, in that same conversation. And then only when we actually know what we want from an end user experience, does engineering pull in and that saves us a whole bunch of time going down the line.
Eric Boduch: Now based on the way you answered that question, I'm thinking design sits outside of the product already. Is that true?
Jeremy Henrickson: That's right. So product and design are separate org, both reporting to me separately.
Eric Boduch: Okay. So design, product edge all report to you?
Jeremy Henrickson: Yeah, that's right.
Eric Boduch: Yeah. Got it. But at the same time, design is separate from product. So got it.
Jeremy Henrickson: That's right. Yeah. I mean, it's its own discipline and it requires its own things crosstalk
Eric Boduch: Yeah. No I've seen a lot of CPOs that they would own design too, or engineering as a separate org reporting to the CEO or chief product officer, VP or CTO reporting to CEO and design would fall under the product org there. In some cases, it's completely separate where product and design all have separate leaders reporting up to another person.
Jeremy Henrickson: Yeah. My view here is that the actual reporting structure and organizational structure in general matters less than particularly in our scale than how do people actually work together? What's the actual working model for here's a product and we need to build a new feature. How does that actually happen? And the structure on top can facilitate good or bad behavior in that. But it's less important most of the time. crosstalk
Eric Boduch: That's what I was going to say. The distraction on top can facilitate good and bad behavior. I think we've all seen examples of that. So now you talked about different engineering leads, different product leads in the different groups payroll, et cetera, et cetera, you end up moving engineering teams between them or is it more or less stayed? How dynamic are your engineering teams? Do they flip between product lines depending upon pushes in a particular area or is it more or less static?
Jeremy Henrickson: I would say people definitely move, but not on a whim. It's a pretty controlled movement because each of these product areas is quite different from each of the other ones. I mean, they all share a common substrate, but engineers tend to get expertise in one area and get really good at it and tend to like the team that they're on. However, we also very explicitly like people to move every once in a while, because the best way to learn the lessons of the things that went well and did not go well in other team is to have people actually jump from one team to another. And so those jumps are deliberately a part of our culture as well.
Eric Boduch: Yeah. Do you jump a whole team or did you jump people? Like where do you move? If payroll is having a big new release, would you move a team off of XYZ product to payroll and be like, " Hey, you're going to do this for the next six months." Or is it like, we want people to move off of one team, say the payroll team to another group?
Jeremy Henrickson: Yeah, very much the latter. If I had to say, " Hey, look, this whole team over here needs to shut down and move over here." I'd be leaving on the first one some longer- term set of stuff that was now just going unstaffed and institutional knowledge of that thing would drift away and it'd be very bad. And so you do that if you've have to. I'm sure there are times I haven't had to do that in the 14 and a half months I've been with the company. So it's more like, Oh one or two people can move from this thing to another thing. And within these verticals, we try to be relatively self- contained, which is pretty easy to do because they're all growing right now. So we're not at a point now where it's like, Hey, one of these teams has hit maturity and doesn't really need to do anything. So it's shrink the team and move a handful of people from here to there. We're not at that stage yet and I don't think we're going to be for awhile.
Eric Boduch: Interesting. Cool. Talk to me about scaling. Specifically, you've gone through that a few times now, right? Big challenges in scaling, especially as we're talking more and more about remote and global teams.
Jeremy Henrickson: Yeah. Scaling is hard, but for some reason I'm masochistic enough to have made a career out of it. I think scaling is fundamentally a human issue in my view, but the problems that I've seen, the challenges, the opportunities whatever you want to call them have been relatively similar across Guidewire and Coinbase and Rippling. They all have their own special flavors because the companies all are culturally a little different, but a lot of it just has to do with how humans interact with one another when they have a shared cause. How many people can communicate with one another accurately within spend time, how well do people know each other as the org scales more and more? And so, I think, the first thing to get right from my point of view is see ahead of the curve and hire the right people and that also can see ahead of the curve or promote people up who have the insight and can do that. And that's hard and certainly I don't get it right. You do your best and you keep growing it. And then product in particular, the nature of how product works, I think changes as an organization scale. So somebody who's like a great product leader when you have a team of 10 engineers and that's the whole company and they're operating in that entrepreneurial mode is different than the product leader who's going to come in when you're 1, 000 person company and you now have a team of 80 folks and you are working on these really big, abstract, strategic priorities. There's things that shouldn't change in that span, but there's definitely things that do and helping people grow into those roles if they want, or find other roles that are really very good for them as they go along is a big part of the game, I think.
Eric Boduch: Yeah. And the big challenge, right? Finding the people that are good. I mean, because product lines change too, as far as maturity, along with the organization scaling. You might have a new product, it's all innovative and then at some point it becomes incremental additions, right? So crosstalk that are different.
Jeremy Henrickson: That's exactly right. When I joined Rippling as an example, there were really two PMs at the company. Parker had been the Uber PM the whole time, but that obviously wasn't going to scale. And so as I've been building out the product organization there for the last year or so, what I've told all the incoming product leaders is, look, what I need, my ideal case for you, perspective product leader is number one, that you can operate in this highly entrepreneurial fashion without a net, without the infrastructure of a mature product organization and a mature product marketing function, a mature sales. You're going to have none of that to start with, but I would like you to be able to grow into that future state leader. That future state leader, where it is 1, 000 person company and your own product line has tens to hundreds of millions of revenue on its own. Those are two completely different modes. I think one of the things I can do at this point in my career better than I was able to, when I was younger is identify people who can span those 10 of two parts of the curve. One of the nuts we've been trying to crack here is finding those people and bringing them on and giving them the opportunity to really own things in a way such that they can go through that growth curve.
Eric Boduch: Now, as you're building this framework of PMs, do you think about getting people with different backgrounds? And I don't necessarily mean just from a diversity standpoint, do I do think that's part of it and I think it's important, but coming from different backgrounds, as far as domain expertise and maybe even characteristics like personality characteristics, do you start building out that mosaic of product teams that have different strengths?
Jeremy Henrickson: Oh, for sure. In aggregate, that's something I think about a lot that over time I need to a group of product leaders who have this range of skill sets, some who are really good at it. The strategy and business folks side have some that are good with customers. Something really good at the detailed feature design. There's some table stakes things you have to have for everyone. On the other hand, for any single PMI hire, I'm just trying to find somebody who is going to be like a great fit for that role right over there. And so it's a little bit of like that first thing is always in the background and actually finding the right person for a particular role is the most important thing. But I think the reality is that this works itself out in some ways, because each product is a little different. Each product needs a different emphasis. I mean, if you think about Rippling's business, one of our products is insurance and benefits. That's an operationally really heavy role. There's like you have to be able to talk with insurance carriers and all of this stuff and the product leader who's going to understand that part of the landscape and be able to build product to suit is different than for example, the kind of leader who's going to be really great at building a time and attendance system which has a really different focus. And so I ended up accumulating that inaudible of skills over time, as I look across the various products and find leaders for those.
Eric Boduch: You mentioned table stakes. What's in the table stakes group as you're hiring product managers? What's the thing that no matter what they have to ask?
Jeremy Henrickson: Intelligence, number one. The ability to like take this incredibly complex space and synthesize it and reduce that complexity down to something that is understandable, would be great for the end user, whoever that end user happens to be. So that's non- negotiable. Second, a mind that thinks in terms of clear priorities, right? Can distinguish between the things that are nice and the things that you've got to do. The things that are imperative culturally for the company and the things that are not. Three, somebody who gets design. The product leader has to be able to work with where they're designing counterparts and work with them to build a product that is going to be a great product and that's also non- negotiable. And then fourth is communication. The ability to hear things appropriately. Some words come out of someone's mouth and what did you actually hear out of that? Did you hear? What the words they said, or did you hear the intent behind them? Did you hear the frustration in it? Like all of those different dimensions of listening and then being able to on the other side of that, understand it, interpret it, distill it and communicate it out to everyone else as you're either representing that person's point of view or as you're making decisions about what things to build on the basis of what you're hearing from all these constituents. And I think that's a pretty rare gift finding people who are going to do that.
Eric Boduch: Yeah. So then it makes me think too about decision frameworks, right? How do you think about making those decisions with priorities? Whether you're contemplating whether to build this feature or not, or how you're going to respond to this customer requests. Do you have decision frameworks you've put in place at Rippling?
Jeremy Henrickson: I do not have a single framework that I use repeatedly aside from having a pretty draconian take on prioritization. The decisions, I think particularly the case like Rippling, where it's a bunch of different products, all of which are in different places relative to the market, that it's more about getting the right people in the room who have in- depth knowledge about the specific customer and specific market they're dealing with. I'm trusting them to come up with the right frameworks for that. And so of course, I have all sorts of suggestions when those kind of conversations come up, sometimes the right framework is to do some numerically based waiting thing. the right decision framework is just purely anecdotal because it's so early that you can see the big flaming white elephant in the sky and it's just obvious you should go there. Or sometimes it's much more subtle than that and you're trying to understand the competitive landscape and do our differentiators matter here or not? And so I like having a set of tools in the garage and I pull out the hammer or the screwdriver or the wrench or whatever I need at the time that I need it, but I'm not too dogmatic about it.
Eric Boduch: Hey, when I see a flaming white elephant into the sky I'm running towards it. You also mentioned something there that made me want to ask a second question and that was draconian approach to prioritization. Expound on that.
Jeremy Henrickson: Yeah. So I think particularly in businesses where you could do a lot. Where the surface area of things that could be valuable is very large. In crypto it's like, Oh, here are all these different ideas, the cool things we could do to advance crypto to help Coinbase help our customers. Or in Rippling, it's like, here are the 32 other products we could build and the features in each one of those products. You have to have a lens that says, " Okay, first here are the things if we don't do them, they will actually kill the company." Let's start there and holding a really hard line to that. And the next line is, " Okay, what are the specific things we've said are the most important things we need to accomplish in our business, aside from survival?" What are the very most important things and what actually aligns with that category? And then you recursively do that down through each product. So here's what is with the company, but now for our payroll product, how is that true? For the filings team within our payroll product, how is that true? And you have the same prioritization scheme across everything. I don't care if it's an idea that product people have. I don't care if it's a refactoring project out of engineering. It's the same strict orientation. What's fascinating about this exercise every time I do it is people inevitably want to believe, some people anyway, that their thing is more existential or closer to the existential side of the spectrum than it is. But when you force them to say under limited resources, like how are you actually going to stand up that thing that you think is critical against this thing you hadn't even thought of yet that somebody else thought is critical. It forces everyone to start thinking like a product leader. And that I think is gold because it creates an alignment in the organization that helps everyone focus on the true things that are existential and that really matter. It helps eliminate the set of things that are really nice to have, but fundamentally not right and focuses the debate where it should be, which is on the things that are on the margin in between. And then like, which ones of those things should we do? Which ones should we do? And what does that mean for how we should hire? What does that mean for how we should allocate people? I love that exercise.
Eric Boduch: Yeah. I can tell. I'm a big prioritization guy, myself too. So I think it's important to have the right perspective, like you said, and to start with, " Hey, let's make sure we're going to stay in business." crosstalk
Jeremy Henrickson: Yeah, let me add what I've done them to that though, which is that it can be too tempting to overly rely on the framework. Because if you end up with a consensus driven framework, you end up with a really diluted product roadmap. And so it's important on top of that to have a clarity of vision and say, " Irrespective of all that stuff, this is where we need to go." We need to get to a place no matter how hard it is. No matter how improbable it seems.
Eric Boduch: You need to get that flaming white elephant.
Jeremy Henrickson: The flaming white elephants. I've never used that phrase before, but somehow I think it's going to stick. The flaming white elephants where we need to get to, and that can override a lot of these otherwise perfectly rational prioritization based arguments because fundamentally, does that lead us there? No. Well then no matter what the prioritization says, either the privatization is the wrong answer or something else is fundamentally broken and let's go hammer on that.
Eric Boduch: We have a dinosaur here as a mascot that came out of just a strange set of occurrences. I feel like a future company and now I'm going to have to have a flaming white elephant first for something for at least a little while, even if it's only funny to me. So now this has been a blast. I mean, I had a great time but we're running out of time. So why don't I get to two final questions about you? First, what's your favorite product?
Jeremy Henrickson: I've loved games my whole life and I'm a huge board gamer. My wife and I met over board games and she beat me a couple of times, very early when we were dating. Because she consistently beat me as we were early dating and so it's been a part of my life. So my favorite product, actually the one I use more than any other is a game on iOS and Windows, everywhere else called Through the Ages. It's my favorite board game ever and the implementation of that board game is sublime. It's just really, really well done and just works the way it should. Every element of it is delightful with one exception of a new thing they introduced. But it's a phenomenal product. I know it's not what everyone to identify with, but it's great.
Eric Boduch: No, but I'm going to have to check that out because I do like board games and I'm yet to play that one.
Jeremy Henrickson: Oh, highly recommended. Highly recommended.
Eric Boduch: I have to ask too, what board games was your wife consistently beating you on when you first started dating?
Jeremy Henrickson: There's a game called Goa which we were playing a lot back then. Spice trading simulation basically. She beat me like four times in a row and the fourth time I got pretty mad. And she's like, " I thought you were letting me win." I'm like, " I never let anyone win." There you go.
Eric Boduch: I'm not sure what that says but we will get into that. One final question for you today, three words to describe yourself.
Jeremy Henrickson: I would have to go with father. That's my most important job. Strategist since I just love to keep these complex spaces and this doesn't align in form of the other two, but empathetic.
Eric Boduch: Love it. Love it. Thank you. This has been a blast.
Jeremy Henrickson: Thanks for having me. This was a lot of fun.