The Biggest Mistake In Marrying Product and Agile

🔗 Master Lean Product Discovery – Sheev Workshops: https://sheev.co.uk/training/leanux/

In this week’s Product Agility Podcast, host Ben Maynard takes the mic solo once again to tackle one of the biggest and most persistent failures in product and agile transformations: the misunderstanding of how learning drives adaptability.

For years, agile practitioners and product leaders have been trapped by a delivery-first mindset. They race to meet deadlines without truly validating their ideas. The result? Teams deliver at speed but fail to learn fast, leading to wasted effort, frustrated stakeholders, and products that miss the mark.

Ben dives into why learning speed > delivery speed and how misinterpreting key agile principles has slowed us down rather than accelerating success. He also unpacks the critical mistake that organisations continue to make: treating the business as just the Product Owner, rather than fostering true collaboration between developers, users, and real business stakeholders.

Key Takeaways:

• The hidden cost of prioritising speed of delivery over speed of learning
• Why the "business" in agile principles should mean more than just the Product Owner
• How teams can validate ideas before writing a single line of code
• The case for continuous user engagement—not just after launch
• A simple shift to break free from feature-factory thinking

Practical Insights:

• Why your roadmap should be a learning plan, not just a list of features
• The power of discovery sprints to de-risk product decisions
• How learning Kanban can revolutionise backlog refinement
• Agile Coaches & Scrum Masters—your real role isn't efficiency, it's learning

🔎 Join the conversation on LinkedIn: https://www.linkedin.com/in/benmaynard-sheev/

Host Bio

Ben is a seasoned expert in product agility coaching, unleashing the potential of people and products. With over a decade of experience, his focus now is product-led growth & agility in organisations of all sizes.

Stay up-to-date with us on our social media📱!

Ben Maynard

🔗 https://www.linkedin.com/in/benmaynard-sheev/

🐦 https://x.com/BenWMaynard

💻 https://sheev.co.uk/

Product Agility Podcast

🔗 https://www.linkedin.com/company/productagilitypod/

💻 https://productagilitypod.co.uk/

🖇️ https://linktr.ee/productagility

Listen & Share On Spotify & iTunes

• Spotify - https://open.spotify.com/show/0lkwAYJzVSuk5zfJ1vIDZq?si=4c691fb12f124a56
• iTunes - https://apple.co/3YvTX8p

Want to come on the podcast?

Want to be a guest or have a guest request? Let us know here https://bit.ly/49osN80

Transcript

0:00

