Real Talk about Empowered vs. Feature Product Teams | Chris Jones (SVPG)

Empowered's a cool word, but it also is. It's a very feel good word. And I think people hear that and they might overhear it as saying, look, I'm empowered, I'm on this team, I'm going to work on what I want to work on. You know, I'm going to use my best judgment, I'm going to try and work this all forward. When in fact, that's really not what we mean by empowered. What we mean is that you are actually allocating problems onto teams. Leadership takes an active role in defining what those problems are. Teams may have something to say about it, but leadership really ultimately is the more accountable because it's how everything actually rolls up and stays coherent. So if you don't have that, that's usually a sign that leadership is abdicating its responsibility. Not really helping guide these teams where they should be going. And then as a result, you got a lot of teams, they might be shipping a lot of stuff, but what they're shipping is not really making much of a difference to anything and it's really quite disconnected from the rest of the teams.

All right, Chris, welcome. Super happy to have you here. Thanks for spending time with us.

Really happy to be here. Thanks for the invitation.

Yeah. So you and Marty just published a new book, Transformed, and there's been a lot of discussion, a lot of PM discourse online. For people who are not familiar. Maybe do you mind just recapping the difference between what a feature team is and what an empower team is?

Yeah, that's something we've actually been talking about for a while, certainly before this book. And it's one of those things that's really easy to say and sort of sounds obvious, but when you start to peel it back, there are sort some really quite profound differences. Fundamentally, it comes down to how work is allocated onto teams. Are you giving teams solutions to build or are you giving them problems to solve? That's the fundamental difference. And then the backside of that is what are you holding the team accountable for? Did they deliver the solution? Did they do it on time, get through all the requirements, or did they solve whatever problem it was that you've given to them? And the reason we use the term empowered is, and if you're doing this right, the team that is given the problem really does have a lot of latitude to figure out what the best solution is. And the idea here is that team is closest to the customer, closest to the technology, ideally should be in the best position to do something like that. And if you imagine you're on an empowered team and you're given a problem to solve. Like, we need to reduce the time it takes to onboard a new customer. Right. We've measured that. It takes us really two or three days before a new customer is getting to the first hit of value from our product. We need to cut that by a fourth. Right. You give a team a task like that immediately, the what that team is sort of incentivized to do is very different. You don't just start building at this point. It's like, all right, we going to have to get some evidence that whatever solution we want to go forward with is actually going to work. Because ultimately we're held accountable for it working. We're not held accountable that we just shipped it and put it into the market. That's basically the fundamental difference between a future team and an empowered team.

Got it. So it's about kind of being given like a business problem and then doing a bunch of customer discovery, figuring out what is even the right thing to build and then building it. And then hopefully not just shipping a product but also moving some metric or achieving some sort of outcome for the business.

Ideally. Yeah. And I mean, I mean there are. It might be a business problem, it might actually be a customer problem that is sort of upstream of some business problem. And then in terms of the metrics, I think, I think a lot of people think pretty narrowly about what that means. A metric might be something like, look, we're going to onboard the first five customers for this new thing that we haven't gotten product market fit yet. I mean that's still a, it's still a metric of sort, but it's pretty wide open and it's much more, much more stated as a, as an outcome. What are we really trying to get to with the thing that we're going to be shipping?

Got it. Let's talk more about metrics a little bit. But I want to talk about kind of my personal experience on how the softness has be made.

Yeah.

Worked at a lot of different companies. My happiest moments as a PM are talking to customers, working with my team, getting to a room, trying to whiteboard out a solution with my team. But there's been so many hours, dude, that I spent just like different companies. I was at one company where there was this like formal agile process, right. Where like you get in a room just like scrum masters and you do point estimations of the work. You spend like two hours doing that. Another company, I had these meetings every quarter where you have these OKR, alignment meetings and like you have a bunch of PMs in your room and they have to like kind of like align all the dependencies for okr. I guess if like no one really enjoys doing this stuff, why do you think this stuff keeps happening?

Really many of the companies that my firm, you know, Silicon Valley Product Group, that when we're helping companies, it's about exactly this, they've fallen into this. And what you're describing gets even worse as companies get bigger. And a lot of old companies have been working like this for a really long time. I'd heard a lot of theories about it and actually many of the big technology leaders have had quotes and things that they've said about this is that companies will start off doing the right thing, being you know, really just rabidly customer focused and the right people doing the right sort of thing. But then when things begin to scale, they feel like in order to hold onto that magic, they need to start putting processes in place. They need to make this, they're trying to encode what they did before in order to make it repeatable or worse, they're trying to take somebody else's process and say, okay, if we do this is actually how we scale. And it gives them just a fundamental sense of control and predictability. In fact though, you know, as I'm sure you found, it really runs the other way. The, you know, the other thing is actually happening. But this can run really deeply. Like it goes all the way back to how projects might get financed. You know, something gets green lighted, money behind it, a team is formed up around it and automatically you're in this state of just looking at process. So some of it has to do with the control and predictability, some of it has to do with stopping trusting the teams that the teams are actually going to do the right sort of thing. That lack of trust may be deserved, it may not. So yeah, there's a, there's all sorts of reasons and it's a hard, a hard thing to get out of. I think the OKR one might actually have its own problem. When I've seen that happen, like when you're just going through all of this OKR lockup and how are we going to get this exactly precise and get these things to align with one another, that's usually a sign that leadership hasn't done a very good job of setting product strategy or setting product vision. When you've got a bit more of a top down idea of where things are ultimately going, it makes it a little easier to get the OKRs rationalized with that, that top level vision or that top level strategy isn't there? Everybody's just kind of in the weeds and mucking around trying to get things to line up in a way that makes sense.

