Subscribe
Share
Share
Embed
The Product Engineering Podcast explores how software teams can move beyond shipping features and start delivering measurable outcomes. Hosted by engineering leader James Charlesworth, each episode covers practical ideas for product engineering, engineering leadership, team operating models and building products that create real impact.
You build the
organization around
the people you have.
If then the people
change, you have to
change the
organization.
That's a bit
of friction.
But if you want to be
super high performing,
that's your best
option because we're
all wonky
shaped objects.
We don't all fit into
a perfect whole.
And so that's where
you're gonna get the
best outcome.
(Upbeat Music)
(Upbeat Music)
Hi, welcome back to
the Product
Engineering Podcast.
And this week we're
talking about where
that line is between
product management and
engineering.
And indeed if there
needs to be a line
there at all.
So for this episode,
I'm joined by
Phil Hornby.
Phil is our product
leadership coach, a
global product lead
for ZF and the founder
of For Product People.
Also the host of his
own podcast, Talking
Roadmaps, which we'll
find a link to in the
show notes of
this episode.
It's great to have you
on the
podcast, welcome.
Great.
And I'm just gonna
extend the list.
I'm also an engineer
if we go back for a
fact, till technically
I'm a
chartered engineer.
I even went that far
and ticked the box,
you know, that no one
ever does when they
finish the degree and
do all the time served
and stuff.
Well, that's perfect
for this topic then.
Because if you've
started as an engineer
and now you work fully
in the world of
product, that means
you've experienced
both sides of
these divide.
And that is actually
not that common to
have somebody that's
worked as an engineer
and then also worked
as a product leader.
So when we talk about
that line between
where product
management ends and
where software
engineering should
begin, it's almost
certainly been getting
fuzzier over the last
few years.
Where do you think it
should sit and how
defined do you think
that
barrier should be?
I mean, I'm gonna pick
up, you said software
engineers.
That's only one
discipline of
engineering.
My background is
mechanical, electrical
and software.
Like you're not full
stack if you can't
design the hardware,
in my opinion.
Back in the front end
doesn't cover cut it.
But where is
the fuzzy line?
Well, ultimately
engine, anyone can do
any of the work.
But I think there's a
fundamental human
system at play here.
There are some of us
that have chosen to
want to go and talk to
people and understand
the problems
that they have.
And there are some of
us that have chosen to
wrangle the code,
wrangle the technology
and make it and shape
it into the way to do
something.
Now, don't
get me wrong.
The ability to do that
shaping is
getting easier.
The ability to
synthesize what you're
doing in those
conversations is
getting easier.
But I still think
there's a human
system at play.
Like I stopped being
an engineer because I
got so annoyed.
We'd basically been
told to build the
wrong thing.
Really came down to
that simple thing.
I mean, there was a
little bit of
circumstance and so on
as well, but I moved
that direction because
I recognize that if
you've been, points
you in the wrong
direction, it doesn't
matter how good you
are as an engineer,
you're doing
the wrong thing.
And if you're doing
the wrong thing,
you're
wasting your time.
And there was an
element of I found the
people problem, people
wrangling a harder
problem and therefore
a more rewarding
problem to work on.
I mean, I can totally
sympathize with that.
That's why I do
engineer management.
I've been an engineer
management for about
10 years because
computers are easy and
people are hard.
And I wanted to tackle
the hard
problem, right?
Like I wanted to deal
with people not being
predictable,
not deterministic and
actually sometimes you
can't always fix a bug
in a person and that
sort of stuff.
So yeah, I completely
sympathize with that.
In fact, I wouldn't
call them a bug.
I'd call
them a feature.
Like
everything's a feature.
Some of it's an
undocumented,
undesigned feature,
but like I'm a great
advocate for
techniques developed
by a guy called
Meredith Belbin from
many years ago,
designing high
performing teams.
Like I am qualified in
the techniques for
assessing teams and
this sort of
thing on it.
And one of its great
principles is be the
greatest of your
strengths, not the
least of your
weaknesses.
And so if I look at
like these things that
I'm not really great
at, like I am not
great at smoothing a
team over and getting
everyone happy and
this sort of thing,
but I'm really great
at setting direction
and making progress,
but that one tends to
upset people.
And then I need
someone who's more of
that team worker to
help smooth the way
behind me.
I'm not great at
dotting the I's and
crossing the T's.
I need someone who's
much more complete to
finish around me.
And so actually it's
about knowing where
the balance in the
team is, how we get
the best team is by
getting everyone who's
world class at some of
those things and
accepting that some
people are not world
class at some of the
others, but we balance
it by having the world
class people.
If you take away your
weaknesses, you
basically
earn a beverage.
If you amplify your
strengths, you can be
world class.
And that to me is a
leading principle in
how I always think
these days.
So I'm playing devil's
advocate a little bit
here, but let's say
I'm arguing the case
that there should not
be a boundary between
product management's
engines, right?
Everything you've just
said, you can't
dictate what someone's
good at or what
someone's bad at just
by their job title.
There will be product
managers who are, like
you say, have
strengths and
weaknesses within the
defines of product
management and you'll
have software
engineers or other
engineers that have
strengths and
weaknesses within the
bounds of
engineering, right?
So if you have an
engineer where
speaking to customers
is one of their
strengths, then surely
there shouldn't
be any barrier.
Surely they should
just go all the way in
that particular asset.
I think, yeah, there's
a whole school of
thought around, do you
build the organization
perfectly?
You design it from the
top and then you fill
the buckets, or do you
build it around the
people that you have?
I was actually talking
about this with one of
my coaches who's a CTO
only on Friday.
And we both are
absolutely of the
perspective.
You build the
organization around
the people you have.
If then the people
change, you have to
change the
organization.
That's a bit
of friction.
But if you want to be
super high performing,
that's your best
option because we're
all wonky
shaped objects.
We don't all fit into
a perfect hole.
And so that's where
you're gonna get the
best outcome.
Like, yeah, an
engineer going out and
talking to customers,
bringing that
insight back.
To be honest, I want
them doing that
anyway, or at least
standing next to me
and listening,
building that empathy,
building that
understanding because
that ultimately is
gonna get
better delivery.
Like, with the classic
sort of mindset of a
product team, it's
found around this
product trio,
typically a designer,
a product manager, or
a product owner, and a
tech lead.
I don't like to have
one tech lead because
usually you've got,
let's say seven plus
or minus two if you
use the
classic number.
I think the teams are
shrinking on the
engineering side
relative to the team,
the ratios
are changing.
But let's say we've
got six people there.
Well, there's gonna be
a bunch of big
initiatives that
people are working on.
And I would much
rather have an
engineer come and
really get embedded on
each individual
initiative, really
understand it, really
live and breathe it,
through the discovery
process, and then go
back and
focus on delivery.
And someone else comes
and focuses on the
next initiative that
we're thinking about.
And like, I think one
of the key
misconceptions is that
product is just doing
that part.
Now, I'm a bit of more
of an old school side
of product as well.
I spend as much time
thinking about go to
market and pricing and
all those businessy
things that even if a
technology or an
engineer wants to come
and understand the
problem, that's an
even bigger stretch.
And I think if we look
back, like I did the
history of product
management as part of,
I researched it as
part of my MBA a few
years ago.
And it goes back to
the 1930s.
Like this is not a
thing, a new thing.
In fact, my first
managing
director in 2001,
he had been a product
manager in the 80s.
He used the foundation
of my
product thinking.
And the thinking
hasn't really changed.
Like, I think
it's Bob Mester.
He has this theory
that every 10 years
you have to rename a
theory or a model to
keep it relevant, to
keep people's mind.
Like I reread the Dell
way recently.
It's all about Michael
Dell from the 90s
building down.
And as I went through
it, I heard
lean startup.
I heard
single-threaded
leadership
from Amazon.
I heard all these
principles that have
now got new names and
new concepts, but
they're not that
different.
When I look at things
like people talk about
the Spotify model.
So we're talking about
matrix teams.
We're talking about a,
you know, where's your
first home?
Those concepts and
communities of
practice and things,
they are not new,
where they were just
kind of given geeky
names more recently.
Yeah, I think that
people are trying to
solve the same
problem, but with
different structures.
And you'll get that.
I don't think they're
different structures.
I think they're just
rediscovered
structures.
However, the structure
can sometimes prevent
people from bleeding
into other worlds.
So we don't talk, like
you mentioned design
in that
triangle, right?
We don't really tend
to talk about design a
huge amount.
We're talking about
product engineering,
but I think that is
quite useful because
product designers for
quite a while now have
been going into the
world of
product, right?
Product designers have
been speaking directly
of users and all that
kind of stuff.
And so they've almost
kind of been through
the transition that a
lot of software
engineers are facing
at the minute, which
is learning a little
bit of product.
And it's, you know,
when I went into
management, people
always said to me, you
don't want to go from
being the best
engineer on the team
to being the worst
manager at
the company.
And you can sometimes
feel like that if you
cross into somebody
else's like expertise,
you could go from
being the best
engineer on your team
to being the worst
product manager.
And so, yeah, I think
like designers, we
could probably learn
from the way that's
happened because it's
been successful for a
lot of people in
design, I think.
It has, but I would
put a caveat on that.
Designers have
transitioned really
well, I think, in B2C
because the customer
and the user are the
same thing.
And they're used to
talking to the user.
When I think about who
I talk to, I talk to
users absolutely, but
I'm much more talking
to the customer.
The person's actually
paying the bill.
The person's hiring
this product to solve
a problem and
understand why they're
going to buy, what
value it's going to
create for their
business, which is not
quite the same as the
user in a B2B context.
I think you're
completely right.
I would actually
disagree because often
in B2C, the customer
and the user are not
the same thing.
So the user will
sometimes be the
product that you're
selling to an
advertiser.
Like take Facebook,
for example, right?
Like a lot of people
will complain.
That's B2B
at that point.
It is.
You're now B2B on that
advertising side of business model.
Facebook is a B2B
company, right?
Like it's an
advertising company.
So if you're a user of
Facebook, people will
complain that Facebook
has terrible
customer service.
Like, no, they have
great
customer service.
You're just not
their customer.
So like, but
you are the user.
So you're a
user of Facebook.
That's where I want
the designer to be
advocating for it more
than the
product manager.
That's where I see
that transition worked
well in a pure B2C
play, in a B2B to C
play like you have
with Facebook.
For certain teams,
someone from a UX
background works
really well.
For others,
they don't.
But everyone can
learn, right?
It's not saying that
they can't.
It's just the skills
that are transferable
are less direct.
Like the user research
I do, or the discovery
work that I do, is far
less intense, far less
rigorous, far less
structured than what a
designer is going to
be, a user research is
going to do.
Because I'm not, I
have a fundamentally
different motivation.
As a product manager,
my goal is to
de-risk things.
Not to make the
perfect solution, it's
to de-risk.
It's like, what's the
smallest thing I can
do to understand that
this is valuable
for a customer?
What's the smallest
thing I can do to
understand it's
valuable for
our business?
And then let's
go and build it.
Let's make progress.
It's a different
motivation.
And I think, if we
come back all the way
to the fundamental
topic here of like
product engineer
versus product
manager, absolutely
that mindset can be
taken by anyone.
I struggle with the
idea of getting down
to, just say a one
person team.
I actually think that
the cognitive
diversity of having
multiple viewpoints, a
different perspective
and different people
in the team is
super valuable.
Yes, I spar with my AI
agent all the time to
try and
accelerate that.
And I tell it to take
on different roles to
do that, but nothing
beats a real person.
I agree.
But then let's talk
about AI because
people are starting to
think, can I just have
a one person team?
And anything I can't
do, I can just
get AI to do.
Like that is a
common thing.
So a common question
that I hear about
product engineering in
particular is, is a
product engineer an
engineer who's learned
a bit of product?
Or as a product
engineer, a product
manager has just
picked up claw code
and they can do
engineering, right?
Now those are two
very, very different,
on the surface of it,
they look similar, but
they're very, very
different because what
you're doing is, the
concept of AI being
the average of the
internet, like it's
never gonna be the
best software
engineer, it's
definitely never gonna
be the best
product manager.
So you can
kind of get by.
You can get by filling
in gaps in your
skillset with AI.
Yeah.
But I think we were
both agreeing on this
though, right?
That like there are
some things you're
always gonna know your
product better than an
AI, AI will possibly
know it because it's
not, it doesn't know
it's not in
the training.
I mean, I use a, I
have a huge personal
knowledge management
system, a bit like
Dave Colleen here.
Dave and Teresa,
Torres have put a lot
of material out there
in the world about
that, those
sorts of concepts.
I didn't pick up
anyone's
existing system.
I listened to them.
I mean, I had dinner
with Dave in Paris, I
think two years ago.
And like I've sat
there with him and a
CEO of an AI company,
the size of the,
Brinn's the size of
the planets.
I'm thinking, can I
keep up in this
conversation?
But I'm listening and
I'm learning.
And one of the things
I took away was
fundamentally what
Dave was doing.
And so I went back to
first principles and I
built my own knowledge
management
system myself.
So I now have this, in
fact, I have two.
I have one at work and
I have one at home.
And they are both, you
know, and they both
influence each other.
Like I learned
something in one, I
take that knowledge
back to the other one
and vice versa.
And they are building
up a huge
amount of context.
And I get a good first
stab of everything.
Like, but one of the
things that you see
with a lot of AI in
writing in particular,
is you get a vanilla,
you know, middle of
the road sort of way
of writing.
Until you take some
time to train it.
Like I'm lucky that
I've got a ton of
content out there in
the world, speaking at
events, this
sort of thing.
So I can go take all
these transcripts.
How does Phil speak?
What's
Phil's voice like?
Phil uses hot ticks,
slightly more
controversial ways of
phrasing things.
Uses copywriting style
of like, can start a
sentence with a but.
And all of a sudden,
the writing
starts to be me.
It's consistent and it
is how I write.
How successfully have
you found the
output of that?
Because I'll be
honest, I've tried
doing that.
I'm writing a book at
the minute and I have
tried like taking a
couple of chapters
that I've written
myself and writing the
whole bit myself,
obviously.
But I've taken a
couple of chapters and
I've said to it, okay,
this is how I write.
Just do a
paragraph for me.
And you can
see it trying.
You can absolutely see
it trying.
You can see it doing
British English and
you can see it doing
all the little
quirks and that.
But it never
really gets it.
I never read it and
think I would have
written that.
Like, I don't know.
So yeah, I think I've
got there.
I might be heavily
using Claude as a
ghost writer in a
writing
project right now.
And I feel it's pretty
consistent
with how I write.
But I have got hours
and hours of
content, right?
So it's maybe just
about how
much I've got.
But I also spend a lot
of time tuning.
When I do things at
work, most of my
output is not code.
So I'm not teaching a
style guide.
I'm teaching it how to
write like me and how
to bring content in
and analyze it.
And then I'm sparring
with it about
that content.
I'm not taking it and
saying this, but then
every single session,
one of the things, I
think it was a Dave
one, end of every
session I have a slash
reflect skill.
It looks back through
the whole session and
sees, what did we
iterate on?
What did it
not get right?
And constantly
improves the system to
be more like, you
know, get to that
answer in less steps
and so on.
So I think I'm getting
pretty good.
It's getting
pretty good.
It's not perfect.
I'm not
aiming for perfect.
I'm aiming for 95%
say, because that is
still better than,
it's probably better
than I would do if I
spent the next year
working on something.
And it depends where
you're writing, right?
Like if you're writing
a book, you probably
want to go for 100%.
If you're writing
marketing copy, you
could probably get
away with a
little bit less.
If you talk about
product management,
writing is an
important skill, as
I'm sure you know in
product management,
but you don't have to
have it, it doesn't
have to be pros.
Like you're writing,
if you're writing a
product requirement
documents or
something, if people
still write those, or
you're building a
slide deck to set out
your vision to C-suite or
something like that.
Like that's
still writing.
It definitely is a
type of error on the
side of pros,
not on decks.
I'm a deck hater, but
I live in corporate
lands, I
have to do some.
But yes, for me,
I'm trying to create,
and I work with a,
where I am, we have a
two in the box model.
So there's me as a
product manager, and I
have a product owner
that I work with.
If I was in a SaaS
business, I'd probably
be called a principal
product manager and
him a product manager.
And the
title's very right.
But the way that it
works is like, he's
directly in the squad
and working on things.
And so we collaborate
on things, but we use
our first drafts, but
we share our
knowledge, our
personal knowledge
management systems.
It's linked up to the
whole Jira, so it can
see all the context.
It's pulling a
lot of stuff in.
And what we found
definitely in the last
few iterations,
because we've both
only been there
working together for
just 18 months.
And so we've been
going through
iterations how
we work together.
And how we work with
our engineering
partners and so on.
Get your storytelling
is the critical part,
like getting to that
story that we can hand
over to engineers,
like the story, and I
don't mean the
user stories.
The user stories are
like the little bit of
detail behind that,
but the overall story,
the customer led
story, the user led
story, that's been the
critical part.
Because there's been
those epiphany moments
for the engineers of,
ah, that's what we're
trying to do.
Which actually, if
they're out in the
room, having to do the
discovery, they've
already got that.
No, I
completely agree.
And those are the
kinds of skills, I
keep trying to think
of software engineers
like learning basics
of products and stuff
like that.
And those are the
kinds of skills that
people don't tell you
you need to learn, but
you absolutely
do need to learn.
And in fact, you need
to learn that kind of
stuff as an engineer,
if you want to
progress to lead staff
software engineers and
stuff like that.
Because the stories
are how human beings
consume information in
the most successful
way, right?
Like we're not very
good at just reading a
bunch of bullet
points, like
LLMs can do that.
But we think of
things, we imagine a
flow through
something.
And so, yeah, no, I
think that's a
really good one.
Just put it in simple context.
Humans in our form
have existed for
100-ish
thousand years.
It's the last 400-ish
years, maybe 500-ish
years, maybe a little
longer, that it's been
written down in a
language that most of
the population
could access.
We've been sharing and
passing knowledge
through stories and
that oral tradition.
So much longer, it is
baked into the
structure of our brain
to learn that way.
So how do you learn
storytelling then?
How do you learn it?
How did I learn it?
Trial and error, a
bunch of training, a
bunch of reading.
Like you can see, I'm
a prolific reader.
This isn't a virtual
background.
I was, yeah, I was
wondering.
(Laughs) I often make
a point, I'll just
pick a book.
We're talking about
storytelling, so okay,
let's go and
get, oh no.
Your red thread,
that's a good one on
storytelling.
Or save the cat,
another one, good one
on storytelling.
I consume knowledge,
but I also bring that
knowledge into my
system, like I'll tell
it, "Ah, I liked this
aspect of
save the cat."
Bring that into your
knowledge, into your
writing system.
Or one of the key
things, if I'm using
AI to help me with
writing an email, I
always tell it to use
Mentos Pyramid,
because that means it
puts the most
important thing right
up at the top.
Like don't
bury the lead.
Because seeing people
read the first two or
three lines, and then
they're done.
So get it at the top,
get it in the head,
and everything else is
just fluff.
Yeah, I mean, why do
you even need
everything else if
anybody's gonna just
take your email and
summarise it
with AI anyway?
So I've
stopped trying.
Here is this whole,
I'm gonna write a long
email with AI, then
someone's gonna
summarise it into
bullet points, and
then they're gonna use
those bullet points to
tell it to their AI to
write their long
answer, and lossiness.
I mean, okay, so take
that concept that you
just described
jokingly, and apply it
to customer feedback
coming in to a
product, turning into
product requirements,
turning
into some code.
It's the same kind of
thing, like AI is
being used to
work on this.
That is what synthesis
is in reality, yeah.
So should AI be used
to simply turn a
feature request into
some code, and then
test it, and
then ship it?
Is that the right use
of AI, or is that just
gonna lead us down a
path where we're not
really in control of
anything anymore, and
we're not actually
building what makes
sense for
the long term?
A feature request,
absolutely not.
Because a feature
request is from a
customer, or from a
user in solution
language, like I want
a button that does X,
and then you have to
ask the
question of why.
I mean, you never
actually ask why.
Why is a really
accusatory word, but
if you ask so you can
dig down and get
underneath the surface
of what they're really
trying to achieve,
that's the skill of
it, that's
the art of it.
Like, I'm gonna be
walking around a bus
depot tomorrow,
because that's one of
my customers.
And I'm gonna be
understanding, I'm
literally going there
to spend two hours
just understanding
their business, how
they operate in terms
of their
maintenance model.
There is no, it's
completely open-ended
discovery, like
nothing
more than that.
But it's, I'll come
away and I'll
literally, as I get in
the car, I'll start a
chat GPT session, and
I'll have a
conversation with
that, with it just to
capture my thoughts
after I come out.
That's my, because I'm
not gonna record the
whole walking around
the depot, but I want
to synthesize as
quickly as I can, and
get as much out, but
it's opinionated.
It absolutely is, it's
biased by all of my
intuition, and my
experience, and so on
of working in
the industry.
And I don't think
that's necessarily a
bad thing.
Like an engineer
knowing that designing
something in a
particular way is
gonna lead to tech
debt issues
in the future.
That's that intuition
coming in again.
That's like that
understanding of the
type of tech stack and
how it's gonna work.
We're actually all
paid to have opinions.
I believe like, you
don't pay someone
senior to not have an
opinion, you pay them
to bring that
intuition, bring that
experience, and bring
that opinion about how
it's best to do
something.
Yeah, software
engineers definitely
have opinions.
But I mean, one
frustration I see
sometimes with
software engineers is
that they have a lot
of opinions about a
very narrow subset of
questions.
So it will be whether
we use Vue or React,
or it will be whether
we do
TypeScript here or where.
But when it comes to
like the really big
questions that really
matter, like are we
gonna go for this type
of user flow or this
type, they don't seem
to get that, waiting
for somebody to guide
them, or someone to
tell them the answer,
and I think.
But I'd say that's
like the
last 15 years.
And before that, I
mean, when I was an
engineer, we got
involved, like I was
doing product work as
an engineer.
So I guess I was a
product engineer, if
we put it in
that context.
I drove the roadmap, I
defined the roadmap.
It was always
how we worked.
Like we just had a
small group, there
were 15 of us.
We were all senior,
experienced, full
stack engineers.
We could all turn our
hands to everything.
So we didn't have that
narrow strong opinion
because we hadn't gone
so deep in each
individual area.
We had the, this is
the problem space we
need to address.
How do we work here?
These are the things
we care about.
Yeah, I mean, that's
kind of the argument
for generalists.
And a lot of the, like
small companies will
have just
generalists, right?
Like if you found a
company of three other
people, then you will
have to be
generalists, or you
have to be able to
cover everything
themselves.
But then as companies
grow, like having
specialist skills, you
have to be a trade off
for having
specialist skills.
So if you have
somebody that's super,
super understands,
like browser dom
interactions or
something, then maybe
it is okay if that
person doesn't
necessarily understand
how to interview a
customer or something.
I think that's true.
I mean, if you look at
like team topologies,
like when you're
thinking about
designing your
organization,
in a specialist
subsystem team,
whatever they, if I
remember, that's what
they call them,
something like that.
It's really, it's not
a short supply.
It's that deep
knowledge that you've
got to keep together.
It's got to look after
components because you
need that depth.
But I don't think
there are many teams
where that's
really true.
At what size?
Because once you go
over like a large
enterprise customer or
company where they
have hundreds and
hundreds and hundreds
of engineers, do you
just have a hundred
generalists?
I think you could.
I mean, the mythical
full stack
engineer, right?
Is just a version of
that kind of phrase.
That is the thing we see.
Like there are
companies that are
approaching a thousand
engineers that would
just have product
engineers and they'll
have like, you know,
senior product
strategy people and
they'll have go to
market people, but
they won't have front
end engineers, back
end engineers, dev ops
people and all that
sort of stuff.
Everybody sort of does
as much as possible.
There are some
companies that are
being very successful
in that model, but
then conversely, there
are a lot of companies
that would never dream
of doing that.
There are a lot of
companies that are
higher for a very,
very specific, you
must have had AWS
experience, the worst
kind of stuff.
And that's where-- I
mean, there are
organizations that
have, you know, there
are different
organizational
cultures and all can
be high performing.
Like let's take Apple
and Google or Apple
and Spotify as
two examples.
Apple are massively
functionally
organized.
You live in your
discipline and that is
your organization and
then there's a lot of
organizational tax
going between them,
but they pay that tax
and they deliver what
seems to be
cross-functionally
coordinated
stuff anyway.
On the other hand, you
have some like, a
Spotify type
organization, where it
is absolutely living
in that
cross-functional team
where you've got
everything you need in
a small organization.
And again, delivers in
a similar way, but
every time you go
outside of each of
those functions,
there's a tax.
And so it's about what
do you want to
optimize for and
what's going to
deliver better for you
and align with your
company culture and
how you think.
Like there's no one
size fits all.
As everyone uses the
phrase and it's my
favorite
one, it depends.
You can build an
optimal organization
in any of
these models,
but you're choosing to
optimize for
other things.
I think that goes back
to the point you made
at the start, which I
do really agree with,
of building the
structure
around the people.
It made me think of
like the football team
analogy, where if
you've got like a lean
or messy in your team,
then you kind of try
and build the team
around them.
Now, obviously, lots
of people would
disagree with that.
Lots of people would
say you should try and
fit people into a
system and all that
sort of stuff.
But yeah, I do like
that approach though.
I do like the idea of
identifying what
people are weak at and
what they're strong at
and building the
structure around that.
I think especially
with smaller teams,
which we're seeing
more and more of now,
working out how people
can compliment each
other and then just
making that the
structure, I
think is useful.
Yeah, I mean, you're
probably still gonna
end up with
someone who is more
businessy, someone who
is more usury, and
someone who is more
technology.
But the
lines are fuzzy.
I mean, with the
classic Venn diagram
from Martin Erickson
that shows the three
sort of areas, it
purposefully overlaps
to show fuzziness
between things.
It's got the business
side, it's got the
user experience side,
and it's got the
technology side.
They're supposed to be
an overlap.
The classic sort of
way people phrase it
is, product is in the
middle there, product
management.
In fact, product
management, not
product, is
in the middle.
I don't agree.
The team is in the
middle when
it's balanced.
And the team can be
made up of any group
of people.
As long as you can
cover those three
areas, you've got a
balanced team.
And typically the
product person is
gonna take more of the
business angle.
There's a group of
people who've chosen
to do that.
There's no surprise
that if you go back
15, 20 years, the
classic qualification
for a product manager
was an MBA, because it
was a business role.
And we've seen, Lean
came out, Lean
Startup, what was it,
2010, 2012?
And we saw Lean
Startup and Agile
thinking and so on
swing the pendulum all
the way towards much
smaller teams, much
more junior product
managers than they
used to be.
You were 10, 15 years
into your career to
ever think of being a
product
manager back then.
Like I had a $300
million P&L,
just as I speak.
Like things change.
And I think we're
seeing it swing me
back a bit more
towards the business.
I think product people
for the last 15 or so
years have done
themselves a
disservice because
when they turn up in
the room with the
engineers, they have
that business
conversation.
But when they turn up
in the room with the
CEO, they're usually
the one
representing the team.
And so they talk about
the technology
all the time.
And so they get seen
as another
technology person.
When actually what
they're doing is
they're balancing the
conversation because
they can never be more
businessy
than the CEO.
That's really
interesting.
No, you're right,
you're
absolutely right.
And I've seen that
happen and
you're right.
Because product
managers embed
themselves in the
team, especially if
they're technical
product managers, and
they see themselves as
part of the team.
And they're not,
they're part
of the business.
And actually the team
is itself part
of the business.
But I like that idea
of holding the whole
team accountable to
driving outcomes in
those three areas.
I mean, I consider
product managers
actually live
in two teams.
They are in the squad
or the development
team, whatever you
want to call it.
They're also in the
go-to-market team.
So they're working
with sales.
There's another trio
over there, sales and
marketing and product.
And it's not talked
about so much.
Might be part of one
of the books
I'm writing.
I think that's the
same as any management
because product
management is still
management.
I do engineer
management and we are
part of the team, but
we're also part of the
business team.
And I consider myself
part of a product
leadership team as
well, right?
So we've got a couple
of minutes left.
A lot of our audience
is senior staff,
software engineers and
engineer managers, and
people that are kind
of thinking, oh, okay,
I know I need to
become more
product-led, but how
do I do that?
So what advice do you
have for people that
have been engineers
their entire career
and they know that
they need to become
more product-led and
they just need some
more advice?
Drop the word
product-led and just
think about being user
and customer curious
and business curious.
Like get to understand
the business.
Understand like one of
the key things that
everyone misses is
what is the thing
that's most important
to their business?
Go and listen to your
next town hall.
What are the two to
three metrics they get
talked about?
Probably revenue,
probably some sort of
profitability.
That is the thing your
business cares
about the most.
Can you couple your
activities to
driving that?
There will be some
strategic initiatives
that they believe are
driving towards that.
How can you
support those?
Ultimately behind
that, it's all about,
go and
listen, go talk.
Take every opportunity
you can to have a
business conversation.
Like Marty Keegan is
famous for, you know,
the godfather of
product management.
Looking enough to be
in the room with him
as part of a coach the
coaches event a few
years ago.
And he tells the story
of how he got
into product.
He was an engineer at
HP and he saw this
product role and
thought it looked
interesting.
And he went and spoke
to a product leader.
And the first thing
they said is, do you
understand finance?
And they sent, they
actually got someone
for finance to train
him in all the like
the financial stuff so
he could
understand it.
And I think it's less
critical these days,
but understanding the
business is key.
And then take every
opportunity.
If you're out and
you're talking to
someone and it happens
to be there, a perfect
target customer for
you, just have a
conversation
with them.
Like take every
opportunity
to be curious.
That's actually
excellent advice.
Well, Phil, thank you
so much for coming on.
It's been honestly, we
could probably talk
about it for hours,
but it's getting late
in the day.
So thanks so much for
coming on.
I'll put show notes in
the description for
your podcast and
everything else you
do, which is quite a
long list.
And if people can
reach you, what's the
best place
to find you?
LinkedIn, just find me
Phil Hornby, or if you
put my name in
YouTube, you'll find
me as well because
there's a fair amount
of content out there.
But yeah, been
pleasure
being here, James.
And thanks for having
me and putting up with
my slightly wild and
pointed opinions.
I'm just glad we both
wore orange T-shirts.
Thanks very much.
Of course.