Lenny's Podcast: Product | Growth | Career: Moving fast and navigating uncertainty | Jeremy Henrickson (Rippling, Coinbase)

It's very, very tempting to kind of float up here as a leader and say,

Hey, you know, you take that hill over there.

You guys do this over here.

When in fact, like what you, where you really learn where the

challenges are or the problems or the successes is by like, just like being

there with, with the people in the trenches on like one of the things,

like 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, by going through that detailed exercise.

Welcome to Lenny's podcast, where I 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 Henriksen.

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 10x 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 of

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 design for the most complex use cases first and tons more.

Enjoy this episode with Jeremy Henriksen after a short word from our sponsors.

Today's episode is brought to you by Miro, an online collaborative whiteboard

that's designed specifically for teams like yours.

The best way to see what Miro is all about and how it can help your team

collaborate better is not to listen to me talk about it, but to go check it out

for yourself. Go to Miro.com slash Lenny.

With the help of the Miro team, I created a super cool Miro board with two

of my own favorite templates, my one-pager template and my managing up

template that you can plug and play and start using immediately with your team.

I've also embedded a handful of my favorite templates that other people

have published in the Miroverse. When you get to the board, you can also

leave suggestions for the podcast, answer a question that I have for you and

generally just play around to get a sense of how it all works.

Miro is a killer tool for brainstorming with your team, playing out your

strategy, sharing user research findings, capturing ideas, giving feedback

on wireframes and generally just collaborating with your colleagues.

I actually used Miro to collaborate with the Miro team on creating my own board.

And it was super fun and super easy.

Go check it out at Miro.com slash Lenny.

That's Miro.com slash Lenny.

This episode is brought to you by Mixpanel.

Get deep insights into what your users are doing at every stage of the funnel

at a fair price that scales as you grow.

Mixpanel gives you quick answers about your users from awareness to acquisition

through retention and by capturing website activity, add data and multi touch

attribution right in Mixpanel.

You can improve every aspect of the full user funnel powered by first party

behavioral data instead of third party cookies.

Mixpanel is built to be more powerful and easier to use than Google Analytics.

Explore plans for teams of every size and see what Mixpanel can do for you at

mixpanel.com slash friends slash Lenny.

And while you're at it, they're also hiring.

So check it out at mixpanel.com slash friends slash Lenny.

Jeremy, welcome to the podcast.

Thank you so much for having me.

I'm excited to be here.

So I heard nothing but amazing things about you and I'm excited to learn from

what you've learned from your experience at Rippling and Coinbase and all of the

products and teams that you've built.

And so thank you again for being here.

Yeah, super happy to be here.

So I want to start with a, with your time at Coinbase where you're a chief product

officer and your chief product officer during maybe the craziest time in the

crypto markets.

It was a, I think 2016, 2018 when I was looking at the Bitcoin prices and it was

like, it went from like $1,000 to $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?

The strongest memories for me for me are during like 2017 where crypto, which has

kind of been at its nadir in like early 2016 and kind of slowly started climbing

out, just kind of took off and became a real thing in the, in the public

consciousness and, you know, Coinbase, which at the time had, you know, an

exchange just like on ramp and off ramp from fiat to crypto and back, experienced

over the course of 2017, 40X growth in usage.

That's like a dream come true for, for a lot of people.

It's, it, no, I mean, it, it was, it was both a dream and a nightmare, you know,

and I was, I was incredibly lucky to be working on it with a, with a team of

people that I could really trust and could stand shoulder to shoulder with

and in the trenches.

And it was a lot of learning about how you can rapidly scale systems over time.

And, you know, people like to trade crypto on Saturday mornings.

So a lot of Saturday mornings, there's like some new like, like thing would

break on the edges of the system and we need to kind of get in there and, and,

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.

Okay.

So let's actually unpack a couple of those.

So focus is really interesting and something people always talk about, but,

you know, hard to actually do.

I guess how did you keep the team focused?

I imagine just like, you know, everyone's getting rich all over the place in

crypto, things are breaking all the time.

Like how did you maintain focus on, on your team?

Well, the first thing is you don't talk about people getting rich.

It's like, it's a, it's a very technical, it's a very technical that you talk

about, like it's customers, it's their money, right?

And number one, it had to be secure.

Right.

So there's a guy named Phillip Barton, friend of mine now, and he's, he's just

this amazing like security leader, um, at, at Coinbase.

And he was able to always put these like decisions that we were making

extremely quickly, like in context, right?

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 like the number, the number one thing.

And then the second thing is like focusing on like the, the, both the kind

of immediate nature of the issue, hey, site is down or whatever.

I'm like resolving that, but also trying to set those in a context of like where

we need to go over the next six months.

Like, what are we actually shooting for?

What do we believe the volumes are going to be?

What's it going to take to, to, to have, you know, everything from a user

experience to kind of the, the deep back end of the product that what would

actually work for them.