Exactly. And I think like I have this saying that like once you hire like, I don't know, a couple hundred PMs things are just getting kind of crap, crappy at the company.

Yeah.

There's kind of this like inertia to just like add more process and stuff.

Right.

So you almost have to like as a leader, I don't know what kind of coaching you give to your clients, but like you almost have to like periodically like weed out some of this stuff. Like hey, is this, does it still make sense or not?

Right? Yeah, no, that's exactly the case. And I wouldn't say it's really common. I will say it's really common when you do get to that kind of scale that these things really do show up. But I don't think it's inevitable. And that's really one of the ideas behind that book. There are ways to prevent this from happening and it does really rest on the leaders and the leaders keeping focused on what the real thing is, what is the important thing. Yeah, we might need some process here and there to do things, but process is in service of the real problem, you know, the real goal, which is serving our customers. There's a great. Jeff Bezos wrote about in one of his, one of his letters to the shareholders. He was talking about what Amazon does in order to remain a day one company and not fly it into becoming a day two company. And one of the big aspects of this is to really be wary of. He called them proxies. And what he meant is something that's not the thing, something that's standing in place of the thing. The real thing is rapidly serving the customers. The proxy is the process. And when people start to look at process as their job, than it's standing in between this thing that the real thing. And I think good leaders really keep that in mind and they're ensuring that the company is not sliding into that sort of situation.

Exactly. So like along similar lines, do you mind also kind of defining what kind of like a feature factory is? And like in the back of my head I wonder if the problem that a lot of these large companies, is it because they're a feature factory or because they're just like not shipping at all because it takes like six months to ship anything? Yeah.

Do you want to, toil I actually think those are two different problems. I mean, I think if you're really just buried in the type of process that you're talking about, and worse yet, you've got a cadence and a process that says we're going to ship every quarter, or even worse than that. There's just a lot of stuff that makes anything difficult to ship. When you've got a bunch of teams that are operating as feature factories churning out as much stuff as they possibly can, usually the problem isn't shipping. You can get a lot of stuff into the market when that happens. It's just that what you ship doesn't really make any difference. It doesn't move any needle in any appreciable way. And that can come from a couple of different places. One of them is that there really is no coherent strategy that's holding this all together. You've got basically each of the feature teams in this factory are trying to address all of the business leaders who are hitting on them saying, I need you to build this and this. And then this other business leader says, I need you to build this and this. And there's nothing coherent holding the thing together. The other one is this is a little less common. But, you know, we do see cases where there are empowered product team. They genuinely feel empowered and they really do have the ability to work on the solution that they want to, but they go further and they're also given rein to work on whatever problem they want to work on. And in those cases, you get, again, you get a lot of work that's just disconnected from each other. There's no power of the leverage of the resources that you do have towards something that's going to move the needle.

So in the latter example, it's almost like the teams are empowered, but they're kind of heading in different directions because there's no unifying strategy. Is that what you're saying?

Yeah, maybe over empowered might be a way or just sort of overhearing that word empowered. I mean, empowered's a cool word, but it also is. It's a very feel good word. And I think people hear that and they might overhear it as saying, look, I'm empowered, I'm on this team. I'm going to work on what I want to work on. I'm going to use my best judgment and I'm going to try and work all forward. When in fact, that's really not what we mean by empowered. What we mean is that you are actually allocating problems onto team leadership takes an active role in defining what those problems are, the teams may have something to say about it, but leadership really, ultimately is the one accountable, because how everything actually rolls up and stays coherent. So if you don't have that, that's usually a sign that leadership is kind of abdicating responsibility, not really helping guide these teams where they should be going. And then as a result, you got a lot of teams. They might be shipping a lot of stuff, but what they're shipping is not really making much of a difference to anything, and it's really quite disconnected from the rest of the teams.

Yeah, I find that even in, like, a great company, there is, like, a mix of empowered teams. And teams are not empowered. Like, just from personal experience. There are some teams where, like, they either have a bunch of negative customer feedback or they're not meeting their goals. So leadership has to really step in and really help them, you know, get back on track. So you can argue that they're not empowered, but they kind of put themselves in that same situation. Right?

