0:00

Hello and welcome to this week's episode

0:02

of The Product Experience. This

0:04

week we talk to product legend and

0:06

author Matt LeMay all about the importance

0:08

of Impact First product teams, which just

0:10

also happens to be the title of

0:13

his brand new book. Watch

0:15

or listen on to find out more

0:17

and while doing things the right way

0:19

isn't always the best way. The

0:26

Product Experience podcast is brought to you

0:28

by Mind the Product, part of the

0:30

Pendo family. Every week we talk

0:32

to inspiring product people from around the globe.

0:35

Visit mindtheproduct .com to catch up

0:37

on past episodes and discover free

0:39

resources to help you with your

0:41

product practice. Learn about

0:43

Mind the Product's conferences and their

0:46

great training opportunities. Create

0:48

a free account to get product inspiration delivered

0:50

weekly to your inbox. Mind the product

0:52

supports over 200 product tank meetups from

0:55

New York to Barcelona. There's

0:57

probably one near you. Matt,

1:06

thank you so much for joining us on the podcast.

1:08

How are you doing today? I am doing well. How

1:10

are you? Doing all right.

1:12

It's exciting. You're a returning champion. We've

1:14

had you on before. returning, whether or

1:16

not a champion. We'll

1:19

leave that one to the audience. But

1:21

you're back because you wrote a new book.

1:24

So for anyone who doesn't remember you from

1:26

last time, can you just do a quick

1:28

introduction? What do you do these days?

1:30

How did you get into product in

1:32

the first place, the short version? Sure.

1:34

Let's talk about the book. So my

1:36

name is Matt LeMay. I work with

1:38

product teams to help them do things

1:40

that matter. I got into

1:42

product by accident a million years

1:45

ago. As

1:47

many of us did, I was a musician

1:49

and music writer and I was living in

1:51

New York and wanted to move out of

1:53

my mom's apartment. So I got a grown

1:56

up job in tech and that grown up

1:58

job was accidentally that of product manager. And

2:00

here I am 15 years later, still doing

2:02

this stuff and talking about it. So I

2:04

guess it was a happy accident. And

2:07

this is your back today to talk about your

2:09

new book, which I'm going to hold up to

2:11

the camera impacts first product teams. Not to make

2:13

you feel left out. Oh,

2:19

Oh, what a cursed image. Here

2:21

we go. But

2:23

this is, this is your fourth book,

2:26

am I right? If you count the

2:28

33 and the third about Elliot Smith,

2:30

which I know you do, then yes,

2:32

my fourth and one of them is

2:34

in a second edition. So my fourth

2:36

and a half. I'm

2:39

the Federico Fellini of product

2:41

management books minus four. I

2:45

think slightly less inscrutable. This book is

2:47

very screwtable, very easy to understand. So

2:51

let's talk about the genesis of

2:53

this. So impact first product teams.

2:55

So for years, we've talked about

2:57

things like North Stars and outcomes

2:59

over output and impact mapping. And

3:01

we map things to make sense

3:03

of them, KPI trees, all this.

3:06

Is this any different? What's

3:08

the fundamental basis behind impact

3:11

first product teams? So

3:13

I'm really. Glad you asked that because

3:15

I think there's a thing that I

3:17

didn't realize until I was working with

3:19

an organization a couple of years ago

3:21

when at a certain point it

3:23

became clear that their objectives and

3:26

their initiatives were misaligned. They had

3:28

objectives which were like OKRs and

3:30

they had initiatives which were sort

3:32

of broader sets of

3:34

resources devoted to solving certain

3:37

problems. And I

3:39

sat down with their leadership and I said, all right, well,

3:41

we've got a misalignment here. So we

3:43

have two options. One is we

3:45

can kind of map these things to each other and say

3:47

it's not a one to one fit, which

3:50

saves us a little pain now, but

3:52

probably creates more pain later. Or

3:54

we can say, look, we need these to

3:56

be the same thing. We can't add any

3:58

additional layers of kind of translation. It's

4:01

hard enough for people to know what they're expected to

4:03

do anyhow. So we can turn

4:05

these into one thing, have some pain now and have

4:07

less pain later. What I

4:09

did not know is that they

4:11

did the secret third thing of

4:13

adding bets. So we

4:16

now had bets and objectives

4:18

and initiatives. And

4:20

I cite that example

4:23

because it illustrates to me

4:25

that the way we've approached

4:27

a lot of these challenges

4:29

to add more layers in

4:31

the middle. to add more

4:34

abstractions to cascade things further

4:36

and further and further. Add

4:38

another layer of OKRs. Add

4:40

another tool or approach until

4:42

the point where we start

4:44

making impact maps rather

4:46

than making impact or

4:48

doing OKRs rather than

4:50

actually delivering work. I

4:53

have a whole set of

4:55

pretty strong feelings about the

4:57

phenomenon of OKR season and

5:00

how it's just so

5:02

bizarre that teams will go through a

5:04

once a quarter exercise of pretending to

5:06

care about what their goals are by

5:09

adding more and more meaningless goals and

5:11

then putting those meaningless goals away on

5:13

a shelf until the next quarter when

5:15

they need to pretend that they were

5:18

meaningful and then set the next quarter

5:20

of meaningless goals. So I think the

5:22

short answer is our approach to a lot

5:24

of these things has been to add more

5:26

stuff in the middle. between the

5:28

success of the business and the

5:30

work of our team. And I

5:32

wrote this book as a way

5:34

to draw a direct line between

5:36

those things, regardless of what particular

5:38

steps your team or organization chooses

5:40

to use in the middle. So

5:42

whether using OKRs or bets or

5:44

initiatives or V2MOM, which is a

5:46

sales force thing, whatever

5:48

it is, like, it's fine. You can do this

5:51

however you want. But at the end the day,

5:53

you still need to be able to answer the

5:55

question quickly and. comprehensively of

5:57

why the work you're doing is

6:00

to the business at large. So

6:02

it kind of sounds like

6:04

what you're saying people suffer

6:06

from is they're getting caught

6:09

up in the process of

6:11

goal setting without remembering what

6:13

the purpose of goal setting is

6:15

for. I think

6:17