Today I'm going to talk about the biggest mistake in Marion product and agile that everyone keeps making. I owe everything I know about agile product management and coaching to the incredible mind I've learnt from over the last 20 years. Whether it's insights from Radhika Dutt or Rich Moronov or Marty Kagan, lean lessons from Jeff Gotthelf and Josh Seiden, or the agile mindset from the likes of Alistair Coburn, or the principles of what it is that makes really great teams from Paul Barber and Lucy Withdison, the same truth is always permeated through all those conversations and all that learning. The best teams don't just deliver fast, they learn fast. World class thought leaders and practitioners. Why I hear you ask? Well, I want to increase your knowledge and your motivation to experiment so that together we can create ever more successful products. My name is Ben Maynard and I'm your host. What has driven me for the last decade to bridge the gap between agility and product is a deep rooted belief that people and products evolving together can achieve mutual excellence. Today I'm going to talk about the biggest mistake in Marion product in Agile that everyone keeps making. Welcome to the Productivity podcast. I'm Ben Maynard as always, and today I'm going to be tackling the biggest failures in every attempt to follow Agile or invasive product mindset is to complete misunderstanding of how learning really drives adaptability. Now I owe everything I know about Agile product management and coaching to the incredible mind I've learnt from over the last 20 years. Whether it's insights from Radica Dutt or Rich Moronov or Marty Kagan, lean lessons from Jeff Gotthealth and Josh Seiden, or the agile mindset from the likes of Alastair Coburn, or the principles of what it is that makes really great teams from Paul Barber and Lucy Woodison, the same truth is always permeated through all those conversations and all that learning. The best teams don't just deliver fast, they learn fast. Yet despite decades of experience and research and case studies proving this, we still see companies stuck in the trap of delivering speed over learning speed. Teams race to meet deadlines, but without validation, they just keep delivering things faster that people don't really want. And when things fail, they blame execution when the real failure was the lack of learning. Some of you may have seen an interaction I had on LinkedIn earlier this month. It's on in February 2025 where someone was explaining to me that what teams need are just clear requirements from the business. And I, I just couldn't really get on board with this if all teams needed was clear requirements from the business. And so much needs to be right with that. The business need to know what they want. And we know, we know whether it's looking at the work of Jake Knapp and design sprints or looking at lean product discovery from the likes of Jeff Gotthelf and Josh Scheiden, is that actually the more brains we get on solving a meaningful business problem and the more we iterate, the more we fail, the more we learn as a team, probably, almost certainly the better decisions we're going to have when the environment that we're in is not predictable and known to us, which in essence is most product software delivery. So yes, what we're looking at today, what I'm talking about today is this trap of delivery speed over over learning speed. It's when teams are racing to meet those deadlines without validation, as I said. And when things fail, I mean, everyone blames agile, they blame execution, they blame delivery, when the real failure was always and will always be the lack of learning. But there's an even bigger failure at play here, one that nearly every agile and product transformation gets wrong. It's the reason why so many teams build that validation, the reason why agile training missed the mark, the reason why teams are stuck in the feature factory instead of real product discovery. And that failure comes from how we completely misinterpreted one of the most important agile principles. You know, it's important here to point out that I'm not on the on the fence here when it comes to my my love and what I owe to the agile community, the agile mega complex, the agile principles and Vandies. You know, I built a career off of that. But what I've also seen over the past 10 years is that Agile alone never really solved the problem. And I think that Agile probably could have done. I think that when we look at what's happening in fantastic product companies, actually it's not a million miles away from where some of the great agile teams and great agile organizations maybe could have ended up if we had just got over ourselves a little bit and actually really focused on the major agile principle and one of those critical agile principles that everyone got wrong and everyone still gets wrong. And it's why it's slowing us down. In one of the original agile principal states, business people and developers must work together daily throughout the project. And it sounds simple, right? Except we completely get it wrong. One debate, you might have heard this in the podcast in the previous episode. And the first mistake I want to talk about is when people think the business equals a product owner. So instead of fostering real collaboration, organisations decided that business people just meant the product owner. One person sitting between the development team and the actual users, filtering, interpreting and often blocking direct engagement with the customers. And this missing single misinterpretation stayed learning down to accrual, I believe. Now, I'm not going to call out the person, but there was a guest probably a couple of years ago who just couldn't get their head around the fact that when we talk about the business people, it didn't mean the product owner, at least in my opinion, what they were saying here. And let's look at the sentiment of it. Let's look at what ought to be. We were talking about the developers, the people who are developing, creating the product, whatever their skill set may be, talking to the people who are the ultimate arbiters of success or failure and doing that frequently. And yes, it says project, but let's just go for ourselves, right? That was written at a time where projects, they were very popular and preserved a purpose. And they still do if we just replace that word in our minds of products and get over that. And actually we can't, you know, get away from the fact that this was the single biggest miss, I think, when it comes to the dodging of agile principles. So. When we do put somebody in between, say the product owner, developers aren't talking to the users, they're talking to the person who talked to a person who might have talked to a user. At some point, insights are diluted, second hand information rules and teams lose their ability to develop intuition about their product and intuition about their customers. We want our development teams, our software engineering teams, our product teams, however we want to label them. I don't really care, but we want these teams to be making decisions as if they were the customer, as if he were the CEO. That's what we want to achieve. And unless we can find a way to tap into those natural human instincts of face to face communication, of talking to the people who are going to be receiving what we're creating so we can build empathy and knowledge and understanding, then we're never going to succeed in speed to learning. And it's always been about just focus on speed of delivery Now. Mistake #2 assuming it was optional, as some organizations ignored this principle altogether, treating user engagement as a nice to have rather than the core part of Agile. They assumed as long as they had a product owner, that was enough. The result? Well, slower speed to learning because insights had to travel through layers of bureaucracy. A lack of product and user customer intuition because engineers weren't exposed to real user feedback in a timely manner. A disconnect between problems and solutions because the the people building the product weren't exposed to the problem first hand. So what's the fix? The original intent of Agile was to ensure that people who make the product and the people who use the product are in constant daily conversation. Not for a middleman directly. And I do remember in all my time in banking, particularly one conversation, you know, the people believe that the success of what they were doing was purely down to really well written requirements. I also recall, and this is going back sometime and I'm not saying, you know, I try to do an absolute as much as maybe some of the stuff I say may seem like that. I try not to. But I do recall a time when. Teams had people with analysis skills on them, and those people with analysis skills, I was one of those people for quite some time, went and spoke to the users and the good ones, in my opinion, connected the teams to the users and the customers so they could have meaningful conversations. Then what happened in new organisations where I was spending my time, those analysis type skills and functions got segmented off, siloed away into what we used to call a change function. So then all those people would do is write requirements documents. Then somebody thought, well, I wouldn't have a change function. That isn't very agile, is it? Let's get rid of a change function. So they got rid of a change function and left this huge gap when it came to the analysis skills, which were necessary to have the conversations with the right people to connect people to, to each other, to connect teams to customers. Like when it disappeared and a puff of smoke. And so then I think people looked around and so, well, Holden, here's Scrum, they got the role of a product owner. Surely that must be the analyst, You know, cue lots of banging your head against a wall because that was not the point. That was not the point. And Safe did a fantastic job at really helping to permit that idea. So I'm not saying that, you know, if you're a product owner, you don't need to resist. You probably do. What I'm saying here is that they've, the types of product owners I see are immensely successful. 20 years ago they were just the people who were on teams as analysts and doing a fantastic job. So I don't really care about the label. The important thing here is that we have an opportunity to, as agile seems to be on the ropes a little bit, is maybe to restore agile to what it was meant to be. To make it useful in marrying with product, make it into a system where learning happens in real time, every single day. That means engineers, designers and business people like real business bid people, not just the the team. Products owner need to have direct and continuous interactions with customers and users. Not once per quarter. Not after launch. Every single Sprint. Here's the funniest ad you're going to hear for a lean product discovery course now. Did you suffer from chronic backlog bloat? Have your sprints become an endless cycle of building things nobody asked for? Are you trapped in a feature factory with no escape insight? You may be eligible for a Lean Product Discovery intervention, the only course designed to teach you how to test ideas before spending months shipping nonsense. However, this does come with some side effects. These include shorter development cycles, stakeholders actually understanding why why you're testing and what you're testing first. No longer needing to pretend that you have for data when you actually just have opinions. So sign up for this today and start your learning faster than your competitors journey. Check for show notes, good more information. This is paid for for the Coalition against Useless Rd. maps now. Let's talk about agile coaches. Yes, I know you're there. I know you're listening. We're not just talking about efficiency, OK? We're talking about learning. You're teaching learning, not efficiency. If you're an agile coach, your job isn't just to make teams work faster, it's to make them think smarter. The best agile teams I've experienced aren't the ones that deliver the most, they're the ones that learn the most per Sprint. So how can you, as an agile coach, or maybe even as a product coach, break the feature factory mindset? Perhaps consider replacing Sprint goals with learning goals. Every Sprint should define what needs to be learned, not just what needs to be delivered. Try and dare I say run some kind of discovery sprints. So. So before committing to any development, really spend the time validating the problem and looking for problem solution fit. Maybe that's how you should be treating your product back Or refinement. Try looking at using learning Kanban. So instead of tracking tasks, track assumptions, experiments and insights gained. A real bad example for me is one team I worked with was excited to build a recommendation engine and instead of jumping and development, they ran a concierge MVP manually curating recommendations from a small test group. The result? User engagement was low. Customers didn't actually want a personalized recommendation system. That single experiment saved six months of wasted development. Now, product managers, I'm talking to you. Your success is measured by learning, not by launches. For product managers, the challenge is clear for me. Stop treating Rd. maps as a list of features to build. A road map should be a learning plan. The fix for this? Think of it as a learning road map. Try it as a learning road map. So frame learning as risk reduction. Show stakeholders that testing early prevents expensive failures later. Tell your stories with data. Instead of saying we think this is a good idea, say we ran this experiment and here's what we learnt. Use visuals. Create a learning pipeline alongside your delivery road map now. I'm going to keep this one short today because you know, the sun is shining here in the UK and I want to go and enjoy some of it. So I want you to just think about this. Speed to learning is speed to value. If you're not learning fast, you're just guessing fast. And guessing isn't a strategy. And if you want to go deeper on any of these topics and do check out my Lean Product Discovery course, where I'll show you how to embed learning into every single step of your product development process. And you want to join the conversation? Well, get onto LinkedIn, check out the posts that we're putting out of the Product Agility Podcast account and share your biggest mistake that you've seen in agile teams in product teams. Share your thoughts and don't forget to subscribe to the Product Agility Podcast for more straight talk and insights. I am looking forward to keeping these up. We will be having some guests coming on, but I just wanted to, I don't know, share some thoughts of you all. So until next time, learn fast, ship smart and stay agile.