Lenny's Podcast: Product | Growth | Career: What sets great teams apart | Lane Shackleton (CPO of Coda)

00:00:00 - 00:30:00

Lane Shackleton, Chief Product Officer at Coda, shares insights on building successful product teams and cultivating a growth mindset. He emphasizes the importance of seeking out challenging moments and discomfort as opportunities for personal and professional growth. Shackleton also discusses his career journey and draws inspiration from the principles of great product leaders. The guest discusses their experience as a mountain guide in Alaska and how it influenced their approach to product management. They highlight the importance of preparation, checklists, and staying calm in challenging situations.

Show more

00:30:00 - 01:00:00

The podcast explores the importance of seeking out uncomfortable and challenging moments for personal growth in one's career. It also discusses the value of learning from experts and the significance of rituals in great product teams. The episode emphasizes the benefits of clear communication, experienced leadership, and effective feedback systems. It also mentions the use of specific tools and systems, such as Catalyst and the 'driver, maker, brain trust, and interested' meeting structure, to improve efficiency and decision-making processes.

Show more

01:00:00 - 01:29:51

The podcast episode features a conversation with Lane Shackleton, the CPO of Coda, who shares insights on what sets great teams apart. Shackleton emphasizes the importance of taking action and making things happen rather than just talking about ideas. They also discuss the value of being customer-facing and understanding customer needs, as well as the shift towards two-way write-ups in product management. The episode concludes with information on how to reach out to Shackleton.

Show more

moments that stretch you or moments that you feel uncomfortable in or you find yourself saying,

like, oh, shit, you know, I shouldn't be here. I'm under qualified to be here. Those are the

moments you should be seeking out, right? Like those are the moments that stretch you and give

you sort of like a new foundation. So oftentimes, you know, you'll hear like a career question,

like, hey, do you feel like you're growing in your role? And that's like a very ambiguous,

in my opinion, way to ask this question. A much sharper way is like, hey, how many like,

oh, shit moments have you had in the last like six months, year or two years? And what are they?

I think if you ask yourself that question and the answer is it's been a really long time since

I've been like stretched in some meaningful way, or I've felt like I'm under qualified to be there,

then it may be worth kind of like digging into.

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 Lane Shackleton. Lane is Chief Product Officer at Coda, where he's held the role

for over eight years. Before that, he was Group Product Manager at YouTube, a product specialist

at Google. And as you'll hear, he started his career as an Alaskan Mountain Guide, and then as

a manual reviewer of Google AdWords ads. Lane is an incredibly deep thinker, very first principles

oriented, and has built an incredible product team and culture at Coda. In part, he's done that by

studying the principles and rituals of great product leaders and great product teams. In

your conversation, Lane shares what he's learned, what he's found, great PMs and great teams do

differently. He shares a bunch of his favorite rituals and principles, how you can implement them

on your own team, plus a really clever and unique way of understanding if you're making progress in

your career. Plus so much more, I could talk to Lane for hours, but we tried to keep this to under

an hour and a half. With that, I bring you Lane Shackleton after a short word from our sponsors.

This episode is brought to you by Epo. Epo is a next generation AB testing platform built by

Airbnb alums from modern growth teams. Companies like DraftKings, Zapier, ClickUp, Twitch and Cameo

rely on Epo to power their experiments. Wherever you work, running experiments is increasingly

essential. But there are no commercial tools that integrate with a modern growth team stack. This

leads to waste of time building internal tools or trying to run your own experiments through a

clunky marketing tool. When I was at Airbnb, one of the things that I loved most about working there

was our experimentation platform, where I was able to slice and dice data by device types, country,

user stage. Epo does all that and more delivering results quickly, avoiding annoying prolonged

analytic cycles and helping you easily get to the root cause of any issue you discover. Epo lets

you go beyond basic click-through metrics and instead use your north star metrics like activation,

retention, subscription and payments. Epo supports tests on the front end, on the back end, email

marketing, even machine learning clients. Check out Epo at geteppo.com that's getepo.com and 10x

your experiment velocity. This episode is brought to you by Vanta, helping you streamline your

security compliance to accelerate your growth. Thousands of fast-growing companies like Gusto,

Com, Quora and Modern Treasury trust Vanta to help build, scale, manage and demonstrate their

security compliance programs and get ready for audits in weeks, not months. By offering the most

in-demand security and privacy frameworks such as SOC2, ISO 27001, GDPR, HIPAA and many more,

Vanta helps companies obtain the reports they need to accelerate growth, build efficient compliance

processes, mitigate risks to their businesses and build trust with external stakeholders.

Over 5,000 fast-growing companies use Vanta to automate up to 90% of the work involved with SOC2

and these other frameworks. For a limited time, Lennie's podcast listeners get $1,000 off Vanta.

Go to Vanta.com slash Lennie. That's V-A-N-T-A dot com slash Lennie to learn more and to

clean your discounts. Get started today.

Lane, thank you so much for being here. Welcome to the podcast.

So glad to be here. Thanks for having me.

It's absolutely my pleasure. I've always really admired the way that you write about product,

the way you think about product and it feels like CODA has one of the strongest and also the most

thoughtful product teams out there and so I am really excited to have you on here and learn from

what you've learned over the years. My first question is completely unrelated. I have to ask

your last name, Shackleton, any relation to a certain very famous Antarctic explorer?

Yeah, it's probably distant at best. I wish it was close. I wish I could claim it as my father,

grandfather, but I definitely grew up with those stories and reading a lot about them as a kid

in high school. We read Endurance, which is a great book. I haven't read it. It's an amazing

story, basically very inspiring how he put people first and brought back all of his men

from this journey to the South Pole. So I've taken a lot of lessons from that, but that's as close as

I can come to the greatness of Ernest Shackleton. Okay, so there's a connection. When I think of

Shackleton, I also think of the ad that he ran for people recruiting people to join his journey,

like low chance of survival, incredibly hard, some chance for glory if you succeed something like

that. It's a wonderful ad. I think I had a mug of that when I was a kid. Amazing. Okay, so on

that same topic, I noticed maybe your first job was a mountain guide in Alaska. Was that inspired

by this legacy and also how did why did you decide not to pursue that and get into product

management? Completely different life. Yeah, very, very different. Very different time. Didn't

have kids back then. I think I was convinced at the time I wanted a career outside. Just like

love spending time in the mountains and climbing things like that. To be honest, I wasn't the

best guide. There were a lot of amazing guides out there that just had, they were almost invincible

in terms of their ability to climb for 20, 30 hours. But I learned a lot from the experience

and maybe the quick story and why I stopped guiding. I was on sort of what is like a dream

trip for mountain guides, which is we were flown to a remote portion of Southeast Alaska about an

hour. It's an hour long flight, mountain called Mount Fairweather, beautiful 15,000 foot peak.

And as a part of climbing on glaciers, one of the things that you do for context is you're

roped to another person. And the reason that you do that is because if you fall, if someone falls

in a crevasse, you want to be able to stop them or pull them out. So any of those ropes to a very

nice client that I was guiding. And he fell pretty close to the top on our way down. And luckily,

we were able to self-arrest and arrest that fall. But I spent probably the next six hours

walking down that mountain thinking the same thing over and over again, which is like,

I really don't want to die, rope to someone that I barely know and don't trust or love.

So that was sort of the last season that I guided. But tons of great memories and learnings and I

think it impacted my life in a pretty significant way. Damn, software much lower stakes. I guess

just while we're on this topic, is there any parallels or big lesson on it if you learn from

that experience that you bring to product? One is just preparation. I think when you go climbing

or when you guide climbing, you spend months and months preparing for usually like a few days of

climbing. So there's that kind of preparation. There's also like just a million checklists.

So before you go on an expedition, you may check a checklist of all your equipment,

stuff like that, a dozen times or more. So you kind of like ensure redundancy

across all your systems. That was definitely a parallel. The other thing I think about a lot is

just how to stay calm and like challenging or scary scenarios. We had another instance where

I had a client pull a big chunk of rock off and break their feet. And that was, you know,

I always like the junior guide on that particular instance. And the more senior guide looked at me,

looked at the situation and was like, okay, we're getting this guy out of here right now.

You know, put him on his back and we basically took turns varying out for a couple miles. And

I'll just never forget like instances like that where the clarity of, you know, stay calm,

assess the situation, prioritize, take action. You know, it's like that's sort of like a

there's a mini version of that when you're building software, I think. So experiences like that, I

think we're, you know, even though I only did it for a handful of summers, we're pretty profound.

Yeah, what a very different life that life path would have been.

Pre kids. Yeah. Oh man. So you mentioned your writing, you mentioned that this something you

want to write about shifting to kind of the core topic of our chat is it's very clear that you

spent a lot of time studying how great product managers operate and how great product teams

operate. You've been doing a bunch of writing on the principles of great product management and also

the rituals of great teams. And so I want to spend a bunch of time trying to extract as much as I

can from your learning so that listeners can learn essentially what are principles of great

product managers, what are rituals of great teams and generally how do the best teams operate.

And my first question is just why is this something that you started doing? What kind of

pulled you into spending so much time and effort trying to understand how the best teams and

people operate? Yeah, yeah, I've been asking myself that question a little bit lately.

No, I'm free. There's a few reasons. One reason is I just found myself giving

a similar set of advice and one-on-ones. And so I think anytime you find as a leader yourself

kind of like repeating the same lessons, it's a good, it should be a good flag to say like,

oh, I should probably scale this in some way. And as soon as you write something down,

you have to clarify your own thinking. And so it becomes very useful for that.

And I don't think I quite expected how useful it would be in that sense, like writing something

down and then putting it out there. You start to get feedback back of where you might have been

