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.