What sets great teams apart | Lane Shackleton (CPO of Coda)

0:00

Moments that stretch you or moments that you feel  uncomfortable in or you find yourself saying, "Oh shit.

0:06

I shouldn't be here," or, "I'm under  qualified to be here," those are the moments you should be seeking out.

0:11

Those are the moments  that stretch you and give you a new foundation.

0:18

So oftentimes you'll hear a career question  like, "Hey, do you feel like you're growing in your role?"

0:23

And that's a very ambiguous, in  my opinion, way to ask this question.

0:23

A much sharper way is like, "Hey, how many, oh shit  moments have you had in the last six months, year, two years, and what are they?"

0:33

I think if  you ask yourself that question and the answer is, "It's been a really long time since I've been  stretched in some meaningful way or I've felt like I'm under qualified to be there,"  then it may be worth digging into.

0:50

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.

0:59

Today my guest is Lane Shackleton.

0:59

Lane is Chief  Product Officer at Coda where he's held the role for over eight years.

1:04

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.

1:13

Lane is an incredibly deep thinker, very first principles oriented, and has built an incredible  product team and culture at Coda.

1:19

In part, he's done that by studying the principles and  rituals of great product leaders and great product teams.

1:29

In our conversation, Lane shares what he's  learned, what he's found great PMs and great teams do differently.

1:34

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.

1:44

I could talk to  Lane for hours, but we tried to keep this to under an hour and a half.

1:49

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

1:55

This episode is brought to you by Eppo.

1:55

Eppo  is a next generation AB testing platform built by Airbnb alums for modern growth teams.

2:00

Companies  like DraftKings, Zapier, ClickUp, Twitch and Cameo rely on Eppo to power their experiments.

2:07

Wherever  you work, running experiments is increasingly essential, but there are no commercial tools  that integrate with a modern grow team stack.

2:16

This leads to wasted time building internal tools  or trying to run your own experiments through a clunky marketing tool.

2:20

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.

2:30

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

2:40

Eppo lets you go beyond basic click through  metrics and instead use your north star metrics like activation, retention, subscription and  payments.

2:45

Eppo supports tests on the front end, on the backend, email marketing, even  machine learning claims.

2:51

Check out Eppo at geteppo. com. That's geteppo.

2:55

com  and 10x your experiment velocity.

3:03

This episode is brought to you by  Vanta, helping you streamline your security compliance to accelerate your growth.

3:06

Thousands of fast-growing companies like Gusto, Calm, Quora and Modern Treasury trust Vanta to  help build, scale, manage and demonstrate their security and compliance programs and get ready for  audits in weeks, not months.

3:17

By offering the most in-demand security and privacy frameworks such  as SOC2, ISO 27,001, 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.

3:40

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

3:44

For a  limited time Lenny's Podcast listeners get $1,000 off Vanta. Go to vanta. com/lenny. That's  V-A-N-T-A.

3:49

com/lenny to learn more and to claim your discounts. Get started today.

3:58

Lane, thank you so much for being here. Welcome to the podcast. So glad to be here. Thanks for having me.

4:09

It's absolutely my pleasure.

4:09

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.

4:18

And  so I am really excited to have you on here and learn from what you've learned over the years.

4:22

My  first question is completely unrelated. I have to ask.

4:28

Your last name's Shackleton.

4:28

Any relation  to a certain very famous Antarctic explorer? Yeah.

4:36

It's probably distant at best. I wish it  was close.

4:36

I wish I could claim it was my father or grandfather.

4:41

But I definitely grew up with  those stories and reading a lot about him as a kid.

4:46

In high school we read Endurance, which  is a great book if you haven't read it. It's an amazing story.

4:52

Very inspiring how he put people  first and brought back all of his men from this journey to the South Pole.

4:58

So have 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.

5:06

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

5:11

Low chance of survival, incredibly hard, chance for  glory if you succeed, something like that. It's a wonderful ad.

5:23

I think I had a  mug of that when I was a kid. Yeah. Amazing. Okay.

5:28

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

5:33

Was that inspired by this legacy?

5:33

And also  why did you decide not to pursue that and get into product management?

5:40

Completely different life. Yeah. Yeah. Very, very different. Very different time.

5:45

Didn't have kids back then.

5:45

I think I was  convinced at the time I wanted a career outside.

5:52

Just loved spending time in the mountains  and climbing, things like that.

5:52

To be honest, I wasn't the best guide.

5:57

There were a lot of  amazing guides out there that just had ...

5:57

They were almost invincible in terms of their ability  to climb for 20, 30 hours.

6:06

But I learned a lot from the experience and maybe the quick story  on why I stopped guiding.

6:11

I was on what is a dream trip for mountain guides, which is we were  flown to a remote portion of southeast Alaska.

6:27

It's an hour long flight.

6:27

Mountain called Mount  Fairweather.

6:27

Beautiful 15,000 foot peak.

6:27

