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 managers call 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 to give it a solve those problems. If you were a product leader and you're doing a roadmap hand off to the team, you're forcing yourself to build slash feature mentality. So feature teams is not what we want because team members want to solve problems. It's 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 that 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 in you. And so aligned with that. And if the product manages not in front of the customer every week, then they're a waste of space. So the product leaders 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 these four types of prototypes. And I've been consciously 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 exp 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 Kanbata.

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 not just talking about the principles. So I don't have so much problem with it. I recommend Scrum to get started. I usually encourage him 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 a process. We don't do safe. And so 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 Mahadein? 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, Mahadein. That was a fun and interesting conversation. And you really appreciate it. I

enjoyed it. Thanks for inviting me. Okay.

Yep. Catch

you later. That was the No Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help with agile contact Murray at Evolve.co. That's Evolve with zero. Thanks for listening.