#0106 - Transforming to the Product Model with Chris Jones

This is the no Nonsense Agile Podcast. Join us for discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice to industry professionals. Subscribe now to learn the latest trends and best ideas in the field.

In this episode, Chris Jones from the Silicon Valley Product Group discusses the product operating model, emphasizing the importance of cross functional agile product teams. He shares insights on transitioning to a product model, the value of rapid experimentation, product leadership and common pitfalls. And he discusses successful examples of product transformations at Adobe Cloud and Trainline in Europe.

Welcome to the no Nonsense Agile Podcast. I'm Shane Gibson.

And I'm Murray Robinson.

And I'm Chris Jones.

Hi Chris. Thanks for coming on.

Thanks for having me.

We want to talk to you about the new book Transformed by Marty Kagan and yourself. But before we do that, can you introduce yourself to our audience?

Sure. So, I'm Chris Jones. For the last 10 years I've been a partner with Silicon Valley Product Group. I started as a humble engineer. My degree was in computer science. Worked in a couple of different development capacities straight out of college. The biggest thing I learned from that was that I wasn't particularly good at it. I was quite slow as a developer. I was a little too architectural and academic, but felt a real kin to the product side of things. I left tech for a while and had a little bit of a diversion doing film production, which turned out to be formative for becoming a product manager. Started a small company during the mid-90s into the mid-2000s, and we helped a lot of different companies that were coping with this new technology, figuring out what it meant, how to apply it. This is where I first met Marty Kagan, the primary author of Transformed and the founder of Silicon Valley Product Group. One of my clients was Netscape and Marty was a VP of Product at Netscape. After this company, I got my first real jobs running product organizations. First was a B2B startup in the information security space. Data loss prevention. VOMTU was the name of the company. So I ran product management and design for that company. Saw that through the acquisition by Symantec. Worked for a couple years at Symantec, continuing to do product for that company. And then I worked more broadly across the enterprise portfolio. My last operational job, I ran product management, design and data and analytics for a company called Lookout, another security company. When I left Lookout, Marty Kagan invited me to join Silicon Valley Product Group and since then basically been helping companies that are trying to get aligned with the product operating model.

What is the product operating model?

An operating model Is just a way of working internally. We're not really at the level of process or framework. It's much more abstract. We divide it into concepts and competencies. So there are a number of core concepts that house principles. So things like what are the working units within a company? What are the product teams? What does product discovery mean, and how does that play a role in what you're doing? What are some of the key principles around product delivery? And then there are a number of competencies of which product management is probably the main one that we talk about. The other competencies are product design, the tech lead, and then the leaders within the product organization. These are often roles that exist in companies, or at least job titles that exist in companies. But how the people in those jobs operate is considerably different. When a company has adopted the principles of the product operating model, what is.

The purpose of the product operating model?

So the reason why companies adopt the product model is to organize around outcomes as opposed to organizing around output. Most companies are driven around what they ship and when they ship it. That is the currency by which everybody is measured. Did we make the release date? Did we get through all the P0 and P1 requirements? That's all output. And the important thing to realize is a company can rock that, but at the end of the day, it might not be moving any particular needle as far as the real business outcome. So when we talk about outcomes, they might be traditional financial outcomes, they might be revenue based, they might be something else. They might be a product outcome, such as how efficiently can you get a new partner onboarded? It takes us a week now. We want that cut down to 10 minutes. So those are outcomes. And the point is that outcomes will exist in a business, but they often don't exist within the broader product organization. The product organization is just building the stuff. Somebody else is responsible for the outcomes. With the product model, we're trying to push accountability for those types of decisions and those types of outcomes all the way into teams that are doing the work. So it is a fundamentally different way of orienting work. You can talk about time to value or what the best companies do call that project versus product. But ultimately it's about getting to these outcomes.

We've had Marty Kagan on before talking about some of these concepts. But you've written a new book. Why did you write Transformed?

Yeah, it's been an interesting progression. The book Inspired was really aimed at the individual product teams. It focused on the engineering and tech leads, the product designers, the product managers, and more importantly, focused on things like Product discovery. How do teams go about finding solutions to problems? The next set of problems that we ran into as we're dealing with companies and bringing them up to speed on those types of concepts was how can the leaders create an environment where this can really happen? And that led to the second book, which is called Empowered, and it deals with the broader product organization, what the leaders and managers do inside of an empowered team model. Setting context, product vision and strategy, as well as the softer skills around coaching and development of people. But really, the story that book did not tell was, okay, what does this mean? Whatever you decide to call your IT department, really what Transform tried to do was create a picture of what the product model is within the context of an entire company. And then the other part of the book was, how do you get from here to there? What are the steps you might take?