And as a part of climbing on glaciers one of the things  that you do for context is you're roped to another person.

6:39

And the reason that you do that is  because if someone falls in a crevasse, you want to be able to stop them or pull them out.

6:44

So I was roped to a very nice client that I was guiding and he fell pretty close to the top on our  way down.

6:52

And luckily we were able to self-arrest and arrest that fall.

7:01

But I spent probably the  next six hours walking down that mountain thinking the same thing over and over again, which is  I really don't want to die roped to someone that I barely know and don't trust or love.

7:14

So  that was the last season that I guided.

7:14

But tons of great memories and learnings and I think it  impacted my life in a pretty significant way. Damn.

7:29

Software much lower stakes.

7:29

I  guess just while we're on this topic, is there any parallels or big lesson you learned  from that experience that you bring to product? One is just preparation.

7:37

I think when you go  climbing or when you guide climbing, you spend months and months preparing for usually a few days  of climbing.

7:44

So there's that kind of preparation.

7:52

There's also just a million checklists.

7:52

So before  you go on an expedition, you may check a checklist of all your equipment, stuff like that a dozen  times or more.

7:57

So you ensure redundancy across all your systems.

8:04

So that was definitely a parallel.

8:04

The other thing I think about a lot is just how to stay calm in challenging or scary scenarios.

8:10

We had another instance where I had a client pull a big chunk of rock off and break their feet  and I was 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."

8:34

Put him on his back and we basically took turns carrying him out for a couple miles I'll just  never forget instances like that where the clarity of stay calm, assess the situation, prioritize,  take action.

8:47

There's a mini version of that when you're building software, I think.

8:58

So experiences  like that, I think, even though I only did it for a handful of summers, were pretty profound. Yeah.

9:03

What a very different life that life path would've been. Pre kids. Yeah. Oh, man.

9:12

So you mentioned your writing, you  mentioned that this is something you want to write about.

9:16

Shifting to the core topic of our  chat, it's very clear that you spent a lot of time studying how great product managers operate  and how great product teams operate.

9:21

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

9:31

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.

9:36

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

9:41

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

9:45

What pulled you into spending so much time and effort trying to understand  how the best teams and people operate? Yeah. Yeah.

9:53

I've been asking myself that question  a little bit lately. There's a few reasons.

9:53

One reason is I just found myself giving a similar set  of advice in one on ones.

10:02

And so I think anytime you find as a leader yourself repeating the same  lessons, it should be a good flag to say like, oh, I should probably scale this in some way.

10:17

And  as you know, as soon as you write something down, you have to clarify your own thinking and so  it becomes very useful for that.

10:24

And I don't think I quite expected how useful it would be  in that sense.

10:28

Writing something down and then putting it out there, you start to get feedback  back of where you might've been right or where you might not be right.

10:39

And so for me it's been  a good learning experience there as well.

10:39

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

10:45

Most companies have career ladders with 10 or 15 levels  and as soon as they hit some scale levels, there's levels between levels and I feel  like I looked at the one at Google and you needed a PhD to decipher it and  interpret how to operate within it.

11:11

And so that's one piece of the construct.

11:11

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.

11:23

And so I found that I basically wanted to have  a broader set of principles that transcended level.

11:31

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. That's one.

11:42

I won't rant further  on that but I think that's one piece of it.

11:49

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 like a prototyper  thinker.

11:57

May have heard of his work.

11:57

He has this talk called Inventing on Principle.

12:02

And in the  early days of Coda, one of our first designers, this guy Jeremy Britten, showed this talk to the  company and my mind was blown.

12:07

And I think it was one of those examples of someone developing a  clear view of what principles they should operate with and then following that principle.

12:22

And it  was just a meta example of how important it is and how impactful it can be when you decide on a  principle and then follow it.

12:30

And so ever since then I've been thinking what are my principles  as it pertains to building software and other things.

12:42

So those are the three reasons that  led me to start writing these things down. Amazing.

12:49

We're going to find that talk and  link to it in the show notes.

12:49

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

12:57

Would it be better to talk about that later after we go through some of these  things or is there something you want to share first of just how you think about it at Coda?

13:03

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 flip from being company focused to being individual focused.

13:23

So I think we delayed it  for a good bit of time.

13:23

There came a time where we decided, "Hey look, we really do need to provide  better guidance here about what it means to grow and what it means to be great."

13:38

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.

13:43

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.

13:54

And I think  that we've done a really good job of that over the years.

13:59

So levels aren't by any means at the  forefront of any company discussion.

13:59

In fact, we don't use titles that much.

14:07

You said that it's not specific to role.

14:12

Do you mean the same leveling attributes are the  same from design and product and engineering?

14:19

We basically have five levels and we call  them role stages and they go from apprentice to principal. So apprentice is ...

14:25

Rope analogy  here is learns about rope.

14:25

Practitioner is can tie basic knots, shown complex knots.

14:34