this has been kind of the cardinal

6:20

sin of product discourse for the last

6:22

10 years is that we've been so

6:24

caught up in best practices and this

6:26

question of how do you do this?

6:28

How do you do that? That we've

6:30

largely lost sight

6:32

of what. these tools and

6:34

techniques are actually intended to

6:37

accomplish. I think if

6:39

you look at the way that OKRs have

6:41

been deployed, that's a great example, right? I

6:43

like OKRs because they're at their best a

6:45

really simple mechanism for having a qualitative objective

6:47

and quantitative measurable goals. I like that. You

6:49

get the quantitative goals. You get a qualitative

6:52

objective where you can systematize them, which I

6:54

think is really valuable. Boom. But I've worked

6:56

with so many teams were like, okay, well,

6:58

we have to have three to five objectives

7:00

and then three to five key results per

7:02

objective. And the score of each one

7:05

should be a six or seven.

7:07

And they sweat the details of

7:09

the process as if executing the

7:12

process correctly. And, you

7:14

know, these are all made up things, but as if

7:16

somehow. There's this talismanic

7:19

power to following best

7:21

practices, which takes away

7:23

the responsibility of the team to actually

7:25

say, yeah, we may have gone

7:27

step by step through the process,

7:30

but does it actually help?

7:32

Do we know what success looks like?

7:34

Are we delivering success for the business?

7:37

You know, I still, when I get brought on by teams,

7:39

the first question I'm

7:42

usually asked is something around, can you

7:44

help us? implement OKRs? Can you help

7:46

us do impact mapping? Can you help

7:48

us adopt a product operating model? And

7:51

those things are all great.

7:54

But at the end of the day, if you go to

7:57

a product team and say, why

7:59

does your work matter to the business? And

8:01

their answer is consult page seven of our

8:03

OKR deck, then they don't really have an

8:05

answer. I love that. My

8:08

consulting is similar in that it's usually

8:10

symptoms that I'm brought in for and

8:12

I want to focus on root causes.

8:15

Well, the thing that I think is

8:17

really funny when it comes to impact

8:19

is that treating the symptoms sometimes makes

8:21

the cause worse. I've

8:23

worked with teams that'll spend six

8:25

months evaluating road mapping tools. It's

8:28

like all that time you spent evaluating road

8:31

mapping tools is time you didn't spend actually

8:33

delivering customer -facing work. It's

8:35

time you didn't spend learning

8:38

how roadmaps work in your

8:40

particular organization. It's

8:42

work that you can control that

8:44

creates the illusion of progress, but

8:46

it doesn't actually deliver value for

8:48

the business. And that

8:50

work is often really tempting. It gives us

8:52

a sense of progress. It gives us a

8:54

sense of control. It's easier work to do,

8:57

but the more we do those things, the

8:59

farther away we get from doing work

9:02

that actually matters to the business. You

9:05

talked earlier about the definition of

9:07

success for a team. Before

9:10

we get to that, can we just

9:12

talk briefly? Who is in the team?

9:14

Is it a product manager and some devs

9:17

and a designer? Is it

9:19

oriented around the goal? What is a

9:21

product team? I mean,

9:23

short answer, it depends. But

9:25

the way I generally think about

9:28

it, the reason I focus this

9:30

book on product teams, not product

9:32

managers or product management, is that

9:34

the decisions that are

9:36

made to deliver impact are made

9:38

by everybody who touches a product,

9:41

right? They're made by

9:43

devs, by designers, by product managers,

9:45

by marketers, by salespeople, everybody

9:47

who is making decisions that affect

9:49

a product should be making those

9:51

decisions based on what success for

9:54

that product and that team looks

9:56

like. One of the things I found,

9:58

you know, a lot of the reason I wrote this book is that

10:01

the most impactful work I've done

10:03

over the last few years has been

10:05

helping teams set goals that are specific

10:07

enough to drive decision making and important

10:09

enough for the business to care about

10:11

them. And one interesting

10:13

thing that happens when you set goals

10:16

at that altitude and that specificity is

10:18

suddenly If you have a product

10:20

team that's just a product manager and a few

10:22

devs, they say, well, we can't be responsible for

10:24

this because we have to work with marketing or

10:26

we can't do this ourselves. We need this other.

10:28

We have dependencies on other teams. And I'm like,

10:30

yeah, you do. That's true.

10:33

Doing things that matter usually

10:35

means navigating dependencies. If you

10:37

optimize your work for minimizing

10:40

dependencies, it is very unlikely

10:42

that you are optimizing your

10:44

work for maximizing impact. So

10:47

I think that. One

10:49

of the interesting things that's come up in doing

10:51

this work is that another thing folks really tend

10:53

to focus on is the org chart Who is

10:55

on the team who's outside of the team? How

10:58

are these teams organized? Those are good questions, but

11:00

at the end of the day I've

11:03

never worked with an organization where there's a

11:05

rule that says you can't talk to someone

11:07

from marketing if they're not embedded in your

11:09

team. It can be annoying to talk to

11:11

somebody from outside of your team whose incentives

11:14

are different from yours who, again, has their

11:16

own definition of success that might be outside

11:18

of your team's definition of success. But

11:21

at the end the day, I think part of the

11:23

reason this kind of impact first thinking

11:25

is so important is that small

11:27

teams or isolated or autonomous teams

11:30

often won't work outside of the

11:32

team unless they have a really

11:34

good reason to do so. And

11:38

a really important, really specific

11:40

goal is a good reason to do

11:42

so. So I

11:44

think it's really interesting how

11:46

you're talking about the sort

11:48

of impact first model that

11:50

you've described, and then

11:52

teams, you know, being made up

11:55

of various different functions. and

11:58

you know you can have that sort of like

12:00

narrower team directly committing to

12:02

a certain impact or whatever

12:04

or maybe to an objective

12:07

or whatever it is. I

12:10

think where it gets really tricky

12:12

and I've seen lots of businesses

12:14

and teams struggle with this is

12:16

where teams own a

12:18

certain objective or goal or

12:20

something. And then, like

12:22

you say, other teams are owning other

12:25

objectives or goals. And everyone's

12:27