So, Chris, what are the five concepts in the product operating model?

Yeah, the first one is product culture. How much innovation plays a role versus predictability? How much do you value trust versus control? There is product strategy, and this is how you bring the efforts of the product organization together as opposed to a bunch of little projects from different stakeholders. There are product teams. That's the third concept. And this is really, how do you construct these teams? Who are members of these teams? How do they work cross functionally? Are you doling out solutions for those teams to build, or are you instead giving those teams problems to solve? The fourth concept is product discovery. And this is all about finding solutions to the problems that you're given. Doing it in a way that is continually assessing the risk, rapidly experimenting, and then product delivery is really what the engineers are doing to bring this to fruition. The actual creation of releases, how things are instrumented. Those are the types of things that you see there.

Okay, so I get like five concepts. Can you give me some examples of principles?

Yeah. So the principles that we talk about within Product Discovery are minimize waste to ensure that we have got evidence that the things that we're building are going to advance us toward the outcome that we're looking for. Another principle within Product Discovery is that we are continually assessing the product risks. There's a value risk when given a choice. Will they buy it? Will they choose to use it? There's a feasibility risk. Do we know what it's going to take to build this from a technical capacity? There's a viability risk. Will it work with all the dimensions of our business? And then there is a usability risk. Is it something that people can figure out? Product discovery is about teams understanding that these risks are there and they're continuously assessing them. Another principle around product discovery is embracing rapid experimentation, that you're going to find the answer by experimenting into it, not by sitting and thinking and writing a bunch of requirements. Some of those experiments might be qualitative, some of them might be quantitative. All sorts of different tools for doing things like this iterate on them very quickly, ideally with a set of tools that is a lot lighter weight than your engineers. Those are some examples of principles that exist around that concept of product discovery.

Can you go through the principles of delivery? Yeah.

The most important one that we talk about is small, frequent, uncoupled releases. Another principle is that anything that is released needs to be instrumented. And we're not just talking about response time and stability, we're talking about usage, things that are going to give you some indication that you're moving toward an outcome. Another principle here is that it's not enough just to instrument. You have to be monitoring what's released. So we don't just put the telemetry into the data warehouse. We have people who are looking at that stuff. And then a principle around having an infrastructure that supports the ability to progressively roll things out, pull things back, have multiple releases out simultaneously. Those are the types of things that we talk about within product delivery.

What about the principles of leadership?

Leadership was something that we explored a lot more heavily in the empowered book. And there's really two fundamental things that we go into there. The first is providing what the teams need to know in order to make good decisions on their own. In most cases, there is a product vision where you're hoping to bring all of this three to five years from now, and you want your customers to feel there's a product strategy. How do you create the right sort of focus across all the teams in your organization? That allows us to communicate problems to teams as opposed to solutions to teams. Our leaders are also responsible for determining the architecture of the teams, what we usually call the team topology. What's the breakdown of your teams? What are the boundaries of ownership? What's the role of platforms? The other big thing that our leaders are doing is coaching and developing the individuals on the teams and ensuring that people are being developed within the context of this model, as opposed to the simple command and control model.

What are the principles of team models?

First of all, they're deeply collaborative. So we want the product manager, designer, and your engineering tech lead collaborating. They're not just working on their sequential piece, creating their artifact and passing it to the Next person they are meeting on a regular basis, mixing things up, looking at prototypes, working with one another. The things that I've mentioned before are how work is allocated to those teams. It's a problem that you give the team to solve. We're holding them accountable for achieving the business goal or the product goal that we're giving them. Did you reduce the amount of time that it took to onboard a new customer? Did you hit the target that we were looking for? It's not enough to ship the feature. What we're really looking for is that a threshold of our user base is actively using that feature. Those are the types of things that we're holding them accountable for, as opposed to simply we made the date. The last big principle around product teams is that they have a deep sense of ownership. We've given them a charter. We don't want lots of little teams where everybody's just a cog and they're executing whatever the next story is on the backlog. They want to see how their area of ownership fits into the bigger picture and have some agency in that.

When you're working with these organizations, you're helping them build their own ways of working that reuses a lot of principles and concepts. Do you find that they say, don't teach me how to fish. This could be the bloody meal.

