#033 - Marty Cagan - empowered product teams

Foreign.

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

And I'm Murray Robinson.

And I'm Marty Kagan.

Hi Marty. So we wanted to talk to you about Agile product management today. Let's start by getting you to tell listeners a bit about who you are and what your credentials are in product management.

Sure. Well, I don't personally view myself as product management. My interest has always been product teams. I started as 10 years as an engineer, I was a great program. I was at HP Labs, kind of known as the Google of the day. Back then it was the rough equivalent. Today would be Google most consistently innovative company in the world at the time and great place for an engineer. And then I learned design, then I learned product. And I've always been a student of product teams. You're not the first one to assume I'm a product management person and I know why. There's already great stuff written about engineering, great stuff today about design, but there's not much about product management that has really been the weak link. And so I find myself spending a disproportionate amount of time trying to help on the product management side to raise the bar there. I say that because products don't come from product managers, they come from product teams. And so I'm all about building a strong cross functional product team where you've got product management, product design, engineering. Working together effectively is a beautiful thing to see. And that's really what I love doing, is working with teams. The more teams that work like that, the better the results are. So that's my focus, I write about and I spent a long time being on teams and leading teams. And now I spend a good amount of time writing about teams and writing about leadership. To me the primary job of leadership is to create these teams we're talking about. What makes me interested in product leadership. Engineering leadership, design leadership is because they play a big role in that. That's my world. I spend most of my time advising startups and growth stage companies. I have some partners that go in and work with bigger companies to help them transform. That's pretty much where I'm coming from.

Okay, great. That's what we wanted to talk about. What would you say is the problem with traditional product management today? Non agile product management.

There's no such thing as agile product management. It's ridiculous. Concept agile is all about delivery, product discovery, which is engineering design and product is where we figure out what to build. And Agile, whether it's Kanban or Scrum or xp, we're delivering that so the whole idea of Agile product management makes no sense. It's marketing is all it is. Traditional product management is a super good question. In my world, traditional product management is actually good product management and the rest is crap. So to me it's like crappy product management and good product management. For many people traditional means the crappy kind. I was lucky I was working at a great product company so it meant something very meaningful. And the nature of the job of that role in the good product companies remarkably has not changed in more than 20 years. Predates agile becoming popular. And it's the same basically the delivery processes are better Now. I do advocate teams go to Agile for delivery if they haven't done it, but frankly almost everybody's done it. Bigger issue we have of course is a lot of nonsense agile out there, the sort of fake Agile that is a big step backwards. It's got really nothing to do with the product management side. That's really about just clueless engineering leaders or IT leaders typically.

Yeah, I agree that there's a lot of fake agile. What I meant by traditional product management is this idea that you split product management into three roles. You have one person who does product research and design. They don't work with engineers at all. They work out what the product's going to be. Then you engage a technical project manager, they implement whatever it is in a 12 month project and then after it's finished, you engage a product marketing manager and they do the marketing. That is what I've seen as traditional product management.

I would have called that waterfall product development. In that model of waterfall there are different roles required, but they're orthogonal concepts. Because even if you have to do a waterfall product effort, you still need good product management, you still need good designers, you still need good engineers. So I think they're orthogonal. There's sort of IT style product teams, which I call feature teams or delivery teams. And then there's what people call empowered teams or you've heard project to product mindset, you've heard customer focus, all these different terms describing that, but that's a good kind. And I say good because these are what the most valuable companies in the world use.

So what's the problem with the feature team approach?

