My guest in this conversation is Marty Cagan. If you aren’t familiar with his work, Marty is a very influential person in the world of technology — he’s basically the godfather of modern tech product management.
Before he founded the Silicon Valley Product Group (SVPG) to help others create successful products, Marty was an executive responsible for defining and building products for some of the most successful companies in the world, including Hewlett Packard, Netscape, and eBay.
As part of his work with SVPG, Marty is an invited speaker at major conferences and top companies across the globe. He’s a highly sought after coach to the best product organizations out there, and has had a significant impact on the teams that make most of the tech products you love.
His first book, INSPIRED, is the seminal book out there for how product people should approach their work. Now he’s done it again with EMPOWERED, which he coauthored with his partner at SVPG, Chris Jones.
Please join me in learning about how to create empowered teams and the kind of environment where people can do the best work of their lives, with the one and only, Marty Cagan.
And if you have a moment, I’d love it if you could give me a little feedback via this SurveyMonkey link. (It only takes one minute.)
SCROLL BELOW FOR LINKS AND SHOW NOTES
Links & resources mentioned
- Marty Cagan – @cagan
- New book: EMPOWERED – coauthored with Chris Jones
- Previous book: INSPIRED
- Silicon Valley Product Group (SVPG) workshops
- Matt LeMay
- Teresa Torres
- Mind the Product
- OKRs vs roadmaps
- Books
Transcript
Transcripts may contain some typos. With some episodes lasting ~2 hours, it can be difficult to catch minor errors. Enjoy!
[00:00:00] Andrew: Marty, welcome to the show. We’re going to talk about some of the big ideas in the book and a whole bunch of other things, as it relates to the craft of how do we build impactful products and the cultures that create them. And I think there’s probably no better person on the planet that I could have to talk about that question.
I am so excited. You’re here, Marty, and very, very excited for the new book.
Marty: Thanks very much for inviting me
Andrew: I think where I want to start is just having you talk a little bit about what I understand to be the core premise of the book, which I found to be. You don’t have to have unicorn humans to do great work, right.
That ordinary people. Really can create extraordinary things together. Talk to me a little bit about why that needed to be said.
Marty: There’s two ways out there to manage people. And I find that this is right at the heart of the difference between how the best companies seem to work and how most companies seem to work.
Then of course, the two ways, you know, the classic old way it’s been around forever since the industrial revolution, but. Command and control, you know, where you basically have [00:01:00] managers in the sort of stereotypical Filbert sense telling their people what to do. And I mean, we see this, I see this everywhere, uh, in, in the not good companies, usually they’re telling them what to do in the form of roadmaps.
A bunch of stakeholders get together and put a bunch of features on a roadmap and just say, do this, build this, design, this, and you know, it’s not that you can’t get stuff. Shipped that way you can, but I think it’s not an accident that the best companies work very hard not to work that way. In fact, I love how, uh, Netflix describes it.
Lead with context, not control the idea. Don’t tell people what to do. Tell them. The, what we call the strategic context, tell them why it’s important. Tell them what the business strategy is. Tell them what the product vision is, tell them what their other teams are working on so that they can make good decisions when you do that.
And, and fundamentally what it turns into is you give the [00:02:00] teams rather than features to build you, give them problems to solve. Yeah. Uh, first of all, it’s sort of, obviously it’s more motivating if you own a problem, versus you’re just there to implement,
Andrew: you have agency in something
Marty: exactly right. You have agency and you feel real ownership, and that’s a, of course, a big one, but more importantly, and this is the part that I think a lot of, uh, this is where ego gets in the way for a lot of the, not very good managers in the Dilbert sense.
And that is that very often the best solutions. Will come from the members of the actual product team, you know, and realize the product team is working with the enabling technology every single day. And you’re talking to the customers every single week. It puts them in the best position to see. What’s just now possible.
And that’s really where great products come from is when you combine with just now possible with real customer pain or real customer problems, the empowered team model, uh, that really is [00:03:00] what I see consistently at the best companies, whether it’s Netflix or Google or Amazon or Apple or Etsy or Slack or Airbnb, that’s really the distinction.
Now, of course, there’s many. Manifestations of that. Most people say, Oh, well they have such good product cultures, but what does product culture really even mean? It’s very vague. Uh, and of course, a lot of times product culture gets wrapped up with the personalities of the founders. What it really, I think when you cut down to it, Really means is how do you treat your people and how do you let your people do good work?
And this is all about how do you get people to do good work. And I mean, I, I was very lucky early in my career to work on very good product team. And it is really a magical experience. And I know firsthand, I am not that team made me look better than I was. Sure it is one of those things. When you’re on a good team, when everybody’s doing their part, I mean, I could carry my own weight and I think every [00:04:00] member of the team does have to be competent, but there were no rocket scientists on our team.
They were just. You know, normal people. A lot of us may college grads pretty much right out of school, but we were put in an environment that was set up to let us really do something great. And I’ve been a fan of that way of working really my entire career.
Andrew: You’ve done a beautiful job giving language to something that I have been trying to get language for for quite a while, which is this idea that you can take a person, you know, a person of competence and character, and, you know, the difference between something incredible coming out of this group of people and something that sucks.
Actually isn’t the people, it’s the environment around the people. Are you familiar with the work of a guy named L David Marquet?
Marty: I just read his latest book actually on language, which matters.
Andrew: Yeah. Turn the ship around. And I think it’s leadership is language, something like that.
Marty: That’s right.
Andrew: It seems to me like, it’d be a beauty.
It’s like a beautiful companion for your new book. I think they might go really well together.
[00:05:00] Marty: Amazing to me. In fact, turn the ship around is one that I’ve been recommending to CEOs for a long time. That’s phenomenal. It is. And I could, I have actually a list of about a dozen books like that. They are written for CEOs really about why it’s important to empower your teams.
And I’ve shared these books myself, by the way, there, I tell people these are really good books. They’re motivated for whatever reason. They don’t seem to move the needle much. Not of them. I have not seen, you know, I can get CEOs to read them, but then what do they do? And what I think is really going on is they don’t know how to really put that into practice.
Turn the ship around was an attacks, nuclear submarine. Right. I mean, it’s like, okay, very cool. Well, that’s a little different.
Andrew: Yeah. I work in software. What is I do with that?
Marty: People can relate to the concept and I do think that’s valuable. So I do encourage leaders to read this. But it doesn’t really tell him how, [00:06:00] by the way, I do believe it’s probably different in a special forces operation versus a, you know, a software team versus whatever.
But my world of course, is tech powered product teams. And so I wanted to write about, well, how do you really do that? If you’ve got a CEO that now has religion, they get that maybe one of those books really clicked with them. How can we give them the tools to really set up a company so they can work like this?
Andrew: I want to go into some specific questions I had about different parts of the book and different ideas in there. We’re going to talk a lot in this conversation about the environment, how you lead and create and foster an environment where people can come in and do the best work of their lives together.
And there’s so many things that go into that and you cover, you know, you have major sections in the book, whether it’s staffing or teen typology, your strategy, and you know, there’s a number of these in the staffing section of the book. You talk a little bit about why quote unquote, cultural fit. Is not a, let’s say useful screen when hiring, I was hoping you could talk a little bit about that because that’s, I hear that term a lot.
[00:07:00] And I also agree that it’s not actually what we want, but I think it needs a little bit of unpacking.
Marty: Yeah, it does. And then of course I would argue this doesn’t come from a bad place. I mean, it’s not like people have bad intentions when they say cultural fit. You know, I sort of came to this realization just by so many companies that I work with.
You know, to be honest, they’re so homogenous, basically some companies in tech, I think this is, you know, I’m not trying to say it’s not a problem all over the world, but in tech, so many companies are so homogenous and some of them are really extreme. Literally. They only want to hire from two or three universities.
They only want to hire, if you have a very specific degree and even in their interview process, they are. Testing for whether or not you would solve the problem the same way they do. And I’m like, what are you doing? You know? So it’s of course, first of all, that any chance of diversity is like almost nil out, but even more.
Do we [00:08:00] really want 12 people that all think the same on a product team is not like a thing. That’s not a good cause that helping it’s not helping. And so I’m like, where does that come from? Well, we have this cultural fit thing and I I’ve been in those discussions where you talk about, well, why don’t we want to make this person an offer?
Well, I don’t think they’re a cultural fit, you know? And it’s like, well, I’m not sure this is helping. And what I really think is that first of all, that whole idea of culture is too vague and I’m guilty of this too, because for a long time, I talk and preach about product culture, but it is all true. And you know, what really made me come to terms with us is somebody called me out on this because I have, you know, if you’ve been inside Apple, Amazon, and Google, as I have all three of those companies, they’re all have very different cultures, pretty much extreme.
But they’re all really great at product culture does not capture it. Just doesn’t capture it. And sometimes we say [00:09:00] product culture, but I just started realizing culture’s not really a useful filter on here. I do think is true across all those companies is. The way they empower their teams, they hire smart people, let them do their job.
Um, that is more important to me. And so, you know, and I also, that we have plenty of evidence today, both academic, but also in my world, just empirical the teams have diverse perspectives on the teams. You know, and th th that’s one of the advantages I think Silicon Valley always has had is that it’s not unusual to have a Russian on the team and Indian on the team, but Chinese national on the team.
We just, because of that, we are sort of built in some level of diverse education, some level of diverse life experiences. No, not as much as we want. Because it turns out there’s a lot more kinds of diversity that really do bring great perspectives. So my favorite teams today are just the opposite of everybody.
The same. They are like, everybody’s different. [00:10:00] In fact, when I do today, I’m looking for like, why are you different? Show me something you can bring to this team that like, no, we don’t already have that. I think much more powerful today. I
Andrew: don’t have a better, um, alternative to the term culture fit. One that I heard at my, the product and the product leader summit.
Uh, Matt, talked about this a little bit and he suggested, what about the idea of culture add, is this person adding to our culture? Are they adding to the ways in which we think about the world and, and, you know, approach things?
Marty: I hadn’t heard that, but I liked that I kind of take, uh, you know, the older I get the blunter I get, I turned it into more, just like.
Don’t hire assholes. That’s really what we really care about more than anything, as long as they’re not toxic to the team, to the organization. That’s like the only filter I really care about. I care more about that over time than I used to. I [00:11:00] used to be one, those that would be occasionally make an exception because somebody had.
Andrew: Or no. Good.
Marty: You know, and now I learned like that is so short-sighted because it, it comes back to bite. You consistently.
Andrew: I resonated with this book so much because of my own experiences where I’ve experienced kind of both sides of this equation. Like I’ve experienced the, the, you know, the, Oh my God. It could, could I be more lucky to work with this team every day?
And I’ve also experienced the, like, what the hell are we doing here? Like, I don’t w what’s going on, you know, and, and seeing so much talent go to waste, which is, there’s nothing that bothers me more on like a fundamental level than the wasted human potential of people. Just building dumb stuff that doesn’t matter, that doesn’t make the world any better ends up.
Not working in the market anyway. So it wastes their time, like th th that’s stuff that just deeply bothers me. And so I think that’s part of the reason I resonate so much with your work.
Marty: Yeah. The flood is deeply bothers. Me too.
Andrew: Yeah. I had a feeling I did at reading the book. One of the things that you talked about in the book, In terms of hiring, there’s a certain practice you advocated for in the book about the hiring manager, you know, not view [00:12:00] themselves as a, a passenger on the ride of hiring right there.
It’s not, it’s not HR job. It’s your job. As the hiring manager and HR is helping and you’ve talked specifically about. You know, when it’s coming, when it comes time to make an offer and that the, the, the hiring manager needs to reach out to the person they’re making an offer to and make a very specific type of call.
Marty: And I was hoping
Andrew: you could speak to that a little bit. Like, what is that call and why is it so important in addition to, whatever’s going to be captured in the formal offer?
Marty: Yeah. Well, and it’s because this is really the. The start of the, the important relationship, which is a coaching relationship. As soon as you hire somebody, it is your responsibility to help them reach their potential.
I mean, if that’s a college hire or something, then it’s to help them reach competence and then reach potential to me, it’s a, you’re basically making a very explicit. Agreement with this new person. And I, I do encourage hiring managers to really just get it out on the table like this, like, look, I think you’d be a great addition.
[00:13:00] I am willing. To personally, do everything I can to help you reach your personal and professional goals. All I’m asking for you is you put in the necessary effort. If you put in the effort, I will put in the effort on my side and, uh, and I, that’s what I’m here to do. My number one responsibility is to help coach and develop you to reach your potential.
And in fact, if I can get you promoted, then I win. That’s my success. So that is, that’s a very explicit sort of contract, right. You’re saying with somebody, and that’s the role that I would argue. That’s the necessary relationship, having somebody from HR dealer call, uh, like that is not the same manager cares about you, but maybe not because he didn’t want to, you know, they
Andrew: didn’t want to pick up the phone for five minutes.
Marty: Yeah, that’s right.
Andrew: That is really beautiful. I was having a conversation with, um, another, another project guests and she spoke so beautifully about people. Uh, [00:14:00] you know, they join companies, but they leave managers. That’s a, that’s a pretty, pretty well understood Warren thing, but going above and beyond that, she quoted some research where they had people ask.
They sort of pulled people about like, who are the most significant relationships in their lives? You know, people don’t, they’ll talk about their doctor who takes care of them and keeps them healthy. They don’t talk about like their accountant. Obviously they talk about like family, right. But on the very short list of those people.
Was like their manager, right? It’s like, wow, that’s a, that’s a very special privilege to be that influential in someone’s life. And I feel like that’s under appreciated by most people who are in managerial roles.
Marty: I couldn’t agree more. And that’s why I try to tell managers that their number one responsibility is coaching.
Andrew: You know, we were speaking just a minute ago about the fact that you can have is incredible experience working on a great team, right. There’s there really is. Like, in my opinion, there’s no better work experience in being on a great team. It’s just, it’s just phenomenal. And then you can have the opposite experience and.
One of the things that I’ve learned over the course of doing this podcast from, from people with much more experience than I, is that a very common [00:15:00] regret
Marty: of, of people
Andrew: going through job searches, hiring processes is that they get really excited about something, right. They get excited about the company, about the team, all the stuff, and then it turns out.
It just, that was a bit of a Mirage. It wasn’t actually, it isn’t actually the way they thought it was like they, what they, what they
Marty: bought and what they
Andrew: got is not what they were sold. Let’s put it that way.
Marty: Yeah.
Andrew: Someone who’s on the outside of a company. Right. So someone who is interviewing, looking for their role in whatever level of a product team, as a, as a PM, as a, as an APM, whatever.
Marty: How
Andrew: can people who are interviewing and looking for their next role, really suss out whether or not as a quote, true, true quote unquote product culture, right. And all the ways that that means, like how can we figure out in advance that, Oh, this is going to be a place I really will be empowered. And I can really work to my highest potential and all the ways that I know I should work, that the community’s figured out or that it’s just window dressing.
Marty: Yeah. Well, of course from the hiring managers, point of view, [00:16:00] their job of course is to number one, make sure you’re competent. You have this basic skills that the team needs. And number two, you’re not an asshole. So that’s what you’re looking for. But from your point of view, your job is to learn as much about how that company really works and especially how that manager would be like to work for.
We have of course, many good ways to do that. You have to be, I always try to coach the, uh, Interview candidates to be realize your first obligation is to show them you’re capable and you’re a good person, so they should want to hire you. But assuming you can do that, you definitely want to take advantage of every opportunity to learn about these, uh, to learn about this question.
What is it really like? Uh, one of my favorite ways of course, is to ask, to be able to go to lunch with the team, for example, Oh, well, if you can find so much out just by the dynamic, that team doesn’t even have to be work-related you can literally just go to a restaurant over in an hour, hour and a half.
You could figure that out. Uh, I also [00:17:00] would ask people that you talk to what it’s like to work for that manager in the interview team. What’s it like, uh, how do you get coaching? How often do you get coaching? What kind of coaching is that? You know, how do you make decisions here? How does work. Uh, get assigned to our teams will tell us things like if it’s a feature team, is it a empowered product team you could ask?
How, how is success measured here? What is it like? Uh, how do you handle hard product decisions? Can you tell me about your last hard product decision and how you guys dealt with that? These are all totally, um, innocent questions, right? They are not accusatory or anything like that. They’re just like. Tell him tell me the things I should know, you know, so
Andrew: tell me what it’s like here.
Marty: You can get a very good understanding now, of course you could be, it could all be a big demo. Like you said, it could all be a facade, but you know, that’s pretty hard to deal and it’s also not, um, you know, it’s not really to the company’s best interests because if they know you’re going to join here a week later, if you’re going to [00:18:00] figure it out, when I’m the hiring manager, especially, I always make sure.
On the interview process to share the things that are difficult about the company, because I’m like, I know you’re going to, if you come here, then you’re going to learn this stuff and I want you to come in eyes wide open and I’ll point out like, okay, well, the CEO is like, Very opinionated. So what we’ve learned is that you have to really do your homework with the CEO and provide the data that works, but you have to do that.
So I’ll have that conversation. Uh, I just think it saves cause you know, when you hire somebody and then they leave, that’s like the worst of all you spent all the time and money and then it’s really expensive mistakes. So I would much rather it be as fully informed as possible.
Andrew: Is there one particular, you know, if you, if you could have an interview candidate ask about only one thing that you think would tell them the most about where the company they’re interviewing with is on the spectrum from, you know, feature [00:19:00] factory to truly empowered product team, what would the be the thing they should ask about.
Marty: Well, what I usually recommend for that is that ask how work is assigned, ask how the team decides what they’re going to work on. Is it something that’s, uh, you know, how does that work? There’s only a few main ways that’s done, but they’ll typically describe it. And it’s what they’re used to. So you’ll be able to recognize that.
Andrew: Hmm. Perfect. Yeah, you can, you can, I’m sure. You’ll find out pretty quickly if like, okay, is this truly a sort of an OKR based, uh, you know, both top-down and bottom-up negotiation or is this like, you know, are people handing on roadmaps and saying go, uh, so I guess that’s a, that’s a good way to, but
Marty: do they technology as a cost center or do they think as a enabler for the business?
Yeah, these are the things that come out in that question.
Andrew: It seems like a lot of this, a lot of the issues that we see really do germinate from, from either the seed of bad leadership or the absence of leadership, frankly, probably more often the [00:20:00] absence than, than actual negative toxic leadership. In the book you talked about, the company’s view of the role of technology is one of these root causes.
And I was curious, you know, what are the other big ones that really at the base underneath everything are driving all of the problems that we see.
Marty: I do zero in on that. Uh, there’s sort of two things that the root that I focus on one is, you know, how do they fundamentally view technology? Like you talked about?
And the other one is fundamentally, do they trust their people? Uh, and trust trite at this point, people, you know, it’s a major thing, but you hear it all the time, but it really is true in an empowered product organization. It’s predicated on trust in every direction, right? The members of a product team trust each other.
Like I trust my designer, I trust my engineers, uh, and. We also trust our leaders to provide us the context, but then we’re trusting that they will let us figure out the best way to solve problems. They are trusting that [00:21:00] we will make good decisions. We will keep the interests of the company and of the customers, foremost, their trust.
There’s a lot of trust that is go around. And when that trust is not. There for whatever reason it’s never been there. It was, it was lost for whatever reason. It’s really hard for the company to do anything but command and control.
Andrew: I have a specific section in the book where you sort of call out the agency model.
And I’m curious, is there any saving the agency model if people really want to work in an empowered way?
Marty: And just to re to be clear, cause we also talked about sense of agency, which is more of a sense of ownership in your work. Yes. The agency model in the book was referring to literally where, um, well, I, I actually talked in the book about two things, real agencies, like.
Can you be a successful company, if you decide to hire Accenture for all your development? Uh, that’s been a model and no, I don’t think you can. That is a true mercenary model. Uh, and it’s nothing wrong [00:22:00] with Accenture. They’ve got a beautiful business, but. Tech product companies are really not their business because of this.
They are, do better, much better on custom solutions. But, and then I also talked about where companies unintentionally often set up like an agency inside their own company, like classic example of that is a design group that doesn’t. Believe that the designers should be in the room where it happens with the product manager, with the engineers.
So they just want to be in their own little agency and they just tell people to tell us what you need and we’ll provide you your design, the internal agency model. And it’s really a shame because, uh, fundamentally when it comes from, I argue is not understanding the real power of design, because if you really do, you don’t want your designers to be brought in way too late, which is what happens in that model after.
Bad decisions have already been made. Yeah. Companies do that. I understand. Uh, also, you know, some of the human motivations for that, if you’re a design leader and you want all your [00:23:00] designers together and you want to just sort of, uh, circle the wagons, if you will,
Andrew: the it’s just going to shape everything they do probably for the worst, frankly.
Marty: Oh yeah. I want to talk
Andrew: a little bit now about sort of the structure of a, of a product organization, right? So, you know, you talk about team typology a lot in the book, and I think I want to start with clarifying something that I think is. Likely often confused when people come to you about this. And I was hoping you could talk to me a bit about the difference between autonomous teams and empowered teams.
Marty: Sure. Well, they’re related for sure. Um, but autonomy refers to your product team. How much of the skills. And the code that you need to change is within your control in a hundred percent autonomous team, which to be fair is really only found in the smallest startups.
Andrew: Yeah. That doesn’t happen at any, any sort of size.
Marty: No, but it’s a theoretical thing. In theory, under a hundred percent autonomous team would be able [00:24:00] to make any change they wanted without. Depending on anybody else and almost never the case, uh, especially at scale and it doesn’t have to be, but however, we do want to, we do want to maximize our autonomy.
Empowered, refers to whether or not we get to figure out the right, the best solutions to the problems we’re asked to solve. So these are related in an ideal world. We’d be empowered and autonomous. Hopefully what we are is we are empowered and we’re mostly autonomous. Uh, it’s not unusual that we have a dependency on a platform team that has to make a change.
And maybe that platform team has a dependency on AWS. Uh, and we kinda all have to live with these. You know, dependencies are never good. They’re a sort of, we want to minimize them, but a lot of times they make a ton of sense. So for example, it’s absolutely a smart dependency for companies to build on something like [00:25:00] AWS or Google cloud or Microsoft Azure.
They should, they should accept that dependency. It’s a great deal for them. They’re getting more than they’re giving up. Similarly for a medium or large size company, the company is almost certainly going to do better. If they introduce explicit dependencies on platform or common service teams, uh, that’s a, that’s an acknowledged dependency, but they do it in the name of.
A lot better results holistically. Overall, it lets the teams that now have that dependency on the platform team not have to worry. They can treat that platform team like a black box, just like we treat AWS as a black box. We don’t have to know, uh, all the hurdles and it lets us focus more on the experience level on the customer and on.
The real innovation we’re here to do, which is not reinvent the wheel.
Andrew: I think that surprised me a little bit was this idea that actually the product vision is what drives the team, [00:26:00] topology and the structure. A why is that? And B in practice? How do we, how does somebody actually do this? If once you spend the time to come up with a compelling and true product vision about a future, you want to build.
How do you translate that into reality of saying, okay, if we’re building that the teams have to look like this.
Marty: Yeah. Well that is a big question. So let’s talk about it. I mean, we’re going to, this is, you’ll see, this is a very big major topic we’re really getting to what’s the real role of leadership and what does it mean to have strategic context?
So the product vision is. The product vision is where we’re trying to go. Of course, in the next several years, usually three to five, where five to 10 for devices, but it’s way out there. Uh, now. There are several things that derive from that product vision that one of the most important ones for everybody on a product team is actually the architecture, the architect derives from the vision.
If you don’t have, in fact, the product vision, and your company tries to redo your architecture, you will [00:27:00] probably waste literally millions of dollars. And that’s not the
Andrew: fault of replatform again and again.
Marty: That’s right. It’s not your engineer’s fault. That’s your. Uh, the lack of a product vision’s fault.
Um, cause of course the job of an architecture is to provide the technology that lets us deliver on that vision. Now of course the vision is several years out. We don’t need to build the architecture today for the next several years, but we do need, you know, you have to realize your engineers are making literally hundreds of decisions all the time.
And if they know where we need to go. Architecturally vision wise, they can make much better decisions than if they don’t. And by the way, if you don’t have that vision. And the other big thing that they’ll do is build an architecture that met the needs of the last five years, rather than so the architecture is a huge.
Consequence of the vision and should be, but now you have this vision of where you’re trying to go and you have an architecture. The team typology is the best way for us to structure our product teams in [00:28:00] order to deliver on the vision. But it’s worth acknowledging, fit best with the architecture because the architecture is the number one factor in how many cities we have.
So, if we want to minimize dependency to your earlier question of autonomy, if we want to minimize, uh, dependencies architecture is extremely important and sell the, uh, vision drives the architecture and the vision and architecture together, drive the team to policy. So the team says, how many product teams do we have?
What’s the scope or charter, if you will, of each team, what are the rules? Chips between the teams, what are the technologies that the teams need to be skilled in and to work with? So, um, typology is all important because that really gets into the dynamics of our product teams themselves and the product to Polish.
The team typology is something that really the head of product and the head of. Technology need to do [00:29:00] together because it really is a compromise, a blend between those, uh, those different forces and tensions. And it’s all I tell teams too. There’s no perfect typology. Anytime you optimize for one thing, it’s at the expense of another, in general.
What we’re trying to do is we’re trying to optimize our typology for empowerment. Uh, Netflix and Amazon, they like to say, when we talk about topology, they want loosely coupled teams that are tightly aligned. Right. So that’s really what we’re trying to do. It’s teams the most autonomy and empowerment we can.
Yet, uh, we’re all going in the same direction. So, you know, these are big topics. Um, the obviously big, like multi hour topics in there in and of themselves. Uh, and then there’s, there’s another big one just for a completion, which is the product strategy, which is other topic about how we, um, how we decide really, which.
Problems each team needs to go [00:30:00] after
Andrew: what are the audiences questions that came in? Actually, it was about this, this idea of typology and vision, and, um, you’ve answered part of it already, but just to, for the sense of completion for the audience, one of the questions was how is a product vision distinct from the corporate vision or the company vision?
Marty: Yeah, well, you know, it’s usually the word vision. Um, it’s similar to the word strategy there’s that it can exist at every level, right? Just
Andrew: lots of meetings,
Marty: strategy, marketing, strategy, product strategy, whatever. Um, and of course, normally we don’t talk so much about company vision. We talk about, uh, a company mission.
So a company has a mission, like organize the world’s information, very famously, but, um, the mission is kind of really. What’s the purpose of this business and why are we here? Why are we here? And I, of course, who could argue against that? It’s like, if you have an employee that doesn’t know what we’re doing here, that’s a problem.
But the purpose doesn’t really answer [00:31:00] too much other than why we’re here. It doesn’t really tell us to do or anything like that. So product vision is really where it gets to be much more tangible product. That’s okay. Well, we know what our purpose is, but what are we, what are we really trying to create here?
What are we trying to build over the next several years? And one of the reasons product, vision is so critical is, um, when you have many. Product teams. This is the such an easier problem in a true early stage startup where one company equals one product team. Yeah. What we’re doing and
Andrew: there’s only nine of us.
So
Marty: that’s hard, totally, uh, on port, but let’s say you’ve got 25 product teams, midsize company. You want to make sure that all 25 product teams know what the common goal is, what are we trying to achieve together? And they also. Oh, how their work fits into that greater whole. That’s why in a lot of companies, they’ll refer to the product vision as their North star, [00:32:00] so everybody can see where we’re heading and they can see how their work contributes to that.
But, um, but that’s the difference. Really product vision is much more, uh, tangible. It’s a, uh, I’ve never seen a useful product vision come out of something like a canvas or a, you know, fill in the blank. It’s harder than that. You’re really trying to show people the future. We usually do that with a vision, a prototype of a vision, which is a color vision type.
Sometimes we’ll make a video showing that off, but because a vision is meant to be emotional and persuasive. So it really is meant to show you why we’re going to do all this work, how it’s going to make the lives of our,
Andrew: yeah, it really seems to be the critical. Artifact that kind of brings the, you know, put some meat on the bones of the mission.
Right. The mission sounds great. And everybody’s like, yeah. Cool. So what does that actually mean? In reality? And then you see something like a real vision type and you’re like, Oh, okay. And I I’m imagining that’s probably why it’s such an effective recruiting tool.
[00:33:00] Marty: It is it’s, it’s really my favorite recruiting tool for the right kind of people.
You know, when we’re looking for people that actually care about what they work on, if you’re just, if you’re just looking for a job to pay the bills, then you know, that’s right. But if you’re looking for something because you really want to do make a difference in the world, even in a little way, you know, you want to work on something meaningful that.
That’s what you’re interested in, by the way you asked her to what are good ways to find if it’s the right kind of company and, you know, saying, can you describe your product vision? You know, they should have great answer to that and you should see their eyes light up now. No. Okay. Now we’re talking about something cool.
And a whole, hopefully even the, you know, whoever recruited you is already kind of started to sell you on the vision, but still you want to understand.
Andrew: That’s a really, really important one that I think gets overlooked a lot, because it’s almost like visions at V the whole vision thing has been done so poorly that most people just [00:34:00] don’t even believe anymore that it’s like,
Marty: yeah, well, you know, it’s unfortunate, but most people, when you say vision, they think you mean a mission statement.
And there are these things, these sort of fill in the blank, canvases that, you know, words, and none of I’ve never seen those inspire anybody. Ever. So they they’re, they’re talking a different thing. Uh, they also usually make the mistake of doing that on a team by team basis, which really misses the point.
They completely miss the memo of, of how powerful these things are. But, you know, because of that, a lot of people are, you know, uninspired by their company vision. And so I really do think this is a critical thing for the leaders to correct.
Andrew: Let’s talk now about kind of how we bring that vision to life.
So product strategy, which I first heard, I think, I think I actually got this definition from you when I, when I took your workshop however many years ago, that was, uh, that, that at least at the time, I think you said product strategy was sort of the. [00:35:00] Sequence of product market fits. We would pursue in route to fulfilling that product vision, uh, and sort of now you’re kind of giving a little bit more abstract of a definition of, you know, it’s basically, how do we choose what problems we’re going to solve
Marty: in, uh, empowered.
I go into much more detail on product strategy. Um, you know, the backstory there, what really happened was. Up until I wrote empowered, I felt like product strategy was one of those things I had to talk face to face with the company about, in other words, so company specific, we really needed to talk, but then of course, what I really realized was that this was too important and.
It’s not scalable. If it’s just, you got to talk to them, it needs to be more scalable. So one of the most important things decided I was going to do when I wrote empowered was I was going to tackle product strategy and try to write about it in a way that’s useful for everybody, or at least in the tech product world.
So there is a lot more depth there to it. We still very often end up with a series of product market fits, [00:36:00] but that is, but now there’s a lot, I’m more into the reasoning. Why and how you would actually do that.
Andrew: Yeah. You talk about basically a high level four step process of going from focus to insights, to action to management.
What part of that do people get wrong when they try to actually put it into practice?
Marty: All four. Okay. It’s true. All four. It’s so funny too, because yeah, this is why for a long time, I felt I needed to do this. One-on-one uh, the first is focus, you know, I would talk to a company and they think they’ve already focused and they would show me a list of 40 major objectives for the,
Andrew: our 40 top priorities on the wall over there.
Marty: Oh my God. Give me a break. You’re not close. You know, even four would be a lot, so we need that.
Andrew: Yeah, let’s try
Marty: to. We would often needed intervention. And you know, that’s the kind of thing. A lot of times you have to sit down with a CEO and say, look, here’s the problem you can try, but you’re not going to, you’re going to do just like you did last year and the year before you’re going to get almost nothing done and [00:37:00] nothing’s going to move the needle.
So we need to talk about how good companies do that. This is what focus really means. Uh, and sample is very often, the answer is especially for a startup. Product market fit. Nothing else matters. Get to product market. That’s our one focus. Don’t try to do 10 things. Don’t try to ramp up the Salesforce at the same time.
You haven’t even figured out your product, that kind of thing. So focuses the first one, they usually mess. Well. Don’t necessarily appreciate what focus really means. Just one is insights. So say you do focus on an area. How do you really decide where the levers are to get the most out of your organization?
Because product strategy is really about how do you get the most out of the, the resources, the people, the talent. You have and the tightening up. So it’s about working smart. And so how do you do that? Well, you need insights and a lot of companies are not set up to harvest to even identify, um, you know, [00:38:00] monetize those insights.
So I try to explain, you know, that the, the, the data is a primary source of insights. Your customers are a primary source. You’re enabling technologies. The primary source, the industry is a primary source. So you need to set up the channels so that these insights are identified and then escalated to the leaders.
And then the leaders side, which ones to really double down on and monetize if you will. Um, and so insights is the second one. They don’t necessarily do very well. Um, those are like developing muscles, you know, you just need to build those muscles, uh, all the best companies. I know. Their muscles are very well developed when it comes to insights.
They’re very good at that. They’re all like all, they’re an organization that’s optimized for identifying and then exploiting those insights. Then the third thing, which they very often mess up is how do you turn those insights into action? How do you act. Execute. [00:39:00] And the there’s really two ways of doing that.
We talked about this right at the beginning. The first way is you, you command and control. You basically say, okay, this is what I’ve decided, build this that’s the roadmap strategy. And then the other way is of course, to give the teams the problems to solve, which is of course what I advocate, because that’s how you empower teams.
Um, so that’s the. The third and the fourth way they often mess up is, you know, no matter what the strategy is, no matter how good it is, how, how strong the insights are. As soon as teams start working on them, it’s like no strategy survives contact with the same thing. Um, because things will happen. Like teams will identify dependencies.
They didn’t realize existed. They’ll realize they need some technology. They realize there’s a staffing, you know, we’re missing a skill on the team. And so. The good management will, it’s sometimes called servant-based leadership, right? They are there [00:40:00] to, to help remove the obstacles to, to smooth the path for the teams.
Bad management says, okay, well you screwed up. Let me take over. Let me drive. Yep. So these are the four things behind product strategy and truthfully, all four are hard for many companies, so, but they’re all learnable. Absolutely. That’s the thing. None of those are things that a company can’t do.
Andrew: If you’re trying to make this change from within the product organization and you’re not in charge, how do you actually do it?
How do you make this transformation?
Marty: Honestly, if you are in charge, then it’s much easier. You know, here’s why, because a lot of people wondered why do we really need the CEO on board here? Because the CEO really doesn’t have to do any of this stuff. Uh, but why? And, and the reason why is because. When a company works the way we’re talking about it impacts much more than just engineers, designers and product managers.
It [00:41:00] impacts HR the way you hire it impacts finance the way you fund it impacts sales and marketing. It really does impact everything in the company. And that’s where you need. The air cover of a CEO to really hopefully because they understand either because the old way hasn’t worked either because there’s a new threat.
Now Amazon’s coming after them, uh, as for whatever reason, but this is much easier when you are in control. If you’re not in control. And I have this conversation with a lot of teams that are like, Oh, my gosh, you know, accompany doesn’t work. They don’t even seem to get any of this. And can I do, I mean, a lot of times they’re like, should I just quit and go to a company that cares about products, cares about customers.
And I’m like, well, before you quit, it’s worth trying this out. And I’m obviously I did write a new book to try to, so giving the book to leaders, I am hoping will help, but you know, you can’t make them. Read the [00:42:00] book or anything like that. So what you can do though, is go to the leaders and say, Hey, one of the things I learned is that the way we work is not how Amazon works.
It’s not how Netflix works. And maybe what we could do is do an experiment. How, what would you think of letting our, our team or a couple teams work this other way for a quarter to. And let’s see if we can get some of the benefits they have. Obviously they’ve got some pretty big benefits, you know, they’re the most tons working pleaser in the world.
So, you know, the green motive enough should be appealing. And so most companies I know. The leaders will at least do that. They’ll at least say, okay, we’ll do an experiment, but if it doesn’t work, we’re going back to what we know, you know, something like that, but you know, that’s not bad. And a number of companies that have transformed really have started that way, that were somebody, um, somebody felt like it’s worth trying [00:43:00] and some decided it was worth letting them try it.
But it is true that the impact is fairly limited in that model. You can still do better than you were doing in my experience, but it’s limited because the broader changes that we’re really talking about here, um, are not always able to happen because of you don’t have the air cover. So hopefully you can get the company to step it up.
Andrew: Doing this, um, I’m going to call it like a pilot team approach. So let’s say you get buy in to do that. A lot of people, a lot of those leaders seem to be really skeptical, which is, you know, fair. If they, they know what they know. Is there any particular agreements that you think are most important to make that pilot come off?
Well, assuming the product team itself, you know, really gets after it.
Marty: Well, there’s a lot of things that you would focus on. One of the things I tell the product team is that usually the engineers and designers are like, they are not the problem. They know what they need to do and are thrilled to [00:44:00] finally be able to do it.
The product manager really needs to raise his or her game, uh, because the role of a product manager in this two models is completely different. They really shouldn’t even have the same title, but. Yep. For historical reasons, they do the job is night and day different. And so it will, it’s like a house of cards.
It will collapse and fail. If the product manager is not able to do this new job. And a lot of them may not ever, never have done it before probably, and don’t know what to do. So that is really a prerequisite. You know, it is also true that there’s, like I said, there’s a lot you want to try to do to get the company.
One of the things that’s hard is if the head of product and your scenario, the hypothetical, the VP product says, yes, we’re going to do this with a team. It’s not just that team that’s impacted at the very least that team has a set of stakeholders are used [00:45:00] to a very different way of working together. So the model where they tell the team what to do.
And now talking about a model where they don’t tell them what to do. It’s and it’s not flipped is just the, now we say you’re moving from the subservient model to the collaborative model. Now as partners. Now, if you pick a pilot team, but you don’t. Make sure that pilot team has, uh, some stakeholders that are on board for that same experiment.
Of course you’re setting things up to fail. Yeah. That’s probably the biggest, uh, the two big things that I see not go right, is one, they don’t have a product manager that knows what’s necessary and they don’t have the, uh, the partners in the rest of the business that also wants something, one to try for something better.
Awesome. Why would I
Andrew: ask a couple of quick audience questions? And then we’ll go to some rapid fire questions and close out. One of the people in the audience, Diane, she asked that we’ve also fallen into the trap of separating the [00:46:00] definition of the problem from the definition of the solution. And Marty you’ve addressed that in some of your blog posts, but I’m wondering if you could speak a little bit more about the downsides of separating these two bits, these two definitions.
Marty: Well, We can get philosophical here pretty quickly. Uh, and I want to keep this very, uh, practical for people, but, um, you know, it’s very, a very old way of thinking was we would, somebody would define a problem and then somebody else would define a solution. And here’s the thing. So often as we progress in our understanding of the solution, we have a different understanding and a better, and a deeper understanding of the problem.
And in fact, We don’t even, it is a non-problem, uh, you know, it’s, uh, it’s one of those things that were enabled by technology and then people realized they had, you know, they wouldn’t use the language of a problem there. These late needs, they would just say, Oh gosh, I can’t live with now, but I didn’t even realize that was [00:47:00] possible.
So. So we ended up, um, siloing when we separate things out. And the biggest consequences of that is usually you have certain people worry about the problem. The classic is we have our product manager and our designer worry about the problem. And then we have our engineers worry about the solution, which really breaks our, our, you know, the chance of innovation.
It, it under chance of innovation because really those engineers. To just leave them to the implementation is a huge loss. What, you know, I’m sort of famous for saying at this point that if you just doing, using your engineers to code, you’re only getting about half their value. Um, so we really want to expand the richness of this.
If all you did was as you explore the problem, you included engineers. And as you explore the solution, you include designers and product managers. You’re already doing much better. So just sort of try to knock down the wall [00:48:00] between those two. Obviously, you know, we care about problems. We care about solutions.
The other thing I like to tell people is look, we have very good techniques to understand problem. It really doesn’t. But a lot of. Product teams, especially a lot of product managers want to spend like months on the problem. What I try to tell them is if you fail, almost certainly it won’t be because of the problem.
It will be because of the solution. Your solution is not good enough to get people to switch. And I, and this is just reality. So you need to pace yourself and spend most of your time on the solution. And again, don’t just leave that as an exercise to the developers, you do that together, product design engineering to come up with a great solution, and we need to spend on the order of 90% of our time on the solution.
Now, if you’re unsure on the problem, then definitely you need to tackle that, but we can tackle that quickly [00:49:00] today. Cool.
Andrew: Uh, and then one more. This is from Steven, who is a senior PM. He says, I believe that user research is vital to the success of our products. And our organization has definitely benefited from interviews, listening to prospects and customer calls.
He’s finding that when push comes to shove, there’s always something needed more urgently. And so this
Marty: question is
Andrew: how would you advise someone who’s frankly, having a hard time, really keeping user research in that close customer contact as, uh, you know, on priority with all these other things competing for their time.
Marty: That’s a good question. It’s a little nuanced, but it’s important. So I, this is going to take me a minute here. Go for it. So user research is one of the most important things we do. You heard me. Say earlier on product strategy, insights, insights come from our data. They come from our customers. And in fact, uh, when we say come from our customers, that’s usually via user research.
So we love user research. Now it’s important to realize there’s actually two kinds of user research. The user researchers kind of break the learnings into two [00:50:00] categories. One is, uh, okay. We have an idea for a solution. Right. I need to see if this solution works use, it helps us understand, does it work?
And most often when it doesn’t, they help us understand why that’s called research. They are evaluating how well this solution worked to help our customers with their problem. That is the most common. User research. We do, we do it on a, this is when I tell teams that you need to be testing your ideas with actual users and customers no less than three hour long sessions a week.
That’s what I’m referring to you need that is because you need to be able to explain the data. Doesn’t tell us, it tells us our solution is not working. It doesn’t tell us why the research helps us figure out why, so we can fix it. Right. So we really want to do is fix it. That’s the most common kind of user research.
That’s the stuff [00:51:00] that’s happening all the time. There’s another kind of user research, which I love. That’s called generative user research. This is where. Oh, my gosh. Maybe we should even be, maybe this isn’t even their most important problem. Maybe a much bigger problem that we’re not even looking at. Now.
That’s an insight that comes from generative user research. Now here’s the thing. This is where the new land nuance comes in from the leader’s point of view. They have given the team a problem to solve. So what they really want us to do is solve that problem. If we hunted them, say, we don’t really want to work on that problem.
We want to work on this problem instead, not the deal guys. That’s not how empowerment is supposed to work. That would just be, you know, From their point of view and at archi, right? You just work on with doula, however you want to do, you know, we’ll end up going in 55 different directions. Now that doesn’t mean they don’t want to know that insight.
They do. [00:52:00] The good ones, especially they do want them, but they want you to understand that your primary job is to solve that problem. That’s mostly evaluative user research as do that, though. You will occasionally get an insight through that is really powerful and it is the job. We try to train our designers and our product managers when they spot these insights.
To immediately escalate them to their manager. And in fact, very often those insights, first of all, they might apply to other teams right now. So the, the managers can spend, but they also might impact the product strategy for the next quarter because the powerful insight, occasionally the insight is so.
Profound that it actually changes the course of the company, whole different thing. That’s called a vision pivot. That’s another discussion, but we love these insights. So just it’s I always have to coach the user researchers [00:53:00] on understanding because a lot of them think their job is like 90% generative.
It’s 90 go out and figure out the problems. Like, no, you know what. We kind of know these are the problems we need to solve in order to deliver on our business strategy and our product vision. So it’s not really about that. It’s about coming up with good solutions that really work for our customers. That kind of user research is the most tangible frequent.
Every week and we doesn’t mean we’re not interested in generative. And once in awhile we may pursue a much more open-ended set of research to generate inspire more and more ideas, especially if you’re looking for a major new product, vision, or product strategy.
Andrew: And how do you coach teams? So let’s say you’re working with a product team and they’re having a hard time finding those three hours a week.
How do you help
Marty: them? You know, we’re really getting into the time management question and I would argue that these, in fact, I do, I tell them all the time, these three hours a week are [00:54:00] probably the most important of your week. Right. If you had the cuts up, ties it. Yeah. Now, um, there’s a lot of ways we can, uh, work smarter.
Of course, product discovery in general, in this testing with users is just part of that product discovery is all about getting to. Money faster, right? Time to money. It’s all about getting to a, an effective solution faster. So it’s really not. Uh, this is a very much a speed thing. Now, if I, if you’re a team that’s been going off for two months on the same problem, then they need serious coaching.
Do quite a bit in the week. We don’t need much for most things.
Andrew: Yeah, absolutely. Well, thanks for that. So we’re going to go ahead and close out now, a couple of rapid fire questions, short questions. Your answers can be as long as you’re feeling. Um, so the first one is what is the thing you would say, you know, best.
Marty: Uh, well, I would say that my sort of lucky advantages I have [00:55:00] had in, I have had a chance to, to see up close some of the best teams in the world work. And that gives me a real advantage and it helps me see the difference between the rest of the teams. Lots of us have seen bad teams, me too. Uh, but yeah, not many of us have been able to see.
Excellent teams. So to you,
Andrew: what is it that makes for a meaningful problem or product?
Marty: I can get very motivated if I can see how real people life can be better. Even if there are people that are not dealing with working on a very non-sexy thing like finance or accounting or taxes, there’s something. But if, you know, as long as there’s real people there.
And you can really improve their life with technology. Uh, I find that very motivating and I find that most product teams can get very motivated. Yeah. Same for me.
Andrew: What’s a quote or a saying that is important to you that you returned to often. And you know, what about it speaks to you?
[00:56:00] Marty: Well, one of my favorite quotes and actually I, uh, it was one of, if you had to pick one quote that inspired the whole book and powered, um, It would be this quote by bill Campbell, who was known as the coach of Silicon Valley, which was the job of leadership is to provide an environment.
Where I’m misquoting it right now, but we provide an environment where ordinary people can do extraordinary work. Um, I’m paraphrasing them there, but that’s really what he’s arguing. And, and I found it amazing that he was literally the guy that, um, coached, uh, Larry and Sergei at early Google and Steve jobs that early Apple and Bezos that early Amazon and I, and all of those leaders.
Seem to really live that.
Andrew: And then I guess just in wrapping up here, you know, when you, when you think about it, if you could have the person listening to this right now, if there was a question you would have them start to ask themselves and [00:57:00] reflect on regularly, what would you have them ask themselves?
Marty: I would say to me, you know, we talked earlier about how it bothers both of us, that there’s so much wasted effort in this world. So many bad products, so many wasted effort. If you’re on a product team of any flavor, I would have you ask yourself, are you on a feature team or are you on an empowered product team?
And if you’re not on an empowered product team, what can you do to get there? Because to me, that’s how you tap in to the real potential of your team.
Andrew: Marty. So, first of all, thanks so much for being here. Thank you for your work in the book. Please keep up the great work you’re doing. What would you like to leave the listener with?
Marty: Ah, well, you know, I definitely hope this was useful. I felt like you asked a lot of great topics and not minor topics either and not easy topics. These were hard topics for sure. Some people may have been scared away from the topic of product after our conversation, but. But I think it’s good to know what’s really involved.
And [00:58:00] so whether you’re an engineer designer or product manager, it’s a great thing to do. And, um, uh, you know, I’d encourage people in that direction.
Andrew: Well, Marty, thanks so much for being here and really excited for the new book. Everybody listening, please go get your hands on this book. If you want to go deeper, which I think you probably all want to do.
Marty: Thank you, Andrew.