This is really one of the reasons that we focused so much on principles as opposed to process, because process means people stop thinking they've lost the game, they've lost the plot. So we always talk about process as being something that's in service of these higher order principles. We also believe that processes come and go. It might fit for this team at this particular time, but at a later time, something better might come in. The principles, though, are evergreen. I think there's a seduction in process. I think there's something a bit easy about it. People say, okay, I get it, my current process is bad. What's the better one? And instead, really what we need to be doing is refocusing people on what is the higher order goal here, and having the process be supportive of that.

How do they know where to start? How do they not bore the ocean and start to realize we need to focus on these ones first?

We recommend that they start small. It might be within a business unit. There might be a collection of teams. And what you want to do is identify a place that looks like it's relatively well set up for this. Maybe you've got the right talent over there. Maybe the nature of the work they're doing within this collection of teams lends itself well to be organized around problems. And you do your best to get those teams running this way. You provide the air cover for them from the rest of the organization to allow them to run this particular way. And then you harvest the successes and evangelize those through the rest of the company. And what we generally see is those teams will end up succeeding in ways that people didn't predict. First of all, you're shifting accountability to them, which many people love. And oftentimes the teams themselves love having that kind of agency. But what also comes out of this often is the innovation that you didn't expect. You've really operationalized innovation. And you may find a team hitting on something that nobody asked them to build but might make a very significant difference to the business. You see this and people start asking questions, hey, how'd you think of that? How did this happen? Nobody asked you to build that. I'm glad you asked. We're trying an experiment with this collection of teams here. We're having them run much more around this product operating model. Then you begin to spread from there. There are going to be more teams, more people are going to work in teams like that, more of the business stakeholders who are getting educated as to what it means to work with teams in this capacity. Basically, you'd start small and deep rather than shallow and broad.

What are the things that people are going to have to worry about when you're scaling from one small team with the right talent and capabilities to multiple teams or one or many different products or a different business unit?

We'll start with one team, about three to nine people. Then there's usually a collection of about five or six of those that are closely allied with one another. There's a level of leadership at that cluster, and above that, you're probably at a business unit. And you do have to make sure that stuff is all well connected. So there is a lot of coaching that has to happen to ensure that. Product manager to product manager, tech lead to tech, lead designer to designer. You've got the right sort of collaboration.

I've been reading through the product management threads on Reddit about this book, and one of the things people have said is that our company decided to go to the product model after reading Marty's book. So our execs went and hired a bunch of product managers and then they made them do project management. So nothing really seems to have changed except we're now getting a lot of product words and executives are now saying we're product led. But Otherwise, nothing's really changed. What can we do about it?

Yeah, clearly that's going to fail. This is really why we've tackled the problem the way we have. It's an operating model problem. It's not a role problem. It's not sufficient to hire in one competency. And most of the time when people do what you just described, they may not even hire a bunch of product managers. They might just retitle a bunch of people who were already in the organization and say, congratulations, you're now a product manager. There is so much more to this than just having that job title. It really is the entire way of working. It's what's expected from those people, but it's what's expected from other people at all levels of the organization.

So how do we change executive leaders thinking so that we can have a real product model?

I've worked with a lot of companies where the executives do get this. They do understand in some cases it takes some training, but usually it just takes learning from somebody within the company who's seen it before. Oftentimes a new talented leader who's worked in this type of organization brings the news in and provides some confidence to the other leaders that this can be done.

So it's about hiring the right executive.

VP of product that can help. There are obviously coaches out there as well who can help with this. There are people who have done it and are offering their services as coaches. But at the end of the day, you are going to have to work with somebody who has seen it before, has made it work, because you're not going to get there with just a book.

All right, let me give you a fairly common example. You have a company that's growing, but inside they're a total mess. They are not product led or product focused at all. They're sales led and engineering led. And yet you've got some people at the mid level who have organized some product focused teams and they've had some big improvements and they're doing well, but they're coming up against mechanistic thinking from higher up. What would you say to those people in the middle who are trying to push this product model?

Yeah, keep collecting evidence that this is working and build champions where you can above so that people begin to see what the value of this is. But the other part of your example that was a little bit tricky is that this is a company that maybe isn't feeling motivated to transform at this point. So those are going to be the forces that you're going to fight against. Seen a lot of companies where from an outward point of view, everything is looking quite good. But there were some people inside who were looking at the data, looking at shifts in the market or even perhaps opportunities that were coming down the pike, and realized that they weren't in a position to capitalize on those. They weren't in a position to do anything about that. And they quietly facilitated change so that the company was in a position to innovate when those types of challenges came along. We do talk in the book about Adobe when they went from the Creative Suite to the Creative Cloud. One of my business partners at SVPG is a former VP of Product there and was there during that transformation. Adobe was doing great. They were crushing all the categories that they were in. But some of the product people were looking at some troubling signs. Some of it had to do with how their target market had been largely saturated and how people were upgrading. They were looking at what was going on with mobile, which was quite new at the time, and looking at what they were not in a position to tackle and realized that they were going to have to make some real changes. And not only did they change the shape of their product, but they changed the operating model as well. But this was quite a leap of faith for them because the company was doing quite well in their existing product architecture and their existing business model. Many transformations happen and are driven even from companies that are doing quite well.

