Make Product Play Nice with Agile (With Mike Moran)

Ben: 0:00

Welcome to the product agility podcast. My name is Ben Maynard your host for today and all other days and probably all coming days and we are joined for the second episode with Mike Moran. Hello, Mike. Hi, Ben. How are you? I'm so good. And thank you very much for taking this time for making this time. I didn't know you could make time for taking this time out of your evening to talk to me, Mike, it's a, it's awesome. And we're doing this very close to the release date of the episode, which is a new one for us. So I'm excited at how quickly this is going to get out. So we can talk about current affairs. Oh, nice. Or maybe we could not talk about current affairs, because they're crap and they age like milk. But maybe what we could talk about is how do we take something from cradle to grave, whether it's a feature or a product? I think something that many of us struggle with, whether we are founders, whether we are product leaders, whether we're agile coaches or a development team, whether we're in marketing is we're going to. Some is going to go from the beginning to an end, but who needs to be involved in what conversations and when, what types of techniques and tools and frameworks and approaches can we use, which makes sure that actually, when we do get together, we're having really meaningful conversations that are just increasing the probability of our product being a success. And also then, well, how do we. Make sure that once it is out, we carry on talking, things continue going smoothly. Now, in our previous episode, Mike, it was an exploration of going from sales led to product focused. And so this is a nice, I jumped to that. It's a nice it nestles along quite nicely. Yeah, I

Mike: 1:33

think it does. Yeah. And it's it's a subject that I like hugely because I think it's I think it's really unique in terms of I. Really enjoy getting into the psychological aspect of people and every good product really understands the psychology of of its users. So,

Ben: 1:57

you said like you really, got the psychology of people, but yeah, spoken like a true serial killer.

Mike: 2:04

That's it. Yeah. Like the Jeffrey Dahmer of product.

Ben: 2:08

That needs to go on your LinkedIn.

Mike: 2:11

I have a Jeffrey Dahmer of products. I think it's a, I think it's a good tagline, but yeah, from a lot of a lot of my experience, Ben, from taking new features of new functions, that first part is. One of the, if not the most critical part, understanding what you're looking at. And it could be a massive subject area. I remember when I worked at O2, we did some design sprints and use a lot of design thinking around FinTech and we started off doing a full design sprint, full five day design sprint. And not one person in the room really knew what FinTech was or what the kind of opportunities were. And by the end. Of the week, we felt like we had a good understanding of what FinTech was, but we also understood the problems that people were facing in that financial sector, whether it be getting finance, banking, all them kind of things. And there was loads of great product ideas that came out the back end of it. I think

Ben: 3:10

that's perhaps a topic which is often misunderstood or at least not explored enough is when you are an SME, a subject matter expert in a particular domain. But often what that means is you've got a great deal of empathy for the users. And I think that's one thing that's maybe often overlooked is that we talk about expertise say in fintech, but then being able to layer on that accuracy of empathetic understanding is hugely

Mike: 3:35

beneficial. Yeah. Massive. And I think I think one of the things that's interesting about it is a lot of people struggle to take themselves out of the scenario. I think it's one of the best things you can learn as a product person to be able to remove yourself. from that empathy stage, it's very easy to think, well, why would you have that problem? But then you might be talking about a group or a persona that really is completely opposite to you. And I remember seeing a really interesting example of this was, I was working at O2 and I was working with this guy who was an insurance professional. He'd been in insurance for years and years and years. And we worked with a company called Trove who did like a digital personal items insurance, and you had an app on your phone and it linked directly to your Amazon account and you could add things in there, but also things that you bought on Amazon automatically went in there and where you could buy short term insurance for each. Thing. So if you were sat at an airport and they were very good at pinging you when you were at an airport, if you're sat at an airport waiting to go on a stag do, let's say, and you've got quite a nice smartwatch you could have a look on there and you could cover yourself for five days while you're away. And it might cost you 5, 10, 15, but you'd be like, well, at least I know that if I if something happens and I lose it or anything like that, it's covered. And I remember talking to to this insurance guy and he was like, but this is all covered on your home and contents insurance. 15 for five days is super expensive. And I was like, yeah, but there's a generation out there that don't have home contents insurance. There's a generation out there that would rather know that one thing is covered. for five days for 15 and take out a giant policy, take pictures of things, that kind of stuff. So yeah, it's really hard sometimes for people to take themselves out of that, space and start to really get into the persona. But that's the bit that I really love. I really love trying to put myself in their shoes.