Yeah.

And it's just like two more. There's, like, there's a team, there's teams where customers love the product and, like, the goals seem to be met. So leadership is like, okay, these guys seem to know what they're doing, so let's leave them alone and let them iterate and, like, build great stuff. But I think even in those teams, I personally had this, like, it's easy, just. It's fun to work with the customer, just iterate and build stuff in your product area. But it actually requires more maturity to actually try to reach out to other product team and try to figure out, okay, collectively, how do we ship something great together, because it just takes more time. It's kind of more annoying to do.

Right, right. Right. So that. Yeah, I really. I like how you framed that up because you captured sort of the two extremes there. There's the one where you've got a leader and they have. They've had all the best intentions around getting a theme empowered, and then something goes wrong, and they step in and they put their hands on the wheel and they start steering and saying, we got to do this and we got to do this, we got to do this. Basically, under stress, they revert to that command and control style of management. And that's a leader that probably could use some coaching in how to really actively lead but not necessarily take control. And then the other extreme that you spoke about is the leader that's just basically saying, look, these folks have got it going on. I'm going to Step way away and get out of their way and maybe even be not really that close to what it is that they're actually working on, that's a problem as well. What we need is the leader that really knows when to lean in and how to lean in and when to step back. And a lot of it has to do with asking critical questions, questions at the right time. But also you may actually, as a leader, you may have to steer a team in a direction that's different than they wanted to go or than they think they should go. And that is your responsibility as a leader because you are sitting in the place that has the perspective of all the team or at least a much larger collection of teams. And it is on you as a leader to ensure that there is a coherence to where all this stuff is going.

And if you're just like a PM leading a product team, like how do you move from being micromanaged by a leader to a place where you're in a good spot, where the leader trusts you? Maybe they check in once in a while and you're not surprised. Like some people get surprised. Like their project could all of a sudden get canceled by their leader or something. Like how do you. Yeah, all this stuff.

Yeah, well, this one's a two way street, right? That some of this is on the leader and some of this is on the individual contributor product manager. But one of the biggest pieces of advice to the individual contributor product manager is you've really just, you've got to get to a place as quickly as possible where you are as smart as anybody else and the things that you need to be smart on, and that's specifically your customers or users, whoever it is, whatever your team is responsible for that kind of customer or user. If you're the product manager of that team, it's your responsibility to be the recognized authority on this. And that means that somebody, anybody has a question, you're the person that they're seeking out to answer that question. Usually when somebody's new to a job, there's going to be a lot of people who know a lot more. You know, the CEO is going to know a lot, the VP of Sales is going to know a lot. So it's on you to really get to the place where you deserve a seat at the table. So that's one dimension of just really getting there and that's going to help build that trust with your manager. But there are other things as well. There's of course, there's the data, there's the product Data how well things are working, you should be the recognized expert on that as well. You may have, have some support from a data analyst or a team there, but doesn't mean you can't. You, you, you're off the hook for knowing that stuff, Knowing the business. Right. Knowing who the stakeholders are within the company that are not part of the product organization. Maybe it is the people in sales and marketing, maybe it is the people in finance or maybe you're in a regulated industry and you need to have a relationship to call them compliance people who understand all of this. So as a product manager you really need to be in that as well. So it's a lot. And you can't just, if you're an individual contributor, you can't just demand that people trust you. You have to be worthy of that trust. And being worthy of that trust comes from really having deep knowledge of all of the things that I was just describing.

Yeah, that makes a lot of sense. I talked to some senior leaders and their advice because recently there's been a lot of cutback on managers and people are trying to get promoted to like senior ICs. And someone told me that like if you come already senior ic, you got to be like subject matter expert in your area. You got to be like the go to person in the company.

Right.

So I think that's very good advice.

Exactly. And that's, I like thinking about it that way because it's something you can just, you can introspect. You can ask yourself like if you're a product manager, am I that person? Do people seek me out for my knowledge about the customer? Do they seek me out for my knowledge about the industry and what the competition is doing here? And if not. And you're never going to start there, right? We don't hire people with that knowledge ahead of time. The whole point is that you have to come that domain expert as quickly as possible. But if you're not there on any of those, then find help. And that's part of your manager's job. Your manager is there to provide that access to help you get in front of the customers that you need to help you understand how to access the data to get some shape of what the industry looked like. So yeah, I agree with you.

Another good hack I found is like just to like a lot of companies have a few customers that really matter, right. That kind of drive a lot of revenue or something. And if you can build a good relationship with those customers, the CEO talks to his customers, so the customers start saying good things.

About you.

But you don't have to spend all your time trying to convince the CEO. The customers will tell the CEO like, hey, this PM is interested.