Well, so feature teams are given a solution, usually in the form of a roadmap. They're given a prioritized list of features and projects and they're told to implement them. That basically is Accenture's business model right there. So there's nothing wrong with it really. We can also Talk about the lack of innovation. Almost never have innovation in that, that model. But the biggest practical issue is only about somewhere between 20 to 50% of our ideas we think are going to work are actually going to work. And so when you put on the roadmap these potential solutions, there is always at least one stakeholder that believes this is the right solution. But if a company actually measures the impact of what they build, they know that most of them do not return the value they thought. So why is that? Well, can't really blame the feature team really because they were just building what they were told to build. There's a little design and then coding. The real source of the problem is the people who thought they knew the answer. And so the problem is they'll never really take the blame for that. They'll just point at the feature team and say, well, they did a crappy job designing, they did a bad job implementing, they ended up cutting functionality. So of course we don't like the result. In contrast, in a real empowered product team, you're not giving them a feature to build, you're giving them a problem to solve. The engineers I know went to school not to implement somebody else's features. They went to school to learn how to solve hard problems. There's a great Steve Jobs quote. We don't hire all these smart people to tell them what to do. We hire them so they can show us what's possible. Jeff Bezos would say to his product teams, I'm not going to tell you what to build, I don't know what to build. Our customers don't know what to build, they don't know what's possible. He tells his product teams, your job is vet great solutions on our customers behalf. So the point is, how do you leverage the brains of the people that you've actually hired, product design and engineering. And that's the idea of an empowered team is you're giving them a problem to solve and letting the team figure out the best solution to that. Now the first or second or third approach might not work, but at least if you're assigning them the problem, they know they're not done until they solve the problem.

So does this mean that you are doing your research and development and engineering all together at the same time? Because you're giving the team a problem, they try something, it doesn't work in the market, so you try something else. So what you're thinking about, well, so.

First let me just a nomenclature difference probably between your side of the Pacific and ours. We would save R and D for the long term research stuff. Okay. We're looking at some machine learning based thing. We need two years to collect the data. What I'm referring to, and I think you mean in our terms is just product discovery. Because there's always been these two things to do in software from day one. First we have to figure out what to build and then we have to build it. Well, build the right product, Build the product. Right. Those go by lots of names today. Companies have their favorite terms for it, but it's the same thing. So I think what you're referring to is how do you figure out what to build?

Yeah, I am. I'm talking about product discovery being done at the same time as development.

Yeah, it is done in parallel with delivery, but obviously it's a little ahead. Your engineers can't build something unless they know what they're supposed to build. So these two things are happening in parallel all the time. Just like your developers don't stop building for a while, they're building every day, every week, and hopefully they're doing continuous deployment. Similarly, the product manager and designer don't stop doing discovery working on the next thing that's going to build. And I should also point out this is not an absolute. The engineers spend a little time every day on discovery. The product managers and designers spend a little time every day on delivery. So there's some necessary overlap there.

They're all in the same empowered product team.

This is one product team. Spotify calls it a squad, but it's one cross functional product team.

Great. And what does this empowered product team look like? How many people are in it? What are the roles? How many engineers are there? Compared to non engineers, and so on, they're remarkably common.

There's a product manager, there is a product designer if it's got a user experience. Sometimes we'll work with platform product companies, which is APIs. And so they typically don't have as many of those designers. But assuming it's got a user experience, there's a product designer and then there's a minimum of two engineers typically and a maximum of about 10 to 12 engineers. And the reason for the range of course, is the nature of the software that's being built. But that's pretty typical. Now those are the people that are typically full time, every day dedicated to that product team. There are usually, especially in larger companies, a set of people that are in support of multiple teams. People like a user researcher that helps the designers do qualitative research. People like a data analyst that help the Product managers answer questions with data. People like a delivery manager, which helps manage the impediments. They usually serve as the Scrum Master product marketing managers. But all these people for rarely one per team. They're more like one of them will support a handful of teams.

So what's the difference between a product manager and a product owner?

Well, product owner is a role on an Agile team, just like a Scrum Master is a role on an Agile team. But most companies don't feel like it's worth hiring a Scrum Master just to be a Scrum Master. Doesn't actually take very long to identify impediments. The harder part is resolving the impediments. So delivery manager is the job they cover the Scrum Master role. It's the same with product manager. The product manager is the job. The product owner role is about 5 or 10% of their time and that covers the administrative rituals for the delivery process that the team is using.

We've had this discussion before and I agree with you that the idea of a product owner from Scrum is quite limited compared to what product management is really all about. But I do see a big push in the Agile community towards what you're talking about now.