Ben: 5:38

So I'm guessing if we're talking about, and I feel nervous now that we've had the Jeffrey Dahmer comments of talking about from cradle to grave. Yeah. I don't want to have any misconstru any misunderstanding here, we're not actually talking about anyone dying. But, when you're beginning then, They're a new feature or even a new product. And Mike, you're thinking about that process. Yeah. But effectively the product development life cycle, they're all the different steps you're going to go through and who you'd like to get involved in wet and how you get them involved. Tell us that story, Mike from those early stages. What's, some of the first

Mike: 6:11

things you do? Yeah. So I'll take a real world example. Cause I think it's always easy to talk about. I was looking at a fleet based products, let's say last year. And it was for small fleets. So what we realized is we looked at the market and we say, is there a gap in the marketplace for people who are not large scale fleet owners? So therefore I've got loads of products available to them. Someone who is like maybe a plumber or a or a a carpet fitter that maybe has two or three vans with three people in. So the first, when I say

Ben: 6:44

fleet, we're talking. Collection of vehicles,

Mike: 6:46

a collection of vehicles. So and we referred to these as micro fleets, cause they weren't like Royal Mail. They've got thousands of wagons and a couple of stuff like that. And the first piece is to really get into that empathize stage. So what we did is brought in a number of people around the organization. Some who had friends or family who were in that space were parents who were plumbers and that kind of stuff brought in people who were industry professionals who worked in that space in that commercial space and understood the fleet space. And then we just brought in like occasionally. That an odd developer here as well, who might have some opinions on it. So what you had is a real collective mind of people that came at things from very different angles. And one of the things that obviously a lot of us use these days is like tools like Miro for for. Running a session like this. And we started to really get in deep into them personas and deep into them, understanding of people. And it's, that's the bit that's super fascinating. So digging through each of the personas is bringing something different. It's well, plumbers, they want to get to their job. They get to their job. Oh, what if they haven't got the right parts? How do they order parts, get them picked up and you start to really dig deep. And then that's when the creativity starts in terms of starting to think of potential product ideas.

Ben: 8:09

Okay, so you mentioned they're bringing a developer in, I'll pick on that because it's an easy one, you mentioned it, we're bringing a developer in, not for reasons of then letting for development organization know what you're talking about specifically, but more for that breadth of thoughts in the group. And for them to bring in some level of their expertise. So it's more about that knowledge, grief, acquisition, generation of ideas than it is having this person there to act as a conduit for the other part of

Mike: 8:43

the organization. Yeah. In an ideal world. And it's never an ideal world, Ben. I like to bring people in that kind of stage and less about them being a developer, just more about them being a human who can relate to other human like problems with the aim that then that permeates into the team. So if you don't want to take developers away too often to be doing workshops, cause then they're not. Writing code and doing the things that they want to do. Most developers like to put the headphones on and get get cracking with some things. So what you then get is once you start to see, once we get to the end the far left hands, right hand side of the of the life cycle, and we start putting it into the product backlog, you've got someone who was. In part, some of them sessions helps the rest of the team understand the vision and why we're doing certain things. So it's great to bring a different person in at them points. So we're not taking too much away from the team in terms of. Output, but you're bringing people into the consultant to sound and say, we did some really cool stuff. The other day on this fleet piece of work and they'll talk to each other and you get different ideas, but you'll also get the ability in there to say, Oh, well, actually, there's this great technology that I've read about the other day, which can also help spawn them creative juices as you're going through that process.

Ben: 10:05