What was maybe the biggest challenge as a product leader and trying to keep

people focused and everything on the rails as things were going 40X?

I think the biggest challenge was that in crypto, there's just so much

uncertainty in general, like simple questions like, is a theory, I'm going

to be a thing, right?

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, because lots

is going, 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,

that you're all shooting toward.

And like, while there may still be differing points of views and debates

that happen on the margins, like 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.

Maybe just the last question there.

Sure.

Living through a time like that, a lot of people are going through these

periods of just like 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 of those

important, meaningful periods of your career.

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 like, here's, there's maybe the silver lining

of being in a period like that.

So it's hard, right?

It wasn't, wasn't always easy.

I had like a new daughter who had been born just a few months earlier, right?

Really tough to like, kind of balance, balance those things.

But I've always loved the rate of learning.

And, and so like those, it is those experiences I feel that like have most

sort of accelerated my own personal growth and personal learnings because it's

in the, in the crucible of things being hard.

And so I think when people are going through those times, it's nice to take

like, you know, a step back and talk with friends or whatever about like what's

really, what's really going on and setting it in the context of, hey, you

know, three, four, five years from now, when we look back on this, you realize,

wow, you know, we, A, we did something amazing with that time and B, we, we

learned a lot and we were able to take that with us kind of into the, into,

you know, whatever we were doing next after that.

Before our chat asked you what people ask you for advice most around and you

said that it's, that people often ask you for advice on how to maintain

velocity at scale, which is something every founder and product leaders 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?

I think there's a lot of different answers here.

And I think a lot of them are, are very specific to the nature of the business

that someone's in, right?

Different businesses can maintain velocity in different ways.

I think there's kind of a universal truth that you want, like small teams

with clear missions, right?

You know, if, if there's 300 people trying to work on one thing, like just

sheer, like 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 like sufficiently small, small bits, the small groups

can attack wholeheartedly and minimize like horizontal communication, I think

is, 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 like a, a clear platform.

It reduces like the decision making complexity for everyone who's working

on like the domain part of the problem.

And so like a clear platform with a clear interface, you can, you know,

easy to use in all the ways that both engineers and product people want it to

be easy to use simplifies the, the, the space in which people have to think

about these problems.

Um, and that's not always easy, right?

The platforms are not, you know, you can't just like write a platform and

hope it's going to work for the products.

It's a 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, um, I think is really

important.

The third thing just from a leadership point of view is like diving deep, right?

Like it's, it's very, very tempting to, to kind of float up here as a leader

and say, Hey, you know, you take that hill over there.

You guys do this over here.

When in fact, like where you really learn where the challenges are or the

problems or the successes is by like just like being there with, with the

people in the trenches on like one of the things, like 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, by going through that detailed exercise.

And I think the, the last thing is just making sure that teams have like the

right distribution of like experience and, and seniority.

Like sometimes you get a team started and the team is like perhaps doing

something that's like zero to one and they're amazing at all this zero to one

stuff.

And then like two or three years later, like those same people are trying

to like scale the product to like, you know, 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 just do constantly like look at the team and make sure that

A, people are doing things that they love.

And if they're not like, Hey, try this other thing instead, right?

And B, like recalibrate the team and make sure like the right kind of skill

sets are there.

I found if you kind of do all of those things and then have product leadership

where we're saying, this is what we need to do, right?

And a very, very clear and precise on, 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.

Okay.

Let me dig into a couple of these.

These are really, please.

So with the small teams with clear missions, is there an example of that at

Rippling or Coinbase where that was like a really good example of this being true?

One example is maybe three years ago when I, when I was just starting at the

company, um, we decided that we needed to build a time in attendance product.

Um, lots of market demand for us in 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, right?

And Satchith brought a few people on with him and those four people over the

course of maybe nine months or so built a time in 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, right?

They didn't have to worry about what was going on with the kind of the benefits

team or kind of our IT products.

They were, they were monomaniacally focused on this one thing and then identifying

the places where yes, there's connectivity to the rest of the suite.

And that allowed them to move extremely quickly.

How much of that was Parker being on the team, helping them unblock

everything versus being very small and focused?

I think it was mostly small focus.

Like obviously Parker can like do things and unblock them in the way that

only a CEO can and that, and that helps.

The thing is that Rippling, like we've now replicated that like, you know,

a dozen times, right?

That's our model first for starting new things.

And so it can't just be him unblocking things.

So he does unblock things.

It's more that like this pattern of having these small groups, like be able

to do things and then being able to go to those people, right?

Whether you're Parker or somebody else in the company and be able to say,

Hey, how are things going?

Or, you know, are we working on the right things?

Or let's see the latest designs for that thing and comment on it.

Like all of those things can happen just at a much greater tempo than if

you're like trying to go three layers down into the org and, and do things.

I think that's the other, maybe the key point here that like everyone is exposed

to senior leadership.

Like, yes, we have like a management structure because you have to, but

that management structure does not interfere with the ability of kind of

