Business agility fails when we don't talk to our customers

What do you think of our services, and has it had the impact you were hoping to see? In today's episode of the Definitely Maybe Agile podcast, Peter and Dave talk about the importance of asking for feedback from our customers to prevent business agility from failing.

This week takeaways:

• Validate emergent needs with your customers
• Build a system that can respond to that.

We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com

Transcript

Peter 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts Peter Madison and David Shark. How are you today, Dave? Excellent, Peter. How are you doing? It's been a good week for you. It has been a good week. It's been awfully busy. It's uh been so many different things going on and uh it's been a lot of fun. But what are we what are we talking about today?

Dave 0:31

Well, I was just gonna ask, have you been busy talking to customers, or have you been busy, busy being busy rather than getting feedback and validating that what you're doing is counting for something?

Peter 0:41

You you it's funny you should say that. Um, but uh this week I actually managed to connect with my customers and ask them about well, how do you feel about our services? How do you feel about the work that we've been doing for you? Has it been having the impact you were expecting to see? Um, has it been as effective as you were hoping? And get some feedback about how we're doing and how we're delivering. And and I I know where this is leading, in that one of the things we're gonna talk about today is how um companies often forget to do this.

Dave 1:10

Well, I'm not sure that they forget to do this because what I was gonna follow up with, because this is the sort of you know, the million-dollar question, is is that those conversations that you're having with your customers and getting the feedback and so on, something that you do once a year or once every 18 months as some sort of strategic piece? Or is it something that's built into your process so that as you're delivering it, you're continually refining what's going on? These are the that it's really the habit of feedback than the act of getting feedback.

Peter 1:41

Yes, yes. And that is a very good point, is that having that habit and yeah, no, I I must admit that uh I don't always remember to do this. And that building that habit is a really essential skill. Um, because it if you don't, then you're never really going to be able to build that uh business agility muscle and start to respond to what's actually coming at you from the marketplace. And because your clients are by far the best indicators you'll have as to whether what you're doing is the right thing.

Dave 2:15

It's uh you you started that that sort of paragraph that you just described there with the word that it's an essential skill. And I think I just wanted to hone in on that because there are many essential skills, and we all nod our heads and go, yes, it's an essential skill. And I think if we'd asked somebody 10 years ago, 20 years ago, 30 years ago for the need to get feedback from customers, everybody then would have agreed it's an essential skill. I wonder if today the essential skill is it it's actually has meaning in the way that it hasn't in the past. Because um, clients, customers, the needs of people are much more visceral. They're much more at the surface today, in the sense that you we really see companies that if they take their eye off the ball and don't understand where their customers' needs are moving, they can become irrelevant or obsolete incredibly quickly. So I think there's a pace of change there that means that an essential skill that has always been recognized as an essential skill is becoming one of the top one, two, three things that organizations have to be exceptional.

Peter 3:18

I think you touched on it there. It's that it's that frequency and cadence. Um, whereas before, hey, we'll go do some customer surveys, we'll go knock on a few doors, we'll find a little bit of information, then we'll go away and we will go build something for a year and a half, and then we'll come back and see if we built the right thing. That that that approach is no longer effective uh in that it won't allow you to be able to respond to those customer needs as quickly as you need to be. It's gotta be much faster. You've got to have a much faster frequency of connecting to your customers, collecting that feedback and understanding and changing what it is that you're you're working towards.

Dave 3:54

Yeah, I I mean, just as an example, I would and to put things in context, I was reading a book uh recently written in 2001, which is 20 years ago. It's not like an eon ago, full of technology and digital, you know, case studies and so on. The relevance of so many of the um uh examples being used in that book are completely absent today because this is pre-Facebook, it's pre-social media, it's pre-so many of the it's actually pre-iPhone, right? We're talking about uh in a decade the world that we exist, you know, exist in is completely different from you know what we may have you know gathered our first experiences of product ownership, for example, product management. So I think that the pace of change is is a huge impact there. Um maybe this where I see this exhibited most strongly is in product management. Um a lot of attention goes to delivery, and the the kind of discipline, if you like, that has to be most ready to address some of these things or have relevance around validating customer needs has to be the product management group.

Peter 5:01