So what we're not saying here is. Bring in, and I think just to loop myself on there to make my job harder when it comes to the edit, we're not saying when there's a false dichotomy where it's like you bring in all the developers or you bring in no one. What we're saying here is let's, find someone and we, maybe we pick, or maybe someone volunteers to come and be involved in the conversations. And then there is an element of when it does get to the backlog and the teams the, overhead for learning is somewhat decreased. Because there's somebody on the team who was on that journey somewhat and get some of the motivation behind it so they can help the team learn. So then what I'm guessing is then that time gap between those initial empathy, is that empathy, archaeology, discovery, creation element and then it going in the backlog. There can't be too long a time between the two, otherwise the, that person's not gonna have it in the forefront of their mind.

Mike: 11:01

I think you have to bring them along. On the longer piece of the journey. So once we move past kind of the design thinking and ideation stage and we've got a whole bunch of ideas one of the things that I will go through in prioritizing them ideas that we've got is exactly that prioritization. And it'll be value versus effort. So having someone in there with a tech background can also help input into that space. So they may come for an hour session as part of ideate. And they may come and add a bunch of good stuff in there. Then there may be a whole bunch of product management work that the product team take away and play with. Maybe work with some designers for some screenshots for some of the ideas, and then you bring it back to the group. So most of the group that you bring together as part of that design thinking phase, They may not do this as a day to day job. So you bring them in, you get them to dedicate some time to it, but then you get them to go back and then we, as product people pick that stuff up, do some more work on it and then bring them people back in. So we're not taking up too much of their time, but we're involving them at each of the stages. Then when we move to the second phase, which is super critical the, One of my favorites of linking up together the design thinking with lean startup is we get the ability to then test some of them hypothesis. We become very hypothesis driven. If it was fleet management, for example small fleets, and you were saying, well, we're building a plumbing app, if I could. Put in a list of parts that I need for a job and it searches all the different merchants where you can buy them. And it lets me know the cheapest price of the cheapest place. I can get all the parts in one thing. That would be a massive help to a small business, and then we go into an experimentation phase where we will experiment with them, hypothesis and the solutions that we think might fit. Where

Ben: 12:58

in that journey to date has marketing.

Mike: 13:02

So you would bring someone from sales or marketing in as part of the initial group, from a marketing perspective, depends how many resources you've got for a product marketing perspective, usually I'd have a liaison who they may not be involved in the sessions, but I would keep them updated on what we're doing. So any good product marketer that I've worked with before always comes over and says, well, what's the roadmap, what we're doing in terms of discovery, what we're doing in terms of delivery. Okay. What are these things and what are the touch points that I need to be involved in? So they might not directly be involved in some of the sessions, but they are a stakeholder needs to be informed all the way through as we're going through, because they start to get ideas and they start to be able to help pull together that marketing material. And also that kind of market validation for when we start putting together what might be our full benefits case for why we should go ahead with a certain feature or function

Ben: 13:57

or product. So I've really found it a struggle for some. Organizations today when, and how to market and get involved. I think maybe in some organizations, marketing was, it's a, maybe see it as like a silo department that receives stuff they would then you'd force it over to them or vice versa over to you, but in the same way, if that didn't work with the development teams saying it doesn't work, well, we know it doesn't work with marketing. What's much better is bringing them, bringing the right people along from those early

Mike: 14:24

stages. Yeah, definitely. I've seen loads of places where products will do a feature or a new product. Get to the point where it's execution. You think you've got a release date in maybe three sprints time. Then you like poke marketing and say, Oh yeah, can you help us put some marketing materials together on it like that can work. That's, It can work in some scenarios, but it's better to get that involvement in from the start. Well,

Ben: 14:53

there's a huge amount of understanding about who's going to be buying it or using it. If you're going to be marketing it, then that's surely that's useful information.

Mike: 15:01

Yeah. It's a bit like bringing in business analysis as well, right? You get business one of the things about being a really good product person, I always find is product people are quite positive and quite. Yes, this is going to change the world. This is going to do this. That's what product people a lot of product people live, for. And that's why I always find business analysis and products make great team because business analysis can tend to be more, they pull out the things that are. Well, what if this happens and you go, Oh, yeah, that's a very good point. Probably should think about that. What about if this happens? Oh yeah, that's a really good point. What if the prices change on the plumbing parts by the time someone gets there and you go, Oh yeah. You know how often the parts change and then that can form part of your experiment. If you were just left to me as a product person, I'd be like, could I is it technically feasible and would it be useful that you could. Put in a list of parts and get a price for them. Yeah, it's completely technically feasible. Probably wouldn't think, how often do the parts price change? Chances are, if if it was a plumbing example it would, parts wouldn't change prices. It's not the stock exchange. They're not chasing on a minute by minute basis. But if that was the case it might not necessarily be viable.