anyone anywhere in the organization to kind of like look at what's actually

happening.

And that happens very directly.

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 teachers are going to talk about this.

And you're saying that you have kind of an approach to adding a new business

unit, essentially, or new product here.

What is, what does that model roughly?

Yeah.

So the model is quite simple.

In the vast majority of cases, we realize we need to build something and we

have, you know, 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 like time and attendance is an example.

Like 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

like make decisions with low information, understands how to work very, very

quickly with like 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 like 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, right?

A team of usually two, three, four other engineers who kind of have that same

zero to one mentality, and they start building.

And usually over the course of like six to nine months, we can get a product

from, you know, a blank sheet of paper to something that is launched, or at

least that we're using sort of internally when we dog food our stuff really heavily.

And then it grows from there.

And then sometimes when you launch one of these projects, get close to launch,

realize, hey, actually a team of five or six people can like kind of handle

this product at nauseam.

Sometimes you have to bump it up.

It's like, okay, this thing's about to production.

There's all these other things to do.

The team needs now needs to go from four to 15 or something like that.

It really depends on the product, but that, that's the general life cycle.

And then you, you keep growing and scaling it.

And that is fascinating.

So just to understand, you find a founder type to kind of take the lead on a

new idea and you recruit them internally, or you sometimes find them externally

just to focus on this product.

Interesting.

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 are you trying to encourage a few?

Usually it's one, like, so there's a designer, right?

So we have, you know, a design, oh, design partner, meaning a designer, not a

company that is like their partner in design.

Oh, no, no, no, no, like literally somebody who, who, who, you know, knows

Riplings products knows, like our component library knows all of that stuff

and is, is, is skilled and like doing, you know, UX and, you know, interaction

and visual design.

Got it.

Okay.

Designer.

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.

Yep, that's right.

And like, you know, every, you know, it's a pretty ad hoc, but every couple of

weeks or something like that, they're meeting with like me or with Parker,

you know, whichever one of us is like the DRI on it and like giving feedback on

the designs, kind of having a critical life or like, oh man, if I were using

this as a admin, you know, 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, like kind of throughout, throughout that

cycle and trying to get the balance of like, you know, speed and comprehensiveness,

right?

This reminds me, you're also, I hear, not a big fan of MVPs that you like

building products to further, to a further point.

Is that, is that true?

And then if so, how do you, how do you think about the initial version of a

product?

First of all, I don't want to knock on MVPs.

I think MVPs like have their place, they're extremely useful, particularly if

you're, you know, literally at a zero to one company that's never done anything

before and you don't have like clear market validation.

I think in our case specifically for, for Rippling, a minimum Bible product

would do a disservice like to both our customers and to like the very team

that was building it.

And the reason I believe that is that when, 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 like 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 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?

You know, healthcare, hospital administration case where like, you

know, it's mission critical in life, then you're going to make a different set

of 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 hundreds 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, and therefore, you know, we believe very deeply, it's like, sure,

understand those simple cases, right?

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 like ridiculously hard use case.

What's the model that would support that, right?

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, right?

Even if we make like the product decision to say, like, 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, 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, um, so that's our approach.

Is there an example that it comes to mind of product you build at Rippling or

Coinbase of just like, it could have been this really simple MVP and then it

ended up being like, no, we did the right thing by building it further along the spectrum.

Yeah.

So I think a great example of this at Rippling, uh, is our global payroll product.

Right.

We could have said, Hey, look, um, we just need to support this one country.

Right.

We need to support, uh, whatever the UK, let's say.

So we're going to copy all of our US stuff.

I just replicate it and like change all the things to be UK.

Like that would have been the fastest thing to do to dramatically over simplify.

Right.

But that's not what we did.

What we did is we said, look, we need to launch with six countries.

And these are six super different countries that we, that we want to like look at.

And they're going to have different requirements from like 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 like 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 have been if you had to

like 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 like, you know, 80% of the system is

baked into our global payroll platform.

And then like the 20% is like country specific.

And most of that specificity can be had a lot by engineers, right?

Who are very, very expensive to change things that are like 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, by, by the system, which allows

us to move much faster, sort of going forward.

I've heard you describe this kind of idea as you encourage teams to design

for the most complex use case first.

Is that kind of the instruction you give these teams?

100% many times.

And so it's one of these things that like until you're here, it's a really

difficult thing to kind of grok.

Because a, so counterculture to what like the background that most people have

come from, it's like, no, no, no, don't think about all those things.

Just like zoom in on this, 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 like absorbing

the culture or to like really, really learn, 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 like 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, the balance of those two things.

Right.

So when I think about rippling, I think of you got kind of the culture is to

do things the hard way and the, 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, you know,

build new products.

The idea of a compound startup for us is that we're basically a lot of

businesses that all work together.

Right.

Like if you think about, 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, like a fragment of benefits is the entire life cycle, the whole company.

You know, our IT products, device management, identity management,