Given a problem,  they can do it.

14:34

Career is you can calculate rope strength.

14:42

You know a lot about knots.

14:42

Principal  is basically invented nylon.

14:42

So the bar is really, really high for principal in these levels and  I think that that's appropriate.

14:50

It should be aspirational that the bar is exceptionally high  at the highest level of our role stages.

14:58

I find it's a pretty good process to draw maybe a  little bit of contrast with other companies.

15:11

I think most other companies, especially large  companies have 10 to 15 levels.

15:11

I think we've made a really conscious choice to have only five.

15:16

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

15:23

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.

15:36

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.

15:49

So those are some differences. Super cool.

15:49

I've never seen it done this way before.

15:54

I think it's an awesome example of first  principles thinking, which I see a lot come out from your product team.

15:58

And then just to make  sure I heard you right, these five stages are roughly the same across role, so designers have  the same five and they're described similarly. That's right.

16:08

They're described similarly at a  high level, but then the specifics if you get into it are a little bit different. Okay.

16:12

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

16:16

But one other very tactical question.

16:20

At what size of product teams, say just PMs,  did you start to develop this framework?

16:26

We were probably at 20-ish PMs  and designers when we did that. Awesome. Okay.

16:30

So let me just ask, what are  some of these principles you've narrowed it on as principles of great product managers?

16:35

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

16:41

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

16:49

And if you think about the job of a product leader or a product manager, everything is  ambiguous all the time.

16:56

It's like what's my role on this team?

17:04

What problem are we solving?

17:04

Who's  the target customer?

17:04

What prototype is going to solve this particular problem?

17:10

So it's literally  everything.

17:10

And so if you're going to do the job well, you really need to get good at spotting  ambiguity and turning it into clarity.

17:15

And so the obvious question that follows from that is okay,  great, that sounds like a great Hallmark card, but how do you actually do that?

17:30

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

17:36

They're my take on how to do this.

17:36

So the first one that I wrote about was systems not goals.

17:44

And one of the ways that I started this  post ...

17:44

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.

17:56

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

18:01

But the story goes, he's done Seinfeld the show  and he's got all this material from the last 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."

18:15

And this is unheard of in  comedy for someone to just throw away all their old material and start fresh.

18:21

And so the question  is what does he do next?

18:21

And the thing that he does is he sets a goal, which is basically  to build up to an hour of material again.

18:34

But the goal isn't that important.

18:34

What's  important here is the system.

18:34

So the system that he uses is he writes for an hour every morning,  doesn't write for more if he doesn't want to, and then he goes and performs at night.

18:46

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.

18:58

And so I think that I take a lot of  inspiration from that and I think product people can generally, which is instead of being obsessed  with the goal, be obsessed with the system that gets you there.

19:10

And so the phrase I sometimes  use is goals with good intentions don't work.

19:17

I really need to give a common example.

19:17

A really  common example is teams that are trying to learn about customers or do research.

19:24

And 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 OKR.

19:31

And then if you watch closely, the next quarter, they may  not have a goal of talking to customers anymore.

19:45

And so their learning is going up and down.

19:45

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

19:53

Every few times a week they're talking to customers for whatever  reason.

20:00

And the impact of that is really hard to see until you understand that the latter team  tends to have really good product instincts or really good customer instincts.

20:13

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

20:18

And in the early days of  Coda, we actually did something similar.

20:18

We had a time allotted on Fridays and it was basically,  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.

20:35

And so sometimes we'd be scrambling the  three hours before to have a prototype ready for a customer.

20:42

Sometimes we would've had something  that we've been baking for a while.

20:42

But the point is that it was default on.

20:48

And so the way that  we developed good customer instincts was not the goal, it was really just the system behind  it.

20:55

So that's one that I'm passionate about and I think it also translates into a lot of  the rituals that we talk a lot about.

21:06

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

21:06

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 a community person find someone in  San Francisco that's a host.

21:15

And there's no agenda, it's just let's have lunch and meet  the team.

21:19

Curious what you're wondering. Exactly.

21:22

And Airbnb hosts are always so nice and has such a pleasant experience.

21:24

Also makes me think about  this book, The Score Takes Care of Itself. Yep. Have you read that? Yeah.

21:31

Where it's just do the fundamentals and you'll win? Totally.

21:34

The other thing it reminds me of is I have this  quote hanging in my office here.

21:34

I Believe it's from the Rick Rubin book.

21:39

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.

21:49

I feel like you just changed art- Yeah. Rick Rubin's amazing. Oh my god, it's so good.

21:52

Just every  section is this quotable thing I want ...

21:55

I need to hold onto this thing. Yeah.

21:55

He's got a great thing on listening.

21:55

I really admire what he says about listening  and I think that a lot of PMs could take that lesson, which is- Yeah. What is that lesson?

22:10