Ben: 16:17

It's interesting you mentioned business analysis there because the episode that's coming out after this one, in fact, is with a gentleman named Shane Hastie, who has written a book called, well, co written a book called The Rock Crusher, which is about the important role analysis plays in product development and actually how, and is a, as a retort to the agile world, which seems to have forgotten about business analysis or just analysis and the agile world, which really struggles to find a way to get it. Good product expertise with design expertise in as well. His articulate, his book is about how you get those right people involved. And it's just a nice that you mentioned it as an ex business analyst it's something I

Mike: 17:00

was just going to say, I'd be interested to read that because I am a big advocate for business analysts. And I hate that kind of, that agile period we went through where it was like, everyone convert business analysts to product owners. And you're like don't, do that. Just don't do it. That like the job they do is amazing. It doesn't need to turn into being a product owner. That's not like the next step. I'm a business analyst. My next career step. Product owner, it's not, it's that's the two separate disciplines and yeah,

Ben: 17:33

They're really fucked up things. I don't often swear on this podcast, but the really fucked up thing is, like when you don't actually get the product owner. Yeah. You haven't got anyone who's got that skill set to hold the accountability and the prioritization and all they haven't got the skills because in the career they've chosen, then you end up with all these, I say this and I remember reminds me of a situation, maybe you'd be familiar with too, but when you have basically as my friend Kareem was saying, lots of little speed boats, all shooting off in different directions, you don't actually bloody know where you ended up. Cause then we'll just go off in different directions. Yeah, it's a problem. It's a problem. So it's nice to see you mentioned business analysis, but that is, there was an episode coming out after this. So I'll send you the link to that when it's out and I will yeah. And the rock crusher is actually written in with support from the international business analysts association, the IBA. So yeah it's, an, it's a good read. It's a good read. And I think you are, if you're a fan of business analysis and. You'll like Shane's book anyway, let's get, yeah, get back. Let's get back on track though. So we've done we've got marketing involved. We've got some people from development involved. We've done through some design sprint redesign sprint. We've prioritized things. We've been factored in some lean startup ideas to come up with some hypotheses, which are the looking to test before we really invest in creating it. All right.

Mike: 18:59

So once we get through the lean startup phase, so a lot of testing and a lot of experiments one of the things that's really important is making sure your experiments are right. So I see so many times we experiment on things and let's say we experiment two different versions of the truth, like an AB test, for example. I've seen so many places where we test one thing, and then we go and do another test to compare, but the constant changes. You have to treat it almost like a science experiment. If you change the constant, like you use a different data set to run the same test, it's really, you're like, But that looks improved, but is it actually improved or is it just because you've changed materially the bit that we've that we've tested it on. So you've got to make sure your experiments are good. Part of the experiment phase and part of the design thinking phase will be the you spend time interviewing some of these personas or showing them some of the products that you've got, making sure you haven't got leading questions and leading people to the answer that you want. Is is fundamentally a huge part of that. And I think for any young product person or any product person out there, I think the greatest moment of learning is when you go to test a product that you've spent a huge, not a huge amount of time, but you've spent plenty of time immersing yourself in the, problem area, the problem statement, the personas, you think you've got the perfect product, then you got to test. And the response is not good. I think that's a moment of kind of clarity for all product people where you go, ah I really thought that we had it there. And I thought that was the product was going to change the world. And then iterating on that and going back around that cycle until you do find the product without having to invest loads of money before going to market and it being a flop.

Ben: 20:51