Well, I hope so, because the Agile community has caused tremendous damage to product companies all around the world. Just tremendous damage. Agile was the forcing function to convert a lot of companies from the IT model where there wasn't a product manager or a product owner. They didn't use Scrum or Agile, they just used Waterfall. But they had these people called business analysts that documented requirements and then they had project managers. So they knew about these roles. But then when they moved to Agile, they're like, well, we need product owners. And they're like, we don't have anybody called a product owner. And so they said, well, we've got these BAs, we don't have any other use for them. How about the bas do it? And they have these certifications, as you know, CSPO and pspo, which are tremendously damaging to the industry. People think that means something. It's so ridiculous. It's like your engineers, when they learn Scrum, does that teach them how to code? Does it even teach them the first thing about any programming language? Of course not. Designers, when they learn Scrum, does it teach them the first thing about user experience design? No. Why do these people think that you learn product management when you learn the product owner role? It's so broken. This is not really so much of a problem in the US it's pretty rare but in the rest of the world, it's become a serious problem. I can't tell you how many companies I meet where the CEO tells me the product owners are completely useless and they don't understand why they're paying for these people. They literally would tell me I'm supposed to trust them and empower them. These people are totally ill equipped to be a product manager. And so again, I don't think that's intentional by anybody. It's just a very unfortunate consequence of focusing on a process rather than the real issue.

Yeah. So I think what we're saying is that there's a lot more to product management than agile teams think a product owner is responsible for.

Yeah, more generally there's a lot more to product companies and product teams than process.

Yes.

I personally think Scrum, Kanban, XP are all fine. Things like safe and less are ridiculous. That's a different issue. The regular process is fine, but the problem is none of them address the real issues. None of them do. There's a great quote from Elon Musk which is be careful because at bigger companies, process becomes the substitute for thinking. I can't tell you how often I see that.

Yeah, you've written some articles about the process police and I think you're talking about Scrum Masters there.

Well, process police in general, you get people who are focused on process and they're missing the point. And I have to coach a lot of agile coaches that they're not helping their companies because Agile coach isn't really what's important. Results coach. How do you actually achieve something meaningful? Agile is just a family of processes. They're not bad, but they're the easy part of the problem.

I think the Agile community has realized this and there's a lot of move in the direction you're talking about about having real product managers, not just business analysts. If you haven't got any product managers and you put a business analyst in there, then you have to have some real product managers helping them and teaching them and think about product management. There's all the old good stuff, the seven Ps of product management, product price, place, promotion, people, processes and physical evidence. There's research and development, there's marketing. There's just a lot of stuff that people are not thinking of when they're setting up these product owners. And you're right that product owners are very focused on delivery.

Agile is a delivery process. The product owner is a backlog administrator and that's fine. It shouldn't be a different person. The product manager should Be the product owner. You get a whole different set of problems if you have a product manager that's not the product owner. But that's not the point. The point is in product discovery we have to come up with something that's valuable, usable, feasible, viable. That's the point.

I've just been writing some role descriptions for product owners and that was the first thing I said had to balance those three things. So tell me, what is the difference between a self managing team and an empowered team? Or are they the same thing?

No, they're definitely not the same thing. There's really a bunch of concepts out there and they all mean different things. There's empowerment, there's autonomy, and then occasionally you hear people talk about self managing, which honestly is another soapbox. The common ones though are empowerment and autonomy. And those are both good concepts, but they're different concepts. Empowerment means the team gets to figure out the best way to solve the problem. Autonomy means they have everything in their team they need to do to make that change. It's very rare, except for a very small startup to have full autonomy. It's not even make sense in medium to large companies. It would actually be worse. Of course, who doesn't like autonomy? It's just that in practice you get no leverage, you get no reusability, you get no sharing. So all dependencies are not bad. Most dependencies we want to remove, but not all dependencies. Netflix says we want to have highly aligned teams that are loosely coupled. It doesn't say uncoupled, which would be no dependencies. It's loosely coupled. So some amount of dependencies is normal. Self managed is basically people that don't understand how real organizations work and scale and the role of leaders.

So let's talk about leadership. What can or should leaders do to support these product teams? Should they be telling them what to do every minute of the day? Should they be doing all the strategy and planning and the teams just focus on doing what they're told or what?

