快速推进与应对不确定性 | Jeremy Henrickson(Rippling, Coinbase)
Moving fast and navigating uncertainty | Jeremy Henrickson (Rippling, Coinbase)
Jeremy Henrickson: It’s very, very tempting to float up here as a leader and say, “Hey, you take that hill over there. You guys do this over here.” When in fact, where you really learn where the challenges are, or the problems or the successes is by just being there with the people in the trenches on one of the things, whichever one seems hardest or most complicated. And so I try to do that as often as I can, and I found that I always learn a lot by going through that detailed exercise.
The Interview Begins
Lenny: Welcome to Lenny’s Podcast, for interview world-class product leaders and growth experts, to learn from their hard-won experiences building and growing today’s most successful products. Today my guest is Jeremy Henrickson. Jeremy is senior vice president of product at Rippling, where he leads the product and design teams. Previously, he was chief product officer at Coinbase where he oversaw 10 x growth of the product and engineering organizations and helped scale Coinbase during one of the craziest times in the crypto markets. In our conversation, Jeremy shares his lessons about maintaining velocity at scale, creating a culture of fast decision-making, the importance of product leaders going deep on a problem, and becoming world experts at their domain. What to look for in product managers you’re interviewing, why relying on frameworks can be so detrimental to your success, why you may want to avoid MVPs and instead designed for the most complex use cases first, and tons more. Enjoy this episode with Jeremy Henrickson after a short word from our sponsors.
Jeremy Henrickson: Thank you so much for having me. I’m excited to be here.
Crazy Days at Coinbase
Lenny: So I’ve heard nothing but amazing things about you and I’m excited to learn from what you’ve learned from your experience at Rippling, at Coinbase, and all of the products and teams that you’ve built. And so thank you again for being here.
Jeremy Henrickson: Yeah, super happy to be here.
Staying Focused Amid Chaos
Lenny: So I want to start with your time at Coinbase where you were chief product officer and you were chief product officer during maybe the craziest time in the crypto markets. It was I think 2016, 2018 when I was looking at the Bitcoin prices and it was like it went from a 20,000 I think in a matter of months. So I’m curious, what was that experience like, and in particular, what was like leading a product team through that experience?
Jeremy Henrickson: The strongest memories for me are during 2017 where crypto, which had kind of been at its nadir in early 2016 and slowly started climbing out, just kind of took off and became a real thing in the public consciousness. And Coinbase, which at the time had an exchange just like on-ramp and off-ramp from fiat to crypto and back experienced over the course of 2017 40 x growth in usage.
Maintaining Speed at Scale
Lenny: That’s like a dream come true for a lot of people.
New Product Launch Playbook
Jeremy Henrickson: No, I mean it was both a dream and a nightmare and I was incredibly lucky to be working on it with a team of people that I could really trust and could stand shoulder-to-shoulder within the trenches. And it was a lot of learning about how you can rapidly scale systems over time and people like to trade crypto on Saturday mornings, so a lot of Saturday mornings just some new thing would break on the edges of the system and we need to get in there and work on it. And so it was just a lot of really incredible lessons about who you choose to work with and focus and making sure you have the right people in the room at the right time.
Thoughts on the MVP
Lenny: Okay. So let’s actually unpack a couple of those. So focus is really interesting and something people always talk about, but hard to actually do. I guess how did you keep the team focused? I imagine just everyone’s getting rich all over the place in crypto.
Jeremy Henrickson: Huh.
Global Payroll Product Example
Lenny: Things are breaking all the time, like how did you maintain focus on your team?
Jeremy Henrickson: Well, the first thing is you don’t talk about people getting rich. It’s a very technical, you talk about like its customers, it’s their money, and number one, it had to be secure. So there’s a guy named Philip Barton, a friend of mine now, and he is just this amazing security leader at Coinbase, and he was able to always put these decisions that we were making extremely quickly in context and say, “Look, these are the kinds of decisions we can make and still have it be secure no matter how fast we need to move.” And so security was always the number one thing. And then the second thing is focusing on both the kind of immediate nature of the issue. Hey, site is down or whatever, and resolving that, but also trying to set those in a context of where we need to go over the next six months. What are we actually shooting for? What do we believe the volumes are going to be? What’s it going to take to have everything from a user experience to the deep back end of the product that what would actually work for them?
Designing the Hardest Cases First
Lenny: What was maybe the biggest challenge as a product leader trying to keep people focused and everything on the rails as things were going 40 x?
Jeremy Henrickson: I think the biggest challenge was that in crypto there’s just so much uncertainty in general, simple questions like, is Ethereum going to be a thing, are the subject of debate. And no one actually at the time had an answer to that question. Lots of really strong opinions and so you have to be able to have those debates because lots is going on, but then you have to be able to come out of those conversations with a clear kind of company point of view that you’re all shooting toward. And while there may still be differing points of views and debates that happen on the margins, you go full speed toward this answer until you decide to go full speed toward a different answer. And I thought we were pretty successful at that at Coinbase and it wasn’t always easy.
The Compound Startup Model
Lenny: Maybe just a last question there.
Jeremy Henrickson: Sure.
Differentiator: Single System of Record
Lenny: Living through a time like that, a lot of people are going through these periods of just intense work and it’s like, holy moly, this isn’t crazy stressful working, like incredibly long hours, but then you look back at those times, and end up being some most important meaningful periods of your career.
Jeremy Henrickson: Mm-hmm.
Culture of Fast Decision-Making
Lenny: I guess one is that, is that your experience too? And then two, I guess is there any advice for someone that’s maybe going through something like that of just here’s maybe the silver lining of being in a period like that?
Jeremy Henrickson: So it’s hard, right? It wasn’t always easy. I had a new daughter who had been born just a few months earlier, really tough to balance those things, but I’ve always loved the rate of learning. And so it is those experiences I feel that have most sort of accelerated my own personal growth and personal learnings because it’s in the crucible of things being hard. And so I think when people are going through those times, it’s nice to take a step back and talk with friends or whatever about what’s really going on and setting it in the context of, hey, three, four or five years now from now when we look back on this, you realize, wow. A, we did something amazing with that time. And B, we learned a lot and we were able to take that with us into whatever we were doing next after that.
Making Your Company Move Faster
Lenny: Before our chat, I’d asked you what people ask you for advice most around, and you said that people often ask you for advice on how to maintain velocity at scale, which is something every founder and product leader is always striving to do. And so what have you learned and what do you tell people about maintaining and maybe even improving velocity as you scale?
Jeremy Henrickson: I think there’s a lot of different answers here, and I think a lot of them are very specific to the nature of the business that someone’s in, like different businesses can maintain velocity in different ways. I think there’s kind of a universal truth that you want small teams with clear missions. Right? If there’s 300 people trying to work on one thing, the just sheer communication challenges, Dunbar’s number, all of those things come into play and it’s really, really hard to act quickly. And so having smaller groups of people breaking down what is always a very, very large problem into sufficiently small bits that small groups can attack wholeheartedly and minimize horizontal communication, I think is the first thing. I think the second thing is that to the extent it’s like a technology problem. The more you can bake into a clear platform, it reduces the decision-making complexity for everyone who’s working on the domain part of the problem.
And so a clear like a platform with a clear interface [inaudible 00:10:12] easy to use in all the ways that both engineers and product people want it to be easy to use, simplifies the space in which people have to think about these problems. And that’s not always easy. Platforms are not, you can’t just write a platform and hope it’s going to work for the products. It’s very much an iterative thing, but the more one can invest in that and have the right kinds of people who are capable of doing that sort of both systems thinking and product thinking simultaneously, I think is really important. The third thing, just from a leadership point of view is diving deep. Right? It’s very, very tempting to float up here as a leader and say, “Hey, you take that hill over there, you guys do this over here.” When in fact where you really learn where the challenges are or the problems or the successes is by just being there with the people in the trenches on one of the things, whichever one seems hardest or most complicated.
And so I try to do that as often as I can. And I found that I always learn a lot by going through that detailed exercise. And I think the last thing is it’s just making sure that teams have the right distribution of experience and seniority. Sometimes you get a team started and the team is perhaps doing something that’s zero-to-one and they’re amazing at all this zero-to-one stuff.
And then two or three years later, those same people are trying to scale the product to millions of people and it turns out that A, they don’t like that part of the job as much, and B, maybe they’re not as good at it. So I think you [inaudible 00:11:40] constantly look at the team and make sure that a people are doing things that they love and if they’re not like, Hey, we’ve tried this other thing instead and recalibrate the team and make sure the right kind of skill sets are there. And I found if you do all of those things and then have product leadership where we’re saying this is what we need to do and very, very clear and precise on what needs to be done, then you can usually actually even accelerate over time because you bake more into this platform, it allows your engineers to do more with less, and that’s always pretty amazing.
Origin of the Go See Principle
Lenny: Okay, let me dig into a couple of these. These are really great.
Jeremy Henrickson: [inaudible 00:12:10] please.
Never Delegate This Step
Lenny: So with the small teams with clear missions, is there an example of that at Rippling or Coinbase where that was a really good example of this being true?
Jeremy Henrickson: One example is maybe three years ago when I was just starting at the company, we decided that we needed to build a time and attendance product, lots of market demand for us and that we hadn’t built it yet, something that many customers need. And so there were a bunch of ways we could have chosen to do that, but the way we did it was to say, look, let’s find one engineer, really talented systems engineer who’s actually capable of doing kind of product thinking and have Parker, CEO also spend time on it. And you start there and Sachit brought a few people on with him.
And those four people over the course of maybe nine months or so, built a time and attendance product. It was the only thing they were doing. They didn’t have to worry about what was going on with our payroll product except to the extent they had to integrate with them a little bit. They didn’t have to worry about what was going on with the benefits team or our IT products. They were monomaniacally focused on this one thing and then identifying the places where yes, you, there’s connectivity to the rest of the suite, and that allowed them to move extremely quickly.
Leaders Must Make Right Decisions
Lenny: How much of that was Parker being on the team, helping them unblock everything versus being very small and focused?
Jeremy Henrickson: I think it was mostly small and focused. Obviously, Parker can do things and unblock them in the way that only a CEO can and that helps. But the thing is at Rippling, like we’ve now replicated that a dozen times. That’s our model for starting new things. And so it can’t just be him unblocking things, though he does unblock things. It’s more that this pattern of having these small groups be able to do things and then being able to have go to those people, whether you’re Parker or somebody else in the company, and be able to say, Hey, how are things going? Or are we working on the right things? Or let’s see the latest designs for that thing and comment on it.
All of those things can happen just at a much greater tempo than if you’re trying to go three layers down into the org and do things. I think that’s the other, maybe the key point here that everyone is exposed senior leadership, yes, we have a management structure because you have to, but that management structure does not interfere with the ability of anyone anywhere in the organization to look at what’s actually happening. And that happens very directly.
The Global Expansion Decision
Lenny: So let’s talk about that model you just described. So what is that model? So this is how you approach new products, and I know within Rippling there’s many, many products and features we’re going to talk about this. And you’re saying that you have kind of an approach to adding a new business unit essentially, or a new product feature.
Jeremy Henrickson: Yeah.
Surprises and Lessons in Global Expansion
Lenny: What is that model roughly?
Jeremy Henrickson: Yeah, so the model’s quite simple. In the vast majority of cases, we realize we need to build something and we have the one-page view of what that is. And usually, we’re lucky enough that the things we’re building sort of exist in some form in the industry today, not in the differentiated way that we can build it, but time and attendance is an example. That’s a well-known thing in the industry. There’s whole companies that do only that, right? So we start there, we find a single engineer who is extremely entrepreneurial, understands what it means to operate at tempo, understands what it means to make decisions with low information, understands how to work very, very quickly with a design partner.
So we have a design partner and we say, “Look, come into Rippling, spend a few months getting to know the platform first of all. So go work on this other team, understand what’s easy for them, what’s hard for them, how the platform works, how other products have been built on top of this. Go talk with other people who founded products here and understand what their experience is so that you can learn from and iterate on it, get an opinion about your product, and then start building it.”
And during this intervening time, they’re also recruiting a team of usually 2, 3, 4 other engineers who kind of have that same zero-to-one mentality and they start building. And usually over the course of six to nine months, we can get a product from a blank sheet of paper to something that is launched or at least that we’re using internally when we dogfood our stuff really heavily. And then it grows from there. And then sometimes when you launch one of these products, you get close to launch, you realize, hey, actually a team of five or six people can handle this product ad nauseam. Sometimes you have to bump it up. It’s like, okay, this thing’s about to go to production, there’s all these other things to do, the team needs now needs to go from 4 to 15 or something like that. Really depends on the product, but that’s the general life cycle and then you keep growing and scaling it.
Thoughts on Frameworks
Lenny: That is fascinating. So just so I understand, you find a founder type to take the lead on a new idea and do you recruit them internally or you sometimes find them externally just to focus on this product?
Jeremy Henrickson: Both.
Harmful Processes and Frameworks
Lenny: Interesting.
Jeremy Henrickson: Both.
Coinbase vs. Rippling Product Development
Lenny: Okay. And then you find a design partner for them to work with to figure out what exactly needs to be built. And is it idea pick one design partner or you try to encourage a few?
Jeremy Henrickson: Usually, it’s one. So there’s a designer, so we have a design-
Pressure and Memories at Coinbase
Lenny: Oh, design partner, meaning a designer, not a company that is like their partner in design.
Jeremy Henrickson: Oh, no, no, no. Literally, somebody who knows Rippling’s products, knows our component library, knows all of that stuff and is skilled and doing UX and interaction and visual design.
Hiring Product Managers
Lenny: Got it. Okay, design. Okay, cool. And then they basically with maybe a couple engineers, just that’s the team that initiates a new product line and then launches it, and then as it scales, it maybe grows the team, maybe not.
Quality of Interview Questions
Jeremy Henrickson: Yep, that’s right. And it’s pretty ad hoc, but every couple of weeks or something like that, they’re meeting with me or with Parker or whichever one of us is the DRI on it and giving feedback on the designs, having a critical life or like “Oh man, if I were using this as a admin, a small company or an admin at a large company, how would I feel about this? Would this interface work for me?” And so we were pressure testing it throughout that cycle and trying to get the balance of speed and comprehensiveness, right.
Lenny: This reminds me you’re also, I hear not a big fan of MVPs that you building products to further point. Is that true? And then if so, how do you think about the initial version of a product?
Kyle Boston’s Interview Story
Jeremy Henrickson: First of all, I don’t want to knock on MVPs. I think MVPs have their place extremely useful, particularly if you’re literally the zero-to-one company that’s never done anything before and you don’t have clear market validation. I think in our case specifically for Rippling, a minimum viable product would do a disservice to both our customers and to the very team that was building it. And the reason I believe that is that when you design a minimum viable product, you’re optimizing for speed. And in that set of optimizations, you are minimizing the deeper product thinking about what can fully differentiate our product based on not only existing kind of capabilities within our products and platform, but based on what it ought to do in the future.
And so it sort of limits product creativity, but worse, it leads to building the wrong thing technically, right? So if you’re only thinking through the simple cases and you’re an engineer and no one’s pushing you on saying, “Wait, what about that healthcare hospital administration case where it’s mission-critical life,” then you’re going to make a different set of as architectural assumptions, and then you’re going to build on those and you’re going to build on those for six months, nine months a year, and you’ll have dozens or 100s of assumptions built on top of those.
And it’s extremely difficult to unwind those decisions once you’ve built them into the product. And therefore we believe very deeply it’s like, sure, understand those simple cases. Understand if you’re a two-person company, you don’t need all of these other things. And what is the product going to look like for you to approach it but also understand what it would mean to have 10,000 people globally around the world with this ridiculously hard use case? What’s the model that would support that? And let’s make sure that as we’re doing the technical and product design for this thing, that it accommodates that view, even if we’re not going to support it in the first version, even if we make the product decision to say, “Look, we actually don’t need to handle that case right now.” You still build the product in a way that’s not going to prevent you from getting there in the future. And does that take a little more time? Sure, yeah. But does it save you time in the long run? Absolutely. Right. And so that’s our approach.
PMs Need a Business Mindset
Lenny: Is there an example that comes to mind of a product you build at Rippling or Coinbase of just, it could have been this really simple MVP and then ended up being like, no, we did the right thing by building it further along the spectrum.
Jeremy Henrickson: Yeah. So I think a great example of this at Rippling is our global payroll product. We could have said, “Hey, look, we just need to support this one country. We need to support, whatever, the UK,” let’s say. So we’re going to copy all of our US stuff, just replicate it and change all the things to be UK-like. That would’ve been the fastest thing to do to dramatically oversimplify, but that’s not what we did. What we did is we said, look, we need to launch a six countries and these are six super different countries that we want to look at. And they’re going to have different requirements from an HRIS standpoint, from an employer of record standpoint, from how you pay global contractors, from how payroll works, and we’re going to make a system that works for those countries. And there’s lots of downstream implications for that.
But what it means is that now our global payroll system, adding a country is, it’s not easy, but it’s a lot easier than it would’ve been if you had to continue to stamp out and replicate and then of course maintain all of these things that have very little underlying connectivity. And instead, what we have is 80% of the system is baked into our global payroll platform, and then the 20% is country-specific. And most of that specificity can be handled not by engineers who are very, very expensive to change things that are local specific, but instead can be configured by somebody that’s in compliance, by somebody that’s in legal that needs to get the right documents into the system. And all of that stuff can be handled by the system, which allows us to move much faster sort of going forward.
Interview Tips for Product Managers
Lenny: I’ve heard you describe this kind of idea as you encourage teams to design for the most complex use case first.
Jeremy Henrickson: Yeah.
Advice for Early-Career PMs
Lenny: Is that kind of the instruction you give these teams?
Jeremy Henrickson: 100%, many times. And so it’s one of these things that until you’re here, it’s a really difficult thing to kind of grok because A, it’s so counterculture to what the background that most people have come from. It’s like, no, no, no, don’t think about all those things. Just zoom in on this one case, use it as a wedge, and then grow from there. And this is one of the reasons that we have people, especially new people in these kind of founding roles, come in and spend a few months just absorbing the culture to really learn these lessons. And it’s one reason that we’re extremely high touch with kind of new products in their infancy to make sure that we just don’t fall into that trap, right? Especially because simultaneously with doing this, we’re like, “Hey, but we need to ship this as fast as possible.” Right? And so you want to get the balance of those two things right.
Great Leaders Often Change Their Minds
Lenny: So when I think about Rippling, I think of you got the culture is to do things the hard way and the right way. And an element of that is there’s this concept that I’ve heard that Rippling is this compound startup? What does that term mean? And then how does that approach impact the way you build product and organize teams and all the things you were just talking about of MVPs and build new products?
Jeremy Henrickson: The idea of a compound startup for us is that we’re basically a lot of businesses that all work together. If you think about the products we offer, we have payroll, well, there’s entire companies built just on payroll, insurance, and benefits, entire companies. That’s our entire life. In fact, a fragment of benefits is the entire life cycle of a whole company. Our IT products, device management, and identity management, time and attendance, each of these things are industries into themselves with multi-billion dollar companies serving each of them. The insight Parker had before he founded the company was actually the result you get that when you have that is that there’s all this data that gets replicated and copied and as impossible to keep in sync everywhere. The right answer is to have a single system of record, one place, one database where all of that information is resident so that each of these downstream systems can always have the right data at the right time.
And then you can build on top of that things like workflow and reporting and analytics and permissioning and all these kinds of underlying capabilities. So the idea of a compound startup is all of these different businesses benefit from being built on top of one platform. The activation energy for that is extremely high. So before my time at the company, Parker, Prasanna, the technical founder, and others, built all of the first versions of all these products and it was a minor miracle, they were able to do that. But having done it, we then had that platform and we could continue to build new verticals and new startups on top of that foundation.
Working with Product-Led Founders
Lenny: This touches on something that comes up a number of times in this podcast, which is the importance of differentiation. And it feels like this is the differentiator for Rippling. It’s not going to be just a better one of these vertical solutions like the main differentiators, we’re going to do it all and everything’s going to be so much better because it’s all in one platform. Is that kind of where the original idea came from or is there a different way to think about that?
Jeremy Henrickson: Yeah, I think that’s right. So I mean, the fundamental contention is having a single system of record is better for many, many, many reasons, right? The most simple of which is there’s a single source of truth and all of these other products can rely on it. But also, unless you start without assumption of everything being in a single system of record, there’s a bunch of other things you can’t do. You can’t build out a, I don’t know, a permissioning system that looks at the various attributes across all of these products. You now suddenly have to do an integration and each of these products talks different languages. You can’t do simple things, build a product and say, who is this person’s manager? Most products, you can’t do that. Most products you find some system of truth, export everybody’s name and email address and a spreadsheet, have another email address or another name, maybe an employee ID of who that person reports to and upload that to another system, which by the way is immediately out of date because organizational structures change all the time.
Whereas with Rippling, it’s always correct. We are the system of record. So all of our products, they’re like, “Hey, who’s that person’s manager.” And the system immediately knows. And that’s a very, very simple example of something that you can only do if you start with solve it to come back to an earlier point, like solve the most complex use case first, solve the fact that this data all needs to be in the same place. And so our ability to differentiate boils down to that one fundamental decision, which just allows us to do things that are literally impossible for any other company to do.
Lightning Round Questions and Answers
Lenny: What would you say is one of the most unique things about Ripplings culture that maybe you haven’t mentioned yet?
Jeremy Henrickson: I would say it’s fundamental, speed of execution. I think in speed of decision-making. It’s the thing that is probably the hardest to explain to people before they’re here. It’s hard to understand until you experience it. It’s like let’s not schedule a meeting for next week or tomorrow or later today. We’re in the middle of a meeting, we need to make a decision. Let’s either make the decision or if we can’t, let’s Slack call in the person that we need in order to make that decision. And we’ll be done with the decision today.
And like sure there are irreversible decisions you can’t make that way, but for the most part, we really value the tempo of decision-making and the speed of response. And no company I’ve been at any scale, 5 people, 5,000 people, has ever operated at the tempo this one does. And I think that our ability to continue to operate at that tempo, which is partly due to the fact that we are a compound startup and have these small teams independently operating teams and all the rest of that is a really differentiating thing about the culture of the company.
Closing Remarks and Conclusion
Lenny: I’m reading Kevin Kelly’s new book where I don’t know if you’ve seen his new book. It’s all these little tidbits of advice and one of his pieces of advice is that usually the best time to do something is right now. And that feels like that resonates with the way you all think. I’m curious just how you create that culture and ability to make decisions fast. Is it purely top-down founder, this is how they behave, or is there something else that you found as effective to create this culture of moving fast, making decisions really quickly?
Jeremy Henrickson: Obviously, a huge piece of this is Parker himself. It’s an attribute of his personality, he likes making decisions quickly, and it’s also a deliberate strategic decision on his part to have a company that makes decisions quickly. And so he models this constantly, right, in Slack, in conversations in person, and in every way possible. And there’s an expectation throughout the company. If you kind of look at our leadership principles, this ability to make decisions quickly is something that kind of everybody promulgates. But also I think there’s a number of things we’ve done to bake it in the way that we even do say quarterly planning. And the fact that there’s this timeline for decision-making that doesn’t leave a lot of room in the way that we expect people to know their domains, especially in product, right?
In product, you don’t own little feature, you own your product and you’re expected to be the world’s foremost expert in it. And if you are, what that means is instead of having to come back to people three days later with an answer, just off the top of your head, you can be like, “Yes, this is what I think I should do about that or give me 30 minutes, look something up and I can tell you what we need to do about that.” And so all of those things in combination just yield an environment in which these decisions happen very quickly.
Lenny: You talked about quarterly planning and you’re saying that there’s like, here’s the timelines we need to make decisions on these dates, and there’s a culture of just we stay firm to that. And if you don’t, then we’re going to move on.
Jeremy Henrickson: That’s right. And it’s shocking to people when we actually move on, right, that haven’t been here yet. It’s like, no, no, that date passed. You don’t get to retroactively make everybody react to the fact that you didn’t operate quickly enough, right? And it’s not a hostile thing, it’s just a, people just have to get used to. It’s a deep cultural principle. And the fact that everyone stands behind it just means it’s gets reinforced on its own, out of its own gravity.
Lenny: Do you have internal values that you’ve kind of outlined that are a part of this? Or is that not something that you find super valuable?
Jeremy Henrickson: No, actually I find them quite valuable. And actually our COO, Matt MacInnis, who joined the company about a year before I did, he has been the one to really drive this and you go to, I can’t remember this specific URL, but on Rippling there’s a search Rippling leadership principles. There they are. And they are really true to the culture of the company. The way we came up with them was to us a couple years ago, to introspect and to what actually made people successful at the company? Like who’s successful, why are they successful? Why do they enjoy being here? Or alternatively the opposite, like why people not worked out, why do some people not enjoy it here? And those are the things that are differentiating and those are the things that we wrote down.
Lenny: Are you hiring or on the flip side, are you looking for a new opportunity? Well, either way, check out lennysjobs.com/talent. If you’re a hiring manager, you can sign up and get access to hundreds of hand-curated people who are open to new opportunities. Thousands of people apply to join this collective. And I personally review and accept just about 10% of them. You won’t find a better place to hire product managers and growth leaders. Join almost a 100 other companies who are actively hiring through this collective. And if you’re looking around for a newer opportunity actively or passively join the collective, it’s free. You can be anonymous and you can even hide yourself from specific companies. You can also leave any time and you’ll only hear from companies that you want to hear from. Check out lennysjobs.com/talent. For someone listening that’s like, we need to move faster. And everyone always feels this, we need to move faster, we make decisions faster. What piece of advice would you give someone for helping them do this at their company?
Jeremy Henrickson: I think it’s really context-dependent, but I think it starts with whoever is in the role of making the top-level product decisions of them being one extremely clear about what those priorities are and more importantly, extremely clear about what all the priorities aren’t. Right? There are so many things that could be important or people can make the case for being important or whatever that are fundamentally distracting from the core mission of getting something done.
But secondly, for that person to go all the way to ground on it, we have one of the leadership principles is go and see. Right? So to look at the thing and then walk all the way to ground and talk with the engineer who’s writing the code on the thing. Because inevitably this top-level communication is insufficient to get to the detail of what matters and doesn’t matter. And you don’t have to do that everywhere, but if you do it in enough places, what it does is it creates a clear expectation of that kind of clarity across the board and forces everyone to up their game a little bit and just helps people understand what the expectation is. Right? And I think in the absence of those sort of clear expectations, it’s difficult for people to perform at their best. Right? And so we try to do that pretty frequently.
Lenny: Okay. I definitely want to spend more time on this, but before we get there, so go and see. I love that. And that actually has come up recently on a number of podcasts, just the importance of people continuing to ask questions and going to the end of what’s possible. Recent story was IO talking about building the cash card and going to the warehouse and watching the printings of the cards and things like that.
Jeremy Henrickson: Yeah.
Lenny: I guess first of all, do you have a sense of where that came from and why that ended up being so important to y’all? And then two is there an example of you doing that or someone you’ve seen do that and that leading to something really important?
Jeremy Henrickson: In the early days of our global efforts, when we were first trying to figure out what global payroll was, it was really tempting to say, “Oh, well we’re going to go into the UK and that’s going to be relatively similar to what we’re doing in the US.” But our kind of head of payroll went in and said, actually, here are the ways in which we knew it was going to be different, but here are the ways in which we didn’t anticipate that it was going to be different, which made us realize that we had to completely alter our approach for how we think about learning about each of these countries and going into them and having a fulsome experience.
And that then backs into things like, well, every country does tax filings, every country does them slightly differently, but how are we going to build a tax filing system that’s going to allow us to satisfy the needs of every country in which we’re going to run payroll? And it was only through that very early on deep look at how one country was actually operating and then doing the same thing with the next country that we were able to set in motion, all of those things. It’s not like we knew all the answers at that point, but it allowed us at a much earlier stage to put in motion a bunch of stuff that we need to do that then got subsequently much more clarified and much more precise over time.
Lenny: And so the leader of that team basically just went and studied the tax laws of each-
Jeremy Henrickson: Yeah.
Lenny: … country.
Jeremy Henrickson: That’s right, went all the way to ground. It’s like, okay, let’s go and open up the big old, I mean, it’s online these days, the big old textbook and look like it’s, or you’re in the United States, it’s like you have to go look at Ohio or Pennsylvania, which have all these little local city or county based taxes. And it’s incredibly instructive to look at just a few of those and think, wow, how do I think about configuring these change unannounced? Some city administrator or the city legislature, whatever they call them, they decide to change the tax rate. Well, how are we going to know about that? How are we going to change it? How are we going to change it so it’s effective at the right time?
And you don’t think about those things until you’ve gone all the way to ground and looked at how these things are actually worked, how they’re communicated, and how they’re thought through. And I think the same thing is true of every aspect of every product in different ways. Right? It might be a technical thing, it might be a design thing, it might be a compliance or a regulatory or a governmental thing, but whatever it is, that detail always exists. And unless you’re getting down there and seeing it and understanding it firsthand, you don’t really understand what your product needs to do.
Lenny: And I think an important element of this that’s between the lines maybe is don’t delegate this to someone. You may have a tax expert on the team, and I imagine many leaders would be like, go figure this out and tell me. And I think what you’re saying is you go do that and learn, become the world expert at it.
Jeremy Henrickson: That’s right. That’s right. You go do it. You go learn and then we can make the case for hiring the tax expert, which we do have by the way now. That’s an incredibly important part of our success is having that specialist but not before somebody with a product mindset. The tax specialist is amazing at tax, right? That’s what they’re, they love and that’s what they do, but that doesn’t make them necessarily a great product thinker. So the person with the product thing has to get into those same weeds first to really understand it.
Lenny: Do you give any guidance and just how much time to spend on all that stuff versus the regular day-to-day of, say, a product leader on a team, it takes a lot of time to become a world expert on the tax systems of many countries, or is it just there’s nothing more important than that, that is your job, and what are you doing not doing that? How do you think about it?
Jeremy Henrickson: I think it’s equally if a job is 80 hours a week, it’s 40 of your hours. I think that you can’t really understand a product unless you’ve gone there. Right? And yes, it takes time and you’re right, you can’t just ignore the other half of the job of communicating with the engineering team and writing documents or whatever, but what’s the point of writing a document if you don’t know what you’re talking about? And so we very deeply value that. And it’s one of the reasons that we keep, at least at Rippling, our product organization really thin. We expect a single leader to be able to know the full scope of the product. In fact, great product leaders can in fact do that because they have this native curiosity and interest and ability to absorb a lot of stuff. And it makes, it’s a lot of fun because now I have a group of people around me who are all really good at what they do and really understand what they do and that’s kind of just an amazing place to be.
Lenny: I’m looking at this list and I just want to keep asking questions about it. One of the sure principles that I love is it reminds me of Amazon has the same principle I believe, which is leaders are right a lot.
Jeremy Henrickson: Yeah.
Lenny: Why do you find that to be important? I know you weren’t necessarily design all these principles, but I imagine that something that you guys follow often and comes up a lot.
Jeremy Henrickson: I mean, this is one of my favorite ones because I think particularly for a product org, right? Because product leaders have to be right most of the time because their decisions reflect across the entire org and their decisions fundamentally spend time and they spend energy. And if they make good ones, the company does really well. And if they make bad ones, the company doesn’t. And one of the things I really value in product leaders are people who can go into an ambiguous information with ambiguous situation, with incomplete information and a complex decision space and can look at that and listen to everybody and read whatever they need to read and say, this is where we need to go.
And even if everyone else is like, ah, I don’t know, that feels wrong for this reason, this reason if they have the confidence to make that call, and then a year later when you look back on it, for them to have been right, that’s extremely valuable. And it’s one of these things that it’s really hard to test for. You can get it by talking with people and asking, “Hey, was this person usually right in respect?” And people think about it, but in the context of a given company, just you have to take the time and see if those decisions are largely right. And it’s the one value we have. It’s like you can’t really learn it. Either you’re really, really good at making those kinds of decisions or you’re not, right? It’s a very peculiar skill that we really value.
Lenny: Awesome. Shifting a little bit, I know you all are going through this global expansion. We talked about this a little bit.
Jeremy Henrickson: Yeah.
Lenny: And so just a few questions along this lines, because a lot of companies start one country, most companies do, and then they decide let’s expand to new markets. So I guess first question is just how do you decide which markets to go after? And specifically where to start first and then just prioritizing the list of markets? What’s kind of your algorithm for that?
Jeremy Henrickson: So it starts with an assumption that we’re going to have to be everywhere ultimately, that you don’t actually have to build native global payroll in every country in the world. Just makes sense to do that every country in the world. But you definitely want to be able to pay people in any country in the world and you want to be able to have contractors anywhere in the world and have their information be in your HRS anywhere in the world. And so the decision for us, we were fortunate to, or when we made that decision, to have quite a few customers already, like thousands of customers. And so we knew not only where their kind of US employees were, but by virtue of being an employee system work, we actually knew where they had other employees. And so it was quite easy for us to say, focusing on US-based companies, which is incomplete data.
But if we just look at our US-based companies, we know that there is immediate demand for those people to pay people in countries X, Y, and Z. And we just listed those out in raw numerical order. And then we kind of looked at, okay, how hard is it to build in these countries and how valuable is it to build in these countries? What is the strategic value of building in the UK or Canada or Germany or India or wherever? And then we had a discussion on where is there risk or where is this hard? Where is there a long pull? Where does this like, in what countries does it take a long time to get approval or whatever? And we just stack-ranked them and then we revisited that decision. The early decisions that we made on exactly which countries. We have subsequently reordered those over time. And as we’ve dove, dived in the countries, and learned more, we rejigger things like a little bit. But for the most part, that same basic list we started with is still mostly right.
Lenny: Okay. And then the other question a lot of founders always struggle with is when is the time to start expanding internationally? Because there’s pros and cons. Do you have a sense of what convinced y’all to start going international?
Jeremy Henrickson: I think our case is slightly special, but I think the right answer to that question is always before you think you do before you think you need to because there are, it’s harder than everyone if they’ve never done it before, it’s harder than you think it is. It’s more specialized than you think it is. People in the UK really, really care if there is a U in color, just as we care if there’s not a U in color. There’s just all of these subtle lessons that, like cultural lessons for companies that take a really, really long time to absorb. And so my view is you always should do it earlier than you think you should that, than you think you have to. In our case, it was always something we knew we had to do. In fact, we have a very clear thesis that companies that aren’t global, particularly in payroll, but also in kind of insurance and benefits in IT. If you’re not global, you’re just not going to be around in 10 years because companies were becoming global, and then COVID happened and companies became global much faster.
It stopped being the province of 100-person companies plus and started filtering down into very, very small companies. It just became commonplace for small companies to be multi-country. And so that very much accelerated our timetable. And then you saw other people noticed that too, and you saw other companies starting to try to address parts of this problem as well. And so there’s this kind of competitive dimension, which is sort of secondary in most ways because we were going to do it anyway, but that also kind of adds a little bit of a fire under the thing.
Lenny: What have you found to be most surprising about expanding internationally to be successful in expansion? For folks that are maybe starting down this road of like, oh shoot, we should think about that.
Jeremy Henrickson: I think the thing that was most surprising to me the first time I did this back at Guidewire in the [inaudible 00:44:23] and remains the most surprising thing to most people every time I do this again, is that every country is unique. You can’t just take your US-based approach and drop it into another country. Other countries find it insulting. It doesn’t matter how much success you’ve had here. Everyone always believes rightly or wrongly that their local context is special. And you have to respect that. And it comes down to little things like they’re being a you in color or not. Or if you ever see a demo delivered to somebody in another country where they see a detailed screen about a person and it includes a social security number, it’s like that you immediately lose credibility. Doesn’t matter how good all the rest of your stuff is.
And I think that that is consistently the thing that I think is most surprising to people is the degree to which that’s true, which seems obvious in retrospect. If you took a German system or something and demoed it in the United States with poorly translated stuff, we would think it would suck too. But it’s not, it’s really hard to adapt to that mindset. And so it takes just a lot of energy to overcome that organizationally.
Lenny: Makes tons of sense. I’m going to go in a different direction now.
Jeremy Henrickson: Sure.
Lenny: Frameworks. So I know that you’re not a huge fan of frameworks. We were chatting about this before we started recording. And so I’m curious just to hear your perspective on why you’re maybe not a fan of frameworks and then also just how you crystallize processes and concepts for your team if you’re not just like, Hey, here’s our framework you should use.
Jeremy Henrickson: Look, I think frameworks are very helpful. So I’m not exactly anti-framework, but I am anti-process as a substitution for deep product thinking, right? So I like to have just enough process to create a frame so that the right decisions can happen and know more. And I think there’s a danger, especially as companies scale, that you end up saying, well, if only we categorize everything correctly and Jira, like we will be able to make really good prioritization decisions. So I’m like, sure, extremely helpful to have clear categorization and things that Jira doesn’t have like data and analysis and to be able to do all of that stuff. But what you really need to do is decide important to build and then have a way to build it really efficiently. And so I think the right answer, the right amount of process for any given team is like, or the right framework for any team is really just dependent on their specific life cycle.
So you won’t see me saying like, oh, we need to use this scrum thing or that combine thing, or whatever the latest, newest thing is. It’s like, don’t care about any of that. What I care is about something that’s going to enable this team in this context at this point in their life cycle to build the right thing as efficiently as possible. And I’m fine if those are different for different teams. And the only place I care about unification is one on the quarterly planning process. And two, everything does need in fact to be in Jira because otherwise, you can’t rationalize about what’s actually getting done in not.
Lenny: Is there a process or framework that you find is counterproductive that you’re just stay away from this thing? We’ve had a lot of trouble with it, or generally, it’s like let’s just rethink everything ourselves.
Jeremy Henrickson: No, I don’t find one to be particular, I don’t consistently found one to be particularly problematic. So I think any framework sort of has its place, the right place, right time. I think there’s danger any one time somebody like dogmatically says, I think we should use process X because that’s almost never the right answer in my experience. I think there are places where that can differ. Like you start a company on the basis of process X and everyone’s bought into that process and everyone understands it. I think they can be really, really great. And on the engineering side, I think this is hugely valuable. It’s like test driven-development, first line of code’s going to be a test, not the actual thing. Like fantastic, very supportive of all that. I think it’s kind of different in the product world.
Lenny: If you had to compare the way Coinbase builds product process-wise or just product development to Rippling, what would you say are the bigger differences?
Jeremy Henrickson: I think the differences are largely born of the different domains. So crypto, as we talked about earlier, really hard to predict what’s going on. There’s all these questions about what’s the future of crypto, what’s going to matter, what do we even need to build? What’s going to survive? And so the process we had at Coinbase run, having those debates and getting to a decision and disagreeing, committing. And then from an execution point of view, being able to move fast. That was the trick at Coinbase. Here we know the things that we need to build at a high level. And the trick is how do we really differentiate it on the basis of these amazing platform capabilities we have? Or how do we have to evolve those platform capabilities in order to continue to build something that’s just discontinuously better than everything that’s out there? And that yields a different decision-making process. So for me, it’s the mental model is actually of how I approach those things with the same, but they just yield different results in the actual making of the software.
Lenny: What is that actual difference? Do you find day-to-day? Is it timeline differences? Is it how quickly, I don’t know the way you structure, how far out you plan, what do you find is the concrete difference as a result?
Jeremy Henrickson: I think the difference is in the day-to-day velocity of decision-making, because we can, Rippling, if you’re on, I don’t know, pick a random team. If you’re on the device management team, you know what you got to do, right? There’s no ambiguity. You’re not debating about whether Mac or Windows is going to exist in the future. There’s none of that cognitive dissonance. There is, we need to build this. It’s hard to figure out how we need to build this, right? Because there’s all these different things that we could leverage, but we need to basically get this done.
And so the kind of total velocity I would say is higher here, which does not say people work harder or less are at Columbia. Columbia was an amazingly fast environment, but it was also subject to the fact that you just don’t know what the crypto markets are going to do, and you have to be incredibly reactive to that. And so I think maybe that’s the one thing, like the reactivity to the environment and the crypto environment, what’s going on, and the uncertainty of the regulatory environment, all that stuff. We got really, really, really good at handling those things really rapidly, which is something that we need to handle somewhat less [inaudible 00:50:34].
Lenny: Sounds quite stressful at Coinbase.
Jeremy Henrickson: Yeah, I mean it was fun. Yes, it was stressful. I mean, every job I’ve ever had has been stressful, but in its own unique way. But all of that stress I think is in the shape of a problem, that’s in the context of a problem that’s really interesting. I mean that’s why I stayed at these places. But yeah, it’s stressful.
Lenny: And looking back, what a joy.
Jeremy Henrickson: Yeah. No, there are very good memories. I look back, I don’t really, I remember the stress, but I don’t like re-experience it, right. I remember foraging these relationships and building these amazing products that I’ve been so lucky to be a part of. And so I have almost only good memories of the places I’ve been.
Lenny: That’s what I find too. You go through these hardships and then you look back and you’re like, wow, that was so cool. But assuming they go well, assuming the company works out and-
Jeremy Henrickson: True.
Lenny: … it feels like it was successful. A lot of times you’re at a startup, your life sucks for two years and it doesn’t work out and that there is a lot of upside and good memories to that, but it’s less glorious.
Jeremy Henrickson: Yeah, that’s fair though. I mean, the first company I was really at out of school’s company called Reactivity back in internet one era, and we were trying to figure out how does this internet thing work and how do we start companies on the basis of these tech new technologies and how do we help other companies build stuff and figure it out? And that company fundamentally didn’t work out, ultimately got kind of spun itself out and got acquired, which was great, but it was this extraordinary set of people that I was so lucky to work with and I loved all the time I spent there and it was foundational to everything else I ever did. And so even though that effort didn’t pay off in the traditional set, the value of the learnings I had there and then the people I had a chance to work with was just really exceptional. So I feel very lucky.
Lenny: That’s a really good point actually. And I think I should correct even what I said that even when things don’t work out, traditionally those experiences end up being incredibly valuable in all these unexpected ways.
Jeremy Henrickson: Yeah, 100%.
Lenny: Yeah. Okay, so final topic.
Jeremy Henrickson: Sure.
Lenny: I want to talk about hiring product managers and interviewing.
Jeremy Henrickson: Yeah.
Lenny: So you’ve hired a lot of PMs over the years. I’m curious, what’s something you’ve learned about what to look for in product managers and also just in product leaders that other people may not be focused on as enough?
Jeremy Henrickson: I mean, I don’t know that I have any particularly special insight here. I think there’s a couple things that I do ask that maybe are more of an emphasis because it’s Rippling than not. But the first of those is when people are going through our process, there’s a part where they do this case study and an important part of the case study is that it’s actually too complex for people to have all of the answers upfront. There’s just the space of the problem is too large to do that, which means that in the interview there’s a lot of opportunities or in the case study there’s a lot of opportunities. So just ask ad hoc questions or to change one assumption. And seeing how people react to that is really indicative of how deeply they understand a new problem or how quickly or how mentally agile they are.
And some people are extremely good at that here in assumption and they blink a couple times. They’re like, oh, well that has these 400 implications. And they just start rattling them off. And some people get really flummoxed. I mean obviously for our environment, that former is really, really important to us. I think the other thing that really matters to me is the insightfulness of questions that people ask, which is indicative of number one, their actual interest in the job.
People tend to ask better questions when they’re more excited about working at a place and done their research and are asking people about it. And also the quality of those questions can vary quite dramatically. And that’s okay. I don’t expect the quality to be the same all the time, but sometimes people ask a question, I’m like, “Oh man, I would’ve never thought to ask that question. That’s such an insightful question.” And then I pause and I have to think about my answer a little bit. And so it kind of pushes me to be a little bit better. And when that happens, I know I usually have pretty good candidate on my hands.
Lenny: Is there an example of someone asking a really good question that comes to mind that you think back to and like, Oh wow, that was great.
Jeremy Henrickson: I remember about three years ago I was interviewing a guy named Kyle Boston and Kyle is now runs our platform product organization. And I can’t remember the specific question he asked, but it had something to do with, wait a minute, if you have all these products and you have this employee system of record thing underneath it, we be thinking about how to create these various pillars of underlying platform technology, things like [inaudible 00:55:22] all this stuff. And this was before we fully formalized the concept of our platform beyond the kind of employee system of record.
And I remember thinking, yes, we should, and that had entered our minds before, but the fact that somebody which who had almost no context on the company, that’s what was impressive about this question. It’s like, man, you’ve been thinking about Rippling for a couple weeks while you’re interviewing with a bunch of other companies or whatever. And you’ve thought about it deeply enough to have this insight into the nature of the platform that we’re building immediately gave me a bunch of confidence in his ability to think through the sorts of things we need him to think through.
Lenny: And I think it touches on PMs need to be business leaders and great questions are often about the business and the future of the business and how to make it run more efficiently and this, and there’s a product org element to it. But I find that that’s a really underappreciated element of PM interviews, just thinking about the bigger business, not just the PM product.
Jeremy Henrickson: For me it’s two things. It’s thinking about the bigger business and having the context around whether it’s revenue questions or strategy questions, but also the detailed questions. It’s like, oh wait a minute. The implication of this thing that I’m getting asked or of this thing with Jeremy that you said earlier is all of these things. And their ability to understand that this isn’t a simple business, it’s really hard, it’s really complex. And the ability to have these insights to help them think through those details is really cool.
Lenny: You talked about this prompt you give product managers not to give away what you actually asked these days, but is there an example of a prompt that you’ve given in the past or you think is a good example of a type of prompt to give a product manager candidate.
Jeremy Henrickson: In terms of a general kind of approach, I think a prompt should always reflect the actual business that they’re going to kind of come into. So when we do, so our process overall is actually quite short. It’s basically get in contact with us somehow, eventually get connected with a hiring manager, have a conversation with them. Then more or less you have a conversation with me, which is a product discussion. And then we have a case study which follows that. That’s the whole process. Modulo, other conversations around the edges. And the questions that matter are around how do people think through that product discussion, which is relevant to our business. How do people think through that case study? That’s number one. And the second thing is there’s always a part of my interview, which is maybe sounds very simple, but it’s just like, Hey, what questions do you have for me?
We actually do that before we do the product discussion. And that’s an incredibly important question because it is again indicative of these things that people have thought through or not thought through or the depth that they’re thinking or their interest in engagement in the role. And at that second discussion, it doesn’t have to be perfect or anything, but it is a very strong signal when people, whether they’ve thought through a set of questions they want to ask or just on the fly generating them, you learn a lot about how people think about product, about what they’re looking for, about what they like doing and not doing, just through those questions.
Lenny: For PMs that are maybe in their early career that are listening to this, what advice would you give them to help them accelerate and advance their career most in the early part of their career?
Jeremy Henrickson: Be humble. Being a product person means that by definition you’re living in a world where no one knows the right answer yet because if somebody did, they would’ve already built it. And so having, no matter how smart you are, there’s a lot of smart people out there. There’s always stuff you don’t know. There’s always people who are going to know things that you don’t know. And it is only through that acknowledgement that you can actually have the humility to say, I’m open to absorbing all of this stuff, I don’t know. And open to synthesizing all this stuff and coming to different conclusions.
And so I found that that humility is one of the biggest differentiators in early career leaders who are able to let go of how awesome they were in school or in their first job or whatever. I mean, I had to do this and realize the job is always hard and the job is always about discovery every single day. And if you can maintain that curiosity and elasticity of thought and creativity and light coming solutions could be awesome. But if you close yourself off to that and think you always have the right answer, then there’s like no hope.
Lenny: This touches on another principle that I still have sitting on my screen here, which is great leaders change their minds a lot or just change their minds.
Jeremy Henrickson: Yeah. Willing to look at new information and say, my mental model is adjusted by that or I was wrong very simply. I mean I think it’s also important to be operating in an environment where you’re allowed to say that you’re wrong, right? Everyone’s wrong sometimes. I mean be right a lot, but everyone’s wrong sometimes. Right? And being in be able to be an environment where you can just say, yep, I was wrong. Here’s the way in which I was wrong. Let’s move on, is incredibly powerful.
Lenny: The final question you’ve brought up Parker a number of times and something that is clear about him is that he’s a very product-minded founder. He has a lot of strong opinions about what product should be. And as a product leader with a founder like that is often a challenging place to be similar to being the first PM at a startup and the founder has strong opinions about product. So my question is just what have you learned about being successful as a product leader with a founder that has very strong opinions about what the product should be?
Jeremy Henrickson: Yeah, no, that’s a great question. So I think you’ve got to be adaptable, right? It’s like any other relationship, right? You have to understand what the nature of that relationship is, where that person’s going to care, where you’re going to care, the ways in which you can challenge each other. I think fundamentally you need to make sure that person is willing to be challenged, right? So I’ve seen product leaders or CEOs who are kind of unwilling to be challenged and I wouldn’t be able to work with those people.
But yeah, Parker is incredibly strongly opinionated, but he’s also incredibly informed, which makes for some really, really great debates. And I’ve just found that whatever, and it’s not even CEO, but whatever a manager’s idiosyncrasies are, you have to find a way to work with those. And I think that adaptability, like I’m just sort of, I like being a moldable puzzle piece where I can just fit in. I think that’s actually one of my core skills. And so that’s worked out for me and Parker and I before I started developing a deep foundation of respect, which is extremely important to building that. And over the years it’s just gotten deeper and deeper and we don’t always agree, but when we can have a totally reasonable discussion about it, and that’s what makes it fun.
Lenny: Adaptability actually is, I took a strength finder test once of finding my own strengths and that was my number one strength is I’m [inaudible 01:02:14] I think we share that.
Jeremy Henrickson: That’s excellent.
Lenny: Yeah, seems like an important attribute for being in a place in. Well with that, we’ve reached our very exciting lightning round. I’ve got six questions for you if you’re ready.
Jeremy Henrickson: All right, I’m ready. Hit me.
Lenny: Here we go. What are two or three books that you’ve recommended most to other people?
Jeremy Henrickson: Well, first is my favorite series of books ever, which is the Baroque Cycle by Neal Stephenson. It’s a nine-volume epic or three-volume, nine-book epic depending on how you want to look at it. But it’s about the time just before and into the enlightenment, historical fiction, a lot of fun. And I also love the Culture series by Iain Banks, which is just super fun, far-future sort of universe that I’ve really enjoyed.
Lenny: What’s a favorite recent movie or TV show?
Jeremy Henrickson: Watched The Last of Us, was an avid fan of the game and I thought they did a really nice adaptation. Favorite mov, like I guess, recent movie, it’s not that recent, but I really like Tenet, which I thought was a, I was impressed with their ability to go there and make that movie and I just really enjoyed it end to end.
Lenny: It kind of ended, but we had a drinking game anytime someone mentioned Last of Us, which took over White Lotus. I’m going to drink some tea right here.
Jeremy Henrickson: Okay, fair enough. I’ll try. I’ve only got water normally I got tea, but water today.
Lenny: That works. But it’s interesting, it hasn’t come up often, so I think maybe we end that for now and see what the new pattern emerges. And then Tenant feels like, I was just thinking it feels like a compound movie, compound startup as a movie, a movie is very complicated too to stay-
Jeremy Henrickson: Yeah, That’s why I enjoyed it. I like trying to figure out the multi-timeline chart in my head as the movie progressed.
Lenny: The puzzle piece within you trying to find all the puzzle pieces.
Jeremy Henrickson: Yeah, for sure.
Lenny: What is a favorite interview question you like to ask? You already maybe answered this, but anything else come to mind?
Jeremy Henrickson: I think I did, no, my favorite one is What questions do you have for me by far?
Lenny: Great. What are some favorite products you’ve recently discovered that you love?
Jeremy Henrickson: I guess I’ll just mention, I don’t know if I go as far as I call these favorite products, but there’s two that come to mind. My wife’s computer broke the other day and I realized it was the CPU cooler that went bad and the Corsair H60 CPU cooler was super easy to use and really adaptable to lots of motherboards. I thought that was great. My other favorite product is the one I’m wearing in my ears right now, which my first pair of nice headphones I ever bought died late last week, and had to do some really quick research into my new favorite pair of headphones. And these Focal Bathys are super nice. I’m a bit of an audio file. I like to listen to classical music and ambient stuff, so we need a lot of dynamic range and noise cancellation and these have been great so far.
Lenny: Okay, so what are they called?
Jeremy Henrickson: Focal, I think it’s Bathys, B-A-T-H-Y-S. Okay.
Lenny: And has there a specific model or there’s like that one?
Jeremy Henrickson: That’s it.
Lenny: Okay.
Jeremy Henrickson: You’ll know it when you see it.
Lenny: Okay. We will link to them in show notes, so maybe I’ll get one. What’s something relatively minor you’ve changed in the way that you built product that has had a lot of impact on your team’s ability to execute?
Jeremy Henrickson: Maybe the most recent innovation sort of at Rippling was the kind of introduction of what I’m calling imperatives. These things that whether they come bottom up or top down are things that like everybody across the entire product and engineering team needs to do and what’s important about that list of things that are not on it. And in a world where we could choose to do hundreds of things at once, being able to force rank that list of things, draw a line, say these are the ones everyone has to do, has created a lot more focus and clarity than we had before.
Lenny: So imperatives are essentially here’s the priorities for the next, say quarter six months here?
Jeremy Henrickson: Here are the priorities for everybody and now integrate that into your own team’s priorities, right? So each team still is building their own priorities, but they have to factor in this set.
Lenny: How many of those do you usually have? This is awesome. I like this tip.
Jeremy Henrickson: It depends on what level of granularity you want to talk about them at, like maybe 10, right? It’s a lot. We’re going through between globalization and large improvements of the platform and a bunch of other large companies. All these things, it creates a bunch of things that just have to be cross-team simultaneously. I think it’s pretty natural part of a company’s evolution and we’re just in that part of the cycle, so-
Lenny: Awesome.
Jeremy Henrickson: … used it.
Lenny: Final question, what’s a question I should have asked you that I didn’t ask you?
Jeremy Henrickson: I guess, what do I do with my kids maybe? I have two kids, they’re nine and-
Lenny: What do you do with your kids?
Jeremy Henrickson: … six. What do I do with my kids? My son, I’m a big board gamer and while I didn’t push it on him, my son, he will play board games morning to night. And so we play a lot of European strategy games together and my daughter’s now getting old enough that she’s getting into them too. And so we just finished as a family playing Pandemic Legacy and the reward tomorrow night as we get to start playing Gloomhaven. So that’s going to be fun.
Lenny: I don’t know either game, sounds very hard and complicated.
Jeremy Henrickson: They’re fun. They’re fun.
Lenny: Amazing. Jeremy, we covered a lot of topics. I feel like this is a compound podcast episode and so thank you for spending time with me. Thanks for being here. Two final questions, working folks, finding online if they want to reach out, learn more, and how can listeners be useful to you?
Jeremy Henrickson: Awesome. LinkedIn is the easiest way online and if what I’ve been talking about today sounds interesting to you, we’re definitely hiring like senior entrepreneurial PMs. And so if those leadership principles on our website look interesting, I’d love to hear from you.
Lenny: What’s the best way to explore those roles and apply? The
Jeremy Henrickson: The website has by far the best channel. It gets to this right recruiter who will tell me about it right away.
Lenny: Great, surfline.com and there’s probably a site for careers.
Jeremy Henrickson: There is a career site on there that you, pretty easy to find.
Lenny: Okay. Rolling to that in the show notes. Jeremy, thank you again for being here.
Jeremy Henrickson: Thanks so much for having me. This was a lot of fun.
Lenny: Hi everyone. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcast, Spotify, or your favorite podcast app. Also, please consider giving us a rating or a leaving review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.
Glossary
| English | 中文 |
|---|---|
| case study | 案例分析(case study) |
| Coinbase | 保留原文 |
| component library | 组件库 |
| compound startup | 复合创业公司(compound startup) |
| disagree and commit | ”虽然不同意但承诺执行”(disagree and commit) |
| dogfood | 内部试用(dogfood) |
| DRI | 直接负责人(DRI) |
| Dunbar’s number | 邓巴数(Dunbar’s number) |
| Ethereum | 以太坊 |
| go and see | ”去看”(go and see) |
| imperatives | 要务(imperatives) |
| Jeremy Henrickson | 保留原文 |
| Kevin Kelly | 凯文·凯利 |
| Kyle Boston | 保留原文 |
| leadership principles | 领导力原则(leadership principles) |
| Matt MacInnis | 保留原文 |
| MVP | 最小可行产品(MVP) |
| Parker | 保留原文 |
| Reactivity | 保留原文 |
| Rippling | 保留原文 |
| Sachit | 保留原文 |
| system of record | 系统记录(system of record) |
| test-driven development | 测试驱动开发(test-driven development) |
| time and attendance product | 考勤和工时管理产品 |
| zero-to-one | 从零到一 |
Reformatted by reformat_english.py
快速推进与应对不确定性 | Jeremy Henrickson(Rippling, Coinbase)
文字稿
Jeremy Henrickson: 作为领导者,浮在上面说”嘿,你去攻那座山头,你们几个去做那边的事”,这种做法非常非常诱人。但事实上,你真正了解挑战、问题或成功所在的方式,是亲自和身处一线的人站在一起,投入其中一件事——不管哪件事看起来最难、最复杂。所以我尽可能经常这样做,而且我发现每次做这种深入细致的练习,我总能学到很多。
访谈开始
Lenny: 欢迎来到 Lenny’s Podcast,在这里我们采访世界级的产品负责人和增长专家,从他们建设和发展当今最成功产品的宝贵经验中学习。今天的嘉宾是 Jeremy Henrickson。Jeremy 是 Rippling 的高级产品副总裁,领导产品和设计团队。此前,他是 Coinbase 的首席产品官,在此期间产品与工程团队实现了 10 倍增长,并帮助 Coinbase 在加密货币市场最疯狂的时期实现了规模化发展。在本次对话中,Jeremy 分享了他关于在规模化过程中保持速度、创建快速决策文化、产品负责人深入问题以及成为其领域世界级专家的重要性的经验教训。在面试产品经理时应该关注什么,为什么依赖框架会对你的成功造成如此大的损害,为什么你可能要避免做 MVP 而是先为最复杂的用例做设计,以及更多的内容。在与我们的赞助商简短介绍之后,请欣赏与 Jeremy Henrickson 的这期节目。
Jeremy Henrickson: 非常感谢你的邀请,我很高兴来到这里。
Lenny: 我听到的关于你的评价都是非常好的,我很期待从你在 Rippling、Coinbase 以及你建设的所有产品和团队的经验中学习。再次感谢你的到来。
Jeremy Henrickson: 非常高兴来到这里。
Coinbase 的疯狂岁月
Lenny: 我想从你在 Coinbase 的经历开始聊。你在那里担任首席产品官,而且你担任这个角色的时间,可能是加密货币市场最疯狂的时期。我想大概是在 2016 到 2018 年间,我看着比特币的价格,几个月内从一千美元涨到了两万美元。所以我很好奇,那段经历是什么样的?特别是作为产品负责人带领团队经历那样的时期,是什么体验?
Jeremy Henrickson: 给我留下最深印象的是 2017 年。加密货币在 2016 年初差不多处于最低谷,之后慢慢开始爬升,然后在 2017 年真的起飞了,真正进入了公众视野。Coinbase 当时只有一个交易所,基本上就是法币与加密货币之间的入金和出金通道。在 2017 年这一年间,使用量增长了 40 倍。
Lenny: 这对很多人来说简直是梦想成真。
Jeremy Henrickson: 既是美梦也是噩梦。我非常幸运能和我真正信任的团队一起工作,大家能肩并肩在战壕里并肩作战。那段时间学到了很多关于如何快速扩展系统的经验。人们喜欢在周六早上交易加密货币,所以很多个周六早上,系统边缘总会冒出新的故障,我们需要立刻冲进去修复。所以那段时间关于选择和谁一起工作、如何保持专注、确保对的人在对的时间出现在对的房间里,这些方面有非常多深刻的教训。
在混乱中保持专注
Lenny: 好,我们来展开聊聊其中几点。专注这个话题确实很有意思,大家总是在谈论,但实际做到却很难。我猜你是怎么让团队保持专注的?我想象一下,加密货币领域到处都是有人在暴富。
Jeremy Henrickson:
Lenny: 系统一直在出问题,你是怎么让团队保持专注的?
Jeremy Henrickson: 首先,你不能谈论什么人暴富的事。这是一个非常技术性的话题,你要谈的是客户,是他们的钱,而第一要务是安全。有一个叫 Philip Barton 的人,现在是我的朋友,他是 Coinbase 一位非常出色的安全负责人。他总是能够把我们极其快速做出的决策放在一个正确的上下文中来看,说:“看,不管我们需要多快地推进,这些是我们能做的决策类型,同时仍然能保证安全。“所以安全始终是第一位的。其次是要同时关注问题的即时性——比如网站挂了之类的——先把问题解决,但同时也要把这些情况放到我们未来六个月要去哪里的框架中去思考。我们真正的目标是什么?我们预计的交易量会是多少?从用户体验到产品深层后端,需要做到什么才能真正为用户所用?
Lenny: 作为产品负责人,在一切都在经历 40 倍增长的情况下试图让大家保持专注、让一切不脱轨,你觉得最大的挑战是什么?
Jeremy Henrickson: 我觉得最大的挑战在于,加密领域整体上充满了不确定性,连”以太坊能不能成”这种简单问题都存在争议。当时没有人能给出真正的答案,只有各种强烈的意见。所以你必须让这些辩论进行下去,因为发生的事情太多了,但辩论之后,你必须能从中形成一个清晰的公司层面的共同目标,大家一起朝那个方向努力。虽然在边缘问题上可能仍会有不同意见和争论,但你要全力朝这个答案推进,直到你决定全力转向另一个答案。我觉得我们在 Coinbase 这一点上做得相当成功,虽然过程并不总是轻松的。
Lenny: 关于这个话题,最后一个问题。
Jeremy Henrickson: 好。
Lenny: 经历过那样的时期,很多人都会经历这种高强度工作的阶段——天哪,这不是那种疯狂的、压力巨大的、工作时间超长的状态吗——但回过头看,那些时期往往成为你职业生涯中最重要的、最有意义的阶段。一方面,这也是你的感受吗?另一方面,对于正在经历类似阶段的人,你有什么建议吗?比如这种时期有没有什么积极的一面?
Jeremy Henrickson: 确实很难,对吧?并不总是轻松的。我当时有一个刚出生几个月的女儿,要平衡这些东西真的非常困难。但我一直很享受学习的速度。正是这些经历,我感觉最大程度地加速了我个人的成长和学习,因为它是在困难事物的熔炉中锻造出来的。所以我觉得当人们身处那些时期时,不妨退后一步,跟朋友聊聊到底在发生什么,把它放在一个更大的时间框架里来看——嘿,三四年或五年后我们回过头来看这段经历,你会意识到:第一,我们在那段时间里做了一件了不起的事;第二,我们学到了很多东西,而这些东西可以带到之后无论做什么中去。
规模化保持速度
Lenny: 在我们聊天之前,我问你人们最常向你请教什么方面的建议,你说人们经常问你如何在规模化时保持速度(velocity),这是每个创始人和产品负责人一直在努力做到的事情。那么你学到了什么?关于在扩展规模时保持甚至提升速度,你怎么告诉别人的?
Jeremy Henrickson: 我觉得这里有很多不同的答案,而且很多都跟你所处的业务性质高度相关,不同的业务可以以不同的方式保持速度。但我认为有一个普遍适用的真理:你需要小团队、明确的使命。对吧?如果 300 个人试图一起做一件事,光是沟通上的挑战、邓巴数(Dunbar’s number)之类的问题就会全部浮现出来,想快速行动真的非常非常难。所以要把一群较小的人组织起来,把一个总是非常庞大的问题拆解成足够小的部分,让小团队能够全力以赴地攻克,同时最小化横向沟通,这是第一点。
第二点是,在技术层面,你能把越多东西固化到一个清晰的平台中,就越能降低每个在业务领域工作的人的决策复杂度。一个拥有清晰接口、对工程师和产品人员来说都好用的平台,可以简化人们思考这些问题所需的空间。但这并不总是容易的。你不能只是写一个平台然后指望它能适用于产品。这很大程度上是一个迭代的过程,但越能在上面投入,并拥有既具备系统思维又同时具备产品思维的合适人才,就越重要。
第三点,从领导力的角度来看,就是深入一线。作为领导者,飘在上面说”嘿,你去攻那个山头,你们去做这个”是非常非常诱人的。但事实上,你真正了解挑战、问题或成功之处的方法,就是和一线的人一起待在战壕里,参与到其中一件事上——无论哪件看起来最难或最复杂的。
我尽量经常这么做。我发现每次做这种深入细节的练习,我都能学到很多东西。最后一点,就是确保团队拥有正确的经验和资历分布。有时候你启动一个团队,团队可能在做一些从零到一的事情,而他们在所有这些从零到一的事情上都非常出色。然后两三年后,同样的人要试图把产品扩展到数百万用户,结果发现:第一,他们不那么喜欢工作中的这部分;第二,也许他们在这方面没那么擅长。所以你需要不断审视团队,确保人们在做自己热爱的事情,如果不是,那就试试别的事情,重新调整团队,确保有正确的技能组合。我发现如果你把这些都做到了,再加上产品领导层说”这是我们需要做的”,并且在需要做的事情上非常清晰和精确,那么你通常甚至能随时间加速,因为你把更多东西固化到了平台中,这让工程师能以更少的资源做更多的事,这总是非常惊人的。
Lenny: 好,让我深入追问其中几个点。这些真的很棒。
Jeremy Henrickson: 请说。
Lenny: 关于小团队加明确使命这一点,在 Rippling 或 Coinbase 有没有特别好的例子来说明这一点?
Jeremy Henrickson: 一个例子大概是三年前,我刚加入公司的时候,我们决定需要做一个考勤和工时管理的产品,市场对我们有很大的需求,而我们还没做,这是很多客户需要的东西。我们可以选择很多方式来做这件事,但我们的做法是说:看,找一个工程师——一个非常优秀的系统工程师,同时也能做一些产品思考——然后让 CEO Parker 也花时间参与。就从这里开始,Sachit 又带了几个人进来。这四个人在大约九个月的时间里,构建了一个考勤和工时管理产品。这是他们唯一在做的事情。他们不需要操心我们的薪酬产品在做什么,除非需要做一些集成;也不需要操心福利团队或我们的 IT 产品在做什么。他们全身心地专注于这一件事,然后在需要与套件其他部分连接的地方做好对接,这让他们能够以极快的速度推进。
Lenny: 其中有多少是因为 Parker 在团队里帮他们扫清障碍,又有多少是因为团队足够小且足够专注?
Jeremy Henrickson: 我觉得主要还是因为团队小且足够专注。当然,Parker 能做一些事情、帮他们扫清障碍,这是只有 CEO 才能做到的,确实有帮助。但关键是在 Rippling,我们这种方式已经复制了十几次了。这是我们启动新业务的标准模式。所以不能只靠他一个人去扫清障碍,尽管他确实会这么做。更核心的是这种模式——让小团队能够独立推进事情,然后无论是 Parker 还是公司里的其他人,都可以直接找到他们说:“嘿,进展怎么样?我们做的事情对吗?让我看看最新的设计,我来给点意见。”
所有这些事情的发生节奏,比你在组织架构里往下穿透三层去做同样的事情要快得多。我觉得这也许是另一个关键点——每个人都能接触到高层领导。是的,我们有管理架构,因为必须有,但这个管理架构不会妨碍组织中任何人、在任何地方去了解实际正在发生的事情。而且这种了解是非常直接的。
Lenny: 那我们来聊聊你刚才描述的那个模式。这个模式到底是什么?这是你们做新产品的方式,我知道 Rippling 内部有很多很多产品和功能,我们待会儿会谈到。你说的是一种新增业务单元或新产品功能的方法论。
Jeremy Henrickson: 对。
Lenny: 这个模式大致是怎样的?
新产品启动模式
Jeremy Henrickson: 这个模式其实很简单。在绝大多数情况下,我们意识到需要构建某个东西,然后会有一页纸的概述说明它是什么。通常我们比较幸运,我们要构建的东西在行业中已经以某种形式存在了,虽然不是我们能做出的差异化版本,但考勤和工时管理就是一个例子——这在业内是广为人知的,有整家公司只做这一件事。所以我们从这里出发,找到一位极具创业精神的工程师,他理解什么是高速推进,理解在信息不足的情况下如何做决策,理解如何与设计搭档以极快的节奏协作。
我们给他配一位设计搭档,然后说:“来 Rippling,先用几个月时间了解我们的平台。先去另一个团队工作,了解对他们来说什么是容易的、什么是困难的,平台是怎么运作的,其他产品是如何在这个平台上构建的。去跟在这里做过产品创始的人聊聊,了解他们的经验,这样你可以从中学习、迭代,形成自己对产品的判断,然后再开始构建。”
在这段时间里,他们同时也在招募一个通常两到四人的工程师团队,这些人同样具备从零到一的 mentality(心态),然后开始构建。通常在六到九个月的时间里,我们可以把一个产品从一张白纸做到上线,或者至少做到内部使用的程度——我们会大量 dogfood(内部试用)自己的产品。然后再从这里发展壮大。有时候当你准备上线一个产品时,快到发布阶段,你会发现五六个人的团队就能持续维护这个产品,不需要再加人。有时候则需要扩编——比如这个东西马上要上生产环境了,还有一大堆事情要做,团队需要从 4 人扩到 15 人之类的。这完全取决于具体产品,但大致的生命周期就是这样,然后你继续扩大规模。
Lenny: 这太有意思了。确认一下我的理解——你们找一个创始人型的人来牵头一个新想法,这个人是从内部招募的,还是有时候也从外部找?
Jeremy Henrickson: 两种都有。
Lenny: 有意思。
Jeremy Henrickson: 两种都有。
Lenny: 好。然后你给他找一个设计搭档一起合作,来确定到底需要构建什么。是只找一个设计搭档,还是会尽量多找几个?
Jeremy Henrickson: 通常是一个。所以我们有设计师——我们有设计团队——
Lenny: 哦,设计搭档,指的是设计师,不是一家合作公司那种设计伙伴。
Jeremy Henrickson: 对对对,就是那种了解 Rippling 产品的人,了解我们的组件库,了解所有这些东西,同时在 UX、交互和视觉设计方面很专业的人。
Lenny: 明白了,是设计师。好,然后他们基本上和几个工程师一起,就是启动一个新产品线并发布的团队,随着规模增长,团队可能会扩大,也可能不会。
Jeremy Henrickson: 对,就是这样。而且比较灵活,大概每两周左右,他们会和我或者 Parker 开会——取决于谁是这件事的 DRI(直接负责人)——对设计给出反馈,做一些关键的压力测试:“如果我是小公司的管理员,或者大公司的管理员,我用这个会有什么感受?这个界面对我适用吗?“所以我们在整个周期里都在做压力测试,努力在速度和完备性之间找到平衡。
对 MVP 的看法
Lenny: 这让我想到——我听说你不太推崇 MVP(最小可行产品),你们做产品是朝着更远的目标做的。是这样吗?如果是的话,你怎么看待一个产品的初始版本?
Jeremy Henrickson: 首先,我不想贬低 MVP。我认为 MVP 有它的用武之地,非常有价值,特别是当你真的是一家从零到一、从未做过任何产品的公司,而且没有明确的市场验证的时候。但就我们 Rippling 的具体情况而言,一个最小可行产品既对不起我们的客户,也对不起构建它的团队。我这么认为的原因是:当你设计一个最小可行产品时,你优化的是速度。在这一系列优化中,你会弱化那些更深层次的产品思考——思考什么才能真正让我们的产品形成差异化,这种差异化不仅基于我们现有产品和平台的能力,还基于这个产品未来应有的样子。
所以这在某种程度上限制了产品创造力,但更糟糕的是,它会导致在技术上构建出错误的东西。如果你只考虑简单场景,作为一个工程师,没有人来挑战你说”等等,那个医疗医院管理的场景怎么办?那是关乎生命的关键场景”——那你就会做出一组不同的架构假设,然后在这些假设之上继续构建,再构建六个月、九个月、一年,最终你会在那些假设之上堆叠几十甚至上百个决策。
Jeremy Henrickson: 而且一旦你把这些决策嵌入到产品中,再想推翻就极其困难了。因此我们深信:当然,要理解那些简单场景。理解如果你是一家两个人的公司,你不需要所有这些额外的东西,你接近这个产品时它会是什么样子——但同时也去理解,在全球拥有 10,000 名员工、面临那些极其复杂的使用场景意味着什么?什么样的模型才能支撑那种场景?我们要确保,在进行技术和产品设计时,能够容纳那种视角,即使我们在第一个版本中不会支持它,即使我们做出产品决策说:“看,我们现在确实不需要处理那种场景。“你仍然以一种不会阻碍你未来到达那里的方式来构建产品。这样做会多花一点时间吗?当然会。但从长远来看它能为你节省时间吗?绝对能。所以这就是我们的方法。
全球薪酬产品的实例
Lenny: 你能不能想一个具体的例子,在 Rippling 或 Coinbase 构建过的某个产品——它本来可以是一个非常简单的最小可行产品(MVP),但最终你们做出了正确的选择,在光谱上往更完整的方向走了一步?
Jeremy Henrickson: 好的。我认为在 Rippling 一个很好的例子就是我们的全球薪酬产品。我们本可以说:“嘿,我们只需要支持一个国家。我们需要支持,比如说,英国。“那我们就把所有美国的东西复制过来,照搬一下,把所有东西改成英国的样子。这会是最快的做法——当然这极大地简化了问题——但我们没有这么做。我们的做法是:看,我们需要同时上线六个国家,而这六个国家差异非常大。它们在 HRIS 方面、在名义雇主(employer of record)方面、在如何支付全球承包商方面、在薪酬如何运作方面都会有不同的要求,而我们要打造一个能同时适用于这些国家的系统。这带来了大量的下游影响。
但这意味着,现在我们的全球薪酬系统中,添加一个国家——虽然不容易——但比你不得不不断地复制粘贴、然后还要维护那些几乎没有底层关联性的各个版本要容易得多。相反,我们的系统中有 80% 是固化在全球薪酬平台中的,然后 20% 是各国特定的。而这部分特定内容大部分不需要由工程师来处理——让工程师去改那些本地特定的东西成本非常高——而是可以由合规部门的人来配置,由法务部门需要将正确文件录入系统的人来配置。所有这些都可以通过系统来处理,这让我们在后续推进时能快得多。
先设计最复杂的场景
Lenny: 我听你把这种理念描述为——你鼓励团队先为最复杂的使用场景做设计。这是你给这些团队的指导方针吗?
Jeremy Henrickson: 百分之百,说过很多次了。这是那种直到你亲身在这里经历之前,很难真正理解的东西,因为首先,它与大多数人过去的背景和文化截然相反。大家习惯的做法是:不不不,别想那么多,就聚焦这一个个案,把它当作一个切入点,然后从那里开始扩展。这也是为什么我们让新人,尤其是那些处于创始角色的新人,进来后先花几个月时间浸润在文化中,真正学习这些经验教训。这也是为什么我们对处于萌芽期的新产品介入非常深入,确保我们不会掉入那个陷阱。特别是因为,与此同时我们也在说:“嘿,但我们需要尽快发布这个产品。“所以你要在这两件事之间取得正确的平衡。
复合型创业公司
Lenny: 所以当我想到 Rippling,我觉得你们的文化就是用困难的方式、正确的方式做事。其中一个要素是,我听说过一个概念——Rippling 是一家”复合型创业公司”(compound startup)?这个词是什么意思?这种理念又是如何影响你们构建产品、组织团队的方式,以及你刚才谈到的那些关于最小可行产品(MVP)和新产品构建方面的做法?
Jeremy Henrickson: 复合型创业公司对我们来说,意味着我们本质上是很多个协同运作的业务。想想我们提供的产品——我们有薪酬,而有专门做薪酬的整家公司;保险和福利,有专门做这个的整家公司。事实上,仅仅是福利的一个片段,就是一整家公司的整个生命周期。我们的 IT 产品、设备管理、身份管理、考勤和工时管理产品——这些东西每一个本身就是一个行业,有数十亿美元规模的公司在分别服务它们。Parker 在创立公司之前的洞见是:当你把这些都分开时,结果就是所有这些数据被反复复制,根本不可能在各处保持同步。正确的做法是拥有一个单一的系统记录源——一个地方、一个数据库,所有信息都驻留在那里,这样每个下游系统都能始终在正确的时间拥有正确的数据。
然后你可以在此基础上构建工作流、报表、分析和权限管理等所有这些底层能力。所以复合型创业公司的理念就是:所有这些不同的业务都受益于建立在同一个平台之上。这个理念的激活能极高。所以在我加入公司之前,Parker、技术联创 Prasanna 等人构建了所有这些产品的第一版,他们能做到这件事本身就是一个奇迹。但一旦做到了,我们就拥有了那个平台,可以继续在那个基础之上构建新的垂直业务和新创项目。
差异化:单一系统记录源
Lenny: 这涉及到一个在本播客中多次出现的话题,就是差异化的重要性。感觉这就是 Rippling 的差异化所在。它不会只是这些垂直解决方案中某个做得更好的版本——核心差异化在于,我们要把所有事情都做了,而且因为全部在一个平台上,一切都会好得多。这是最初的构想来源吗?还是有不同的理解方式?
Jeremy Henrickson: 是的,我认为是这样的。核心论点是,拥有一个单一的系统记录源在很多、很多、很多方面都更好,对吧?最简单的一点是,有一个单一的事实来源,所有其他产品都可以依赖它。但除此之外,如果你不是从一开始就以所有东西都在一个单一系统记录源中为前提来构建,有很多其他事情你就做不了。你没法构建一个——比如说——能跨所有这些产品查看各种属性的权限系统。你突然之间就得做集成,而每个产品说的是不同的语言。你连一些简单的事情都做不了,比如构建一个产品然后问:这个人的经理是谁?大多数产品做不到这一点。大多数产品是找到某个事实来源系统,导出所有人的姓名和邮箱地址到电子表格里,再带上另一个邮箱地址或另一个名字,可能还有一个员工 ID 标识那个人向谁汇报,然后上传到另一个系统——顺便说一下,这些数据立刻就过时了,因为组织架构一直在变。
Jeremy Henrickson: 而在 Rippling,这一切始终是准确的。我们就是那个系统记录源。所以我们的所有产品只需要问:“嘿,这个人的经理是谁?“系统立刻就能给出答案。而这只是一个非常、非常简单的例子,说明了一件事——只有当你从一开始就解决了最复杂的用例,就像之前说的,解决了所有这些数据都必须放在同一个地方这个问题,你才能做到这一点。所以我们的差异化能力归根结底就是这一个根本性的决策,它让我们能够做到其他任何公司实际上根本不可能做到的事情。
快速决策的文化
Lenny: 你觉得 Rippling 文化中最独特的地方,可能是你还没提到的,是什么?
Jeremy Henrickson: 我觉得最根本的一点是执行速度。我认为是决策的速度。这可能是最难在人到来之前向他们解释清楚的事情。你很难理解,直到你亲身体验。就好像——我们不要把会议安排在下周、明天或今天晚些时候。我们正在开会,需要做一个决定,那就当场做决定;如果做不了,我们就立刻在 Slack 上拉需要的人进来通话。今天之内,这个决定就会做完。
当然,确实存在一些不可逆的决策不能这样处理,但在大多数情况下,我们非常重视决策的节奏和响应速度。我待过各种规模的公司,从 5 个人到 5000 个人的,没有一家公司能以 Rippling 这样的节奏运转。我认为我们能够持续保持这种节奏——这部分也要归功于我们是一家复合创业公司(compound startup),拥有这些小型独立运作的团队等等——这是公司文化中非常具有差异化的一点。
Lenny: 我正在读 Kevin Kelly 的新书,不知道你有没有看过。书里全是各种小建议,其中一条就是:通常做某件事最好的时间就是现在。这感觉和你们思考问题的方式很契合。我很好奇,你们是如何创造出这种快速决策的文化和能力的?纯粹是自上而下由创始人塑造的行为模式,还是有其他你觉得有效的方式来建立这种快速行动、快速决策的文化?
Jeremy Henrickson: 显然,很大一部分原因在于 Parker 本人。这是他性格中的一个特质,他喜欢快速做决策,同时这也是他一个刻意的战略选择——要让这家公司成为一个快速决策的公司。所以他不断以身作则,对吧?在 Slack 里、在面对面交流中、在一切可能的方式中。整个公司都有一个期望——如果你去看我们的领导力原则(leadership principles),这种快速决策的能力是每个人都身体力行的。但除此之外,我认为我们还做了很多事情把它融入到了工作方式中,比如我们做季度规划的方式。我们的决策时间线没有给拖沓留下太多空间,而且我们期望人们——尤其是产品方面的人——对自己的领域了如指掌,对吧?
在产品部门,你不是负责某个小功能,你负责的是一个产品,而且你被期望成为这个产品的全球顶尖专家。如果你确实做到了,那就意味着你不必花三天时间回来找人才给出答案,你可以脱口而出:“是的,我认为应该这样做”,或者”给我 30 分钟查一下,我就能告诉你我们需要怎么做。“所以所有这些因素叠加在一起,就形成了一个决策速度极快的环境。
Lenny: 你提到了季度规划,你说有一个时间线,规定在这些日期之前必须做出决策,而且有一种文化就是——我们坚守这个时间线,如果你没赶上,那我们就继续往前走了。
Jeremy Henrickson: 没错。对还没适应这里的人来说,当我们真的继续往前走的时候,他们会感到震惊。就是——不,不,那个日期已经过了。你不能事后让所有人都来应对你行动不够快这个事实,对吧?这不是什么敌意的事情,只是大家需要适应。这是一个深层的组织文化原则。而所有人都站在它身后这一事实,意味着它会靠自身的引力不断被强化。
Lenny: 你们有没有整理过内部价值观?这是你们觉得很有价值的东西吗?
Jeremy Henrickson: 有的,事实上我觉得它们非常有价值。实际上我们的 COO Matt MacInnis——他在我加入之前大约一年加入了公司——他一直是推动这件事的人。你可以去——我不记得具体的 URL 了——在 Rippling 上搜索”Rippling leadership principles”就能找到。它们确实真实反映了这家公司的文化。我们制定这些原则的方式是,几年前我们进行了一次内省,去审视到底是什么让一些人在这家公司取得了成功:谁成功了,为什么成功,为什么他们喜欢在这里?或者反过来看,为什么有些人不合适,为什么有些人不喜欢这里?那些真正产生差异的东西,就是我们写下来的东西。
如何让公司跑得更快
Lenny: 对于一个正在听节目、心想”我们需要跑得更快”的人——每个人总会有这种感觉,我们需要跑得更快,决策更快——你会给他们什么建议,帮助他们在自己的公司实现这一点?
Jeremy Henrickson: 我觉得这非常取决于具体情境,但我认为首先要从那个负责顶层产品决策的人开始——他需要对哪些是优先事项做到极其清晰,更重要的是,对所有不是优先事项的事情也做到极其清晰,对吧?有太多事情可以被说成是重要的,或者人们可以为它们的重要性找到理由,但它们从根本上是在分散注意力,偏离了完成核心任务的目标。
其次,这个人需要一追到底。我们的领导力原则中有一条叫”去看”(go and see)。就是亲自去看那个东西,然后一路追到最底层,和写那行代码的工程师交谈。因为不可避免地,仅靠顶层沟通是不足以传达什么重要、什么不重要的细节的。你不需要在每个地方都这样做,但如果你在足够多的地方这样做了,它的效果就是创造出一种清晰的期望——那种全面的清晰度——并推动每个人都提高一点标准,帮助人们理解期望是什么,对吧?我认为,如果缺少了这种清晰的期望,人们很难发挥出最佳水平。所以我们尽量频繁地这样做。
“去看”原则的由来
Lenny: 好的,我确实想在这个话题上多花点时间,但在此之前——关于”去看”(go and see),我很喜欢这条原则。最近这在好几档播客里都被提到了,就是人们持续提问、一路追到最深处的那些可能性到底有多重要。最近一个例子是 IO 谈到做现金卡的时候,亲自跑到工厂去,看卡片是怎么印出来的,类似这样的事情。
Jeremy Henrickson: 对。
Lenny: 首先,你是否知道这个原则最初是从哪里来的,为什么它对你们来说变得如此重要?其次,有没有一个例子,是你自己这样做,或者你看到别人这样做,最终带来了非常重要的成果?
Jeremy Henrickson: 在我们拓展全球业务的早期,当我们第一次试图弄清楚全球薪酬到底是什么的时候,很容易就会想说,“好吧,我们要进入英国市场,那应该和我们美国做的差不多。“但我们的薪酬负责人亲自去深入了解之后说,实际上,这些是我们知道会不一样的地方,但这些是我们没有预料到会不一样的地方。这让我们意识到,必须彻底改变我们的方法——重新思考如何了解每一个国家、如何进入这些国家,并获得真正完整的体验。
而这又反过来推动了其他事情的落地——比如,每个国家都有税务申报,每个国家做法都略有不同,那我们怎么构建一个税务申报系统,能够满足我们将在每个国家运行薪酬的需求?正是因为在最早期对一个国家的实际运作方式进行了深入审视,然后对下一个国家做了同样的事,我们才得以把所有这些事情启动起来。并不是说我们在那个阶段就知道了所有答案,但它让我们在非常早的阶段就开始推动一系列需要做的事情,这些东西随后随着时间的推移变得越来越清晰、越来越精确。
Lenny: 所以那个团队的负责人基本上就是亲自去研究了每个国家的税法——
Jeremy Henrickson: 对。
Lenny: ——各个国家的。
Jeremy Henrickson: 没错,一路追到最底层。就是,好吧,我们打开那本大厚书——当然现在都是线上了——翻开来看,或者你在美国的话,你得去看俄亥俄州或宾夕法尼亚州,它们有各种各样基于地方城市或县的税收。只要看几个这样的案例就非常有启发性,你会想,天哪,我怎么考虑配置这些税种的变化——而且这些变化是没有提前通知的?某个城市的管理者或市立法机构——不管他们叫什么——他们决定改税率。那我们怎么知道这件事?我们怎么去更新?怎么确保更改在正确的时间生效?
除非你一路追到最底层,去看这些东西实际上是怎么运作的、怎么传达的、怎么被思考的,否则你根本不会想到这些问题。我认为产品的每一个方面、在每一个维度上都是如此,对吧?它可能是一个技术层面的事,可能是设计层面的事,可能是合规、监管或政府相关的事,但无论是什么,那个细节永远存在。除非你沉下去亲眼看到它、亲自理解它,否则你并不真正理解你的产品需要做什么。
不要把这个环节委派给别人
Lenny: 我觉得这里有一个字里行间的关键信息——不要把这个环节委派给别人。你的团队里可能有税务专家,我猜很多领导者会说,去把这件事搞清楚,然后告诉我。而我觉得你说的恰恰相反——你自己亲自去,去学习,成为这方面的世界级专家。
Jeremy Henrickson: 没错,没错。你亲自去做,亲自去学,然后我们才有理由去雇那个税务专家——我们现在确实有税务专家,顺便说一下。那是我们成功中极其重要的一部分,拥有这样的专业人才,但前提是必须先有一个具备产品思维的人深入到底层去。税务专家在税务方面当然很厉害,对吧?那是他们热爱和擅长的事情,但这不意味着他们天然就是出色的产品思考者。所以那个有产品思维的人必须先深入到同样层次的细节中,才能真正理解它。
Lenny: 关于在这类事情上应该花多少时间, versus 日常的产品领导工作——要成为多个国家税务系统的世界级专家,这需要大量时间。你会给出什么指导吗?还是说,没有比这更重要的事情了,这就是你的工作,你不做这个在做什么?你怎么思考这个问题?
Jeremy Henrickson: 我觉得,如果一份工作需要八十个小时,那其中四十个小时应该花在这上面。我认为,除非你亲自深入到那个层面,否则你无法真正理解一个产品。对,这确实需要时间,你说得对,你也不能忽视工作的另一半——和工程团队沟通、写文档等等。但如果你不知道自己在说什么,写文档又有什么意义?所以我们非常看重这一点。这也是为什么我们在 Rippling 至少保持产品组织非常精简的原因。我们期望单个领导者能够了解产品的完整范围。事实上,优秀的产品领导者确实能做到这一点,因为他们天生有好奇心、有兴趣,有能力吸收大量信息。而且这也很有趣,因为现在我周围都是一群在各自领域非常出色、真正理解自己在做什么的人,那是一个相当了不起的状态。
领导者要经常做对决策
Lenny: 我看着这份原则清单,忍不住想继续追问。其中有一条原则我很喜欢——它让我想到亚马逊也有一条类似的原则,就是”领导者经常是对的”。
Jeremy Henrickson: 对。
Lenny: 为什么你觉得这条很重要?我知道这些原则不一定都是你设计的,但我猜这是你们经常遵循、经常被提起的一条。
Jeremy Henrickson: 这条是我最喜欢的原则之一,因为我认为尤其对一个产品组织来说,对吧?产品领导者必须在大多数时候做出正确的决策,因为他们的决策会反映到整个组织中,他们的决策本质上就是在消耗时间和精力。如果他们做出了好的决策,公司就会表现得很好;如果做出了糟糕的决策,公司就不会。我在产品领导者身上非常看重的品质之一,就是那些能够在信息不明确、情况模糊、信息不完整、决策空间复杂的情况下,审视这一切,倾听每个人的意见,阅读需要阅读的资料,然后说:这就是我们要去的方向。
即使其他所有人都在说,“嗯,我不知道,这感觉不对,因为这个原因、那个原因”——如果他有信心做出那个判断,然后一年后你回头看,发现他是对的,这是极其有价值的。而且这是一种真的很难测试的能力。你可以通过和人们交谈来了解,问他们,“嘿,这个人通常是对的吗?“人们会想一想,但在某个特定公司的语境下,你必须花时间去验证这些决策大体上是否正确。这也是我们所有价值观中独特的一条——它很难学会。你要么非常擅长做这类决策,要么不擅长,对吧?这是一种我们非常看重的非常特殊的能力。
全球扩张的决策
Lenny: 好的。换个话题,我知道你们正在进行全球化扩张。我们之前稍微聊过一点。
Jeremy Henrickson: 是的。
Lenny: 围绕这个方向我有几个问题,因为很多公司都是先在一个国家起步,大多数公司都是如此,然后才决定拓展到新市场。所以第一个问题是,你们如何决定要进入哪些市场?具体来说,先从哪里开始,然后如何对市场列表进行优先排序?你大概的算法是什么样的?
Jeremy Henrickson: 首先从一个前提假设出发,就是我们最终必须在所有地方都有布局。你其实不一定非要在世界上每个国家都建设原生的全球薪资系统,但这样做确实合理。但你肯定希望能够向世界上任何国家的人支付薪酬,能够在世界上任何地方雇佣承包商,并且他们的信息能出现在你的人力资源系统中。所以对我们来说做这个决定的时候,我们很幸运地——已经有相当多的客户了,数千家客户。所以我们不仅知道他们的美国员工在哪里,而且由于我们是员工系统,我们实际上知道他们在其他地方的员工在哪里。所以我们很容易就能判断——当然仅仅关注总部在美国的公司,数据并不完整——但如果我们只看总部在美国的公司,我们就知道这些客户有迫切需求要向X、Y、Z国家的人支付薪酬。我们直接按原始数字顺序列出来,然后评估,在每个国家建设的难度有多大,价值有多大?在英国、加拿大、德国或印度等地建设的战略价值是什么?然后我们讨论了风险在哪里,哪里比较困难,哪里周期很长,哪些国家需要很长时间才能获得审批之类的。我们就这么做了个堆叠排序,然后重新审视这个决定。我们早期关于具体进入哪些国家的决策,后来随着时间推移做了重新调整。随着我们深入各个国家、了解更多信息,我们对排序做了一些微调。但大体上,我们最初制定的那个基本列表现在仍然基本正确。
Lenny: 好的。另一个很多创始人都在纠结的问题是,什么时候开始国际化扩张?因为有利有弊。你有没有一种感觉,是什么让你们决定开始走向国际的?
Jeremy Henrickson: 我觉得我们的情况有点特殊,但我认为这个问题的正确答案始终是:比你认为需要的时候更早开始,比你认为不得不做的时候更早去做。因为如果你从来没做过这件事,它比你想象的要难,比你想象的更专业。英国人真的很在意 “color” 里面有没有一个 “u”,就像我们很在意没有那个 “u” 一样。这些微妙的文化差异,公司需要花很长时间才能吸收。所以我的观点是,你应该总是在比你认为自己应该做的时间更早的时候去做。在我们的情况下,这是我们一直都知道必须要做的事情。事实上,我们有一个非常清晰的论点:不全球化的公司——尤其是在薪资领域,但也包括保险、福利和IT领域——如果不全球化,十年后就无法生存下去。因为公司本来就在变得全球化,然后新冠疫情发生了,公司全球化的速度大大加快了。全球化不再是百人以上公司的专利,开始向下渗透到非常小的公司。小公司跨国经营变得司空见惯。这极大加速了我们的时间表。然后你会发现其他公司也注意到了这一点,开始尝试解决这个问题的不同部分。所以存在一个竞争维度,这在大多数方面是次要的,因为我们本来就要做这件事,但这确实也给大家添了一把火。
国际化扩张中的惊喜与教训
Lenny: 关于国际化扩张,你觉得最令人意外的是什么?对于那些可能刚开始考虑这条路、想着”糟糕,我们应该想想这件事”的人,有什么启示?
Jeremy Henrickson: 我觉得最令我意外的事情——我第一次经历这个是在 Guidewire 时期——也是每次我再做这件事时最令大多数人意外的,就是:每个国家都是独特的。你不能把美国的做法直接搬到另一个国家。其他国家会觉得这是冒犯。不管你在这里有多成功,当地人总是相信——不管对错——他们当地的情境是特殊的。你必须尊重这一点。这体现在一些细节上,比如 “color” 里有没有一个 “u”。或者如果你看到给另一个国家的人做产品演示时,详细的人员信息界面里出现了社会安全号码,你就立刻失去了信誉。不管你其他所有功能做得多好都没用。
我认为这一点始终是最让人意外的,就是这种程度有多深——虽然事后看来似乎很明显。如果有人拿一个德国系统、用翻译得很差的内容到美国来演示,我们也会觉得它很烂。但真正困难的是去适应那种思维模式。所以要在组织层面克服这个问题,需要投入大量精力。
Lenny: 非常有道理。我现在换个方向。
Jeremy Henrickson: 好的。
对框架的看法
Lenny: 框架。我知道你不算是框架的忠实粉丝。我们在录制之前聊过这个话题。所以我很好奇听听你的看法——为什么你可能不太推崇框架,以及如果你不是直接对团队说”嘿,这是你们应该用的框架”,那你是如何为团队提炼流程和概念的?
Jeremy Henrickson: 听着,我认为框架是很有帮助的。所以我不完全是反框架,但我反对用流程来替代深度的产品思考,明白吗?我倾向于只保留刚好够用的流程,来搭建一个框架,让正确的决策能够在其中发生。我认为尤其是当公司规模扩大时,会有一种危险,你最终会说,“只要我们在 Jira 里把所有东西正确分类,我们就能做出非常好的优先级决策。“我的意思是,清晰的分类当然非常有帮助,Jira 里没有的那些东西——比如数据和分析——也同样重要。但你真正需要做的是决定什么是重要该建的,然后找到一种高效的方式来构建它。所以我认为,对于任何一个给定团队来说,正确数量的流程,或者说正确的框架,实际上取决于他们所处的具体生命周期阶段。
所以你不会听到我说,“哦,我们需要用这个 Scrum 方法或者那个 Combine 方法,或者随便什么最新的新东西。“我不在乎那些。我在乎的是,什么东西能让这个团队在当前的情境下、在他们生命周期的这个节点,尽可能高效地构建正确的东西。不同的团队用不同的方式,我完全接受。我唯一在乎统一的地方有两点:一是季度规划流程,二是所有东西确实都需要放在 Jira 里,因为否则你无法真正搞清楚到底在做什么、不在做什么。
有害的流程与框架
Lenny: 有没有哪种流程或框架是你觉得适得其反、需要避开的?比如”我们在这个东西上吃了不少亏”,或者一般来说,“我们还是从头重新思考吧”。
Jeremy Henrickson: 没有,我没觉得哪一个特定框架是——我没有持续地发现某一个框架特别有问题。我认为任何框架都有它的用武之地,合适的地方、合适的时机。我认为危险在于,任何时候如果有人教条地说”我觉得我们应该用流程 X”——因为在我经验中这几乎从来不是正确答案。我认为也有一些例外情况,比如你创建公司的基础就是流程 X,所有人都认同并理解这个流程,那我觉得它可以非常非常好。在工程方面,我认为这非常有价值。比如测试驱动开发(test-driven development),第一行代码就是测试,而不是实际的功能代码。太棒了,我非常支持这一切。但在产品领域,我觉得情况不太一样。
Coinbase 与 Rippling 的产品开发差异
Lenny: 如果你必须比较 Coinbase 和 Rippling 在构建产品的流程方面、或者说产品开发方面的异同,你会说最大的区别是什么?
Jeremy Henrickson: 我认为这些差异很大程度上源于不同的领域。加密货币,正如我们之前聊到的,真的很难预测会发生什么。有太多关于加密货币未来的问题——什么会重要、我们到底需要建什么、什么能存活下来。所以在 Coinbase,我们的流程核心就是围绕这些辩论,做出决定,然后”虽然不同意但承诺执行”(disagree and commit)。然后从执行的角度来看,能够快速行动。这就是 Coinbase 的关键所在。而在这里,我们在高层面上知道自己需要构建什么。关键在于,我们如何基于我们拥有的这些出色的平台能力来实现真正的差异化?或者说我们如何演进这些平台能力,以持续构建出比市场上所有东西都断崖式领先的产品?这会催生一种不同的决策流程。所以对我来说,我的思维模型——我如何对待这些事情——其实是一样的,但它们在实际开发软件的过程中会产生不同的结果。
Lenny: 具体差异到底是什么?你在日常中感受到的是什么?是时间线上的差异?是速度上的不同?还是你组织工作的方式、你计划多远的未来?你觉得具体的差异是什么?
Jeremy Henrickson: 我认为差异在于日常决策的速度。因为在 Rippling,随便找一个团队——比如你在设备管理团队,你知道自己该做什么,对吧?没有模糊地带。你不需要争论 Mac 或者 Windows 未来会不会存在。完全没有那种认知失调。就是”我们需要构建这个东西”。困难的是搞清楚怎么构建,对吧?因为有各种不同的东西可以利用,但基本上我们就是需要把这事儿做成。
所以我觉得这里整体的速度会更高一些。这并不是说这里的人比在 Coinbase 工作更努力。Coinbase 是一个速度极快的环境,但它也受制于一个事实——你根本不知道加密货币市场会怎样,你必须对此做出极其快速的反应。所以我觉得可能这一点是——对环境的反应能力,加密货币环境的动态,以及监管环境的不确定性,所有这些东西。我们在 Coinbase 变得非常、非常、非常擅长快速处理这些事情,而在这里,我们需要处理这类情况的程度要低一些。
Coinbase 的压力与回忆
Lenny: 听起来在 Coinbase 压力挺大的。
Jeremy Henrickson: 是的,我意思是,也很有趣。是的,压力很大。我意思是,我做过的每一份工作都有压力,但每份工作的压力各有各的独特之处。但所有那些压力,我认为都是以问题的形态存在的,是在一个真正有趣的问题的语境下的。这就是为什么我一直留在了这些地方。但确实,压力很大。
Lenny: 回头看的话,会觉得是一段很愉快的经历吧。
Jeremy Henrickson: 是的。不,有很多非常好的回忆。我回头看的时候,我记得那种压力,但我不会重新体验到它,你知道吧。我记得的是建立那些关系、构建那些我有幸参与的很棒的产品。所以我对我去过的地方几乎只有美好的回忆。
Lenny: 我也有同感。你经历了那些艰难时刻,然后回头看,你会觉得”哇,那真是太酷了”。但前提是结果不错、公司做成了——
Jeremy Henrickson: 确实。
Lenny: ——你会觉得那是成功的。很多时候你在一家创业公司,生活糟糕了两年,最后没做成。虽然也有收获和好的回忆,但就没那么辉煌了。
Jeremy Henrickson: 是的,这话说得对。不过,我毕业后的第一家公司是一家叫 Reactivity 的公司,那是互联网 1.0 时代,我们在摸索这个互联网的东西到底怎么运作,如何基于这些新技术创建公司,以及如何帮助其他公司构建东西、搞清楚方向。那家公司从根本上来说没有成功,最终拆分之后被收购了,这很好,但那是一群非凡的人,我非常幸运能和他们一起工作,我很珍惜在那里度过的所有时光,它对我后来做的一切都是奠基性的。所以即使那次努力没有在传统意义上获得回报,我在那里学到的东西的价值、以及我有机会共事的人,都是真正杰出的。我觉得自己非常幸运。
Lenny: 这确实是一个很好的观点。我觉得我甚至应该纠正我刚才说的——即使事情没有成功,传统意义上讲,那些经历最终也会以各种意想不到的方式变得极其有价值。
Jeremy Henrickson: 是的,百分之百同意。
招聘产品经理
Lenny: 好,那么最后一个话题。
Jeremy Henrickson: 好的。
Lenny: 我想聊聊招聘产品经理和面试。
Jeremy Henrickson: 好。
Lenny: 这些年来你招了很多产品经理。我很好奇,关于在产品经理以及产品领导者身上应该看重什么,你有什么心得是其他人可能不够重视的?
Jeremy Henrickson: 我倒不觉得我在这方面有什么特别独到的见解。但确实有几件事我在面试中会比较强调,可能因为这是 Rippling 所以会更注重。第一件是,候选人走我们的面试流程时,有一个环节是做案例分析(case study),这个案例分析的一个重要特点是,它实际上太复杂了,候选人不可能一开始就有所有的答案。问题的空间太大了,做不到面面俱到。这就意味着在面试中——或者说在案例分析中——有很多机会可以随机提问,或者改变某个假设前提。观察人们如何应对这些变化,非常能说明他们理解新问题有多深入、理解速度有多快、以及思维有多敏捷。
面试中的提问质量
Jeremy Henrickson: 有些人在这方面极其出色——某个假设前提一变,他们眨两下眼睛,就会说:“哦,那会有这四百条连锁影响。“然后就开始一条条列出来。而有些人则会完全手足无措。显然对我们的环境来说,前者对我们真的、真的很重要。我觉得另一件对我来说非常重要的事,是人们所提问题的洞察力,这首先反映了他们对这份工作的真实兴趣。
人们在越兴奋想去一个地方工作时,往往越会做足功课,会向别人打听情况,提出的问题也就越好。而且这些问题的质量差异可以非常大。这没关系,我不指望质量始终如一。但有时候有人提出一个问题,我会觉得:“天哪,我根本想不到问这个问题。太有洞察力了。“然后我会停下来,需要想一想该怎么回答。这实际上反过来推动了我自己变得更好一点。当这种情况发生时,我就知道面前很可能是一位非常优秀的候选人。
Lenny: 有没有一个具体的例子浮现在你脑海中,某人问了一个非常好的问题,让你回想起来觉得”哇,那个问题真棒”?
Kyle Boston 的面试故事
Jeremy Henrickson: 我记得大约三年前,我在面试一位叫 Kyle Boston 的人,Kyle 现在负责我们的平台产品组织。我记不清他具体问的问题是什么了,但大概是这样的意思——“等一下,如果你有这么多产品,底下又有这个员工系统记录,那你们有没有想过如何创建这些底层平台技术的不同支柱,比如[听不清]之类的东西。“那是在我们还没有将平台的概念从员工系统记录完全正式化之前。
我记得我当时想,是的,我们应该这么做,这个想法之前也出现过,但真正让我印象深刻的是,一个几乎对公司没有任何背景了解的人能提出这样的问题。就好像,天哪,你在同时面试很多家公司的时候,花了几周时间思考 Rippling,就能如此深入地思考到我们所构建平台的本质,这立刻让我对他的思维能力产生了极大的信心,相信他能想清楚我们需要他去思考的那些问题。
产品经理需要具备商业思维
Lenny: 我觉得这触及到了一个点——产品经理需要成为商业领导者,而好的问题往往是关于业务本身、业务的未来、如何让运营更高效等等,虽然也有产品组织的层面。但我发现这是产品经理面试中一个非常被低估的要素,就是去思考更大的商业图景,而不仅仅是产品经理负责的产品本身。
Jeremy Henrickson: 对我来说是两个方面。一方面是思考更大的商业图景,有相关的背景知识,不管是收入问题还是战略问题;另一方面是对细节的追问。比如:“等一下,我被问到的这个事情——或者你 Jeremy 刚才说的那个事情——它的含义其实是所有这些东西。“他们能理解这不是一个简单的生意,这真的很难,真的非常复杂。而他们能够产生这些洞察来帮助自己理清这些细节,这真的很酷。
给产品经理的面试提示
Lenny: 你之前提到过你会给产品经理一个提示,能不能不要透露你现在实际问的是什么,但有没有一个你过去用过的提示的例子,或者你认为适合给产品经理候选人的那种提示的一个好例子?
Jeremy Henrickson: 从总体方法来说,我认为提示应该始终反映他们即将加入的实际业务。所以我们的整体流程其实相当短。基本上就是通过某种方式联系上我们,最终和招聘经理对接上,和他聊一次。然后基本上就是和我进行一次对话,是一次产品讨论。之后是一个案例分析,紧跟在那之后。这就是全部流程了,加上边缘的一些其他对话。真正重要的是,人们如何思考那个与我们的业务相关的产品讨论,以及如何思考那个案例分析。这是第一点。第二点是,我的面试中始终有一部分,听起来可能非常简单,就是:“嘿,你有什么问题想问我吗?”
实际上我们是在进行产品讨论之前就做这一步。这是一个极其重要的问题,因为它再次反映了人们思考了什么、没有思考什么、思考的深度如何、以及对这个角色的投入和兴趣程度。在第二阶段,不要求完美,但当人们——无论是事先准备了一组想问的问题,还是临场发挥——你都能从这些问题中了解到很多:人们如何看待产品,他们在寻找什么,他们喜欢做什么、不喜欢做什么。
给早期职业产品经理的建议
Lenny: 对于那些可能正处于职业早期的产品经理听众,你会给他们什么建议来帮助他们在职业早期加速成长?
Jeremy Henrickson: 保持谦逊。做一个产品人意味着,你身处的是一个没有人知道正确答案的世界——因为如果有人知道,他们早就已经做出来了。所以无论你多聪明,外面总有很聪明的人。总有你不知道的东西,总有别人会知道你不知道的事情。只有承认这一点,你才能真正保持谦逊,说出”我愿意接受所有这些我不知道的东西”,并愿意去综合这些信息,得出不同的结论。
所以我发现这种谦逊是早期职业领导者之间最大的区分因素之一——那些能够放下自己在学校或第一份工作中有多厉害的人。我自己也经历过这个过程,要认识到这份工作永远很难,这份工作每一天都是关于发现。如果你能保持那种好奇心、思维的弹性、创造力,并且让解决问题的思路保持开放,那会非常棒。但如果你把自己封闭起来,认为自己总是有正确答案,那就没有希望了。
优秀的领导者经常改变想法
Lenny: 这让我想到了另一条原则,我屏幕上还挂着——“优秀的领导者经常改变想法”,或者就是”改变想法”。
Jeremy Henrickson: 对。愿意看到新信息后说,我的心智模型因此调整了,或者很简单地承认”我错了”。我觉得同样重要的是,你要处在一个允许你说自己错了的环境中,对吧?每个人都会犯错。虽然要对的时候比对的时候多,但每个人都会犯错,对吧?能够处在一个你可以说”是的,我错了,我错的方式是这样的,我们继续往前走”的环境中,这是极其有力量的。
与产品型创始人共事
Lenny: 最后一个问题。你多次提到 Parker,他身上很清楚的一点是,他是一个非常有产品思维的创始人。他对产品应该是什么样有很多强烈的观点。作为一个产品领导者,面对这样的创始人,往往是一个充满挑战的位置,类似于在创业公司做第一个产品经理,而创始人对产品有强烈的主见。所以我的问题就是,你从与一位对产品应该是什么有非常强烈观点的创始人合作中,学到了什么关于做好产品领导者的经验?
Jeremy Henrickson: 好问题。我觉得你需要具备适应性,对吧?就像任何其他关系一样。你要理解这段关系的本质是什么,对方在意什么,你在意什么,你们以什么方式相互挑战。我认为根本前提是,你要确保那个人是愿意接受挑战的。我见过一些产品负责人或 CEO,他们不太愿意被挑战,我没办法跟那样的人合作。
Parker 确实观点非常强烈,但他也极其博学,这让我们的讨论非常精彩。而且我发现,不管是什么——甚至不只是 CEO,不管一个管理者有什么样的个人特质,你都要找到与之合作的方式。我觉得这种适应性……我把自己看作一块可塑的拼图,能够嵌入各种形状。我认为这其实是我的一项核心能力。所以我和 Parker 之间配合得很好,在我们之间建立起深厚的信任基础之前,这一点非常重要,而要建立这种关系,深厚的尊重是极其关键的。这些年我们的尊重越来越深,我们并不总是意见一致,但我们可以就此展开完全理性的讨论,这正是其中的乐趣所在。
Lenny: 适应性其实——我曾经做过一次优势识别测试,那是我排名第一的优势。我觉得我们在这一点上是共通的。
Jeremy Henrickson: 太好了。
Lenny: 嗯,看来这确实是身处这个位置的一个重要特质。好了,接下来进入我们非常激动人心的闪电问答环节。我准备了六个问题,准备好了吗?
Jeremy Henrickson: 好,准备好了,放马过来。
闪电问答
Lenny: 开始了。你向别人推荐最多的两三本书是什么?
Jeremy Henrickson: 首先是史上我最喜欢的系列小说——Neal Stephenson 的《Baroque Cycle》。它是一部九卷本史诗,或者说是三卷本、九册的史诗,取决于你怎么算。它讲的是启蒙运动前夕到启蒙运动初期那段时期的故事,是历史小说,非常有趣。另外我也很喜欢 Iain Banks 的《Culture》系列,那是一个超级有趣的遥远未来宇宙,我非常喜欢。
Lenny: 最近最喜欢的电影或电视剧是什么?
Jeremy Henrickson: 看了《The Last of Us》,我是那个游戏的忠实粉丝,觉得他们改编得非常好。最喜欢的电影嘛,算是比较近的吧,其实也没那么近——我很喜欢《Tenet》,我对他们敢去拍这样一部电影的能力印象深刻,从头到尾都非常享受。
Lenny: 这游戏算是结束了,但我们之前有个喝酒游戏,只要有人提到《The Last of Us》就得喝,之前它已经取代了《White Lotus》。我现在就喝口茶。
Jeremy Henrickson: 好的,没问题。我尽量吧。我平时喝茶,但今天只有水。
Lenny: 也行。不过有意思的是,这个话题出现得不多,所以我们先这样吧,看看会不会形成新的规律。然后《Tenet》感觉就像——我刚才在想,它就像一部”复合”电影,就像复合创业公司拍成电影一样,一部电影也非常复杂——
Jeremy Henrickson: 对,所以我才喜欢。我喜欢在电影进行的过程中在脑子里梳理多条时间线的图谱。
Lenny: 你心里的那块拼图在试图找到所有的拼图碎片。
Jeremy Henrickson: 没错。
Lenny: 你最喜欢问的面试问题是什么?你之前可能已经回答过这个问题了,还有什么别的吗?
Jeremy Henrickson: 我觉得我确实回答过了。不,我最喜欢的问题就是”你有什么问题想问我吗”,毫无疑问。
Lenny: 很好。你最近发现并喜欢的产品有哪些?
Jeremy Henrickson: 我提两个吧,不知道能不能算”最喜欢的产品”,但有两个印象比较深。前几天我太太的电脑坏了,我发现是 CPU 散热器坏了,而 Corsair H60 CPU 散热器非常容易安装,而且兼容很多种主板,我觉得非常棒。另一个就是我现在耳朵上戴的这个。我之前买的第一副好耳机上周坏了,不得不赶紧做了些研究,找到了我现在最喜欢的新耳机。这副 Focal Bathys 非常出色。我算是个音频发烧友,喜欢听古典音乐和环境音乐,所以需要很大的动态范围和降噪功能,这副耳机目前表现非常好。
Lenny: 它们叫什么名字?
Jeremy Henrickson: Focal,好像是 Bathys,B-A-T-H-Y-S。
Lenny: 有具体的型号吗,还是就那一种?
Jeremy Henrickson: 就那一种。
Lenny: 好的。
Jeremy Henrickson: 你看到就知道了。
Lenny: 好,我们会在节目笔记里放链接,说不定我也买一副。有没有什么你在做产品方式上做过的相对较小的改变,但对团队执行力的提升产生了很大影响?
Jeremy Henrickson: 最近在 Rippling 的一个创新,大概是引入了我所说的”imperatives”(要务)。这些东西不管是自下而上还是自上而下产生的,都是整个产品和工程团队所有人需要做的事情。而同样重要的是,那份清单上没有放进去的东西。在一个我们可能同时选择做上百件事情的环境里,能够对那个清单进行强制排序、划一条线,说”这些是每个人都必须做的”,这给我们带来了比以前更多的聚焦和清晰度。
Lenny: 所以 imperatives 本质上就是比如未来一个季度或半年的优先事项,对吗?
Jeremy Henrickson: 这是所有人的优先事项,然后你要把它整合进你自己团队的优先级里。每个团队仍然在制定自己的优先级,但他们必须把这组事项纳入考量。
Lenny: 你们通常有多少个?这个方法很棒,我喜欢这个建议。
Jeremy Henrickson: 取决于你在什么粒度上讨论,大概十个吧,不少。我们正在推进全球化、平台大规模改进以及一系列其他大型项目。所有这些都产生了许多必须跨团队同步推进的事项。我觉得这是公司发展过程中很自然的一个阶段,而我们正好处于这个周期中。
Lenny: 太棒了。
Jeremy Henrickson: 这个方法效果不错。
Lenny: 最后一个问题:有什么我应该问你但没问的问题?
Jeremy Henrickson: 大概是,我和孩子们做什么吧?我有两个孩子,一个九岁一个——
Lenny: 你和孩子们做什么?
Jeremy Henrickson: 一个六岁。我和孩子们做什么?我是个桌游爱好者,虽然我没有刻意推他,但我儿子可以从早到晚玩桌游。所以我们经常一起玩欧洲策略桌游。我女儿现在也到年纪了,也开始感兴趣了。我们一家刚玩完《Pandemic Legacy》,明晚的奖励是我们开始玩《Gloomhaven》,会很开心。
Lenny: 这两个游戏我都不了解,听起来都很难很复杂。
Jeremy Henrickson: 很好玩,很好玩。
结语
Lenny: 太棒了。Jeremy,我们今天聊了很多话题,感觉这是一期复合播客(compound podcast)节目。非常感谢你抽出时间,感谢你的到来。最后两个问题:正在找工作的听众如果在网上看到你的信息想联系你、了解更多,应该去哪里找?听众怎样能帮到你?
Jeremy Henrickson: 好的。LinkedIn 是最方便的在线联系方式。如果今天我聊的内容让你感兴趣,我们确实在招聘资深的、有创业精神的产品经理。所以如果我们网站上那些领导力原则(leadership principles)看起来让你感兴趣,我很期待听到你的消息。
Lenny: 了解这些职位并申请的最佳方式是什么?
Jeremy Henrickson: 网站是目前最好的渠道。信息会直接送到对应的招聘人员手上,他们会立刻告诉我。
Lenny: 好的,rippling.com,应该也有一个招聘页面。
Jeremy Henrickson: 上面有招聘网站,很容易找到。
Lenny: 好的,链接会放在节目备注里。Jeremy,再次感谢你的到来。
Jeremy Henrickson: 非常感谢邀请,这次很开心。
Lenny: 大家好,非常感谢收听。如果你觉得这期节目有价值,可以在 Apple Podcast、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们评分或留下评论,这真的能帮助其他听众找到这档节目。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于节目的信息。下期再见。
术语表
| 原文 | 中文 |
|---|---|
| case study | 案例分析(case study) |
| Coinbase | 保留原文 |
| component library | 组件库 |
| compound startup | 复合创业公司(compound startup) |
| disagree and commit | ”虽然不同意但承诺执行”(disagree and commit) |
| dogfood | 内部试用(dogfood) |
| DRI | 直接负责人(DRI) |
| Dunbar’s number | 邓巴数(Dunbar’s number) |
| Ethereum | 以太坊 |
| go and see | ”去看”(go and see) |
| imperatives | 要务(imperatives) |
| Jeremy Henrickson | 保留原文 |
| Kevin Kelly | 凯文·凯利 |
| Kyle Boston | 保留原文 |
| leadership principles | 领导力原则(leadership principles) |
| Matt MacInnis | 保留原文 |
| MVP | 最小可行产品(MVP) |
| Parker | 保留原文 |
| Reactivity | 保留原文 |
| Rippling | 保留原文 |
| Sachit | 保留原文 |
| system of record | 系统记录(system of record) |
| test-driven development | 测试驱动开发(test-driven development) |
| time and attendance product | 考勤和工时管理产品 |
| zero-to-one | 从零到一 |
此文档由 AI 分片翻译(translate_long_document)