lead

"Building a Kick-Ass Product Team” by Martin Eriksson, founder of ProductTank & Mind the Product



Sharing buttons:

[Music]

thank you very much glad to be in Berlin

it's actually my first time in Berlin

I've been in like five or six other

cities in Germany but never berlin for

some reason so I decided I have to fix

up so I'm here to talk a little bit

about what it takes to build awesome

public teams and I was glad to see a lot

of you are here from product tank and a

lot of your park managers but I think

also a few entrepreneurs out there

figuring out how to build your team and

how to set them up for success or even

how you should be thinking about the

product approach as you're building your

company is always incredibly important

so as Lou said my name's Martin I'm also

known as bft Martin everywhere which is

Big Friendly Giant

for obvious reasons and you can find me

on Twitter and everything else as Lou

said I run a started product tank in

2010 which was a meet-up just for public

people would have been totally happy if

I just ate about twenty thirty people

every month it has kind of taken off

from there there's 400 people meeting in

London tonight and the meetup is in 105

cities around the world including Berlin

how did I be able to spend out my new

product which is the conference that I

run for the full time job which is the

world's largest with two conferences one

at Lund and one francisco 69 people each

but before that I was doing product

management for nearly 20 years in

various startups in Sweden London and

the US and when I was at a start-up in

London called huddle which was the b2b

software-as-a-service

application this is the team I had a

kind of an aha moment and that moment

was our most successful launch the best

product that we launched in the time

that I was there I didn't write a single

story I didn't do a single wireframe I

didn't do a single mock-up I had nothing

to do with the product that actually

shipped out the door but actually I had

a lot to do with it because I was the

one that set up that team and I was the

one to set up the problem for them and

made them successful and I think that's

when I realized the product leadership

is something very different

first most the time the team actually

looked like this

and that's part of the product managers

job zone where really product leadership

is difficult it's not glamorous and it's

not about product because it's actually

about people and so setting your team up

obviously starts with like any good

heist movie starts with assembling your

team you have to find your safecracker

you have to find your getaway driver you

have to put that team together and for

us what that means is really thinking

about complementary skills so a lot of

you hopefully seen this kind of Venn

diagram it's my definition of product

management as the intersection of the

customer the technology and the business

the challenge of this is a lot of people

think that that means product teams

should look like this you have to have

everything you have to know everything

you have to be really deep deeply

knowledgeable about all three of those

areas but realistically we all look like

this or we look like this or we look

like this and the key is to make figure

out how to make your team work together

so that together you have all of those

skills and I think that's one of the big

reasons that we probably suffer most

from imposter syndrome in the tech

industry because everybody else knows

some things better than we do and it's

such a journalist role that that can be

really crushing it's also thinking about

diversity in your team so it's not just

thinking about the skillsets they come

from it's also thinking about what work

experience do they have what industry

knowledge do they bring to the table

what background do they have what

culturally from what there's a life

experience what gender are they all of

those things are important to think

about when you put together your team

and again a person looks like this you

want to figure out like the next hire

that you bring on their team whether

it's a developer - designer a next

product manager looks a bit like this so

you start complimenting each other and

you have different skills we bring

different context to the table and

that's so important when you're in a

product role because it's at the end of

the day it is all about empathy good

product is all about empathizing with

your end customer your end user and the

more you can bring context to that table

and experience that table the more

likely you are within that team to be

able to empathize with your customer

it's also a team sport so it's thinking

about how that whole team sits together

there's a famous quote by Marty Kagan

who's probably kind of the Godfather

product modern product management which

is that if you're only using your

engineers to code you're only getting

half their value and that's true of

every role in the company is true for

your designers if you're only using your

designers to design you're not getting

half most of their value if you're only

using product managers right specs and

put them in gear if you're not getting a

value the key is to bring everyone

together into one cross-functional team

because it as soon as you start

splitting out into teams as your company

grows that's when you start getting

friction and when one team has to ask

another team for help there's a little

invisible barrier between the teams and

that's when you have to start figuring

out queuing systems prioritization tools

Road mapping tools whatever it is you

need to be able to overcome that

communication gap and really what you

need to be thinking that is how do I

make one cross-functional team that can

execute on their goal and has all the

skills they need in that team to execute

on that goal a really good example is a

start-up called transfer lives in London

how many no transfer is fairly common so

it's all about currency conversion and

my favorite example for this is they

have a team that just handles currencies

and that team's responsibility is to

figure out what markets do they need to

go to what new currency transfer path do

they need to open up so within that team

they don't just have devs designers

develop and a product manager they

actually I also have a banker and they

have all two lawyers so that whenever

they go to a new country they can open

up the account they can set up all the

legal agreements and execute it they

don't have to go to a separate legal

department and hand in a request form

and waits three months to get the right

paperwork back they have everything they

need in their team to execute on their

goals so once you set up your team for

success you need to create their

environment and it's not about having a

ball pit in your office it's not about

the ping pong table or the free beer at

the end of the day although those things

are nice it's about thinking about what

makes a team successful how many of you

heard of project Aristotle at Google

definitely go look this up Google being

data minded as they are decided to

figure out what makes their teams

successful so they looked at all of

their teams across the company looked at

all the performance data that they could

get for those teams looked at all the

data that went into those teams and

tried to figure out over like a five

year span what it was that made a team

successful and being Google they assumed

basically the more Stanford engineers

you have in a team the more successful

is going to be the smarter the people

were the better their qualifications the

better their degree the better their

scores and what they found out was that

that had no correlation whatsoever with

success the number one thing by far they

found five things but the number one

thing by app mile is this concept of

psychological safety which basically

means that the teams that were most

successful were the ones that were happy

to disagree with each other they admit

mistakes to each other to have an

argument about the product or the

solution or the process and they were

more open basically to admitting

mistakes taking on new challenges and

challenging the status quo and then

thinking about what makes a team

motivated this was on the great book I

really recommend this by Daniel pink is

called drives the surprising truth but

what motivates us there's also a great

TED talk on this if you want the short

version and he identified three things

that matter and he did this through a

study at MIT where again they did a

really large study looking at innovation

in teams so really looking at that kind

of high knowledge work that we all do

new ideas new innovation and what makes

those teams more successful and all the

old methods around like the carrot and

stick thing of the more you incentivize

them you more you gave them bonuses all

those things stopped working the three

things that worked in various

combinations and depends on your team or

autonomy mastery and purpose autonomy is

our desire to be self-directed and it

increases engagement over compliance and

again the kind of high knowledge work

that we all do you want to engage team

you don't want them just following

orders and executing exactly what you

write on a ticket

mastery is the urge to get better skills

and master our craft which is hopefully

where most of you are here today to

learn more about this job and purpose is

the desire to do something that has

meaning and has impact that kind of big

picture that joke that they have on

Silicon Valley about I'm going to change

the world it doesn't have to be that big

but it has to be something meaningful it

has the impact and it feels like you're

changing the lives of people around you

or making someone's life better or

saving people money or whatever that

goal is it's something you can buy into

and believe in you've got the team now

you have to figure out how to lead and

again everything comes in threes there's

kind of three key ways to think about

leadership authoritative participated

and delegative authoritative is all

about setting very clear expectations

the manager makes decisions with little

or no input from their team and it's

very task driven and it works well when

labor is low skilled and the leader has

all the knowledge in the experience so

this is your basic factory model the

staff doesn't really need to know that

much about what they're doing it's very

simple jobs or tasks driven they just

need to execute existing plans obviously

know how any of us should be working

participated gets a little bit more open

the manager still has hands-on guidance

they get inputs from the team but they

retain the final decision-making and

it's very collaborative and I think most

teams these days especially in our

industry work like this

but there's one step further that I'm a

huge passionate believer in and it ties

into that autonomy point of motivation

which is delegated which is where you

kind of hand all the decision-making to

the team after giving them high-level

guidance so that they have the autonomy

to make the decisions execute on their

plans and it's very people doing and

again this works well when the workers

the team has more knowledge or more

experience than you as a manager do

which let's be honest it's almost always

the case

now the tana me is an interesting topic

I think because we're talking not

talking bad enough and I think it's such

a big motivator for what we do know such

a big motivator for those of you who are

entrepreneurs that's why you're out

there doing is you want that autonomy

you want to be the Masters of your own

destiny and building your own thing and

it works in teams because it motivates

people better again going back to the

motivation point it scales better

because it's much easier to spin up a

new autonomous team and let them go

execute a plan than to try and scale

what the middle managers and lots of

processes and figuring out how to do

ticketing and handovers it's also just

plain old quick and nimble because they

all those small teams can stay very

small they can stay autonomous they can

say agile and not have to worry too much

about communication overhead with other

teams and again it works because your

team is smarter than you are and most

importantly your team is much much

closer to the customers than you are

they're the ones that are facing those

problems every day they're the ones

talking to the customer every day

hopefully and so they're going to know

more about that problem than you ever

will so why would you make the decision

instead of them now a lot of people

think that this just sounds like anarchy

and chaos and it's not it can be it's

all about finding the right level and

it's about aligned autonomy or autonomy

with accountability different terms that

are coming up for this and this is a

chart by a guy called Henrik Nyberg who

was the agile consultant same as for

kind of setting up the Spotify teams the

squads and things that they run and he

mapped out like all good consultants do

a two-by-two chart with alignment on one

axis and autonomy on the other and

obviously if you have low alignment and

low autonomy it's basically a

micromanaging organization in different

culture people just doing whatever they

want if you have high alignment and low

autonomy it's a very authoritative place

where the boss is telling you go do this

thing this is exactly we need to execute

the conformist culture everyone just

kind of toes the line high autonomy but

low alignment entrepreneurial chaotic

that's where you start getting anarchy

obviously where you want to be like oh

good two-by-twos is in the top right

which is high alignment and a high

autonomy which means basic the boss's

job is to make sure that everyone knows

what their goals are knows what they

they're aligned to do but then has the

freedom to go execute it because then

you have the autonomy you're going to

execute quickly it's a collaborative and

innovative organization

and some of the tools that you use to do

that are thinking about how you set your

goals I believe in trying to set the

goals from a bottom-up perspectives once

you have that kind of a high picture

vision you have an alignment that you

know our goal is lists for the year

let the individuals and the teams figure

out how can they contribute to that how

are they going to what levers are they

going to pull what metrics are they

going to push and then boil that up to

the top and see if you can actually hit

the goal that you want to hit because

then when you look at it from the top

down then you can see whether you're

going to hit those goals where you have

challenges where you need to add

resources where you need to focus your

time and it's also thinking about

incentives because what you incentivize

is what you're going to get Dilbert as

always says it best if you incentivize

fixing bugs by paying people a bonus for

every bug they fix their going to create

more bugs you're going to get what you

measure and that's obviously know what

you want which brings us on to thinking

about how you measure success for that

team so you got the team set up you got

some organized you got some motivated

they're all autonomous how do you figure

out whether they're successful or not

first of all I think it's really

important to balance qualitative and

quantitative there's a lot of debates

online about oh it should be totally

metrics driven or should be totally kind

of ethnographic study driven go talk to

our customers all the time you really

need both because without the data you

can't make sense of the feedback you're

getting and without the feedback you

can't make sense the data and then it's

really about focusing on outcomes for

the customer this is a pretty famous

quote I hope you've heard it before that

people don't want a quarter inch drill

they want a quarter inch hole and

actually I would challenge you to think

even deeper than that and ask why one

more time it's not more why do they even

want the hole are they trying to hang a

picture maybe they just need to one of

those sticky hooks are they trying to

you know run a cable for their TV

through to the next room maybe there's a

wireless solution to that once you

really understand the outcomes and the

problem that you're trying to solve it's

much easier to understand what the

solutions to that can be because it can

be a lot of different ones and that's

why I think you should spend a lot more

time focused on defining the problem and

there's another great quote from Ken

that came out from the injuries we're

doing for my book

which is that once you understand the

problem at that deep level measuring

success is actually really easy because

it's the absence of that problem so

going back to the whole thing if you

know that the person needed to hang a

picture measuring success is is the

picture on the wall and you're done you

solve the problem a little simplistic

maybe but it's a good way to start

thinking about what are you actually

measuring and what are you trying to

solve for your customers then finally I

think one thing that is really important

to think about in our teams and in their

startups is balancing discovery versus

delivery because there's nothing quite

so useless as doing with great

efficiency that which should not be done

at all and I think as an industry we've

kind of been obsessed with the delivery

side of this for very long time we have

all these amazing methodologies agile

scrum lean Kanban really old school ones

like Six Sigma prints - even waterfall

at one point was an innovative way to

build stuff and they're all focused

about how do we ship something that we

know we need to ship and they all come

from a factory background it's all about

we know what the Toyota Prius looks like

how do we most efficiently build a

Taylor previously ship it to the

customer the challenge is we kind of

forget that the person who designed the

Toyota Prius doesn't work like that they

work in a design studio in fact it's

kind of autonomous mode much more open

much more free and there are

methodologies for that but especially as

product managers historically we've kind

of forgotten about some of those so

there's Design Thinking design sprints

discoveries dual track agile there are

tools out there but we just as leaders

have to make sure that we are focusing

our time on both sides of that balance

because I think we have to be careful of

the dogma that's out there so when

you're reading the agile books and

reading the lean books it's really easy

to think of them as like step-by-step

check plans that you need to follow if

you're not doing stand-ups every morning

you're not in agile if you're not doing

your weekly retrospectives you know a

job and all that's to be honest

because in the agile manifesto itself

which I believe in completely it says

that we value responding to change over

following a plan and that's the bottom

line

we have to figure

what works for us and our teams we have

to take the bits of the process at work

when we're executing for our customers

and not just follow a plan so just to

wrap up John Maeda who's an amazing

designer said don't forget the people

make this stuff relations make the

bigger stuff if you get the relations

and the people part right everything

else will follow

just to recap assemble your team Avenger

style Evers cross-functional co-located

ideally set them up for success by

thinking about psychological safety

giving them autonomy giving them purpose

giving them a mission and then make sure

that they're balancing discovery and

delivery are they out talking to their

customer as often as possible or are

they just focused on shipping tickets

because why is more important than what

for one finally product leadership is

not about products it's about people

there's some read more stuff here like I

talked about if you go to Google's

rework is called rework with Google comm

they have all that data that they've

shared from their project Aristotle

Daniel Pink's drives and silence onyx

start with Y and of course I have to

plug my own book at the end which is

coming out any week now and it's based

on these interviews that we've been

doing a nearly 100 product leaders

around the world so thank you very much

hope you enjoyed it and see you around

thanks the tough part of a group of CEOs

that talked about cross-functional teams

before what they had found they had

built teams from scratch up to about 60

or 70 people or so they found that when

they tried to implement cost functional

teams too early that it didn't seem to

work for them and functional teams

seemed to work better in practice so I'm

just curious what you think of company

maturity and whether or not that matters

in this company maturity more volume on

the phone company maturity probably does

have an impact you're right I mean I

think when you're under 10 people

everyone needs to do everything anyway

so that is just probably one giant

functional team I think the challenges

as you start scaling a lot of it

actually comes down to

what product you're building I think is

opposed to the maturity of the company

because it's more about doesn't make

sense to have different teams focused on

different areas of the public art or the

or the experience it's another example

from transferwise is actually how they

think about when they mean

cross-functional teams at about time we

do whatever they want they really mean

it as well as to think is another team

that's another thing most teams don't

think about so for example their online

marketing team has of course designers

developers in it and if they need to

optimize a user flow from a Facebook ad

all the way through to sign up they

don't just have power to change that ad

and like the landing page like most

marketing teams to do they can actually

go all the way through the user force

they're allowed to touch any part of the

code you're allowed to take whatever

they need to I think it's that kind of

complete openness it starts making it

work because that team can literally go

change the user signup flow of the

dashboard to make sure that they're

hitting their goals it gets sticky and

messy like teams clash with each other

and they clash over the dashboard and

things like that but that's better than

having kind of that cueing system that

means that effort never gets changed to

optimize that flow for that user so I

think there's there's some things around

cross-functional where people kind of

done a little half-ass almost and then

it might not be as optimized but I also

think more than company stage it's

probably the product so if it's one

monolithic products or one one solid

user flow then it might make more sense

to get more throughput which means you

might want to have functional teams

whereas if there's lots of different

experiences like different throughputs

or different types of users different

personas and it makes sense to have

teams assigned to each of those I hope

that helps I think the problem is

there's no one right answer for all of

the screen more questions I think's

again for the great talk but what about

purpose so let's say okay I'm working at

the company and the industry is here the

product is quite clear the product idea

this lease is clear how can I give them

more purpose than that what I try to do

on the task level is okay just imagine a

customer can do this or that and that's

why it's value but oh is it is it what

you mean with purpose or is there more I

think the the key with autonomy mastery

and purpose is getting the balance of

them right so

don't have to max out all of them like I

don't think any company in the world can

do that unless your can somehow let

someone rebuild it an amazing new tool a

new software for like a you know a

volunteering organization something like

you're not going to be able to max out

purpose and autonomy and master its

figuring out like what what are your

team motivated by and if you can't like

max out purpose if it's an e-commerce

tool or something like it's we're just

selling things and we're something nice

things like it's not not a bad business

but it is the business right then make

sure you're making have let them have

autonomy mastery if that makes sense so

it's making sure that they're in balance

as much as anything else and I think

that it's important to realize again

like that's why it's such a joke on the

Silicon Valley TV show right so like

we're going to change the world cause

like every company isn't going to do

that and that's okay that's not a bad

thing that doesn't have to be that super

high purpose but I think there is

something basic in what you're already

saying around having enough purpose that

you feel like you're solving a customer

problem

what are even if it's just cheaper shoes

or something that's still like you have

a purpose which is I'm going to help the

customer and then if they have enough

autonomy and mastery then I can you know

I would be interested in some of your

experiences with actually introducing

product thinking within the company

because quite often like you especially

like smaller startups they bring in a

product manager thinking they will fix

things and they will kind of you know

bring the right culture like they speed

up the development team but actually at

the core is also that the product itself

has some or the company has a product

thinking so how can you help the company

develop this I think ultimately product

managers job is about communication so

they should be communicating that

process I think where I think it depends

if their organization is going to

resistant to the change I think the one

thing that you can do is really start

small right and do show rather than tell

so find one little thing that you can

change and show how product thinking can

impact that so a good example of even a

big organization was get a speaker in

the conference last year called Maria

Judy's who's the chief experience

officer I believe at Autodesk and she

came into that organization to like

change it from a very product oriented

shipping software boxes to a kind of

full and

and experience company and the first

thing she did in their first 90 days

kind of thing was actually changed the

footer on the homepage like it's not

even that important a part of the

product that she saw an issue and she

knew that she could change it with this

kind of methodology and she communicated

about it like this what we're going to

do this is why we're doing it is the

research we have to prove why we need to

do it they made the change they achieved

the number they wanted to do and that

kind of started teaching people in the

organization that this is a valuable way

to work and then they went on to bigger

and bigger and bigger things and like a

year or two later she's like right now

we're going to take all these hundred

products and make it into one experience

so like she bought herself a trust by

showing that this process works build up

to the big thing I think that's saying

for even if you're just coming into a

startup it's thinking about how can you

show that the product kind of thinking

product methodology work so going out

and talking to customers figuring out

the problem is showing that you know

what the problem is and how to fix it

because of that research and then that

you can actually deliver on what you

promised in your discovery versus

delivery slide there was a big fat line

between the two and I was wondering what

are the best practices to get rid of

that line and what's actually the second

question is what's the perfect week for

a product manager because like how much

time should I be spending on hiring

versus go getting for the why versus

going for user feedback versus

prioritizing what what's the best

product manager which is that I think

the the timing thing is definitely going

to change depending on stage of the

product right so like when you're in the

very early stage you suppose you

spending four days here week just doing

user research and data and stuff like

that and then when you have a bit better

picture then it's maybe two days and

then when you're kind of just improving

and executing on kind of something or

after you've hit product markets it's

then maybe it's just one day you're a

week you're talking to customers and the

rest of time you're figuring out how to

execute on the problems because you

already have enough data so I think that

changes I think to your point about the

line that's a very good point it's

probably a design problem there that

there shouldn't be a line you're right

and I think that's where some of those

methodologies really inching like dual

track agile which is a very kind of

iterative looping process that goes and

involves everyone and I also think it's

where I again plant really important

that the whole team should be part of

that process so you usually also say the

product managers job is actually to

prioritize the problem and bring the

problem to the team

not the solution the whole team should

be helping come up with the solution and

that involves going through all that

used to research together looking at the

videos and then designing the right

thing because again your engineers are

created people as well right so

everybody should be involved in helping

figure out the best possible solution

and that's one of the reasons that that

Longy talking about the beginning of the

talk went so well is because I'd been

able to set up the problem and

communicate it well enough to everyone

in the room we had a kickoff meeting

that involved sales marketing design

development and was one of the junior

developed in the backers room was like

that's what we're trying to do why don't

we do this and I was like yeah great

first story on the board this awesome

looks a great idea because he had a

better understanding of the technology

stack than anyone else in the room and

could figure out the best possible

solution so I think that's you're right

it has to be a very kind of iterative

process but the whole team should be

involved on both sides ideally like that

developers the engineers they should see

the users research maybe they're not

sitting there all day with the customer

but they should see the videos they

should see the feedback we should look

in on a meeting everyone all to get that

direct feedback because there's nothing

quite so honest is being able to see a

user struggle with your public's and

then go back up I'm going to fix that so

it's very motivating song oh well thank

you Martin I just have one question

actually because then you've been doing

this for with more than 20 years okay I

that and then you went on to interview

hundreds of planet leaders around the

world and is there one learning that

really really surprised you thank you

I don't think of that surprising as I've

been doing the conferences and stuff as

well is that we're all facing same

problems and I think the main thing that

came out in the book the only kind of

structure change is a little bit like

the stage of company so that it's

slightly different in the startup versus

a midsize company to an enterprise but

really we're all faced the same problems

whether you're Google or Facebook or

some small startup in Stockholm you're

facing the same challenges and we're all

trying to figure out the same things as

people that means everyone gets the same

chance of doing ok go a big round of

applause for someone and success

[Applause]

[Music]