So there are really two styles of management in the world. Now this is where people talk about traditional and new is actually around management because the traditional way is command and control, top down. So the big boss says this is what we need and the medium bosses turn that into roadmaps and they hand that down to the teams to build. That's command and control. The alternative to that is empowerment or what Netflix calls lead with context, not control. And the idea is the leaders provide the context to the team and then they push decisions down to the teams so that the teams can make these choices. Now what is that context turns out quite a bit the product vision that can't come from the individual product teams. If you have 25 product teams in your organization, you don't want 25 product visions. You'll go in 25 different directions. Hopefully that's obvious, but you can't believe how many people spout nonsense about product manager should be doing product vision, product strategy. The leaders do the product vision, the leaders do the product strategy. The output of a product strategy is actually those problems to solve. And then if you don't want to command and control and just give directions to the teams, the alternative to that is to give them the problems to solve. Usually that's one or two problems per quarter per team. So they're given a problem to solve and then they get to focus on solving it and they're held accountable to those results. So the leaders are doing the product vision, the product strategy, and also assigning the work to the teams in the form of team objectives. The other big thing they worry about is team topology, which is how do you structure your product team so that you do have minimized dependencies so that teams feel very empowered and you get a lot of throughput flow as well. So that's a lot. And the biggest thing I didn't even mention, the leaders are responsible. They're the ones responsible for staffing and coaching. You know, for me, I mentioned I started as an engineer for 10 years. Every single day of those 10 years I had at least one manager assigned to coach me to be better at my job. I thought that was normal. And then you leave the bubble of Silicon Valley, you realize, not so normal. But you know, it's wonderful seeing this again. Just the other day I saw a video from Satya, the head of Microsoft, saying we are growing like crazy. And the reason you should come work here is because our manager's primary responsibility is coaching you, which of course Google says the same thing. And that's been recognized as one of their biggest strengths for years. And Apple, their leaders are given four big responsibilities and one of those four is coaching. Not enough other companies do that.

I agree with you. It's very rare in the organizations I've worked for in Australia and I've worked for a range of small and large organizations. Managers don't even understand that coaching is part of their job. It rarely happens. For example, it's rare for a manager to have one on ones with their team members weekly to talk about how things are going and give advice. For some reason it's just been really super rare in the organizations I've worked for.

Perhaps the reason is we call them managers when we say manage something. We don't call them coaches and leaders and say lead the organization. Coach your teams that work with you to be better. Because terms count. Product, owner, scrum, master, they all come with behaviors just like a project manager does. So why do we keep calling them managers and not leaders and coaches if we want to encourage them to change their behavior the way they work, what they do in an organization for the company?

As I grew up in, manager is not a dirty word like that. It's like, oh, they're the ones that do all the staffing and coaching. Yeah, that's my friend. So it doesn't have the connotation that yours does. If that's the connotation, for example, in New Zealand and Australia, then you either have to find a way to rehabilitate that concept or maybe rebranding is in order. I will tell you, though, I have learned a long time ago, rebranding big terms like this is really hard.

I don't believe it is a localization problem. I think one of the things we've seen on the podcast with all the guests we've had is the majority of organizations that were formed in the 70s and earlier are formed based on hierarchies. Their intrinsic DNA is command and control, and therefore the term manager means command and control. And then we see organizations that are formed later, coming with different DNA, a different culture, and then maybe the term means something different. The interesting one for me is HP because it was formed back in the days of command and control, but it didn't behave that way. So some unique organizations are just different and have survived because of it well and thrived.

Andy Grove was the father of empowered teams, really, although AHP practiced them as well. Peter Drucker used to advocate for this. We're talking 50 years ago. The concepts of good companies are not new. The problem is it's not evenly distributed around the world. I can point to companies in San Francisco that are literally right across the street from a great company, and they're terrible. So a lot of the time, the leaders just have very different views of the world.

I've gone into more of a product leader role in our startup, and I struggle to find product management information that's just not fluff. So why is that? Because product management has been around for many, many years. It's not new. Why is the information out there so lacking?

Well, there's always been more than One way of doing things, the old style and the more modern style and something on the order of 70, 80% of the stuff you'll find online. It's nonsense. I mean it's from a very different era. Not trying to innovate at all, not trying to take care of customers. That's my opinion. But there's no question that there's very different views on that stuff.

When I did my MBA in 1990, we did go into product management as part of marketing in quite a bit of depth. And there was big thick management textbooks.

There are.

Cotter wrote the classic book on marketing, but it's before agile, it's before digital.

Honestly, consumer packaged goods, which is where that really came from. That's a very different beast. We've talked about the problems that were caused by overzealous agile coaches thinking that they'll teach people how to be product managers. We've also had a problem with old school MBAs teaching old CPG style product management to people who know they need to learn product management. And old style product management is actually much closer to product marketing, not product management. So what we in a tech company would call product marketing. And so good companies will hire great MBAs, but then they put them through a deprogramming so they can unlearn that stuff that they probably learned.