right or where you might not be right. And so for me, it's been a good learning experience there as

well. I think the second reason is I've always been pretty frustrated with career ladders.

Most companies have career ladders with like 10 or 15 levels. And as soon as they hit some scale,

there's like levels between levels. And I feel like I looked at the one at Google,

and you kind of like needed a PhD to decipher it and interpret like how to operate within it.

And so that's sort of like one piece of the construct. If you think more broadly, though,

they aren't consistent across companies. So now you're in a situation where you're in your

version of the rat race. And so I found that I basically wanted to have a broader set of

principles that transcended level. So things that could be true when you are an ICPM starting

your career and things that can also be true when you're the head of product or running a product

team or things like that. And so that's one, I won't rant further on that, but I think that's

one piece of it. And then I think the last reason I'll mention is I was pretty inspired by a talk

that is by this guy named Brett Victor, who's kind of like a prototyper, thinker,

may have heard of his work. He has this talk called Inventing on Principle. And in the early days of

COTA, one of our first designers, this guy Jeremy Britton, showed this talk to the company

and like my mind was blown. And I think it was one of those examples of someone

developing a clear view of what principles they should operate with and then like following

that principle. And it was just sort of a meta example of how important it is and how impactful

it can be when you decide on a principle and then follow it. And so ever since then,

I've been thinking like, what are my principles? Is it pertains to like building software and

other things? So those are kind of like the three reasons that led me to start writing these things

now. Amazing. We're going to find that talk and link to it in the show notes. I want to ask about

what principles you've come to, but I also want to understand how you actually ended up doing

ladders and performance review stuff at COTA. Would it be better to talk about that later after

we go through some of these things or is there some you want to share first of just how you think

about it, COTA? When we were doing career ladders, first of all, we put it off for quite a bit of

time. And that was based on the advice of a lot of other leaders that said, as soon as you introduce

this, then the incentives sort of like flip from being company focused to being individual focused.

And so I think we delayed it for a good bit of time. There came a time where we kind of decided,

hey, look, we really do need to provide better guidance here about like what it means to grow

and what it means to be great. And so about the same time we were doing the levels thing, I started

writing down some of the principles that I've been publishing. One of the things that I think about

a lot when talking about levels is just how to keep everyone oriented toward their team

and their company. And I think that we've done a really good job of that over the years. So levels

aren't by any means at the forefront of any company discussion. In fact, we kind of don't use titles

that much. You said that it's not specific to role. Do you mean like the same leveling attributes

or the same for design and product and engineering? We basically have five levels. And we call them

role stages. And they go from apprentice to principal. So apprentice is kind of rope analogy

here is learns about rope. Practitioner is can tie basic knots, shown complex knots,

you know, sort of given a problem, they can do it. Career is you can calculate rope strength.

You know, a lot about knots. Principal is basically invented nylon. So the bar is like

really, really high for principal in these levels. And I think that that is, you know, that's

appropriate. Like it should be aspirational that the bar is exceptionally high at the highest level

of our role stages. I find it's a pretty good process to draw contrast, maybe a little bit

of contrast with other companies. I think most other companies, especially large companies have

have 10 to 15 levels. I think we've made a really conscious choice to have only five. I think the

other bit of contrast I would draw is basically, role stages are not visible across the whole

company. Like, you know, we're not showing levels of any individual PM or designer. And that's

partially because we just don't want to put a big focus on it. And then probably the biggest

difference is we have a centralized compensation committee, and that's who decides compensation.

And so it's not the manager that drives your compensation. So those are some differences.

Super cool. I've never seen it done this way before. I think it's an awesome example of first

principal thinking, which I see a lot come out from your product team. And then just to make

sure I heard you right, these five stages are roughly the same across role. So designers

have the same kind of five, and they're described similarly. That's right. They're described

similarly at a high level, but then the specifics, like if you get into it, are a little bit different.

Okay, I'm going to ask about what the principles are, or a few of them that you can share. But

one other very tactical question at what size of product teams, say just PMs, did you start to

develop this framework? We were probably at 20ish PMs and designers when we did that.

Awesome. Okay. So let me just ask, what are some of these principles you've

kind of narrowed it on as principles of great product managers?

Maybe it's helpful to start with a little higher level context on the kind of unifying thesis. I

think the unifying thesis is the core job of a product person in general is to turn ambiguity

into clarity. And if you think about the job of a product leader or product manager, kind of like

everything is ambiguous all the time. It's like, what's my role on this team? What problem are we

solving? Who's the target customer? What prototype is going to solve this particular problem? So it's

like literally everything. And so if you're going to do the job well, you really need to get good

at spotting ambiguity and kind of turning it into clarity. And so the obvious question that

follows from that is like, okay, great, that sounds like a great hallmark card, but how do

you actually do that? And so I think the principles that I've been writing down are very personal.

They're like my take on how to do this. So the first one that I wrote about was systems,

not goals. And one of the ways that I started this post, I'm a big fan of getting inspiration from

outside of tech. And so one of the stories that I tell is basically the story of Jerry Seinfeld.

If you haven't seen the documentary Comedian, it's amazing. It's definitely worth watching.

But the story goes, you know, he's done Seinfeld the show. And he's got all this material from

the last like 15 years. And he comes in one day and he says, look, I'm going to throw away all my

material and I'm going to start fresh. And like this is like unheard of in comedy for someone to

just like throw away all their old material and start fresh. And, you know, so the question is

like, what is he next? And the thing that he does is he sets a goal, which is basically to build up

to an hour of material again. But the goal isn't that important. What's important here is like

the system. The system that he uses is he writes for an hour every morning, you know, doesn't write

for more if he doesn't want to. And then he goes and performs at night, right? And so when you

rinse and repeat that system, do it hundreds of times, that's how he builds up from five minutes

to 15 minutes to 30 minutes of material. And so I think that, you know, I take a lot of inspiration

from that. And I think product people can generally, which is instead of being as obsessed with the

goal, you know, be obsessed with the system that gets you there. And so the phrase I sometimes use

is, you know, goals with good intentions don't work. And I think that a really, maybe to give a

common example, a really common example is teams that are trying to like learn about customers

or do research or, and, you know, one thing I've observed is a team may have a goal like an OKR

of talking to 10 customers this quarter. And they may or may not hit that, you know, that OKR.

And then if you watch closely, you know, the next quarter, they may not have a goal of talking

to customers anymore. And so they're sort of like learning is going up and down. And

to draw contrast, that's just really different than a team that has some default on system for

talking to customers, you know, every few times a week, they're talking to customers for whatever

reason. And the impact of that is like really hard to see until you understand that the ladder team,

you know, tends to have like really good product instincts or really good customer instincts.

It's because they've just had this like sort of default on mindset of talking to customers. And

in the early days of Coda, we actually did something similar. We had a time allotted on

Fridays. And it was basically like, it was on the calendar, a customer or a potential customer

was coming in. And so you knew that it was going to happen. And you had to have something to show.

And so like, sometimes we'd be scrambling, you know, the three hours before to, you know,

have a prototype ready for a customer. Sometimes we would have had something that we've been baking

for a while. But the point is that it was default on, right? And so like, the way that we developed

good customer instincts was not the goal. It was really just the sort of system behind it.

So that's one that I'm kind of passionate about. And I think it's also

translates into a lot of the rituals that we talk a lot about.

There's so many directions I can go with this. I really like this one. It

reminds me of something I did at Airbnb where we had a lunch with a host every Friday with the team.

And we had our community person find someone in San Francisco that's a host. And

there's no genders. Just let's have lunch and meet the team curious what you were enduring.

Exactly. And Airbnb hosts are always so nice. And it's such a pleasant experience.

Always also makes me think about this book, The Score Takes Care of Itself.

Yep. You heard that? Yeah. Where it's just like, do the fundamentals and you'll win.

The other thing that reminds me of is I have this quote hanging in my office here from,

I believe it's from the Rick Rubin book. And the quote is, the object isn't to make art.

It's to be in that wonderful state which makes art inevitable.

I love it. I feel like you just changed art. Oh my God. So good. There's just like every,

every section is like this quotable thing I want to like, I need to hold on to this thing.

Yeah. He's got a great thing on listening. I think I really admire what he says about listening.

And I think that a lot of PMs could take, take that lesson, which is.

Yeah. What is that? The way he talks about it is essentially you want to listen

and absorb sort of every fragment of what that person is saying, including, you know,

their body language and everything else. And try to turn off the side, which is crafting your

response or, you know, figuring out what you're going to say next or what the problem with their

argument is or whatever. You know, it's really, it's quite hard to do, right? Because like your

default mode is always sort of the next step of the conversation. But I think if you can really

challenge yourself, like he says, to pause and really try to internalize sort of holistically

what that person is saying, it's pretty powerful. I was actually just reading that chapter and the

next chapter is about this, the idea of the beginner's mind. And if you remember that,

we're going to, I feel like we get, people get sniped by Rick Rubin stuff. But anyway,

I'm going to go down this thread. He talks about how Alpha zero or Alpha go, the first AI thing

that beat humans and go and how there was this move it made and move 37 in the game that was just

like the person that was playing walked out of the room. He's like, I can't, I don't even know

what just happened. This is out of anything I've ever imagined. And it won. And it was,

and the lesson there is it was trained not on what we've learned, but it trained itself and

figured things out from first principles and then came up with this thing we've never even

comprehended. And so it's a really good example of the power of coming from a bigger mind and not

being influenced by what's already been done. Yeah, we do. We have like a walkthrough ritual

that we do. Tell me more. The prompt is essentially like sort of put yourself in the shoes of

someone who knows nothing about this topic whatsoever and like kind of have beginner's mind