The way he talks about it is essentially  you want to listen and absorb every fragment of what that person is saying, including  their body language and everything else, and try to turn off the side which is crafting  your response or figuring out what you're going to say next or what the problem with their  argument is or whatever. It's quite hard to do.

22:37

Because your default mode is always the next  step of the conversation.

22:37

But I think if you can really challenge yourself, like he says, to pause  and really try to internalize holistically what that person's saying, it's pretty powerful.

22:52

I was actually just reading that chapter and the next chapter is about this idea of the beginner's  mind.

22:56

I don't know if you remember that.

22:56

I feel like people get sniped by Rick Rubin stuff.

23:01

But  anyway, I'm going to go down this thread.

23:01

He talks about how AlphaZero or AlphaGo, the first  AI thing that beat humans at Go and how there was this move it made, move 37 in the game that  was just like ...

23:13

The person the AI was playing walked out of the room.

23:19

He's like, "I don't even  know what just happened.

23:19

This is out of anything I've ever imagined." And it won.

23:23

And the lesson  there 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.

23:32

And  so it's a really good example of the power of coming from a beginner's mind and not being  influenced by what's already been done. Yeah.

23:41

We have a walkthrough ritual that we do. Tell me more.

23:46

The prompt is essentially put yourself in the  shoes of someone who knows nothing about this topic whatsoever and have beginner's mind and then  walk through with five or 10 people watching you and let's fix all the problems that we see. Okay.

24:01

I want to talk about rituals.

24:01

We're getting ahead of ourselves a little bit.

24:07

Is there any  other principles that you can share either just on a high level or in depth that you've come across?

24:12

And I know people can go to your Substack and read this.

24:17

And by the way, what's your Substack  URL for people that want to check it out? Just lane. substack. com. Sweet.

24:20

We'll definitely link into it. Yeah. Any other principles?

24:24

I think the other one is cathedrals, not bricks, and then the other one is proactive,  not reactive.

24:30

Cathedrals, not bricks I think is a classic one.

24:38

I think I had a moment of realization  and talking to Shishir in a one-on-one when I was at YouTube bemoaning the fact that my team  wasn't performing to the potential that I thought they had.

24:49

And he had a very pointed  and unexpected question, which is like, "Do they know their cathedral?

24:55

Do they have a  cathedral?"

24:55

And I'm sitting there like, "Man, what are you talking about?

24:59

We're talking about  performing as a team and you're asking me about cathedrals."

25:05

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

25:05

In that- What's the cathedral story? It was quite clarifying. Yeah. Do share. Yeah.

25:13

The cathedral story is basically you walk up to three people, they're laying bricks.

25:16

You ask  the first person, "What are you doing?"

25:16

They say, "Well, I take the bricks from over here and I put  them on that sack over there."

25:23

You ask the second person, "What are you doing?"

25:28

They say, "Well,  I take this little cement and I put it on top of the brick that that person lays."

25:32

You ask the  third person, "What are you doing?"

25:32

And they say, "Well, we're building a cathedral."

25:36

And the core  insight here is that you want your teams to feel like they're building a cathedral and not laying  bricks.

25:43

And I think it's really, really easy to do when PMs are really busy on a day-to-day  to just be one task after the other, really execution oriented and maybe not take the time  to help the team take a broader frame, open the aperture a little bit and have a view of what the  cathedral is.

26:03

And I think we've learned many times that one unexpected bit of this is that everybody  needs to see a different facet of the cathedral. So very often ...

26:22

And I've made this mistake  before plenty of times.

26:22

Very often people will do a great writeup on vision or strategy or whatever  it is and the result is people can't quite see their version of what this broader arc is or this  broader cathedral is.

26:38

And so one of the things that we have tried to do when we go through big  planning cycles is show all the different sides of this.

26:52

So instead of just having a writeup, we may  have a writeup, we may couple that with a metric, we may couple that with directional mocks and  what the billboard might look like or how our homepage may change.

27:03

And really what we're  trying to do is take the mystery out of the set of broader constraints or where we're headed.

27:11

I think great product teams and great PM leaders tend to always orient their teams towards a  broader cathedral as opposed to laying bricks.

27:26

Such a beautiful metaphor.

27:26

Reminds me of  this other quote I just looked up while you're chatting.

27:30

"If you want to build a  ship, don't drum up the men to gather wood, divide the work and give orders.

27:33

Instead teach  them to yearn for the vast and endless sea." Classic. Classic. It's Antoine. That is right. Antoine de St. Exupery. Okay.

27:48

Something I was curious about as you were chatting  also is for folks that want to develop their own principles and define how they want to think  about products, is there anything you found to be useful in helping emerge these into principles  that you can come to?

27:56

Is it just sitting around thinking?

28:02

Is there anything else you've done  that has helped you define these things? Probably two things.

28:05

One is reading really  broadly.

28:05

So I think not just reading PM style literature.

28:14

Like I said, I tend to get a lot of  inspiration from outside of tech.

28:14

I think that's one thing.