So let's say that you are a business analyst or an engineer. You've been appointed to the role of product owner in a cross functional product development team that has testers and engineers and a designer in there and you've got this responsibility. How do you learn to be a product manager? What do you do that's not just product ownership and requirements?

Well, the best thing is to go work for somebody that has been there, done that at a good company. The vast majority of people I know that are really excellent at product management learned it from someone who knew how to do it. Sometimes that's within your own company, sometimes that means another company. But it's the best way. Because the truth is it takes somewhere between a year, two years to really get that experience under your belt. And that's hard, it's hard to replicate. Now there are courses just like with anything, just like when you need to know enough to find that right person to work for, you need to know enough to get the right courses. I don't want to beat up too hard on the Agile community here, but one of the big problems with PSPO and CSPO is the people teaching them almost never have done product management at a good product company. So all they're doing is using the ridiculous content provided to them. They have no idea. So that's the blind leading the blind. That's not helpful. So if you're going to take a course, get it from somebody who knows what they're talking about. If you're going to read a book, do your homework. If you're going to read articles online, do your homework. Because there are better resources than there have ever been. But there's also more nonsense than there's ever been. So you have to be able to tell the difference.

As a product manager, what are you actually doing apart from requirements and prioritizing the backlog?

Yeah, requirements are kind of the output. The question isn't the requirement. In fact, I don't even like to encourage the word because it makes it sound like all you have to do is uncover it under the right stone and you have the requirements. The point is to discover the requirements. Writing them down takes only minutes. The hard part is to figure out what they really are. And in truth, there's very few true requirements. The only real requirement is to come up with something your customers will buy that works for your business. So what we're trying to do is come up with a solution that's valuable, usable, feasible, viable. Four big risks. We can't do that alone. We need product design and engineering to be able to address those four risks. Specifically, design obviously is responsible for usability and engineering's obviously responsible for feasibility. But value and viability are responsibility of the product manager. To be able to do that, the product manager needs some knowledge. The first area they need deep knowledge is on their customers. So a product manager that's not face to face with users and customers every single week is a waste of a person on a team. So they have to really go deep on users and customers. Second, they have to go deep on how your business works. They have to learn the sales issues, the marketing issues, the financial issues, the monetization strategy, the compliance issues, the privacy issues, the legal issues, the ethical issues. They don't have to be an expert in all these any more than a senior engineer needs to be an expert in the whole tech stack. But they need to know enough to know when they need to go talk to other people. They need to have a pretty good understanding. They also have to have direct interactions with the engineers and designer. What product essentially is doing is putting together real needs for customers with what's just now possible. So you're going deep with the engineers. That's why any of the processes you find where the product manager is not connected directly to customers, but most importantly to the engineers is a process where the people don't understand the nature of product innovation at all.

So how do we incorporate discovery in the team while we're doing development? So the product manager and the user experience designer are in the team with the developers and we've got a problem to solve and maybe it's three months of work. How are we breaking that down? Are we breaking that down into research spikes, discovery spikes, discovery stories, and are we doing those alongside development stories? What's it practically like?

Well, this is basically how do you do product discovery? So there's a lot of things. I'll mention a few things, but don't misunderstand me. I'm just giving you the tip of the iceberg here. So this is what's different about discovery. At least half the items we start working on, we decide are not worth pursuing. The bigger question, though, is we've got a problem to solve. We need three critical skill sets to solve that. We need the product manager that understands the business constraints, the user issues, the industry trends. We need the engineers that understand the enabling technology, and we need the designers that understand service design, interaction design, visual design, and user research. So those are the kind of the three core skill sets. And then what we need to do is figure out a solution that works. You've all heard of Lean Startup, that Lean Startup was just the rough equivalent of Agile. But for discovery, Lean Startup is just discovery techniques, just like Scrum is a delivery technique. So most teams are using Lean Startup techniques for discovery and they're using Scrum or Kanban for delivery. That's not complicated. The hard part is, okay, well, how do you do this? Well, in discovery, you know, a lot of people talk about MVPs. I don't talk about MVPs too much because too many people are very confused about MVPs and it's caused more confusion than benefit. So I just talk about prototypes because MVPs should be prototypes anyway. And I explained to teams that there's four critical kinds of prototypes, and your team needs to be skilled in all four of those because you're going to need all four of those. We talk about testing those prototypes qualitatively, we talk about testing them quantitatively, but I tell them the whole idea is we want to very quickly try out many approaches because we want to find some approach that works. Once we do, we put it on the backlog.