time and attendance, each of these things are industries into themselves with

like multi-billion dollar companies serving each of them.

The insight Parker had, you know, before he founded the company was like,

actually the result you get that when you have that is that there's all this

data that gets replicated and copied.

It is 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, you know, things like workflow and

reporting and analytics and permissioning and all these kind of underlying capabilities.

So the idea of a compound startup is like all of these different businesses

benefit from being built on top of one platform.

The activation energy for that is extremely high, right?

So before my time at the company, you know, Parker, Prasanna, the technical

founder and others, you know, built all of the first versions of all of these

products and it was a minor miracle that they were able to do that.

But having done it, right, we then had that platform and we could continue to

build like new verticals and new startups, right?

On top of that, on top of that foundation.

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 that the

main differentiators we're going to do at all.

And everything's going to be so much better because it's all in one platform.

Is that, is that kind of where the original idea came from?

Or is there a different way to think about that?

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 like 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, right?

You can't, 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 like 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 in a spreadsheet.

You know, have another email address or another name, maybe an employee ID of

like 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, right?

We are the system of record.

And so all of our products, they're like, Hey, who's that person's manager in

the system immediately knows, right?

And that's a very, very simple example of something that, that you can only do

if you start with like solving, to come back to an earlier point, like solve

the most complex use case first, right?

Solve the fact that this data all needs to be in the same place.

And so our ability to kind of differentiate, right, boils down to kind of

that one fundamental decision, which just allows us to do things that are

impossible, literally impossible for any other company to do.

What would you say is one of the most unique things about Rippling's culture

that maybe you haven't mentioned yet?

I would say it's fundamental, a speed of execution, right?

I think in speed of decision making, it's the thing that is probably the hardest

to explain to people before they're here.

Like it's hard to understand until you experience it, like let's not schedule

a meeting for next week or tomorrow or later today.

You know, 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 like slap 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, they're irreversible decisions.

You can't make that way, right?

But for the most part, we really value like the tempo of decision

making and the speed, the speed of response.

And no company I've been at in any scale, five people, you know,

five thousand people has ever operated at the tempo of this one does.

And I think that our ability to continue to operate at that tempo, which

partly due to the fact that we are a compound startup and have these

small independently operating teams and all the rest of that is a really

differentiating thing about the culture of the company.

I'm reading Kevin Kelly's new book or I don't know if you've seen his new

book, it's all these like little tidbits of advice.

And one of his pieces of advice is that usually the best time to do something

is right now.

And it 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 is

effective to create this culture of moving fast, making decisions really quickly?

Obviously a huge piece of this is like Parker himself, right?

It's an attribute of his personality likes making decisions quickly.

And it's also a deliberate strategic decision on his part to like have a

company that makes decisions quickly.

And so he models this constantly, right?

In Slack and conversations in person and in every way possible.

And there's an expectation kind of throughout the company.

If you kind of look at our leadership principles, like 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 sort of like bake it in.

Right?

Like in the way that we, you know, even do like say quarterly planning and the

fact that like there's this timeline for decision making that doesn't leave like,

you know, a lot of room in the way that we expect people to know their domains,

especially in product, right?

And product, you're, you don't own like little feature.

You own like your product and you're expected to be the world's foremost

expert in it.

And if you are, what that means is like, 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, you know, give me 30 minutes, look something up.

And like, 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.

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.

That's right.

And so, and so, and it's, 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, you don't get to like retroactively, like, like make everybody

react to the fact that you didn't operate quickly enough, right?

And it's, and it's not a, it's not a hostile thing, right?

It's just a, people just have to get used to it.

So it's a, it's a deep cultural principle.

And the fact that everyone stands behind it, uh, just means it's like,

gets reinforced on that sort of its own, out of its own gravity.

Do you have values, like internal values that you've kind of outlined

that are a part of this?

Or is that not something that you find super valuable?

No, we actually, I find them quite valuable.

And actually our CEO, Matt McInnis, who, you know, joined the company

about a year before I did, you know, he has been the one to like really drive

this and you know, you go to, I can't remember the specific URL, but on

rippling, there's a search for rippling leadership principles.

You know, there they are.

Um, and they are really true to the culture of the company.

The way we came up with them was to us, you know, a couple years ago, to

introspect into what the, 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, right?

Like why people not worked out?

Why do some people like not enjoy it here?

And like those are the things that are differentiating.

And those are the things that we wrote down.

Are you hiring or on the flip side, are you looking for a new opportunity?

Well, either way, check out lennysjobs.com slash talent.

If you're a hiring manager, you can sign up and get access to hundreds

of hand-created 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 100 other companies who are actively hiring through this collective.

And if you're looking around for a new 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 slash 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?

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.

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, 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.

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.

I think in the absence of those clear expectations, it's difficult for people

to perform at their best.

And so we try to do that pretty frequently.

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.

Yeah.

I guess first of all, do you have a sense of where that came from and why that