kind of working in silos,

12:29

if you like, against their objectives. And

12:32

I think that that causes

12:34

problems with whose objective is more

12:37

important than, you know,

12:39

or is the most important and how

12:41

do we work together as an overall

12:43

organization. I mean,

12:46

I've only ever worked in

12:48

smaller organizations. So I can't

12:50

imagine it must be like... in

12:52

larger organizations, or maybe it's

12:54

fine because it's departmental. But

12:56

like, what's your sort of

12:58

solution for juggling that in

13:00

terms of like having the

13:02

much bigger teams and more

13:04

focus on a variety of

13:07

impacts that need to be

13:09

not delivered, but kind of

13:11

worked on. So

13:14

my answer to that. actually comes

13:16

from Christina Wadke's book, Radical Focus, which

13:19

was a huge inspiration for this book.

13:22

And Christina blurbed it on the back, which

13:24

I'm like, I'm done. I did a good

13:26

job. Don't have to do anything else. But

13:28

there's a graphic she puts in that book,

13:31

which I reproduce here, which essentially

13:33

says, rather than thinking about goals as

13:36

a cascade, you should think of them

13:38

as an orbit. So in

13:40

a lot of big organizations, the way it works

13:42

is you have the team, you know, the company

13:44

level goal, then the department goal, the big team

13:46

goal and the small team goal and the individual

13:48

goal. And when I've worked with companies like this,

13:50

one of the first questions I usually ask is,

13:52

okay, show me how all

13:55

the lowest level goals add up to the

13:57

highest level goals. And that's

13:59

an absurd question in a lot

14:01

of cases, because when you have,

14:03

you know, a hundred small teams,

14:05

you can't look like. Nobody

14:07

knows. Nobody knows if each of these

14:10

teams achieves their goals that will actually

14:12

add up to success for the business.

14:14

It's just too much math to do.

14:16

And again, you'll wind up consulting slide

14:19

76 of the quarterly OKR document. What

14:22

Christina Wadke recommends is that you

14:24

think of every team or department

14:26

or individual goals as orbiting around the

14:28

company goals. So no more than one

14:31

step away from company goals. you

14:34

know, if you're looking at a revenue goal, for

14:37

example, then you could have one team that's responsible

14:39

for revenue per user and another that's responsible for

14:41

the number of users. You could have different teams

14:43

that are responsible for growing users from different segments.

14:46

But the idea is that if you look at

14:48

them together, you're never more than

14:50

one understandable step away from translating it

14:52

into the terms that matter most to

14:54

the business. And I like that because

14:56

it gives you a chance to actually

14:59

look across teams and say, These

15:01

goals are in conflict with each other, or

15:03

these goals are in harmony with each other,

15:05

or, hey, we've got one team of five

15:07

people that's supposed to contribute $10 million of

15:09

incremental revenue, and one team of 10 people

15:11

that's supposed to contribute $1 million of incremental

15:13

revenue. Do we take some of the people

15:15

from that 10 -person team and put them

15:17

on the five -person team? When

15:20

you have different team goals expressed

15:23

in terms that level up clearly

15:25

and immediately to a shared set

15:27

of company goals, it's

15:29

much easier to have those conversations. You

15:32

still have to have those conversations, but

15:34

I think that you're able to have

15:37

them in terms that, yes,

15:39

again, they're not easy conversations to

15:42

have ever, but at the very

15:44

least, you can start to make

15:46

more meaningful decisions about how you

15:48

allocate resources, how you prioritize work,

15:50

and how teams work together. I'm

15:53

glad you said they're scary conversations. Oh, they're so

15:55

scary. Because it's one of those things. It's

15:57

a very easy thing for you or I

16:00

to say as outsiders to companies. And

16:02

it's an easy thing for leaders to

16:05

say that we should have everything one

16:07

step away. But if you're in

16:09

a company whose culture is to

16:11

cascade these, it's much harder.

16:14

How does a team have the power to step

16:16

away from low impact work? What can

16:18

you talk about a time when you've worked with

16:20

the team and they've had that conversation and they've

16:22

brought that up? How did it go? How did

16:24

they do it successfully? Yeah, I

16:26

mean, I think a lot of this comes

16:29

down to incentives, right? And

16:31

for a long time, I

16:33

think product teams believed more

16:36

or less correctly in most cases that if

16:38

they did what they were told, everything would

16:40

be okay. If executives come

16:42

to you and say, build these 10 features, if

16:44

you say, look, we built the 10 features and

16:47

we thought they would be 100 story points, but

16:49

they were 97 story points. So we finished them

16:51

a week early. Then leadership would say, great,

16:54

you are my magical special product

16:56

team and everyone gets a bonus.

16:58

But due to

17:00

a number, a constellation of

17:03

factors, let's say, I

17:05

don't think that's true anymore. I talk at the

17:07

beginning of the book about the round

17:09

of Spotify layoffs that happened last year when

17:12

about 5 % of the

17:14

company's workforce was laid off and leadership said

17:17

they've been doing low impact work or even

17:19

work around the work. That's

17:21

like somebody came up

17:23

with a strategy of doing that low

17:25

impact work or that work around the

17:27

work. I doubt that these teams said

17:29

we want to do low impact work

17:31

or we want to do work, the

17:34

impact of which cannot be directly or

17:36

easily attributed. So Part

17:38

of what I try to get

17:40

across to teams, and this sounds

17:42

harsh sometimes, but I don't think it

17:44

is, is that you

17:47

are always better off proactively managing

17:49

the conversation about business impact than

17:52

you are waiting until somebody asks

17:54

you. Even if

17:56

it is a cascady kind of

17:58

culture, at some point, you might find

18:00

yourself in a room with somebody several levels above

18:03

the person who cascaded those goals to you, and

18:05

they're gonna say, well, what's the impact of this?

18:08

And if you are in the position, as

18:10

I have been to say, well,

18:13

that's really hard to answer, or

18:15

we can't attribute it,

18:17

or if you look at slide

18:19

62 of our objectives and key results,

18:21

it says that delivering the roadmap is

18:23

one of our objectives, then

18:26

it's just not a

18:28

good position to be in. So I think that.

18:30

