#185 - The Transformed Organization: A Blueprint for Moving to the Product Operating Model - Chris Jones

[00:01:22] Introduction

Henry Suryawirawan: 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”. So if you still remember Marty Cagan, he actually appeared in episode 102 before. This Transformed is actually one of the series in SVPG book. So 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 to be here to actually talk more about the book. So welcome to the show, Chris.

Chris Jones: Thanks, Henry. Great to be here.

[00:01:56] Career Journey

Henry Suryawirawan: Right. Chris, I always love to ask my guests first to maybe tell us more about yourself, right? So if you can maybe mention any highlights or turning points that we can learn from, I think that will be great.

Chris Jones: 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 worked for a developer for a bit. Did a little bit of work at Microsoft and then another startup. And 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, you know, certainly 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, you know, that sort of thing. So I actually abandoned that.

And 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 and a producer and a videographer on some documentaries and a little bit of music video work. And it was kinda around the mid nineties that work led me into kind of 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.

And so I ended up actually starting a small company, basically, to work in that space. And 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. So we were very… actually, let me talk a little bit about what the company did. 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. And we were working with all sorts of companies and we had about a third of the employees were product managers, a third were designers, a third were engineers. And, you know, worked with a lot of companies doing a lot of pretty cool stuff at the time. This incidentally actually is where I first met Marty Cagan, who you mentioned before, the author of these books and the founder of Silicon Valley Product Group.

But anyway, 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, big B2B sort of thing, we actually really kind of defined a new market within information security. The company was purchased by Symantec, worked for a while across their enterprise portfolio. And 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 here, where I am. I was with them for about five years and learned a whole new set of things, you know, very, 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. And 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.

[00:05:40] Moving Into Product Management

Henry Suryawirawan: Thanks for sharing your story. So one thing that I’m really interested in, so because I think quite a number of engineers may also think that maybe that is not their career, right? And for you, you switch into product managers now. So maybe if you can advise those engineers who probably are thinking of switching the lines, what will be some of the, I don’t know, key traits or key signs for them to think about moving into product management?

Chris Jones: 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. You know, if you’re an engineer, you’ve been living mostly in the technology, you know, mostly in the what’s possible, mostly in the how things are put together. But, you know, actually 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, you know, being curious about those things. Or how does it actually work with the business? You know, not just the money making side of things. You know, are there regulatory concerns? Are there brand concerns? Are there partnership concerns? If you find yourself curious and interested in all of, you know, in that entire problem space, then product management is probably, you’re going to resonate really well with that because that’s what good product managers are concerning themselves with. All of those sorts of topics.

[00:07:13] Key Theme of “Transformed”

Henry Suryawirawan: That’s a very key point, right? So get curious, not just in terms of technology, right? Also in the business, in the customer value, and everything else, right? So I think today’s topic is definitely touching around those things as well. So the book titled Transformed, which is quite recent, right? So Moving to the Product Operating Model, that’s the subtitle. So maybe in the first place, I know that SVPG has come up with, I think, at least four books by now, right? So the first three books, Inspired, Empowered, and Loved. So tell us why another book?

Chris Jones: Yeah, it is interesting. I mean, there’s been a real progression here. We started with Inspired. And Inspired really was about capturing the best practices of what was going on within individual product teams. And we have kind of 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. And Inspired goes into, you know, 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? And the book was a big hit.

And there were, you know, a lot of companies out there saying, yeah, you know, 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. And because the rest of leadership within the broader product organization didn’t know how to create that sort of environment. And that really led to that second book, which was called Empowered. And it is also scoped, you know, 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.

So quick detour. Loved is on a slightly different path. It’s a bit, you know, whereas Inspired and Empowered and then now Transformed really lives 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. So that’s really what that book is about. And 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.

But back to Transformed is sort of the next level here is like 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? Because 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. You know, 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, you know, it’s about a framing that allows you to bring these ideas to the entire organization. And I’m sure you’ve seen kind of transformation is sort of the big thing that a lot of these companies are talking about. And really 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?

[00:10:39] Product Operating Model (POM)

Henry Suryawirawan: Right. When we speak about transformation, right, 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? So what do you think is the difference between this transformation against like all the other transformations that some companies are already embarking?

