Subscribe
Share
Share
Embed
Every product leader has to make them: the high-stakes decisions that define outcomes, shape careers, and don't come with easy answers.
The Hard Calls podcast, hosted by Trisha Price, features candid conversations with product and tech leaders about the pivotal decisions that drive great products and the pressure that comes with it. From conflicting priorities and unclear success metrics to aligning teams and navigating executive expectations, you will hear compelling stories and best practices that drive business outcomes and help you make the Hard Calls.
Real decisions. Real stakes. Real leadership.
Presented by Pendo
Learn more at pendo.io/
Follow Trisha Price on LinkedIn: https://www.linkedin.com/in/trisha-price-3063081/
Trisha Price: If you build
software or lead people who do,
then you're in the right place.
This is hard calls, real decisions,
real leaders, real outcomes.
Hi, I'm Trisha Price, and welcome back
to Hard Calls where product leaders
come to talk about the business outcomes
they're accountable to and the hard calls
they have had to make to achieve them.
Today's guest is one of the
most influential voices in
modern product management.
Marty Cagan partner at the
Silicon Valley Product Group.
Marty has spent decades shaping how the
world's best tech companies build product.
He started with executive roles
at eBay, AOL, and Netscape, and
he's continued his work advising
product leaders across the globe.
He's the author of three foundational
books in the product world.
If you haven't read them, you should.
The First is Inspired, How to
Create Tech Products Customers
Love, the second, Empowered Ordinary
People, Extraordinary Products.
And the third, my personal favorite,
and one we're gonna talk most
about today, Transformed Moving
to the Product Operating Model.
Through Marty's writing, coaching,
and speaking, he has helped redefine
the role of product teams moving
from feature factory to strategic
driver of innovation and growth.
His work is read, taught and referenced
by product leaders everywhere.
Marty, welcome to the show.
Thanks very much, Trisha.
Thanks for inviting me.
I'm so excited to have you here, and as
you know this is the Hard Calls Podcast,
and so I like to kick off each one of
these sessions to just hear from you.
If you look back over your product career,
what has one hard call that you've had
to make and what made it so challenging?
Marty Cagan: Well, first of all, you
probably people who could do the math.
Man, I've had a very long career, I mean,
literally 45 years doing tech products.
So a lot of calls and a
lot of mistakes for sure.
Honestly.
Um I'm guessing what you're really looking
for is hard calls that you kind of regret.
The hard calls that went
well make you look smart.
But hard calls that don't go
well are humbling for sure.
And honestly, they're the ones
that really stick in my head.
The other thing I'd probably admit
is the first half of my career was
as an operator really running product
organizations and, the calls for that
are a lot harder than the second half
of my career, which was is as an advisor
and coach where I give my opinion,
but really it's whatever the person
wants to do and I try to support 'em.
That's much easier.
So the calls I do, you could say, well, I
make some hard calls on what to call the
product operating model in a new book.
But really it doesn't matter
that much in the world whether
or not you get that right.
I would, I mean, we all have scars.
I have scars that my last real
job was running product at eBay.
And at the time we were actually
twice as big as Amazon, so it was a
very major property for the internet.
And I remember that one of the,
and the good news is it was young
and it was growing and there was
opportunities everywhere and we
did a lot of very good things.
But there was one big product called,
that I remember, that I personally made.
It was a huge mistake and I
really learned a very hard lesson.
I don't know how much I could spend an
hour telling you about how, what made
it hard and stuff, but fundamentally,
we had just acquired PayPal.
And, the hardest part for people on
early eBay was just paying for something.
They were literally sending
checks through the mail.
I mean, a lot of people were born after
what I'm describing, so it was a long
time ago, but it was, this idea of
integrating a real payment solution.
There was some crummy ones
before, but this was good.
Was something that we were really
excited about and it was one of
those rare eBay's, a marketplace.
So there's buyers, sellers, and then eBay.
It was one of the rare win win-wins.
Buyers wanted it.
Sellers wanted it.
We wanted it.
It was just a great win, and we tested
the hell out of it because this was a big
change to the workflow to list something,
a big change to buy something we did.
We tested the hell out of it.
We did all the practices
that, you try to advocate.
Because of other mistakes earlier you
learn that are really important to do.
And we did it.
And I remember, 'cause we got in
this, right before we launched,
we had a, we all sat down with
the CEO and said, are we ready?
And I'm like, we're ready.
This is gonna be, this is,
we're, we're so excited.
The community knows about it.
They're excited about it.
The people that tried it loved it.
Anyway, we launched it.
It was a disaster.
And it was a disaster.
It's one of those things, whenever you
launch something big, you're kind of
looking at the data because it's normal
that there's a little bit of a dip because
it's basically people are learning how it
now works and then that's normal, but you
expect it to go up again and get better.
And it wasn't.
And I'm like, finally, oh my God.
I know, I know what happened.
We screwed up.
I screwed up.
and, and this was a lesson
that I've got so many scars.
I share this with so many companies
even today, that it's not enough
that people love your product.
It's not enough.
They also have to be able to digest it.
And what was going on was, even though
these buyers and sellers were screaming
for this solution, that doesn't mean they
were screaming to change how they work.
And, I remembered that very
early when I met the co-founder
of eBay, Pierre Omidyar.
He had warned me about this.
I don't even know, I actually haven't told
this story in probably more than a decade.
I'll tell you the story just 'cause
it's hilarious, but feel free to edit
it out if you go because it's very old.
But I thought this boy, I should
have listened to him harder on this.
He was explaining to me that,
'cause I had only done products
for developers before eBay.
So I was a platform guy, developer
platform, and I love developer
tools and eBay's this weird
marketplace with all these crazy
buyers and lots of crazy sellers.
Just very different personalities.
Very fun, but very different.
He was trying to explain to me,
they're not like developers.
They're like, they're very,
they view it as their website.
They view it as their solution,
and and we are just the custodians.
Trisha Price: Mm-hmm.
Marty Cagan: And he was telling
me right, in the earliest days, he
had no idea it was gonna take off.
Like this, but, he just whipped together.
He was a front end developer.
He whipped together this website
that just looked hideous.
You can find out on the way back machine
just how hideous eBay used to look.
It was really, really ugly.
Probably one of the ugliest sites ever.
But it worked, right?
So it was taking off and, he
was surprised because, news.
Crew.
Actually, the San Jose Mercury
News, for those of you that know,
your internet history, they were
like the regional newspaper.
They said, this is, we'd
like to interview you.
And, and, and they took a picture
of the screen and he was embarrassed
because now he sees on a newspaper
this hideous screen, so he says, oh
my gosh, we just have to fix this.
And like, like they hired their
first designer and they just.
All he actually did was
change the visual design.
They literally just changed the color.
Uh and because they had this hideous
background, yellow background,
it was just, you don't do that.
Right?
And, and anyway, he, all they
did was change the color and
they had their first online
riot.
They literally the the buyers
and sellers made petitions online
to get eBay to change it back.
And he was like, I, I'm not
trying to pick this fight.
This this, and so we just said whatever.
And they rolled it back.
They rolled the whole thing back and
he, but he was still very embarrassed.
And, the comp, the company kept growing
and then a TV station wanted to interview
him and he said, well, this is, I
just can't go public like this again.
But he said this time he was smarter.
This time, what he did is
over the next two weeks.
Every two days, they rolled out a
slightly lighter shade of yellow.
Wow.
And in two weeks it was gone.
There were no yellow and
nobody said anything.
And he was trying.
And I laughed, I thought it was funny.
But he was trying to con explain
to me that change for a community
like this is really, really hard.
And I, I learned what he was really trying
to explain to me when I made that mistake.
Yeah, on the payment stuff.
But it's true.
And Facebook has made this mistake.
Twitter made this mistake
a lot of people do.
It's it's a hard lesson to learn.
But anyway, when you do it this
long, you acculate lots of lessons.
Of course, learned like this.
Trisha Price: I mean, Marty, that story
is still so true for all of us today.
I'm sure.
Very true for the companies
you advise and help.
Change management's hard and if we're
in the business of not shipping features
and celebrating, but getting outcomes,
thinking about how people can consume what
we're changing and putting out there is,
is a super important part of what we do.
So that's still super relevant.
And, and so with that, Marty, one
of the things I'm really excited to
learn from you about today and talk to
you about today is operating models,
frameworks, and you and I both know
we, we see product leaders, product
teams all across the world, and almost
all of them, not all of them, but
almost all of them have some sort of an
operating model, a cadence, a framework.
But a lot of times it's still
falling short in terms of driving
the outcomes that they're trying
to achieve and accountable to.
So, Marty maybe you could just
kick us off with why that is.
What are most people getting wrong?
Because I know you seeing this time
and time again was very influential
for your most recent book.
Marty Cagan: Yeah.
Well, I mean obviously everybody works
some way, and, that way, they often
will call their framework or their
SDLC or their, their operating model.
So, but if you look closely
at most how most of them work,
it's all around projects.
It's all around features
and projects in particular.
It's not around outcomes.
Now sort of easy to understand
why it's not around outcomes
'cause outcomes is hard.
Outcomes is super hard.
What it's about, and honestly,
even when they don't acknowledge
this, it's about predictability.
They're trying to optimize for
predictability, so they wanna predict
how much money they're gonna make.
They wanna predict when
things are gonna happen.
These are, and these are not
crazy things to wanna know.
Trisha Price: when you're running a
business those are important things.
Marty Cagan: Those are, they're
running a business and so they're
reasonable things to wanna know.
the, part that gets so many companies
is they don't realize that these are
things they can't know at that stage.
So that's a different issue.
But they, they set up their
whole way of working around this.
Though we, we call that the project model.
So you fund projects, you staff projects,
you build projects, you ship projects.
That's waterfall basically
is all around that.
The whole, the whole formal lifecycles,
software development lifecycle, product
lifecycle, stage gate, phase gate.
These are all just names
for the same basic thing.
You staff a project, you figure out
requirements, you design the solution, you
build the solution, you test the solution,
and finally you ship the solution.
Right?
Then you
Trisha Price: have a
big party, right, Marty?
Yeah.
Then you have a release
Marty Cagan: party and you, you
kind of feel like you need it by
then and, but unfortunately you've
sort of given up by then on outcome.
Because you've had to make real
trade-offs on what you're gonna do.
And so, and of course when the company
decided to do it, they only funded
it for a certain amount of time.
And there's all these, there.
The, the consequences of the
project model are so well known
because we've seen it for 40 years.
So it is really well known.
So many people all write an article that
talks about it and they're like, how did
that's what's going on in our company?
Are you listening?
No.
It's like, this is what
so many companies do.
However, if is not all the
companies, many companies figured
this out many years ago that that,
that's actually all about output.
And what matters supposedly is outcomes.
And what would we do differently if
we're trying to optimize for outcomes?
Well, okay, that's a very different thing.
Just shipping and not achieving
an outcome is an empty victory.
And the irony is, the teams that actually
ship for outcomes develop for outcomes are
much more likely to predict an accurate
date than those that are doing projects.
So it's, it's counterintuitive, but
anyway, that's, that's the case.
And so what we have been.
I mean, honestly, Silicon Valley
Product Group, I started it almost
25 years ago, and it was just about
sharing these techniques I would see
in the best companies because I was,
lucky enough to work at some really
good companies that had worked this
way, and yet then I started visiting.
Because I was told you I was
doing tools for developers.
Yeah.
I started visiting customers.
Yeah.
Early on I'm like, oh my God,
how come you work this way?
It's crazy.
Where did this come from?
And they're like, what do you mean?
This is how everybody works in the Midwest
and the East and Europe and I'm like
Wow, that does not look good.
And you're, you're not
happy with the results.
You don't seem to even like your jobs
and your customers are not happy.
Why do you keep doing it this way?
And it's like, well, this
is how we've always done it.
This is what our leaders know.
And again, there's a real
desire for that predictability.
So what, what the latest book is all
about is just sharing the, the techniques
that we see used in the best companies.
Trisha Price: And when people are starting
to move from this project model to a
product model, what do you think the
hardest hurdles for them to get over?
Is it the trust, the the giving up
control and empowering their teams?
You know what is it that is like the thing
that just catches everybody every time?
Marty Cagan: A lot of things.
So everything you mentioned for sure,
but more, so there's a lot of things.
In fact, the way I've really started
framing it as very much like a product.
What does it take for a
product to be successful?
Mm-hmm.
A lot of things have to be done
right For a product to be successful.
It's gotta have a good
design, it's good experience.
Of course, it's gotta
be technically feasible.
It's gotta provide real value.
It's gotta have a lot of things right.
And all it takes is really one
of those to go significantly
wrong and you've got a failed
product just like you'll
have a failed transformation.
So there are a lot of things
you've gotta get right.
The hardest things for, I'd say for
most of those companies to get right.
Probably starting right at the top.
So many people want to think of
everything we're talking about as
just a tech thing, an IT thing,
but it's not, it's a company thing.
Trisha Price: Yeah.
Marty Cagan: And so because it's a
company thing, it impacts finance,
sales, marketing, services, legal,
fine, compliance, all of these.
And so all that means if
the CEO is not on board.
Most of those people are
gonna be, passive aggressive.
They'll just wait, they won't do anything
or they'll get in the way literally.
So the CEO really has to have, they don't
have to be experienced in it, but they
do have to understand what's going on and
step in and show some leadership at times.
Mm-hmm.
And so that's a key one.
Another key one is, and it's one
of those things when I look back
over the years, I kind of regret.
Never tackling the problem of the name,
title, product manager because the title
product manager means so many different
things to so many different people.
Mostly because they're describing
the project model companies.
Or even worse, 'cause there is
even worse, when you talk product
owners, there's even worse.
Out there.
So I always like, I don't
wanna fight that battle.
I don't care what it's called.
Let's just call it a product manager.
It's fine.
It's just a different job definition.
But the job definition is so different
for the product manager on an empowered
team in the product model than a
project team or a feature team that
that's one that constantly get wrong.
They get wrong because HR
just wants to retitle people.
It's so much easier to just
retitle people, but it is
much harder to upskill them.
And these are very different skills.
At its essence.
A feature team product manager is much
more project manager, which is important
of course, but it's not this job.
Trisha Price: Same, it's, it's funny you
say that, Marty, because of my role at
Pendo, I get to also go in and talk to
product teams all over and, I was with
a very large company last year, and they
literally took their entire workforce and
took everyone who had a title of business
analyst and titled them Product Managers.
Yeah, that was it.
Classic.
They didn't train them, they
didn't see who had the right
backgrounds and skillset sets.
They didn't say, here's
the difference in the job.
They just said.
Business analyst, not even product
owner, not even project manager,
business analyst to product manager.
Marty Cagan: Yeah.
So I see that it's a classic one.
It's a classic one.
And that's the, that's the,
that's a big problem, obviously.
Another big problem is the
way they treat engineers.
Mm-hmm.
So many of them treat 'em as
outsourceable people.
Mm-hmm.
And they literally are outsourced
in a lot of these big companies.
And we have to explain to them,
no, in the product model, your
engineers are front and center.
In fact, they're the, they're
the best source of innovation.
If you care about outcomes, they need
to be the ones coming up with the
things that go on the roadmap, not
your stakeholders, not your customers.
It's a, again, a very different model,
which is sort of what we're really
describing now is probably the hardest
thing for most of these companies is
it's essentially a cultural change.
So we are talking about things around
culture, about who makes decisions,
how do they make decisions, how
do they make progress, where do
ideas come from, that's different.
And so, I've never been surprised
at why it's so hard to transform.
Because, I mean, these are big changes.
These are not, they're big changes.
Changes, but, but the good news is there
are companies that manage to do it.
Trisha Price: Yeah,
there
are.
And do it well.
And you're talking about you, you were
talking about the change and a lot of the
change you were talking about is sort of
in the ideation and prioritization phase,
which is obviously wildly different when
you're prioritizing and empowered in
support of a goal versus being told to
go ship something and now you're breaking
the problem down and trying to ship it.
But I equally see the problem in
terms of change on the backend.
And what I mean on the backend
is iterating, launching,
constantly tweaking,
experimenting, figuring out
what's working and not working.
And one of the problems I see is
they have an idea, companies teams
have an idea of the big goal, right?
Like, I want to get revenue
in this new product, right?
But like, how do I break that down into
something manageable and achievable
this quarter, this month, and then
prioritize against it is something I
just see people sort of get frozen in.
Marty Cagan: Do you see that, Marty?
Yeah.
Well, to continue from your last question
on all the things that have to be done
right, a whole other big question is
how do you decide what to work on?
Yeah.
And that's, that's usually
framed as prioritization when
you get down into the teams.
But at the higher level, how do
you decide what to invest in?
How do you decide what you're gonna do?
And, most companies in the
project model are used to doing
that with their stakeholders.
And they kind of all sort of make a bunch
of proposals for how much money they
think things would get and all this stuff.
The spreadsheet,
Trisha Price: the best Marty,
like the weighted spreadsheet,
that's like the death.
When I see that, I'm like, no.
Oh no, you don't have a
voting weighted spreadsheet.
Yeah, please no.
Marty Cagan: So that's what so
many do in one form or another.
I can't tell you how many I've seen.
Now, of course, if you're in the,
if you're using the product model.
That's a very different way of working.
Your job, of course, is, for the
product leaders, is to make sure
you're pursuing the most important
opportunities and responding to the most
serious threats, but more generally,
instead of top down, roadmaps.
Instead of that, what we're trying to
do is in two big things, product vision.
Which is, how are you going?
Product vision is not about
you, it's about your customers.
How is it gonna make you the
lives of your customers better?
Because if you don't manage to do
that, you're not gonna sell anything.
You're not gonna, so everything,
there are no outcomes.
That's right.
You derives from the product vision.
And most companies, of course, don't
do product vision, so it's only.
In my experience, it's really only
the companies that are trying to
do the product model that actually
do a serious product vision.
If a team company tells you, we do a
vision for every team, it's like they
don't even know what a vision is.
Right.
That doesn't even make any sense.
So a great product agent, at
least they probably have a feature
roadmap for each one of their teams.
Absolutely.
They do.
Right?
So when they do a real product vision,
that's a, for our organization,
maybe even for our entire company,
this is what we're trying to do.
It's gonna take somewhere between
five, 10 years to do this product
vision, but that tells us how we're
gonna make our customers lives better.
That's the first part, the
product leaders have to do.
The second part then is you can't just
go away for five years and do this.
I wish.
We wish we could, but we can't.
We have to actually pay the bills along
the way, and that's the product strategy.
The product strategy says, okay,
we've got probably only order of
five to seven years, it's gonna take
us to make this vision a reality.
We've got 20 quarters
between now and then.
Now we've gotta figure out what
problems do we solve each quarter.
Mm-hmm.
And what we're trying to do there,
like I said, is pay the bills
and get us closer to the vision.
The product leaders need to
prioritize those critical
problems to solve this quarter.
That is prioritization.
Once they've done that, now they
have a set of problems to solve and
a set of teams that are equipped to
solve them, and that's what they do.
They assign the problems to
solve to the product teams.
They discover a solution worth
building and deliver that solution.
It's not complicated or anything,
but it's very different.
The product model from how, the
spreadsheets we were talking
about, it's very different.
And most importantly, it
requires product leaders that are
skilled in vision and strategy.
This is referred to as the strategic
context, like Netflix likes to say,
lead with context, not with control.
Because command and control down, this
Trisha Price: is truly the opposite
of command and control and requires a
level of trust with your team that most
people are pretty uncomfortable with.
Yeah.
Marty Cagan: think you talk about that.
Yeah.
Yeah, we do.
Because that's really, if you
had to pick a single theme
undercurrent for the whole successful
transformation is probably trust.
Because, and I don't mean trust,
like somebody gets a blank check.
No.
It does mean that there's, instead of
the leaders making all the decisions,
even the ones that are really not
in a good position to make, like
enabling technology and the what
this customer needs right here.
They are making strategic decisions about
the most important problems to solve, but
then the teams are making the decisions
on the best way to solve those problems.
Trisha Price: Yeah.
Marty Cagan: And that though is
still a, significant degree of trust.
And one of the mistakes that a lot
of companies make when they try
to transform is that they think
somehow a CEO of a billion or
very, large company is just gonna
Give them that trust works.
It doesn't work that way.
And it, in fairness, it
shouldn't work that way.
Shouldn't I agree?
What if that company just renamed
all their business analysts to
product managers, they're gonna fail.
Any CEO that just trust them is, is
getting what they deserve, right?
Yeah.
So, no, we have to earn that trust.
And so the way we often frame a
transformation is it's all about winning
the hearts and minds of the leaders
of the company and the way we do that.
Is safe, small, low cost, low
risk experiments, which it's
really using the product model
to move to the product model.
Mm-hmm.
In other words, don't make a big project
to move to the product model where you
have, you plan out a year of all this
training and all this nonsense, instead
we pick a pilot team.
It's basically like an MVP Yeah.
Of what this is gonna look like,
and that pilot team is meant to
show your organization and your
leaders what good can look like.
Trisha Price: You pick
an outcome for them.
Yes.
And then you start doing
modern product discovery.
Yes.
Then you show them
Marty Cagan: experimenting.
Yeah.
Now once they see it works, especially a
couple times, it's a different situation.
Now for, lots of more teams want to move.
It's that whole technology adoption curve.
We're working through that and
the company starts to feel like we
should apply this to different areas.
This is a good thing,
but they know what it is.
And by the way, they also, at that
point, they know you can't just
retitle a business analyst because
they seem what good looks like.
Yeah.
So that's why it's so important to do
these small, low cost, low risk pilot,
show the company what success looks like.
You are earning trust
each time you do that.
Trisha Price: So Marty, it sounds
like, just the way we were talking
about, you can't set a vision and
wait five years to deliver when you're
working with these companies that are
moving to the product operating model.
They can't wait five years
to show progress and deliver
against that model either.
So tell me like, how, how long does it
take for these companies to transform?
How long does it take for them
to quickly start seeing wins
and, and start building moment
Marty Cagan: Good.
Well, there's two parts to that.
Two answers to that . The first one
is, how long does it take an entire
business unit to change, for example.
And the honest answer to that is
typically one to two years for a
business unit, and which means it's one
to three years or so for a whole big
enterprise with multiple business units.
However, the real question is how
long does it take to see results?
Because for the trust point,
that's the real question.
And that's usually a quarter, maybe
two, because that's why what we do is
if you try to change a whole company,
like I said, it's gonna be years.
Nobody's gonna give you that blank check.
If you try to say, let's pick one product
team in this business unit, that you've
said is very important, let's give them
a problem to solve that you believe you
couldn't have solved this before, but
is something that really is meaningful.
And let's set them up the
way we, best companies have
sort of shown that you need.
In other words where you don't have
these competencies, you're gonna get
these competencies, you're gonna coach
these people, you're gonna show them
how good team works, and then let's run
that for a, a few weeks, few months.
Yeah.
Trisha Price: When, you talk about
measures of success or outcomes, one
thing I see people get tripped up on,
on moving to this like, Hey, let's
just try something and experiment is
what's the measure?
Is it revenue?
And if they're in a sales led
company or a company, even with a
sales, large sales organization.
How can I be accountable to revenue?
because I'm not the one
selling the product.
So maybe give us a little bit of your
opinion on is revenue the right metric?
Does it depend on the company?
And if it's not revenue, what are
other good outcomes that product
teams can begin to set as their
north star and experiment to achieve?
Marty Cagan: It's kind of a tricky one
because, the higher order point is that
it's not always revenue, that that is the
right thing, but it is a business result.
That's the higher order
point a business result.
I'll give you some real examples in
a minute so this is not ambiguous.
However, sometimes it is revenue.
Yeah.
And, and that, and sometimes
it should be revenue.
I'll give you an example of
that in a minute too, where
it's like that is the business.
So, that's the result
everybody cares about.
So whenever you 'cause that same
objection, you hear that all the time,
it's like, well, we don't control.
First of all, nobody controls
everything except the CEO, right?
Right.
Nobody controls everything.
So if you, unless you're willing to just.
Push all the decisions to the CEO.. Yeah.
You're gonna have I say the same.
Trisha Price: How do you
think the revenue team feels?
Yeah.
When they get a crappy product and
they still have to make their quota.
Marty Cagan: Well, well I explained
because a lot of these product teams don't
even know that salespeople are commission
based and they are like, they're
completely dependent on their paycheck
goes whether that product is any good.
Yeah.
It's like how would you like
to sign up for a quota when you
can't even control the product?
Right.
So.
And I was taught, I mean, this is one of
the very first things I was taught, and
this is why management by Objectives OKRs,
are so powerful, is I was taught, look,
a lot of times revenue is the issue and,
the biggest driver on that is the product.
So if the product is not selling,
don't you think we need the product
manager to get their ass out of
the building and go sit with sales
and figure out why they can't sell?
I mean, like that's what I was
literally, I was, it was more
colorful language than that.
That was explained to me.
But I was like, and I'm like,
you can't say it's not, you
don't control the sales people.
You don't control finance.
You don't control marketing,
but you control the biggest
single factor of the product.
And the whole idea of a
cross-functional team is we should
go figure out what it takes.
Who else is gonna do that?
So, so don't run.
I tell people don't run from revenue as
a key result if that's the right result.
Just because you don't
control salespeople, that's
like a very lame excuse.
and by the way, I've made so many
friends and sales because they're,
they love nothing more than a
product person that understands.
Yeah.
Yes, for sure.
And they also know there's nothing
us product team can do more important
than give them happy customers.
It's all about happy
referenceable customers.
So this is not a bad thing.
Now that said, one of the product
coaches that we work with just published
an article, and I was particularly
interested in this one because it
was a company that we did not do
a transformation engagement with.
So most of the successes I can point
to are the ones my partners did
transformation engagements with,
because that's why they're my partners.
They're the best in the world at this.
However, the idea is that why can't you
just read a book, like Transformed, and
maybe get the help of a product coach
in and do the same kind of success.
The product coach is Gabby Bufrem.
You may have heard her name.
Yeah.
Oh yeah.
A terrific coach.
I recommended Gabby to this company
because she was one of the very
few coaches coaches I knew that
speaks Spanish and she's in Mexico.
And anyway, so she shows up at
this company in Mexico, it's like,
40,000 employee company, some travel
services company, and same thing,
they had tried to transform for years.
It was a disaster.
They finally, it's like she's, she's like,
you have to demonstrate that this works.
Let's pick a product team
and let's show a real result.
They picked a pilot team and in the
first quarter they showed a 40% increase
in conversion rate for their bookings.
Like, and now for those that don't
know, that's basically revenue.
That is everything.
That is revenue comes from that.
Yes.
And that's the kind of thing that, yeah.
That's what the business needed to see.
The power center in that
company was the head of sales.
No surprise.
It's right.
Yep.
That's what they sell
bookings at a resorts.
So, and it wasn't until he
saw that this really worked,
that anything really changed.
So that, and they did
that in a couple months.
Yeah.
So so's amazing.
So that's what we do.
That's, and that's a real result.
Now did her team, did the product
team have control over sales?
No.
But did they go out to the
resorts and actually test?
Yes.
That's what they did.
Trisha Price: Yeah.
That's amazing.
That's a great story and super helpful.
'cause I hear that a lot from my friends
in product, from customers that I talk to.
It's just, I'm not in control of revenue.
I'm like, well, you kind of are.
If you build a great product.
Marty, earlier when you were talking
about the transformation from project
to product, you talked about needing
at least CEO support because it
is more than just a product and
an engineering way of thinking.
This is something personally
I call whole product, which is
instead of thinking about shipping
product as engineering and product.
It's, does my sales team know how to sell?
It is the skew in my CPQ and, moving
to this whole product mentality.
And, and for me, like I remember my
early days of Pendo and I'm, I know
we all have this bad story somewhere.
We've worked.
I came in.
And I looked in Jira and it said
something was shipped and I had
seen release notes about it and I
went into the product, 'cause I use
our product all the time myself.
And when I went in I couldn't find
the feature to play with it and I,
oh well that's because it's fine to
flag and we've only rolled it out to
so and so because we haven't actually
taught sales and support, doesn't
know how to support that feature yet.
So.
It's not done.
And I'm like, well, then it's not done.
And, but then I went to engineering
and they were like, no, it's done.
Look in Jira, it's done.
how much of that.
Is a part of this transformation in your
coaching and move to outcomes for you?
Marty Cagan: Well, partly we just
need there, there's the model,
which is really a set of principles,
and then there's people executing.
Yeah.
And knowing how to do their job,
you're of course class talking,
classic product marketing.
Right.
so, and, and in a world of continuous
deployment, it's normal if things
are tested behind feature flags.
Sure.
And we make sure that's all good rigor.
But like you said, that wasn't done.
Then maybe there was a product
marketing person that said, well,
it's not done because it's not ready.
We're on week two of a three week
rollout, or whatever they might have had.
But if there's no answer to that
question, then it's just hanging.
Right.
Yeah.
And, and this is a, a good question
because that's really execution.
There is not rocket science here.
I mean, this normally
happens every single day.
So then there's a question,
so who is responsible for this
consistent, reliable execution?
There are two ways companies address this.
One of 'em I think is the
beginning of the end, and the
other is what good companies do.
The first is they say, well,
oh, we need a formal process.
So we need a release process.
And so clearly the product marketing
person didn't follow the release
process and if they would've
only, checked their whatever check
Trisha Price: box.
Yeah.
On template four A in the file,
Marty Cagan: Then of course the
product marketing person said that
this is a different kind of thing.
The template's not for
that, blah, blah, blah.
And, and so processes.
I, unfortunately, it's true that processes
in big companies, especially used as a
substitute for thinking, because what
you did is just common sense, right?
You came in and said, where
is this thing I, I am supposed
to be able to play with it.
It's not here.
What's going on?
All right.
The real, the second approach
is how do you ins, how do you
ensure consistent execution?
And this comes from constant
weekly coaching of your people.
So, for example, in that scenario,
and I've been in exactly your scenario
there, I mean, that's not that unusual.
Everyone,
Trisha Price: everyone has at
Marty Cagan: Who is in this case,
who's the product marketing person?
I probably would've said, no, let me
talk to the product manager first.
And I would've said, all right,
well, do you consider this done?
Maybe they say yes, but I said,
but I can't see it, so let's
agree it's not done right.
So then the question is, all right, so,
so why not, let's, let's figure this out.
And then we may realize either the product
manager didn't, do something they should
have, or product marketing shouldn't have.
But the point is, somebody
needs some coaching here.
And that's what we're
doing one-on-one coaching.
We're helping people
get better at their job.
And what's special I think about
product is that, it's so tempting
to write up something as a process,
but everything we build is different.
The risks are different,
the scenarios different.
The data is different, and this is
only becoming more true when you
build a feature on a foundation model.
So this is, even more of the case.
So the point is what we wanna do is
help people get better at their job.
And there's always areas people can
get better and better, and then they of
course become the ones coaching other
people on how to be better at their job.
So the real key to scalability that I
believe in was taught and is, is coaching.
Trisha Price: I love that.
Earlier you mentioned, and I'm, I'm
curious for, for my own purpose too, that
product managers are not project managers,
but project managers are still necessary.
Where do you think that fits in, like
when you talk about good execution?
If you have technically, if you
have all the right accountable
people who have the right coaching
and are communicating regularly.
Do you need a project manager?
But in reality, most of these
organizations that you and I are
talking about are fairly complex
and large, and it's not that simple.
And they would spend their
days chasing things if someone
wasn't there to help them.
So tell me your philosophy on that.
Marty Cagan: Yeah, and this is pretty
common, what I'm about to say in so many
companies is there is a crossover point.
At most startups honestly
don't need project managers.
They don't if, if you've got less
than a handful of teams, there
are so few interdependencies, and
the easiest way to see this is
impediments and just dependencies.
But at a certain point it's usually
around a half a dozen product teams,
the number of dependencies, the number
of impediments becomes such that
could the engineering manager do it?
Could the product manager do it?
Of course.
But is that their best use of their time?
And are they able, because one model
is - some companies say, well, we
don't wanna hire project managers
'cause Agile doesn't like them.
So what we're gonna do is we're
gonna, just make our product
managers work 60 hours a week.
So that's one way, but I, that's okay.
I don't actually think, 'cause what
happens even to those project managers
that are willing to work that long is
then they're forced to choose between
urgent and important every day.
And they choose, they can't help
but choose urgent most of the time.
And that's project management.
And then they don't do
the product management.
So normally I am for
anything but a small startup.
I'm a big advocate for project managers.
Now there are program manager type
project managers, product project
managers and delivery managers.
They're all project managers of a flavor.
We like the kind that are more
service based than the kind that
are top down program control types.
But
Every great product model company
I know has project managers.
It's nothing wrong with that.
The key is they're not
the product manager.
Trisha Price: Yeah, yeah.
And the key is they're not just
checking check boxes because
there's a process to say, right.
They deeply understand and are aligned
in the outcome you're trying to
drive, and they're a part of the team.
Marty Cagan: Yeah,
Trisha Price: pretty critical.
Well, Marty, I have one final question
for you, before we finish up today, and
just coming back to hard calls, we've
talked about, making hard decisions and
prioritization and empowering your teams.
And we've talked about
driving towards an outcome.
But for you, when you're coaching and
looking at some of these great product
teams and the best product teams around,
How do you think about that fine line
between gut instincts, taste, and
true data-driven decisions that need
to be made to support hard calls?
Marty Cagan: Yeah, no, it's actually
a great topic, which is so I
don't really even believe in the
whole concept of gut decisions.
I think that's just a
phrase we use to represent
experience and, and that we, the term a
number of people use, Shreyas Doshi is
the one who finally kind of convinced
me to adopt the term product sense.
The reason I didn't use it originally
was because it sounded a lot
like something you're born with.
But you're not born with it.
You, you learn it, you develop it.
So we had talked about
coaching a minute ago.
The main goal of coaching is to
develop good product sense in your
product people, good product sense.
They understand the customers, they
understand the data, they understand
the business, they understand the
constraints, they understand the industry.
This is product sense.
This is what helps you
make good decisions.
Now, even when you have great product
sense, sometimes you're gonna want
enough data that you know this is right.
Yeah, sometimes we even want proof.
Sometimes we just want evidence, but you
have enough product sense to know what
you need for each of those decisions.
Some decisions are minor.
You can reverse.
You can correct a mistake in a few hours.
With a hot fix.
Yeah.
In other decisions, they're like,
oh my God, we're gonna be sued.
Right.
Or kids could be harmed or the
environment could be harmed.
So really bad consequence.
So those are things you're
not gonna take lightly.
Mm-hmm.
So this is the kind of stuff we coach
them on, and this is really product sense.
Yeah.
And I explain.
For a lot of the coaching I do.
That's what I'm doing.
I'm, I'm kind of helping them
understand what is the right level of
rigor and analysis for this decision.
They need to make the decision,
but they need to make sure
they've got the right input.
They also need to understand some
of those stakeholders have a vote.
Some of them just have opinions, right?
Some of them, it's not a democracy.
They can say no, and
you can't ship anything.
So you need to understand the difference
and you need to make sure that you
understand their constraints and their
concerns so that we product is solving for
the customer and solving for the business.
So this is the kind of thing
we're developing in people.
And when you meet a great product
person they typically have great
product sets which they have earned.
Yeah.
And that's, it's not
Trisha Price: because they're just smart.
I mean, they might be, and it's not
because they were born that way.
It's, it's the part you kicked
off today's episode with, which
is learning from the mistakes.
When we made a hard call that
didn't work well, that backfired.
It's learning from the wins, it's
watching other people who have
coached us and invested in us.
It is something that
we just earn over time.
and I think for some people it
comes more naturally than others.
And it also probably depends
where we've had the good fortune.
Of being able to spend time in, were
we empowered and were we able to learn
at the micro level before we were
forced to make the macro decisions too?
Marty Cagan: Yeah.
Such a big, like I know, I'm so
grateful every day I started as a
product with somebody who was coaching
me and he told me his job was within
three months to get me to competence.
And that was a lot of
work, but it was doable.
I mean, if somebody's there to guide you.
It's amazing how fast you can
get to where you need to be.
So, you've gotta put in the work,
you've gotta talk to customers,
you gotta spend time with the data.
But this is what product people do.
It's absolutely doable.
What I think is really interesting
going forward is, that's kind of
what's left with product management.
With gen AI and the tools,
the, those other things are,
Trisha Price: the busy work is gone.
Marty Cagan: Yeah.
Trisha Price: Now you've gotta have
product sense and make decisions
and be accountable to outcomes.
Marty Cagan: That's right.
Trisha Price: Now you gotta
spend time with customers, right?
That's right.
It's exciting.
It's an exciting time.
I think personally, it's the best time
ever to become a product manager if you're
working in the right organization because
a lot of the more operational aspects.
Are gonna be automated or already
automated for us, and now we can spend
our time thinking and driving outcomes.
Exactly.
Well Marty, thank you so
much for joining us today.
I know our listeners
appreciate your advice.
A reminder for everybody if you
like what you heard from Marty,
but wanna learn a lot more.
Marty has three great books out
there, that you can read and
learn and get a lot more detail.
Or you can obviously engage with,
Silicon Valley Product Group as well.
So thank you, Marty.
Well, thanks for inviting me, Trisha.
I enjoyed the conversation.
Me too.
Thank you for listening to Hard
Calls, the product podcast, where
we share best practices and all
the things you need to succeed.
If you enjoyed the show today, share
with your friends and come back for more.