Interesting. Yeah, no, I like that. I mean, obviously, yeah, that's a great, that's a great hack. You align yourself with that core customer advisory board. Yeah. You're going to be speaking with the same voice as, as those people. That's a little fraught too. There, there are definitely some traps you can fall into there, especially if that group of reference customers is not necessarily representative of your broader market. You need to make sure that you're not over indexing on just that group. But I do agree with you. I mean if you've aligned yourself with the parts of the business that the executives in your company are aligned with, that is a really a good way to build trust.

Awesome. So let's kind of go back to talking about outcomes over outputs.

Right.

So I worked at Meta for a couple years and Meta is a great company. Right. The execution is off the charts. But when I worked there, a lot of PMs, they were measured basically based on can they achieve their metric target for the quarter.

Right.

And at least you making like really bad trade offs like, oh, I'm just going to stop importing this product. Let me just put a big banner on the feed to get a bunch of users coming so I can meet my target. So I guess how do you kind of. I think metric is one of those things that's like a proxy, right. It's like very convenient to measure things but it can totally go overboard. So how do you find the right balance here?

Yeah, no, I think you're absolutely right. That is kind of metrics run amok there. It's one of the reasons why I think okrs like okrs by themselves are not going to solve things. But this is one of the sort of promises that's supposed to be there, right. That you've got the measurable quantitative metric, the kr, but there's always the okay, right. The O is the objective stated in prose. This is what we're trying to do and this is why this is important by the way. This KR is just a proxy and we might actually put another proxy in there. And we certainly don't want to craft the krs in a way that people can game it and really just artificially drive the metric. You've lost, you've lost the plot again. So that I agree that's not a good thing. I think that's something that's gotten a, a little out of hand. We also actually advocate my, my firm advocates those types of outcomes, those types of metric being shared by a cross functional team. So it's not just the product manager owns the metric or and then engineering owns these other metrics and things like that. It's that you're trying to create those OKRs in a way that there's a group collaborating against them or trying to figure out what the best thing is there. That's a bit of a different dimension. I suppose you could still find that bad behavior in a team kind of collectively gaming a metric. But in general, in kind of the setup like that's something that I would always look at. If we're just putting those metrics on people based on their functional job as opposed to onto a cross functional team.

Yeah, that's like another pet peeve of mine, man. I heard from somewhere that OPMs are responsible for setting a product direction. Engineering managers responsible for delivering the product and then design is responsible for what? For making the product beautiful or something. I don't know, I just feel like why don't you just sign everybody up for the same product goal that they're trying to achieve?

Like yeah, yeah, that's exactly how we do it and how we talk about it. You have that cross functional team, collectively they're going after that product goal and just saying it. That way you can start to see the benefit of doing something like that that actually compels people to collaborate. Right. There is actually now like a, like an economic incentive for people to be working together because they're all in that same boat, they're all responsible for that same outco. So for example, you're an engineer on a team like this and you kind of see the team know what the outcome is and you see the team barreling towards something and you as the engineer a little suspicious. Like I don't think that's going to work. Like is that really going to move this? Have we done enough discovery, have we done enough experimentation before we go and spin up a bunch of stuff and spend a lot of resources. So let's make sure that we know that right? When you put those OKRs on the team, on the collective team, those types of conversations start to happen. When you don't do that and when you've got each person responsible for their own thing, they're not talking. Right. There's no incentive to talk. So yeah, I agree with you.

Yeah, exactly. And how about like this trend towards teams getting smaller, right? Like before I was a product manager, I was in product Marketing. And it always felt crazy to me that like product manager would hand me over to product and be like, hey Peter, go craft like some messaging for my product. I mean, isn't that your job to craft some messaging? So like, I don't know, this is kind of trend towards collapsing the talent stack towards people wearing more hats again, like at a startup.

Yeah.

How do you feel? I mean, I personally think this is a great trend, but like how do you think people can.

No, I do see, I mean, it's within reason, right? I mean, it's not that everybody's responsible for everything. I mean, we do have some particular things that, that particular roles are going to be more concerned with or less concerned with. But just knowing from the start that we're collectively trying to solve a business problem, that's really one of the things that unlocks. It's a, it's one of the innovation unlocks because you just get the benefit of cross functional people collaborating on a solution together. So yeah, we've advocated an operating model like what you're describing. I've also heard it described, I can't remember where it is. A couple of companies ago, somebody described it as hiring athlete as opposed to hiring specialists. You might want to have somebody who's a specialist in one thing, but it's that T shaped person who really is broadly skilled and can apply a broad set of skills to a much more generalized problem.

That makes a lot of sense.

Yeah.