Ah, that's a hard message for people. It's a hard thing to take on board. It reminds me of the right it by Alberto Salvoia, which you might have last time I spoke actually, but he talks about. But how can you increase your confidence and seven before you build it? But he calls a prototyping, which is like pretending something's wrong or trying to get some more meaningful feedback. So it's one thing going and saying how do you feel if you, how do you feel when you're afraid of this problem? How would you like it to be solved for him? He's always saying, well, actually, what can you do to really test that? So what can you do to get feedback? Whether they've got skin in the game, because it's like the, it's like the mom test it's easy. Mom would always say it's a brilliant idea, but the moment she has to give you money for it, maybe it's not such a good idea, or she has to go at some time to invest in creating it. And as soon as that skin in the game happens, there's a few other little things as well, he suggests, but then it changes the. Quality of that feedback. And I say this, it's difficult for people early in their product career to just get over so many excitement and try and see things like a scientific experiment. Yeah.

Mike: 21:52

As you were saying. Yeah. Because it's the metrics that you will get from the, from adding some science, adding some data points in there as part of your testing that is really going to drive you forward. Also, it helps write your business case for the investment you're going to need to actually go into development, but it's such an interesting point. Ben one of my favorite forms of testing or experimenting is wizard of Oz testing. So exactly that pretending that it works I heard a great story, whether or not it's a hundred percent true, I can't confirm or deny, but I had a great story that when they were building Amazon Alexa, for example Amazon decided that maybe. Bluetooth speakers could be improved if you could talk to them and just tell them what to play rather than pairing your phone and doing it all on your phone. So they got a Speaker prototype thing that maybe probably looked like one of them desk speakers that you use for conference calls. And they had someone behind a pane of glass with a computer. And they brought people in one by one and they said this speaker is really magical. You can ask it anything. You can ask it to do anything. And it will do it, why don't you ask it to play some music? And you had a guy behind a pane of glass with a plugged into a computer. And they said, oh, okay, then play The Rolling Stones and he'd go on the computer and play the Rolling Stones and they would judge the reaction of the person. The person's my God, I just asked you to play the Rolling Stones and. It's actually playing it and they went through some testing and then they said, well what else would you use it for? And you're like, Oh, it'd be great if I could ask it about timers if it could set a timer or an alarm. All right. Yeah, that's that's, great. So out of that testing, not only did they ratify that if they put the investment into doing text to speech where they could actually get a speaker to play things out of there by just being asked. And get that technology to where it needed to be, a good product. They've also now got a list of sub features and depending on how many people said timers, recipes, or any of the other things that you want to do with a smart speaker they could then prioritize that backlog. So they got really solid tested that said, this product blows people's minds. It makes people feel like the process of pairing your phone to a Bluetooth speaker, and then going on your phone and playing music versus just saying, play music. Makes that feel laborious, the amount of friction, whereas if you asked them and said, look. Have you got a Bluetooth speaker? Yes. I've got a Bluetooth speaker. Do you like using it? Yeah. It's really easy to use. Just turn it on. It pairs. I put some music on. That's all good. And I think out the back of that we saw with smart speakers, they were the fastest adoption of new technology ever seen when they came out. There was the Christmas.

Ben: 24:46

Is that what it was

Mike: 24:47

called? Well, that's what it felt like. Everyone got one. Even my dad got one. And he's a, technophobe, but the fact that he can speak. So it was a great, easy product for him to start using. He's still got it today.

Ben: 24:59

And I think IBM did it with their,

Mike: 25:01

they did text speech, didn't they?

Ben: 25:03

Yeah. And it was actually, so someone tapping away. I mean, it's amazing when you look at the size of the investment you have to make that type of technology real, then it makes sense to test it in some way in a realistic way. And it generates loads of extra ideas. But then Mike said, we've got to a point. Are we able to actually write any code yet? Or are we still

Mike: 25:24