Again, part of the reason I

18:33

scoped this book to product teams is

18:35

I actually think that most teams have

18:37

more leverage and more leeway to do

18:40

this than they probably think they do.

18:43

I think a lot of leaders are

18:45

also afraid to name numbers

18:47

and to commit to specific

18:49

impact level goals. I've

18:51

worked with a few teams where, for

18:54

example, I worked with a team that was

18:56

responsible for taking some subset

18:58

of users from the old version of

19:00

an HR management platform to the new

19:02

version they were building. And

19:04

I said, all right, well, how many new users by

19:07

when? And room goes dead silent. Just

19:09

like, we don't know

19:11

what we can say. I'm like, okay, well, then

19:13

how do you make decisions, right? If

19:15

you're trying to get a thousand users on

19:17

the platform next week, that's very different from

19:19

if you're trying to get 10 users on

19:21

next year. How do we know what decisions

19:23

to make? And they looked around

19:25

that, but we can't, we don't know, we have to

19:27

ask. I was like, before you ask, what do you

19:30

think the numbers should be? Knowing

19:32

that this business has made a sizable

19:34

investment in this team, what is the

19:36

outcome where you feel good going to

19:38

leadership and saying, yeah, here's what we

19:40

accomplished. Again, silence. Like,

19:43

all right, end of the quarter, 10, a hundred

19:45

or a thousand. Let's just look

19:47

at some orders of magnitude. We don't have to be precise.

19:50

And one of the engineers on the team

19:52

says, gosh, if we got a thousand users

19:54

onto this platform by the end of the

19:56

quarter, I would feel so secure in this

19:58

team's work. So we called

20:01

a meeting with the CPTO chief product and technology

20:03

officer and said, you know, you haven't asked us

20:05

for a number, but we would like to focus

20:07

on delivering a thousand users onto this new platform

20:10

by the end of the quarter. If we're going

20:12

to do that, we need your support. We need

20:14

to say no to other requests that come in.

20:16

If this is what we're focused on, then this

20:19

is what we're focused on. But we believe that

20:21

if we are allowed to focus on this, we

20:23

can deliver this result for the business. The

20:26

CPTO was like, yes, absolutely. You have

20:28

my support. That number

20:30

sounds great. Let's do it. Again,

20:33

I think people are afraid to be the

20:35

first person or first team to name a

20:37

number, but there is

20:39

power in setting the baseline.

20:42

And I think that when teams reclaim

20:44

that power, they are much better positioned. How

20:47

do you advise kind of product

20:49

teams to develop more of that

20:52

commercial awareness and to... You know,

20:54

it's not always obvious. I think

20:56

in some organizations what is going

20:58

to be the the correct impact

21:00

of focus on. So how do

21:02

they try and discover that for

21:05

themselves? So there's a

21:07

question in the book. The book is structured around

21:09

a number of powerful questions. And

21:11

the first one is if you were the

21:13

CEO of this company, would you fund this

21:15

team? And

21:18

I love that question because it shifts

21:20

the way that a lot of folks

21:22

think from my job is to find

21:24

the next defensible feature to build to

21:27

like, oh, wait, my team cost this

21:29

company money. Maybe

21:31

we need to justify that.

21:33

So I find it an easier way of

21:35

approaching that conversation. You know, I tried to ask me

21:38

a few times like, how much do you think this

21:40

team costs the business? And that just makes everyone get

21:42

really nervous. But when you ask the

21:44

question, like, you know, if you were in charge of the

21:46

company, would you fund this team? It

21:48

kind of shifts their perspective just

21:51

enough to start thinking, oh,

21:54

yes, this team does cost money

21:56

to the business. What does this business

21:58

need from the team? I've

22:00

worked with two teams that have actually

22:03

disbanded themselves after we had that conversation

22:05

because they realized that they would not

22:07

fund this team. and that if they

22:10

didn't make the choice to redistribute themselves

22:12

to higher impact teams, they ran a

22:14

risk of the entire team being in

22:16

a very vulnerable position. So

22:19

I think it's a really tough

22:21

thing to talk about these being

22:24

hard conversations. The

22:26

reality is that your success and

22:28

the success of the business are

22:30

always already intertwined. If

22:33

the business goes out of business, if the business has

22:35

a really rough quarter, That's probably

22:37

not going to put you in a very

22:39

good position. If the business does really well,

22:41

hopefully that puts you in a better position.

22:44

So I think one of the big

22:47

mindset shifts here that's really challenging for

22:49

teams is it's hard to take on

22:51

accountability for things outside of your control

22:53

to say we want to be responsible

22:56

for growth, for revenue, for things that.

22:59

depend upon people outside of

23:01

our control and markets outside

23:03

of our control doing certain

23:05

things. But the reality is

23:07

your fate is already tied

23:09

to those customers and those

23:11

markets. And if you

23:14

can speak to that and

23:16

create reasonable expectations and be

23:18

the kind of source of

23:20

truth on what that connection

23:22

is and how you're managing

23:24

it, it puts you in

23:26

a much stronger position. than

23:28

being in that reactive position when somebody, you

23:31

know, again, I've been there when suddenly you

23:33

have a meeting with someone important. You're

23:36

in a much better position than

23:38

you are if you find yourself

23:40

in that meeting with that senior

23:42

person who is suddenly asking you

23:44

to justify your team's very existence,

23:46

which you might very well be

23:49

at some point. Matt,

23:51

there's lots of teams that...

23:53

are not directly in control

23:55

of things that feel like

23:58

they're impactful. Certainly

24:00

not direct customer impact.

24:03

Let's bring up an example of

24:06

enabling teams or platform teams, teams

24:08

that aren't directly customer facing. I

24:11

know you said there's lots of teams that

24:13

feel like the things are outside their control,

24:15

but these teams are, they're almost B2B to

24:18

C within their own companies. How

24:21

did how should they approach this? I joke in

24:23

the book that the people from these teams haunt

24:25

me at all of my public appearances. And it's

24:27

true, like every time I give a talk, I'm

24:29

like, yeah, I'm on a platform team. So how

24:31

does any of this apply to me? And

24:34

it's a fair question, right? And I think that