28:20

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.

28:26

Think about, okay, this person came to me with this challenge. What  was my response?

28:30

Why was that my response?

28:30

Am I giving that response a lot of times?

28:35

Okay, maybe  this is a more deeply held belief.

28:35

So I think noticing those instances was helpful for me.

28:42

Are there any books or topics or areas that you found most inspirational when you talk about  reading and studying other non-product tech?

28:53

I mean definitely sports.

28:53

I would say sports is  really interesting to me. Team sports.

28:53

I've always been a huge fan of everything team sports. Storytelling.

28:59

Go look at some of the best storytellers in the world and they're actually  out there on a stage telling stories.

29:07

There's a book called Storyworthy that I really like.

29:13

I was just going to mention that. That book is so good.

29:16

Somebody mentioned this on the  podcast and I read it.

29:16

It's the most useful practical book for how to tell stories. It's so good. The insight is amazing.

29:21

Just in case your listeners are interested, the  insight is basically the nugget of a great story is five seconds of transformation.

29:30

So  if you just orient everything else around that moment of transformation, then you end up  usually telling a reasonably good story.

29:36

I had a conversation with the author right after  I read that book because I was just totally enamored with it.

29:50

And then we ended up bringing  him into Coda and he gave a great talk.

29:50

So yeah, big plug for Matthew Dicks.

29:55

The other thing that stuck with me also from that same ...

29:59

We're just going on all  kinds of tangents.

29:59

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.

30:10

So I'm watching movies with my wife now, I'm like, "Okay, she's very shy right now.

30:14

She's going to  be very extroverted by the end of this movie."

30:14

Or, "They love each other.

30:18

Oh, they're going to have  a lot of problems." That's so interesting.

30:18

Oh, that's such a good idea.

30:24

Okay, I'm  going to get this guy on hopefully.

30:26

And he's a Moth champion basically. Yeah.

30:26

I would say as maybe a principal version of this, the way that you learn or  the way that everyone including me learns new things is you go seek out the best at that  given craft.

30:42

So in this case, you go to the Moth StorySLAM you see some really good stories.

30:48

If  you ever watch these on YouTube.

30:48

And then you just unpack what they're doing and how they're  doing it.

30:54

And then obviously I think the other way to learn quickly is to throw yourself in the  deep end.

30:59

So insofar as you can put yourself in situations that are uncomfortable or force 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.

31:18

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

31:20

Find the best at all these things  and learn from them, extract and share.

31:24

And the world is much better for it.

31:24

This podcast is an amazing resource. Thanks man.

31:28

You've done something very special. I appreciate it.

31:31

This podcast episode is already  very special.

31:31

The point you just made reminds me of something that I heard you talk about,  which is this oh shit moment.

31:37

I don't know if it's related to what you shared of just giving  people a sense of whether they're making progress in their career. Can you talk about that? Sure. Yeah.

31:46

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

31:51

The basic thesis is that moments that stretch you or moments that you feel  uncomfortable in or you find yourself saying, "Oh shit, I shouldn't be here," or, "I'm under  qualified to be here," those are the moments you should be seeking out.

32:11

Those are the moments that  stretch you and give you a new foundation.

32:11

And so I have found that they turn out to be a pretty  good way to calibrate whether someone is growing in their career.

32:27

So oftentimes you'll hear a  career question like, "Hey, do you feel like you're growing in your role?"

32:33

And that's a very  ambiguous in my opinion way to ask this question.

32:39

And a much sharper way is like, "Hey, how many, oh  shit moments have you had in the last six months, year, two years, and what are they?"

32:45

I think if  you ask yourself that question and the answer is, "It's been a really long time since I've been  stretched in some meaningful way or I've felt like I'm under qualified to be there,"  then it may be worth digging into. That is so good.

33:04

Making me think about this  podcast where I never wanted to do podcasts.

33:09

I'm like I'm not a podcast person.

33:09

I just  want to sit there and type out newsletters. How cool is that?

33:13

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

33:19

It also reminds me of this quote that I  love that I always think back to.

33:19

"The cave you fear contains the treasure you seek." Nice. That reminds me of ...

33:23

Have you read the book The Obstacle is the Way? No. Say More.

33:34

It's a great book by Ryan Holiday.

33:34

And the core  thesis is ...

33:34

It's a bit about stoicism.

33:34

But the core idea is essentially instead of running away  from obstacles, you should be running toward them and that's where you experience either the most  growth or the most profound moments of your life.

33:55

He gives a lot of examples in that book of people  throughout history who made that choice.

33:55

And I think he's also given that talk to hundreds of  sports teams. It's a good book. Worth reading. It's so hard.

34:07

It's so hard to do hard things,  man.

34:07

So we've been talking about principles of great product managers.

34:13

You also spent a  lot of time looking at the rituals of great product teams.

34:16

And I know you're working on  this handbook that I'm excited to learn more about.

34:21

Can you just talk about ...