in Portland? I think so, Ben, and sometimes these things will go concurrently together that does just because we've now moved to more of an agile products, the delivery phase doesn't mean that we're not going to stop doing some of the lean startup thing and some of the testing. So we may be in a place now where we've got a cool set of features. We've proved our idea. We've got a benefits case. We've worked closely with our business analysts to write a really good set of requirements and a great backlog. And that's been estimated by the team and they set off. Working on whatever them, maybe them initial features are for an MVP, but it might be the other features that we're out testing one of the big things I like to implement, especially in that phase is I use a lot of Kano analysis and he was working before knows that I bull them at tears with Kano and you've got Moscow and a bunch of other methodologies. Don't talk about Moscow. Yeah, I'm always a Kano man. That's just what I like to look at. and and I think the example there is making sure that you've got, you can't build everything. So you'll end up with loads and loads of feature ideas and plotting out them feature ideas using Kano analysis and ensuring that you pick the right ones. And you've got the right blend of features. It must have, otherwise it will just completely disappoint customers. The features, which are quite nice to have. And some differentiators or even just a single differentiator makes all the difference in a device. And I I think I'm always really passionate about that because I lived through the iPhone. Launch in 2007. And at the time I had a job for orange in the UK where I tested all new devices. So I spent virtually every day with new Sony Ericsson's, new Motorola's, new Nokia's, and I remember the iPhone being announced and there was so many features that were missing it didn't have 3g, every other phone had 3g, didn't have 3g, didn't have MMS. And I remember saying. It won't be a success. And there was part of me that there's part of an allegiance to the network you're on and it was exclusive to O2. It wasn't on Orange. But I was like, I wouldn't get an iPhone. It hasn't got any of the features that a load of the other phones have got. And its camera's only 2 megapixel. But it had the differentiator of the App Store and being able to get apps that could do things for you, help you with travel and them kind of things. The rest is history. The rest of the devices have Died off. So you don't have to go to market with every feature that your competitors have. And a differentiator, you can miss out some of them features. If there's features that people are like, yeah, that's, yeah, it's an okay feature. I don't use it every day. It's not a must have for me. So I think them bits are really important. And then you can have the kind of two cycles going together where you're testing some of the extra features that you're going to bring in versus the features that you are currently still in delivery with.

Ben: 28:23

It reminds me, and I was just looking for the person's name, but there's a lady who I interviewed at the productize conference, who's the product manager for Chrome, who uses the car name model a lot and how they are prioritizing for joy and how they've. Could have come up with a calculation to calculate what does joy really mean? What does it look like? And it's really fascinating and it is available on our podcast. I will dig up her name in a second, cause it was a really fascinating, very short episode about how they still use it. And I remember she said to me at the time, I like I use the. The Kano model. I know I'm a bit out of date saying that it's embrace it, right? Let's let's talk about it, but she gets a huge amount of value from it. And I did, I have looked and is it pronounced Kano or Kano?

Mike: 29:12

I only pronounce it Kano cause there's a rapper, I think, called Kano with the same spelling, but you're right. It probably is Kano. It's another one of the great agile Japanese things that came out around car manufacturing.

Ben: 29:27

Well, sure.'cause Kano was a character of Mortal Kot. Oh he was? Yeah. See, when I hear Kano model, I think of Mortal Kot.. But yeah, I like it. I mean, don't get me wrong, but I've I'm discovering that I enjoy. Disco meaning, I like understanding things and anything which is analytical, which enables me to almost put something somewhere, even if it's temporarily just put something on a grid or label something. I like that. I like understanding the meaning of it. So I've always liked the Kano, Whatever it is model because it does allow you to put it in there. And the mobile phone examples is always a fascinating one. Do you have to reach feature parity or do you just have to go out there, that killer feature? And that's a, it's a great thing for people to look at. And if you can then find ways to measure the levels of people, delight or excitement and joy and factor that back in, then surely you want a winner. But one thing I wanted to delve into, I know we haven't got a huge amount of time left, but. And there's lots of agro, agitation between the agile agile development teams and product and how it all comes together. And by the way, you explained it all felt like, ah, just it's just smooths in, like a nice, way. But so what have you found makes, makes for a successful interface between the

Mike: 30:43

