The world of Product Discovery and Creation is becoming increasingly challenging due to mistakes and missed opportunities that are prevalent in agile teams, large-scale Scrum and all other agile frameworks. History has shown that when organisations try and scale their product development to more than one cross-functional team, mistakes are made that cut short many chances of getting all possible benefits.
The route of this for many is the need for more attention paid to the incredible advancements in Product Management driven by hordes of professional Product People who prove that making their customers happier is not a pipe dream but a hard and fast reality.
This podcast exists to explore all topics related to Product and Agility and Coaching.
How do you marry the agile principles with Product discovery?
Is it really possible to have hundreds of cross-functional teams (or Product Teams) all working from an effectively prioritised single Product Backlog and a dedicated Product Owner?
How can you embrace continuous improvement and empirical process control for your product, people and processes?
Ever wondered how to overcome the problems people face when trying to scale the Product Owner role and how it relates to Product Management and Product Teams?
Baffled by how to define a product in such a way that enables Feature Teams (aka Product Teams) and why doing wrong means you will only ever be stuck with technical teams?
Scrum Teams are not compatible with modern product management techniques.
Want to know what Product Focus means and how the right focus makes creating a shippable product less painful?
Need to get your head around how to blend modern product management techniques with Sprint Planning and Sprint Reviews to achieve Product Increments that cover the entire product?
This podcast's original focus was on Scaling Scrum vs Single-Team Scrum and how organisations can reap the benefits of Scrum when working on a larger product but still keeping a single product backlog. We found many Product People liked what we said, and then the penny dropped. This isn't a podcast about scaling Scrum or the limitations of single-team Scrum.
This podcast is for Product People & agile advocates who coach or get their hands dirty with Product creation.
We promise there is no Taboo topic that we will not explore on your behalf.
We aim to transcend the conversations about a single team, Daily Scrums, Scrum Masters and the double-diamond and bring everyone together into responsible teams dedicated to working on the entire product to make their customers happier and their lives more fulfilling.
Come and join us on our improvement towards perfection, and give us your feedback (we have a strong customer focus, too), and who knows, perhaps we will discover the magic wand that we can wave over all the broken agile and sudo-products to create a more resilient and adaptable future by bringing the worlds of Product, Agility and coaching together.
This podcast has the conversations and insights you need.
In this week’s Product Agility Podcast, host Ben Maynard takes the mic solo to tackle one of the most controversial (and misunderstood) statements in product development: "Developers should NEVER talk to customers or users…"😲
But wait—should they? Or is this just another myth holding product teams back?
Ben dives into the real reasons why some organisations resist letting developers engage with customers, why this mindset stifles innovation, and how shifting towards an outcome-driven approach leads to better products, happier teams, and more business impact.
With years of experience bridging the gap between Agile and Product, Ben shares practical strategies for empowering teams to focus on solving real problems rather than just shipping features.
Key Takeaways:
Why many teams are stuck in a feature factory—and how to break free.
The power of direct customer conversations—and why every developer should be involved.
Outcome vs. Output: How to stop wasting time and money building the wrong things.
The Lean Product Canvas in action: A real-world example of saving tens of thousands by testing ideas early.
Leadership mindset shifts: Moving from feature delivery to solving business problems.
Practical Insights:
How teams can validate their ideas BEFORE writing a single line of code.
Why traditional backlog management is failing product teams—and what to do instead.
The simple interviewing techniques that empower teams to make better decisions.
Scrum Masters & Agile Coaches: How to bring customer learning into sprint reviews.
Ready to challenge the status quo? Listen now and let us know: Do developers in your team talk to customers? Why or why not? 👇
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.
It means if you're a product owner, the shift is moving away from backlog management to problem definition of solving. Like stop being the person who just translates the stakeholder request into Jira tickets. Instead, push back, ask what's the business problem we're solving? If you have an answer, then it's probably not worth building yet. Welcome to the Product Agility Podcast, the missing link between Agile and product. The purpose of this podcast is to share practical tips, strategies and stories from 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? It's a deep rooted belief that people and products evolving together can achieve mutual excellence. Welcome. Today's a break from tradition because we're not going to have any guest on. When I started the podcast from the years, I used to do the cooking pieces where I would just pick a topic that was close to my heart at a particular point in my life and basically release as an episode. And I've missed that. So please indulge me today because there is something which I've been doing a lot of recently and I really want to talk to you all about it. Which is something I think every product team, development team, engineering team has experienced at some point, which is the relentless focus on simply shipping features rather than solving real business problems. This is something which is so, so omnipresent in many organisations. I want take some time to explore like why this happens and how I found that teams can shift towards an outcome driven approach. Also, what can leaders do to stop wasting people's time focusing on output, timelines, deadlines, Stop wasting money and effort on things that don't really in the grand scheme of things, make a big difference for their customers, their users, and importantly, this their business. So this is exactly the kind of shift that I've been helping teams make with some of our Lean product discovery workshops, but I'll talk a bit more about later. For now, let's really begin just to get into this whole topic. Let's scratch the surface a little bit. I'm going to try and not be too prosaic because I know it's a topic which some people feel has been done to death. So I'm going to be talking from my real life experiences with this. So one of the big problems, maybe the main problem that you see is that teams are given specs and not problems to solve. This is something which I don't know if you've worked in software development for any length of time, you're bound to recognise this. Teams are handed a list of features, given deadlines and expected to deliver. No one asks what these features will actually solve and if it's going to solve anything. Is that a real problem for the customer? I think even when teams do ask, it's just often lost. One of the first software delivery teams that I worked in as a business analyst, AKA I says what many people may now call something similar to a product owner. The devs wanted to talk to the users. I didn't think that was a thing to do and part of me didn't think it was a thing to do because that's what I was taught. But also I was really nervous. I didn't want to be exposed is basically talking shit because I think a lot of the stuff I was saying was made-up. And so the work we were doing, the only way we ever really stood a chance that we're solving a real problem for our customers and users was by getting our engineering teams talking directly to the customers. But when the goal is simply hitting deadlines and not creating impact, it's a really hard sell. So I've worked with teams that have actually in many, many years working in this way, given specs expected to deliver no involvement in customer discovery, no involvement with the customer at all. And when I first suggested to some of these organizations, some of these teams that they speak to customers, I was told, well, developers don't want to do that, which I thought is just utter rubbish. It isn't true. But no developers, no engineering teams, no one on those at the coalface right, of creating the software products isn't able to talk to or doesn't want to talk to customers. It's this weird thing that we think that teams and people don't get a buzz from that. I think of one particular situation where I was, yeah, challenged on it, saying have you ever worked in an organization where the people in the software teams actually want to talk to customers? And I said, well, yeah, every organization that I've worked in for any long period of time, and I say long, probably six months plus, which I mean, isn't that long in the grand scheme of things. But that's when you really start to see a shift, like actually do have developers that talk to customers or users. And some of it is because they weren't given an opportunity to before. Some of it is because they weren't given the skills, the support or the encouragement to perform. Sometimes it's because the system has no mechanism, has no desire, has no goal to enable them to talk to the users and the customers and focus on those rule outcomes, The challenges in organizations. When you hear these statements, it isn't because that person was wrong in that organization. In that context. Do you know what? The engineers probably don't want to talk to the customers, but maybe some of that's because they weren't hired to. So what I'm saying here is actually if you can put yourself in a position where you can give people the opportunity and the skills to do it, I think you'll find that often teams grab the opportunity at both hands. So when I did this recently, we went through the Lean Product Canvas workshop. I told them some simple interviewing techniques. What do you think happened? The teams realized within hours that what they were about to build wasn't solving a problem that was worth solving. By talking to the user and actually asking them some questions and explaining the solution they proposed and what they thought that solution would do for this particular user, They realized it wasn't going to save anywhere near the amount of time they thought it would do. So they scrapped the feature even before writing a line of code. This was a huge moment for them. Now you some may think, well hold on a minute, They had this conversation with the customer or user and it's ended up with some work not being done. Didn't they feel foolish for coming up with the wrong idea? Didn't they feel stupid? Didn't they feel that it wasted the company's money and nice or maybe a little bit? I mean, that's natural. We're humans, right? And some, you know, sometimes we do get quite sensitive about these things and about being wrong. But the headline for me was that we'd just saved 10s of thousands of pounds, if not more, by able to prove that that solution, that feature that we're going to create, didn't solve the problem. We saved so much money and wasted effort. We were then able to forget the amount of money we saved from all the sprints worth of work that would have got into creating it. We also now able to focus on something that is with more value. It's how much more money, how much more revenue, how much better can we make our customers lives of the power of focusing on outcomes over outputs and not just blindly chucking out something which would have no impact. Now there is obviously a huge leadership mindset shift that needs to happen and we're going from shipping features to really solving genuine business problems. And if you're sitting with your leadership talking about how your organization builds software, then there's a good chance that as part of them that already knows that something isn't quite right, maybe they've seen teams deliver features that no one uses, or at least have a strong gut feel that's the case. Maybe they're frustrated that the business outcomes aren't improving despite all the hard work or the effort or the investment that's going into delivery. All the, dare I say, wasted money spent on agile training for teams who don't really give a shit. They just don't see the value in it. You know, I think we can we could have saved lots of money by not sending everyone on agile introduction courses, but actually finding ways just to get our engineers, our software development teams talking to the users, giving them some interview skills sought the rest. I think back to a time when I was having this very conversation and visible, but now gave back on what I was saying. Actually, if you're talking to leadership, there must be something in them that believes it isn't quite working. Well, maybe this person did, but I was sitting in a a large bank in London in Bishopsgate and was ever been there. And a lovely glass building it was. And the person I was sitting on talking to told me that without a shadow of a doubt, the single thing that has made all of their software delivery was successful. Has been a huge amount of effort into creating a really large, a really large and well defined specification. You scratch a surface on that and what they were successful in is delivering what was written down and not often worth making an impact to the business. And this was a part of the organization which had been exulting the virtues of agile. So I was confused when I asked, well, there's an agile principle. Developers in the business had worked together on a daily basis or worst of that effect. And he said that this is impossible, it's never going to happen. We need the specs. And when I think back about agile and potted history with it, you know what, for me, the most impactful principle was always that is getting the people that are receiving, the people who are willing to exchange their time or their money or both to have something created which makes their lives better, which improves the running of their business or their lives in some way. That you put those people in touch with the people that are creating the software, you give them the right techniques. I think every so much of the other crap that's been taught in agile introduction classes over the years to software engineering teams could have just been forgotten. I really think that we everyone started with the wrong thing. So it's no wonder that leadership are frustrated and as they wanted, maybe are searching forever options because Agile kind of failed, failed to deliver a lot of that promise. And yet they're still seeing more and more on delivery. So the problem is that many leaders don't really know what to do about it. And that's where perhaps, you know, we can come in with some guidance or some support. For me, I've always found influence comes from having a hard conversations about strategy or the lack of one. Leaders, honestly, generally speaking, don't want fluff and they don't want someone telling them that they're doing it all wrong. What they need is someone who understands their reality, who can earn their trust by proving they have real world experience and, and, and in solving these problems and can really help help them and other people understand what their strategy is and how your support can help them make that strategy execution of reality. And then there's also accountability. For many leaders, output is comforting because it's measurable. If they don't trust their teams or they save it, but they really don't. They want a list of deliverables to hold and accountable for. And they fear that the shift to outcomes is going to make things seem too vague and too fluffy. And you know what? I don't blame them. I think all too often people are soaking about value and we've pushed backlogs and privatisation and Scrum and the rest of it. But value, I mean, the one thing I've heard more than anything I said about value, it's really vague. And what is value? I mean Christ value is something that. From a certain perspective, make saves or protects the organization's bottom line and we provide value to our customers or our users to make that impact a reality. So when we're talking about having lists of output and keeping to a time frame and promising dates, it's it's there to control, it's there to get around some of this fluffy value nonsense because we've all been too vague about it. And I think this is the big shift that we can see particularly then going through something like the lean product canvas is that outcomes don't have to be vague, they're just measured differently. So instead of saying we'll deliver a feature X or batch of features Y by Q3, we shift to kind of saying, OK, well let's show progress as we go. Let's talk about the outcome and let's say who is doing what by how much is create measurable goals on the short term, which we can then create hypothesis to test our solutions and always be working towards that. And so we can begin to root our progress in meaningful outcomes. And then we're able to say, and if we've got a good sort of business problem that we're solving. So if that person is doing something new by a certain amount and we can really say this is going to impact this, it's going to impact the business, it's going to solve this business problem, then we can begin to make those vague fluffy value things seem really, really concrete. And I think this who does what by how much is based upon the work of Jeff Got Health and Josh Scheiden in their new OK our book. And for me, that's what make outcomes tangible is what when we're talking about OK, ours, yeah, which want key results. That's how we'd like to have our key results because they're tangible and they're real. We will absolutely then create hypothesis and say, well, if we're going to get the users doing that to get that value, will this solution help? How might we get that outcome by delivering the solution. And we have those conversations and we test them, and we test them as early as possible before writing a line of code through conversation. Perhaps then we will go on and we'll write some code and we'll turn on some prototypes, but only when our confidence is increased, we're really solving that problem. So for example, if we want 20% more users to complete on boarding in under 5 minutes, it's really clear, it's measurable and it's focused on the user and that. And probably if we're talking about speeding up on boarding a problem with that time because we're faced on a customer, hey, customer behaviour rather than feature releases. So this is all great, Ben, well done. How can we get teams started? I think I always start a small experiments to test whether they're solving the right problem. Shifting to an outcome based mindset doesn't have to be a massive transformation. It can actually start in the smallest of ways. So here's one small thing any team can do right now. Find a user, talk to them about the work you're doing, the work you're intended to do, and figure out what they're actually trying to achieve. It's been more specific to pick a feature in your backlog, so debating its priority or going into endless refinement sessions and trying to understand you, what's the task breakdown, et cetera, et cetera, without that user being in a room where there's a proxy. Let's get that product backlog item, all those items. Let's not debate the priority of it because if we're picking it, then surely it must be a priority. Let's get the team together and let's challenge them and say let's find one customer or user and ask them how they currently solve this problem. Ask them what's so wrong with the way they're currently solving the problem. That means that they want something different. Because if we can teach the team some of these basic interviewing skills, some listening skills, and get them in front of a customer or internal user and have that internal customer user tell us the stories that we can listen to. Understand why they're going to be choosing to exchange bandy. Give us their time. Stop doing the thing they have been doing and start using the new thing. Like one conversation can completely change the direction of your entire product, your entire product backlog. We're even just a par for that day. So what is the role of product natural coaches in this shift? Yeah, this is a really interesting one because I think that the market has been tough for many agile coaches and you know, I still see lots of product coaches out there trying all kinds of different ways to entice customers into paying money for their services. You know, I think fragile coaches and product owners, grandmasters, product coaches, you know, our job isn't just to facilitate the meetings or go through and have them fill in a template that is to create the conditions for for better decision making. If you were listening to this and saying, oh, great, there, what we need to do then is just go and get a product canvas or go and get this template and get people different template. You're wrong. Go and get yourself a book called playing to win. Look up the pitfalls of template strategies and you can apply this to OK, ours. You can apply this to product strategy. You can apply this to a product discovery. When we think that our role is to facilitate the completion of a template, I think we're fact. We need to make the conditions about decision making. And that means for us to do some research. It means if you're a product owner, the shift is moving away from backlog management to problem definition of solving. Like stop being the person who just translates the stakeholder request into Jira tickets. Instead, push back, ask what's the business problem we're solving. If you have an answer, then it's probably not worth building yet. And if you think that's scary, you've done that and it hasn't worked, then sometimes it isn't going to work. But you got to try build that context, do some research, influence, impress, be humble, be open to listen, make people like you a little bit and let them open the door to give you that information. The Scrum Masters, how can we help the team move beyond there? We just completed the Sprint backlog as a success metric. Bring in more customer learning. Bring it into the not in retrospectives here, but bring that into the Sprint review. OK, Treat your Sprint reviews as an incurrent retrospective. Get the customers involved, create help, create that customer insight like get the teams closer to the customers. Take a risk. Ask the question. Instead of going through your Sprint review, just going through the list of product backlog items. Begin it by having to answer the question, what do we don't about our users or customers in this Sprint? Prepare them for that. Take that as the goal and have them be ready to answer that question. And fragile coaches. This is much about trying to coach leadership as it is about the teams. You have to help leaders see that agile isn't just for love, velocity, or cycle time. It's about creating real, tangible value which makes, saves, or protects the organization's money. And that doesn't mean blindly following a framework or filling in a template. It means teaching them to measure progress in terms of customer impact, not just output. So my preferred way of doing this at the moment is absolutely influenced by the the Lean UX book and actually the Lean product Canvas. And when we look to engage teams, you know, there's two ways typically that we, I would tend to engage with, with this one approach, and this is a risky 1, is to do a really intensive 2 day workshop. And I've been doing this quite a lot over the last month or so, where teams work through the lean product Canvas. But I've also done 10 research in the background. We begin to look at all of the content that they've been putting up on the canvas as we're going through lots of different facilitated and very excellently structured activities. It's just assumptions to start testing. It's all about declaring our assumptions. Assumptions never approach is spreading out over a number of weeks in two hour blocks. And this is really quite nice because it does give time for people to do some research to then complete something beforehand. You go into the room or the virtual room, you give them some support, you go through and then you gradually build it up over the course of a couple of weeks. Well, this also gives you good opportunity to do is to go away and do more research, do that more learning and kind of gives you plenty of talent to prepare for what's going to come up. Either way, the goal is the same by the end, each team has a hypothesis backlog, a prioritized list of ideas backed by research so they can start testing right away, even if it isn't writing code. But to really make this work, it isn't just about the facilitator running a process. It isn't about me going in there and just kind of going through a fight, a 5 minute by 5 minute schedule and just kind of carrying it all out, you know, going to bang on about it. Again, you really have to understand the company's strategic and product vision and goals here. It isn't about the fillers, it's that it isn't about just filling in the canvas. It's about facilitating Better Business decisions. So if this sounds like the kind of shift your team needs, then drop me a line. Let's have a chat. Yeah, but I'm absolutely happy to help you in any way that I can do by going through the lean product canvas by giving you some insights into the workshop. So I run then please do drop me down on LinkedIn, even very easy to find, you know, if you want help and support and it's something I'll offer for free in defining clear business problems. And so looking at feature requests, if you want some little tips to interview customers to validate what they actually need, if you want to create actionable hypothesis backlogs that really Dr. outcomes, then drop me a line. I'm more than happy to give you half an hour of my time if you're really, really keenly like this. And yeah, absolutely going to sheave.k.uk and they bag yourself one of the limited places we have on some of our upcoming workshops for this. Anyway, that's me done. I've quite enjoyed just kind of venting my spleen a little bit on this and I hope you have enjoyed listening to it too. If you have enjoyed listening to it, like why not share this with someone who you think needs to hear the truth about focusing on outcomes over output? Somebody who is perhaps feeling a bit lost and doesn't quite know where to turn because whenever job market is hard and I thank you very much for listening over the next month or two we're going to be running a few of these little experiments and to see how they land the main, you know, wave. I know how well it lands is by how many people download the episode and the downloads, of course, all of our episodes yeah are still creeping up quite nicely. You know we're running about 30 odd 1000 downloads now since the podcast was created and it'd be great if we can get 50,000 by the end of the year. So if you liked it, share it, put something on LinkedIn or just, you know, feel happy that you got some value from it. If you didn't like it, even better let the world know. Let me know because only with that data, that feedback that any of us can get better. So this is me signing off and until next week. And my name is Ben Maynard, and this is the product at Jersey Podcast.
.jpg)