34:21

I guess one,  where this idea came from of studying rituals of great teams and also just how do you actually  go about learning about these rituals?

34:25

I know you have this really interesting process. Yeah.

34:28

In general, I'm a big believer in good design and good product starts with noticing.

34:36

Tony Fadell has a great talk on this.

34:36

So I think a bunch of us that are really obsessed with rituals,  we just honestly try to be great at noticing.

34:44

So see something happening with a customer, ask a  few questions, get introduced to their team, hear about something interesting from a non-customer,  ask for an intro, end up just probing and asking a lot of questions.

35:05

And then in many cases nowadays  with Coda, we're building new rituals alongside people.

35:13

So someone has a creative idea about how  to implement something and we're like partners or collaborators with them on that, which is honestly  incredibly fun to just see people's creativity expressed in a tool and then by extension the  social construct that they exist in.

35:28

So that's a little bit about how we got started in that  whole process.

35:36

And then of course Shishir is writing a book called Rituals of Great Teams so  we've been cataloging those.

35:40

We've been hosting a bunch of rituals dinners where we basically get  people together for a dinner and we usually have three or four presenters at those dinners.

35:51

It's  just a great chance to learn and think about how the engine runs in a lot of these companies.

36:00

What are some rituals that you've learned from these dinners and these and this research  you've done that have really stuck with you? There are so many. It's hard to choose.

36:10

Maybe  I'll choose two that are top of mind.

36:10

One is Dharmesh Shah has this ritual from HubSpot  called flash tags. Have you heard of this? No.

36:24

We've all probably been in the situation where someone gives you feedback and you either  under interpret it or over interpret it.

36:29

And as an organization, I think the core principle here is  like you want to be calibrated on how much to pay attention to a bit of feedback.

36:45

And so he outlines  four flash tags.

36:45

He presented this in one of our dinners.

36:54

And I absolutely love the phrasing of  these as someone who's given a lot of feedback on product stuff in their career. So it ranges from  ...

37:00

I think it's FYI, suggestion, recommendation, plea.

37:07

So FYI is basically like I had a thought,  take it or leave it kind of thing. Suggestion is ...

37:15

And he uses this hill dying metaphor.

37:15

So  is this a hill I'm going to die on?

37:15

And FYI is there's no hill in sight.

37:23

Suggestion is there's  a hill.

37:23

I'm not going to die on it but this is what I would do if I were you.

37:29

You can take  it or leave it.

37:29

Recommendation is I'm climbing the hill.

37:35

I'm not going to die here, but I've  thought about this a lot, so don't ignore this.

37:42

And then the fourth one, plea, is hopefully  rarely used in the organization.

37:42

It's like, I don't like dying on hills.

37:48

That's not what we do  here.

37:48

But this is a pretty good candidate for it.

37:54

You should really trust me.

37:54

And so we have ended  up using that.

37:54

I was actually just at an offsite and someone gave a lightning talk to our team  on how valuable this has been just to calibrate, hey, we got 100 pieces of feedback and there's  one plea.

38:08

Okay, let's spend our time on that.

38:14

Or there's a whole bunch of FYIs. I think  we're fine. Let's keep going. No worries. That's amazing.

38:20

It's interesting  none of them are just do it this way.

38:23

I imagine that's very intentional. Yeah.

38:23

Honestly it's a sign of ...

38:23

In Dharmesh's case, I don't know him super well, but it's  a sign of a really experienced leader to know that scale.

38:36

But every time I look at the scale  and I'm weighing where I am between suggestion or recommendation, I have to giggle to myself.

38:42

And how do you actually use it?

38:42

In the feedback you put a hashtag plea kind of thing?

38:48

The way gets used in code docs and the way I think other companies have made it a ritual is  you'll have a feedback table and you'll write your feedback and then there'll just be a little  select list and you can select between those four.

39:07

And usually what people do is they include  the description so you can as you're choosing it, think do I really feel that strongly about this?

39:16

And honestly, it's good hygiene.

39:16

Otherwise, every bit of feedback is taken the same.

39:24

Which just fundamentally the impact of that is it slows everything down because now you're  looking at a list of 100 pieces of feedback and you're going like, "Oh man, we got to address  all this feedback."

39:36

Whereas as soon as you distinguish between what's most important,  it's much easier to sort through that.

39:46

What about if it's in person?

39:46

Do you  say this is a plea or this is a FYI?

39:50

Oh, I've definitely heard that in many meetings.

39:50

Are you making a recommendation or are you making a plea? Amazing.

39:58

And making the person think through that choice I  think is just a very helpful shared language.

40:04

I 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 taken really seriously and the team's going to rush back and be like, "Oh,  Lane told us to change this thing."

40:12

I imagine it helps you just make it clear.

40:16

No, you don't need  to actually change this. It's just my thoughts. Yeah. Exactly. Yeah. Awesome.

40:21

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

40:27

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.