and then walk through with five or 10 people watching you and let's sort of fix all the

problems that we see. Okay. So I want to talk about rituals. We're getting ahead of ourselves

a little bit. Is there any other principles that you can share either just on a high level or

in depth that you've come across? And I know people can go to your sub stack and read

this. And by the way, what's your sub stack URL for people because I want to check it out?

Just lane at sub or lane dot sub stack. Sweet. We'll definitely link to it. Yeah. Any other

principles? I think the other one is cathedrals, not bricks. And then the other one is proactive,

not reactive. Cathedral is not bricks. I think is a kind of classic one. I think I had a moment

of realization and talking to Shishir in a one on one when I was at YouTube sort of bemoaning the

fact that my team wasn't performing to the potential that I thought they had. And he had a very

sort of pointed and unexpected question, which is like, do they know they're cathedral? Do

they have a cathedral? And I'm sitting there like, man, what are you talking about? Like,

we're talking about like performing as a team. And, you know, you're asking me about cathedrals.

And then he sort of explained the cathedral story, which I can, which I can talk about.

And that was quite clarifying. Yeah, the share. Yeah, the cathedral story is basically, you know,

you walk up to three people, they're laying bricks. You ask the first person, you know,

what are you doing? They say, well, I take the bricks from over here. And I put them,

you know, on that stack over there. You ask the second person, what are you doing?

They say, well, I, you know, take this little cement and I put it on top of the brick that

that person lays. Yeah, it's the third person, what are you doing? And they say, well, we're

building a cathedral. And the sort of core insight here is that you want your teams to feel like

they're building a cathedral and not laying bricks. And I think it's really, really easy to do when

PMs are really busy on a day to day to just like be one task after the other really execution

oriented, and maybe not take the time to sort of help the team take a broader frame,

open the aperture a little bit, and have a view of what the cathedral is. And I think,

you know, we've learned many times that one kind of unexpected bit of this is that everybody

needs to see a different facet of the cathedral, right? So very often, and I've made this mistake

before plenty of times, very often people will, you know, do a great write up on vision or strategy

or whatever it is. And the result is people can't quite see their, their version of what this like

broader arc is or this broader cathedral is. And so one of the things that we have tried to do

when we go through big planning cycles is kind of show all the different sides of this. So instead

of just having like a write up, we may have a write up, we may couple that with a metric,

we may couple that with directional mocks, and you know, what the billboard might look like,

or how our homepage might may change. And really what we're trying to do is kind of take

a mystery out of the set of like broader constraints or where we're headed. And so I think that that

is a, you know, I think great product teams and great PM leaders tend to always orient their

teams towards a broader cathedral as opposed to laying bricks. Such a beautiful metaphor. Reminds

me of this other quote I just looked up while you're chatting. If you want to build a ship,

don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn

for the vast and endless sea. Classic. Classic. That is right. Antoine de Saint-Expiry. Okay.

Something I was curious about as you're chatting also is for folks that want to develop their own

principles and define how they want to think about product. Is there anything you've found to be

useful in helping kind of emerge these into principles that you can come to? Is it just

sitting around thinking? Is there anything else you've done that has helped you to define these

things? Probably two things. One is reading really broadly. So I think not just reading kind of like

PM style literature, like I said, I think tend to get a lot of inspiration from outside of tech.

I think that's one thing. I think the other thing is insofar as you get the opportunity to mentor

other people, think about what you're saying to these people. Think about, okay, this person came

to me with this challenge. What was my response? Why was that my response? Am I giving that response

a lot of times? Maybe this is a more deeply held belief. So I think noticing those instances

was helpful for me. Are there any books or topics or areas that you found most inspiration of?

You talk about reading and studying other non-product tech? I mean, definitely like sports.

It's really interesting to me. Team sports have always been a huge fan of everything. Team sports,

storytelling, go look at some of the best storytellers in the world. They're actually

up there on a stage telling stories. There's a book called Storyworthy that I really like.

I was just going to mention that. That book is so good. Somebody mentioned this on the podcast

and it's like the most useful practical book for how to tell their stories.

The insight is amazing. The insight just in case your listeners are interested. The insight is

basically the nugget of a great story is like five seconds of transformation. So if you just

orient everything else around that moment of transformation, then you end up usually telling

your reasonably good story. I had a conversation with the author right after I read that book

because I was just like totally enamored with it. Then we ended up bringing him into Coda

and he gave a great talk. So yeah, big plugs for Matthew too.

The other thing that stuck with me also from that same, we're just going all kinds of tangents,

from that same insight is, and I watch movies completely differently now,

where basically the characters you meet at the beginning of the story, they're going to be

completely opposite at the end of the story because of this transformation that takes place.

So I'm watching movies and my wife and I'm like, okay, she's very shy right now. She's going to be

very extroverted by the end of this movie where they love each other or they're going to have a

lot of problems. That's such a good idea. Okay, I'm going to get this guy on hopefully and he's

like a moth champion basically. Yeah, I mean, that's like what I would say is maybe a

principle version of this. The way that you learn, the way that everyone and including me

learns new things is you go seek out the best at that given craft. So in this case, you go to the

moth, story slam, you see some really good stories. If you watch these on YouTube and then you just

kind of unpack what they're doing and how they're doing it. And then obviously, I think the other

way to learn quickly is to throw yourself in the deep end. So in so far as you can put yourself

in situations that are uncomfortable or having forced you to do things like tell a story or

force you to come up with a clear strategy, you should always opt into those, especially early

in your career. The first thing you said, that's basically the whole premise of this podcast,

find the best at all these things and learn from them, extract and share. And the world is much

better for it. Yeah, this podcast is an amazing resource you've done. Thanks, man. You've done

something very special. I appreciate it. This podcast episode is already very special. The

point you just made reminds me of something that I heard you talk about, which is kind of this

oh shit moment. I don't know if it's related to what you shared of just giving us people a sense

of whether they're making progress in their career. Can you talk about that? Sure, yeah. I think

I picked this up originally from Seth Godin, the author, and it just like totally stuck with me.

The basic kind of thesis is that moments that stretch you or moments that you feel uncomfortable

in or you find yourself saying like, oh shit, I shouldn't be here. I'm under qualified to be here.

Those are the moments you should be seeking out, right? Those are the moments that stretch you and

give you sort of like a new foundation. And so I found that they turn out to be a pretty good way

to calibrate whether someone is growing in their career. So oftentimes, you know, you'll hear

like a career question like, do you feel like you're growing in your role? And that's like a very

ambiguous in my opinion way to ask this question. And like a much sharper way is like, hey, how many

like, oh shit moments have you had in the last like six months, year or two years? And what are they?

And like, I think if you ask yourself that question and the answer is it's been a really

long time since I've been like stretched in some meaningful way, or I've felt, you know,

like I'm under qualified to be there, then it may be worth kind of like digging into.

That is so good. Makes me think about this podcast where I never wanted to do a podcast. I'm like,

podcast person, I don't like, I just want to sit there and type out newsletters. How cool is that?

And I'm like, no, I got to do it because it's hard. And, and I'm glad I did it. It also reminds

me of this quote that I love that I always think of back to the cave you fear contains the treasure

you seek. Nice. That reminds me of, have you read the book, The Obstacle is the Way? No, say more.

It's a, it's a great book by Ryan Holiday. And the kind of core thesis is it's, it's a book

a bit about stoicism. But the core idea is essentially, you know, instead of running away

from obstacles, you should be running toward them. And that's, you know, where you experience,

like either the most growth or the most sort of profound moments of your life. And

he has a lot of examples in that book of people throughout history who sort of made that choice.

And I think he's also given that talk to like hundreds of sports teams. So it's a good book

for 3D. It's so hard. It's so hard to do hard things, man. God damn it. So we've been talking

about principles of great product managers. You also spent a lot of time looking at the

rituals of great product teams. And I know you're working on this handbook that I'm excited to

learn more about. Can you just talk about, I guess, one where this idea came from of studying

rituals at great teams and also just how do you, how do you actually go about learning about

these rituals? I know you have this really interesting process. Yeah. I mean, in general,

I'm a big believer in, you know, good designs and good product starts with noticing. And I think,

Tony Fidel has a great talk on this. So I think a bunch of us that are really obsessed with

rituals, we just honestly try to be great at noticing. So, you know, see something happen

with a customer, ask a few questions, get introduced to their team, hear about something

interesting from a non-customer, ask for an intro, you know, end up kind of like just probing and

asking a lot of questions. And then in many cases, you know, nowadays with Kota, we're building new

rituals alongside people. So someone has a creative idea about how to implement something. And we're,

you know, we're like partners or collaborators with them on that, which is honestly incredibly fun

to just like see people's creativity expressed in a tool and then, you know, by extension kind of

the social construct that they exist in. So that's, that's a little bit about how we, we got started

in that whole process. And then of course, Shashir is writing a book called Rituals of Great

Teams. So we've been kind of cataloging. We've been hosting a bunch of rituals dinners where we

basically get people together for a dinner. And we usually have, you know, three or four

presenters at those dinners. And, you know, it's, it's just a great chance to learn and think about,

you know, how the, how the, how the engine runs in a lot of these companies.

What are some rituals that you've learned from these dinners and these,

and has research you've done that have really stuck with you?

There are so many. It's like, it's hard to choose. Maybe I'll choose two that are,

that are top of mind. One is Darmesh Shah has this, this ritual from HubSpot called Flash Tags.

Have you heard of this? No. So yeah, we've all probably been in the situation where,

you know, someone gives you feedback and you're, you either like underinterpret it or overinterpret

it. And as an organization, you know, the, I think the kind of core principle here is like,