It's a good example. They had a real opportunity to become Kodak or Blockbuster. They did it at the right time and it wasn't easy. But I still use them and I still pay them far more than I pay most of my assessed platforming products that I use. So there's been this whole digital transformation bullshit where big consulting companies and large corporates grabbed a whole lot of great ideas and bastardized them and implemented them badly. Do you see that? People are picking up this idea of a product operating model, but just rebranding the people and giving them new slippers, not fundamentally change the way they think, not fundamentally change the way they work.

Yeah. So in the legacy model, you've got a product organization that is beholden to the business. It's there to support the business. It's there to execute what the business thinks it needs. And that is really where the lines of power are. That is really what the operating model is there to support. And we are shifting that. In the product model, there is a status shift that's going on where the decisions that the product organization is making are on par with the Business, maybe even going above the business. They're rationalizing the various needs of the business into something that is coherent and aligned. At the end of the day, a strategy is not necessarily going to make all the business leaders happy, but that is a decision that an organization is going to make because they know that applying technology this way is going to give them much better innovation, much better returns.

So if you're looking at an organization, how can you tell they are a company that has a product strategy or a company that has a business strategy and a product organization.

The biggest tell as to whether a company is really operating around this kind of strategy that we're talking about is how many things are they working on. Do they have 50 or 60 initiatives in flight right now? And furthermore, they really proud that they got that down from 600. That's usually an indication of a company that's not really operating from any sort of coherent strategy. That's just a bag of stuff that's coming from a lot of places, places in your product organizations responsible for making all of those stakeholders happy. If, on the other hand, there is something coherent in terms of a product strategy that has a much, much smaller number of focus areas, and some of those focus areas are articulated much more around outcomes, initiatives are fundamentally output. If you've got a strategy that maybe has a couple of those initiatives in there, but there's also these big areas of outcome that are being articulated and you've got your teams organized around that, that's usually a pretty good indication that you've got a product centric way of looking at your business.

We often see head of revenue makes money and the head of products spends money and they're not aligned.

Who owns the P and L? We've got the business guy here, we've got the product guy here. We're now saying that the product guy is making all the decisions. But this business leader still has all of the P and L. What gives? How can that possibly work? And of course, in some cases, in many cases, the P and L responsibility will move. But it's not just a straight lift. We've got, let's say, 10 stakeholders. They each have their P and L. We don't want to just lift that and put it onto the product organization. What's instead happening is that product is going to be the main driver of the P and L here and we're going to shift it there. On this other business, there's some type of expansion that we need to be making happen. It might not be a P and L responsibility it might be another type of outcome that's required in order to advance that aspect of the business. So the outcomes that are within the strategy at the product level need to be aligned with the business, and in some cases that is going to involve taking revenue over or at least sharing it.

I can see how they can be aligned if there's outcomes to align different teams. Do you see that as being a pattern that teams should use, or do you see it's been abused and just becomes a bunch of KPI metrics when it's used correctly?

OKRs are a fine, very effective device for communicating outcomes, but frequently abused. We're going to put OKRs into the system and magically we're going to be outcome oriented, when in fact all they've done is change the language of their roadmap. It's still just output. At the end of the day, you can have a very outcome oriented organization with or without okrs.

I want to talk about Marty's criticism of Scrum people. So listening to you and Marty, I feel that there's a very strong alignment between what we talk about on this podcast and what you guys are writing about. And a lot of our other guests on this podcast from the Agile community are advocating the same sort of thing. There's been a big move from project to product, and continuous discovery and continuous delivery have really become really big things over the last 15 years or so in the Agile community. But then I've heard Marty say some really critical things about Scrum Masters. What's going on there?