So, so let's talk about some like specific company examples just to bring some of this stuff to life a little bit more. We can talk about. Let's talk about Airbnb first. Right, so. So like, I think it was like a year ago or something, like Brian Chesky came on and said like he got rid of the PM function or something, but in reality he just added product marketing to the PM function. And I think Marty wrote some sort of response to some of his management styles. But anyway, like imagine you're like Brian trying to keep Airbnb alive after Covid, or drop the revenue by like 80% or something. Like, how do you like, is that the right environment to empower your PMs? Or like, what's the right way to kind of empower them to actually keep your company alive.

Yeah, well, so I kind of heard there's sort of two topics in there. The first one is what Brian Chesky said about product management. And honestly, like there's sort of the actual job titles and then there's the roles and things that are going on and we've always described product management within the context of these teams. They're responsible primarily for customer value and business viability. So whatever solutions that team is producing, the team is collectively trying to find a solution that works. But the product manager is really going to be advocating ensuring that there is genuine value that's being transmitted to whoever the customer or user is. And whatever we're doing is going to work for all of the relevant aspects of our business, whether it be go to market or compliant or whatever, internal brand, existing partnerships, all of that kind of stuff that is really the domain of the product manager. And if you are erasing that role within the company, if you're taking that out as a job title, somebody still has to be responsible for the things that I just said. Right. Their value and viability are still issues there. So it may shift to somebody else. Whether it's shifting to a product marketing person, whether it's shifting, maybe the designer is picking up some of that stuff. So the fundamentals don't change, it's just how you're doling out responsibility for those risks across the people within the team. That was essentially kind of how we framed what he was saying there. Now, as far as the other part of your question dealing with this potential threat of the pandemic, quite honestly, the operating model that we talk about in the book that you mentioned at the beginning, the thing that involves these teams, the thing that involves product strategy, that's precisely the thing that allowed many other companies survive this exact event that you're talking about. We in fact we profile a couple of companies in that book on how the fact that they had moved to this sort of model allowed them to innovate their way through and deal with something that fundamentally changed their customer experience and in some cases even their business model. So what it comes from though is you're, it's that it's what we were talking about a little bit before. We don't over delegate and over autonomize really our, our various teams and just hope that one of them is going to figure something out or a couple of them are going to figure something out. There still is a considerable amount of leadership and top down energy put onto those teams to get them moving in the right direction or the same direction. And it comes in the form of a product vision and it comes in the form of a product strategy that is this broader strategic context within which teams are going to innovate. And yeah, as I said, we've got some examples of just that. We don't profile Airbnb but we profile some companies that have some similar dynamic and faced some similar threats when the pandemic came down.

Can you talk about this model in a little bit more detail or what are the key components of this?

Yeah, so as a product operating model, we've been talking about this for a long time. The term product operating model is something that the industry seems to be coalescing around in the last couple of years or so. So we've really adopted that. And it's not the kind of process and stuff that we were talking about before. And it's not even really a framework, it really just a way to think about a set of principles. If you look at the companies that are operating this way, they'll use different words, but if you interview people within these companies, they'll kind of say similar things in terms of the processes that they use. They might have or, sorry, in terms of the principles that they follow. They may go about putting them together in very different ways internally. How Apple does product is really different from how Airbnb does products is really different from how Amazon does product. But these fundamental concepts are there and it really divides into kind of three broad categories. How do you build, how do you solve problems? And how do you decide which problems to solve? And what I'm talking about is like, this is company wide, right? So how you build. Most people, if you understand anything about this stuff, that's usually the place that you start. This is getting into shipping a lot more frequently coupled releases, cicd, a lot of monitoring and instrumentation and those sorts of things. Your deployment architecture. Right. So the stuff that most people think about, like when they might do an agile transformation, the next category that, that one is how you go about solving problems. And that's where you and I started this conversation on empowered teams versus feature teams. Are we giving teams problems or are we giving them solutions that they need to go and ship? And all the various behaviors that come downstream from that. What does product discovery look like, what do teams look like, how do you staff them? All of that. So that's kind of the second area. And then the third area is really more about the product strategy. Like, okay, we got any number of problems to be working on. How do we really provide the right sort of focus and insight on that so that we're going to actually move forward in a really cohesive way. So, and there's work usually that needs to be done at all three of those levels, all three of those dimensions. If you're taking a company and moving it to get more consistent with this type of operating model.

Yeah, it kind of reminds me of the understand, identify, execute process that like Facebook, these other companies follow. I think going back to the Airbnb, I think it's a fact that like Brian himself is not going to be able to do all the customer discovery for all the nitty gritty details of each part of the strategy that like a bunch of PMs or designers or whoever can do.

Right.

Like to me, to me at least, like the customer discovery part of things is like one of the most important pieces that a PM does. What is it supposed to do? So I think that's a really strong argument. Like Brian can tell a PM to make the fees more transparent or something on the website, but like the PM will have to go and talk to customers and figure out exactly how to do that.