24:36

the anxiety, again, when you have folks being laid

24:38

off for doing the work around the work,

24:40

if you're on a platform team, like this question

24:43

of how do I explain the value of what

24:45

I do is a very real, impressive question. The

24:48

way I think about it is

24:50

that. If you are on a

24:53

platform or supporting team that is

24:55

not delivering direct customer -facing impact,

24:57

then you are ideally an amplifier

24:59

of direct customer -facing impact, which

25:02

is to say, rather than prioritizing which

25:04

teams you support based on who bothers

25:06

you the most, you should be prioritizing

25:09

which teams you support based on who

25:11

needs your support the most to deliver

25:13

the most impact. So

25:15

with those teams, I generally advise them,

25:17

to talk to the teams they are

25:19

helping to say, with our support, with

25:21

our participation, if we were to do

25:23

this, how would it change either the

25:25

amount of impact you deliver or the

25:28

timeline in which you can deliver it?

25:30

If we were not to deliver that

25:32

support, how much would it impact the

25:34

amount of impact you can deliver or

25:36

the timeline in which you can deliver

25:38

it? So rather than, again, adding another

25:40

layer and doing these kind of cascades,

25:42

it's pretty directly like, we help you,

25:44

how much do you do? We don't

25:46

help you, how much do you do?

25:48

And if the team can't speak to

25:50

their impact, then this is a great

25:52

opportunity for those teams that are being

25:54

supported to learn to ask for resources

25:56

through the language of impact rather than

25:58

the language of frustration or disempowerment. or,

26:00

you know, it's not fair. We don't

26:02

have enough resources. Like, all right, well,

26:04

what could you do with those resources

26:06

that you can't do without those resources?

26:08

If you can make the case to

26:10

the business that investing in another engineer

26:12

is going to help the business achieve

26:14

its goals in a way that far

26:16

exceeds that investment in a single engineer,

26:18

then yeah, that's a great case to

26:20

make. If you say like, the business

26:22

doesn't care about us, we never get

26:24

the resources we want, and we just

26:26

have to fight and fight, then like

26:28

that's probably not going to get you

26:30

to the outcome that you want. So

26:33

have you ever worked with

26:35

all met teams that have

26:38

done this well, who are

26:40

very impact first? So

26:43

it's, it's funny because the name of this

26:45

book is impact first product teams. And it

26:47

almost sounds like there's going to be this

26:49

set of teams out there that are like,

26:51

we're putting impact first, things are easy for

26:53

us now, but it's, it's, it's never easy.

26:55

I was just talking to a client about

26:57

this today that. product work

26:59

never stops being challenging.

27:01

You just kind of

27:03

choose where that effort

27:05

is manifest, right? When

27:08

you're pushing, does that push deliver for the

27:10

business or does it work against the business?

27:13

Does it help deliver value to your customers

27:15

or does it try to change the practices

27:17

of the ways you're working in a way

27:19

that may or may not actually deliver value

27:21

to your customers? So I think when I

27:23

think about an impact first team, a

27:26

lot of the teams and individuals

27:28

I spoke to are just choosing

27:30

to direct their effort, both in

27:32

terms of their actual work product

27:34

and where they put their political

27:36

energy towards things that are really

27:38

meaningful to the business. I

27:41

think my favorite, I don't want to

27:43

play favorites, but a story in this

27:45

book that really resonated with me was

27:47

from Randee Psydu who worked at the

27:49

NHS building their COVID app. And

27:51

he said that when they would

27:54

have these open meetings to pitch

27:56

functionalities and features, the one question

27:58

was, how does this reduce the

28:00

transmissibility of the virus? One

28:02

impact metric. How does

28:04

this reduce the transmissibility of the virus? It

28:07

doesn't matter if it's a really cool idea.

28:09

It doesn't matter if it's super innovative. It

28:11

doesn't matter if a very important person asked

28:13

for it. How does it reduce the transmissibility

28:15

of the virus? And when you ask that

28:17

question, it shifts the way you think about

28:20

the solutions you build. where it's not just

28:22

what's the most advanced geolocation, blah, blah, blah.

28:24

But what about people who need it in

28:26

a different language? If we can unlock a

28:28

new market through a new translation or through

28:31

reaching a group of people who might be

28:33

resistant to using the application, that

28:35

delivers the impact we want oftentimes more

28:37

than the kind of cool and interesting

28:39

things we want to do. I think

28:41

a lot about when I worked at

28:43

Songza, which was a music startup in

28:45

New York. We started doing

28:47

these kind of impact level goals, one

28:49

of the quarters I worked there. We

28:52

did it through the OKR lens and

28:54

our objective was to strengthen the flywheel

28:57

between user growth and revenue growth. And

28:59

our actual metric we were looking at

29:01

was revenue per user. We wanted to

29:04

increase revenue per user in the quarter.

29:06

We had all these ideas for really

29:08

cool features we were going to build.

29:11

But when we looked at what we

29:13

could do, the most impactful thing was

29:15

to actually just connect to a new

29:18

ad serving network, because we knew that

29:20

that would reliably increase revenue per user.

29:22

That was like the least interesting thing

29:25

we could have possibly had a team

29:27

of engineers at a music startup working

29:29

on. But it was so incontrovertibly clear

29:32

that this was the work that was

29:34

most likely to deliver the impact we

29:36

needed to drive for the business. And

29:38

as a result, we were able to

29:41

approach this work without being like, upset

29:44

about it without being like, oh, the business is

29:46

making us do this thing we don't want to

29:48

do. It was like, we're choosing the work that

29:51

actually helps us achieve our goals. So,

29:54

again, in most of the stories and most

29:56

of the examples, the things

29:58

that are interesting to me are number

30:01

one, they're almost all stories about being

30:03

subtractive, not being additive, which is to

30:05

say, focusing on one or two or

30:08

a really small number of important goals,

30:10

rather than applying the right complex goal

30:12

setting framework. They are

30:15

almost all stories that involve

30:17

ongoing difficult conversations, but ongoing

30:19

difficult conversations that are redirecting

30:22

work at all levels towards

30:24

business impact. And

30:27

over time, the conversations get

30:29