you want to be calibrated on how much to pay attention to a bit of feedback.

And so he outlines four Flash Tags. He presented this in a dinner, one of our dinners. And I,

I absolutely love the phrasing of these as like someone who's given a lot of feedback on product

stuff in their career. So that it ranges from, I think it's FY, suggestion, recommendation,

plea. So FY is basically like, I had a thought, you know, take it or leave it kind of thing.

Suggestion is, and he uses this like hill dying metaphor. So is this a hill I'm going to die on?

And FY is like, you know, there's no hill in sight. Suggestion is like, there's a hill,

I'm not going to die on it. Like, you know, this is what I would do if I were you, like,

you can take it or leave it. Recommendation is like, I'm climbing the hill. I'm not going to

die here. But like, I've thought about this a lot. So like, don't ignore this, you know,

and then the fourth one, plea is, you know, hopefully rarely used in the organization. It's

like, I don't like dying on hills. That's not what we do here. You know, but this is a pretty

good candidate for it. Like, you should really trust me. And so we have ended up using that

actually just at an offsite. And someone gave a lightning talk to our team on how valuable this

has been, just to calibrate, you know, hey, we got 100 pieces of feedback, and there's like

one plea. Okay, let's spend our time on that, you know, or, you know, there's a whole bunch of FYs.

I think we're fine. Let's keep going. No worries.

That's amazing. It's interesting. None of them are just just do it this way. Imagine that's very

intentional. Yeah, I think it's, I mean, it's honestly, it's a sign of a, in Darmash's case,

I don't know him super well, but like, it's a sign of a really experienced leader, you know,

to know that that scale. But every time I look at the scale, and I'm sort of weighing where I am

between, you know, suggestion or recommendation, I have to kind of like giggle to myself.

And how do you, how do you actually use it? You, in the feedback, you like put a hashtag

plea kind of thing. The way it gets used in code docs and the way I think other companies have

made it a ritual is like, you'll have a feedback table. And, you know, you'll write your feedback.

And then there'll be just be like a little select list and you can select between those four.

And usually people, what people do is they include the description so you can kind of like as you're

choosing it, think, you know, am I really, do I really feel that strongly about this?

And honestly, it's just, it's good hygiene, you know, otherwise, every bit of feedback is taken

the same, which is just fundamentally like the impact of that as it slows everything down. Because

now you're looking at like a list of pieces of 100 pieces of feedback and you're going like,

oh man, we got to address all this feedback. Whereas, you know, as soon as you distinguish

between what's most important, it's much easier to sort through that.

What about if it's in person? Do you say this is a plea or this is a FYI?

Oh, I've definitely heard that in many meetings. Like, are you making a recommendation or are you

making a plea? Amazing. And making the person think through that choice, I think, is just a very

helpful shared language. Imagine one of the other benefits of this is, I think, most leaders that

rise up the ranks eventually realize anything they say in a meeting is going to be like taken

really seriously and the team's going to rush back and be like, Oh, exactly.

Told us to change this thing. Imagine how you just make it clear. No, you don't need to actually

change this. Just my thoughts. Yeah, exactly. Yeah. Awesome.

This episode is brought to you by Ezra, the leading full body cancer screening company.

I actually used Ezra earlier this year, unrelated to this podcast, completely on my own dime,

because my wife did one and loved it. And I was super curious to see if there's anything

that I should be paying attention to in my body as I get older. The way it works is you book an

appointment, you come in, you put on some very cool silky pajamas that they give you that you get to

keep afterwards. You go into an MRI machine for 30 to 45 minutes. And then about a week later,

you get this detailed report sharing what they found in your body. Luckily, I had what they called

an unremarkable screening, which means they didn't find anything cancerous. But they did find some

issues in my back, which I'm getting checked out at a physical next month, probably because I spend

so much time sitting in front of a computer. Half of all men will have cancer at some point in their

lives, as will one third of women. Half of all of them will detect it late. According to the American

Cancer Society, early cancer detection has an 80% survival rate compared to less than 20% for late

stage cancer. The Ezra team has helped 13% of their customers identify potential cancer early,

and 50% of them identify other clinically significant issues, such as aneurysms,

disc herniations, which maybe is what I have, or fatty liver disease. Ezra scans for cancer and

500 other conditions in 13 organs using a full body MRI powered by AI and just launched the world's

only 30 minute full body scan, which is also their most affordable. Their scans are non-invasive and

radiation free. And Ezra is offering listeners $150 off their first scan with code Lenny150.

Book your scan at ezra.com slash Lenny at ezra.com slash Lenny.

Any other rituals that stand out as really interesting, either more recently you've

learned or something, you're just like, oh, wow, that was genius. I guess one that I get asked

about a lot on our team is called Catalyst. And I guess maybe to set some context on this one,

in most product teams, their review forum is just like a really important part of the product

development process. And the kind of like core insight for, you know, most review forums or,

you know, product reviews or decision forums is that they generally suffer from two problems

that are like kind of hard to spot unless you've sat through, you know, hundreds of them.

The first is they have standing attendees. And the second is they're normally single-threaded,

meaning they're normally like one topic at a time. So maybe I'll talk about both of those,

because I think they're not exactly intuitive. So when you think about what happens in a standing

with a standing set of attendees, you either have the situation where you have like too many people

in the meeting, or you have like not enough people in the meeting, and both of those can cause

problems, right? So like, if you've ever been in a meeting, I certainly have where it's like,

hey, do we have the salesperson who like knows most about this, or do we have the engineer

who's actually implementing this here? Oh, great, they're not here. They're not like a part of the

standing set of attendees. You either like have to reschedule the meeting, or worse, you just like

do the discussion without the person who's like most knowledgeable, which seems, you know, crazy

in retrospect. The second problem is single-threaded. So like one topic at a time. So if you think about,

you know, if a product development process is like, you know, somewhat of a chaotic assembly line

for a second, you know, your review or your decision forum ends up being a big time bottleneck

in many cases. And like, obviously, you know, you want to be in a situation where

product people have a lot of autonomy and they can make, you know, most of the decisions themselves

and a big believer in kind of like decentralized leadership and all of that. But there are things

that cut across the company that like need to get reviewed by a broader set of stakeholders.

And so what happens when those things are single-threaded is, you know, either the meeting is like

really long. So it's like a three-hour review meeting once a week. And by the end, everyone is

like, you know, about to fall asleep, or it's really short. And it's like really hard to get on the

calendar. You're like, Oh, can we get on the calendar in two weeks? And the downside of both

that like the downside of the, you know, not being able to get on the calendar is that

now you've like just slowed down the whole velocity of the company, because the like throughput of

your review meeting is really slow. So we built Catalyst to really solve those two problems.

And so the way it works is it's essentially three one-hour blocks throughout the week. And the

assumption is that the whole company is free. So you can get anyone in the company for those three

hours. And each topic has essentially four roles, driver, maker, brain trust and interested. It's

a very transparent system. So like a salesperson can say, Oh, I'm interested in this product

development review, I'm just going to mark myself as interested. And then the driver is like the

person who's actually going to like drive the meeting, drive the decision, drive the outcome,

things like that. And basically, this is all centralized in like one doc. And what happens

is the day before that hold that's on calendar gets removed. And then you have specific topics

that get added. So there may be like three topics going all at the same time, because they don't

have overlapping attendees. And, you know, the impact of this, I think if you really

watch it in progress is huge, like it's, you basically have many topics running all at the

same time. So the throughput is much better. And you have the right attendees every single time.

And you have like a clear set of like drivers and roles in these meetings. So that means that

like we can review work much, much faster with the right people. And ideally, that results in,

you know, more value to our customers, more things getting shipped, just a higher velocity

organization. So that's, that's one that we get asked about a lot. And actually a couple weeks

ago, we spent a while kind of remaking the template for that one. I love that ritual. You

actually wrote a, even in more depth in the post that we worked together on on how Kota builds

product, which we'll link to, if folks want to try this out and you link to actual templates,

people can actually use it their companies. When someone's listening to this and they're like,

Oh, wow, this is extremely cool. How easy is it, do you find for people to take a ritual from a

company and implement it? Like how much of that is cultural? And it's hard to transplant? Or do

you find people can take this catalyst idea, plug and play at a lot of companies? Yeah, I think it

depends a lot on what your role in the company is. Like, you know, if you're maybe to say the

extremes for a second, if you're like a brand new PM to an organization, you probably shouldn't go

try to like remake the whole review product review cycle that like the head of product is really

passionate about and it's like crafted. But you know, you can probably take a, you know, a decision

template or some interesting ritual that has facilitated a team, you know, in the past and use

it with your team. Another one of my favorites there is $100 voting. We use that a lot in the

context of planning. And I find that like creative rituals like that are easy to pick up for teams

because oftentimes it's like, okay, maybe I'll describe the ritual real quick. So the ritual is

essentially you can take any set of, you know, problems or solutions or themes or, you know,

whatever you want to get people's input on and you put those in into a table and then people can

basically vote with their dollars and usually you allocate $100. And so people will go through and

say like, I want to allocate $10 to this and $20 to this and $50 to this because I think it's really

important. And I have found that especially in planning processes, little rituals like this

are great at kind of like getting the elephant in the room out. So it's like, oh, wow, we have like a

huge spread on this one particular, you know, problem. You think it's a huge problem. I don't

think it's a problem at all. Let's talk about it, you know. And so I think a lot of, you know,

going back to the thesis of turning ambiguity into clarity, you know, a lot of this is like,

we're trying to get the ambiguous stuff out there so that we can make it more clear.

And so I use that as an example because you can be, you know, a brand new PM,

