Hey, a quick message, for those of you who are listening to this
episode on Spotify, I have a small favor to ask Spotify.
Now allows mobile users to rate podcasts, I would really
appreciate it. If you can take a quick, pause
to go to the technology on our podcast page and leave your
favorite show. Your best rating on Spotify.
It will help me a lot to get this podcast to reach more
people on the platform. Thanks a lot and Empower G is
given a problem to solve so they don't get to pick what they
work. Like, What an empowered team
needs is that they get to figure out the best way to solve that
problem. So, instead of being given a
roadmap of features, they instead say here's the problem,
you figure it out. That is what's meant by an
empowered team. Hey everyone.
My name is Henry Surya, we Robin.
And you're listening to the technology, you know, podcast
the show where I'll be bringing you the greatest technical
leaders practitioners and thought leaders in the industry
to discuss about their Journey ideas and practices that we all
can learn and apply to build a highly performing technical team
and to make an impact in your personal work.
So let's dive into our Journal. Hello, my friends and my
listeners. Welcome to the technology on our
podcast, the show where you can learn about technical leadership
and Excellence from my conversations with great
thought, leaders in the tech industry and you are listening
to the episode 1 or 2. If this is your first time
listening to technology, you know, make sure to subscribe and
follow the show on your podcast app and on LinkedIn, Twitter and
Instagram, every day. I post interesting quotes from
the episode to inspire us and to spot a discussion within the
community. And if you'd like to support my
channel, Journey. Creating this podcast.
Subscribe as a patron at technology, know that Dev slash
Patron. My guest for today's episode is
Marty Kagan. Marty is the founder of the
Silicon Valley product group and the author of The Amazing books
inspired and empowered. In this episode, we discussed
how companies ought to build great products by learning from
the best product companies. Marty explain the importance of
building the right product and he shared the too inconvenient.
It's about building products. Marty then elaborated on the
traits, a good product team has and how to create an empowered
product team by ensuring ownership and alignment with a
clear product Vision strategy and focus to its DN multi, share
the importance of coaching and nurturing people how to hire
better and how to structure product team, topologies.
I hope you enjoy listening to my conversation with Marty, and if
you find it useful, please share.
Share it with your friends and colleagues who can also benefit
from listening to this episode. It is my ultimate mission to
spread this podcast to more people and I really appreciate
your support in any way towards fulfilling my mission.
Before we continue to the conversation, let's hear some
words from our sponsor definitey is the top International
software development conference, with an emphasis on coding
architecture and Tech leadership skills.
The lineup for this year is truly stellar and features.
Diligence in software development names, such as
Robert Uncle Bob, Martin can back, Scott Hanselman, Franca
subramanyam Carolyn honey, Alan Halep, Mary, poppendieck, and
many other prominent names, including some of those who have
also appeared in this podcast before the conference takes
place online. So you can enjoy it from the
comfort of your couch. We spoke to the definite, the
organizers, and I'm happy to share that technology.
You know, has got the 10% discount code for you.
Enter the promo code, awsm underscore tlj.
When you purchase the ticket on definite e.com, here's the promo
code. One more time awsm underscore,
tlj. Depending on the time when you
purchase a ticket early price is still available.
See you there. Today's episode is proudly
sponsored by skills matter. The global community and events
platform with more than 100,000 software professionals here,
ma'am. Scan organize, their learning
experiences around the technology topics.
They care about most you get on-demand access to their latest
content thought, leadership insights, as well as the
exciting schedule of tech events running across all time zones.
So whether devops our data science is your bus or you are
fan of functional programming or all things Cloud, you can make
real connections with people who share your interests head on
over to skills method of calm to become part of the Tech
Community. Unity that matters most to you.
It's free to join and you will find it easy to keep up with the
latest tech Trends. There everyone, welcome back to
the new episode of the Attack. Original podcast there, I'm
really excited to have a guess. Who I admire by reading his
books. His name is Marty Kagan, he is
the founder and partner of Silicon Valley product group or
S VP G in short while before founding this as vpg, but he has
served in few successful companies as the If needing the
products development including HP Labs, Netscape Communications
and eBay. So if you haven't heard about
Marty kickers book, those two books are titled inspired.
And empowered those two books are really, really good.
If you haven't read it today, I have a pleasure to talk to
Marty. So Marty, welcome to the show.
Thank you so much for spending your time.
Oh, thanks very much for inviting me Henry.
So Marty I always love to start my conversation by introducing
the guest, asking them to tell their story.
He's any highlights or turning points in their career?
Well be careful what you ask because I've been doing this a
very long time. Actually I just hit 40 years
exclusively doing Tech products. So for a long time, I study
computer science in school and I was sort of in that first wave
of developers. I joined what was considered
today is sort of like the Google of the day HP was considered the
most consistently Innovative tech company in the world at the
time. And so, my professors at school
told me, that's the Place to work and I spent 10 years there
as an engineer, I started by writing software and then I got
promoted to Tech lead. Speaking of which I was the
first time I was a tech lead HP had an engineering leadership
training program. So, I went from Tech lead to an
engineering manager and then I wanted to move over to product.
I'll tell you about that in a second.
But what I should say is through really my entire career with
really just one Option, which was eBay.
All the products I worked on were products for developers.
So I love developer products, developer tools, I worked on
languages, I worked on operating systems, I just like doing tools
and environments for other developers.
I think a lot of developers like doing math.
So I did that. But what happened was about
halfway through my time at HP, I worked on a product that was
very heavy, very Advanced product.
It was called the Speed, artificial intelligence work
station, but you have to realize this was a good 30 years.
Before AI technology was ready, we had got this in technology
from universities, and we were way too early.
But anyway, we built this product.
This is before the internet products, took one to two years.
Generally, to do a product a long time.
Anyway, we finally released it and nobody wanted to buy it.
Because there was no market for this at all some University
researchers, but then they wanted it everything.
Given to them for free. So there was no Market at all.
It was the first time I really asked the question, who decided
we should do that product. I was so excited about the
technology which was really cool technology.
It was the first time I got to use object-oriented languages
and we did rule based language. It was very cool technology but
it was the first time I asked the question, why should we do
this product? And I learned that there was a
whole other side to the product which is figuring out what to
do. Of product managers product
designers. I had been introduced a little
bit to that when I learned to be a tech lead, but not much.
And so, I asked my engineering BP, I told him I wanted to learn
product management and he said, he didn't know, it himself is an
engineering leader but he would find somebody at the company who
would agree to coach me and he did for the next product, which
was another set of tools for developers.
I was both the tech lead and also the Like manager and I had
this person guiding me to make sure I did a reasonable job so
that got me interested in more than just engineering more than
just the development. I've always been interested in
both in truth. The rest of my career, I kind of
have a reputation for talking a lot about product managers but
it's not really by choice. My interest is always been
product teams. I'm interested in Engineers
working with designers working with product managers.
To build something great. That's what my interest is.
It's true though that I know a lot of very good people that
write and talk about engineering tech leads.
I know a lot of good people that write and talk about design but
there's not many people that talk about product management.
So I find, I have to talk more about it because it's the
weakest link in a team often anyway, after 10 years of doing
products for developers, I was very lucky because for Those who
don't know. The original internet company
was Netscape Communications, I got to work for the co founder
Marc Andreessen and I was responsible for again, the
development platform and tools. So now people were asking how to
build large-scale applications that could serve, millions of
users, nobody had ever done that before and so, I was having a
great time. We had JavaScript team in my
group, we had SSL. We had application servers, we
had job. All these Java came from Sun, as
you probably know, flash came from macromedia.
Just all these pieces came together and we put together a
platform for building internet applications, one of the
first-ever applications built on the internet was eBay.
And I got to meet the founder of eBay Pierre omidyar, and I
really liked what he was doing. When I joined, they had
developers, but I was brought in as the original head of product
and design to punt of bring those skills to eBay.
And then then after eBay, I just wanted to work with startups and
grow stage companies. So that's what I've been doing
ever since which is really, I'm not providing tools anymore for
developers, but I do share techniques.
So it's the message, the ways of working.
And that's really what I do for the last 20 years, actually.
Yeah, thank you for sharing your story.
It's really interesting. Fascinating actually to hear
that you started from engineering become technically,
the normal engineering route and then switching into product
management. Now, well, known more for the
product knowledge, but putting that aside also, you work on
developer tools. Mostly so this is, I think also
a very interesting story. Thanks for sharing that.
So Marty, I think because of your history, right?
Working with products including experiencing failed products.
I think that lets you to writing these two books, right?
It started by inspired and followed by empowered inspired
subtitle is how to create Tech products.
Customers love and for empowered, it's like Ordinary
People Extraordinary products. So from these two themes, it
seems like product is the main theme including customers and
also the people working on the product.
So there are small, maybe why you have the idea to write these
two books and what kind of problems you want to solve with
these two books? You asked and you're making a
good point to my whole world has always been products, either
Building Products, designing products, product managing
products, but always products. I've never actually been
interested in custom software. Lucian's.
So, like, what Accenture does, Accenture has a fantastic
business, but I have no interest in that business.
I'm interested in creating a single product that millions of
people want to use not create one product for one company.
So that's the difference and there's nothing wrong with
custom Solutions. It's just my interest is in
commercial products, building real products.
I'm interested in everything about products though, whether
it's the An earring or the design or the data or user
research, anything about product is interesting to me.
So what happened was after I left eBay and I started talking
to friends companies in other places, I started realizing that
there was a big difference between how the best companies
created software products and how most companies were creating
products I was confused by that. I didn't really understand.
Why wouldn't they want to work like the most valuable companies
in the world? Why wouldn't they want to work
like Amazon or like Google or like apple?
I didn't understand why they would sell.
I talk to a lot more of them and I realized that for the most
part, they didn't know how nobody had ever taught them.
They had managers that never worked at those companies so
they didn't know how. So I realized there was a need
to share the techniques, the good companies use in both of my
books. There's nothing in there that I
invented or my partner's invented.
It's all things we find at Good Company.
He's all I'm really doing is sharing that look, all the good
companies seem to do this. They call it different things.
Sometimes, one company will call it product Discovery and other
one will call it fake it before. You make it another one, we'll
call it build, things that don't scale, then build things to do
scale but they're all describing the same thing.
So I realized we needed to share that.
And so that's what inspired was to share the techniques of good
product teams. Especially how does a good
product team. Out what to build.
There's already a lot of books many books on how to build the
product. In other words, how do you get
consistent? Reliable releases?
How do you do, continuous integration continuous, build,
continuous deployment. There's lots of books on that.
By the way, if I find the company that doesn't do that,
I'm like you have to do this, this is critical but even more
critical is making sure you're building something worth
building. So I'm interested in that side
and that's what Inspired us. I did two editions of inspired.
The first edition was really just for my little bubble in
Silicon Valley sharing with friends.
But the second edition a bigger publisher took it and took it
all over the world. And so I heard from a lot more
people in places all over the world that I far beyond Silicon
Valley and one of the things they told me is that they love
this. They want to work this way but
their managers won't let them. And so I realized that it wasn't
enough to share the practices of Teams that we also needed to
share the practices of the leaders and the practices of the
leaders are even more different than the practices of the team.
So the book empowered came out to be even a longer book than
Inspire in truth. The techniques are harder.
The things I talked about in inspired, I don't think they're
very complicated, they're more fun than anything else.
They're fun techniques, but in empowered when you talk about
what a good engineering leader does or what a good design,
Leader does, that's hard. Those are hard topics.
Those are not topics for 10 minutes on a whiteboard, you're
all done. It's hard.
So that was the motivation for the book empowered.
That's really my books. And then, I have a partner that
just turned out a marketing Book for a product marketing people,
and I've another partner working on a book about big company
transformation. That's another hard problem.
Sure, those two books, I typed up left and transform, I think
some of it are not Published yet, Marty, you mentioned that
you have seen it right? How the best companies built
products. Versus most of us who probably
had very little knowledge about how to build products properly.
Nothing also coming from your experience last time in HP Labs
building that AI workstation. So you mentioned in the book
that it doesn't matter. How good your engineering team
is how sophisticated the technology if they are not given
something worthwhile to build. I think this is something really
important that maybe we can dive a little bit deeper.
Why do you think that building the right?
Product actually matters first, regardless of other techniques,
well, I'll just comment sensitive software is garbage in
garbage out if the product backlog is full of nonsense,
then what do you expect will be ship?
That's what happens in so many product teams.
The things that they're asked to build, make no sense.
Their feature chasing or they're just doing what different parts
of the business are asking them to do.
There's nobody really looking at.
What is The real problem for the customer and how do we come up
with a solution? That's technically possible, but
also works for the business and also the customer would love
that's a much harder assignment, much harder work, but that's
really what good products have always been about.
And you mentioned, there's this concept too inconvenient truths
about product when I read it actually is very insightful.
Can you tell us what these two inconvenient truths are?
Now I think the reason I use the term the too inconvenient troops
because in most companies that aren't very good.
The biggest problem, the source of a lot of their problems is
really the product roadmap from the engineering point of view.
The road map is just these are the features.
They want us to build. The problem is, we have Decades
of data. Now that show that most of the
items on those road maps, are not going to deliver any
results. I mean, realistically between 10
and 20% The things on a road map.
For most companies actually produce a return but they
actually provide the benefit. The company was hoping 80%, 90%,
whatever it is wasted. So why is that that's what led
to the too inconvenient truths? The first Inconvenient Truth is
that we know, at least half the ideas on that road map is just
never going to work. We just know that.
Now it might fail because the customers don't want it.
That happens a lot. Not our CEO once it but our
customers don't want it. So that happens all the time.
Another problem is that they do want it but it's so poorly
designed, it's too complicated. They can't figure out how to use
it and sometimes they never even get to see it because it turns
out to be much harder to build than was originally anticipated.
The two sprints turns into 20 Sprints and eventually people
say forget it, it's not worth it.
So, These are reasons why most of the items on the roadmap are
not worth building, and then the other Inconvenient Truth is,
let's say you have a good thing on the roadmap, something that
really is, people really do want it.
It turns out in order to get that to the point where it
really makes money. It takes several iterations,
usually takes three, four, five iterations until its profitable.
Basically, we say in product that it's not so much about time
to Market, it's about time. To money time to actually,
delivering whatever the value is.
And that usually takes several iterations.
So if you just think about your typical company with quarterly
roadmaps that they fight about, at the beginning of every
quarter, and they have all these features and projects that they
dumped on the teams and say, build them, only a small
percentage of those things actually might work and then a
small percentage of those. Get the several iterations.
They need Make money. So this is what I mean by.
So, many companies are so bad and product, they don't
understand those two inconvenient truths that leads
to most of the waste in the typical company.
So you brought up an interesting point about product road maps.
I think still many companies, if not most companies are still
doing product roadmaps either yearly, quarterly or at least
every spring. There's some kind of a quality
product vision of product goal, what do they want?
So if If you are saying that the first Inconvenient Truth that,
at least half of those products from the product road maps, will
be wasted. Is there a better way?
How to execute this kind of a plan to build the products?
Oh, absolutely. And this is what good companies
do is. They know the difference.
The truth is our product roadmap does not have to be the disaster
that are usually is. The key is this, when do you put
an item on the roadmap? Do you put it on the item before
you've done? Any product Discovery or F.
If you put it before the problem is you don't know.
You just have these hopes that it's going to make all this
money but you don't know if it's going to make any money and you
don't know how much it's going to cost to build on the other
hand if you do product Discovery and I haven't really defined
that. But in general, what that means
is we have to make sure our Solutions are valuable usable
feasible and viable. We do that with a lot of quick
prototyping and quick. Testing.
So that's how we do that. Now if you do that first for the
ideas, that work, you put those on the product roadmap.
That's fine. Then it's just a communication
tool and you mentioned also another aspect of the product so
called the product roadmap you should not aspire to just build
features on top of features but you also should focus more on
the outcome. People usually call this output
versus outcome. So tell us more about that.
That's right, that's another difference.
When we talk about good products, And there's really
four things that matter. I've hinted a couple of them so
far, but we should just get these on the table because the
truth is, it doesn't really matter.
What process, the team is using, it doesn't matter if they're
using kanban. If there are using scrum, really
doesn't matter. And as you probably know, a lot
of the best teams, they'll use any of those.
So, it's not important. What matters are these four
things? First of all, is the teen.
Given a problem to solve, instead of a feature to build,
we want to give the team problems to solve.
L've, they can be customer problems, they can be our
company's problems, but their problems to solve not features
to build second, is, are they addressing the risks value,
usability, feasibility, and viability before?
They have their engineers build something, or are they
addressing that after four? Never.
So that's the second thing. The third is, how do they
actually solve problems? If they think, the way you solve
a problem, is somebody with a title product manager defines
requirements. And gives it to a designer who's
supposed to do workflows and whose then gives it at Sprint
planning to the engineer's that's waterfall.
Even though I just said sprint planning, that is literally
waterfall. So instead, what we want is
product management, product design, engineering to come up
with that solution side-by-side collaboratively.
In fact, this is the Little Secret in product consistently
the best single source of innovation is not our Product
managers is not our customers is not our Executives.
It's the engineer's because the engineers are working with the
enabling technology every single day.
They're in the best position to see what's just now possible.
And so the point is great product ideas come from them.
Let me just make this very explicit Henry.
If the first time the engineer's or the tech lead, even sees a
product idea, is that Sprint planning, that is a bad product
team. Hey, they should have seen the
idea way before that from the beginning of the idea.
Anyway, that's the third. The fourth one.
Is what you brought up outcomes? Good product teams measure
themselves against outcomes. Not outputs.
In other words, good teams, shipped every day multiple times
a day. With continuous deployment.
What matters is not shipping a feature?
What matters is achieving that outcome, whatever that problem,
we were trying to solve. Did we solve it?
So I think that point where you mentioned that engineering
should be involved even earlier, they should not be involved only
during Sprint planning or maybe backlog grooming that is
probably too late. And you mentioned in the book
that if your engineers are used, just to produce code, they
actually bring half of value. I think that's a very insightful
thought because all along, I think in many companies as well,
Engineers, maybe they also treat themselves.
Like, I just want to coat. I don't want to involve in this
product Discovery or product management but actually the best
This would involve these technical people early in the
process. In fact, I mean, literally at
the best companies they consider the single most important thing
are engineer's, doing more than just coding.
They refer to it as this notion of an empowered engineer.
An engineer that cares just as much about what they build as
how they build it. So that is a huge difference
between good companies and the rest in a lot of Silicon Valley,
the way they talk about. This is They'll say, do you have
teams of missionaries or teams of mercenaries mercenaries,
basically, build, whatever they're told to they don't care.
If you tell them to build the stupidest feature in the world,
they will build the stupidest feature in the world, they don't
care, they don't care. They like just pay me.
I'm fine. And in fact in a lot of those
companies they're not even employees their outsourced.
So no in a good company, they would never do that.
In fact, when they interview for engineers, they're trying to see
that they're not Like that, that they really care about what they
build, you know, in a good product.
Team did a good product company the engineers don't have to
build, what the product manager says, if they don't agree, they
don't build it. Wow.
So I think that's the very interesting findings and Eunice
also have a say what to build for what not to be.
I think that's really key. So, you mentioned this keywords
about empowered. I think that's the type of
second book empowered teams. What are some of these
attributes of Empower team? So, maybe If you can explain,
what does the term mean? Because so many teams also, they
feel like they are empowered. They can do whatever they want.
That may be one interpretation of empowered, maybe there's
something else. No, that's a fair question.
Because there are different interpretations.
The most common concept that it's confused.
With is another important concept which is referred to as
an autonomous team. So, there's autonomous teams in
there are empowered teams and some teams are empowered and
autonomous. But the difference Is an
empowered team is given a problem to solve, so they don't
get to pick what they work on. That's Fantasy Land because
imagine having all these different teams and all these
different engineers and they all pick whatever they want to work
on, nobody would get anything done for our customers so they
don't get to pick what to work on.
But what an empowered team needs is that they get to figure out
the best way to solve that problem.
So, instead of being given a roadmap of features that say, we
want you to put this payment. Method.
We want you to do all this. They instead say here's the
problem. You figure it out.
Here's the problem. You figured out that is what's
meant by an empowered team, an autonomous team means you have
everything in your team. You need in order to make those
changes you need to make. So if you need to build
something that requires certain skill set, you have that skill
set. Now in truth, most good
companies have empowered teams but only partially, Animus.
In other words, it's very hard to have full autonomy in most
companies because there are so many interdependencies there are
all these platform teens and we depend on.
And so it's not about full autonomy, it's about maximizing
autonomy. So you write up these key word.
Autonomy, I think there are two things are covered in the book.
It's called the ownership and Alignment.
So I think not just the Empower team has the autonomous
capability, but the people inside also having ownership A
ship and also alignment regarding the product that they
want to build. So can you tell us more why?
These two attributes also are important in a product team.
Well, you're getting at another topic.
That is a very big topic and honestly one of the most
difficult that most companies and this is referred to as the
team topology topic. They actually I got that term
team topology, you might have noticed, inspired I didn't use
that term. I just referred to this concept
by the way most companies did which is How do you structure
your product teams? So if you've got a hundred
Engineers, you've probably got between 10 and 20 product teams.
How do you decide what each product team bones?
How do you decide what they work on?
That's the team topology topic. You may know that there is a
couple devops Engineers came up with this book called teen
topology. I knew one of them and I reached
out when I saw that book and I asked them where they got that
name because I love it, but I'd never heard of It before they
said, they invented it and they tried it out at a conference
talk and people liked it and I told him well, I like it too.
I'd like to use it in my book and I'll just reference your
book. So that's what I did.
Their book is a good book teen topologies.
If you haven't read it, you'd probably like it, but it talks a
lot about this concept of, how do you structure your product
teams? What you're bringing up this
notion of alignment and ownership?
There's a lot of different ways to legitimately structure your
product to you. There's also a lot of bad ways
to do it, you know, it's a bad way.
If all of your engineers complain that they can't make
any change without getting 10, other teams involved, it's very
demotivating, the opposite of autonomy.
So it's easy to spot a bad team topology.
It's much harder to say what's a good one.
Now, you can optimize team topologies for different things
in the book. Team topologies, they recommend
optimizing for Throughput, which is a good thing, right?
Getting software shipped, you know, realize they're coming
from Deb up. So, that's is naturally what
they're going to care about throughput in a product company.
We do care about throughput, but we don't care as much about
throughput as we care about, building great products.
So it's not only about throughput.
It's about value, it's not a minor topic.
It's just more of. You can have these different
levers that you can adjust when you Deciding the right topology
for your teeth. When we tell people that
optimized for empowerment, rather than throughput, we tell
them ownership is critical. You need teams to feel like this
is their part of the code base, anything to do with search the
search team owns. Its there's other teams might be
able to change the code and do pull request, but the engineers
on search all in it, are responsible for it.
So that sense of ownership is Very important.
And another thing that's important is alignment what that
refers to. As let's say you're dealing with
Uber and you've got Riders and you've got drivers well if you
have a product team that's structured right around Riders,
they can get to know those Riders.
They can get to test with them. It's much easier for them to be
aligned with the business than if they were on a team that did
some things were writers, some things for drivers, something
For Uber operations people. It's just, it gets hard to know
your customers deeply and that's what we need.
So we say, try to optimize for ownership and Alignment, that's
sort of what we're leading to with empowerment.
Thanks for the elaborate answer. So I think ownership and
Alignment. I fully agree and you mentioned
about team topology, I had a chance to talk to one of the
authors as well Manuel piyush. I think it's like episode 44
long time back. So, I think, for people who
haven't checked it out or haven't heard about this term,
I'll make sure to put in the show notes, maybe you can listen
as well. So the other aspect of this
empowered team is the other notion where you call it a
strong product leadership. So I think moving to the product
management site, right? You mentioned that product
leadership. Has this concept of product
vision and product strategy. Maybe if you can explain, what
do you mean by strong product leadership and what is the
characteristics of good product vision and strategy?
Sure in the book empowered? Explicitly defined product
leadership as the leaders of engineering design and product
management. All three.
So, that's what we're talking about here.
Now, obviously, engineering leadership cares about things
like Tech debt, and architecture product management.
Leadership cares, about things, like product vision and product
strategy. Designed leadership cares about
their own set of things. Like what is the holistic view
of Of our product. What are the design language?
We're going to use for this product.
So all of the leaders have their hearts, for sure.
You're asking about product vision and product strategy.
Product vision is basically what you're trying to do over the
next 3-5, 10 years, what are you trying to do in terms of
helping, your customers have a better life, their company be
better, but how does it help people?
That's what the product vision is about.
It's meant to be very inspiring. And in fact, if you go to a good
product company, the number one, recruiting tool is their product
Vision. They will bring you on so that
you can help work on this important product Vision.
Product strategy is a lot more tactical.
Product strategy is what are we going to do this quarter?
So you asked earlier in our chat, you asked about what's
really the alternative to a product roadmap of a bunch of
features. The alternative is a product
strategy, product strategy is what identifies those problems.
Is that need to be solved by the product teams.
Those products strategies are not just whatever people are
screaming for. It's looking at the data.
It's looking at customer feedback and insights were
getting. It's looking at the enabling
technology, it's looking at industry Trends.
What product strategy is really about is getting the most out of
your organization. So if you have 100 engineers in
your product company, a good product strategy can help that
hundred engineer, Do as much as 500 engineer organization if
that other 501 doesn't have a product strategy, and many of
them, don't sell. A product strategy is really
gets you all about leverage. It's about working, smarter, not
just more features. And I think you mentioned that
if Engineers kind of like having good product strategy, they will
produce tremendous output. And I think the key also here is
to focus, right? I think many companies just
build features, but there's so many features spread across
Across different areas. So I think you brought up a very
good discussion in the book about Focus I will say it's not
just in product management, even people's life we tend to have
this problem of focus so maybe if we can explain it a bit about
Focus here. Well, I mean honestly focus is
the hardest part because the focus part is not just your
engineering leaders in your product management.
Leaders, it's your CEO. And that's usually who I have to
talk to about Focus. There's a great quote from Steve
ABS, which was focuses, not saying no to the bad ideas.
Focus is saying no to 100, good ideas, that's what focus is.
And that's why it's so hard to imagine.
You're the CEO of a growing company and you're very worried
about competition. You're very worried about
customers, not being happy or very worried about running out
of money. You're very worried about all of
these things. So 40-year point of view is like
I want to do all these features because maybe one of them is
really the thing we really need. That's an understandable
feeling. But we have to explain to the
CEO that that actually hurts their chances of succeeding
because not all ideas are equal, not all Focus areas are the same
value to your company. So we need to focus on a small
number of areas. And then of course the real work
of product strategy gets going, which is we To learn about what
is the right thing to do in order to make a difference on
that Focus area. So for example, let's say it's a
fairly young SAS company and they're growing okay, but their
retention is bad, which is unfortunately, very common.
That's like people, try it, but they don't really like it yet.
It doesn't really do what they needed to do.
Now, you can have a problem, which is fixed retention, that's
a problem but there can be a thousand ways to fix.
Option 2 fixture and our product teams need to get to work and
try to figure out what are the things that really matter what
will really make the difference. And I think also sometimes in
this example of yours fix our attention but sometimes some
product companies also do the other focus on the opposite
area, which is like to also bring new users.
So you have a little Focus here. So it's like bringing new users
and also fixing retention. Is there any Converse problem is
a classic problem. They get ahead of themselves.
Normally in a product company, we talk about product markets,
debt and until you get product Market fit, you're wasting most
of your marketing money. And so what companies do is they
often start spending a lot of money on marketing before they
have product Market fit. So now they're spending all
their money to bring more customers with the customers.
Don't like the product. That's a bad business right
there. So is that a strategy to
affecting that you would advise people?
How can they gather better focus?
So that They can actually focus on the things that matter and
focus on building the right product.
Well, I mean it's not that it's physically hard, you'll have to
understand why Focus is necessary.
So a lot of times it's just literally a conversation with
the CEO and explaining what's going on, why, they're not
getting much done even though everybody's busy.
And so you have to explain to them why I focus is so
important. I think everybody I know learns
it sort of the hard way they learn what happens if Don't
Focus. So most product people are very
big Believers in Focus. It's so important for all of
this. And then, of course, what we
want to do is we want to spend our Cycles, getting a great
solution to the problem that is really the most important
problem and that, that aspect Ilia, that you mentioned is
about Recruitment and hiring. I think you covered this a lot
in your empowered book. How to find, good people, how to
actually nurture people and also the aspects of leadership.
Maybe you can tell us a little A bit more about these people
expect, how do you find them? How do you nurture them?
And things like that? Well, the biggest Topic in this
is another one of those very big and obvious differences, between
great product companies. And the rest is, this is a
thing. Nobody, even if you go to a
great University, you don't come out of it, knowing how to be a
great engineer. If you're lucky, you'll earn
some Theory. But what you really learned is
at the job and the point is that nobody joins your company,
nobody joins your Two teams really with the skills they
need. So, it's the manager's job to
coach them. This is such a big difference.
So, for example, it Apple, all of their managers, their
technology managers have four big responsibilities, and one of
them is coaching that Microsoft, there are three big
responsibilities for all their managers and one of them is
coach at Google. They've been very good about
this for many years coaching I know when I introduce some
Nobody to work at Google, they will get coaching, but in so
many companies, they join there's no coaching at all
nothing. It's like here start coating
will have a code review on Friday or something like that.
There's no coaching. And so this is a very big Miss.
I'm glad that more companies are being more vocal about how
important it is for managers to provide coaching.
And if you're a first level manager, a manager of individual
contributors, Your number one responsibility is coaching and
I'm not exaggerating here, coaching and Staffing is
normally about 80% of their work week, so it's coaching and
Staffing. So, you emphasize really a lot
about this coaching. I think it's not just the
manager of the ICS, but manager of the managers manager of
Superman and District the higher you go, the less time you spend
coaching because these people are supposed to be more
experienced by then, but the higher you go, the more you
spend, Bond vision and product strategy.
So how about Staffing? How do you find great people?
You mentioned about ownership mentality, right?
So maybe there's other aspect. Well the biggest thing that I
wanted to talk about in the book empowered was I think there's a
really big myth in the Silicon Valley culture.
People think that Google hires people that nobody else could
hire. I mean we can't hire those
people, only good will can hire those people.
Meaning they're like some kind of Special alien human race or
something, but it really isn't true.
The reason I know this, first of all, I've and working with
people there, for more than 20 years, don't get me wrong.
They have their fair share of very good people.
But what they've learned a long time ago, was great product
teams, they're not made up of rock stars, they made up of good
people that get the coaching they need to succeed.
And in fact, that's where the subtitle of the book came from
ordinary. People, but extraordinary
products, the best teams, I know that's what they have.
In fact, Google shared a lot of their own research on this.
It's under something called project Aristotle and it talks
about what it takes to make a good product team.
If you take the superstars from across the company and put them
together it generally doesn't go very well and we all seen that
what you do much better is hire good people for sure but hire
good people that people want To work with that are not jerks and
Coach them to be great people and that I think is the scalable
solution. So you mentioned this in the
book that a good stuffing strategy, is to find people that
you can trust and trust is a function of competence and the
character of the person. So it's not just the rockstars
that has a lot of competence but it's also the character how they
take ownership, how can they do stuff and learn on the go?
I think that's also part of it. So as we are going almost to the
end of the conversation, you mentioned about Apologies and
how to structure team. This is probably one of the
hardest problems in any software Product Company.
Maybe you can give us some tips on how should you structure the
team's? Some of the principles are some
of the common problems that you see from your consulting, or
from your experience in the industry.
I mean, this is a very difficult question.
So, just to be honest, I get that question that literally
every single company, I advised, I don't think there's ever been
an exception, so it is a very real thing, but before I can
answer Sir it for that company. I have to ask them about a
hundred questions. I have to ask them.
How many Engineers do you have? How many designers do you have?
How many product managers to have?
Tell me about your product? Tell me about your kinds of
customers? How many different kinds of
customers? Do you have?
Do you have personas? I need to know what your
technology stack. How different are those
Technologies? How are you on Staffing against
skill sets? And then I need to get into
things like tell me about your architecture because your
Texture is the biggest Factor on the dependencies.
And so if you want teams like it, Netflix and Amazon, they
say, we want our product teams to be highly aligned.
But Loosely coupled, the highly aligned is not the hard part.
The Loosely coupled is the hard part with that means is minimum
dependencies between teams. So we need to understand the
engineering side, we need to understand the design side.
We need to understand the product side.
We put all this together and then we say, all right, there's
Several ways you could do this. Let's look at the pros and cons
of each. And so I have never once given
the same answer to more than one company, it's always different
because every company is different.
When you look at this level there are some Trends which are
good like we love that there's more platform teams now, we also
love the architectural trends that enable more services
oriented architectures enable us to do product teams that are
more end-to-end. This is a nice benefit so there
are trends that help but it's true that every one of these
companies is different. So what I do is I tell the head
of engineering and the head of product that they have to work
this out together, I encourage them to read the empowered book
on team topology. I encouraged them to read the
book called teen topologies that you referenced and then sit down
and put together what you think is a reasonable approach.
And then a lot of times, we'll put That on a whiteboard and
we'll discuss the pros and cons of those, but it's complicated
in truth, it's complicated. It is indeed too complicated.
I mean, if you have look in a start-up before or even in the
big company, sometimes they do restructure as well because
something just doesn't feel right?
So they structure again and things like that.
And you brought up a good point about architectures, sometimes,
or mostly drives a good team structure.
I think this is what people refer to as with Conway's law,
Mel Conway's law, you should probably also check it.
If you haven't heard about this Conway's law.
So Maddie is been a pleasure. I learned so much about product
management, how to build the right product, not just building
the product. But unfortunately, we have to
end this conversation. But before I let you go,
normally, I have one last question that I asked to all my
guests which is to share about this thing called three.
Technical leadership is MM something that you want to give
advice to listeners here. May be based on your experience
based on your expertise and things like that.
Well sure, I know you're talking about technical leadership in
general, but in particular on product teams, I love the tech
lead role, the most senior engineer on a product team.
And I spend a lot of time with those tech leads.
They are the people often that make the difference on whether
they company innovates or not. But I normally share for things
so I don't know. I, you could pick three from
those four, but these are the four things.
I usually tell them what is that?
They need to care as much about what?
Bill as they care about how they build it.
We were talking about that before.
The second thing I tell them is get in front of real customers
and watch them interact with your products.
I mean, don't let anybody tell you know, you must get in front
of real customers. It's one of the most powerful
things. A tech lead can do.
And then third as the tech lead, they are always supposed to be
asking themselves. Is there something that is
possible? Well today that wasn't possible
yesterday because as you know the Technologies are changing
constantly. Is there something that's
possible today that helps us solve a problem.
We wanted to solve for a long time, but we really didn't know
how. So this is where Innovation
comes from something that's just now possible.
And then the fourth thing I always tell them is process is
never what's important? Because a lot of engineers get
caught up in worrying about process, they easily start
forgetting, what's important. It's not important.
The people on your team is important and the product you're
building is important. Your process is really not while
I left the last one. I'll make sure to put all these
folks right away. So I left the fourth one,
sometimes you have people, we tend to try to extend a dice or
come up with a good process. Optimize the process standard
operating procedures and things like that.
M, but I think you're at the end people and the product that you
built actually met them more than perfecting the process.
So Marty if people want to continue this conversation or
find out more about your books, your resources or blocks
training and all that, is there a place where they can find you
online? Sure, it's SVP g.com Silicon,
Valley Product group.com. Thank you so much for spending
your time. Marty, it's been a pleasure
looking forward, to have more people learning about product
management, and how to build products that matter.
Well, thanks very much Henry, I enjoyed our conversation.
Thank you for listening to this episode and for staying, right
until the end if you highly enjoyed it.
I would appreciate if you share it with your friends and
colleagues who you think would also benefit from listening to
this episode. And if you are new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show
notes of this conversation on the episode page at Tecla
Journal, death website, including the full transcript
interesting. Courts and links to the
resources mention from the conversation.
And lastly, make sure to subscribe to the shows mailing
list on package. You know, dot f to get notified
for any future episodes. Stay tuned for the next
technology, you know, episode. And until then goodbye.