two worlds? So this is where, when we were talking before, Ben, about bringing people in and keeping people updated about things that are going on, there's some things that are really great to do. I think sometimes, especially if you've got a product owner or product manager with a dedicated team that looks after a product area, right? So let's say you've got, you're going for the tribes model and we've got a tribe that works on identity or something like that. I think it's worth sometimes as well, the product manager articulating in standup, the activities that they're doing. Now, I don't know if it's the right or wrong thing to think. My personal opinion is if I've got product managers that spend all of their day with the, agile development team, like almost handholding, they're having to talk about every ticket all day long. Then we're doing something really, wrong. The pro the stand up in the morning is a great place to go answer any questions that come in, find out where there's anything that could be blockers, where you as the product manager need to either go speak to someone else, try and help clear them blockers, or work closely with the team to to undo them blockers. Then after that, your day should be freed up to be going and doing stakeholder management go in and testing and learning about. New feature sets, prioritizing your roadmap, any of that kind of stuff. So I think by bringing people in at all the different stages, it leads for a less frictioned kind of environment because you always get that friction. you you never won't get it. But I find if you've done everything, all the upfront bits on your own, and then you go into the squad and you say, this is the thing that we're going to do, and the first question is quite rightly so, well, why are we doing this? What's it about? What's the vision about and sometimes you may have spent a large amount of time kind of preparing all these things and then you find in yourself having to take. Maybe to explain to the team why we're doing it so they can get behind it. And that's a huge amount of overhead. Then you don't want to get down to get into your first sprints and having to take effectively like a sprint zero type exercise where actually we're just doing tons and tons of me. It's so what I like to do is I like to keep people informed as you go through. So that they know these kinds of things are coming up, they've got some kind of knowledge, drop it into things we get towards like sprint reviews as a product manager, give something back to the team. Say, do you know what I've been looking at over this last couple of weeks, I've been looking at how we might move into the world of FinTech or whatever it might be that we're, doing. So you pre preparing it. And then when you go from. We've tested a bunch of stuff. We're actually going to write some code and start producing a feature. That's when I always organize a kickoff session, try and get pizzas, try and get people in the flesh. And then I think the product management team, maybe even bringing some of the external stakeholders. So if we're in an organization that's got sales, I'll say, look. You're the sales guy's been talking to three customers about this thing and why it's super important. Can you come to this session or even an external speaker? If you've got a customer that's that, that was the one who raised the problem and said I'd really like a product that does X bring them into, the space. And then hopefully in a single day, You can bring everyone up to speed to where you are. And then when the tickets start coming in, yes, you'll get the friction of, well, how are we going to buy? What's our build patterns? What are all these kinds of tech things, but everyone should be really clued up on why we're doing it and what's important about it. And also be really enthused, right? There's nothing worse than a development team building a, building something that they think this is a completely waste of time. What, why are we building this? You want to get them excited and get them on the journey. I

Ben: 34:32

wonder that in doing what you suggest, and I'm not at all challenging it, it's very similar to what I have done and will continue to do because I think it works. And what I find fascinating is that we've spoken about the stuff, the physical stuff you can see, the knowledge sharing, the learning, the building of empathy. But the magic thing, I think, between all of this is actually you're creating a dynamic, like an organizational dynamic, so that people know. Different communication styles, what people would like, what they don't like. We're giving people some common connection on certain things. You're enabling people to get to know each other, perhaps on the coffee breaks or something else, to create those connections and help make the dynamics so that you can actually communicate with ease rather than be all janky and saying, well, here you go, here's the stuff you've got to go and work on. And everyone's well, thanks. And yeah, with no no like stroking of your back or like nothing, just here you go, have it. And then that means, makes people feel like shit because they're like, well, you don't respect me. How am I supposed to work with this? And then you're just going to work to whatever you think you need to put out there. You're not going to be infused or motivated. And some of that is that they're learning on the why, but so much of it is dynamics. It's that invisible stuff, which kind of keeps everything's moving, everything moving, which I think from what you're saying is you're helping to. Create that with the pulling in of the right people at the right time. I

Mike: 35:53