ended up being so important to you all?

And then two is just, is there an example of you doing that or someone you've

seen do that and that leading to something really important?

In the early days of our kind of global efforts, right?

When we are first trying to figure out like what global payroll was, it was

really tempting to say like, oh, well, we're going to go into the UK and that's

going to be like relatively similar to what we're doing in the US.

But our kind of head of payroll went in and said like, actually, here are the

ways in which like, 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, right, for how we

think about learning about each of these countries and going into them and having

like 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 like

satisfy the needs of every country in which we're going to run payroll, right?

And it was only through that like very early on, like deep look at how one

country was actually operating and then doing the same thing with the next

country that like we were able to set in motion all of those things, right?

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 than over time.

And so the leader of that team basically just went and studied the tax laws of each

country.

That's right, like went all the way to ground.

It's like, okay, like let's go and open up the big old like, I mean, it's like

online these days of the old tax book and look like it's like, or when you're in

the United States, like you have to go look at Ohio or Pennsylvania, which have

all these like little like local like city or county based taxes.

And it's incredibly instructive to look at just a few of those and think like,

wow, how do I think about like configuring these change like unannounced, right?

Like some city administrator, you know, or the city legislature, whatever they

call them, right?

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 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, you know,

in different ways, right?

It might be a technical thing.

It might be a design thing.

It might be a compliance or regulatory or governmental thing.

But whatever it is, that detail always exists.

And unless you're getting down there and seeing and understanding it first hand,

you don't really understand what your product needs to do.

And I think an important element of this that's between the lines maybe is don't

delegate this to someone like 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. 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, right?

Which we do have, by the way, now, right?

Like that's that's an incredibly important part of our success is having

that specialist, but not before somebody with a product mindset.

Like the tax specialist is amazing at tax, right?

That's what they're that's what they love and that's what they do.

But that doesn't make them necessarily a great product thinker, right?

So the personal, the product thing has to has to get into those same weeds first

to really understand it.

Do you give any guidance and just like how much time to spend on all that stuff

versus like, you know, the regular day to day of, say, a product leader on a team,

you know, there's it takes a lot of time to become a world expert on the tax

systems of many countries.

Or is it just like there's nothing more important than that?

That is like your job.

And what are you doing? Not doing that.

How do you think about?

I think it's an equilibrium, you know, if a job is 80 hours a week,

it's like 40 of your hours.

Like it's it's I think I think that 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 like the the other half of the job of, you know,

communicating with, you know, the engineering team and like writing

documents or whatever.

But like, what's the point of writing a document if you don't know what

you're talking about, right?

And so 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, right?

We expect like a single leader, right, to be able to know like the full

scope of the product.

In fact, great product leaders can in fact do that because they like have

this native curiosity and interest and like ability to absorb a lot of stuff.

And it makes it's a lot of fun because now like I have a group of people

around me who like are all like really good at what they do and really

understand what they do.

And that that's kind of just an amazing, amazing place to be.

I'm looking at this list and I just want to keep asking questions about it.

One of the principles that I love is it reminds me of Amazon has the same

principle, I believe, which is leaders are right a lot.

Yeah.

Why do you find that to be important?

I know you weren't necessarily designing all these principles,

but I imagine that something that you guys follow often and comes up a lot.

I mean, this is one of my favorite ones because I think for

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, right?

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 like an ambiguous information with ambiguous situation with incomplete

information and like a complex decision space and can like look at that

and listen to everybody and read whatever they need to read and say,

this is where we need to go.

And like even if everyone else is like, I don't know,

that feels wrong for this reason, this reason.

If they have like the confidence to like 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 like it's really hard to test for, right?

You can get it by like talking with people and asking, hey,

is this person like usually right and respect people think about it?

But like in the context of like 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, right?

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.

Awesome.

Shifting a little bit.

I know you all are going through this global expansion.

We talked about this a little bit.

And so just a few questions along the lines because a lot of companies

start, you know, one country, most companies too.

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?

So it starts with an assumption that we're going to have to be everywhere,

ultimately, right?

That you don't actually have to build like native global payroll in every country

in the world doesn't make sense to 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, 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, right?

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 like 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, right?

Like 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 like, where is their risk, right?

Where is this, where is this hard?

Where is there a long pull?

Where does this like, in what countries does it take like a long time to get

approval or whatever?

And we just stack ranked them.

And then we revisited that decision, right?

Like the early decisions that we made on exactly which countries, like we have

subsequently like reordered those over time.

And as we've dove dived into countries and learned more, you know, we rejigger

things like a little bit.

But for the most part, like that same basic list we started with is still like,

you know, mostly right.

Okay.

And then the other question a lot of founders always struggle with is when is

the time to start expanding internationally?

Cause you know, there's pros and cons.

Do you have a sense of what convinced you all to start going international?

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 like 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 you in color, right?

Just as we care if there's not a you in color, right?