Yeah, yeah. You know, I think all of this still works. I mean, there's sort of what's going on at the team level and what you're just describing is very much what's going on in the team level and then there's what's going on at the leadership and management level so that the teams are kind of doing the right thing. So. And what you were describing there, Brian would be living much more in the realm of product strategy. These are the areas we need to focus and it really, as we start, obviously not going to be him by himself, but this is how we want to start to decompose this in a way so that as we set these teams off against various objectives, we're going to be able to achieve this product strategy, meanwhile advancing us toward a longer term vision. And so yeah, that's, that's a lot of what we've been talking about actually through the years, kind of what happens at the level of the team, what happens at the level of leadership.

Got it. What about, let's, let's take another example. What about like Google, Right, Google five years ago or even now, you can argue it's a company that a lot of PMs want to work for, a lot of people want to work for. But as you can, as you've seen, they've seen some challenges to shift towards AI. And people who have been there complain about how there's too many layers now, there's too many little fiefdoms. It's kind of like a country of a bunch of states that want to go in their own direction and then it's kind of hard to. Yeah, so, so I guess maybe let's start at the, the executive level. Like what do you think Google needs to do to fix this and kind of move fast, faster?

Yeah, this is a tricky one. I, I can't really speak to any firsthand knowledge of exactly what's going on at Google with regard to AI, and it changes so quickly. I mean, they just recently had had an event where they, you know, rolled out a lot of their plans and their strategy on the infrast, the cloud and how that all plays with AI and quite frankly, it looks pretty together and they've been really working on this for a long time. Some of the criticisms that I've heard, especially when ChatGPT was rolling out and Gemini and all of these sorts of things, was had to do with a little bit more of an abundance of caution within the team and what it meant to unleash a lot of AI in a way that's responsible and accurate and ethical and all of that stuff. And they made some missteps there. But that fundamentally there, there has been a lot of advancing here. Again though, I'm not really speaking from a place of direct knowledge, so I'm just kind of piecing this together from the outside. I would not short Google on this. I really think they're going to come out as one of the. They already are, but I think they, there's a really good chance they are. They're going to come out in a very good place on this whole thing. But in general, I do think your question really still makes a lot of sense because many companies do find themselves in a deficit like what you've described. You've got a lot of fiefdoms, you've got a lot of groups that are pursuing things that are independent. There's nothing that coherently putting them together. A lot of it is grown up around the org chart and where leaders have been put and, you know, they have their kingdoms and they're running their own little businesses. But there's not then sufficient emphasis placed on product strategy. That's that third dimension. I said deciding what problems we're going to work on. How do you get that stuff actually coordinated? And in some cases it's an issue with how the companies are organized. Right. It's sort of structurally built in and in some cases it just depends on the leaders themselves. You don't have enough incentive to collaborate with one another. They're not being given objectives at that high business level that actually encourages these things to be dealt with in a much more holistic way. So. But yeah, as far as Google, hard to say. And I'm sure your listeners and readers all have an abundance of opinions here.

Yeah, no, I think you bring up some really good points. I mean, I think most of the readers and listeners here are going to be more people in the product team as opposed to like some VP or something.

Right? So, yeah, yeah.

Maybe let's take it from that perspective then, like going back to what we've talked about before. Engineers, designers, PMs, product team, they just want to deliver good products, they want to grow their career and they don't want to get stuck. The thing about product strategy is, especially at large companies, you could easily get stuck in product review hell. You're just making decks all day and going through reviews of directors. VPs just keep getting stuck doing all this stuff and then you don't have time to actually execute or talk to the customer. So how do you, I guess at the end of the day, if you can give some advice for these product team folks to find themselves in a good spot to actually kind of be.

Able to enjoy their job, like, yeah, well, so I'll take one more run at the strategy side of things. We don't advocate that. The phenomenon that you just talked about, we don't really necessarily equate strategy with lots and lots of decks and lots of consensus and lockup and process and things like that. I mean, it's really quite simple for us. It's much more about choosing a relatively limited set of things that you're going to focus on. And, and that, by the way, can be a, just by itself, a very profound step. And this is one of the things where Steve Jobs has a great quote and he says is most people think that focus is about saying yes to the things that you're going to focus on. That's not what it means at all. What focus means saying no to the potentially hundreds of other really great ideas that are out there that your company could be pursuing. So taking a stand at the leadership level on the areas of focus that teams can be pursu and being pretty ruthless about not letting things get too far outside of that area of focus, that's one of the things that we're really looking for there. So as far as an individual engineer, I think if you're trying to find a place to work, whether it's a company or an individual product manager for that matter, you're trying to find a company or a place within the company, but just looking for the areas that run the way that we're talking about the type of empowerment that I've been talking about. The, the teams are Fundamentally, given problems, they may have some insight on what those problems are, but their job is to find the best solution to those problem. That can be an incredibly rewarding level of empowerment. Right. And it's one that not for the least of which is it usually is the sort of way that lead to a lot better success in terms of products. So if you, on the other hand, are finding yourself in a place that's buried in process, or if you've got a manager who just doesn't really get how this stuff works and really wants to go into command and control, it's going to be. It's going to be hard to fully change that from the bottoms up. You may be able to begin to chip away at it. One of the pieces of advice I give, especially for product managers is any time your team is given something to build, given a feature to build, or given a roadmap to execute on, try and bring into the conversation the topic of the outcome. Like, okay, great, you want us to ship this feature. What does success look like? And success is not, you ship the feature on time. Success is that we are going to get at least 20% of our existing customers to adopt to try this out within the first month. And of those ones who try it out, 90% of them are going to keep going with it. Right. We've got maybe an adoption and a retention metric that we're going to go for, and that's a place to start. So it's like, okay, I'm going to build this thing you're asking me to build, but I know what success looks like. And even that is going to create some level of empowerment. When you take it to the further level, you're not even getting the solution, you're only getting the outcome and the team is able to really figure out what that solution would be.