think one of the things that one of the places where I saw this and it was a bit of an epiphany moment when I worked for O2 and we worked on a product called O2 Drive, we had a core team on the kind of business and market inside of which. Being the product person you were involved in. So you went to them sessions and you would work with the director of the digital area. And they'd say these are our targets for where we want to get to in terms of users and all that kind of stuff. And we'd have we had a head of product marketing. So I'd work really closely, a woman called Elizabeth Pondsford. Brilliant. We used to work together on these, the messaging, this is how we're going to put it out there. I'd work with a team on these are the ideas that we've had for features. And then, oh, two was. beautifully positioned place in terms of how the building works. You had business on one side of the office and kind of engineering and that kind of stuff on the other side of the office. And there was a bridge that kind of. Join the two and as the product person, I'd be the person who was backwards and forwards between what was the engineers and the developers and the kind of business side of things. And it was a really big building and we had a Costa coffee down at the bottom and you could stand on each floor and you could see right down into kind of the little foyer bit. And I remember looking down and seeing four members. Of the O2 drive team stood in the queue for coffee with about three of the developers who build the product. The product's been going for 18 months, two years, and they're sitting in a queue. And it was the moment I realized they don't know who each other is. They all spend every day working towards the same goals. They're stood in a queue and don't know who they are. And then that was a piece where you go, this would be a lot more simple if they knew exactly who each other was. So when I talked to the development team, I said, look, I've been talking to Elizabeth and I actually think this is a really good idea. And they're like, who's Elizabeth. And you're like, Oh, well so we started doing more where we invited them guys, because one of the things that you had is we were technically different business areas as well. So in that kind of large scale corporate environment, the engineers were part of an it delivery piece that you pay wooden dollars to, to get a team. So you went, Oh, well, that's the team that we pay over here. And this is the kind of business team that's working on this problem. Once you start to break them barriers down. It definitely helps a huge amount more. And you get more from it because you've got more people who are engrossed in the product, sharing their ideas and their thoughts about how you can improve it and move it forward. Love it. It

Ben: 38:29

reminds me of the conversation with Shane on this episode coming up next, where he says as a, as an analyst or a product person, then you should. And excuse the metaphor, it weirdly overlaps what you were saying, but to be a bridge, not a ferry all the time, you're taking information from one shore and giving it to the other. Then you're always in situations where both inhabitants of both shores can be standing next to each other and never know if you can make yourself a bridge so that people can come across and actually meet in the middle. Then that's the goal of what we're trying to achieve with all of this. And Mike we are, at time. Sadly, I thought we could keep going for a bit longer, but we have. Got to the end of a nice episode. I feel, and let me try and do a recap. Let me see if I can get this right. So we spoke about effectively it's a product development lifecycle, but how do we take something from cradle to grave? Really brush over the serial killer statements. I don't want to go there, but we spoke about where you start when we talk about coming up with ideas and building empathy and getting the right people in the journey, when we're moving into you saying in your experience, you enjoyed doing design sprints and then use value and effort matrices to, to understand that which work is going to be prioritized and then about how do we kind of experiment and we understand that these hypotheses that we've created about what we think could be good features, how they can. How do we prove or disprove him? How do we get data, which can then go into our business case? You then also went on to explain how use things that the carnet model to then prioritize your features and work for the look, look for the things that are going to delight people. And then how we look to help create a good interface between product and the agile development teams, even if they are in a separate part of the organization, say that actually, yes, they understand the why, but they also understand what's some of what's on the backlog. Some, maybe not all of them do, but importantly. And this is where we got to that last moment is the dynamics. You've built some core dynamics there, which enable people to communicate easily and without fear. And I think for me, that's one of the best things. One of the things I've taken away from everything you said, Mike, is what can we do to create environments where the dynamics are such that people can communicate freely and easily and without fear, because I think if we can do that, then all the different, doesn't matter how the organization is structured, power handing things over, then surely we're on the path to success. So Mike, thank you so much for your time. As always, we'll put your LinkedIn details into the show notes. Before we end, is there any closing thoughts you'd like to share?

Mike: 40:59

No just well, there, there is actually, but yeah, I would say never stop learning and never think that what people want and always be willing to embrace when people. You find out that people don't like the product that you've designed. See it as a great learning step rather than take offense to it. I've seen too many people in the past create a product, test it, go through these kinds of cycles, and then find that people don't want it. And then feel like they're doing it. Personally against you, it's just get back to the drawing board. Just constantly learn, constantly rethink, constantly iterate, and eventually you will succeed. Awesome.

Ben: 41:43

I don't know, sage words. I thank you everyone for listening, Mike. Thank you very much for coming along. And we'll be back again next week.