run a brainstorm, run a planning session like that, and you're probably going to get great

feedback, right? Like people are probably going to go, this is kind of cool. I've never done this

before. Now, to go to the other side of the spectrum, you know, we help a lot of companies

that want to remake a whole process. They want to remake like a review system like Catalyst

or they want to remake, you know, their decision kind of like rituals. And so in that, in that sense,

we're usually talking to like a head of product or director product or VP of product and someone who

tends to have a lot more agency over, you know, the way that the team works.

Code is interesting in that it feels like you have pretty stable processes for planning and

reviews. I find most companies just like every six months rethink a lot of these things.

I guess that's probably a sign that you found something that's really good and works and you

don't have to redo it. How much are you radically changing the way you operate versus working in

similar ways? Is there like a, how do you think about that percentage wise?

People are always coming up with new creative ways and to kind of like make their teams run better,

make decisions, go smoother. And we're kind of continuously adopting those, but there's

definitely a backbone of the system. Like the backbone of the system is Catalyst and Tag Ups

and the concept called Bullpen. And then, you know, there'll be a lot of iteration on top of

that. And even those systems went through a lot of iteration. Like I talked about how the calendar

hold got removed and then like individual topics got added. I mean, that took us launching like

automations and the ability to add things to calendar in order for that whole process to

really work. So in the years prior to us launching that, you know, we kind of did it with very manually.

So I think there's still a lot of creativity that I see every day. So I'll give one quick example.

One of our PM leads on core products, this guy Nathan, you know, he basically saw that a lot of

decisions had a lot of different stakeholders because like he's in the core product. And now he's

leading the core product team. So he's trying to figure out what guidance do I give to each of these

DMs on like who to involve in these decisions? Because like every one of these with core product

feels like they impact everybody. And so like a very simple thing that he did, you know, probably in

the last six months was he had a table of all the upcoming decisions. And then at a tag up, which I

can explain if you want, but basically with a small set of stakeholders, he had all the upcoming

decisions. And then he let people hit a little reaction and say, Oh, I want, you know, I don't

need to be involved, just notify me of the decision after or have some opinions, but you can keep going.

Or no, I really want to be like heavily involved in this decision. And it was like such a pro move.

You know, it was like such a, I've been through a million of these. I don't want to treat every

one of them the same because if I do, it's going to slow down the velocity of this whole organization.

And so instead, you know, the majority of those Shashir or I or Oliver, the head of engineering

will say, I may have some opinions, but keep going. Like that's kind of like often the default.

And then there are plenty where we say like, just notify us of the decision after. And in doing that,

Nathan can now give better guidance to the PMs on his team and say, like, Hey, you don't really

need to involve like as wide a group as you think. So just like keep, keep going and, you know,

check in later. So I think those are those types of little iterations are usually based on a really

good insight. It sounds like a dream come true for a platform team to reduce how many people

have to be involved in all your planning and decision making. And that process and which

really you call it tag up, maybe just briefly explain it. And then I want to talk about this

handbook you're working on, which is going to I think cover a lot of these things.

Tag up is based on this insight that a lot of work and project work tends to get discussed

in one on ones. And actually, that's like an it's really an anti pattern. It's a pattern you

should try to avoid. So if you're talking to your manager about product work, what's not happening

in that moment is your engine lead and your design lead, they're not hearing that. And so you end

up with this like big game of telephone where, you know, you'll have a conversation with your

manager and one on one, they'll go back and translate to their engineering and design lead.

And of course, like the fidelity of, you know, the game of telephone, something is lost and all of

those transmissions. And so the core idea is kind of have a group one on one with the key

stakeholders. And so we have this concept of brain trust that's kind of modeled off after

Pixar's brain trust. And so we'll have a tag up with a small set of people from a given team.

Or sometimes we have kind of larger groups. And then they meet with their brain trust.

And it's once a week. And it's really the it's sort of the same mindset of a one on one. It's

like their time. So anything that they need to unblock a decision or to like make make progress,

they should use that time for and they often start by like reviewing KRs and metrics and

things like that. But then we generally get into a table of topics. Anyone can add a topic.

You know, those topics are upvoted. So people will react. And then the table will sort itself.

And then we'll say, okay, this is clearly the topic on people's mind. And that's like a version of

called Dory, which I can talk about. But essentially, the kind of principle is

you should discuss that project work with the whole group there, right? Like with the whole

triad there. And oftentimes with the salesperson there and with the marketer there and like with

everybody else. So I found that that is just a really good practice to try to sort of move a lot

of that work out of one on ones and into a small group setting. Awesome. Okay, so you're working

on a handbook that's collecting a lot of these rituals. Talk about that. And then when can people

maybe look for it? One of the realizations I had the other day, probably like a month or two ago

when we started working on this thing was someone I was talking to someone about catalysts and a

couple other concepts. And they're like, I get it. I'm sold. Like let me like I want to implement

some of these things. Where do I look? And so I found myself sending them a bunch of links to

individual templates. So that was kind of like that queued us into the fact that we needed to

have like a better kind of core handbook for teams that wanted to adopt some of these rituals.

And also learn from all the rituals that we have learned from and feel very fortunate to have

partnered with so many customers on. And so what we did was started writing this handbook.

And it's going to come out hopefully by the time this recording is done. And in it, you know,

we'll talk about, you know, everything from rituals like catalysts to decision rituals to a

lot of like planning and strategy and roadmaps, that kind of stuff. And trying to pull out the most

interesting patterns and also give people a pretty practical view of like how to implement these

things. So I think that's, that's what has been lacking sometimes. Amazing. We'll definitely

link to that. Hopefully it's live by the time this goes up. We'll make it happen. I know also

you said Shashir is working on a book that's related and basically rituals of great teams.

And Shashir was on the podcast and talked to a lot of some of these other, he talked about Dory,

so we don't have to get into that. If people want to learn about Dory, they can watch that episode.

It was one of the earliest episodes actually, one of the most popular. Yeah, I remember that.

Okay, cool. So I have a bunch of random questions now. I'm just going to go in a few different

directions. One is you wrote this post that you call learn by making not talking. Is that

another principle, by the way? Is that amongst your many principles? Okay, awesome. So in that

post, which we'll link to, you show the story of how you and the YouTube team came up with

skippable skippable ads, which was, I didn't realize was such a controversial,

but we're thinking about it, obviously, like letting people skip ads. I could see why people

were not excited about that. Can you just tell that story? And basically, it's like the story of

how skippable ads on YouTube came about. Yeah. So I moved over to YouTube shortly after the

acquisition. It was amazing, like tight-knit team. It definitely felt like the Wild West.

It was, you know, we were getting sued by Viacom for a billion dollars when that was a lot of money.

No advertiser wanted to talk to us. It was essentially viewed as like a site of cat videos

and dogs on skateboards and things like that. And then I guess the other context, the sales team

was like very nascent. And all they wanted to sell was the homepage. And for good reason,

like that was where you made your money as a salesperson. And so, you know, I had just been

sponsored by Salar and Shashir to become a PM. It's a longer story. I'll leave out for now.

And we can go into it. But, you know, on day one of being a PM, Shashir is like,

great, you're the new guy. You get the project that nobody else wants. And that's called skippable

ads. And, you know, we've got this crazy idea that we can align the incentives of advertisers

and viewers and creatives in this like really clever way by putting a skip button on the ad

and then charging people for views. And the latter part, we hadn't quite cemented yet,

but it was sort of a part of the core idea. And so, the thing I write about in this post is,

like, as a new PM, this feels like a really consequential decision, right? It's like,

we've got this like new product idea. Nobody really wants it, like advertisers don't want it,

the sales team doesn't want it. And it's like a very unproven thesis. And so, the thing I write

about is like, these are the types of things that you can debate for like months or years,

you know? And I was sitting in a one-on-one with this guy named Phil Farhi, who's an amazing

product leader and was my boss at the time. And we're, you know, we're trying to figure out what

and how to handle all the different dynamics. And he just kind of like stops and he's like,

you know what, like just test the extremes, start the experiment tomorrow, like then we'll

figure it out, essentially. And I think his point was like, look, we can debate this forever.

So, like, I would rather us see the upper and lower bounds of like how good this could be or

how bad this is going to be, like immediately. And so, you know, we launched a set of experiments,

this guy, Jamie Kearns, who's still there, a little tiny little skip button, you know, on one

experiment, giant skip button that covered the entire player on the other side of the experiment.

And within a few weeks, I think we had developed some conviction, you know, based on some very

directional data that we were onto something. And so, the lesson that I took, you know, this is

many years ago, and I've seen this proven out hundreds of times since, is, you know, stop talking

about it and like go make something, go like run an experiment, go make a prototype, you know,

go write a doc, go make a mock, just don't talk about it. And I found that people, you know,

also as a leader, people really follow that concept. And I also found that it's like,

it transcends level, you know, like I'm not talking just to ICPMs, I'm talking to like heads

of product and CPOs and CEOs to some degree, like, you know, you should always be out there

trying to learn by expressing your ideas and putting them out there. And that's much more

valuable in many cases than, you know, pontificating about it or having endless, you know, circular

discussions on it. Makes me think a little bit about Twitter, where they spent years just thinking

about the added button, or all these different changes, they're so scared, they did so much

research. And then now it's just like they're changing things left and right, everything's fine,

everyone's still using it, shows you that you don't have to be so delicate. Yes, it's almost never

as bad as you think it's going to be. So yeah, it's just a question of how much better it can be,

oftentimes. You mentioned in your early career, we talked about your Alaska guide phase,

something else I saw is that you are on the AdWords approval team, you're basically reviewing ads

people submitted to run on AdWords. And that's kind of how you started in tech. So I guess,