Yeah. So what are those four types of prototypes?

The most frequently used prototype is created by the designers, and they're called user prototypes. Those are simulations. When people say fake it before you make it, they're talking about user are prototypes. They range from low fidelity. You've probably seen tools like Balsamiq and then very high fidelity like Envision and Figma, which look like the real thing, but it's all fake. We can go into the virtues of low fidelity versus high fidelity, but you need to be able to do lots of these. There's also something called a feasibility prototype. You know what we mean by running a thread through the whole process so that you can uncover all these things that are lurking. A feasibility prototype very quickly tells us what we don't know. In fact, I learned a long time ago as an engineering leader, never trust a date without a feasibility prototype. You're just setting yourself up for trouble before you give any date. Do a feasibility prototype. That's all. Do that feasibility prototype. That's what we trust. Once we've seen that feasibility prototypes are one of the few that are actually need to be created by the engineers. Most prototypes are actually created by the designers. The third kind of prototype is a live data prototype. The idea of a live data prototype is we actually do need to collect some data. A user prototype, you can put data in all day. It doesn't go anywhere, it just goes to the ether. But in a live data prototype, it can collect real data. Because a lot of times we need some evidence before we make a decision. Sometimes statistically significant results. But we don't want to wait three months before we have a product out there. And even if we were willing to wait, we don't want to pay the time and money to build a product when we might just decide this is a stupid idea after all. So a live data prototype is a very quick way to collect some real data on specific use cases in order to make a decision. Sometimes that's just a little evidence, sometimes that's statistically significant results. And then the fourth kind of prototype is actually called a hybrid prototype. Discovery is all about addressing these risks. Value risk, usability, feasibility, viability. And everything you're working on has a different risk profile. Some things are not risky at all, frankly. They're just like we call them. No brainers, just no problem. Who cares? It's not going to cause any problem. Let's just do it. Put it on the backlog and build it. Other things are very risky and so on. Those things that have significant risk. Normally we would do a prototype for each to address the specific risks. But with a hybrid prototype, we Basically create one prototype designed to address several risks at once. Live data prototypes in hybrid are a lot easier to describe with real examples from real companies. You just didn't know this is how they did it. But they're great. Whether it was creating the iPhone's keyboard, whether it was creating an Alexa device, you know, these kinds of prototypes are essential. So those are the four main kinds of prototypes.

If I look at the four types of prototypes, so what you call a feasibility prototype, sometimes we would treat it as what we would call a research spike. It's saying there is a high level of uncertainty and we want to do some technical work to see where the risks are, what is feasible, what isn't. I work a lot in the data space, so we would typically encourage teams to wireframe early to get feedback from the customers before we've invested too much because we get so much learning when we put a wireframe in front of some customers or users and say, was this what you meant? High fidelity prototypes, I don't tend to see in the data space, we tend to see it more in the app product space. But in terms of the product that I'm working on now, yeah, we definitely do high fidelity prototypes. When we have a problem that that prototype helps us de risk that idea of click through without actually building, but understanding the flow, that's going to happen. We get massive feedback from that. And then live data prototypes. Yeah, coding something out that works, it's not production ready, but we're getting feedback because stuff's going in, stuff's coming out, we're seeing where the problems are. So I think what people don't understand is that you have to use those four prototypes at different times. It's not one big bang. You don't wireframe everything. Sometimes you will jump from a feasibility or research spike to a high fidelity because it just makes sense that the risk you're going to manage is managed better with a high fidelity prototype.

And a couple questions asked by our audience. So the first one is, what's wrong with mercenaries? Marty, you talk about missionaries versus mercenaries, and that's what you should have on your team. But, you know, mercenaries are professional, they're highly skilled, they're craftspeople, they care about the work that they're doing. What's wrong with mercenaries?