40:39

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.

40:48

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.

40:55

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.

41:09

Probably because I spend so much  time sitting in front of a computer.

41:09

Half of all men will have cancer at some point in  their lives, as will one third of women.

41:19

Half of all of them will detect it late.

41:19

According to the American Cancer Society, early cancer detection has an 80% survival rate  compared to less than 20% for late stage cancer.

41:30

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 may be what I have, or fatty liver disease.

41:41

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.

41:55

Their scans are non-invasive and radiation free.

42:00

And Ezra is offering listeners $150 off  their first scan with code Lenny150. Book your scan at ezra. com/lenny at E-Z-R-A. com/lenny.

42:08

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 a genius?

42:19

I guess one that I get asked about a lot on our team is called Catalyst.

42:23

And I guess maybe to set  some context on this one, in most product teams, the review forum is just a really important part  of the product development process.

42:31

And the core insight for most review forums or product reviews  or decision forums is that they generally suffer from two problems that are hard to spot unless  you've sat through hundreds of them.

42:47

The first is they have standing attendees, and the  second is they're normally single-threaded, meaning they're normally one topic at a time.

43:00

So maybe I'll talk about both of those because I think they're not exactly intuitive.

43:05

So  when you think about what happens with a standing set of attendees, you either have the  situation where you have too many people in the meeting or you have not enough people in the  meeting, and both of those can cause problems.

43:24

So if you've ever been in a meeting, I  certainly have, where it's like, "Hey, do we have the salesperson who knows most about  this or do we have the engineer who's actually implementing this here? Oh, great. They're not  here?

43:33

They're not a part of the standing set of attendees?"

43:37

You either have to reschedule the  meeting or worse, you just do the discussion without the person who's most knowledgeable, which  seems crazy in retrospect.

43:44

The second problem is single-threaded. So one topic at a time.

43:52

So  if you think about if a product development process is somewhat of a chaotic assembly line for  a second, your review or your decision forum ends up being a big time bottleneck in many cases.

44:07

And obviously you want to be in a situation where product people have a lot of autonomy and  they can make most of the decisions themselves.

44:18

And I'm a big believer in decentralized  leadership and all of that, but there are things that cut across the company that need to  get reviewed by a broader set of stakeholders.

44:28

And so what happens when those things are single  threaded is either the meeting is really long, so it's a three-hour review meeting once a week,  and by the end everyone is about to fall asleep, or it's really short and it's really hard  to get on the calendar.

44:41

You're like, "Oh, can we get on the calendar in two weeks?"

44:45

And  the downside of the not being able to get on the calendar is that now you've just slowed  down the whole velocity of the company because the throughput of your review meeting is really  slow.

44:58

So we built Catalyst to really solve those two problems.

45:06

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.

45:12

So you can get anyone in the company for those three hours.

45:17

And each topic has  essentially four roles.

45:17

Driver, maker, braintrust, and interested.

45:25

It's a very transparent system.

45:25

So a salesperson can say, "Oh, I'm interested in this product development review.

45:31

I'm just going  to mark myself as interested."

45:31

And then the driver is the person who's actually going to drive the  meeting, drive the decision, drive the outcome, things like that.

45:41

And basically, this is all  centralized in one doc.

45:41

And what happens is the day before, that hold that's on calendar gets  removed, and then you have specific topics that get added.

45:55

So there may be three topics going  all at the same time because they don't have overlapping attendees.

46:00

And the impact of this, I  think if you really watch it in progress is huge.

46:11

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 a clear set of drivers and roles in these meetings.

46:24

So that means that we can review  work much, much faster with the right people, and ideally that results in more value to  our customers, more things getting shipped, just a higher velocity organization.

46:36

So  that's one that we get asked about a lot.

46:41

And actually a couple of weeks ago, we spent  a while remaking the template for that one. I love that ritual.

46:45

You actually wrote even in  more depth in the post that we worked together on how Coda 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.

46:54

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?

47:04

How  much 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.

47:15

I think it depends a lot on what your role  in the company is.

47:15

Maybe to say the extremes for a second, if you're a brand new PM to an  organization, you probably shouldn't go try to remake the whole product review cycle that  the head of product is really passionate about and has crafted.

47:32

But you can probably take a  decision template or some interesting ritual that has facilitated a team in the past and use it  with your team.

47:41

Another one of my favorites there is a hundred dollar voting.

47:47

We use that a lot in  the context of planning, and I find that creative rituals like that are easy to pick up for teams  because oftentimes it's like, okay ...

47:53

And maybe I'll describe the ritual real quick. Yeah. I was going to ask.

48:02

The ritual is essentially you can take any set of  problems or solutions or themes or whatever you want to get people's input on, and you put those  into a table and then people can basically vote with their dollars and usually you allocate  $100.

48:17

And so people will go through and say, "Oh, I want to allocate $10 to this and $20 to  this and $50 to this because I think it's really important."

48:28