first of all, is that true? And then second of all, how did you graduate from that phase and become

this chief product officer of one of the fastest growing, most interesting companies in the world?

That was a really memorable time. It was, there's an amazing cohort of

people that started in tech, there was like 200 or 300 of us at that time, and then eventually

thousands that started in Sheryl Sandberg's organization. I guess maybe some quick context,

before running ads on Google.com at that time, you had to have them manually approved by a human

before that was handled by machine learning and outsourced to other countries.

And so there was this process where basically an ad would show up on your screen, you would mark it

family safe, non-family safe form, and then you would, based on that, it would either run or it

wouldn't. And actually funny enough, some of my most successful friends were terrible at the

approval event. Like they failed the ROTE task of approving ads, they just couldn't handle it,

and they went on to be really, really successful. So after working on ad approvals, at that time,

I moved to chat support. It was basically like when AdWords was launching chat support, I

remember very fondly having two chats chatting with two advertisers at once,

moved on to phone support. That was eight hours a day of talking to AdWords customers. Really,

a total roller coaster ride, it was basically like one minute you would pick up the phone and it would

be someone from a Fortune 100 company trying to spend like millions of dollars on AdWords,

and then like the next minute you would be on the phone with like a psychic or a taxi driver

that was like warring with their compatriots over some really specific keyword. I think there were

kind of like two lessons that I would draw from this. One is I had a mentor at the time and his

advice when I was starting my career was basically like, you have to get customer facing from the

very beginning because you're going to end up serving a customer your whole career. Like even

when you're the CEO of a company, you're going to be serving a customer. So you better get like

really good at being in any customer scenario and being able to handle it. And so I think that that

turned out to be insanely good advice. And if I think about something that a piece of advice that

I give out to people who are early in their career, I've definitely recycled that advice.

I think the other thing that I took away from that experience was

it's just a great lesson in when people don't actually care about your product.

So in AdWords case, people did not care about AdWords. Like you were like the expert on it

and you're trying to tell them about ad groups and like how this ad format works and blah blah

and like most of the time people are like, dude, I'm a small business owner. I'm trying to like

get people to come to my auto mechanic store and I'm trying to get people to come to like

my taxi service or whatever it was. I don't care. And so like you're basically the product had to

kind of get out of the way and really just drive impact for the customer. It was like

they just want more phone calls or they want more people in the store. So those are I think two kind

of like pieces that I think about from those days still. And then I worked in a variety of other

roles. I worked in a role called product specialists, which is an awesome role back when

there are like 15 product specialists at Google. And that was for me, that was an amazing time because

I had I was getting to sit on like seven or eight different core teams, core product teams.

And in my observation, most people these days, most PMs don't get to sit on other people's core

teams. And so I kind of had these like three or four years of just, you know, I kind of call

like a masterclass in PMing because I was getting to watch like what was working for some PMs and

what wasn't working for other PMs and just kind of like taking notes behind the scenes. So that was

a that was a really influential role. And then yeah, went on to various PM roles at Google and

YouTube. Coming back to noticing comes up again and again in our chat. This is so interesting

because it feels like you basically came from the mail room of tech to the top of the product field.

And so I think there's a lot of inspiration people can take from this journey. One quick

question is how long was that journey from not being a PM like from, I guess, being at a tech

company to getting a first PM role just to give people a sense. Let's see, I probably worked

for at least four, five years before being able to to PM. And that was I think that was like a

slightly harrowing journey because at the time you had to have a computer science degree at Google,

right? Cool. So I think that's one takeaway too is give it time. It's not going to happen. There's

a lot of people that are just like, I need to become a PM immediately. And I think that's a good

example of like, it's not going to happen overnight. Coming back to your two lessons, I think they're

really interesting. And I'm curious if there's anything else that comes to mind of what you've

found was essential to you succeeding in this path. So the first lesson you shared is being

customer facing. And in this case, like being in retail as customer facing is your advice,

like get in a tech company and work on something customers use or is even like working at Starbucks

or you know, Abercrombie, does that count? Yeah, I mean, I think maybe related to what you just said,

if I were to give advice to someone who really, you know, is trying aspires to be a PM or trying

to get into PM, like, I think in many cases, if you're in a customer facing role, you are the

expert on the customer. And that is like really, really valuable in tech organizations. And oftentimes

it's kind of undervalued. And so I think people who are who want to move into PM roles, who are

sort of not currently in PM roles, can often lever that experience and that knowledge of the

customer in ways that are, you know, pretty profound for the organization and pretty insightful

for the organization if they if they really are creative about it. And then I think the other

thing is, regardless of like where you are in the organization, you're always serving a customer,

you can't just like, talk to one big enterprise customer and you can't just talk to the smallest

customer, you kind of have to like, have a diverse and continuous stream of customer interactions

in order to have good intuitions about what to do next. And, you know, your engineers aren't

going to really trust you unless you have good intuitions about like where the customer's headed

and what they want and stuff like that. And so the stakes I think are pretty high. And it's,

you know, the good news is, it's like easier than ever with all these tools to really get into,

you know, the mindset of a customer.

Well, lesson touches on something the previous guest talked about Paige Costello, where she was

like the often the youngest person in the room and built a lot of respect and people really

trusted her over time. And her lesson was, know thy customer. If you know the most about what

they need, and you can show like, here's what I've heard this again and again, again, people

just like, oh, Lane, tell us more and they bring you into conversation because you're providing

value. You're not just there sharing opinions. Everyone's got opinions.

I mean, that's basically how both me and I had a friend named Bill Ferrell who transitioned into

PM at the same time. And that's essentially how we got, you know, that the try at being a PM

inside of Google is like, we knew the customer really, really well. And we were often in conversations,

you know, sort of bridging the gap from here's what the customer thinks that, you know, here's

what I think they're really saying, or here's what I think we should build based on, you know,

what they said. The other thing I wanted to mention, you talked about the product and how a lot of

customers don't care about the product, they just care about just any of this thing done. Reminds me

at Airbnb, we hired this guy, Chip Connolly, who was a hotelier. He created the Ruataville Hotel

chain and just like is steeped in hospitality. And he came to Airbnb and started doing this

worldwide tour talking to hosts. And he's just like, guys, when you talk about product, like

you're like telling hosts, hey, the product's going to be updated, we're going to launch all

these features, like they don't, like they think they're home as the product of Airbnb,

they don't understand what you're talking about. When you're talking about the online experience

and the website, like that's the last thing they think about it's the experience of someone

traveling on Airbnb and staying in their own. So I think it's a really good reminder of like,

most people don't care about the product, they just have this problem. And you just happen to be

this website that'll help them solve it.

I think most people can be like way more concise to their communication, like even internally,

people don't care. You should assume that people don't care. Or if you're talking to customers,

writing a blog post for customers, like you should assume that they don't care. When you

start with that assumption, you really force yourself to be a little bit sharper in your

communication. So I have one final question before we get to a very exciting lightning round.

I heard a story that at Coda, there's this moment called Tim Ferriss Day

that drove a lot of traffic. Can you share that story? Does that ring a bell?

Sure. Yeah, there's lots of memorable days at Coda. One of them was Tim Ferriss Day. So I guess

maybe for context, we had built this kind of like publisher, very nascent publisher motion,

where we were going out and helping people, you know, publish their rituals. And this is what

you see in the gallery, the Coda gallery, and a lot of what we talked about today. But we had this

one person on that team, this guy Al Chen, Tim Ferriss Fan, and also I think had been really

tenacious with like the people around Tim Ferriss and basically finally got into him and like

figured out a really neat way to implement one of his rituals and Coda Doc. So none of us really

knew this, but like this is all happening. And anyway, we wake up one morning and traffic is

just like spiking through the roof. Signups are spiking. No one knows what's going on.

Like I'm convinced this is all spam. I'm like something's wrong with our data or like, you

know, something's going haywire. At the time, we were also in the China Basin office and the

fire alarm went off. And so like now we're like outside on our laptops, we were like in a war

room trying to figure out what what was happening. And now we're outside trying to figure out what's

going on. So anyway, make a long story short, data scientists investigate. And you know, we

eventually figure out that we had been featured in Tim Ferriss's email newsletter. And you know,

I think early on, you hear you hear this lesson or this adage of like first time founder build a

great product, second time founder build a great distribution. I think that was like one of those

early big cues to think about, you know, the importance of content distribution and the importance

of these publishing flywheels. And it definitely made us double down. We're like, okay, if we can do

this with Tim Ferriss, like what, you know, what's next? And we definitely spent a few months trying

to reach that, you know, that high watermark that was set that day and in traffic and sign up. So

it was the fun memorable day and people for like the subsequent one or two years, you know, would

refer to it as Tim Ferriss day. So funny. I bet Tim Ferriss said, I had no idea what he did. No

idea. And hoping you have a Lenny's podcast day when this comes out, everyone's going to be freaking

out. What is going on here? Is there anything else you wanted to share before we get to our very

exciting lightning round? Maybe we're talking really briefly about two way write ups. Yeah,

let's do it. Yeah, I have that in my notes, but I skipped it. So I'm glad you mentioned it. Cool.

Yeah, I think I mean, this is a concept that I wrote a bunch about. And I often now get asked about

and I guess that maybe the historical view of this, I got really obsessed with the history of like

how work gets discussed and decided upon and kind of broke it down into like three phases. And so

the first phase was 1980s, we had PowerPoint, you know, it was like this amazing tool, you could

like manipulate shapes on a screen and we were all like using fancy clip art, you know, it was

really fun. But we've all had the experience of being in a really long PowerPoint presentation

and kind of like someone's droning on in their slides and stuff like that. Second phase is in