Chris Jones: Yeah, well, so we really come at this on kind of three dimensions. And other models out there might’ve approached parts of these dimensions, you know, they’ll focus in particular areas. But the product model, we haven’t really even defined what that means. And I’m guessing that we’re going to get into that, what some of the details are. But at the end of the day, what it really has to do with is operationalizing outcomes. So what we’re looking to do and to draw a very stark contrast. You know, 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. And then hopefully good stuff happens later.

There are various flavors of operating that way. And we generally associate that with output based models. You know, 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. Then it’s like whether or not that thing succeeds, that’s really the responsibility of the people who asked them to build this particular thing.

And there’s all sorts of attendant badness, a lot of just a horrible track record of things. When you build things that way, there’s just a horrible track record of them working at all. You know, customers don’t adopt them or there were things missed along the way and they realized 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? And everything is organized around that. And 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. So, you know, 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, is it actually, you know, are people using it? Is it generating the revenue that we thought it was going to generate? All of those sorts. And that’s how they’re measured and that’s how they’re measuring themselves.

So 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. And by the way, there’s a lot of overlap with many of these models. But, you know, 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, you know, 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, the second big dimension 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? And when you move things to outcomes, there’s a lot of other stuff that tracks after that.

And then 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. You know, 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. And 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.

So that was a relatively long answer and kind of getting at the the top level of how the product model is organized. And as I said, and 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, you know 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.

Henry Suryawirawan: So thanks for elaborating a little bit more about how this product operating model works and also like how it compares with others, right? So I’m sure like 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 that maybe this is another new angle or perspective that people can try to explore, right?

[00:15:52] Model, Not a Framework

Henry Suryawirawan: Speaking about product operating model, I think the word model here is explicitly curated, I guess, right? So it’s not like a framework. It’s not like a process that people has 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.

Chris Jones: 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. You know, what things are important, what things are more important, what things are less important. And 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, right? You start to say, well, how well am I executing this process? And 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. As if you see your job as fulfilling steps in a process, it’s very, very easy to not do what really that process was intended to do. And 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, you know, your product didn’t work. It failed in this or that way. And you can easily respond, look, I did my job. I followed the process. I followed it better than anybody else. So if there’s a fault here, it’s either the process or somebody else in the process. And clearly that’s not good for anybody, right? It’s not bringing us closer to any sort of goal.

And, you know, 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. And 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, you know, one of the actual principles that we name as part of the product model. It’s a little bit of a meta self referential principle, but it’s basically, this is about kind of using the old school Agile X over Y. This is about principles over process, right? 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. And if you put the process ahead of the principles, bad things are going to happen and you’re not in the product model.

Henry Suryawirawan: Very interesting take, right? So I think the key thing here is the principles, right? So I think many transformations, people try to adopt some kind of framework. Or maybe something advised by some white paper or some consulting companies, right? And mostly are process-driven, framework-driven, and practices-driven, you know. I think typically they call it Agile transformation, or maybe even DevOps transformation. Some of them are doing that. But I think the key focus is not the practices, the process, but the principles, right?

[00:19:28] The Driver’s Seat in POM

Henry Suryawirawan: And I think 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? So I think this mindset shift is I think is very important for people to talk about. So can you maybe elaborate a little bit of evolution? Like traditionally people use IT, right? IT model. And how it goes to product model.

Chris Jones: Right, right. It’s kind of the who’s in the driver’s seat sort of question here, right? So, yeah, you know, at the beginning I talked about the typical way things are done, you know, very much command-and-control and, 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, because something has come in from a customer, but it’s like we have to build this thing and then, you know, orders are issued and they’ll figure out the best way to build it. But that’s ultimately what’s happening. So 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 actually a lot of the early Agile concepts as well. And 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. And it’s like, that’s not it, actually. So really, we have a couple of levels that are going on here.

At the level of the individual teams, the solution to a problem, that is determined by the team, right? That’s what it means to empower that team. Given a problem, they will find the best solution. And 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. So we are 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, so some things are pushed down, but not everything is pushed down.

Henry Suryawirawan: Right. I think this thing I rarely see, at least, even in my experience, right, the team who are not just given the empowerment to actually solve the problem that is given, right? Because typically, like stakeholders will have some goals, maybe even set with the board of directors, whatever that is, right? And they just push it down to the team, okay, we need to build this. So I think that’s a really, really key importance in this product operating model. I think the other models I was referring to, you know, like, there’s an IT model previously where you, hand over these kind of projects to IT people, right? There’s a project model as well. And then there’s a feature team where you just build features as requested. And if you sell products, typically also like sales or marketing will drive what you build, right? So I think these some of the different models that are available out there.