a little bit easier. I

30:32

mean, one of the most surprising things

30:34

for me researching this book was that

30:36

the commercially minded product managers and teams

30:38

I talked to were also the happiest

30:40

because they do their job, right? They

30:42

go to the office and they do

30:45

their job and their job is to

30:47

make the company successful. They're not fighting

30:49

this existential battle to make their company

30:51

understand how to do product the right

30:53

way. Why will they never understand me?

30:56

They're there to do a job. When

30:58

you're there to do a job, when

31:00

you're focused on the impact you're driving,

31:03

I think it's easier to see constraints

31:05

and challenges as surmountable. Because again, there's

31:07

always the opportunity you have every lever

31:09

at your disposal to drive more impact.

31:12

Whereas if you say, it's impossible for

31:14

my team to work the right way

31:16

unless we go through this massive reorg

31:18

or unless every leader at the company

31:20

understands what it means to be outcome

31:23

driven, then you're just going to be

31:25

fighting a losing battle and you're going

31:27

to be really miserable. So

31:30

when do I, I probably should have asked

31:32

this like right at the beginning, but when

31:34

you, when you're talking about impact. It

31:37

sounds like you're mainly talking about business

31:39

impact, but then you

31:41

also mentioned the example with the

31:43

NHS app, with reducing the transmissibility

31:45

of the virus. Where

31:48

does the customer experience come

31:50

into this? I'm so

31:52

glad you asked that. A by

31:54

-product of, of course, if you

31:57

do well for the customer, then

31:59

business impact just comes. How do

32:01

you factor that into this? So

32:04

one of the things that was not

32:06

lost on me when writing a book

32:08

called impact first product teams is that

32:10

I myself have often spoken about being

32:13

a customer first company. So

32:15

what is the difference? Is it

32:17

okay to be impact first to

32:19

focus on the business first by

32:22

way of example? I was

32:24

working with a company a couple of years

32:26

ago that was embroiled deep in a debate

32:28

about how much discovery is the right amount

32:30

of discovery to do. And I suspect both

32:32

of you have found yourselves embroiled in this

32:35

debate at one point or another. How

32:37

much discovery is the right amount of discovery?

32:39

Are we doing too much discovery? Are we

32:42

doing not enough discovery? I was making everything

32:44

worse. I was like, maybe this amount.

32:46

No, I'm like, okay. Like, hey, researchers

32:49

like, they're like, no, more.

32:51

And I go to the prod teams and they're

32:53

like, uh, should we, and they're like, no, that's

32:55

too much. And I'm like, eventually the CPO of

32:57

this company was like, all right, look, we've got

32:59

pressure. We need to increase the number of users

33:01

who are getting through our signup flow. Like we're

33:04

losing too many people. So we need to go

33:06

from X percent to Y percent. We need to

33:08

do it in a month. Suddenly

33:10

we stopped having conversations about what's the

33:13

right amount of discovery to do. We

33:15

started talking. to users to

33:17

figure out where and why they were

33:19

churning. Because if we didn't talk

33:21

to those users, we did not have a

33:23

chance in hell of achieving that goal. And

33:26

the CPO was very clear that she actually

33:28

expected people to achieve this. This was not

33:30

just a nice to have. This was the

33:32

mission critical objective for the business. I

33:35

remember one product manager who just went

33:37

off and partnered with the UX researcher

33:39

and found out the 10 biggest pain

33:42

points in the onboarding journey. called

33:44

a meeting with all the product managers

33:46

across different teams and said, I will

33:48

haunt you in your dreams until these

33:50

are fixed. Again,

33:53

these conversations are still challenging, right? You

33:55

still have to figure out where and

33:57

how to expend political capital. But I

34:00

think expending your political capital on threatening

34:02

to haunt product managers in their dreams

34:04

until they fix the problems that will

34:07

deliver the result you need for the

34:09

business to achieve its targets is a

34:11

better expenditure of that capital than most

34:13

of the ways that I've expanded that

34:16

capital, certainly in having an abstract debate

34:18

over what is the right or wrong

34:20

amount of discovery to do. So

34:23

I think that broadly speaking, understanding impact

34:26

starts with asking the question, What does

34:28

the business need to achieve to be

34:30

considered successful on its own terms at

34:32

a specific point in the future? So

34:35

again, with that NHS app, that was what

34:37

success looked like was, have we saved lives?

34:40

For some businesses, that means have we made

34:42

money? For some businesses, it means have we

34:44

achieved product market fit or do we have

34:46

enough users? totally depends

34:48

context to context, business to business.

34:50

But once you know the answer

34:53

to that question, then you can

34:55

start to say, all right, who

34:57

do we need to talk to?

34:59

Who do we need to learn

35:01

from? Who needs to do what

35:03

for us to do this? So

35:05

I think that having that grounded

35:07

sense of business impact helps you

35:09

prioritize what discovery you need to

35:11

do in a way that is

35:13

actually much more truly and realistically

35:15

customer centric than demanding

35:17

more research, if that research is

35:20

not actually going to be utilized

35:22

towards building the product differently, which

35:24

it often isn't. So

35:26

we need to acknowledge we've had RandEEP on

35:28

the podcast. He's also spoken on the Mind

35:30

and Product stage about this story. Oh, yeah.

35:32

a fantastic story. It's such a good story.

35:34

Definitely worked our back to it. But I

35:36

love that you're coming back to this. I

35:38

was reading the book, and I was thinking

35:40

about this, and we talked about this last

35:42

week. A lot of what

35:44

you're talking about here is a culture.

35:46

It's a way of working. It's how

35:48

to approach things. And

35:50

you talk about this book is

35:53

for the product team itself. And

35:55

the product team itself is not

35:57

the one writing the strategy for

35:59

the organization. But when there's an

36:01

absence of strategy, it's really

36:03

problematic, because you need to figure it.

36:05

I work with a lot of teams

36:07

and I've been counseling them. If there

36:09

is no strategy, let's provoke discussion. Let's

36:11

propose something and see what happens. It's

36:13

discovery about the strategy. The worst thing

36:15

is they'll tell us it's wrong and

36:17

then we'll figure out something else. But

36:20