the early 2000s, kind of like two things converge. One was Google bought this company called Rightly,

that became Google Docs. So instead of having Word on your desktop and sending files around,

you now had kind of like online collaborative editing. And the other thing was Jeff Bezos sent

this very famous memo, which basically said no more PowerPoint at Amazon. And what that did was

kind of started in earnest, their six major ritual. So you can read all about this in the book,

Working Backwards, a good book, Colin Briar's book. And so that started, I think, what was kind of

like what I'll call the one way write up phase, which is like, you're writing down your ideas,

you're expressing them clearly, it's in prose, so you have to be really clear. That was like a big

step up, I think, from presenting, always presenting work and deciding on work by presentations.

And then kind of the thesis is that we're like in the midst of a new phase, which is essentially

two way write ups. And that's where it's more conversational and feedback and discussion is

like actually part of the content itself. So that's kind of like the broader historical art.

But if you think about it, PMs and like product people are always at the like brunts, you know,

they sort of feel this the most because they're the ones that are like driving decisions. And

really the ones that are driving discussions oftentimes in companies. And so, you know,

I think the problem with one way write ups, I felt very deeply at Google on YouTube. And

just to name them, the first one is, you would always be trying to figure out like who's read

your write up. So, you know, I have many memories of sending a write up out at 11 30 PM, and then

like waiting patiently for the avatar of like the SVP in my area to show up in there. And

that was like a sign that they had like read it, which is like, you know, just totally insane

if you think about that behavior. The second one is you end up having a lot of the discussion

in the comments itself. So, you know, this is a space that's really built for like grammar

and spell checking and things like that. And you're having like these really meaningful

discussions in this kind of like 100 pixel right margin. And part of that I think is like

there are all these questions that are being raised. And so, you have really no idea

like what the most important question is. And so, if you're facilitating those discussions in

one way write ups, you're often like going through the comments in the 20 minutes before

that session trying to figure out like which one of these do I want to address. And then the other

behavior and I don't know if you've ever seen this in a doc, but like in one way write ups that

you see a lot is like there'll be a just a mega comment thread on like the title of the doc.

And it's like people are like, I don't think we should do this or like, you know, you'll get into

this 30, you know, 30 comment thread on the title because that's like the best place to put your

like overall thoughts. And I saw this like pattern all the time. So, if you if you live that life,

I think the world of two way write ups and like the way that I think a lot of our customers are

doing it and you can do this on other tools besides Kota 2. I think it's quite a bit better.

You end up, you know, I guess the alternative to go down that list is you have a done reading

button at the end of a write up. So, now you can say like, oh, you know, these are all the people

that have read this. And like, I think even you see a pattern in some of our customers where if

it's like a particularly long write up, you'll have three done reading buttons. So, you can kind

of see like where everyone has gotten to. And then the second thing is making sure that you're

actually addressing the most important question. So, instead of pulling questions out of the

comments and trying to figure out which one to address, just putting those in a table and then

letting people upload those. And that's what we call Dory. And then I think probably the most

valuable is sentiment or pulse, which is, you know, how do you feel overall about this particular

proposal? And if you think about, you know, the contrast between like a comment thread on the title

and seeing a list of all the sentiment, how everybody feels about this proposal,

and really being inclusive to the entire audience is just wildly different. I think

in my particular experience, I'll give you one example. I read this proposal. This is now a

couple of years ago. I thought it was going to sail through no problem. I thought I was going to get

four out of five and five out of five smiley faces from everybody. That's sort of how the

sentiment table works. And one of the like lead designers basically said like one smiley face,

we shouldn't do this. I was like, oh man, this particular person's like not really vocal on

meetings. And so I would not have heard that feedback. It was like very unlikely I would have

heard that feedback unless, you know, they had had a sentiment table, a place to add that. And so I

think the, you know, the kind of punchline on all of this is I really authentically believe

that this is like a, this is sort of where we're headed and, you know, hope that a lot of PMs

and product teams adopt this in general. I'm so glad that we touched on it. And there's a

template or an explanation of this that you wrote up that we'll link to. Yeah.

Great. Yeah. Awesome. Is there anything else that you think that we should touch on that we

haven't touched on? Yeah, I think one thing that we've discussed before is just about strategy

and planning and stuff like that. So it may be useful to touch on a couple kind of like insights

there. I think there's kind of like two, two insights in the strategy and planning thing. And

this is again, in the handbook that we're writing, but the first that I end up seeing a lot is just

this idea that like, okay, ours are not actually strategy. So, you know, I think the way that we

plan and the way that our customers plan, the kind of key point is it's, it's critical to disconnect

like strategy discussions from okay, our discussions. And it sounds really obvious, but

it's like, I think a very common mistake. And I think a really simple question to ask yourself

was like, do we have a separate strategy process or strategy ritual that is like distinct from

okay, our setting and like metric setting and goal setting. And I have found, you know, you can pick

whatever strategy framework works for you. But I do think it's, it's quite important to pull those

two things apart. The other kind of like rule that we live by on the planning side is what we

call 10% planning rule, which is essentially, you know, just ensure that you're not for a given

time period planning for more than 10% of that execution period. And I think this is a really

easy mistake to make. I mean, we, this is a hard fought rule because we've made that mistake before,

but you end up getting kind of like bogged down and planning or saying like,

planning felt rushed. And so we need to make it three weeks instead of one week or whatever.

And the byproduct of that over the course of a lot of time is that you end up, you know,

just planning way too much. And oftentimes, you know, you really don't know what's ahead until

you've, you know, launched or learned something. And so I think that that's a pretty good rule,

the follow. I love that rule. I found the same heuristic. So 10% like planning for a week,

plan for half a day, playing for a month, maybe like three days. Yeah, I love it. With that,

we've reached our very exciting lightning round. Are you ready? I'm ready.

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

One that comes to mind is Turning the Flywheel. It's a little manuscript book. Jim Collins wrote it.

It's really, I think, a very succinct and very fast read about how flywheels work.

We talked about story worthy. I recommend that book a lot. Good strategy, bad strategy.

Love that book, very simple framework that I've reused a bunch, maybe Outside of Tech, Waking

Up as a book by Sam Harris, Unmindfulness that I really like. And then an old one that I really

like is The Inner Game of Tennis by Timothy Galway, which is a kind of classic.

Amazing. On Good Strategy, Bad Strategy, I'm working on getting Richard Remolt on the podcast and

talks with his agent and they seem to be excited. So we'll hopefully that actually

happens. And then you're inspired me to try to get this third story worthy guy on. So

what a cast of characters we're going to get on here. Next question, what is a favorite

recent movie or TV show that you really enjoy? Yeah, it's a little bit hard with three kids and

a job these days to watch a lot of TV. I would say I really enjoyed The Last Dance. I love

any sports documentary, all those. Have you seen Underrated, Steph Curry's new documentary?

No, I haven't. I've got to watch that. It's really good. I've been rewatching Arrested

Development. That's also just a timeless classic. Classic. I love that Michael Sarah is in the

Barbie movie not to give any spoilers. That was a funny surprise. Next question, what is a favorite

interview question they like to ask candidates? There's two I really like. One is teaching me

something that I don't already know. I think it's just an awesome way of seeing if someone's

going to lean in and really figure out what you don't know and then how passionate they are about

sort of pitching what they do know. I think it's really fun. And then Shashir and I have been asking

a version of Teleporter question and evolving it for many years now. So I like that question quite a

bit. Shashir shared that question in his episode and we make TikTok clips out of some of these

conversations and that clip just went crazy. People love it. It's the most of you clip I think

on TikTok or just like what would you answer to that question? So we'll try to link to it in the

show notes if you want to watch just that one interview question. I think you maybe gave it away

so maybe that's why you're evolving it. Yeah. I also recently read a post about my favorite

ref check question, which I think is I would love to learn other people's favorite ref check

questions. References check. Oh man, that's its own. Oh man, I'd love to do a podcast just on that.

That is such an important skill. The first question you mentioned of asking people to

teach you something. I heard the best version of that in a previous episode where Maya,

the head of product for Spotify podcast asks, what would your podcast be if you were to start a

podcast? I like that. Yeah. I like that. So feel free to steal it. I sometimes do a version of

making them explain it two different ways after and making the candidate explain it two different

ways and saying like, okay, now you have to explain that to your grandparent. And then like

now you just told me about sewing or some hobby of yours, like I'll sell it and it's like most

technical form to someone who knows everything about this particular topic. And so it's like

kind of fun to also see the range that people can operate. Awesome. What is a favorite product

that you've recently discovered that you really love, either digital or physical? Anything that

comes to mind? A few. I'm like become a real sleep nerd. So this I'm asked that, that like

sort of cup around your eyes. I love, obviously in the tech world, like Chad GPT, there's a,

there's a product that got really obsessed with tennis during the pandemic. There's a product

called Swing Vision. It's really good. It basically like cuts up your match into like different,

you know, all your forehands are all the longest rallies or all that uses AI to do that.

There's a corresponding meditation app to the book Waking Up that I really like. That one's a

very good one. We live not so far from each other. So we got to play some tennis and I could check

out this very cool product. Yeah, let's do it. You're on. That'll be our sequel, just our game.

Next question. What is a favorite life motto that you either repeat yourself often, like to share

with people around you, share with your kids, maybe? I don't know if it's a motto as much as

it's just a way of being. Essentially, the present moment is all that we have, you know,

realizing that our attention is very often on the past or the future. And in so many ways,

the present is where it should be always. And so I think that that is something I think about a lot.

I think maybe more broadly, I had a mentor who roughly said a version of like make things happen.