Yeah. And I think sometimes success is actually like if you have the maturity. And I made this mistake in the past where I was very focused on the success of my product, but I wasn't thinking about, hey, if like a million users adopt this product, is this actually good for the company or not? Like, is this the most important thing the company should be working on right now?

Right.

And sometimes you need to have that maturity to be like, actually, you know what the thing you're giving me, the product or the problem you're giving me is actually, I don't think it's the most important thing to do right now.

Yeah, well, that's a good conversation to have then with your leader and a good leader, a Good manager is going to have that conversation with you and they should be able to articulate to you why they believe it's important. You can articulate why you believe it's a problem. And you may not actually get to consensus, you may not actually end up agreeing with one another, but at least you're understanding the logic behind it. It's not a because I said so sort of thing there. You may at first blush not believe that this is good for the company, but after the conversation with the manager, you may come around and say, all right, I see that logic. I might not be fully convinced, but there is something there. Yeah.

And just to follow on the previous thread, like, what happens if you are a product manager or someone kind of currently stuck in that product review health stage, right? Where like, Maybe it's the CEO's pet project or like maybe they don't trust you? How do you systematically rebuild that trust? Like, is just over communicating or I mean, moving away.

You're talking about how do you begin to move away from a really process oriented team to one that's a bit more empowered?

Let's assume that there's other teams at a company that are actually empowered. So it's not just like toxic companies.

It'S just yours that's been disempowered or something. Okay, yeah, well, yeah, that means trust has broken down for some reason. Right. That leadership doesn't trust your team to do it. And I think in the immediate term, doing as much as you can to have outcomes be part of the conversation. So it's not like, okay, stop giving me solutions and only give me problems. You're not going to do that. But what you can do is say, all right, I do need to understand really at the business level, when is this thing going to be successful? What is going to be successful about this? So that's one of the things to do, is just shifting that conversation. And then the other one is kind of back to what I said. If you sort of lost the trust, it might be because you as a product manager aren't the expert on the customer, you aren't the expert on the data, you aren't the expert on. You don't really know deeply what's going on in the business. So kind of going back to those fundamentals that I talked about and getting yourself to that level, I think is another way to rebuild trust.

And also maybe just having the honesty. Like because sometimes when you launch something and people hate it or like the metrics aren't quite there, people would like to Hide this information from leaders, and it usually doesn't work out. So just having to honestly just like, share that stuff openly and tell what.

You'Re doing to improve. Well, yeah. So, I mean, there's a lot of things that can lead to that particular situation. The first thing I would probably question as a leader, if somebody presented me that was, why did we not do more to understand that this could have been a risk? Was there more product discovery that could have been done to highlight this? Why were we surprised by this? And there may be a very good reason. There may absolutely be a very good reason. But then the next question is, okay, so why do we think, based on everything we've done both in product discovery and product delivery, why do we think this is not delivering the numbers that we were hoping and a true failure would be? There's no insight in there. Well, we just don't know. We took our best shot and it was crapshoot. It could have gone either way and it went badly. Like, that's a bad answer. Right, because you can't do anything with that. But if there's an. An insight in there as to why this thing didn't work, well, we celebrate that and we make sure that we bank that insight and we, you know, are taking advantage of it for the next thing that we do. But it is a bummer when you get all the way to building something and then you're surprised by how it's adopted or how it's retained. Usually, as I said, that's usually a failure of product recovery, which I think.

Is like the most important part of product management. I mean, I'm biased, but.

Yeah, you and me both. You and me both.

So, last question, Chris. We talked about how to feel empowering a company, but how do you feel empowering your career?

Right.

Like, I think tech goes through cycles. I mean, you've been around the block and so have I. Like, every couple years there's like big layoffs or down, downturn. You could be doing a great job and you can just get totally laid off and then your livelihood is gone. So how do you build a career where you have more control and feel.