there's that famous Peter Drucker quote about

36:22

culture eats strategy for breakfast. And

36:25

the thing I got from reading the book and

36:27

listening to you talk is, yeah,

36:29

culture is incredibly important, but it needs a

36:32

strategy to hang itself on or to orient

36:34

itself around. I mean, you're

36:36

talking about the process of how teams

36:38

should work and not asking how much

36:40

discovery to do, but using it in

36:42

service of something. What's the right way

36:44

of looking at this? Help me figure

36:46

out the better way of saying this,

36:49

please. Well, it's an interesting one, right?

36:51

Because the way I think about culture

36:53

has changed a lot in the last

36:55

couple of years. I used

36:57

to kind of think that culture was

36:59

top -down deterministic, like the leaders set

37:01

the culture. The culture is this system.

37:04

And the org chart and a lot of other things

37:06

are kind of pieces in the system that can move

37:09

around. But one thing I've

37:11

learned is that the system changes

37:13

when individual nodes in the system

37:15

change. When one

37:18

team starts to work differently,

37:20

that shifts the culture, even if

37:22

it's just a localized action. When

37:24

one product manager starts to say,

37:27

yeah, I know we have, you know,

37:29

our OKRs, but right now my team

37:31

is really focused on this one thing.

37:33

that starts to shift the culture slowly,

37:35

but surely piece by piece, node by

37:38

node, team by team, the culture starts

37:40

to reshape itself. And

37:42

I think for those of us who do

37:44

consulting work, I was certainly really tempted by

37:46

the idea that I could go in and

37:49

change the system. Like, well, we'll start doing

37:51

strategy differently. Here's our new way of doing

37:53

strategy. But when you replace those, you

37:56

know, those are, those are meaningful bits, but.

37:59

It takes so many little

38:01

changes for the way the

38:03

system incorporates that strategy to

38:06

change for all of those

38:08

interactions to use some agile

38:10

wordage. For those individuals and

38:12

interactions to change, they change

38:14

the individuals and the interactions

38:17

around them. So

38:19

I think what I keep coming

38:21

back to is that new culture

38:23

is this thing that is created

38:25

constantly. It's a thing that we

38:27

are creating and recreating and shifting

38:29

and changing through every conversation we

38:31

have and every action we take.

38:33

And if we can get one

38:35

team in an organization to do

38:37

this differently, a few individuals to

38:39

ask different questions, if we can

38:41

start to take some of these

38:43

conversations and make them feel safer

38:45

and more comfortable, then that will

38:47

also ultimately shift the way that

38:49

the more important and impactful parts

38:51

of the system relate to the

38:53

system. So I've just

38:56

come to a point where

38:58

I think every little shift

39:00

you make with every individual

39:02

and every team is critical

39:04

and valuable towards changing the

39:06

way that these things are

39:08

done writ large. And

39:11

I try to remind myself

39:13

not to get frustrated when

39:15

it takes time and not

39:18

to try to make big

39:20

changes that will ultimately be

39:22

rejected by the

39:25

current set of systems

39:27

and relationships between individuals

39:29

and teams. Matt,

39:31

this has been fantastic. I think we've got

39:34

time for one more question. And

39:36

this has been really actionable stuff. We've asked

39:38

you a bunch of hard questions. You ask

39:40

a bunch of really great, hard questions, which

39:42

is wonderful. I'm not going to toss one

39:44

of those at you right now. But

39:46

in the spirit of actionable things

39:48

that you're talking about, I was

39:50

going through the book yesterday. And

39:53

there was a question that came up really early

39:55

for me. And I wrote it, and was like,

39:57

aha, I've got him. This is a gotcha question

39:59

for him. And then later on in the book,

40:01

you absolutely addressed it. And I love the way

40:03

you addressed it. So well done, you. A

40:07

lot of the teams that we're talking

40:09

about, so in startup scale -up, having

40:12

the ability to focus on an

40:14

impact is really easy. But there's

40:16

not a lot there, potentially. Oh,

40:18

there's not a lot of cruft that's there.

40:20

But in legacy companies and enterprise, a

40:23

lot of teams, they have a big

40:25

percentage of their work that's BAU and

40:28

then another percentage that change. And

40:30

the impact first stuff is usually change.

40:33

So how do you deal with it when you're in

40:35

one of those teams? What's the right way of approaching

40:37

this? So I

40:39

caution against, look, the word

40:42

innovation is a word that

40:44

I really don't like because

40:47

It's a word that can mean a

40:49

lot of different things to a lot

40:51

of different people that often exists outside

40:53

of a company's business model in a

40:55

way that makes it really difficult to

40:57

bring that work back in. So,

41:00

you know, I've worked with teams where

41:02

there's the BAU teams and then there's

41:04

sort of the accelerator team or the

41:06

skunkworks team or the team that's going

41:08

off and. Usually folks on

41:10

the business as usual teams hate those teams because

41:13

they get to do all the cool stuff and

41:15

aren't held accountable for it and it's not fair.

41:18

I think that can be okay is

41:20

so long as it is explicit what

41:22

success looks like for those teams. That

41:24

to me is really the key. So

41:26

if you have a team that is

41:29

told like, look, your job is to

41:31

explore new business models outside of our

41:33

existing business model. Okay, great.

41:35

They know not to try to generate

41:37

revenue within the existing business model. If

41:39

you have a team that's told you

41:41

are responsible for optimizing our existing business

41:43

model towards these ends. That's

41:45

great. That's reasonable. It's a conversation that

41:48

can be had where I see things

41:50

getting really messed up is when there

41:52

are assumptions about what success looks like

41:54

for teams or when the goalposts shift.

41:56

So when, for example, there's a team that is

41:59

an innovation team that then gets let go because

42:01

they're not revenue generating. That's like. were

42:04

they supposed to be revenue generating or were

42:06

they supposed to be exploring and validating new

42:08

business models? Conversely, when you

42:10

have a team that is responsible

42:12

for optimizing something towards a specific

42:14

goal and they're not shipping a lot

42:17

of new software, it's like, well,

42:19

probably they're not supposed to be like

42:21

that might not be the most valuable

42:23

thing for them to do. So