Like all of these subtle lessons that like cultural lessons for companies that take

like a really, really long time to absorb.

And so my view is you always should do it earlier than you think you should.

That then 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 and 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, right?

It stopped being the province of like 100 person companies plus and like started

filtering down into very, very small companies just became commonplace

for small companies to be multi country.

And so that very much accelerated kind of our time table.

And then you saw it, you know, 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 like that also kind of adds a little bit of a, you know, fire under the under the thing.

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.

I think the thing that was most surprising to me the first time I did this back at

Gadwire in the, in the aughts and remains the most surprising thing to most people,

you know, every time I do this again is that every country is unique.

You can't just like, you can't just take your U.S.

based approach and like 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 like little things like they're being at you in color or not.

Or, you know, if you ever see a demo delivered to somebody in another country where they see

like a detail screen about a person that 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.

I think that 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, right?

If you took like German system or something and like demoed it in the United States with

like poorly translated stuff, we would think it would suck too, right?

And so, but it's not, it's really hard to adapt to that mindset.

And, and so it takes just a lot of energy to kind of overcome that organizationally.

Makes tons of sense.

I'm going to go in a different direction now.

Sure.

Frameworks.

So I know that you're not a huge fan of frameworks.

We were talking, 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 like how you crystallize processes and concepts for your team.

If you're not just like, here's a framework you should use.

Look, I think frameworks are very helpful, although 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, right?

So the right decisions can happen and like no more.

And I think there's a danger, especially as companies scale that you end up saying, well,

you know, if only we categorize, you know, everything correctly and JIRA, like, you know,

we will be able to make like really good prioritization decisions.

I'm like, sure, extremely helpful to have clear categorization and things in JIRAs

and have like data and analysis and to be able to do all of that stuff.

What you really need to do is decide what's important to build, right?

And then like have a way to build it like really efficiently.

And so, so I think the right answer, the right amount of process for any given team

is like right framework for any team is really just dependent on like their specific life cycle.

So you won't see me saying like, oh, we need to use like this scrum thing

or that combine thing or whatever like 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, like everything does need in fact to be in JIRA

because otherwise you can't rationalize about what's actually getting done and not.

Is there a process or framework that you find is like counterproductive

that you're just like, 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.

No, I don't find one to be particular.

I haven't consistently found one to be particularly problematic.

So I think any framework sort of has its place, right place, right time.

I think there's danger any one time somebody 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 like on the basis of process X

and like everyone's bought into that process and everyone understands it.

I mean, they can be really, really great.

And like and on the engineering side, I think this is hugely valuable.

Test driven development, first line of code is 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.

If you had to compare the way Coinbase builds product process wise

or just product development process wise to Ripling,

what would you say are the bigger differences?

I think the differences are largely born of like the different domains, right?

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 like having those debates

and like getting to a decision and disagreeing and committing.

And then from an execution point of view, being able to move fast,

like 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 like

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 continuously better

than everything that's out there?

And that like yields a different decision-making process.

So for me, it's like the mental model is actually of how I approach those things

with the same, but they just like yield different results in the actual making of the software.

What is that actual difference you find like day to day?

Is it like timeline differences?

Is it how quickly, I don't know, the way you structure, how far out you plan?

What do you find is like the concrete difference as a result?

I think the difference is in the day to day velocity of like decision-making,

because we can, you know, rippling, if you're like on, I don't know,

pick a random team, if you're on the device management team,

like, you know what you got to do, right?

There's no ambiguity.

You're not debating about, you know, whether, you know,

Mac or Windows is going to exist in the future.

Like none of there's none of that cognitive dissonance, right?

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 hard.

Coinbase was like an amazingly fast like environment,

but it was also subject to the fact that like,

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 like the environment

and the crypto environment, what's going on and the uncertainty

of the regulatory environment, all that stuff.

We are really, really, really good at handling those things really rapidly,

which is something that we need to handle somewhat less heroically.

Sounds quite stressful.

Yeah, I mean, it was fun.

Like, 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, right?

And so, but yeah, it's stressful.

And looking back, what a joy.

Yeah, they are very good memories.

Like I look back, I don't really, I remember the stress,

but I don't like re-experience it, right?

I remember like forging these relationships

and building these amazing products that I've been so lucky to be a part of.

And so I have, you know, almost only good memories of other places I've been.

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 like it feels like, you know, 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.

Yeah, that's fair.

Though, I mean, the first company I was really at kind of out of school

was a company called Reactivity back in internet one era.

And like we were trying to figure out like,

how does this internet thing work?

How do we start companies on the basis of these tech new technologies?

How do we help other companies like build stuff and figure it out?

You know, and that company like fundamentally liked and worked out.

Ultimately got kind of spun itself out and got acquired, which is great.

But like it was this extraordinary set of people that I was so lucky to work with.

And I, you know, I loved all the time I spent there.

And it was foundational to like everything else I ever did.

And so even though that effort didn't like, you know, pay off in the traditional set,