More inoculated on that? Yeah, I mean, this is probably going to sound obvious, but always have to keep your network up. And it's not just for these downtimes, something that you can lean on, but your network's going to help you. It's going to provide advice. It's going to, you know, provide mentoring and coaching in some cases. So just if you're not inclined to do that. And there's a period in my mic I'm fundamentally kind of introverted and there are periods where it's like, yeah, I'm not really doing that great of networking. I would just give myself a little MBO or a little OKR on it and like, okay, this week I'm going to make sure that I reach out to at least three people from my historical network. And whether it's just an email or maybe trying to sell a lunch, check in on how they're doing. Not necessarily any big agenda, but just kind of keeping that network alive. And that's the single best thing you can have when there is a downturn, that you're top of mind for people or other people are top of mind for you. And yeah, it just gives you a sense of empowerment that's not entirely rooted within the company that you're working at.

Yeah, that's really good advice. I mean, that's why I do these interviews. Like, we had a great 50 minute conversation. I got to know you a little bit.

I'm glad to have you in my network now for exactly this reason. Yeah, dude, when I.

When I hear the words empowered or like feature factory or some of these words, like, I feel like after I had this conversation with you, I understand all the nuances a lot better now. And like, you kind of explained it very well. And just hearing the words empowered can trigger some people. So. So I'm really glad that we had this conversation and kind of like sharing the actual real how the sausage actually gets made.

Great. Thanks, Peter. Great to meet you. I really appreciate the opportunity.

All right, man. Yeah, we'll definitely stay in touch. We'll end the interview here. Yeah, thanks, Chris.

Cheer when you don't do that and when you've got each person responsible for their own thing, they're not talking. Right. There's no incentive to talk. So. Yeah, I agree with you.

Yeah, exactly. And how about like this trend towards teams getting smaller? Right? Like, before I was a product manager, I was in product marketing and it always felt crazy to me that like, product manager will hand me over the product and be like, hey, Peter, go craft like some messaging for my product. I mean, isn't that your job, to craft some messaging? So, like, I don't know, this is kind of trend towards collapsing the talent stack towards people wearing more hats again, like at a startup.

Yeah.

How do you feel? I mean, I personally think this is a great trend, but, like, how do you think people can.

No, I do too. I mean, it's within reason. Right. I mean, it's not that everybody's responsible for everything. I mean, we do have some particular things that particular roles are going to be more concerned with or less concerned with. But just knowing from the start that we're collectively trying to solve a business problem, that's really one of the things that unlocks. It's a, it's one of the innovation unlocks because you just get the benefit of cross functional people collaborating on a solution together. So yeah, we've advocated an operating model like what you're describing. I've also heard it described, I can't remember where it is. A couple of companies ago, somebody described it as hiring athletes as opposed to hiring specialists. You might want to have somebody who's the specialist in one thing, but it's that T shaped person who really is broadly skilled and can apply a broad set of skills to a much more generalized problem.

That makes a lot of sense. Yeah, so, so let's talk about some like specific company examples just to bring some of this stuff to life a little bit more. We can talk about. Let's talk about Airbnb first. Right, so. So like I think it was like a year ago or something, like Brian Chesky came on and said like he got rid of the PM function or something, but in reality he just added product marketing to the PM function. And I think Marty wrote some sort of response to some of his management styles. But anyway, like imagine you're like Brian trying to keep Airbnb alive after Covid dropped the revenue by like 80% or something. Like, how do you like, is that the right environment to empower your PMs or like, what's the right way to kind of empower them to actually keep your company alive?

Yeah, well, so I kind of heard there's sort of two, two topics in there. The first one is what Brian Chesky said about product management. And honestly, like there's sort of the actual job titles and then there's the roles and things that are going on. And we've always described product management within the context of these teams. They're responsible primarily for customer value and business viability. So whatever solutions that team is producing, the team is collectively trying to find a solution that works. But the product manager is really going to be advocating ensuring that there is genuine value that's being transmitted to whoever the customer or user is. And whatever we're doing is going to work for all of the relevant aspects of our business, whether it be go to market or compliant or whatever, internal brand, existing partnerships, all of that kind of stuff that is really the domain of the product manager. And if you are erasing that role within the company, if you're taking that out as a job title, somebody still has to be responsible for the things that I just said. Right. Their value and viability are still issues there. So it may shift to somebody else, whether it's shifting to a product marketing person, whether it's shifting, maybe the designer is picking up some of that stuff. So the fundamentals don't change. It's just how you're doling out responsibility for those risks across the people within the team. That was essentially kind of how we framed what he was saying there. Now, as far as the other part of your question dealing with this potential threat of the pandemic, quite honestly, the operating model that we talk about in the book that you mentioned at the beginning, thing that involves these teams, the thing that involves product strategy, that's precisely the thing that allowed many other companies survive this exact event that you're talking about. We, in fact, we profile a couple of companies in that book on how the fact that they had moved to the.