Transcription
**Empowerment is not a free-for-all.** That's the most beautiful answer for this question. Ever wondered how the best product companies build their products and operate today? I'm thrilled to have Chris Jones with us. With over 30 years of experience, Chris has led product teams at startups and Fortune 500 companies. He is the co-author of *Empowered* and *Transformed* alongside the father of modern product management, Marty Cagan.
As a partner in Silicon Valley Product Group, Chris has worked with over 200 companies, aligning their organizations with modern product best practices. Today, we will dive into how top companies build their products and how to transform into product-led organizations. We will navigate the common pitfalls, discuss shifting teams from shipping features to solving problems, and explore how to coach product managers to take ownership.
But first, what is the product operating model?
The product operating model is a relatively new term for what is a pretty old concept. We haven't called it that within Silicon Valley Product Group prior to this book. For over 20 years, we have been talking about how the best companies creating tech-enabled products are vastly higher performing than the rest. While these companies are really different internally and may have various ways of doing product, there are some consistent practices across the best companies that are quite different from the rest.
Best is defined as the companies that can routinely innovate and, in some cases, even disrupt themselves. They are generally seen as consistently able to bring value to their customers. At the highest level, that's what we're trying to solve: identifying the best practices.
When you start to penetrate this concept a little deeper, what truly differentiates the product model from other ways of working comes down to one or two main things. I will focus on one of them here: the role that outcomes play in how things are set up.
Are people asked to build things and deliver them by certain dates? This is typically referred to as output. Or are they asked to solve problems and given the agency to figure out the best solution to that problem? That's an outcome. What they do there is going to be an outcome. Yes, there might be some output along the way, but ultimately, what they're doing is solving a problem.
This is the sort of thing where the words are pretty easy, and the concept is pretty easy, but when you begin to connect the dots regarding the implications of what I just said, they get pretty profound. The job is different. When you're a product manager, that job is very different when you're working in that type of model than in one where you're organized much more around output.
At the top level, that's what it's about, and all the things that flow from that conclusion.
**Can you describe a typical transformation journey for a company moving to the product operating model, and what are the common pitfalls that you see to avoid?**
You bet! We have a lot of ways of approaching the product operating model. The highest level one we call the three dimensions of the product operating model. They are: how you build, how you solve problems, and how you decide which problems to solve.
Let me break down each of those because they're all significant. Before I go too deep, a company that's transforming will have to look at all three of those dimensions. Different companies may be a little further along on one dimension than another. Some things are independent on those dimensions, but there are also things that are very interrelated across those dimensions.
Looking at them one at a time, the easiest one to understand is how you build. This is where a lot of energy around transformation historically has lived. For example, when we bring agile delivery into a company, how you build really speaks to how you pull together the things you've decided to build. This is the primary job of your engineers. They have a role to play in the other dimensions as well, but that's their day job.
What we're striving for in the product model regarding how you build is the ability to iterate very quickly and ship at least as frequently as every two weeks, ideally much more frequently than that. This doesn't mean that everything you ship is immediately visible to your customers, but you're able to be more or less continuously building.
The other part of how you build, which many people lose sight of, is the notion of instrumenting everything that you ship. I'm not just talking about the health of the build, uptime, performance, and response. We're talking about how a new feature is being adopted, how many people are actually using it, and how deeply they engage with various parts of the product.
The reason this is so important is that ultimately, it's necessary to track and respond to outcomes. If you've got a model that's all about outcomes, you need to measure how well you're doing. So, how you build is really where we have that conversation: how well are you set up to do this? Are you instrumenting everything that actually goes out into the market? More than that, have you operationalized looking at those things and responding to them, empowering teams to do things with whatever they learn from that?
That's the first dimension.
The second dimension is how you solve problems. Fundamentally, this has to do with the units of organization and the units of work that are assigned to those units of organization. The product model is looking for small, cross-functional teams. By cross-functional, I mean a collection of captive engineers, a product manager, and a designer on that team.
Importantly, what we are asking them to do is where the rubber hits the road regarding outcomes versus output. Are we giving them roadmaps and solutions that they may tune up but ultimately deliver? Or are we giving them problems with not a lot of specificity on what solution is going to be best for that problem? That's the essence of how you solve problems.
There are several consequences of working this way. In an output-based model, the team is incentivized to get delivered plans, encode requirements, and get through all the P0 and P1 stuff. With outcomes, the focus shifts to how we are going to best solve this problem. You can imagine what your reflex would be if you're a product manager on a team like that. Your job is to be measured on how well you solve the problem, not just to start building. That would be crazy because we have no evidence that what we're going to build is actually going to solve the problem.
This leads us to things like solution-seeking prototyping and various techniques within product discovery.
The third big place, and this one is often the trickiest, is deciding which problems to solve. In traditional organizations, this model is typically very stakeholder-driven. The stakeholders, usually the leaders of various businesses, say, "We want you to make this for us." The product organization dutifully goes and builds those things.
In this case, we are shifting the decisions about that into the larger product organization. The leaders of that product organization are making the call on the overall product vision and strategy, figuring out the best places to invest to meet the needs of the business. That's where that shift happens.
As a long explanation, I think you asked me what companies need to do to transform. That's usually how we break it down: on those three dimensions. As you can see, there's a lot inside all of those dimensions.
**What are the pitfalls?**
There are quite a lot, but I'll pull out a few. One of them is that there is not an adequate understanding of what's required outside of the broader product and tech organization to work this way. A lot of times, companies believe this is the responsibility of product management, engineering, and design. They think, "Get your act together, and then we're going to be in the product model."
As you can see, especially with that third dimension I spoke about, it's really redefining the relationship between the product organization and the rest of the company. A transformation that fails to acknowledge that and have high-level buy-in may yield some benefits, but you're only going to get so far.
One of the things we typically like to say is that your CEO probably needs to have a voice in this whole thing. They're not going to be experts in transformation or drawing up the plan, but they need to be seen as being behind it. Otherwise, the rest of the business is probably going to operate the way it wanted to operate.
Another pitfall would be a more deeply cultural issue: an overemphasis on predictability. When a company believes it really needs predictability above everything else, it's probably not an appropriate fit for the product model. While predictability is definitely a part of it, the product model is fundamentally about bringing innovation and allowing that to happen throughout the entire organization. If a company isn't ready to take that on, that's going to be a place where there will be setbacks.
I've got a whole list of pitfalls, but maybe I'll stop there.
**Chris, I love your passion; it really shines through.** You mentioned the CEO. What specific actions and mindset shifts are necessary for a CEO to successfully lead transformation to a product-driven company?
I think, you know, I was talking about why the CEO needs to be involved. Tactically, if we are asking to change the relationship between, let's say, the head of sales and the product organization, the head of sales is used to demanding that the product organization deliver X, Y, and Z for them because they need it to close deals.
The product model is not going to work that way. Your heads of product and engineering are going to be very tied in with the head of sales. They will understand their needs and constraints, but they are also balancing this with the needs of other stakeholders. They will come up with a strategy that is the best way through this. Unfortunately, not all stakeholders will be thrilled about this, and this is when a CEO or someone very senior above all of this will have to break the tie on where things go.
That's one reason they need to be involved. But I think there's a deeper thing that the CEO can communicate. There's a quote—think Bill Campbell said this—that the company cares about what the leaders care about. If you see your leader signaling the importance of this, telling the story of why we need to work this way, and why they believe deeply this is important for the company's success and for the company's customers to be successful, that will make it a lot easier for people to understand why this transformation is happening in the first place.
Transformations are hard, and they will ask a lot of people who historically may not have had to deliver on this. If your CEO or highest-level leaders demonstrate passion for this, they will inspire people to move forward through the transformation.
I was reading the book, and one sentence struck a chord with me: "Credibility follows influence." As a product leader, they always say, "It's not my fault; it's management's fault. They are output-oriented; we should be outcome-oriented." What specific roles do product leaders play in driving a successful transformation, and how can they build credibility and influence within their organization?
That is such a critical point because I've been talking for a long time about what the stakeholders may be giving up in this whole thing, but what I haven't talked about is why they would be compelled to trust this particular team.
One of the things I'll often say is that you're asking a product manager to make a decision about what the right solution is to solve this problem. Historically, a business stakeholder would do that, but now we're asking the product manager to make that decision. If that product manager doesn't know as much about the customers—at least as much as that stakeholder—then why would that stakeholder ever trust them to make a decision like that?
So that's fundamentally the intent behind the sentence you asked about. More specifically, the leaders within the broader product organization are responsible for two big things.
Number one is providing the context, which we call the strategic context for these teams. Teams aren't just making decisions with no constraints on them; they have to understand how it all fits together. Elements of strategic context that leaders are responsible for include things like:
- What's our product vision 3 to 5 years out?
- What do we think the world is going to look like, and where are we going to play in that world?
- What's the strategy for moving toward that vision while satisfying the business goals we need to satisfy along the way?
Another part of strategic context has to do with how we organize teams and what they are responsible for. Ideally, we want durable teams that have an area of ownership—a charter that they're responsible for—and they will solve problems within the scope of that charter.
How do we allocate those charters? How do we divide the teams up? Who's responsible for what? What are the boundaries between them? If we divide them this way, what kind of dependencies are we creating? If we divide them a different way, might we get a different set of dependencies?
Ultimately, the last part of this strategic context is how we craft what needs to be done and allocate this into teams in the form of problems, as opposed to just saying, "Go build this." We want to allow that innovation to percolate up.
The other half, though, is just as important, and it's something that people talk about a lot but don't commit a lot of real time to: coaching. It's about developing a team and ensuring that people know how this operating model works and how to get better in it. More than that, it's about communicating all of this strategic context in a way that these teams can operationalize it and bring it into their decision-making process.
We talk in the book about the main competencies—what are the key competencies in the product operating model? One of those is the product leaders, and this is perhaps the trickiest one. It's a very difficult thing for leaders to do, especially if they're used to a command-and-control style where they say, "I need you to do this for me."
This is a different mode, and leaders often don't understand what it looks like to work the way I just described.
There are so many questions I can ask, but first, because we have this myth that as a product leader, I should not interfere with the product team and just let them discover whatever problems they need to solve. But you're saying that's wrong. They should have a vision, a strategy, a team topology, and they should focus on coaching.
Regarding team topology, I know it's an unfair question to ask, but should you create teams around certain KPIs like revenues, technologies, or problems? Can you share any examples from your experience?
You bet! There are two things you said. The first one is about leaders who misunderstand or overfit the notion of creating empowerment within the teams. They often look at it as you phrased it: let the teams figure out the solutions and the problems. They know best where the opportunities and problems are that need to be solved.
We actually don't advocate that. We think that's a recipe for chaos. You end up having a lot of teams skittering off in their own direction. A leader can feel like they're doing a great job by getting out of the way of the team, but really, the leader is not doing their job because they haven't provided the right context for that team to operate in.
The way we usually say it is that it's the leader's responsibility to determine the problems to be solved. Within that context, the team has all the empowerment to figure out the best solution to that problem. That's where the difference lies. Empowerment is not a free-for-all; we mean something specific.
You also asked about the topology of teams. There are many strategies for how you break down teams, and usually, a company is going to employ them all. You're not going to just pick one mode and say, "We break our teams down like this all the time." Usually, there are pockets of this and pockets of that.
You may break down along pure technology lines—areas within the stack. You might have a mobile team, a web team, backend teams, or a model-building team. These are all focused around the areas of technology, and there's a lot of comfort that comes from that. You end up having engineers who can easily report to the same person.
But that's not the only way to divide things up. You may divide things up that are a little more oriented to a particular actor in the ecosystem. For example, if you're a big retailer, you might have teams for merchants, online shoppers, and in-store shoppers.
You may also orient around a particular facet of the journey or some aspect of an experience that a customer or user might go through. It may be oriented around a vertical industry because serving financial services is a little different than serving manufacturing or media.
You may have teams that are oriented around your go-to-market strategy. These are the teams around the direct sales portion of your portfolio, and these are the teams around the self-service SMB portion of the portfolio.
Regarding specific KPIs like revenue or growth, I don't love organizing teams strictly around a KPI. There was a big push for growth teams, and there still are a lot of growth teams out there. Some companies have been successful with that strategy, but I've always found it a little disruptive because those teams tend to cut across many other teams. They create a lot of dependencies and lose broader context.
That said, if you really need to put a deep focus on a particular KPI for a long period of time, then maybe you do want to home in on a team. I tend to prefer those KPIs manifesting more in the problems we allocate to the teams. For example, we may have several teams and say that for this quarter, growth is really the most important thing. We need you to focus on that for this quarter.
That's typically how I use that, but we're getting into some real specifics on topology.
**What are the signs or telltales that you have the wrong topology?**
The biggest one is when you're drowning in dependencies. You've got bottlenecks, and there's always going to be cross-team collaboration. Teams are always going to have to work together; you're never going to get rid of dependencies. But if you're spending a huge amount of time and energy getting six teams to collaborate on things, then you may want to look at your topology and see if there's a way to reimagine how the boundaries are set up on these teams that might alleviate some of the worst dependencies.
That's probably the single biggest sign.
There are some other signs as well. If you have a lot of teams where the charters are such that people don't have a real sense of ownership of anything, they're just tiny cogs in a giant machine. If they're disconnected from having any sort of impact, you're always going to have some teams like that, but if you've got a lot of teams like that, you're not creating a sense of empowerment through ownership.
Those are a couple of signs.
One of the problems I face, especially with junior product managers that I coach, is ownership. How can you coach or teach ownership? This is one of the hardest problems for me personally.
By ownership, I think you mean that this product manager isn't bringing it on. They say, "Just tell me what to do, and I'll do what you want me to do."
The first thing that happens a lot with older school product managers is that it feels a lot more like project management. You're following a process, getting a lot of things organized, and I'm not minimizing this; it's a hard job, but it's a very different kind of job. A lot of people derive comfort from following the process.
You give me the tasks, and I'm going to do the tasks. The problem is that you can do all the tasks and do them to an A+ level of performance, but the overall outcome still may not move. The product manager can say, "Look, we did everything you asked us to do. The product didn't work; the customers didn't like it. That's not my fault; I built what you told me to build."
This is the essence of the product model. We're trying to push accountability and ownership down into the teams, where people are not only responsible for these outcomes but are passionate about them. They want to do better.
As you're coaching people like this, the first thing you really need to determine is whether this person is capable of thinking this way. Some are not. For some, it doesn't feel safe. There's a lot of risk because now their judgment is much more in play. If you're not taking on that ownership, you're relying on your leader's judgment, your manager's judgment, or whoever is telling you to create the things you are creating.
If you're deciding what's getting created, you have to rely on your own judgment, and that's scary for some people. So, that's your first step: determine if this person is right for this job. They may not be.
If they are right for the job or have some potential, then you need to actively coach them. For someone new to this, you might have more than one one-on-one a week with them. You may be actively rolling up your sleeves with them for several weeks while they understand what's involved here.
You need to communicate, "No, no, no, this is your decision to make. I'm here to support you. I can give you input, but you need to understand we're waiting for you to make this decision."
There's one other thing. Christian Idiodi, one of my partners, said something once that I thought was great: "If you know, you will care." What he meant is that you have product managers do their homework and meet with customers. If they haven't done it yet, have them go out and meet with 20 or 30 customers.
Ensure that those product managers are meeting with customers and users regularly. The magical thing that happens is that when you start to know what's going on out there, you as the product manager will start to have opinions. That's a way to coax someone into taking on that ownership. The more they know, the more they will want to know.
So, I love that. I've started talking about that pretty frequently with my customers.
To recap, I gave you three steps:
1. Determine if the potential is there at all. Be honest with yourself and this person.
2. Routinely meet with them and remind them what it means to own what we've asked them to own, what it means to be accountable, and what it means to be empowered.
3. Coach them to do a lot of the homework and learn about the customers, the data, and the broader business stakeholders.
All three of those things together are the recipe for pushing ownership down to the level of individual product managers.
That's the most beautiful answer for this question because you have no idea how much I ask this question. This podcast keeps me honest. I was that product manager who did not have ownership, and there was a great product leader who decided I had the right skills. He invested so much time and energy in coaching me, so I'm internally grateful for him.
I've had a couple like that myself, and I think it's good to take stock of those people. Look back at various points in your career and think, "I learned these things from this person." It's rare to get someone like that, so I'm glad you found someone like that.
Can you share one of those stories or one of your learnings from your mentors?
Sure! I've told this story in many forms, but this was a particular coaching story about a specific point in my career. This was a little less about ownership and more about helping me make the transition from being a really good individual contributor to a manager of product managers.
As a manager, I was hiring my first person. My manager told me, "Your new person is coming in. Let's call them Bob. Bob needs to understand two things. For whatever part of the product you're giving to Bob, he must know more about that part of the product than anybody in the company, including you."
The second thing my manager said was, "You need to ensure that Bob has a public win in the company within the first 30 to 45 days. He needs to be able to stand up at our company all-hands meeting, describe something that happened, and take a bow for the applause that will follow."
My manager told me these two things, and it was funny because I misheard them. I misinterpreted them. I thought, "Yeah, Bob needs to know he has to perform. He has to get a win and learn all this about the product." I was thinking this was advice for Bob.
I quickly figured out this was advice for me. It was telling me I needed to figure out how to step back and allow this person to know more about this aspect of the product than I did. I also needed to help engineer a win for this person.
We got there, and Bob took his bow. Of course, I did a lot, but it was my job to be proud that this had happened and not to be insecure because I wasn't getting the credit for this thing that happened.
This was such a profound thing for me, and it took a few months for it to settle in how meaningful that little piece of advice was. It was so profound that I've leveraged it with almost everybody I've ever trained through that particular transition.
I've even shared this technique with the managers I have led who are bringing other people through that transition.
That's one of my favorite stories. I think it really is a firsthand example of such an insightful piece of advice that was simply delivered but absolutely reframed how I looked at my work.
I'm always obsessed with what I'm doing, what I'm delivering, and what the company sees in my work. Once you become a product leader, it's not about you anymore, and it is hard.
It's a tough transition. You have to learn how to understand your value in a very different way. Your value is not directly tied to building; your value comes from how successful you've made somebody else.
There's some insecurity that comes with that because you may wonder how people will know. How do they know that I did that? There's a bit of a leap of faith for people making that transition.
In my case, the advice I got from my manager made me passionate about that. It made me passionate not just about what I was building but about the team I was building.
When I look back on my tenure as a head of product, the things I am most proud of don't have anything to do with the products or their success in the market. I'm proud of where the people on my team are now and the leadership positions they've gotten into.
Of course, they did that, but I feel a lot of pride in what I did to help enable that and steer those people in those directions.
This is such an interesting point because I've watched a few interviews preparing for this podcast. Some product leaders are proud of their products, while others are proud of the teams they build. Why is building teams very important for you?
I think two things. Part of it is just how I'm built constitutionally. I like people; I like connection and collaboration. I am personally proud of bringing that energy into the world.
When I can create something, I would describe it to people as, "Once you become a real leader of product, your product is the organization you're building." It's not just the people you put in there; it's how you put them together, how you coach them, and how you incentivize and empower them. That's an engine, and I am proud of building that kind of engine.
As companies scale, this is the only way it works. There are a few examples of visionary leaders who maintain tight control even as the company scales, but that is quite rare. Many great companies achieved greatness because they were able to scale empowerment into the organization.
We touched a little bit on the competencies for product managers, but can you help me understand what the essential competencies for product managers, designers, and tech leads are that they need to thrive in a product-driven company?
We use the term competency to describe the role. There is a product management competency, a product design competency, and a tech lead competency, which is a role played by one of the engineers on each of the teams. We've already spoken quite a bit about the product leader competency.
Within each of those competencies, there are some things that are a bit different in the product operating model than in other operating models.
Starting with the product manager, we are trying to create empowered teams. An empowered team is responsible for figuring out the solution to a problem and is held accountable for how well they solve that problem.
If teams are operating that way, that leads to some differences within these classical job titles. The competency of product management here is very much oriented around the value of the solution being created and the viability of that solution.
By value, I mean: Is this solution going to resonate with customers? Is it going to work in a way that they need it to work? By viability, the question is: Is this solution going to work for our own business? Is it sellable? Is our sales force going to be able to move it? Is it compliant with the right sorts of regulations? Can we market it? Is it consistent with our partnership obligations?
All of the business side of things is something we collectively as a team come up with solutions for. As a product manager, I will be concerned with those two things.
These two things are particularly interesting because, in more classic command-and-control or feature teams, you don't usually have to worry about those things within the product team. Whoever's asking you to build this stuff is responsible for thinking about value and viability.
In the product model, it is the fault of the product team if something fails. Therefore, we need someone who deeply cares about the value and viability risks of any solution we're going to try.
That's kind of the main differentiator within that competency.
For our product designers, in the old model, there really isn't a sense of product design in the same way. There might be a lot of design—UX design or visual design—but many times, those people are quite downstream. A lot of decisions are made before the product designer is ever involved.
This makes it a very tactical role. In the product model, it's a very strategic role. Often, they are the ones figuring out how things work from an experience perspective.
One of my favorite Steve Jobs quotes is, "Design is not just what things look and feel like; it's how they actually work."
What we expect from a designer in crafting an experience is that they are prototyping like crazy. A good product designer might do more than a dozen prototypes in a week. They might be very lightweight, and some might be higher fidelity, but most of them will get thrown away.
The whole point is that there's always this churn of ideas that the team can discuss and bring in front of customers. It's a very different way of operating.
The tech lead is the last competency we haven't spoken about. Again, we're talking about empowered teams here, and we are trying to bring engineering into the fold—not just on how you build but also on what you build.
There's an old adage that products are about the what and the why, and engineering is about the how. In the best companies, they don't look at it that way. In the best companies, engineers are often the real engine of ideation and innovation because they know what's possible in ways that nobody else does.
In a traditional model, they tend to be pretty far away. They're just the story factories. "Okay, I'm going to pull this thing off and code it up."
What we're trying to do is bring engineering into deeper collaboration. Usually, we center that on someone called the tech lead. Any engineer can do this, but we are saying that at least one is responsible not just for delivery but also for spending some of their week on product discovery.
This means they are actively collaborating, looking at prototypes, weighing in, and determining the feasibility of what it will mean to build it this way. They may even participate directly with customers at various times in interviews and user tests. They're helping to be the conduit to the rest of the engineering team around the discovery side of things.
There's more to be said on all of these competencies, but those are the main things we're trying to bring forward and why we talk about these key competencies in a way that's a little different from traditional job titles.
Most tech leads I work with are obsessed with delivery only. Why should they care about discovery?
The main reason, from an organizational perspective, is that we're not getting the full value out of our engineers if we use them the way you just described. That's an example of worrying about the what and the why while we're going to worry about the how.
What the product operating model says is that some of your engineers may work that way, but there's a lot of talent here that can have ideas on the what as well. If you only knew more about the context, if you only cared more about product discovery, if you only knew more about the customers, you can't help yourself; you're going to have ideas.
Your ideas are probably going to be better than anybody else's. The reason for that is that engineers know technically what's possible right now in ways that nobody else does. This is often the main engine of innovation.
That's why we're explicit about saying, "If you are the tech lead, understand that yes, your day job is delivery. That's the main thing you're doing, but you do have a bit of a side hustle here on discovery." You should expect that 20-25% of your hours will be on tasks that are more about figuring out what we're building rather than just how we're building it.
That's a beautiful answer. I'm going to clip this and send it to all my programming friends.
Let me give you a question from the community. You touched on it a little bit, but how can organizations transition from feature teams to empowered product teams, and what are the key elements to ensure this transition is effective? We always hear about mercenary teams.
We've been talking around a lot of this. This is one of the elements of transformation. I think we've hit why we want to transform and the main attributes of this. If you've got a lot of feature teams and you want to empower some of them, there are a couple of things those teams need.
The first one, and probably the most important place to focus, is how work is articulated to them and what we are asking them to do. If you start from that point, are we giving them a roadmap? Are we giving them a solution that they need to define some requirements for? That's what you do with a feature team.
Don't get me wrong; for some companies, a feature team is a big step up. A lot of companies out there don't even have notions of teams. They have ephemeral project teams where people swarm around something, deliver the project, and then disband to form around different projects.
Feature teams will give you some benefit, but you really don't have any empowerment there. Yes, the teams have a lot to figure out, but they are not empowered to determine the solution.
What we need to do is figure out what is required to give a team a problem to solve and allow them to figure out the best way to do it. One of the things is defining that interface: what is the unit of work? Is it a solution they're tuning up and delivering, or is it a problem for which they will figure out the solution and deliver that solution?
A lot flows from that because, in most cases, a feature team that has only ever operated as a feature team doesn't understand how to figure out a solution. This is where product discovery comes in.
Understanding the techniques of running experiments quickly, what the various types of prototypes are for helping understand the risks inherent in the ideas we have, and how to put those prototypes into a testing context—some will be quantitative, and some will be qualitative. Ultimately, a solution is not planned and executed; it is revealed through rapid prototyping and experimentation.
A team needs to understand how to do that. Often, there's going to be a big training component for that.
There's also the issue of product managers or teams who are not inclined to work this way. You need to figure that out. Are they coachable, or do we need to not have them in this particular team we're trying to empower?
I've jumped around here, but for me, it really starts with what you're asking a team to do and moving that from a solution into a problem. Then see what kind of falls out from that. That's where you're going to get the people and the roles, and that's where you're going to get product discovery.
**There's another thing you mentioned in the book. Under the product operating model, when you build stuff, you have two outcomes: the product itself and the learnings as well. Some people forget about the learnings.**
Yes, for sure. One of the high-order cultural principles around the product model is that it emphasizes learning. Everybody talks about failure or right and wrong, but it's really about harvesting, sharing, and celebrating the insights you get. Those insights propel the whole engine forward; they're the fuel of the whole thing.
You definitely want to bring a lot of focus to that. Most cultures are about whether something succeeded or failed. The thing we built will reward success and punish failure, and that's all there is.
That leads to your incentive structure, which drives behavior. Here, we want to do a lot of work designed to generate insights and learnings, but we want to do it in a way that's fast, cheap, and low risk.
The slowest and highest risk way to get those learnings is to build everything people think should be built, put it into the market, and see what happens. Only then do you learn that this feature idea we thought was so good isn't getting the adoption we expected.
That's an expensive way to figure out that you probably shouldn't have built this thing. If instead, you did some quick prototypes in a day, showed them to a few users, and interacted with them, you might realize that if we do it this way, it's going to connect a lot better.
We're falling into this hole we didn't realize, but now that we've talked to half a dozen people, we see there's a big problem here. This is why we want to focus on insights and get people celebrating insights, almost irrespective of whether it succeeded or failed. If there's something we can leverage going forward, that's a good thing. We've done the company a favor.
**I want to talk to you about roadmaps, specifically outcome-based roadmaps. What are they, and how can they be implemented to ensure that product teams focus on solving the right problems?**
Roadmaps are much maligned, of course, within product operating model circles, and I think that doesn't tell the whole story. Roadmaps are doing some important jobs. They ensure that we're working on the most important things first, and they bring some measure of predictability into the organization.
We may need that predictability to get other things synchronized. These are very real and important problems, and we can't just say all roadmaps are bad and blow them up. Dates don't matter anymore because we're agile—that's crazy. You can't do that, especially at scale.
The problem with roadmaps in general is that they tend to be more prescriptive than is helpful in this type of empowered team model. They tend to articulate solutions. I'm not saying every detail and every requirement is encoded in a roadmap, but there's enough encoded that it sets us off on a particular trajectory.
Specifically, it sets us off on a trajectory of managing to output rather than managing to outcomes. People care more than anything about hitting that date, and at this point, you're going to shut off all the judgment required for doing product discovery. Product discovery will become a nuisance; it will take time away from producing output.
That's usually the problem: we make commitments very early in the process, and it sets this engine in motion in a particular way.
Outcome-based roadmaps are trying to address this. Before I go into outcome-based roadmaps, I should say that there are absolutely tools within the product model for committing to dates. There are times when we need to commit to a date on something.
The problem with most organizations is that we run everything through that process, and everything looks like that. In the product model, we're much more judicious about what things need dates. We reserve what we call high-integrity commitments for the things that really need it and can anchor around it.
We also bring in some discipline to do some product discovery before we make that commitment. In many cases, we make the commitment well before we know anything.
So, that's the first piece. The other one is that we have dates, but the things we put on that roadmap are much more the outcomes we're looking for. What metrics are we trying to move? What is the ultimate impact of what we've done without necessarily committing to what the actual solution is going to be on that roadmap?
This becomes a way of structuring things. There are dates, but we associate an outcome with a date; we don't associate output with a date.
There was one other thing I wanted to mention. I always had a magic word I would use, especially when I was trying to change the language around roadmaps. When I had a lot of parties banging on about needing to see the solutions, I would say, "We need to see that you guys have something in mind and that you're not just being airy-fairy about outcomes."
There's distrust, and in some cases, you do need to reveal that we are considering certain things. Rather than talk about features on a roadmap, I prefer to use the word "candidate." A candidate means this is something under consideration.
We haven't done the full discovery on it, but it's a direction we're going to look at. Ideally, you can put multiple candidates out there, with the implication being that we're probably not going to choose all of them. We may not choose any of them, but it's a way to annotate some of these outcomes to make them a little more tangible for people who are uncomfortable dealing purely in outcomes.
**After all we've discussed, I'm wondering how the product operating model scales. How can organizations scale the product operating model across multiple teams and departments, and what are the key considerations to keep in mind during this process?**
Scaling is very hard. Some companies are really excited about the product model and are engaging at a high level within their company. Their reflex is to train everybody in this thing and roll it out everywhere, which is not a recipe for success.
It's much better to pick some area and go deep on that area. We call these pilot teams. Maybe it's within a particular business unit or a specific part of the value portfolio being offered to the world. We're going to go deep with that set of teams, figure out how it's going to work, evangelize what we're learning, and harvest the successes.
We need to ensure that people understand what we've done and build enthusiasm there. Then we work to the next set of teams, and it gets quicker after that.
Going deep rather than going a lot of groups at the same time and going shallow is generally what we've seen work.
**How can companies ensure that their transformation efforts remain customer-centric, and what specific techniques can they use to stay aligned with customer needs and expectations?**
That's a deeply cultural orientation. We need to be banging that drum all the time. We've already spoken a lot about strategic context, and I think that's a starting place. Product vision is the work that gets people inspired and connected with why they come to work every day and what the job is about.
At the highest level, providing that context and coaching from leaders is important. It has to be cared for and fed continuously. It's not something where we do one presentation, and then everybody's good and gets it. You have to continuously remind them.
There are some other things at the team level that are really helpful. Simple tactics include ensuring that every product manager and product designer knows that we expect them to talk to, say, three customers a week, every week.
We are not batching this customer and user contact. We're not batching that up to a phase where we're doing user testing for a couple of weeks, and then we're in that phase and moving into a delivery phase. You need to communicate that this is part of your day job.
You need to be doing this all the time, and there's a lot of benefit that comes from that. It was kind of what I was describing earlier when we were talking about ownership and Christian's quote about if you know, you care. This is a way of ensuring that everybody continuously knows and cares.
Those are the two things: one is a bit more top-down, providing broader context and inspiration, and the other is much more at the level of what you're asking your product managers and designers to do. Ideally, we want engineers to be involved in that as well.
They're not going to commit to the same level, but we want them to get into that as well. It's amazing how much the customer and user stays in the conversation when you do that.
**One of the earliest lessons I learned as a product manager is never to release a feature without a way to track it.** How can companies measure the success of this transformation to a product-driven model, and what key metrics should they use to track it?
I get the question here: how do you measure the transformation itself? This is a tough one. There are no easy metrics like retention or revenue that always translate directly to the success of a transformation.
We encourage companies to look at two things.
Number one is: for whatever business outcomes you're looking to achieve through your product, are you achieving them? In most cases, before the product model transformation, they can't even answer that question. They don't know because they haven't connected the outcomes to the product organization.
They have some vague sense that they succeeded here and failed there, but it's very difficult to translate that into where this came from in the product work. So, what are your normal business outcomes, and are you achieving them? That's the whole reason for transforming in the first place.
The other one is a little more subjective. It specifically involves spotting things you were able to do that you could not have conceived of before the transformation. Usually, it's in the form of some innovation—something that has been added to the product model that nobody asked for.
It didn't come from the top down; it wasn't a stakeholder that asked us to do something. We made some discovery that was fundamentally important. Many of the customers we've worked with will point things like that out. They'll say, "Look, we have this innovation here. This wouldn't have happened if we hadn't been operating the way we are now. This wouldn't have happened in our old operating model."
**I have one last question. Can you share some lessons learned from companies that struggled or failed in their transformation efforts, and what are the key takeaways that others can apply to avoid similar outcomes?**
It's a tough question. If you look at any transformation within a large company, it's not a binary thing. It's not like they transformed 100%, and everything is great. It's going to be a mixed bag. There will be places where it takes hold early and is quite successful, and there will be places where things lag quite a bit.
Some places may not be entirely appropriate for bringing the product model in.
Some things I've seen are that a transformation is often led by a charismatic leader who is seen as the real champion of it. If that person leaves the company before a critical mass has been reached, it is difficult. If there's not been a real changing of the guard and someone has assumed that same mantle, it can derail a lot of this.
If it gets to a certain point, there's a threshold where enough of the ideas and culture have changed, and that's fine. But early on, if you see somebody leaving, that can derail a lot of this.
Another thing I've seen is that it may be a good fit for the first set of pilot teams, but as you begin to scale, it may be a tougher fit. One of the things that have come up for us quite a bit is that some of these more traditional corporate IT organizations are looking to bring a lot of the product model concepts in.
They're trying to get more oriented around outcomes and time to value, which is good. They're trying to create good pockets of ownership, but at the same time, they are often dependent on vendor tools.
They have their CRM tool from someone else, their manufacturing tool from someone else, and the IT group is responsible for integrating and configuring these things. They're not necessarily building solutions.
Here's a place where the product model can apply somewhat, but it certainly can't be as total a transformation as something that is more directly customer-facing. That becomes a challenge in figuring out what the product model means in these different places.
One more thing has to do with the imperative. Many cases, companies are brought to the product model because there is some business climate imperative for them to do so. Maybe there's a competitive threat, or there's been a tectonic shift in technology that they don't believe they can take advantage of.
They feel they need to change their operating model, so there's a lot of energy and impetus. A lot of people are in wartime mode. But if that passes and things are a bit more calm, and that energy has been taken away, it's easy to slip back into the old ways of working.
Those are some setbacks to be aware of.
Thank you so much for sharing and being candid with your answers. I think that's a wrap-up. Where can our community find you? I'm going to include a few links in the comment section.
I'm with Silicon Valley Product Group, so svpg.com is the place to find us. We're publishing articles regularly there. Of course, we have the books we've published, but books are just a snapshot. The thinking is always adapting.
If anyone's interested, we also have a newsletter that goes out every time we publish a new article. You can sign up for that on the website as well. That's probably the best place.
I am also on LinkedIn. I have one of those ungoogleable names; both my first and last names are very common. I can share my LinkedIn address with you, as it can be a little difficult to find through search sometimes.
Great! You can put that link out there.
What are your ideal customers? They can hire your company to help them with the product operating model.
We work with an expanding list of companies. Most companies these days are what we call tech-enabled. They might be legacy companies that predate the internet, or some of my customers are over 100 years old.
There's no question that technology and digital experiences are becoming part of every company. We work with a lot of different industries and sizes. Large and medium-sized companies will engage us directly for private engagements.
For smaller companies and individuals, we run what we call public workshops, which you can find on the website. Our product master class is basically four days—four half-days online—and it walks through a lot more detail on the types of things we've been talking about today.
I encourage anybody to take one of those.
Thank you so much, Chris, for making the time to be on the podcast.
Thanks! It was a lot of fun. I enjoyed the conversation.