Transcription
The point of the product operating model is to really define the outcomes up front. What is it that we're trying to do with this product? What do we need to have happen with this product? Everything is organized around that. The product model really attacks it from three different dimensions.
There's how you actually go about building something. The second big dimension is really about how you solve problems. The third big dimension speaks more to product strategy. It's changing how you decide what problems you want to solve in the first place. That's what it means to empower that team. Given a problem, they will find the best solution. So that aspect has been removed from leadership and pushed down. But what hasn't been removed from leadership are the problems that we're asking them to solve.
To really be working in the product model, the first aspect of changing how you build has to do with how quickly you're shipping. If you are shipping anything less frequent than two weeks, you're probably not there.
Hello, guys. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me Chris Jones. He's one of the co-authors of this recent book titled “Transformed.” If you still remember Marty Cagan, he actually appeared in episode 102 before. This Transformed is actually one of the series in SVPG book. Previously with Marty, I've discussed the title Inspired and also Empowered. This time with this new book, I'm very glad to have Chris here to actually talk more about the book.
So welcome to the show, Chris. Thanks, Henry. Great to be here. Right. Chris, I always love to ask my guests first to maybe tell us more about yourself, right? If you can maybe mention any highlights or turning points that we can learn from, I think that will be great.
Yeah. I mean, like so many people, I have a relatively non-standard route into product management. I don't think there really are that many standard routes into product management. I started as an engineer. My degree was in computer science, and I worked for a developer for a bit. Did a little bit of work at Microsoft and then another startup.
Actually, I think my biggest takeaway from that period of time was that I was a terrible, terrible software developer. I love technology and loved how it connected to the business, but I had a really theoretical education. I was not good at moving quickly with code. I would overthink it and that sort of thing. So I actually abandoned that.
I had a little bit of time where I was lost in the woods doing something very different. I was actually doing film production for a few years, working as an editor, a producer, and a videographer on some documentaries and a little bit of music video work. It was kind of around the mid-nineties that work led me into what at the time was really the big technology innovation that was disrupting everything, and that was the worldwide web.
You know, it was kind of as big then as a lot of the large language models are now in terms of the impact on the world and companies trying to figure this out both technically and from a business model perspective and from a culture perspective. I ended up actually starting a small company to work in that space.
We didn't realize it at the time, but a lot of the ideas that Silicon Valley Product Group, my current firm, really espouses now, we were kind of hitting on some of those themes. We were a service organization. We were working with companies that were essentially coping with this new opportunity. Some of them were using it internally for their own operations. Some of them were using it to enhance their own products, creating new surfaces of interaction.
Some were brand new companies that had never existed before who were creating all of the infrastructure and technology around this stuff. We were working with all sorts of companies, and we had about a third of the employees who were product managers, a third were designers, and a third were engineers. We worked with a lot of companies doing a lot of pretty cool stuff at the time.
This incidentally is where I first met Marty Cagan, who you mentioned before, the author of these books and the founder of Silicon Valley Product Group. After that, I spent about eight years doing that, and I had my first real product management leadership job. It was a company that was in the information security space, a big B2B sort of thing. We actually really kind of defined a new market within information security.
The company was purchased by Symantec, and I worked for a while across their enterprise portfolio. Then I took another leadership job running product design and data analytics for more of a consumer security company. It was a mobile security company also based in San Francisco, where I am. I was with them for about five years and learned a whole new set of things, you know, very much a design-forward, data-forward, quick iteration sort of company.
After I left that company is when Marty Cagan invited me to join Silicon Valley Product Group. I've been with them now for 10 years, basically working with all sorts of different companies and individuals who are really trying to get better educated on what best practice looks like within product.
Thanks for sharing your story. One thing that I'm really interested in is that I think quite a number of engineers may also think that maybe that is not their career, right? For you, you switched into product management now. If you can advise those engineers who are probably thinking of switching the lines, what will be some of the key traits or key signs for them to think about moving into product management?
Yeah. It's a great question. It's one I think about a lot because being a product leader for a while, I hired quite a few people who came from that side of things. I'd say get curious about a very, very wide variety of things. If you're an engineer, you've been living mostly in technology, mostly in what's possible, mostly in how things are put together.
But many good engineers already are very curious about things like customer value, like what is it about this product that is resonating with customers or the experience of the value that is being produced. Being curious about those things or how does it actually work with the business? Not just the money-making side of things. Are there regulatory concerns? Are there brand concerns? Are there partnership concerns?
If you find yourself curious and interested in that entire problem space, then product management is probably going to resonate really well with you because that's what good product managers are concerning themselves with—all of those sorts of topics.
That's a very key point, right? So get curious, not just in terms of technology, right? Also in the business, in customer value, and everything else, right? Today's topic definitely touches around those things as well. The book titled Transformed, which is quite recent, right? Moving to the Product Operating Model, that's the subtitle.
In the first place, I know that SVPG has come up with at least four books by now, right? The first three books, Inspired, Empowered, and Loved. So tell us why another book?
Yeah, it is interesting. There's been a real progression here. We started with Inspired. Inspired was about capturing the best practices of what was going on within individual product teams. We have a technical definition for that, you know, a small cross-functional group of people and how do they work when they're truly empowered to come up with a solution to a problem that they've been given.
Inspired goes into a lot of the core principles there, kind of what it looks like to be operating in a team like that. What does product discovery look like? What are some of the techniques that these teams use in order to come up with good solutions? The book was a big hit. A lot of companies out there said, yeah, we've been waiting for this for a long time, and this is the way that we want to operate.
But they very quickly hit a wall because the rest of leadership within the broader product organization didn't know how to create that sort of environment. That really led to that second book, which was called Empowered. It is also scoped very much to the broader product organization, kind of the people within engineering, within design, within product management, maybe a few other roles.
But specifically the managers and leaders and what is it that they need to do in order to create an environment for teams to operate the way that we are talking about within Inspired. Quick detour: Loved is on a slightly different path. It's a bit, you know, whereas Inspired and Empowered and now Transformed really live solidly on the product side of things, Loved is a little more oriented toward the go-to-market and the product marketing side of things.
That's really what that book is about. It's relatively standalone. Go-to-market is a huge topic for product management as well as product marketing. So it's really intended for both. Back to Transformed, it's sort of the next level here. Okay, this is great. Our product organization understands what we need to do. We understand it at the team level. We understand it at the leadership level.
How do we get the whole company to digest this? When you're really running in this model, when you're really building products the way that we've been talking about, it very quickly gets outside of the product organization. It involves how your stakeholders work with the product organization. It involves how sales thinks about the product organization, how the CEO thinks about the product organization.
So really, it's about a framing that allows you to bring these ideas to the entire organization. I'm sure you've seen transformation is sort of the big thing that a lot of these companies are talking about. We have a take on it when we're talking about transformation. For us, it really means what are we talking about when we're trying to work more in this product operating model?
When we speak about transformation, of course, it's kind of like so many companies are still doing it now. Although it seems like digital transformation, Agile transformation, whatever transformations have been happening for quite some time, right? What do you think is the difference between this transformation and all the other transformations that some companies are already embarking on?
Yeah, well, we really come at this on kind of three dimensions. Other models out there might have approached parts of these dimensions; they'll focus on particular areas. But the product model, we haven't really even defined what that means. I'm guessing that we're going to get into that, what some of the details are.
At the end of the day, what it really has to do with is operationalizing outcomes. What we're looking to do is to draw a very stark contrast. You might have a command-and-control model where people are deciding we need to build these things, and then there are people who are asked to go and build those things. Hopefully, good stuff happens later.
There are various flavors of operating that way. We generally associate that with output-based models. If you're talking to the product organization, their job is to ship. Their job is to meet dates; their job is to get through the set of requirements that they've often been given. Maybe they've teased some things out and framed them up a little bit.
But generally speaking, it's about shipping these things. But then their job is over. Whether or not that thing succeeds is really the responsibility of the people who asked them to build this particular thing. There's a horrible track record of things when you build things that way. Customers don't adopt them, or there were things missed along the way, and they realize that it actually is going to take a whole additional six months to build it, or it somehow did not work with some other aspect of the business or whatever it happens to be.
There's all sorts of ways that they can fail. The point of the product operating model is to really define the outcomes up front. What is it that we're trying to do with this product? What are we hoping is going to happen? What do we need to have happen with this product? Everything is organized around that.
It's not just at the top levels of the organization where those outcomes live. Those outcomes get pushed. They get divided up in various ways, but they're ultimately pushed all the way into the small teams that are actually executing the product work. A particular team is going to be concerning itself not just with did I ship this thing on time. They're going to be concerning themselves with, are people using it? Is it generating the revenue that we thought it was going to generate?
All of those sorts. That's how they're measured and how they're measuring themselves. With that as a starting point, the product model really attacks it from three different dimensions. There's how you actually go about building something. This is usually where Agile plays. By the way, there's a lot of overlap with many of these models.
How you build things has to do with your release process. It has to do with how your engineers are organized. It has to do with how things are instrumented. It has to do with your infrastructure and your architecture, all of that kind of stuff. The second big dimension, and I'm assuming we can go into more detail on these if you're interested, is really about how do you solve problems?
Another way of saying that is what's the unit of allocation of work that gets put onto a team? Is it a piece of output or is it an outcome? When you move things to outcomes, there's a lot of other stuff that tracks after that. The third big dimension really speaks more to product strategy. It's changing how you decide what problems you want to solve in the first place.
In typical organizations, you have lots and lots of stakeholders out there who are throwing things at the product organization. They're doing their best to prioritize and keep all these people happy. But there's nothing coherent that's really holding this all together. When you're really dealing with a product model transformation, you have to focus on that aspect as well.
How do you go about really making sense of all of this stuff and coming up with a coherent strategy? That will essentially create and reveal the problems that we're going to ask these teams to solve. That was a relatively long answer and kind of getting at the top level of how the product model is organized.
As I said, back to your question of how does this compare to other models out there, there's a lot of models that do have some things in common with this. But, as I said, most of the models that people are thinking about transforming to really are living just in that first dimension, you know, how you actually go about building.
Thanks for elaborating a little bit more about how this product operating model works and also how it compares with others, right? I'm sure many people who have gone through transformations, statistically, some of them are still not happy with the output, right? Or with the results, so to speak. So maybe this is another new angle or perspective that people can try to explore, right?
Speaking about the product operating model, I think the word model here is explicitly curated, I guess, right? It's not like a framework. It's not like a process that people have to follow. So tell us a little bit more why you consciously choose to name it a model instead of, you know, like a process or framework.
We actively resist actually creating a process or framework. We instead think about this really at its core level. It's a set of principles. It's a set of things that you hold when you're setting up how your company works, how your product organization works. These are sort of the what we believe. What things are important, what things are more important, what things are less important.
When you start to institute whatever, whether it's processes or things like that, you have to look at them and say, are these actually in service of the principles? One of the things that we have found is that when people get focused on frameworks or processes, then that's what the job becomes. You start to say, well, how well am I executing this process?
Very quickly, you lose sight of what the real goal is, which is bringing value to your customers in a way that works for your business. If you see your job as fulfilling steps in a process, it's very easy to not do what that process was intended to do. It is difficult because many people crave the security of a process like that.
It is a way for people to suspend their judgment a little bit because you can say, you know, somebody can say, hey, look, your product didn't work. It failed in this or that way. You can easily respond, look, I did my job. I followed the process. I followed it better than anybody else. If there's a fault here, it's either the process or somebody else in the process.
Clearly, that's not good for anybody, right? It's not bringing us closer to any sort of goal. I'll take an empirical answer to your question. There are a number of very big processes, like lots of stuff, certifications, and things like that dripping off of this stuff. I'm not going to name them, but I think we all know what they are.
We have yet to find a really good product company that has fully implemented these sorts of processes and is really committed to them. In fact, most of the companies we talk with who have these processes in place are really trying to figure out how to get clear of them because they've noticed exactly the phenomenon that I'm talking about.
As we get into the details of this, one of the actual principles that we name as part of the product model is a little bit of a meta self-referential principle, but it's basically about using the old school Agile X over Y. This is about principles over process. It doesn't mean that there's no process. It doesn't mean that all process is bad, but it means that the principles are much, much more important.
If you put the process ahead of the principles, bad things are going to happen, and you're not in the product model. Very interesting take, right? I think the key thing here is the principles, right? Many transformations, people try to adopt some kind of framework or maybe something advised by some white paper or some consulting companies, right?
Typically, they call it Agile transformation or maybe even DevOps transformation. Some of them are doing that. The key focus is not the practices, the process, but the principles, right? One key thing about this product operating model that you also explained quite clearly in the book is the movement between who actually makes the decision, right?
This mindset shift is very important for people to talk about. Can you maybe elaborate a little bit on the evolution? Traditionally, people use IT, right? The IT model. How does it go to the product model?
Right, right. It's kind of the who's in the driver's seat sort of question here, right? At the beginning, I talked about the typical way things are done, you know, very much command-and-control. Obviously, things are more subtle than that kind of black and white. But generally, within the command-and-control, we have somebody in some very high position.
Or maybe it's a sales person because something has come in from a customer, but it's like we have to build this thing, and then orders are issued, and they'll figure out the best way to build it. That's ultimately what's happening. What we are building is usually coming from another place.
The thing about the product model is, and we have to be careful here because I think some people actually hear a lot of this. They hear a lot of the early Agile concepts as well. They believe that when you're empowering a team, you're empowering them to do everything, right? You're empowering them to figure out what the right thing to build is, figure out the problem they're going to solve, and the right solution to that problem.
That's not it, actually. We have a couple of levels that are going on here. At the level of the individual teams, the solution to a problem is determined by the team, right? That's what it means to empower that team. Given a problem, they will find the best solution.
The whole idea here is that we're setting that team up in a way that they are as close to the problem as possible. They know that aspect of the customer or the technology or whatever it is better than anybody in the company. We're going to give them a problem to solve. We're going to give them some goal that they need to go for, and they're going to figure out the best way to get there.
So that aspect has been removed from leadership and pushed down. But what hasn't been removed from leadership are the problems that we're asking them to solve, right? We want our leaders to create the right sort of context, the understanding through product strategy, through product vision, and ultimately the problems that we're asking the individual teams to solve. That's coming from leadership.
So leadership still has a big, big job to do here. It's not just like, I'm going to hire great people, empower these teams, and just get out of their way. That is not leadership. That is a complete abdication of leadership. So yeah, some things are pushed down, but not everything is pushed down.
I think this thing I rarely see, at least in my experience, right? The team who are not just given the empowerment to actually solve the problem that is given, right? Typically, stakeholders will have some goals, maybe even set with the board of directors, whatever that is, right? They just push it down to the team, okay, we need to build this.
That's a really key importance in this product operating model. The other models I was referring to, you know, like there's an IT model previously where you hand over these kinds of projects to IT people, right? There's a project model as well. Then there's a feature team where you just build features as requested.
If you sell products, typically also like sales or marketing will drive what you build, right? These are some of the different models that are available out there. Maybe let's go deeper into this product operating model, right? Earlier you mentioned the three dimensions: changing how you build, changing how you solve problems, and changing how you decide what problems to solve.
Let's try to go deeper a little bit one by one. What do you mean by changing how you build, right? Because so many teams have different flavors of processes and frameworks. Is there something new that you want to advocate here in changing how you build?
Yeah. This one's the easiest to understand. I'll focus on two aspects of this. One, I think many companies are getting pretty good at, and the other one, maybe not as many, but these are still relatively easy to understand.
To really be working in the product model, the first aspect of changing how you build has to do with how quickly you're shipping. If you are shipping anything less frequent than two weeks, you're probably not there. There's just no way you can iterate fast enough.
We talk about small, uncoupled, frequent releases. I said two weeks; it can be way more frequent than that, all the way to CI/CD. Now, some people freak out on this. A common objection we'll hear is like, look, our customers will revolt. Our releases are these big events; they have to go through training and all of this sort of thing. They won't accept this.
A couple of things to say about that. Just because you are building and integrating and have something ready doesn't mean you have to actually make it visible and turn it on right away. If you do have a cadence that you need to be following in order to line up with your customer's operational requirements, there's no reason you can't do that.
But we still do need to be building and integrating much, much faster. The truth is there are a lot of things that you probably do want to fix with the customer a lot faster than quarterly or monthly, whatever it happens to be. Things that they might not even see, those sorts of things.
It actually just works much, much better for things like regression testing, you know, things like just the complexity of these sorts of builds. That's the first thing. There's no real new news there. Agile has been saying this for a long time, and many people get this.
The other one, though, goes back to what I was saying about the primacy of outcomes in the product model. What this basically means is that anything that you ship, anything at all really needs to be instrumented. You need to be understanding not just the typical stuff that a DevOps group is going to be worried about, you know, uptime and response time and all of that sort of stuff.
You need to be instrumenting usage. You need to be instrumenting adoption. You need to be instrumenting retention or engagement, you know, whatever these things mean for your particular product. Because, in all likelihood, the outcomes that you're driving to are very dependent on knowing that information.
So you have to instrument it. The flip side of instrumenting is somebody has got to be looking at this. You've got to be actually operationalizing that aspect of things; your overall data IQ within an organization is going up. Those are really the two things.
So small, uncoupled, frequent releases, and then the instrumentation and monitoring. Basically, there are a few other things we talk about there, but those are the main ones.
I think small, uncoupled, frequent releases. So much literature or resources already cover that. The Agile, the DevOps, the Accelerate book, right? State of DevOps report. It's quite clear that you have to release frequently, right? If not all, every commit, right? So going to the continuous delivery model.
But the second one, instrumentation, I think some teams actually still don't have this kind of mindset. Maybe practices are abundant as well, right? Many techniques and tools are available. But I think some teams are still falling back into a reporting model, you know, like the way they kind of measure the outcome is actually by doing some kind of reporting, data warehouse, or querying the database, right?
Why do you think instrumentation is a much better approach than those approaches?
Yeah, you mean the monitoring, right? Instrumentation and monitoring, I think is what you mean. It's because the teams have to be responding very, very quickly. In those reporting-based cultures, a lot of that has to do with how data is dealt with organizationally.
Sometimes it's a group that might be in finance or some other area of the company. They're often set up as an agency, right? A service bureau. You put queries in, and you put some job in, and it's a first-in-first-out sort of thing. They get to that queue when they can.
You end up with reports and analysis, and everything is very slow. When we're talking about monitoring here, we're talking about deeply operationalizing this. You want to put this all the way into the level of the teams. The teams are, you know, what they need to know on any given day is probably going to change really, really quickly.
That's really what we're talking about here. It's about speed and responsiveness for data and inquiries about data or reports on data, you know, whatever it happens to be.
I think this also fits into the next thing that you advocate people to change, right? So I'll just jump a little bit. Changing to decide what problems to solve, right? Because maybe the instrumentation here will also feed into what kind of problems that you decide to work on next, right?
So tell us about this dimension, changing how we decide what problems to solve.
Yeah, so there are a few things we can focus on here. This is a big one, by the way. While we didn't really use this language before, this is largely what the Inspired book was really covering. A couple of big ideas here.
The first one has to do with the unit of who is executing on the work, right? The unit of organization, you know, these fighting units, right? The idea of a small cross-functional product team is here. Small is, you know, Bezos calls them the two pizza teams, you know, something that if it's too big to be fed by two pizzas, it's probably not a product team.
What we have is a small collection of engineers, maybe 2 to 10-ish who are dedicated to the team. We've got a dedicated product manager on that team. If there is any sort of experience to be had, there is a dedicated designer on that team. These are all the core competencies within the product model.
I haven't really mentioned that yet, but I'm sure we're going to get into that also. Really how that team works together cross-functionally, the fact that we're really shifting kind of the political units, right? It's not the functional groups. It's not like here's product management, and they're all together, and they do their thing, and then they pass stuff to design, and they're all together, and they do their thing.
Then it gets passed to engineering. We're really trying to put these people together and have them collaborate on a near-continuous basis. That's one big aspect of this dimension.
Another big aspect of this dimension really has to do with how work is allocated to those teams. As I mentioned before, are you asking them to build a solution or are you asking them to solve a problem? When you give them a problem, you're not giving them a solution. It's on them. They're going to figure out what the best one is, and they're going to have to test out a lot of things.
That's kind of the second thing is around what are they accountable for. Are they empowered to actually deliver on what they're accountable for? This ultimately leads to this idea of product discovery, right?
Imagine you're on a team that is being asked to solve a problem rather than to build a solution. You need to reduce the amount of time it takes to onboard a new customer. We've determined on average it takes this long, and we need to cut that in half, right? There's no solution in there. It's a problem to be solved.
There's a pretty clear way of measuring how effective a solution is going to be. If you're on a team like that, I don't know about you, but I think you'd be crazy to just start building something, right? Somebody's got an idea. Oh, yeah, we'll do that. Okay, let's go spend all of our engineering budget and build that thing and just hope, you know, we'll cross our fingers and hope that that works.
That'd be a crazy way to work. This is really where product discovery comes in, and it's about how do we test solutions in a really cheap way and kind of vet them along all sorts of dimensions as to what's actually going to work. See ultimately what the best way to proceed is in order to solve that problem.
When we talk about changing how you solve problems, those are really kind of the big ideas that are in there.
Right. I think when you speak about building something, testing the ideas in the cheapest way, right? Many people are still not doing this, I believe, right? Because again, they are driven by a typical features or typical roadmap that they have to meet, right? Many engineers also do not habitually fall into this kind of experimentation mode, right?
They just build something that maybe is not perfect, and maybe it has lots of technical debt. But then what happens is after it gets rolled out, right? It never gets refactored again, never gets rebuilt. So tell us how this experimentation is something that people can try more, right? What kind of mindset shift can they do in order to do this kind of approach more?
Right, right. Well, you're right in identifying one of the big differences. You know, you use the term feature team before to contrast it with this empowered product team that I've just been talking about. A feature team is one that's given a roadmap or given things to build, and then they go about doing it.
If that is how you're being measured, if those are the tasks that you're being given, then discovery makes no sense. I know a lot of companies and teams try and do a little bit of discovery because they know they need to be doing a better job. But ultimately, their operating model is fighting them.
There's no incentive to do this. In fact, there's a disincentive to doing it because it's just time you're not spending working toward the output that you're being held accountable for. I don't fault teams for not really understanding discovery or just not even trying to do it because it just doesn't make sense given where the incentives are in the model that they're working in.
Now, if you truly are in an empowered team... You were asking about engineers specifically. When we get into the details of the model, discovery is not engineering's day job. We want them participating. In particular, the tech lead, you know, that is somebody who at least some of their time they'll understand will be related to discovery.
Some engineers might participate in it more than others. Some may be craving it right now. Some may be when they start realizing that they're responsible for outcomes, they're going to be naturally led to it. There will be some engineers out there who say, I don't want anything to do with that. Just tell me what to build, and I want to build it.
That's fine, right? I think there's a place for all of these, but we do want at least some engineers in those first two categories on our product teams. The main reason is they are by far the single best source of ideas for solutions. They know what is technically possible in a way that nobody else in the company does.
The product manager doesn't. The leaders don't. The salespeople don't. Even the customers don't, right? They don't know what's possible. All these folks might have some ideas of solutions. They know what the problems are, but they don't know what can be done right now.
I would say that some engineers are inspired when they hear this and realize, yeah, okay, I really am quite good. This is one of the things I really try and dispel with my customers is this old adage that is so pervasive of, okay, you know, you're product, you're the what and the why, and we're engineering, we're the how.
No, right? We're missing the point here. We really want to bring engineering into that. Maybe not the why, right? The why is going to come from leaders. But we definitely want them part of the conversation on the what, either refining ideas that are coming up or, in many cases, generating some of those ideas.
Thanks for raising the importance of engineers in this process, right? I think Marty previously also mentioned about this. He mentioned like if the engineers in your team are there just to code, you kind of like utilizing them 50 percent of their capability, right?
Because engineers know what kind of potential solutions that people can build, right? What technology can bring into this kind of innovation, right? I think definitely involve engineers more into, you know, not just the implementation of things, but also the design, the discovery, and things like that.
You mentioned a few times about empowered teams, right? Empowerment. I think this goes back also to the trust, right? Because if you just want to leave a team with a problem to solve, definitely, there's a big trust that they can do it, right?
So tell us how leaders can put a lot more trust into such teams, right? How can the team actually also take the trust and do it?
Right, right. Yeah. One of the biggest things that I see, you know, when I'm... Say, I'm talking to teams and I describe this whole idea of empowerment. They will often say to me, can you please go talk to the stakeholders because we need them to know that they can trust us to do this?
My answer is usually, yeah, we're talking to stakeholders too, but you have to understand you need to be in a place where you are worthy of being trusted. Right now, I'm going to guess that they know a lot more about the customers than you do. Right now, I'm going to guess that they know a lot more about the business than you do, and kind of what makes for a viable solution.
You have to be worthy of their trust. You have to be in a position that you're not just going to be firing crazy ideas over at them that are just going to be dead on arrival because you didn't understand the context well enough. That's a really, really big angle on the whole thing.
In fact, with companies that I'm working with, that's often the first problem that needs to be solved. The product managers, the product teams, the designers, the product organization as a whole needs to up its game in terms of how well it understands the customers, how well it understands the data.
How well they understand the viability to the business, the regulatory environment they're playing in, all those things I mentioned before. The partnership requirements, what does their go-to-market look like? How can the sales force actually cope with the things that you're actually suggesting?
You have to up your game even before we really start talking to the stakeholders. So yeah, that's basically where we start on that trust side of things.
I think that's a very big key insight for me, right? Because there are so many teams, like when we talk about empowered teams, they just put it to the stakeholders, yeah, give us more trust. But I think what you mentioned is really important, right?
Sometimes the team also doesn't know fully inside out about what's happening with their product, why they do solve a certain outcome, right? This is a really key point for any team who listens. To be empowered, you need to be worthy of that trust, right?
Naturally, if you are an expert in all this, right, the leaders will naturally give you the trust. I fully believe in that.
Yeah, exactly. It's more than that too because they'll begin to start to value your ideas. Especially if you've been successful in bringing some engineers along for this journey as well. You're going to start having ideas that the organization was not capable of generating before.
When that starts to happen, not only are the stakeholders trusting you, but they're actually looking to you to partner and for guidance.
Let's move to the next dimension, which is how you prioritize things, right? Is there anything here that we can learn as well?
Yeah, I went through this one a little bit more, I think on the first pass. But just to, you know, at the risk of retreading a little bit. Typically, how things work is we've got a lot of stakeholders who have a lot of concerns, a lot of things they need from the technology organization.
The technology organization or the product organization really looks at this as a giant prioritization task. We've got so many resources. We've got so much stuff that we're being asked to do. The way we're going to deal with this is figure out how to peanut butter things a little bit.
We're a bit little here and a little here and a little here. We're going to make as many of these people as happy as we possibly can. If you take a step back, maybe you've made a bunch of stakeholders somewhat happy. None of them are probably going to be that happy.
If you take a step back, it's really just a bunch of cockroaches skittering around in a lot of different directions, right? There's nothing coherent here in what's been built. When we talk about changing how you decide what problems to solve, this really is fundamentally about creating a strategy that's going to focus the work.
One of the punchlines of this whole thing is that not every stakeholder is going to be happy necessarily, right? There is a subtle power shift that's going on here. It's not that the stakeholders have no say. The product organization is absolutely partnering deeply with these stakeholders.
The product organization needs to understand to a pretty sufficient detail what the implications of all of these decisions are. But at the end of the day, they have to focus. They have to say, look, rather than working on 60 initiatives, we're going to have to call this down to a small number of focus areas.
Some of these things that we can't focus on now, we'll get to later. But right now, if we're focusing on everything, we're focusing on nothing. That's really the main thing that this is about. It can often be the most tricky.
When a company is transforming, to kind of go back to those three dimensions, changing how you build is relatively uncontroversial when we talk about the rest of the organization. It's like, you guys do you, right? You're the product organization. It's the engineering. We don't know about that stuff anyway.
If it's going to run faster and more predictably, I'm for it, right? Let's go. Changing how you solve problems, we are now changing the interface between our stakeholders and the teams themselves. The unit of work that we're communicating is a problem, as opposed to a solution.
So there's some broader education that needs to happen there. This one's even bigger though because this is starting to say, okay, the stakeholders have their collection of things that they all believe are very important. We are centralizing the decision on what the most important things actually are going to be, what we are actually going to focus on now, and what we're going to say no to right now.
There's a big change that actually has to go on on that particular dimension.
Yeah, I fully believe this one is probably the trickiest, right? Because you will upset some of the stakeholders, right? In many typical teams, right? You have, I don't know, like you have the CEO to report to, you have the IT side, the CTO, you know, engineering has its own roadmap.
You probably have a compliance or security aspect as well, where you have to comply with certain things and maybe different other stakeholders like marketing, sales, or whatever, right? These are key challenges. Every stakeholder has their own roadmap as well.
How do you build such a unified product strategy, you know, a product vision that the team can actually get more clarity in terms of focus, right? Rather than trying to spread their focus into so many different areas. How could the stakeholders also come with a unified vision?
Yeah. There's no easy way through this one, right? This is messy. But, you know, I would say that if you're going to start from the point of view of 20 stakeholders with 20 roadmaps and trying to rationalize that, that's probably not going to end well.
You're going to want to start the partnership between the stakeholders and the product organization much, much earlier than that. It means that the product organization needs to be understanding the business challenges, the business constraints, the things that are going on within all of these areas quite early as a product strategy is being crafted.
Rather than it being kind of outside in, business to product, and then they rationalize everything, it probably needs to be coming a bit more inside out, you know, with the partnership and then tuning it up. But really that's going to be up to individual companies and how they go through and do planning and how their organizations are set up.
My hunch is if I ran into a company that, and I ran into many that work the way that you're describing, I would probably coach them that it's going to be very difficult getting there by modifying what you're doing right now. Just the way information is flowing, the way status is set up, your product organization really has no choice but just to respond to all of this stuff coming in.
As opposed to truly generating a point of view and a focus that is going to hopefully work for as much of the business as possible.
Yeah. So I think I can feel the pain of so many product teams out there, right? They have to answer all these things. What you mentioned, I know it's very difficult to do, but it comes back to the top, right? How the leaders, maybe the CEO sets the direction for the company, right?
If they still operate in this way, where each of the stakeholders has their own roadmaps, I think it's kind of difficult, right? This brings me to actually the importance of the role of the leaders or the CEO. How can they drive this product operating model to be a successful transformation within their company?
Yeah. I'm going to divide this into two categories of people. They're both very important, but I look at them a little bit differently. There's the CEO, and then there are the leaders within the product organization. The most senior product managers, you know, the CPO or VP of product, and the same on the engineering side, CTO, VP of engineering, the design, you know, those are the ones that are the true product roles.
We'll call those all product leaders, even though it's not just product management, right? We'll call those all product leaders. In terms of... Let's take them one at a time here. So let's start with the product leaders. Usually, a product model transformation is driven from that organization. Not always, but it's usually driven from those most senior people there.
They are going to need to ensure that there's alignment and that there is the ability to operate this way, you know, amongst the leaders. They need to understand what it means to create a true product strategy and a product vision, and how to empower teams and hire the right sort of people who know how to work in a model like this.
In the case of the CEO, the CEO is not going to be somebody necessarily who is planning the transformation or even driving the transformation, but they are a very key player. They need to absolutely be informed as to what's going on, and they need to be seen broadly as an advocate and an evangelist for it.
Without that, you're really going to have a very hard time getting the product model to be adopted and considered outside of the product organization. There's nothing that can really compel these stakeholders to do this, to work this way. The only thing that could is somebody who sits above both groups, which is usually the CEO.
It is something that we really look for early in a project. We don't necessarily look to see, okay, is the CEO bought in right now? But if there's no path to them becoming a real advocate for this whole thing, we usually don't work with companies like that. Just because we kind of see where it's going to end up there.
They may get some benefits out of the product model, but they're really only going to be able to go so far.
Yeah, I think the transformation typically has to start. The champions must be from the top, right? If you are doing it in a departmental silo aspect, I think typically you will hit some kind of ceiling, right? It could turn into political things as well, right?
Sorry, if you don't mind, I'll just go ahead and say that one of the biggest things that I look for in companies that are looking to do this is truly how serious I think they are. If there is not a real high-level buy-in yet, the risk for them is not that they're going to waste a lot of time and money, you know, engaging with an outside firm to help them understand what the product model is.
The real risk is they're going to get their best people really excited about working this way. Those very same people are going to learn within a few weeks or months that their company is not serious about doing this, and then they're going to leave, right? They're going to go look for a company that is serious about doing this.
It's something that we take very, very seriously.
Right. So you mentioned a few things about competencies, right? You mentioned something like product manager, product designer, tech leads, and engineers here. Are there any other competencies that people need to put in the cross-functional teams? How about the role of coaches, right? How can the team get upskilled into this kind of thinking?
Yeah. We've been talking most of this session about the principles around the product model. It really is about principles, but it is also about some competencies. You mentioned some of them here. We talk about four in the book, and this isn't to say that these are the only titles in a company and that you can fire everybody else.
It's not that at all. It's just that there are four really key core competencies to making this work. Oftentimes, even though companies have these job titles in the company, they may not have the competency, right? They may not actually have product managers, for example, who work this way, the way that we talk about here.
So product management is one. Product design is another one. We go into a lot of detail as to what product design really looks like in a company like this. We also call out the tech lead, which is usually one, you know, it's sort of a role distinction given to at least one engineer on each of the product teams that we're talking about.
Now we've got a lot to say about engineers broadly, but I think, in passing, I mentioned that there is at least one engineer on every team whose job is about product discovery. It's not just delivery. You can have more engineers who are interested in product discovery, but we're going to mandate that there is at least some energy like that.
So that's the third competency is around the tech lead. The fourth competency that we call out are the product leaders. Basically, the managers and leaders of those three disciplines that I just mentioned. If you are a director, VP, you know, senior manager, whatever it happens to be of any of those sorts of things, that is a core competency as well.
How we expect those people to work with empowered teams is typically a different set of skills than what traditional leaders in a command-and-control organization look like. Now you asked about other roles, and there are many. Some of which are associated directly with product teams, you know, embedded in the same way that those other roles are.
In some cases, they work outside of the product teams, maybe supporting multiple product teams. In some cases, it might actually be a completely separate role. Many of the roles that we talk about are, you know, there is a flavor of program management or project management that happens. There are data analysts. There are product marketing managers.
You may have Agile coaches or even discovery coaches, you know, so there are a lot of other roles that can be there. Again, I don't want to imply that those aren't important jobs. But just in terms of the real fundamentals of the product model, we focused on those four.
Right. So I think when you mentioned tech leads, one of their core roles is to do product discovery. I think that's a really, really big difference, right? Because many tech leads assigned to the team typically will just focus a lot on the technical aspects, like the quality attributes, the design, the architecture, the reliability of the system, but rarely touching into the product discovery aspect.
That's why I said before that many companies have these job titles, but they don't have the competency the way that we're talking about. We find that it's good to be really overt about this particular one because it just emphasizes the importance that the role of engineering plays in product discovery.
Thank you for elaborating so many things, you know, the principles that people need to think about the product operating model, right? I think the book, I highly recommend that. All the books from SVPG are typically really insightful, right? Including this one.
If you want to try to transform your organization, if you think your company does not operate in the way that Chris mentioned or elaborated earlier, please do check out this book. There are a lot of insights that you can learn. Also, don't forget to give it to your leaders as well, right?
This kind of transformation will not happen just within your team. The management, the executives, and the product leaders, they all have to agree to these set of principles so that their transformation can be more successful.
As we go into the end of our conversation, I only have one last question for you. I call this three technical leadership wisdom. If you can think of it just like advice to anyone, you don't have to be technical. You can also think from it from the product side.
What will be your leadership wisdom here?
Yeah, so you had sent me this a little bit earlier, and I was deciding what level to come in here. Whether it's the high-up leader who's kind of running a department or running a function or say somebody who is more like a manager of a small number of people.
Unless you have a preference, I'll start on the lower side of things just because there's some fun hacks here, and I'll see if I can get through them really quickly. One of the tricky things that I found was helping somebody become a manager for the first time. There was a technique used on me when I became a manager for the first time.
Basically, my manager told me, who I'm becoming a new manager. This new person that you've hired, they need to understand that they need to know more about whatever product you're giving them or whatever aspect of the product they're giving. They need to know more about that than anybody else in the company.
And Chris, that includes you. The other thing that my manager said is that this new person needs to get a public win in the company within the first 45 days. They need to be able to stand up in front of the company and take a bow for something that they did.
The brilliance of this advice was it really encouraged me to step back in a way that allowed this person to step forward. I needed to allow them to be smarter than me on something. I needed them to take a win for something I probably engineered and really was behind the scenes pulling all the strings on.
This was just such powerful advice for me, and I've passed it on to every single person that has worked for me that was becoming a new manager. So there's one. The second one has to do with overcoming a fear, right? You're trying to coach and develop somebody who's not done something, and they're a little bit trepidatious about it.
I'm calling this the rule of six. I stumbled on this. I didn't invent this through some great wisdom, but I just observed it because it kind of happened to me accidentally. It was actually when I first joined SVPG doing my first two-day on-site workshop. I was terrified.
I've done plenty of public speaking, but I'd never run a room of 65 people for two days straight all by myself. The thing that happened was just purely accidentally, I signed up for six of these before I had done one of them. That interestingly reduced stress. You'd think it's a paradox, right?
You'd think that would create this huge stress. But what it did is it took the pressure off of each individual one. Basically, I could look at it and say, all right, I'm going to do six. They're not all going to be great. One might be great. These other ones might be in the middle.
It took a lot of that pressure off of the very first one. So that's another thing that I've helped people, you know, it's, you just got to coach them through that but just realizing that it is actually more comforting to sign up for many things and do them all and treat it as one big group.
The third one, this is a little less profound, but just as a manager, like a first-level manager, I got a lot of value out of having people create pie charts on how they spend their time versus how I would like them to spend their time.
It's not one of these things like you account for every minute of what's going on. It's like, you know, at the end of the week, I want you to create a pie chart. You can choose from these categories. Do it; you can look at your calendar, but what is it?
It became a very, very powerful tool for helping, first of all, understand how people were actually spending their time and then to have a conversation on, okay, how I'd really like this pie chart to look. This slice is too big, and how can I help you make it smaller? This slice is non-existent. We really need to be able to get this one up.
Just by looking at the percentage of your time, I think that's an incredibly powerful tool as well. So yeah, hopefully that helps. Those are the three kind of maybe hacks, management hacks.
I find all of them very profound, right? These are really great things for, especially not just first-time leaders, right? All leaders can actually learn from these hacks, right? The first one is about helping someone to become a better manager.
I would say a better manager because even some managers who have been around, right, they don't understand this aspect, right? Stepping back and letting others shine, right? Taking the credit. The second one is about overcoming fear, right? Do more.
I think we all say if it's painful, do it more often, right? I guess you can treat it the same thing. The last one is about thinking at the end of the week, probably, or the end of the cycle, whatever that is, right? How much time or energy you spent each time and how the shape was, right, and what would you like it to be in the next iterations.
Thank you so much, Chris, for elaborating all this. If people want to connect with you or they want to ask you more questions, is there a place where they can find you online?
Yeah, the best place is probably the SVPG website, so Silicon Valley Product Group, which is svpg.com.
Right. So I'll put that in the show notes. Thank you so much, Chris, for your time today. I hope people learn a lot about the product operating model and they are able to adhere to these principles in their own team.
Thanks, Henry. I had a lot of fun.