And so I really try to apply that to anything that I do. If that's like work or life or sports,

you know, I try to be the person who creates like momentum and positive change in progress.

And so I think that that's like generally a good kind of motto to live by. Beautiful.

What is the most valuable lesson that your mom or your dad taught?

My mom's a psychologist and so in a professional counselor. So certainly active listening,

you know, maybe the tech version of that or the modern version of that is like steel manning

someone's argument, being able to like repeat back to someone what they said in a better form,

more clearer form. So yeah, she's an amazing woman taught me a lot about listening.

Final question. You were a guide in Alaska helping people climb. If someone were to

pursue climbing, is there a tip or a lesson or something that you think people should know

to get better at this or to know before they go down this route?

You know, the there's kind of a saying, which is like the safest climber is the one who knows

when to come down, you know, essentially. And I think that there are many times that you have to

kind of like put your ego in check and come off a mountain or come out of a climb because it's not

as safe as you thought it was. So I think that's maybe one. I think the other is,

you know, it's probably not a one way door. So I think in many ways you can do

climbing and you can do some of these outdoor pursuits on the side or you can,

you know, you can always come back from them. So it's maybe not as big of a choice as some

people think it is. Lane, I said at the top of this episode, Kota has one of the most thoughtful

product teams out there. And I think it'll be clear to people after listening to this,

why that's the case and where it trickles down from. Thank you so much for being here.

Two final questions, working folks finding a line if they want to reach out and ask you any

other questions. And how can listeners be useful to you? I'm on LinkedIn and Twitter. And I have

a sub stack. We'll be releasing that handbook for product teams that I will probably post on sub

stack. And in terms of useful to me, yeah, give Kota a try. Give us feedback. I love hearing

from product people all over. It's like one of the bright spots in my day to hear all the creative

rituals that come from this community. You've created just a legendary community of people.

And so, you know, they always give very thoughtful feedback. So I'm very open to all of that. And

yeah, thanks for having me. Awesome. Lane, thank you again so much for being here. Thanks. 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.

Machine-generated transcript that may contain inaccuracies.

Keywords

Lane Shackleton, Coda, PMs, OKRs, skippable YouTube ads, career ladder, guiding principles, beginner's mind, rituals, two-way write-ups, product leadership, Catalyst, Tag Ups

People

Lane Shackleton, Tim Ferriss, Jeff Bezos, Colin Briar

Companies

Coda, Google, Airbnb, YouTube, HubSpot

References

Warning: Undefined variable $clean_references in /srv/www/podtranscript.com/app/podcast_episode.php on line 376

Brought to you by Eppo—Run reliable, impactful experiments | Vanta—Automate compliance. Simplify security | Ezra—The leading full-body cancer screening company

—

Lane Shackleton is CPO of Coda, where he’s been leading the product and design team for over eight years. Lane started his career as an Alaskan climbing guide and then as a manual reviewer of AdWords ads before becoming a product specialist at Google and later a Group PM at YouTube. He also writes a weekly newsletter with insights and rituals for PMs, product teams, and startups. In today’s conversation, we discuss:• Principles that set great PMs apart• Rituals of great product teams• The fine line between OKRs and strategy, and why it matters• “Two-way write-up”• The story of how skippable YouTube ads were born and lessons learned• How to gauge personal career growth• “Tim Ferriss Day” and its impact on Coda’s history• How Lane bootstrapped his way to CPO from the bottom of the tech ladder

—

Find the transcript for this episode and all past episodes at: https://www.lennyspodcast.com/episodes/. Today’s transcript will be live by 8 a.m. PT.

—

Where to find Lane Shackleton:

• X: https://twitter.com/lshackleton

• LinkedIn: https://www.linkedin.com/in/laneshackleton

• Substack: https://lane.substack.com/

—

Where to find Lenny:

• Newsletter: https://www.lennysnewsletter.com

• X: https://twitter.com/lennysan

• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/

—

In this episode, we cover:

(00:00) Lane’s background

(04:03) Working as a guide in Alaska

(07:32) Parallels between guiding and building software

(09:12) Why Lane started studying and writing about product teams

(12:49) How Lane came up with the career ladder and guiding principles

(14:10) The five levels Coda’s career ladder

(16:30) Principles of great product managers

(21:06) The beginner’s-mind ritual at Coda

(24:05) Two rituals: “cathedrals not bricks” and “proactive not reactive”

(27:46) How to develop your own guiding principles

(31:17) Learning from your “oh s**t” moments

(36:03) Rituals from great product teams: HubSpot’s FlashTags

(42:15) Rituals from great product teams: Coda’s Catalyst

(47:01) Implementing rituals from other companies

(49:48) How to navigate changing vs. sticking with current rituals

(53:02) “Tag up” and why one-on-one meetings are harmful 

(55:27) Lane’s handbook on strategy and rituals

(57:10) How skippable ads came about on YouTube   

(1:01:46) Lane’s path to CPO

(1:07:02) Advice for aspiring PMs

(1:10:53) Tim Ferriss Day at Coda

(1:13:24) Using two-way write-ups 

(1:19:30) The fine line between OKRs and strategy, and why it matters

(1:21:41) Lightning round

—

Referenced:

• Endurance: https://www.amazon.com/Endurance-Shackletons-Incredible-Alfred-Lansing/dp/0465062881

• Bret Victor’s talk “Inventing on Principle”: https://www.youtube.com/watch?v=EGqwXt90ZqA

• Jeremy Britton on LinkedIn: https://www.linkedin.com/in/jeremybritton/

• Comedian on Netflix: https://www.netflix.com/title/60024976

• The Score Takes Care of Itself: My Philosophy of Leadership: https://www.amazon.com/Score-Takes-Care-Itself-Philosophy/dp/1591843472

• The Creative Act: A Way of Being: https://www.amazon.com/Creative-Act-Way-Being/dp/0593652886

• AlphaZero: https://en.wikipedia.org/wiki/AlphaZero

• Antoine de Saint-Exupéry: https://en.wikipedia.org/wiki/Antoine_de_Saint-Exup%C3%A9ry

• Storyworthy: Engage, Teach, Persuade, and Change Your Life through the Power of Storytelling: https://www.amazon.com/Storyworthy-Engage-Persuade-through-Storytelling/dp/1608685489

• The Moth: https://themoth.org/events

• Seth Godin’s website: https://www.sethgodin.com/

• The Obstacle Is the Way: The Timeless Art of Turning Trials into Triumph: https://www.amazon.com/Obstacle-Way-Timeless-Turning-Triumph/dp/1591846358

• Tony Fadell’s TED talk: https://www.youtube.com/watch?v=9uOMectkCCs

• FlashTags: A Simple Hack for Conveying Context Without Confusion: https://www.onstartups.com/flashtags-a-simple-hack-for-conveying-context-without-confusion

• How Coda builds product: https://www.lennysnewsletter.com/p/how-coda-builds-product

• 100-dollar voting ritual: https://coda.io/@lshackleton/100-dollar-voting-exercise

• Pixar’s Brain Trust: https://pixar.fandom.com/wiki/Brain_Trust

• Lane’s product handbook: coda.io/producthandbook

• The rituals of great teams | Shishir Mehrotra of Coda, YouTube, Microsoft: https://www.lennyspodcast.com/the-rituals-of-great-teams-shishir-mehrotra-coda-youtube-microsoft/

• Principle #4: Learn by making, not talking: https://lane.substack.com/p/principle-4-learn-by-making-not-talking

• Phil Farhi on LinkedIn: https://www.linkedin.com/in/philfarhi/

• How to ask the right questions, project confidence, and win over skeptics | Paige Costello (Asana, Intercom, Intuit): https://www.lennyspodcast.com/how-to-ask-the-right-questions-project-confidence-and-win-over-skeptics-paige-costello-asana-intercom-intuit/

• Chip Conley’s website: https://chipconley.com/

• Jeff Bezos Banned PowerPoint in Meetings. His Replacement Is Brilliant: https://www.inc.com/carmine-gallo/jeff-bezos-bans-powerpoint-in-meetings-his-replacement-is-brilliant.html

• Working Backwards: Insights, Stories, and Secrets from Inside Amazon: https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595

• Dory and Pulse: https://coda.io/@codatemplates/dory-and-pulse

• Turning the Flywheel: A Monograph to Accompany Good to Great: https://www.amazon.com/Turning-Flywheel-Monograph-Accompany-Great/dp/0062933795/

• Waking Up: A Guide to Spirituality Without Religion: https://www.amazon.com/Waking-Up-Spirituality-Without-Religion/dp/1451636024

• The Inner Game of Tennis: The Classic Guide to the Mental Side of Peak Performance: https://www.amazon.com/Inner-Game-Tennis-Classic-Performance/dp/0679778314

• Good Strategy/Bad Strategy: The Difference and Why It Matters: https://www.amazon.com/Good-Strategy-Bad-Difference-Matters/dp/0307886239

• The Last Dance on Netflix: https://www.netflix.com/title/80203144

• Full Swing on Netflix: https://www.netflix.com/title/81483353

• Stephen Curry: Underrated on AppleTV+: https://tv.apple.com/us/movie/stephen-curry-underrated/umc.cmc.23v0wxaiwz60bjy1w4vg7npun

• Arrested Development on Netflix: https://www.netflix.com/title/70140358

• Shishir’s interview question clip on TikTok: https://www.tiktok.com/@lennyrachitsky/video/7160779872296652078

• The Ultimate Reference Check Template: https://coda.io/@startup-hiring/reference-checks-template

• SwingVision: https://swing.tennis/

• Waking Up app: https://www.wakingup.com/

—

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.

—

Lenny may be an investor in the companies discussed.

Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe