How to lead
A Product Development Team
"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]