Yeah, what drives that is this belief that if you just are using your engineers to code, you're only getting about half their value. And mercenaries, literally, you're just using them to code. They're brought in way too little, way too late to contribute to this much earlier stuff. So the best source of innovation is not your customers, it's not your executives, it's not the product managers, and it's not the designers, it's the engineers. And a mercenary model will not tap into that. If the first time your engineers are seeing your product ideas, is it Sprint planning? You screwed up. And most teams I meet, that's what they're doing. The engineers are like, I need to know what this is. Tell me more. And, you know, they're all figuring it out simultaneously. So that's a sign.

I wonder if the corollary of that is that you shouldn't be outsourcing your development to another company in Vietnam to be building your product for you, because they're just mercenaries.

I don't know a good product company that would do that. Don't get me wrong, there's always things like test automation that you can use some augmentation for. But one of the things I wrote about in the new book, because I thought it was so egregious, was Boeing, which is one of the biggest airplane manufacturers in the world, they literally outsourced to a team in India their flight control software. Think about that for a minute. How.

Massively incompetent you'd have to be as a leader to do that. They thought they'd save a few bucks. You know, it ended up costing them billions of dollars because they thought they'd save a little money instead of having a team that was constantly looking to build the most fuel efficient, safe, comfortable flight control software in the industry. Think of it this way. Would Tesla outsource the equivalent of flight control software? Not in a million years. They're way too smart to do that. And yet that's the mindset. So to me, when I hear you, I'm fine being a mercenary. And I know engineers that feel that way. Well, I didn't study computer science in order to build a bunch of dumbass features that some state builder wants.

Yeah, I agree. Software developers actually tend to be really smart people, and a lot of them are quite creative. There's a lot of musicians amongst the software development community, a lot of gamers and so on.

If I had to choose between having a serious engineer on a team or a product manager, I'd take this engineer.

So another question from our listeners. You talked about using written narrative approach in your book Empowered. So some people say, yeah, it worked for a while at the exec level, but then it dissipated and people just started going back to packs. So can you talk about this narrative.

Approach Most of the written narratives that I work on are product strategies. They're describing the different data, they're describing the ones we're going to bet on, the trends that we're going to go at. They're more of a rigorous PowerPoint deck. You're actually giving the evidence behind it. It's work to read that kind of written narrative. You can also use the written narrative to make something like a press release that's called the prfaq. The written narrative is meant to force you to think. When you write out your reasoning, you can't hide behind a pretty slide. You have to really spell it out. And even the very process of creating a written narrative will show me the holes in my logic. And then I show it to somebody I trust and they spot the rest of the holes in my logic. And so then when I've got this done, it's solid. I've done my preparation. We have different techniques for inspiring teams versus doing a rigorous analysis. When we're going for inspiration, we're going for something visual, something impactful that they can really say, I understand now what we're trying to create. Five years from now, I'm going to be able to do this. And they get all excited.

So what's an example? Is this like a product brief or a problem solution statement? Give us an example.

Probably most popular are a prfaq. And you can find examples of these online or on the svpg.com website prfaq. It's like two pages of a press release and four pages of anticipating the questions. That's a common example. And by the way, big part of Amazon's culture. It's part of their working backwards process, which is their name for focusing on outcomes. It's great. And then the other common kind is really a product strategy. It's like, okay, this is what we want to do. We're going to refocus our resources on this. This is the reason why. This is the data behind it. This is our plans. And you can shoot holes in it if you want. We're laying all our reasoning out in the open. You can see if there are any flaws, point them out. That's the purpose of this.

I did read somewhere that Steve Jobs at Apple, whenever anybody came with a product idea, he would say, create an ad for me. Create a print ad with a picture and a headline and some copy, because I want to see if you got something that we can sell that people are going to want before we even do anything else.

He was an interesting character because most people didn't really understand what he actually did at Apple. They think he dictated what the product needed to be, but it was really far from the truth. In fact, the guy resisted most things. Like the App Store, he resisted. But I've never seen a company that embraced prototypes more than Apple. But you have to realize they're doing physical devices. The risk of screwing up is a lot higher, and the cost of screwing up is a lot higher. What he was really good at was, let me see the prototype, give me 10 minutes, and then at the end of 10 minutes, he would list all the things wrong with the prototype. The guy was a master at setting a very high bar for what the product needed to be and had a really good sense of what people would love, what they'd appreciate. But frankly, he had a very high bar. And one of the problems I see is in a lot of companies, they don't have anybody playing that role. That's making sure that the company's not shipping a bunch of crap.