like 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.

That's a really good point, actually.

And I think I should correct even what I said,

that even when things don't like work out traditionally,

those experiences end up being incredibly valuable in all these unexpected ways.

Yeah, 100%.

Yeah.

Okay. So final topic.

I want to talk about hiring, hiring product managers and interviewing.

Yeah.

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, you know?

I don't know that I have any like particularly special insight here.

I think there's a couple of 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

as 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.

It's just like 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.

Like here in assumption, they blink a couple of times.

They're like, oh, well, that has like these 400 implications, right?

And they just start rattling them off.

And some people get like really flummoxed, right?

I mean, obviously for our environment,

that former is like really, really important to us.

I think the other thing that really matters to me

is like the insightfulness of questions that people ask,

which is indicative of number one,

they're like actual interest in the job, right?

Like people tend to ask better questions

when they're like more excited about working at a place

and like done their research and are asking people about it.

And also like the quality of those questions

like can vary quite dramatically.

And that's okay.

I don't expect the quality to be the same all the time,

but like sometimes people ask a question like,

oh man, I would have 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.

Is there an example of someone asking a really good question

like that that comes to mind that you think back to

and like, oh, wow, that was great.

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 of these products and you have this

like employee system of record thing underneath it,

shouldn't we be thinking about like how to create these

like various pillars of kind of underlying platform technology

things like permissioning all the system.

This was before we like fully formalized the concept of our

like platform beyond the kind of employee system of record.

And I remember thinking like, yes, yes, we should.

And you know, that had entered our minds before,

but the fact that somebody who had like 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 like a couple of weeks while you're like interviewing

with a bunch of other companies or whatever.

And like you've thought about it deeply enough to have this

insight into the nature of the platform that we're building.

Like immediately like gave me a bunch of confidence

and his ability to kind of think through the sorts of things

we need him to think through.

And I think it touches on PMs need to be business leaders.

And yeah, great questions are often about the business

and the future of the business and how to make it run more efficiently.

And listen, you know, there's like a product org element to it.

But I find that that's like a really under

appreciate element of PM.

Everybody's just like thinking about the bigger business,

not just like the PM product.

Yeah, for me, it's like two things.

It's like thinking about the bigger business, right?

And having having the context like around, you know,

whether it's like revenue questions or strategy questions,

but also like the detailed questions, right?

It's like, oh, wait a minute, the implication of this thing

that I'm getting asked or of this thing, Jeremy,

that you said earlier is all of these things, right?

And their ability to kind of understand that,

that this isn't a simple business.

Like it's really hard.

It's really complex and the ability to kind of

to have these insights help them think

through those details is really cool.

You talked about this prompt that 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 like a good example of a type of prompt

to give a product manager candidate?

In terms of like a general kind of approach,

I think a prompt should always like reflect

the actual business that they're going to kind of come into, right?

So when we do like, so our process overall

is actually quite short.

It's basically, you know, getting contact with us somehow,

eventually, you know, 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, you know,

modulism, other conversations around the edges.

And the questions that matter are around like,

how do people think through that product discussion, right?

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, which is maybe sounds very simple,

but it's just like, hey, what questions do you have for me?

All right, we actually do that before we do the product discussion.

And that's an incredibly important question,

because it is, again, indicative of like these things

that people have thought through or not thought through,

or kind of the depth that they're thinking,

or their interest and engagement in the role.

And like at that second discussion,

it doesn't have to be like perfect or anything.

But it is a very strong signal when people, you know,

whether they've thought through a set of questions they want to ask,

or just like, you know, on the fly, like generating them,

you learn a lot about how people think about product,

about, you know, what they're looking for,

about, you know, what they like doing and not doing,

just through those questions.

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?

Be humble.

Being a product person means that like by definition,

you're living in a world where like,

no one knows the right answer yet,

because if somebody did, they would have already built it.

Right.

And so having like, no matter how smart you are,

there's a lot of smart people out there.

Right.

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, right,

that you can actually have the humility to say like,

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 like

the biggest differentiators in early career product leaders

who sort of are able to let go of like,

how awesome they were in school

or in their first job or whatever.

I mean, I had to do this, right.

And like, and realize like the job is always hard.

And the job is always about discovery every single day.

And if you can maintain that like curiosity

and elasticity of thought and creativity

and like coming solutions can be awesome.

But if you close yourself off to that

and think you always have the right answer,

then there's like no hope.

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.

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, you've got to be right a lot,

but everyone's wrong sometimes, right.

And being able to be in an environment

where you can just like say, yep, I was wrong.

Here's the way in which I was wrong.

Let's move on is incredibly powerful.

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 production be?

Yeah, that's a great question.

So I think you've got to be adaptable, right.

Like it's like any other relationship, right.

You have to understand like 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.

Like I think fundamentally,

you need to make sure that person

is willing to be challenged, right.

So, you know, I've seen product leaders or CEOs