[00:23:00] Changing How You Build

Henry Suryawirawan: Maybe let’s go in deeper into this product operating model, right? Earlier you mentioned the three dimensions, right? Changing how you build, changing how you solve problems, and changing how you decide what problems to solve. So maybe let’s try to go deeper a little bit one by one. So what do you mean by changing how you build, right? Because like 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?

Chris Jones: Yeah. This one’s the easiest to understand. And you know, I’ll focus on two aspects of this. And one, you know, I think many, many companies are getting pretty good at. And the other one, maybe not as many, but you know, these are still relatively easy to understand. So, 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. And if you are shipping really anything less frequent than two weeks, you’re probably not there. There’s just no way you can iterate fast enough. And there’s a whole set of other problems that come along with this. So we talk about small, uncoupled, frequent releases. And 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. And, you know, 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. And a couple of things to say about that, you know, number one is there are many things that… Well, let’s do it this way. 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. So 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, you know, monthly, whatever it happens to be. Things that they might not even see, those sorts of things. But also it actually just works much, much better for things like regression testing. You know, things like just the complexity of these sorts of builds. So 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. And what this basically means is that anything that you ship, anything at all really needs to be instrumented. And which, you know, 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, you know, in all likelihood, the outcomes that you’re driving to are very dependent on knowing that information. So you have to instrument it.

And then the flip side of instrumenting is somebody has got to be looking at this. And you’ve got to be actually operationalizing that aspect of things, your overall data IQ within an organization is going up. So those are really the two things. So small, uncoupled, frequent releases, and then the instrumentation and monitoring. Basically, there’s a few other things we talk about there, but those are the main ones.

[00:26:37] Importance of Instrumentation & Monitoring

Henry Suryawirawan: Right. I think small, uncoupled, frequent releases. So many, you know, literature or resources already cover that. The Agile, the DevOps, the Accelerate book, right? State of DevOps report. So I think 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, yeah, some teams actually still don’t have this kind of, I don’t know, mindset. Maybe practices are abundant as well, right? So many techniques and tools are available. But I think some teams are still falling back into reporting model, you know, like the way they kind of like measure the outcome is actually by, I don’t know, like doing some kind of reporting, data warehouse, or querying the database, right? Why do you think instrumentation is much better approach than those approach?

Chris Jones: 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. So, you know, in those reporting-based cultures, a lot of that has to do with how data is dealt with organizationally. You know, sometimes it’s a group that might be in finance or some other area of the company. They’re often set up as as an agency, right? A service bureau. So, you know, you put queries in and you put some job in and it’s a first-in-first-out sort of thing. And they get to that queue when they can.

And so you end up with reports and analysis and everything is very slow. Really 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. And so 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.

[00:28:27] Changing How You Solve Problems

Henry Suryawirawan: Right. 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 feeds into like 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.

Chris Jones: Yeah, so there’s a few things we can focus on here. This is a big one, by the way, you know, while we didn’t really use this language before, this is largely what the Inspired book, that was really the territory it was really covering. So I’d say a couple of big ideas here.

You know, 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? So the idea of a small cross functional product team is here. And 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. But 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. And 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. Haven’t really mentioned that yet, but I’m sure we’re going to get into that also. So 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’re do their thing, and then they pass stuff to design and they’re all together and they do their thing. And then it gets passed to engineering. We’re really trying to put these people together and have them collaborate on the near continuous basis. So 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? And 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. So it’s… That’s kind of the second thing is around what are they accountable for. And are they empowered to actually deliver on what they’re accountable for. And then this ultimately leads to this idea of product discovery, right?

So 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. You know, 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. And a pretty clear way on 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? You know, somebody’s got an idea. Oh, yeah, we’ll do that. Okay, let’s go spend all of our engineering budget and we’ll 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. And see ultimately what the best way to proceed is in order to solve that problem. So when we talk about changing how you solve problems, those are really kind of the big ideas that are in there.

[00:32:03] Product Discovery & Experimentation

Henry Suryawirawan: Right. I think when you speak about building something, testing the ideas in the cheapest way, right? So many people are still not doing this, I believe, right? Because again, like they are driven by a typical features or typical roadmap that they have to meet, right? And I think many engineers also not habitually fall into this kind of a experimentation mode, right? Where 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? Like what kind of mindset shift that they can do in order to do this kind of approach more?

