Transcription
**Empower** is a cool word, but it’s also a very feel-good word. 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 team leadership. 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 determinable 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. As a result, you have a lot of teams that 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.
**Chris:** Really happy to be here. Thanks for the invitation.
Yeah, so you 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 empowered team is?
**Chris:** Yeah, that's something we've actually been talking about for a while, certainly before this book. 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 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.
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?
The reason we use the term empowered is that 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. The idea here is that the team is closest to the customer, closest to the technology, and ideally should be in the best position to do something like that.
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." 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.
You give a team a task like that, and immediately what that team is incentivized to do is very different. You don't just start building at this point. You have to get some evidence that whatever solution you want to go forward with is actually going to work because ultimately, you're held accountable for it working. You're not held accountable for just shipping it and putting it into the market.
That's basically the fundamental difference between a feature team and an empowered team.
---
Got it. So it's about being given a business problem and then doing a bunch of customer discovery to figure out what is even the right thing to build, and then building it. Hopefully, not just shipping a product but also moving some metric or achieving some sort of outcome for the business.
**Chris:** Yeah, and I mean, there might be a business problem, or it might actually be a customer problem that is sort of upstream of some business problem. In terms of the metrics, 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 metric of sorts, but it's pretty wide open, and it's much more stated as an outcome. What are we really trying to get to with the thing we're going to be shipping?
---
Got it. Well, let's talk more about metrics in a little bit, but I want to talk about my personal experience on how the sausage has been made. I've worked at a lot of different companies. My happiest moments as a PM are talking to customers, working with my team, getting into a room, trying to whiteboard out solutions with my team.
But yeah, there have been so many hours I spent at different companies. I was at one company where there was this formal agile process, right? You get in a room with Scrum Masters, and you do point estimations of the work. You spend like two hours doing that.
At another company, I had these meetings every quarter where you have these OKR alignment meetings, and you have a bunch of PMs in your room, and they have to align all the dependencies.
I guess if no one really enjoys doing this stuff, why do you think this keeps happening?
**Chris:** Really, many of the companies that my firm, Silicon Valley Product Group, helps, have fallen into this. What you're describing gets even worse as companies get bigger. A lot of old companies have been working like this for a really long time.
I've 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. Companies will start off doing the right thing, being really just rapidly customer-focused, with the right people doing the right sort of thing. But then when things begin to scale, they feel like in order to hold on to that magic, they need to start putting processes in place.
They need to make this repeatable. Or worse, they're trying to take somebody else's process and say, "Okay, if we do this, this is actually how we scale." It gives them just a fundamental sense of control and predictability.
In fact, though, as I'm sure you found, it really runs the other way. The other thing is actually happening. This can run really deeply; it goes all the way back to how projects might get financed. Sometimes it's greenlit money behind it, a team is formed up around it, and automatically you're in this state of just looking at process.
Some of it has to do with control and predictability, and 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 are all sorts of reasons, and it's 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 trying to get everything to align, that's usually a sign that leadership hasn't done a very good job of setting product strategy or setting product vision.
When you have 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 top-level vision or that top-level strategy. If that 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. I think I have this saying that once you hire a couple hundred PMs, things are just getting kind of crappy at the company. There's this inertia to just add more process and stuff, right?
So you almost have to, as a leader, periodically weed out some of the stuff. Like, "Hey, does this still make sense or not?"
**Chris:** Yeah, no, that's exactly the case. I wouldn't say it's really common, but I will say it's really common when you 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 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 or the real goal, which is serving our customers.
There's a great quote from Jeff Bezos in one of his letters to shareholders. He was talking about what Amazon does in order to remain a "Day 1" company and not fly into becoming a "Day 2" company. One of the big aspects of this is to really be wary of what he called "proxies."
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. When people start to look at process as their job, then it's standing in between the real thing.
I think good leaders really keep that in mind, ensuring that the company is not sliding into that sort of situation.
---
Exactly. Along similar lines, do you mind also defining what kind of a feature factory is? In the back of my head, I wonder if the problem that a lot of these large companies face is because they're a feature factory or because they're not shipping at all, since it takes like six months to ship anything.
**Chris:** Yeah, 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're shipping doesn't really make any difference. It doesn't move any needle in any appreciable way.
That can come from a couple of different places. One of them is that there really is no coherent strategy that's holding it all together. You've got basically each of the feature teams in this factory 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." There's nothing coherent holding the thing together.
The other one is a little less common, but we do see cases where there are empowered product teams. 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 given reign to work on whatever problem they want to work on.
In those cases, 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?
**Chris:** Yeah, maybe "over-empowered" might be a way to put it. Or just sort of overhearing that word "empowered." I mean, empowered is a cool word, but it also is a very feel-good word. 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. 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 its responsibility, not really helping guide these teams where they should be going.
As a result, you have a lot of teams that 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.
---
I find that even in a great company, there is a mix of empowered teams and teams that are not empowered. Just from personal experience, there are some teams where they either have a bunch of negative customer feedback, and their goals are not being met, so leadership has to really step in and help them get back on track.
You could argue that they're not empowered, but they kind of put themselves in that situation, right?
And then just like two more points: there are teams where customers love the product, and 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 build great stuff."
But I think even in those teams, I personally had this experience where it's easy to just work with a customer, iterate, and build stuff in your product area. But it actually requires more maturity to reach out to other product teams and 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.
**Chris:** Right, right. I really 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've had all the best intentions around getting a team empowered, and then something goes wrong. They step in, put their hands on the wheel, and start steering, saying, "We got to do this, and we got to do this."
Basically, under stress, they revert to that command-and-control style of management. That's a leader that probably could use some coaching in how to really actively lead but not necessarily take control.
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 not really be 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. A lot of it has to do with asking critical questions at the right time.
But also, as a leader, you may have to steer a team in a direction that's different than they wanted to go, than they think they should go. That is your responsibility as a leader because you are sitting in the place that has the perspective of all the teams, or at least a much larger collection of teams.
It is on you as a leader to ensure that there is coherence to where all this stuff is going.
---
If you're just a PM leading a product team, 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. Some people get surprised when their project could all of a sudden get canceled by their leader or something. How do you navigate all this stuff?
**Chris:** Well, this one's a two-way street, right? Some of this is on the leader, and some of this is on the individual contributor product manager.
One of the biggest pieces of advice to the individual contributor product manager is you've really just got to get to a place as quickly as possible where you are as smart as anybody else in the things that you need to be smart on. That's specifically your customers or users—whoever it is, whatever your team is responsible for.
If you're the product manager for that team, it's your responsibility to be the recognized authority on this. That means that if somebody 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. 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.
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. 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 some support from a data analyst or a team there, but that doesn't mean you're off the hook for knowing that stuff. Knowing the business, 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 with the compliance people who understand all of this.
So as a product manager, you really need to be in that suit as well. It's a lot, and you can't just, if you're an individual contributor, 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've just described.
---
Yeah, that makes a lot of sense. I talked to some senior leaders, and their advice—because recently there's been a lot of cutbacks on managers, and people are trying to get promoted into senior IC roles—someone told me that it's become really important to be the subject matter expert in your area. You gotta be like the go-to person in the company, right? So I think that's very good advice.
**Chris:** Exactly. I like thinking about it that way because it's something you can introspect. You can ask yourself, like, if you're a 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?"
If not, 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 become that domain expert as quickly as possible. But if you're not there on any of those, then find help.
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 looks like. So yeah, I agree with you.
---
Another good hack I found is that a lot of companies have a few customers that already matter, right? They kind of drive a lot of revenue or something. If you can build a good relationship with those customers, the CEO talks to those customers. So if the customers are saying good things about you, you don't have to spend all your time trying to convince the CEO. The customers will tell the CEO, "Hey, this PM is doing a great job."
**Chris:** Yeah, I mean, that's a great hack. If you align yourself with that core customer advisory board, you're going to be speaking with the same voice as those people. That's a little fraught too; 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 good way to build trust.
---
Awesome. So let's kind of go back to talking about outcomes over outputs. I worked at Meta for a couple of years, and Meta is a great company, right? The execution is off the charts. But when I worked there, a lot of PMs were measured basically based on whether they could achieve their metric target for the quarter.
It leads to making really bad trade-offs, like, "Oh, I'm just going to stop this product. Let me just put a big banner on the feed to get a bunch of users to come in so I can meet my target."
So I guess, how do you find the right balance here? I think Meta is one of those things that's like a pro, right? It's very convenient to measure things, but it can totally go overboard.
**Chris:** Yeah, no, I think you're absolutely right. Metrics can run amok. That'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 promises that's supposed to be there, right? You've got the measurable quantitative metric, the KR, but there's always the O, 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. 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 the plot again, so I agree that's not a good thing.
I think that's something that's gotten a little out of hand. We also actually advocate—my firm advocates those types of outcomes, those types of metrics being shared by a cross-functional team. So it's not just the product manager owns the metric, 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, 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 on that 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. I heard from somewhere that PMs are responsible for setting the product direction, engineering managers are responsible for delivering the product, and then designers are responsible for making the product beautiful or something.
I don't know; I just feel like one sign is to get everybody signed up for the same product goal that they're trying to achieve.
**Chris:** Yeah, that's exactly how we do it and how we talk about it. You have that cross-functional team collectively going after that product goal. 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 an economic incentive for people to be working together because they're all in that same boat. They're all responsible for that same outcome.
So for example, you're an engineer on a team like this, and you kind of see the team barreling towards something. You, as the engineer, are a little suspicious, like, "I don't think that's going to work. 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 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.
---
Exactly. And how about this trend towards teams getting smaller? Before I was a product manager, I was in product marketing, and it always felt crazy to me that a product manager would hand me over to product and be like, "Hey, Peter, go craft some messaging for my product." I mean, isn't that your job to craft some messaging?
I don't know; there's this kind of trend towards collapsing the T-stack, towards people wearing more hats, again like at a startup. How do you... I mean, I personally think this is a great trend, but how do you think people can navigate that?
**Chris:** No, I do. I mean, it's within reason, right? It's not that everybody's responsible for everything. 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 innovation. 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—this was a couple of companies ago—somebody described it as hiring athletes 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 much more generalized problems.
---
Yeah, that makes a lot of sense. So let's talk about some specific company examples just to bring some of this stuff to life a little bit more. We can talk about Airbnb first. So I think it was like a year ago or something, Brian Chesky came out and said he got rid of the PM function or something.
But in reality, he just added PR and marketing to the PM function. I think Marty wrote some sort of response to some of his management styles. But anyway, imagine you're Brian trying to keep Airbnb alive after COVID dropped the revenue by like 80% or something. How do you... is that the right environment to empower your PMs? What's the right way to empower them to actually keep your company alive?
**Chris:** 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. Honestly, there are sort of the actual job titles and then there's the roles and things that are going on.
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 being transmitted to whoever the customer 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, compliance, or whatever internal brand existing partnerships, that kind of stuff.
That is really the domain of the product manager. 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 or maybe the designer is picking up some of that stuff. The fundamentals don't change; it's just how you're doing out responsibility for those risks across the people within the team.
Now, as far as the other part of your question—dealing with this existential 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 to survive this exact event that you're talking about.
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.
What it comes from, though, is that it's what we were talking about a little bit before. We don't over-delegate and over-automate. We 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.
It comes in the form of a product vision and a product strategy that is this broader strategic context within which teams are going to innovate.
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 dynamics and faced some similar threats when the pandemic came down.
---
Can you talk about this model in a little bit more detail? What are the key components of this?
**Chris:** Yeah, so 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.
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 is 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 product. It's really different from how Amazon does product.
But the 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?
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, CI/CD, a lot of monitoring and instrumentation, and those sorts of things—your deployment architecture, right?
So the stuff that most people think about when they might do an agile transformation. The next category, that one, is how you go about solving problems. 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?
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.
Then the third area is really more about the product strategy. Like, okay, we've 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?
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 Facebook and these other companies follow. I think going back to Airbnb, I think it's a fact that Brian himself is not going to be able to do all the customer discovery for every detail of each part of the strategy.
A bunch of PMs or designers or whoever can do that, right? To me, at least, the customer discovery part of things is one of the most important pieces that a PM does or is supposed to do. So I think that's a really strong argument.
Brian can tell a PM to make the fees more transparent or something on the website, but the PM will have to go and talk to customers and figure out exactly how to do that.
**Chris:** Yeah, 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 at the team level. Then there's what's going on at the leadership and management level, so that the teams are kind of doing the right thing.
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 on, and it really, as we start, obviously, is 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 while advancing us toward a longer-term vision.
So yeah, 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 and what happens at the level of leadership.
---
Got it. What about Google? Five years ago, or even now, you can argue it's the company that a lot of PMs want to work for. A lot of people want to work for it, but as you've seen, they've faced some challenges in shifting towards AI.
People who have been there are complaining about how there are too many layers now, 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...
So I guess maybe let's start at the executive level. What do you think Google needs to do to fix this and kind of move faster?
**Chris:** This is a tricky one. 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 an event where they rolled out a lot of their plans and their strategy on the infrastructure and the cloud and how that all plays with AI.
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, 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 is responsible, accurate, ethical, and all of that stuff.
They made some missteps there, but fundamentally, 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 there's a really good chance 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, and there's nothing that coherently puts them together.
A lot of it has grown up around the org chart and where leaders have been put. They have their kingdoms and are running their own little businesses, but there's not been 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?
In some cases, it's an issue with how the companies are organized, right? If it's sort of structurally built in, and in some cases, it just depends on the leaders themselves. They don't have enough incentive to collaborate with one another. They're not being given objectives at that high business level that actually encourage these things to be dealt with in a much more holistic way.
So, yeah, as far as Google, it's hard to say, and I'm sure your listeners and readers all have an abundance of opinions here.
---
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, maybe let's take it from that perspective then. Going back to what we talked about before, engineers, designers, PMs, product teams want to deliver a good product. They want to grow their careers, and they don't want to get stuck.
The thing about product strategy is, especially in large companies, it could easily get stuck in product review hell—just like making decks all day, right? Going through reviews of directors and VPs, it just keeps getting stuck doing all this stuff, and 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 be able to enjoy their job?
**Chris:** 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 by the way, that can be, just by itself, a very profound step.
This is one of the things where Steve Jobs has a great quote. He says, "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 is 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 pursuing 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 that's looking for the areas that run the way that we're talking about—the type of empowerment that I've been talking about.
The teams are fundamentally given problems. They may have some insight into what those problems are, but their job is to find the best solution to those problems. That can be an incredibly rewarding level of empowerment, and it's one that, not for the least of which, usually leads to a lot better success in terms of products.
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 hard to fully change that from the bottom 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 anytime 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?" Success is not just shipping the feature on time. Success is that we're going to get at least 20% of our existing customers to adopt this within the first month, and of those who try it out, 90% of them are going to keep going with it.
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."
Even that is going to create some level of empowerment when you take it to the first 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, I think sometimes success is actually—if you have the maturity, and I made this mistake in the past—where I was very focused on success on my product, but I wasn't thinking about, "Hey, if a million users adopt this product, is it actually good for the company or not? Is this the most important thing the company should be working on right now?"
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 not the most important thing to do right now."
**Chris:** Well, that's a good conversation to have then with your leader. 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.
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."
---
And just to follow on the previous thread, what happens if you're a product manager or someone currently stuck in that product review hell stage? What if it's the CEO's pet project, or maybe they don't trust you? How do you systematically rebuild that trust? Is it just over-communicating or moving away?
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 are other teams at a company that are actually empowered, so it's not just a toxic company; it's just yours that's been disempowered or something.
**Chris:** Okay, yeah. Well, yeah, that means trust has broken down for some reason, right? That leadership doesn't trust your team to do it. I think in the immediate term, doing as much as you can to have outcomes be part of the conversation is key.
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—shifting that conversation. Then the other one is kind of back to what I said. If you've 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 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. Also, maybe just having the honesty—because sometimes when you launch something and people hate it or 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 share that stuff openly and tell publicly what you're doing to improve.
**Chris:** 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?"
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?"
A true failure would be, "There's no insight in there. We just don't know. We took our best shot, and it was a crapshoot. It could have gone either way, and it went badly." That's a bad answer, right? Because you can't do anything with that.
But if there's 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 take 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 discovery, which I think is like the most important part of product management. I mean, I'm biased, but...
---
You and me both!
---
So last question, Chris. We talk about how to feel empowered in a company, but how do you feel empowered in your career? I think tech goes through cycles. I mean, you've been around the block, and so have I. Every couple of years, there's big layoffs or downturns. You could be doing a great job, and you 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 empowered on that?
**Chris:** I mean, this is probably going to sound obvious, but always keep your network up. 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 provide mentoring and coaching in some cases.
So just if you're not inclined to do that—and there's a period in my life where 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, like, "Okay, this week I'm going to make sure that I reach out to at least three people from my historical network."
Whether it's just an email or maybe trying to set a lunch, a check-in on how they're doing—not necessarily any big agenda, but just kind of keeping that network alive. 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.
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. We just had a 50-minute conversation. I got to know you. I'm glad to have you in my network now for exactly this reason.
**Chris:** Yeah, dude! When I hear the words "empowered" or "feature factory" or some of these words, I feel like after I had this conversation with you, I understand all the nuances a lot better now. You kind of explained it very well.
Just hearing the words "empowered" can trigger some people, so I'm really glad that we had this conversation—kind of sharing the actual real how the sausage actually gets made.
**Chris:** Great! Thanks, Peter. Great to meet you. I really appreciate the opportunity.
---
All right, man. Yeah, we'll definitely touch base. I'll end the interview here.
**Chris:** Yeah, thanks! Cheers!