We Talked To Product Management Legend Marty Cagan. Here’s What We Learned | BUILD Podcast

We Talked To Product Management Legend Marty Cagan. Here’s What We Learned | BUILD Podcast


(upbeat music) – Welcome to Build, today
I’m really excited because live in person I have the OG Marty Cagan. He was at Netscape, he was at
eBay, and now he’s a partner at Silicon Valley Product Group. I know your work mostly for
all the orange header articles that I’ve been reading for
my entire product career, so it’s exciting to finally
meet you, so welcome. – Thank you very much. – Yeah, so I know there’s
a million questions that the team and I all had for you, but where I wanted to
start was just getting right into it with this theme
of empowered product teams. So how did this come
to be a thing that you sort of identified and
started to think about? – Okay, yeah, it’s a
good question, because, and this is kinda my focus for this year, I’ve decided to really focus hard on it. The reason is, actually,
because, mostly for years I’ve been focused on what I
loosely call product discovery, lean startup is a subset of that. The idea is that how does
product managers, designers, and engineers solve hard problems in ways that customers love but
work for a business? That’s basically what all
product people try to do. But it’s incredibly hard, and you know, the harder the problem
to solve the more clever you really need to be, and I
have over the years learned a lot of techniques, ’cause
there’s a lot of situations, there’s a lot of risks, there’s, like, there’s quantitative and
qualitative techniques. Anyway, I wrote, I ended
up writing a book about all these techniques, 300 pages
of these different techniques, and it did well, and lots
of teams, I do work with a lot of teams and I show
them these techniques and they get it, but too often I find out that they’re not allowed to use them. They’re literally not allowed to use them. Not like they’re
prohibited, it’s more like, hey, here’s your roadmap,
just build these features. – Right. – And is that discussion that explicit? Is it, like, literally– – It’s sometimes very explicit,
depends on the culture. Lot of times it’s not,
in fact, a lot of times the leaders don’t even know
this is what they’re doing. – Really? – They’re not even aware
of it, because what they’re really doing is working the
way they grew up or working and they thought that’s
how everybody works. And what I realized in those
companies, ’cause often what I’d do is I’d go in and
talk to the CEO and said, look, why are you doing this? You know this isn’t how
good companies work. A lot of times I know already, most CEOs have certain companies they admire. They might really admire
Netflix, they might really admire Salesforce, or they
might really admire Google, and I’m like, you know that’s
not how they work, right? So why are you doing this? And I, the answer, it’s
not always admitted, but usually they’ll fess up to what’s really going on is
they don’t trust the teams. – [Maggie] Okay. – They really don’t trust the teams. – And they’re like, look, you
know, they’ll say they’re not, they’re hardly talking to
customers, they really don’t know what they’re doing, and I just need them to implement these features. And so I’ll try to get
them to understand that what they really need to
do is empower their teams. And now I will also say, empowered teams has been a thing forever. – Right. – At good companies, that’s
how they work and that’s how they’ve worked from the beginning. It’s not like it was introduced to them, this is in their DNA. I’ve written lately about
how Apple’s founding, Amazon’s founding, Google’s
founding, they actually had the same coach, interestingly
enough, the founders. – Oh, right, The Trillion
Dollar Coach book that just came out, yeah. – Bill Campbell. And he didn’t coach me,
unfortunately, I wish. I did meet him, but I
worked for two people that he coached directly,
so I was a beneficiary. – [Maggie] You got the
lessons, yeah. (laughs) – A beneficiary of the lessons,
in fact I realized when I read that book how many
of the things that I thought was sort of me was really
him coming through, and so, anyway, empowered
teams have been a thing for a long time, but that’s
in companies that get this. And in most companies it’s
not, they’re set up, you know, it’s often referred to as
IT culture, project culture. But, you know, you have a bunch
of executives and sometimes prospective customers
dangling a big check. But one way or another they
have a bunch of features that get prioritized onto
a roadmap and eventually a team is asked to build these features. – [Maggie] Right. – [Marty] And that’s, that’s really the anthesis of what I’m talking about. And so those are the two models
out there, and I am trying to get more companies to
understand that it is not an accident that Amazon’s had
the success that they’ve had. That it’s just not random,
there is a method to it. – So what are the, sort of,
for the audience, the pieces that make up an empowered product team? Like, I think there was,
like, four characteristics? – There’s a, it’s a good,
I don’t think I’ve ever enumerated them like that
but there are a lot of defining characteristics and I
would also say prerequisites. – I mean, ’cause fundamentally
what you’re trying to do is get the leadership team to
give the product team squads, if you prefer, this idea
of cross functional teams, problems to solve rather
than features to build. That’s kind of the
defining characteristic, give them problems to solve. Now the other side of that, though, is that they have to
staff ’em appropriately. So, you know, ’cause in
a lot of organizations, if they’ve been running this
old way they almost certainly don’t have the staff that they will need to run this new way, and I say
that, and I wanna be careful. There’s, every company I’ve
seen there’s been exceptions, there’s been, like, awesome
people that were in that, but it’s like, but most of
them had left or never joined. Because if you’re a real
product manager, you’re like, to be honest you might get the
title product manager at one of those companies, but you’re
not doing the product job. You’re really a project
manager with a fancy title or a backlogged administrator, you know, you’re a product owner, which
is an administrative role. – Or if you’re a really
professional designer, it’s like, you don’t want to work there. Because you’re not able to
do your job, you’re not able to apply your skills, you’re
just there to make it pretty, put on the company, you know, color scheme and logo in the corner. – When the PM has
already handed you, like, a fully done wireframe and it’s like, oh, just add the visual design. (laughs) – And so what competent
designer really wants to work in that environment, and
frankly the same with engineers. I’ve long argued that if you
just use your engineers to code you’re really only getting
about half their value. – ‘Cause the real, a professional
engineer, the kind that we love to hire, they are as
into coming up with a solution as they are to delivering the
solution, so that’s a big one. You need to staff the team with
the skills that are needed. And so there’s a give and take, you know, we’re starting to get
into how do you move from that old model to the new,
but the big things are you have to provide the
team with the capabilities. So this is what we invite, we
go cross functional product team or squad, which is product
design engineering typically and then you have to get the leaders to entrust the team to solve problems. – So that’s where I have a question. I think, it makes sense to me
at the individual, sort of, team or squad level, to
say oh, this is the problem that we need to solve, go
figure out how to solve it. Like, that makes sense, but
then as I’ve transitioned from individual contributor
into product leadership, having, I get this question,
which is, you know, how do you communicate in
outcomes in a way that makes sense to someone who’s not super
close, who might ask a question like, okay, but what do I get for it? Like, who needs to see some
sort of tangible, you know, for lack of a better word, feature, that they are gonna get from their teams? – So just to be clear, your
context is you’re wondering, like, what do you tell a stakeholder? The VP of marketing or
something like that. – Yeah, ’cause to your point
that we were discussing before we started, I
don’t think anyone wants to not work in this model, right? If someone, you know, if we’re– – Well, I will tell you, lots of people don’t wanna work in there,
especially the stakeholders. Because, let’s pretend.
– Okay. – Let’s pretend, I don’t
wanna pick on anybody in particular, could be any
role, but, like, VP marketing. Or merchandising in an e-commerce company. Which is a really
critical role, by the way, or the editorial in a media company. Any of these sort of common stakeholders. They very likely have very strong opinions about how to solve the problem,
and that’s human nature. I never fault anybody for
that, it’s human nature. I do it too, we all do it. – [Maggie] We all do it, yeah. – So, but, that’s very
disempowering to the team, first of all, but even more
importantly, if you look at the numbers, Harvard Business
Review actually did a story on this last year, but most
of the time we’re all wrong. – Definitely. – Most of the time we’re wrong. – Yep. – Now, so the way it actually
is much to our advantage to give them the problem
to solve rather than the specific solution
that may or may not work. Now, it shouldn’t, with the
stakeholder, if they don’t know the problem to solve
you have a bigger issue. They usually do, for example,
the VP of international may be really suffering because
nobody can pay, you know, they can’t pay all the
payment methods in the US are not accepted there, and
so they’re like, come on, we need to get our, we need
somehow for our customers in Europe to effectively
pay for our services. And it’s clearly not happening. Now they might have an
idea on how to do that, they probably do, they
probably saw another company that added PayPal and they’re thinking maybe that’s what did it
or that’s what’ll help, so they might have an
idea, and that’s fine. It’s not very hard to get
them to say, look, the problem you wanna solve is
international payments, right? And where are we today? Well, only 1% of our customers
are buying internationally. Where do you wanna be? Well, we can’t even have a viable business unless we’ve got 5%
actually able to do that or some dialogue there, and now we know the problem to solve, now we
know where the goalposts are. And now we, if we have one of these teams that we’re talking about, a product team that’s actually empowered,
they’re told, go solve it. – [Maggie] Okay. – Go solve it in a way that our international customers love
but works for our business. You know, that means legally,
that means financially, it means sales and
marketing can handle it, our go to market is set
up for that, we can afford to acquire customers, the
sales cycle, all of that. And that’s what good product teams do. So it shouldn’t be hard to
explain, it is hard, though, and this is what I’m gonna
acknowledge, if you have a very strong opinioned
executive from international that’s been there, done
that, at some big companies. And it’s really not gonna
be a problem if it was one of the companies that are
really good, but if they’re one of the majority, you’re
working in the old way, they are probably gonna say,
look, here’s the roadmap. – Yeah, so, like, how do you
help teams move away from that and into this model of
focusing on the problem? ‘Cause I think, you know,
even we have really strong product founders, who
have really strong vision about how they want the
company to go, and, you know, I think even for us
it’s hard, we fall back into talking about features,
because it’s easier. – It is, it’s normal. And there’s nothing wrong
about really talking about features, it’s when they get etched into a roadmap
that we get into trouble. Because now it’s a commitment. – [Maggie] Right. – [Marty] And that’s
where we get into trouble. Mostly because we’ll end
up building and delivering something that doesn’t actually
work and we should have been using that time to solve that
problem in a way that does. – Yeah, one thing that we’ve
started to do is we had a couple of ideas that were sort of, like, actually maybe this is a better question. How do you approach features or products that might move the market
forward in a way that it’s like you might not even know how
to articulate the problem yet? – Well, so let me just say– – Like, do you think everything can be articulated as a specific
problem to be solved? – I do, although there
are, I will admit there are some cases where you kinda
have to bend over backwards. That’s mostly platform stuff. – Okay. – And we can talk about that if you want, but you know what you’re getting at. So there is a very popular technique at very good companies today for this. They’re called OKRs, you’ve
probably heard of OKRs, right? And most people have. It’s honestly simple:
objectives and key results. The interesting thing
is those were created, that system was created around
the model I’m talking about. – [Maggie] Right. – But it’s being, well, it’s
been used for over a decade at Google, and LinkedIn, at
Facebook, all these companies, and so everybody’s trying
to do it, and unfortunately, even though it’s a simple
concept it’s usually a complete mess at most
companies and I try to explain what’s really going on is,
yes, it’s an easy concept if you’re already in
the empowered team mode. If you’re not, it’s sort of theater. Because what’s going on
is you still do roadmaps, yet you still are trying to
tell people problems to solve. The combination of both, I’ve never seen that actually make sense. It’s meant to be the alternative to that. So, and is it hard to express things? In general, no. You have to use some common sense, though, because if you have a
platform team, for example, that is fundamentally there
to help the other teams solve problems for
customers then could you express what they do in problem solving? Yes, but it’s really convoluted. – Definitely. – So I usually tell people,
you know, chill a little bit and bend the rules, it’s okay there. But you need to keep the focus for those customer facing teams,
especially, on problems to solve. Yeah, it’s not hard. There’s actually an old
technique that’s been around, it’s super easy technique, it’s called an opportunity assessment,
it’s just a few questions. So when somebody gives you that
feature, like, add whatever in just 10 minutes you can
reverse engineer what the problem to solve is and what
they measure as success, it’s super easy technique. So that’s never been hard. And I think that’s
always, if it’s not clear why we’re adding this,
you know, it could be for lots of different reasons,
then that product manager, it’s on the product manager to make sure the team understands, really,
what the measure of success really is, what is the
problem under there? And it’s not hard, it just
is a dialogue with whoever that vice president or CEO
is and say, hey, we’ve been thinking about this, we’re
ready to get working on it, but we realize this could
actually be for several different purposes, so we
wanna make sure we do it for your purpose and solve the
problem you’ve got in mind. My assumption is we’re
doing it because of this. Is that right? And they might say no,
or they might say yes, but either way we know
what we need to solve. – Right, and the thing that
we, the tool that we decided to try using, at least now,
is we had a couple of examples where there was an idea
and we just built them. And, you know, built them
super quick, super scrappy, but then realized that
maybe it wasn’t actually the best idea to have
just hopped to right into building the feature, so now
I think it’s probably similar to the opportunity assessment
you were talking about, we have this idea of a concept
where, you know, no code, not really any meaningful
amount of design, but really just a PM taking
a step back and saying, okay, if we were to do this
this is what it would look like and this is the impact it might
have, as a tool to kind of evaluate and, like, share back
the impact of those ideas. – Yeah, I mean, you’re describing a very primitive way of doing discovery. Now the first thing I’d say is that’s why we have prototypes. And there are four main
kinds of prototypes, that’s what they’re for. – [Maggie] Yeah, yeah, yeah. – [Marty] And the other thing I’d say is it’s really bad if it’s
just the product manager. You’ll get really bad solutions. You want it to be product
manager, designer, and at least one of the engineers. But you’re right in it’s no
code, it’s quick and dirty, because everything changes
once you can play with it. – Oh, for sure. – So that’s what we wanna do. – Yeah, and when we
actually go to build things we do start with the jobs
we’ve done and we start with the story time, which is product design. – [Marty] But still I
would argue you’re mixing, ’cause now we’re talking building things. – [Maggie] Yes, yes. – [Marty] That’s delivery. For discovery we don’t wanna
build anything, we wanna… – Right, no, what I’m
saying is when we start discovery on a problem
we start with the problem and then we get everyone in
the room, product, engineering, design, to do that initial
generative idea phase. – Okay, that’s good,
shouldn’t need to spend much time on that ’cause you really wanna spend your time on prototyping. – Yeah, so that’s 30 minutes. – Okay, good. – Maybe an hour. And then we go into a phase
where it’s prototypes. Tracer bullets, technical tracer bullets, it’s designs, it’s
concepts, it’s research, it’s iterating on those ideas
before we do any kickoff. – [Marty] Before you build. – [Maggie] Yes. – [Marty] Good, good, you’re
kinda framing it in waterfalls so that’s part of what makes me a little uncomfortable with this. – [Maggie] Which part? – [Marty] Like phases and
handoffs and kickoffs. But the spirit at least
at the higher order you’ve kinda got the right concepts there. – Yeah, we’ve found that it’s
been really helpful to say, to have words to describe where we are. So that we can communicate out. – Yeah, I understand, but
this sort of, you know, waterfall is a real mindset. And it is a slippery slope. So I meet this all the
time, companies that say they’re agile but in all
meaningful sense they’re not. – So when people, so in that situation, like, what are you seeing? What are they saying
that they think is agile but that’s actually waterfalling? – Well, this whole idea of these phases is very waterfall concept. Now when I say that there’s really things that honestly I care about. – Okay. – The first one is are we actually tackling the risks upfront? There’s value, usability,
feasibility, viability, these are the risks in all
product and we need to make sure we are tackling those
before we write a line of software for delivery,
and what you said did sound good for that to me. The second is how are you
actually solving that problem? Are you solving it with
some product manager defining requirements
and designers, you know, doing wireframes and engineers
coding, or are they literally side by side coming up with prototypes? ‘Cause that’s critical,
that we have those three. And waterfall kinda separates those. And third and really the
most important one as far as the defining characteristic
is do you have, before you go into delivery, to building
things, are you, like, consciously saying, yes, this
is what we wanna go build? That is, unfortunately that’s
a defining characteristic of waterfall because we really are not, we don’t succeed when
we ship that feature, we succeed when we
actually solve the problem. So you don’t wanna have a phase that says, all right, we’ve done our
design or whatever and now we’re in the implementation, because in truth we’re gonna be iterating many times. And so the success is
not launching a feature, the success is our KPI
has finally achieved what we needed it to achieve. If we were trying to improve
our international purchases to 5%, once we hit 5%
we’ve actually achieved. And that’s what really, when
you have agile sort of the way it’s intended to be is that’s
what we’re really doing. We’ve got an empowered
team that is trying to solve a problem, it’s not
just about shipping a feature. So you can kinda see when
you have these defined sort of milestones, it
kinda works against us. It’s not impossible, and the reason I say it’s not impossible is because
there’s a class of product called consumer electronics,
for example, devices, where you kinda have to
have an element of that. – [Maggie] Right. – [Marty] ‘Cause you can’t
literally change the device. (Maggie laughs) So we have to do what we’re
talking about in discovery and then there is, kind of,
and there’s a lot of praying with devices, you know,
there’s a lot of, like, man, I hope we did that right. – So one of the things
that I think has helped us, or at least the benefit
I’ve seen of the moment where we decide, okay, you
know, we’ve done a bunch of discovery, we’ve evaluated
a bunch of different ideas, we’re gonna try this
first thing that we think is the best opportunity that
we have to solve the problem. And we scope, we just
agree as a team to, like, what that’s actually gonna look like, the first thing that
we’re gonna ship, to like, move towards solving a problem,
and I think having a moment, and it’s, you know, 10
minutes where we all just look at each other and say,
yeah, we’re gonna try this one, this is the one we’re
gonna ship to customers has helped set better
expectations between the team and better timelines so we can
communicate with each other. – Yeah, I would, if I was
coaching that particular team, I would encourage them
let’s do that in discovery. Let’s get the evidence from
our customers in discovery. Now they might not know the techniques, they might say how do we do that? And that’s easy. – Are you including, like, let’s say a beta group as part of the discovery? – Beta is normally a delivery
technique, it’s more like QA. But it is, in the looser
sense of am I talking about a select group of customers
that have opted in to try out new stuff with us, yes, definitely. You can call it very limited distribution, there’s actually a lot of
techniques and it depends if we want to do
qualitative or quantitative. But the point is we
would do this and gather this evidence in discovery before, we might not even decide
to build anything. – [Maggie] Definitely. – [Marty] As a result of that. Instead of sorta saying,
well, ’cause your assumption behind what you said, I
would argue, is the only way to do this is have our engineers
build it and we’ll ship it and see how it works, even
if we just ship it to beta or something like that, and
that’s a really, first of all it’s not a correct assumption,
but it’s really expensive to do that, that’s a very
expensive and slow way to test. – Okay, so how do you move from, is it wrong to think there’s
a point at which, you know, you built several prototypes,
you have done a bunch of customer research, you’ve
been talking to customers, showing them designs,
showing them the prototypes, but there is a point at which it’s like, it’s better just to go for it? – Absolutely, I mean, there’s
always judgment call on this, and I mentioned there’s always, I mean, this is my taxonomy that I use. You just need some risk at
taxonomy, so you think about all the risks, but I thought about value, which is would the customer buy it? Usability, could you
figure out how to use it? Viability, do we know how to build it? Sorry, feasibility, do we
know how to do it, build it? And viability is can it work for the different parts of our business? And if it’s super expensive and risky you’re gonna do a lot of validation. If it’s not, you’re
gonna say, you know what? We’re gonna just go for it. – [Maggie] Okay. – [Marty] And I tell teams
you have to make that call. If you don’t make that
call you won’t have time to actually spend the time
on the real risky things. So you have to use your judgment. It’s typically when the
production manager, the designer, and the tech lead discuss
it and they’re like, are we okay with this? Let’s just go. So, or they might say, the
engineer might say, you know, this is gonna be really
expensive, we need to see if this is gonna work before
we spend the time to do it. So here’s what I propose
as a way to solve it. – Okay, so I wanna go
back just a little bit to the difference, like,
the real difference between discovery and delivery. ‘Cause I would imagine
that there are teams that get them a little bit confused. – [Marty] Definitely, and I would argue that’s what was kinda going on before. – [Maggie] Yeah, yeah, yeah. – [Marty] Yeah, I mean, it’s not meant to be rocket science or anything. Delivery is where we build products our customers can run for real. – [Maggie] Okay, for real. – That’s for real, so that’s
stuff that you can ship without apologizing, you
know, sales and marketing. And when I say apologize it’s
not like, oh, this is an MVP, this is whatever, this
is, no caveats, they can, you can sell it and stand behind it. – Okay. – So delivery is, and that’s
what we mean by product. – Definitely, okay. – Discovery’s all about figuring
out what we should build. So that’s why I try to tell people discovery’s all about prototypes. You don’t want, if you build
a product in discovery, which by the way is what
most people do when they misunderstand what an MVP
is, they build, they spend four months building a half baked product and they call it an MVP. That is, like, the opposite,
so that’s just confused. This should, we should, we
have much better techniques, shouldn’t be four months,
should be more like four days. And for a lot of the techniques
we have more like four hours but, so, discovery we use prototypes. But really the purpose of discovery is to tackle those four risks. And once we feel like, you
know, once the product manager and designer and tech, we feel
like these are reasonably, we have some reasonable
evidence that it makes sense to actually use our engineers
to build production quality scalable version of this, we go do it. Sometimes we’re still
wrong, I consider that a very acceptable failure, you know? ‘Cause if you optimize just
to get all the risks perfect you’ll go, you know–
– It would take forever. – Take forever, so you have
to use your judgment there. – So, okay, last question, sort of. You just said when they feel
like they’ve hit the end, and it’s all ready, have you
seen teams quantify that? Or is it really, like, your feeling, it’s a feeling between
those three stakeholders? The PM, the designer, and the tech lead. – Yeah, and we wouldn’t,
stakeholders kind of– – Sorry, the three people. – Yeah, and usually it is their
judgment that you’re there. But I will give you,
there’s a lot of examples where we do feel like
we need to quantify it, but now we’re talking
about, just to be clear we’re talking about the scenario
where it’s really risky. When I say really risky
meaning it’s gonna be expensive to build or it’s gonna be
really expensive to deploy or any of these things that up
the consequence of screwing up. – Yeah, definitely. – Hardware, by the way,
is by definition risky. – Yeah, I think working
in Sass it’s sort of, there’s not a lot of things
that are very, very risky for us to do, so, I
mean, we are a little bit more comfortable with
just sort of going for it. – Yeah, I would argue the big consequence in Sass is opportunity costs. In other words, if you spend
three weeks building something and then launching something
and it doesn’t actually do what you need, the biggest
cost there is what you should have been doing
with those three weeks. It is also true that a
lot of people do, I mean, in the beat of the Sass
world, as you know, there’s a lot of terrible
solutions out there. – [Maggie] Yeah. – [Marty] Just terrible, that’s
what creates opportunities. – [Maggie] Absolutely, yeah. – But there are really terrible solutions. And that’s a pretty expensive consequence of not doing their job,
I would argue, well. So yes, sometimes we do
have a very explicit bar and we’ll say, look, this is
really risky or expensive, which is a form of risk, right? And so we are going to set the
bar here, high on evidence. Which may mean, in fact, proof. Sometimes the bar for
evidence is proof we want to be convinced it is
absolutely going to work. The gold standard for
proof is usually an AB test with a live data prototype,
it’s kind of our, that will give us the best
evidence that what we build will actually work as we hope. But that’s more expensive than
some of the other techniques so that’s why we consider
all these alternatives. – Yep, I’m trying to think
if there’s any other question I can ask that I can thinly
veil my own work (laughs) to get your feedback on. – Well, you, I’ll just,
’cause you mentioned my big focus for, like,
the last several months is what I think you just
described yourself as, which is somebody who moved
from an individual contributor, product manager, maybe,
to a leader of product. That’s, I’ve decided that’s,
like, the most important place for me to focus my
time, because, and we can talk about that if you want.
(Maggie laughs) Because, basically the whole
model of empowered teams the teams are only as good
as their product manager. And I wanna be clear,
I’ve never met a good team that didn’t have competent
people in product design and engineering, I mean,
you need all of it, but it’s also true, I believe,
that if the product manager’s not strong you’re gonna fail. And so who do we hold accountable for strong product managers? – The product leaders. – Yes, you. Director of product management,
VP product management, these are the kind of typical titles. And most of them in my experience are not actually doing what they need to do. – [Maggie] Okay, what do we need to do? – [Marty] ‘Cause that’s
the right question. – [Maggie] Tell me the way
in, what, five minutes. – And really, so the first and foremost, and I really should end it
here, I won’t, after this, ’cause there is other things,
but first and foremost is to coach your product managers. – Okay. – So many product leaders
I meet, that is like fourth or fifth on their list. – [Maggie] What’s above that? – [Marty] For them? Well, usually what they wanted to do. – [Maggie] Roadmapping? (laughs) – [Marty] One form or another,
micromanaging their people. Or, you know, handling
the CEO or the executives or doing vision and strategy
and so I’m gonna get to, there is other things, but
the point is number one needs to be developing, and I try
to say it more specifically. The director of product management’s number one responsibility
is to get each of her product managers to
competence, and that should, normally that takes no
more than three months for each person that reports to you. And that’s with active work,
you know, getting somebody, a new project manager, whether,
even if they’re experienced from another company, but on
your products, your markets, your technology, getting them
up to speed, your business, normally takes two to three months. If it takes more than that, the
product manager really needs to decide, sorry, the product
leader really needs to decide if that person’s gonna
be able to do the job. And a lot of ’em, you know,
they’re conflict avoiders and they are not really tackling that. But that’s their first responsibility. So that’s why I’ve been writing
a lot about coaching tools and here’s how you assess
the person and here’s how you help them in all their gaps,
’cause my experience is if the manager knows what they’re doing, if they’ve been there,
done that, you know, they’ve seen good, they know what it is, if they put a real effort
in, most of the time they can get their people
to where they need to. You know, assuming they did
a reasonable job hiring, they’re reasonably smart
and dedicated and committed, you know, if you’re looking
for the right things, you can get them there. Not always, I’ve not
always been able to do it. I mean, there’s some people
that are just, once they really get the product job they
really don’t wanna do it, so that’s fine, find them a different job. But the first responsibility
is to get them to competence. And I also wanna be clear,
’cause there is nothing wrong, like, I love university
hires, but I don’t care what university, we’re in
Boston here, we’ve got Harvard, we’ve got MIT, it doesn’t
get any better than that, none of them know how to do
tech product out of school. So that is, you know,
but those are often great new employees but there you’re not hiring for competence you’re
hiring for potential. But in that case the
product leader needs to commit to not just, like,
once a week coaching, we are talking about once a day coaching. And I love doing that, but
if the manager is not willing to put the time in to do
that, then you can’t hire, (laughs) you know, don’t
hire college hires, ’cause they’re not gonna
get the attention they need. So that’s the first responsibility. Beyond that, really this is
where product strategy becomes real, I mentioned what a mess
OKRs are at so many companies. The number one reason for that is the product leaders are
not doing their job. They think that the teams
are supposed to, like come up with their own
objectives and somehow it’s all gonna make sense at the end of the year. Which of course, is nonsense
if you state it like that. But that’s what they’re doing. And they’re not taking
an active enough role, so I don’t want those
directors to micromanage. The only case micromanaging
is okay is if you are trying to take somebody
right out of college and show them, really,
how to do their job, you’ve gotta provide more oversight. But our goal is to get them
to competence so that we can give them problems to solve
and not hold their hands. – [Maggie] So the product
leaders are supposed to coming out with the problems? – They are, well, it’s even a little more complicated than that. ‘Cause at the CEO level
there’s, and this typically comes out at the board of
directors meetings, right? They meet four, five, six
times a year and usually once a year they come up
with the annual objectives for the company, and
those are almost always business objectives, to be
clear, it’s rare that they come out with a roadmap but there’s some dysfunctional companies they do. But most of the time they come up with real business objectives like
we have to go international this year, you know, we’re
saturating the US, or whatever. Or our churn rate is too high,
that’s gonna be our focus, or we need a new product line
’cause we’re not diversified, these are normal board
discussions, and good ones. Then it kind of, like, what happens? What really happens in
most companies is that a bunch of executives
do roadmaps that they hope will hopefully fix
these things, but what we do if you’re really doing
an empowered team model, and that’s why OKRs are designed
this way, is that, okay, there’s a set of
objectives for the company, but now the product leaders
need to translate that into objectives for each product team. You know, if you’ve got five product teams it’s actually not that hard, if you’ve got 25 product teams it’s a lot harder. And so we wanna figure out,
because all the product teams are working on different things, some are working on one kind of customer, some on another, some are infrastructure, they’re all working on different things. And so the leaders have
to decide which teams should be assigned which problems. Now we don’t want to give
the teams the results, because that is disempowering, right? That is setting them up– – So in that, so what you’re saying is, okay, so we get the business objectives and then the product leaders translate those business objectives
into problems to be solved? – [Marty] Yeah, which
is what an objective is. – I feel like people say OKRs and I’ve had enough conversations about
it that I think people don’t, it sounds like people don’t
always understand the objective. – Well, that’s true, now a
lot of OKRs, when I see them, and the place you see this is not in the objective it’s in the key result. So if the key result
is launch this feature, it’s like, that is not a
key result, that’s output. So, and the point of
this is to get them to do the problems to be solved. – I have a vivid memory
of an OKR slide that had an objective and then
each key result was a feature. – [Marty] Yeah, this is just the normal sort of bastardization
of OKRs and roadmaps. They’ve just kinda been
mashed up together. – And then it was hit 80% this, but really it better be all green. – Yeah, I mean, that’s what
I meant by OKR theater. There’s really no OKR
in any meaningful sense in that model you just described. – No. – So, but now we’re talking
about how would you do it the way and the spirit it
was intended, you know? By Andy Grove at Intel and
this sort of, and the model is, yeah, so the leaders, and
honestly with your counterparts in engineering, you have
to do this together. But you say all right,
well, these teams need, let’s give this objective to this team, these objectives to this
team, and of course, their job, then, this
is what it means to be an empowered team and an
autonomous team, it doesn’t mean they get to go work on a
different kind of business, it means they get to go
figure out the best way to solve this problem, and then
they propose the key results and that’s a whole other
discussion how aggressive or ambitious you want
them to be, but that’s, and there’s a lot of
give and take there too. Another team might say
we’ve got some great ideas to solve that problem, give it to us. We love that, that’s a
motivated team, right? – Definitely. – We love that, so we’re
not discouraging them from suggesting objectives,
but we do need to make sure, and this is where the leaders
to play a real active role, we need to make sure that
at the end of the quarter and even more at the end of
the year, we’ve delivered on as many of the company
objectives as we can. That doesn’t happen on its own. That doesn’t happen
when the teams are just allowed to go do their own thing. So what happens then? We’ve got a vacuum and
the stakeholders step in to fill the gap with
roadmaps, back to roadmaps. That’s really the second big
thing that the product leaders need to do is they need
to get very involved. Some people refer to
this, and I like this too, as holistic view of product,
you need to look overall. A lot of times the heads of
product and the heads of design are the first ones to
really see issues coming because they can connect the dots, right? – [Maggie] Yeah, ’cause you’re
sort of right in between the teams who are in the
front line and you’re getting enough of the context from
the C suite or the VPs or whoever’s above that you’re
sitting right in the middle and you can see, you can
feel the pain on both sides and you’re probably best
positioned to transit that way. – Absolutely, and the other
thing that you need to realize is in the empowered team
model squads, which, I mean, to me it’s all about optimizing for them We could talk all day
about how we do that, but it’s also true that
the more you have of them the less you can expect them
to see the whole picture. Because they’re, you
know, they’re hugely busy solving the problems
they’re supposed to solve, which makes it even more
important for the leaders to connect the dots, to say,
hey I know you don’t know this, there’s no reason you would,
but there’s another team over on the platform side
that’s actually working on something very related to this,
you need to go talk to them. Now eventually somebody would
have figured this out, like, six months too late, but that
is the job of the leaders is to connect the dots this way. – Yeah, one of the things I found, we’re running out of time, that
I found to be really helpful is at the director, VP level
across all of the teams, making sure we have a forum
for constantly talking about what we’re doing, and
even just setting up a space for us to have a conversation
between design and products and engineering at that
level is hugely valuable, because we’re sharing what we’re
learning, what the problems that we’re encountering and
inevitably every single time someone says, oh, well, we’re
gonna, we have this thing that’s going on and it’s
gonna solve that problem. Or this team can take that on, because, you know, they’re handling this thing. – [Marty] I personally
like it when the leaders of those three areas
actually sit together. – [Maggie] Oh, yeah. – [Marty] I mean, I make
a big deal that, again, it’s all optimizing for the
product team, they should, if possible, sit together,
at least, but a lot of times the leaders of the areas
don’t sit together. – Oh, so they’re in
their, sort of scattered. – They’re in their wherever and it’s just there’s such a synergy that
happens when those people sit together, it just makes it
a lot easier to communicate. So many of the issues are
serendipitous kinds of things. They’re just random. – Yeah, okay, so we
have, we’re out of time. But I have to ask you, are you reading or listening to anything
that you think we should all be reading or listening to to
get better as product people? Anything you’re recommending? – [Marty] Well, I’m
always, there’s so much. I just finished a wonderful book and I recommend it to all product people, that’s the one called
Trillion Dollar Coach. – [Maggie] Trillion Dollar Coach, yep. – Yeah, Eric Smith and
Jonathan Rosenberg from Google, former CEO and former head
of product, they had written the book How Google Works
if you remember, which was a good book, but they were
also coached by Bill Campbell. And so they, Bill Campbell
died a few years ago and they had the idea to go talk
to lots of other people that were coached by him and put together, really, a book of his lessons. It’s not like a academic
business book in any sense, doesn’t even pretend to
be, it’s really just like this guy’s life principles and lessons. And I thought it was probably
one of the best books out there now for, really,
business in general but especially for product people. – Okay, and then one piece
of advice that you would give to PMs and product leads who
are listening or watching? – Well, the thing that
constantly drives me nuts is so many product
people, product managers, whether they’re titled product
owner or product manager, they think the job is what’s taught in a certified scrum product owner course. They think the product owner role is the product manager job. It is a responsibility of the
product manager, no question. But it’s like 5% of
their responsibilities. And so to me, this is kind of
the biggest obvious problem. And I hate to say it but I actually think the average skill level of
project managers has dropped over the last several years,
and I think the biggest reason for this, not ’cause
people are dumber or whatever, it’s because too many of
them think that’s the job. And I realize I give mixed messages, too, ’cause I’m like you should
absolutely take a CSPO class, it’s easy, you’ll learn
the rituals that are part of the process you’re using,
whether it’s scrum or Kanban. But you’ll also learn
your responsibilities as product owner, but
that is not the job of a product manager, that’s just
one of many responsibilities. So it is really important,
otherwise, and I’ll tell you why I make such a big deal, is I’m
on the other side trying to convince CEOs to give their
product people a chance. And how can I do that if they’ve got these incompetent product people? – So the advice is… – Is learn your job,
do your homework, yes. – Do your homework. – I’ve written a lot, I
mean, even separate from my, I’ve written a lot about
look, this is your job. – I know, I read your
articles all the time when I have a question. – But I’m trying to, you know, I’m trying to be really clear about it. And I fully admit it’s a
hard job and a lot of people don’t wanna do it, but
if you do wanna do it, you know, I think you need to do it well. – Awesome, well, (laughs)
thanks, Marty, for coming in. I appreciate you taking
the time to school me on all things that I’m doing
probably a little bit wrong. – Thank you for being my guinea pig. (Maggie laughs) – Thanks. So, everyone who’s listening or watching, please leave Marty a review,
six stars, obviously. I haven’t gotten very many recently so I’d really appreciate
some, and let me know if you have any feedback
at [email protected] Thank you. (upbeat music)

1 thought on “We Talked To Product Management Legend Marty Cagan. Here’s What We Learned | BUILD Podcast

Leave a Reply

Your email address will not be published. Required fields are marked *