Chris Jones: 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. Like discovery is going to be a waste of time. And, you know, 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. So, you know, 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, you know, 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. And really when we get into the details of the model, discovery is not engineering’s day job. We want them participating. And 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. And some engineers might participate in it more than others. And some may be craving it right now. Some may be when they start realizing that they’re responsible for outcomes, they’re gonna be naturally led to it. And then there’ll be some engineers out there who say, I don’t want anything to do with that. Just tell me what to build and I wanna build it. And 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.

And 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, you know, the product manager doesn’t. The leaders don’t. The sales people 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. So, you know, I would say that some engineers are inspired when they hear this and they realize, yeah, okay, I really am quite good.

But this is, you know, 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? I mean we’re missing the point here. You know, 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.

Henry Suryawirawan: So thanks for raising about the importance of engineers in this process, right? I think Marty previously also mentioned about this, right? 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? So 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.

[00:36:10] Empowerment & Trust

Henry Suryawirawan: And you mentioned a few times about empowered team, 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 will the leaders be able to put a lot more trust into such teams, right? And how the team can actually also take the trust and do it.

Chris Jones: Right. right. Yeah. So 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. And they will often hear like, okay, they’ll 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? And 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. So 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. So that’s a really, really big angle on the whole thing.

And in fact, with companies that I’m working with, that’s often the first problem that needs to be solved is that 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. You know, how well they understand the viability to the business, the regulatory environment they’re playing in, all those things I mentioned before. You know, the partnership requirements, what is their go-to-market look like? How can the sales force actually cope with the things that you’re actually suggesting? So you have to up your game in, even before we really start talking to the stakeholders. So yeah, that’s basically where we start on that trust side of things.

Henry Suryawirawan: Right. I think that’s a very big key insights for me, right? Because there are so many teams, like when we talk about empowered team, they just put it to the stakeholders, yeah, give us more trust. But I think what you mentioned is really important, right? Like 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? So I think this is a really key for any team who listen. To be empowered, you need to be worthy to be given that trust, right? So I think, naturally, if you are expert in all this, right, the leaders will naturally give you the trust. I fully believe in that.

Chris Jones: Yeah, exactly. It’s more than that too, because they’ll begin to start to value your ideas. And 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. And you know, when that starts to happen, not only are the stakeholders trusting you, but they’re actually looking to you to partner and for guidance.

[00:39:21] Changing How You Decide What Problems to Solve

Henry Suryawirawan: Right. Let’s move to the next dimension, which is, yeah, how you prioritize things, right? So anything here that we can learn as well?

Chris Jones: 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. And 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. And the way we’re going to deal with this is figure out how to peanut butter things a little bit. And 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, you know, maybe you’ve made a bunch of stakeholders somewhat happy. None of them are probably going to be that happy. But if you take a step back, it’s really just… it’s a bunch of cockroaches skittering around in a lot of different directions, right? There’s nothing coherent here in what’s been built. So 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.

And 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. I mean, that the product organization is absolutely partnering deeply with these stakeholders. The product organization needs to understand to pretty sufficient detail, you know, what the implications of all of these decisions are. But at the end of the day, they have to focus. And 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. And maybe 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.

So that’s really the main thing that this is about. And 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 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 predictable, 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 as 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, you know, the stakeholders have their collection of things that they all believe are very important. And 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. So there’s a big change that actually has to go on on that particular dimension.

Henry Suryawirawan: Yeah, I fully believe this one is probably the trickiest, right? Because you will upset some of the stakeholders, right? And 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 to certain things and maybe different other stakeholders like marketing, sales or whatever, right?

[00:42:56] Unified Product Vision & Strategy

Henry Suryawirawan: So I think one key challenge is 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. Like how could the stakeholders also come with a unified vision?

Chris Jones: Yeah. So 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. And 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, and rather than it being kind of outside in, business to product and then they rationalize everything. 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. But 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. Because 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.

[00:44:45] The Role of the CEO & Product Leaders

Henry Suryawirawan: Yeah. So I think I can feel the pain of so many, you know, product teams out there, right? So definitely they have to answer all these things. So definitely 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 have their own roadmaps, I think it’s kind of like difficult, right? Which brings me to actually the importance of the role of the leaders or the CEO. So how can they drive this product operating model to be a successful transformation within their company?