And I have found that especially in  planning processes, little rituals like this are great at getting the elephant in the room out.

48:37

So  it's like, "Oh wow, we have a huge spread on this one particular problem.

48:44

You think it's a huge  problem.

48:44

I don't think it's a problem at all. Let's talk about it."

48:50

Going back to the thesis  of turning ambiguity into clarity, a lot of this is like we're trying to get the ambiguous stuff  out there so that we can make it more clear.

49:03

And so I use that as an example because you can be  a brand new PM, run a brainstorm, run a planning session like that, and you're probably going to  get great feedback.

49:12

People are probably going to go, "This is cool.

49:16

I've never done this before."

49:16

Now to go to the other side of the spectrum, we help a lot of companies that want to remake  a whole process.

49:22

They want to remake a review system like Catalyst or they want to remake  their decision rituals.

49:29

And so in that sense, we're usually talking to a head of product  or director of product or VP of product and someone who tends to have a lot more  agency over the way that the team works.

49:48

Coda is interesting in that it feels like you  have pretty stable processes for planning and reviews.

49:52

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

49:52

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.

50:01

How much are you radically changing the  way you operate versus working in similar ways?

50:09

How do you think about that percentage wise?

50:09

People are always coming up with new creative ways to make their teams run better, make decisions go  smoother.

50:15

And we're continuously adopting those, but there's definitely a backbone of the system.

50:24

The backbone of the system is Catalyst and tag-ups and the concept called Bullpen.

50:31

And then  there'll be a lot of iteration on top of that.

50:37

And even those systems went through a lot  of iteration.

50:37

I talked about how the calendar hold got removed and then individual topics  got added.

50:42

That took us launching automations and the ability to add things to calendar in  order for that whole process to really work.

50:55

So in the years prior to us launching that, we  did it very manually.

50:55

So I think there's still a lot of creativity that I see every day.

51:04

So I'll give one quick example.

51:04

One of our PM leads on core product, this guy Nathan,  he basically saw that a lot of decisions had a lot of different stakeholders because he's in  the core product.

51:20

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 PMs on who to involve in these decisions?

51:29

Because every one  of these with core product feels like they impact everybody.

51:35

And so a very simple thing that he  did probably in the last six months was he had a table of all the upcoming decisions and then  at a tag-up ...

51:43

Which I can explain if you want.

51:49

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  don't need to be involved.

51:54

Just notify me of the decision after."

52:01

Or, "Hey, I have some opinions,  but you can keep going."

52:01

Or, "No, I really want to be heavily involved in this decision."

52:08

And it was such a pro move.

52:08

It was such a, I've been through a million of these.

52:14

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.

52:20

And so instead, the majority of those, Shishir or I or Oliver,  the head of engineering will say, "I may have some opinions, but keep going."

52:32

That's often the  default.

52:32

And then there are plenty where we say, "Just notify us of the decision after."

52:38

And in  doing that, Nathan can now give better guidance to the PMs on his team and say, "Hey, you don't  really need to involve as wide a group as you think, so just keep going and check in later."

52:49

So I think those types of little iterations are usually based on a really good insight.

52:57

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.

53:04

And that process in which 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.

53:17

Tag-up is based on this insight that a lot of  work and project work tends to get discussed in one-on-ones.

53:25

And actually it's really an  anti-pattern.

53:25

It's a pattern you should try to avoid.

53:30

So if you're talking to your manager  about product work, what's not happening in that moment is your eng lead and your design lead,  they're not hearing that.

53:36

And so you end up with this big game of telephone where you'll have  a conversation with your manager in a one-on-one, they'll go back and translate to their engineering  and design lead, and of course the fidelity of the game of telephone, something is lost in all  of those transmissions.

53:54

And so the core idea is have a group one-on-one with the key stakeholders.

54:02

And so we have this concept of braintrust that's modeled off after Pixar's braintrust.

54:08

And so we'll have a tag-up with a small set of people from a given team,  or sometimes we have larger groups, and then they meet with their braintrust and  it's once a week.

54:20

It's the same mindset of a one-on-one. It's their time.

54:28

So anything that they  need to unblock a decision or to make progress, they should use that time for.

54:35

And they often  start by reviewing OKRs and metrics and things like that.

54:39

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

54:39

Those topics are up voted, so people will react and then the  table will sort itself.

54:47

And then we'll say, "Okay, this is clearly the topic on people's mind."

54:53

And that's a version of what we call Dory, which I can talk about.

54:59

But essentially the  principle is you should discuss that project work with the whole group there.

55:07

With the whole triad  there.

55:07

And oftentimes with the sales person there and with the marketer there and with everybody  else.

55:13

So I found that that is just a really good practice to try to move a lot of that work out  of one-on-ones and into a small group setting. Awesome. Okay.

55:26

So you're working on  a handbook that's collecting a lot of these rituals.

55:31

Talk about that and then  when can people maybe look for it?