Yeah, and there's this the the principle uh boring, I think, out of XP, right? Of Yagni, you ain't gonna need it. This this idea that uh you if you if you don't have that frequent feedback loop, you might not realize you're building the wrong thing. And you're you might realize you're building the wrong thing too late. So you end up packing a whole ton of features in that nobody's ever gonna use, they're never gonna want this, they're and uh it's not fit for purpose. Whereas if you and I remember from years ago looking at this, the example is the used to be and it's becoming less so, but you'd pull out the like the smartphone and the apps are single purpose versus this idea of a multifunction application that does absolutely everything for you. And it's a Swiss Army knife, even though you're not going to use 90% of it. So now you're building something that's much more targeted uh to a particular customer need, and it gets really, really good at doing that.

Dave 5:53

Yeah, yeah. And and we're we're very much uh um as sort of comfortable with that. I mean, there's this whole sort of I think in many uh product management groups that we'll work with, there's a there's a mindset of we know what the customer needs, we have a list of features, we're gonna go gallop after all of those features. And as you say, sometimes it's we're gonna take two years and get all the features built and then ta-da, get hit the market, or it's a case of we've started getting some traction and we're gonna build as many features as possible as quickly as possible. And I think there's a often in exactly what we're talking about, often in the pressure of meeting the next deadline or getting the next feature out, or the excitement of another marketing splurge around some new set of functionality, we don't necessarily carve out the time to get feedback and validate that the value that we expect, the usage we're expecting is actually happening.

Peter 6:49

Yeah, exactly. If if we look at all this, how would you how would you wrap this up into three points for our listeners?

Dave 6:54

Um, I think first of all, uh there's an element that we have to recognize that what's always been an essential skill is event is is is like capital E essential skill at this point. It's something that's very um a critical uh kind of tool in any product manager's product management team's arsenal, if you like. And I think that's something that we kind of have to um encourage and carve out time for. That would be the first thing. Uh a consequence of that, by the way, and I know we're dragging off a little bit, but I just wanted to touch on this is as a leader working as a stakeholder or a champion working with product management teams, we often like the security of a well-defined product roadmap that we can look at and polish up and share and get behind. And what we're talking about when you're validating emergent needs with your customers and users is often that that product roadmap is uh going to change direction. It's going to be something that doesn't have stability that we're used to. And there's something there's something really nice about having the you know that security of a really well-defined plan to get behind. And I think that has the tendency to then the consequence of that is my product management group knows this and delivers a well-defined plan. Now we've got inertia behind it, we've got resources, we've got money, we've got commitment behind it. And now all of a sudden you're in a place where you cannot, even if you validate, even if you find opportunities, you're in a situation where you can't really change gear or change direction uh without it violating, without it breaking the security of that plan. So there's an element there that we need to be very cautious of as well.

Peter 8:34

Yeah, that uh dynamism, the uh this idea that uh we've got to be uh looking at the emergent customer need and be able to build a system that is able to respond to that. It's funny you mentioned commitment. There's the uh real options is a is a great book. There's a book called Commitment that uh talks about real options and the idea, like at what point, what information do I need to know to be able to make the next decision? So where am I in being able to decide that? And how how can I create my options? What options do I have? How can I determine what the next information point is where I can decide which way to go?

Dave 9:09

That kind of uh and what's interesting in the books and the the ideas that you're describing there is at no point is there this uber product person making all the decisions based on their understanding of the market, their gut feel or something. What you're describing is data-driven, you know, observationally based decisions, looking at, you know, can we should we keep investing here or do we stop the investment here and pursue a different option over here? And it's a it's uh it isn't the people like some sort of leader person in the product management group making decisions around this. This is something that has a lot more data, which is that validation piece again. How are we validating the ideas and getting the data and and using that to steer?

Peter 9:51

So so this week's topic has always been about uh the piece of where business agility fails because we don't go and talk to our customers. And uh we were looking at this as the counterpoint to uh the previous podcast we did on increasing profitability and like the efficiency in organizations. So uh I hope everybody's enjoyed listening to this. If that if anybody has any feedback, they can reach us at feedback at definitely maybeagile.com. And of course, if uh if you like listening to this, then share it with your friends and invite other people along. And uh as always, Dave, it's great fun. I always enjoy these conversations and uh till next time.

Dave 10:27

Um Peter, great fun as well. And just as a reminder, this one has all been about customer validation. Feedback is king. So any ideas, thoughts, please provide them so that we can steer our own path as well. Looking forward to the next conversation, Peter.

Peter 10:41

You too. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrick focus on the art and science of digital, agile, and DevOps at scale.