42:26

again, I think part of why This

42:28

focus on impact is so important is

42:31

that it gives teams the freedom and

42:33

the leeway to do the work that

42:35

is actually going to help them achieve

42:37

what the business needs from them. If

42:40

the business isn't clear about what it

42:42

needs from them, which it often isn't,

42:44

then it's up to the team to,

42:46

as you said, Randy, even if. They're

42:48

wrong to have some sense to be

42:50

able to provoke that conversation and say,

42:52

Hey, here's what we're working towards. Is

42:54

this going to be successful for the

42:56

business? Is this enough for the business

42:58

to feel good about the work we're

43:00

doing? But when you

43:02

don't know what that is for those

43:04

teams that are like, I think, you

43:07

know, I don't with a team like

43:09

this where. They were

43:11

responsible for the most revenue generating

43:13

product on a company that really

43:15

that had revenue targets. But all

43:17

of the company's initiatives were about

43:19

building new products. And they

43:21

were kind of like, I

43:23

guess we don't matter because the company's been

43:25

rolling out. They've had this whole big thing

43:27

rolling out initiatives. Ooh, who's on an initiative?

43:29

And none of the initiatives are about optimizing the

43:32

existing product. So building this cool new stuff. So

43:34

I guess we don't matter to the business. I

43:36

was like, tell you what. how much revenue does

43:38

your product generate? And they're like, this much. I'm

43:40

like, how much will it generate if you achieve

43:42

this much? I'm like, all right, let's go to

43:44

the CPO. And they go to the CPO and

43:46

he's like, why are you even talking to me?

43:48

Of course your team is important. You work on

43:50

the one revenue generating thing. Why on earth would

43:53

you think that your team is not important? That

43:55

makes no sense. But again, when we add more

43:57

and more of this stuff and we have the

43:59

objectives and bets and the layers and this and

44:01

that, blah, blah, blah. It's really

44:03

easy for folks to get super,

44:05

super, super confused about what success

44:07

looks like. which is why having

44:09

that impact level goal, that ability

44:12

to say, we are delivering this

44:14

much value to the business in

44:16

the terms that the business cares

44:18

about the most is the most

44:20

important thing for any team to

44:22

start with. I do

44:24

find as well that

44:27

there's a lot of

44:29

ego tied up in

44:31

some of these conversations

44:33

and people want to

44:36

be involved in,

44:38

like you say, the innovation

44:40

stuff or, you know, the

44:42

most impactful work. And

44:45

I don't really have an

44:47

answer for, like, how you

44:49

deal with that situation, but

44:51

I've definitely experienced it before

44:53

with teams where, like

44:55

you say, there's a bit of a

44:58

kind of like... My work is obviously

45:00

not important because I'm not having meetings

45:02

with the board about... know, the initiatives

45:04

that I'm working on and there's a

45:06

bit of kind of competitiveness that happens

45:09

and a bit of sort of sulking

45:11

and I don't want to say tantrums

45:13

but you know, maybe I will say

45:15

it. So I'm going to

45:17

give my less spicy answer to that and then

45:19

I'm going to give my really spicy answer to

45:21

that. My less spicy answer

45:24

is again, people are

45:26

going to have egos, people are going

45:28

to be hurt, have hurt feelings. The

45:30

question is, are they leveraging those hurt

45:32

feelings towards seeking out work that is

45:35

more impactful or work that is more

45:37

visible? And if there's a disconnect between

45:39

those two things, then I think your

45:41

question speaks to where things might wind

45:44

up. My very spicy

45:46

take for those of you who are still

45:48

sticking with us through this conversation, there

45:51

is and you're seeing this in the way a lot

45:53

of stuff is playing out in the US right now

45:55

in truly heartbreaking ways. There's

45:57

this theory that Businesses are

46:00

rational and exist to make

46:02

money. I think what

46:04

we're seeing is that a lot of businesses

46:07

and governments run like businesses are irrational and

46:09

exist to make a few men feel good

46:11

about themselves. And

46:13

I don't know way

46:15

around that short of

46:17

broad -based revolution and

46:20

slowly but surely hopping

46:22

out of working with

46:24

toxic people who seek

46:26

to do harm. But

46:28

once that clicked for me, I

46:31

was like, oh, a lot of

46:33

businesses are essentially like elaborate machines

46:35

to convert capital into special feelings

46:38

for a few insecure men. Then

46:40

I feel like I have a

46:42

better understanding of the world. Yeah,

46:45

well, we could have a whole nother

46:47

long conversation about the ethics and morals

46:49

around this, which is not the topic

46:52

for tonight. No, an important topic.

46:55

Yes, we should definitely retire, get a drink

46:57

and have that conversation. Absolutely. But

46:59

the way to soothe yourself as long as

47:01

you're not doing anything too bad is the

47:03

quote from Mad Men of, that's what the

47:05

money is for. That's why they pay us

47:07

to do their jobs. Matt,

47:10

this has been fantastic, except for

47:12

that last five seconds. Thank

47:16

you so much. The book is wonderful. It's

47:19

one of my favorites of recent times. I

47:21

really enjoyed I think it's really useful, really

47:23

impactful. And it's also really

47:26

short. It's 116 pages, I think,

47:28

and every page is fantastic. Thank

47:30

you. I wanted, you know, who

47:32

wants to read more than that

47:34

much about business impact, right? Certainly

47:37

not I. It depends how many

47:40

my ties I'm drinking, so. I

47:43

think there's probably an optimal number of my ties.

47:45

I think maybe one or two, any more than

47:47

that. And I'm playing the book down and going

47:49

and doing something else. Thank

47:52

you Matt. It's been really great chatting with you

47:54

again. Thank you. It's been such a pleasure. The

48:07

product hosts are Smith, host

48:09

by night, and Chief Product

48:11

Officer by day. And

48:13

me, Randy Silver, also host by night.

48:15

And I spend my days working

48:17

with product and leadership teams, helping

48:19

their teams to do amazing work.

48:22

Lu Pratt is our producer, and

48:24

Smith is our editor. And

48:27

our theme music is from product

48:29

legend band Pow.

48:32

Thanks to them for letting us use their track.