Chris Jones: Yeah. So I’m going to divide this into two categories of people. And they’re both very important, but they, I look at them a little bit differently. There’s the CEO and then there are the leaders within the product organization. So the most senior product managers, you know, the CPO or VP of product and same on the engineering side, CTO, VP of engineering, the design, you know, those the ones that are the true product roles. So those are the people we call product leaders, even though it’s not just product management, right? We’ll call those all product leaders.

And 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. And 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, you know, 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. And 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.

So it is something that we really look for early in a project. You know, 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.

Henry Suryawirawan: Yeah, I think the transformation typically has to start, you know, the champions must be from the top, right? If you are doing it in a departmental silo aspect, right? I think typically you will hit some kind of ceiling, right? And it could turn into political things as well, right? Especially if you don’t involve other-departments as well.

Chris Jones: 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. And if there is not a real high level buy-in yet, the risk for them is not that they’re gonna 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. And then 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. So it’s something that we take very, very seriously.

[00:48:36] Product Model Competencies

Henry Suryawirawan: Right. So thanks for that plug. So you mentioned a few things about competencies, right? You mentioned something like product manager, you know, product designer, tech leads, and engineers here. So maybe are there any other competencies that people need to put in the cross functional teams? Like how about the role of coaches, right? How can the team get up skilled into this kind of thinking?

Chris Jones: Yeah. So we’ve been talking most of this session about the principles around the product model. And it really is about principles, but it is also about some competencies. And 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. And oftentimes, even though people have, 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 who is part of their 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. So basically the managers and leaders of those three disciplines that I just mentioned. So 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. Because 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 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.

So, you know, 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. And 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.

Henry Suryawirawan: 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 be it the quality attributes, you know, the design, the architecture, the reliability of the system, but rarely touching into the product discovery aspect.

Chris Jones: Right. And 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. And 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.

Henry Suryawirawan: Right. So thank you for elaborating so many things, you know, the principles that people need to think about product operating model, right? So I think the book, I highly recommend that. So I think all the books that are from SVPG, I think it’s typically really, really insightful, right, so including this one. So definitely 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, right, please do check out this book. So I think there are a lot of insights that you can learn. And also don’t forget to give it to your leaders as well, right? This kind of transformation will not happen just within your team, right? So the management, the executives, right, and the product leaders, they all have to agree to these set of principles so that their transformation can be more successful.

[00:53:05] 3 Tech Lead Wisdom

Henry Suryawirawan: So, Chris, as we go into the end of our conversation, I only have one last question for you. I call this three technical leadership wisdom. So if you can think of it just like an advice to anyone. You don’t have to be technical. You can also think from it from the product side. So maybe what will be your leadership wisdom here?

Chris Jones: Yeah, so you had sent me this a little bit earlier and I was deciding what level to come in here. You know, 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. And I think, unless you have a preference, I’ll start on the lower side of things, just cause there’s some fun hacks here and I’ll see if I can get through them really quickly.

So one of the tricky things that I found was helping somebody become a manager for the first time. And there was a technique used on me when I became a manager for the first time. And 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.

And then 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. And 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. But 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. And, I’m calling this the rule of six. And 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. And 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. And the thing that happened was just purely accidentally, I signed up for six of these before I had done one of them.

And that interestingly reduced stress. You’d think it’s a paradox, right? Because you’d think that 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. So 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.

And then 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. And it’s not, you know, 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, just you can look at your calendar, but, you know, what is it?

And 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. And you know, this slice is too big and how can I help you make it smaller? And this slice is non-existent. We really need to be able to get this one up. So just by looking at kind of 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.

Henry Suryawirawan: Right. I find all of them very profound, right? So I think really, really great things for, especially not just first time leaders, right? All leaders can actually learn from these hacks, right? So 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 about this aspect, right? Stepping back and letting others to actually shine, right? Taking the credit. And then the second one is about overcoming fear, right? Do more. I think we all say like if it’s painful, do it more often, right? So I guess you can treat it the same thing. And the last one is about thinking at the end of the week, probably, or the end of 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.

So thank you so much, Chris, for elaborating all this. So 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?

Chris Jones: Yeah, best place is probably the SVPG website, so Silicon Valley Product Group, which is svpg.com.

Henry Suryawirawan: Right. So I’ll put that in the show notes. So thank you so much, Chris, for your time today. I hope people learn a lot about product operating model and they are able to adhere to these principles in their own team.

Chris Jones: Thanks, Henry. I had a lot of fun.

– End –