I think that we've been trying to fight against the parts of Agile that are very process heavy. And I'm sure you would admit that there are a lot of religious zealots out there around certain frameworks, certain methodologies, certain certifications, that sort of thing. And really that's the big danger. It's just this over focus on process. Shane, earlier you were talking about people looking for the formula, looking for the framework that we should swap in. It's really that type of thinking that is problematic, and many systems within the Agile community really do put a lot of emphasis on that. So this has been a crusade of Marty's in particular for quite some time.

I think.

Really that's what you're hearing.

Okay, so it's this process way of thinking. If I reflect on organizations where we've tried to do agile, what you very often encounter is a mental model from the executives all the way down, that the organization is a machine, like a very complex factory, and the way to improve the Organization is to improve the processes and make everybody do them. And since we're talking about a machine, we bring consultants in and we stop the machine, we make some changes and we start the machine again. It's the way of people thinking about it, which is the problem. Whereas I don't think Agile comes from that school of thinking at all. If you read the Agile manifesto and not the safe framework, Agile has a very different way of thinking based on continuous improvement.

And we, we would absolutely agree with that. That's the Agile lowercase a as opposed to the Agile frameworks which are all uppercase A, where those have gotten adopted and put into very much a process framework. I've also heard it described as being agile versus doing agile. Being agile is much more consistent with that manifesto. But so much of this has gotten bastardized into these systems and it's all about creating a better machine, better clockwork.

Yeah, I'm sure we're going to see a scaled product operating model come out with a big A3 diagram and a whole lot of certifications. Because when things get successful, they get commoditized and they get monetized.

It'll be something that we'll fight against. One of the principles right at the top within the culture concept is principles over process. So it's a bit of a meta principle. Don't make a process out of this. Like you might have some processes that are going to support this, but don't make this into a process.

But aren't you guys starting to certify product coaches?

No, we're absolutely not certifying product coaches. We have no level of certification. We do have some that we've worked with before and we will on occasion provide referrals for people. We are not benefiting monetarily in any way. So we have no finder's fee. There is no business relationship between us and those particular people. Yeah, no, there's no certification. There will never be certification.

All right, so with every patent there's an anti pattern. So how can the product model turn into an anti pattern?

I think it is easy to take a couple of pieces of it. Maybe you implement okrs, maybe you decide to retitle people as product managers and convince yourself that you've done the product model. I think that's probably the biggest risk. It's very difficult to do one small piece of this in a half assed way and get the type of outcome that the thing is really supposed to be giving you.

Okay. We've talked to some people in Silicon Valley who said that they try and do these sorts of things, but it's not really the way that you're talking about it that most of these organizations are quite dysfunctional.

It's absolutely true. Silicon Valley Product group was named 15 years ago, and there were a number of companies that Marty Kagan had identified, and the industry at the time would have agreed that these companies have it going on. They do innovate on a regular basis. They keep the customer very much front and center. They work differently than the rest of the companies out there. And that was really where the name came from. A lot of our business initially was outside of Silicon Valley, but I'd say we have just as much in as out. So there are good companies and bad companies to be found everywhere. It's interesting because from a brand perspective, Silicon Valley as a brand is on the wane and we've been a little bit saddled with that. But yes, the people that you're talking about are right. There's nothing particularly special about many of the companies that are here these days.

Can you give us any examples, maybe from your book and apart from Adobe, that have transformed successfully to a product model and what have the outcomes been?

In the UK and continental Europe, there's a company called Trainline where they aggregate ticket sales for passenger rail. This is a company that had a failed IPO and was picked up by a private equity firm that came in and transformed the place. They started by hiring a new CEO who brought in a new CPO and cto. They made significant changes on how everything happened internally, focused heavily on product vision and product strategy, redefined where the value proposition was, extending it far beyond selling tickets. The entire travel experience, what you do while you're traveling, what you do before, what you do after. They did a lot of work on formulating cross functional teams, really training them up on how to solve problems through product discovery. They came up with a number of really quite interesting innovations. They built an entire data practice that they brought into this and built a lot more value. Monday through Friday, it was the most popular smartphone app in the travel category within the entirety of the UK, even more than Uber. The company re IPO'd and at the time it was the most successful IPO in UK history. They made some real incredible outcomes.

Okay, Shane, do you want to go to summaries?