All right, we better go to summaries.

So for me, the way you speak, I can replace the word product with agile. If I think about the overarching concept of agile, not agile methodologies, I found that interesting. I like the concept that products come from the product teams, not the product managers. The product manager's core part of the team. A product leader needs to be on the team, but they're not dictators, they're not handing it off. The team are working together to solve those problems. If you're a product leader and you're doing a roadmap handoff to the team, you're forcing yourself to build feature mentality. So feature teams is not what we want because team members want to solve problems. Some good sound bites. We invent great solutions on behalf of our customers. We build the right product and then we build it the right way. I see a lot of synergy between the idea of cross functional product teams. I like an idea that what we're looking for is highly aligned teams that are loosely coupled. They are able to get the job done by themselves, but they're still aligning and reusing where it makes sense. I like the idea that leaders do the product vision and the product strategy. They then give problems to solve. The thing I struggle with is getting a good definition of what the hell a product vision is versus the product strategy versus a product roadmap.

Hopefully you'll read the book Empowered because that's what it describes.

So leaders are responsible for coaching. That's a core philosophy we're hearing. Time and time again and so align with that. And if the product manager's not in front of the customer every week, then they're a waste of space. So the product leader is engaging with the customers to understand what problems they need solved. That's one of their roles, primarily on that team. I like the idea that leaders set the team topology. The team topology drives a lot of the way of working across an organization. So focus on the team topology, the operating model, the who's going to do what first and then worry about the rest of it. And the big takeaway for me is there's four types of prototypes and I've unconsciously stumbled across them in the application or product space, so I'll use those terms more often now. So that's me. What do you got, Murray?

I agree with nearly everything you've said. I also think that what you're describing is what I call Agile Product Management. I know you said you didn't like that term, but that's what I think Agile Product Management is. And I see quite a lot of other people talking about the same sort of thing in the Agile community. I think it's great that you're writing about it and teaching people because people have been getting pretty confused about this. We can blame Scrum and XP for somehow making this a technically focused role where it should be much bigger. But I do think that the whole Agile community has been moving quite strongly in the direction that you're talking about. It's going to be a really big thing. I see a lot of people now that I know who used to be user experience designers or business analysts who went through a product owner role and have now become product managers and seem to be doing much more real product management.

Well, I hope so. I can't help but observe that in the best tech powered companies in the world, Amazon, Tesla, Netflix, a lot of them just think Agile is a bunch of bullshit. And when I talk to them about how they work, they're actually a lot more agile than the companies I meet that brag about how agile they are. I think there is a fundamental disconnect between the people who interpret agile very much around the process lens and those that really understand the nature of technology powered product. And so to me, I think as an industry we need to move away from that process focus. That's why I don't want to call it Agile Product. That to me makes no sense because it's focusing too much on the process. But that's something that's been uncomfortable for a lot of the people the best teams, they're not using Scrum, not using Kanban.

Yeah, but you don't have to do Scrum at all to be agile. I think that's what people get confused about.

I know I'm saying that, but when people talk so much about the rituals, when they talk so much about the roles. But what are you really talking about though? You are talking about a process. They're. They're not just talking about the principles.

Yeah.

So I don't have so much problem with it. I recommend Scrum to get started. I usually encourage them to go to more Kanban later, but who cares as long as you get to two week releases, I'm okay. I'm not going to beat you up on that. But if you're still doing quarterly releases and you're calling yourselves agile, I'm calling bullshit on that. That is like no agile in any shape or form. The industry needs to raise the bar on that. Yep.

And we don't do it by getting more process. We don't do safe and say here's a bigger process picture because that's how we're going to be successful. So I think all three of us agree on that one.

Yeah. One more thing. How can people find and Engage Mahadi?

Well, svpg.com Silicon Valley Product Group. I'm writing articles constantly and sharing them. I have a partner writing a great book right now. Another one with a book coming out.

So you do coaching and training and hands on consulting?

SVPG does, yes. I do a lot of writing and I also do some advising with the companies I work with.

Okay, great. Well, thanks very much for coming on, Marty. That was a fun and interesting conversation and really appreciate it.

I enjoyed it. Thanks for inviting me.

Okay.

Yeah. Catch you later.

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

Sam.