who are like 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 like whatever,

and it's not even a CEO,

but at whatever a manager's idiosyncrasies are,

you have to find a way to like work with those.

And I think that adaptability,

like I'm just sort of, I like being like,

you know, a moldable puzzle piece

where I can just kind of fit in.

I think that's actually one of my core skills.

So, and so that's worked out for me.

And, you know, Parker and I, before I started,

you know, started developing like a deep foundation of respect,

which is like extremely important to like building that.

And like over the years, it's just gotten deeper and deeper.

And, you know, we don't always agree,

but like when we don't,

we can have a totally reasonable discussion about it.

And, you know, that's what makes it fun.

Adaptability actually is,

I took a strength finder test once of finding my own strengths.

And that was my number one strength,

because I'm a definitely, I think we share that.

That's excellent.

Yeah.

Seems like an important attribute for being in a place you're in.

Well, with that, we've reached our very exciting lightening round.

I've got exceptions for you if you're in.

All right.

I'm ready.

Hit me.

Here we go.

What are two or three books that you've recommended most to other people?

Well, first is like my favorite series of books ever,

which is the Baroque Cycle by Neil Stevenson.

It's a nine volume epic or three,

three volume nine book epic,

depending on how you want to look at it.

But like it's about the time like just before

and like into the enlightenment, historical fiction, a lot of fun.

And I also love the culture series by Ian Banks,

which is just like super fun, far future sort of universe that I really enjoyed.

What's a favorite recent movie or TV show?

Watch The Last of Us, you know, was an avid fan of the game.

And I thought they did a really, really nice adaptation.

Favorite, like I guess recent movies, not that recent,

but I really like Tenet, you know, which I thought was a,

I was impressed with their ability to kind of go there and make that movie.

And I just really enjoyed it, like end to end.

We had a, 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.

Okay, fair enough.

I'll try.

I've only got water.

Normally I got tea, but water, good.

That works.

But it's interesting and hasn't come up often.

So I think maybe we end that for now and see what the new pattern emerges.

Yeah.

And then Tenet feels like, I was just thinking,

it feels like a compound movie, compound startup as a movie.

That movie is very complicated to stay up.

That's why I enjoyed it.

I liked, I liked trying to like figure out like the multi timeline chart

in my head as the movie progressed.

Puzzle piece within you, trying to find all the puzzle pieces.

Yeah, for sure.

What is a favorite interview question like to ask?

You already maybe answer this, but anything else come to mind?

I think I did.

No, my favorite one is like, what questions do you have for me?

Great.

What are some favorite products you've recently discovered that you love?

I guess I'll just mention, I don't know if I go so far as to 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 like super easy to use and really adaptable to lots of

other boards.

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 last week, late last week.

It had to do some really quick research into my new favorite pair of headphones.

And these focal bathies are super nice.

I'm a bit of an audiophile.

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.

Okay, so what are they called?

Focal, I think it's Bathis B-A-T-H-Y-S.

Okay.

And is there a specific model or there's that one?

That's it.

Okay.

You'll know it when you see it.

Okay, we will link to that in show notes and 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?

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 is the things that are not on it.

And in a world where we could choose to do hundreds of things at once,

like being able to kind of force rank that list of things, draw lines,

these are the ones everyone has to do has created a lot more focus and clarity than we had before.

So imperatives are essentially like here's the priorities for the next say quarter,

six months here.

Here are the priorities for everybody.

And now integrate that into your own team's priorities, right?

So each team like still is building like their own priorities, but like have to factor in

like this set.

How many of those do you usually have?

This is awesome.

I like this tip.

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 like between like globalization and like large improvements to the platform

and like a bunch of other, you know, large companies, all these things.

They create 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 awesome.

Final question.

What's the question I should have asked you that I didn't ask you?

I guess what do I do with my kids?

Maybe I have two kids.

They're nine and 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, you know, morning,

tonight.

And so we play a lot of like European like strategy games together.

And my daughter is now getting old enough that she's getting into them too.

And so we just finished as a family playing a pandemic legacy.

And the reward tomorrow night is we get to start playing Gloomhaven.

So that's going to be fun.

I don't know.

Either game sounds very hard and complicated.

They're fun.

They're fun.

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?

Awesome.

LinkedIn is the easiest way online.

And, you know, 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.

What's the best way to explore those roles and apply?

The website has by far the best channel.

It gets to this right recruiter who will tell me about it right away.

Great.

So airplane.com and it's probably a site for careers.

There is a career site on there that you pretty easy to find.

We'll link to that in the show notes.

Jeremy, thank you again for being here.

Thanks so much for having me.

This was a lot of fun.

Bye, everyone.

Thank you so much for listening.

If you found this valuable,

you can subscribe to the show on Apple Podcasts, Spotify,

or your favorite podcast app.

Also, please consider giving us a rating or leaving a 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.

Bye.

Machine-generated transcript that may contain inaccuracies.