I do indeed. I love the fact that you came from product design and data and analytics. A number of people in product don't have the data and analytics part and I really struggle to understand how they can build something if they're not in charge of being able to measure it. I love the fact that you call it a product operating model. The move from delivering outputs to delivering outcomes. It's a bunch of patterns that you can use to craft your way of working to adopt product. I love the way you broke it down into concepts, principles and competencies. The five core concepts really are groupings and then the principles are the key and then the competencies are things we need to achieve. Those principles, roles and job titles has been one way of understanding what those competencies are. I like the idea that the book's going to flow. So inspired. Start with that. Because it's about individual product teams empowered. Came in to help leaders and managers lead the product organization transform. Just bringing in those way of working patterns that people can use to figure out what to improve next. And I like the fact that you not only describe what they are but how to use them to transform your organization on that journey. Sounded like a manifesto and I like that because that gives me clarity. And I like what you said around iterate with tools that are lighter than engineering because that was always the value was we could do some experimentation really quickly and really lightly because we're just drawing pictures, get some feedback before we commit. I'd love for the engineering piece to be as light as the design piece. Maybe with Genai, maybe it will, maybe it won't. But I'd never thought about it that way really. It's the design tools we use that allow us to iterate faster because they are lighter. And the key thing is we're embracing rapid experimentation. So principles over process. I want to minimize waste. There's 101 ways we can try to implement that principle and align with it. And every time we do one small bit that does, it has value for us. Processes come and go. Principles are evergreen. We constantly iterate our processes as we should. Our principles should stay for a bit longer. How do we know we're moving there? We're talking about time to value, not time for delivery. And then the stuff in terms of starting small. So right talent, right capability, provide air cover. That's the key thing a lot of people forget. There needs to be a senior person that can take the shit while the team are reforming the way they work. And they need a period of time to be able to do that safely. If you are the lead, harvest that success and broadcast that success across the organization and then scaling is hard. Go from a team of three to nine, then you're going to expand out to five teams. Then you're going to expand out to a business unit. What you talked about was leadership and collaboration are the two things that tend to break as you scale. So focus on those, because if you can get those right as you scale everything else, you've got a chance of it being successful. How do we know that we are or aren't a product company? The real gold was looking at an organization and identifying how many things they're working on. Is it focused and aligned on an outcome? So that's the one that I'm leaving with. Murray, what do you got?

Yeah, I find that I agree with nearly everything you and Marty say. It's the same message that a lot of our guests have on this podcast, although everybody comes at it from a different angle. Somebody comes at it from testing, Somebody comes at it from leadership strategy. Somebody comes at it from product. What you've done is you've combined it all together into a high level model with a set of principles which is easy to understand. And you've been good as an organization of communicating that out to people. And I think it's been picked up and taken on and it's a good thing. I support it. There is more to product management than we've talked about. For instance, there's product price, place promotion. If you go back to consumer goods product management. It's much more than just engineering and doing continuous discovery and continuous delivery. There's also marketing and research. There's pricing, there's competitor analysis. There is project management in there. But that's okay. That's not really the subject of this book. I agree with Marty's attack on the process place. There are people who are trying to turn agile into this heavy process and it's not meant to be like that at all. I think real agile and what you're talking about are pretty much the same thing. What you've brought to it is much more of a product focus though, which was missing from the original manifesto. So let me close out by asking you what are three books that you would recommend to our listeners that are not your own book?

All right. Yeah. So probably the one that I recommend the most ardently is Good Strategy, Bad Strategy by Richard Rummeld. If you haven't read that, it does talk about product strategy. It talks about all manner of strategy, geopolitical and military and economic and company and all of that. I think it really does frame up what true strategy looked like better than any book I've ever read. Another book that I read probably within the last year or two was Build by Tony Fadell. An interesting tour of a lot of the big hardware devices of the last several years and very colorful character and good storyteller. For the third one, I think I'll do Trillion Dollar Coach by Eric Schmidt, which is the book about Ron Conway. Lot of anecdotes that get into many of the kind of inside baseball, behind the scenes stuff that happened within Silicon Valley. But more than that, I think it puts so much of a focus and energy around the value of coaching and how important that is in order to create a successful company of almost any sort.

All right, that's great. Now where can people learn more about Silicon Valley Product Group and your book Transformed?

You can find us@svpg.com we publish articles every week to two weeks or so. There's quite a lot of stuff that's out there now totally free. There's information about the books, there's information about the engagements that we do. We also run some public workshops that describe various aspects of these models and.

What sort of services do you provide to companies.

Yeah, so there are training services and transformation services. Transformation engagements are mainly for companies that are still trying to figure out if this is the way that they want to work. Training engagements are primarily intended for companies that have already committed to this. They just need to get more people on board with what it means to work in that model.

All right, great. Thanks for coming on, Chris.

Thank you guys. It was a lot of fun.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help to create high value digital products and services, contact murrayvolve.co. that's evolve with a zero. Thanks for listening.