Ep. 105: Exploring the six myths of product development

Peter: 0:05

Welcome to Definitely Maybe Agile, the podcast where Peter Madison and David 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 Sharrock. How are you today, Dave?

‍Dave: 0:20

Dave Brilliant. Well, I've got a vacation coming up, so I'm all smiles, as I just currently delete one email after the next.

Peter: 0:29

It doesn't matter, you need the next two weeks.

Dave: 0:31

It doesn't matter, I'm going on vacation, so it's a great end to the week, a good opportunity for us to have one of those relaxing chats that we like to have once in a while.

Peter: 0:39

Yeah, I'm quite looking forward to this one. It should be interesting. So you want to introduce the topic for us?

Dave: 0:46

For sure. So there's a Harvard Business Review article, and the Harvard Business Review article that we were looking at is six myths of product development, which sounds so relevant, until we realize it was published 10 years ago. But it's one of those things that you kind of come across when you're doing a bit of research to try and maybe provide some insight to leadership teams that we're working with, and it just it's so relevant deal, in fact in some ways, I think, even more relevant today than it was 10 years ago or 11 years ago when it was first written. So the article itself is written by Stefan Tonka and Don Rineitzen, so you know, great kind of pedigree in a thought process of the ideas in the article and the authors explore six myths that I think we still today we've been talking about this on many episodes still today bump into around product development and specifically really digital product development and how it's different to what went before would be the way I would think of it.

Peter: 1:48

Yeah, and the interesting thing that we were talking about this before is how we're still running into these problems. All of the time we see this and there's this sort of we still haven't managed to solve this within organizations, even where we well, when we help organizations solve these problems, but we still keep running into these problems. We keep seeing people go down this same path. So there's almost a piece of like well, what drives people to think that this is the right way to go? This is the right way to solve it.

Dave: 2:15

Well, and I think well, we should start going through some of those myths in just a moment, but I think one of the starting points that we have to recognize is perhaps two things. One is the article really is contrasting physical manufacturing ideas and what works really really well, let's say, in a factory setting. So think lean, think sort of project management where people are moving widgets backwards and forwards and coordinating activities there to digital environments, and digital environments were moving information, and it's a very different thing. Information is not something that's on a shelf. There's one of them. We know where the shelf is. We can go find it. Information is something that you and I can both have copies of the same information.

Peter: 2:55

Maybe they're copies.

Dave: 2:55

Maybe we're working in the same place and we can be doing this in parallel, and there can be many people doing it in parallel. So it really changes how we go about dealing with the work, and I think that's some of the foundation of these myths. Is this difference in the context within which these are discussed.

Peter: 3:13

Yeah, the. In the physical world, in a manufacturing setting, you're trying to produce as many of exactly the same thing as fast as you can. Typically, you're not looking to create all these individual pieces, but by its very nature, information is different and there are different elements and it needs to be treated differently, which creates complexity. So let's start going through these myths, and so the first one up is maximize utilization. So I mean, this is an interesting one. We know this. We talk about this from the point of view on many occasions of needing slack in the system, that as a system becomes more and more utilized, it becomes less and less available for work and context switching becomes a problem and this causes causes problems at every layer as well. As we look at organizations, one of the interesting analogies that I use with the more technical folks is talking about CPUs. Like when you load a CPU to its full extent, the CPU thrashes. It's basically spending all of its time trying to swap stuff in and out of memory and your computer just grinds to a halt. And I've experienced this when you're dealing with some sort of electronic device and it's working fine, but you open too many tabs, you open too many pieces and it just gets to the point where it can no longer operate, and part of the reason that is it's constantly just swapping, it's thrashing, it just doesn't know what to work on next because it's trying to do everything all at once and we run into that same sort of problem with utilization.

Dave: 4:32

Well, let's bring the people into it as well, because I think we're a little bit of distance there. There's certainly an overuse of overuse of processes and systems and so on. I think and we were talking earlier on just in that context piece about people working in physical environments and this is where project management, that project management mindset of how can I make use of your skills most effectively begins to be a focus on utilization because I need you in a particular place. If I think of a surgeon within a hospital, any time that surgeon is not in the operating theatre or preparing for or closing out the operation is a costly waste of that surgeon's sort of cost to the hospital, for example. So that physical bit means that we're going to want to know how to optimize the utilization of those key skills there. Now, if I translate that into a digital space, this is where our architects are, our key skilled individuals, senior developers, architects, ux, whoever, these database engineers and so on these key skills suddenly get, you know, overutilized, slammed into every project to be there. They're the ones who you sit down and we're just working with clients a couple of clients right now where they're talking about 130, 160% utilization of some of these key individuals because they're still in that mindset of how do I control where that individual is working? Because that's what we need to be doing and that utilization we know anybody in development just recoils from that. We've had conversations about this in the industry for decades.

Peter: 6:04

Yeah, and it is very interesting. One of the pieces I noticed and I saw this in a recent document and it really stuck out to me was, at any time that you see people being referred to as resources, it's like then, very often, it's there that comes with that utilization mindset. It's like, well, resources are things that we use and things that we consume, versus people. And so one of the things that I often do when I'm talking to the organization is starting to stop referring to them as resources and start thinking about the people that you have and then understanding well, do I have enough people to get this done with the right capabilities and skill sets? And then we start to have a different conversation, just out of that natural switch in language.

Dave: 6:45

And we've discussed this a few times. I think that whole mindset of resources, people is a big piece of it. There's another element, which is the type of work that is being done, and the utilization gives the idea that the task is well defined, that somebody can turn up, spend a certain period of time, the task is complete, they can move to the next one. And, of course, one of the things you find in digital products which is different to physical products most physical products they need to build the same thing over and over again. It's a very you know, unless they were really going in the bespoke area, most of them is repetitive, consistent approaches, whereas in the digital product space, variability rules. Right, we know what I did last week and what I do this week, even though they're quite closely related, could be very different but, equally innovation rules. In the same way, because we want what we did last week to be different to what we do this week, even if the tasks are very similar, because we will have learned something and we're bringing something new to the table and maybe we can do things in an even better, more effective way. So we're now in a situation where that is much more variable, and so the concept of maximizing utilization 98% of use of all of our resources or people is actually squeezing out the value that we can generate in that digital product space.

Peter: 7:59

Yeah, very much so. And let's say, and that that context switching is where this, this, this thrashing of CPU comes from, bringing it back full circle.

Dave: 8:07

Full circle. There we go Back back in the view. Now I think there's a lot more we can just chat about that one, but let's maybe move on. We'll probably keep coming back to it, but if I remember rightly, like the, the second myth is and we're paraphrasing. Of course they're much pithier in the article itself, but the second myth is basically working large batches. If you know what you're going to do, let's do as much of it as possible all at once. Get it out of the door, and then we'll do as much as possible somewhere else.

Peter: 8:30

And this again comes a little bit to that sort of utilization.

Dave: 8:33

If I have my particular skilled person in the room I should use, I should get all of the work done by that skilled person in the room right then and there in a big batch so that when they leave I don't have a dependency that's overhanging.

Peter: 8:46

Yeah, and this, this, especially in the DevOps space I spend so much time in the is. It's the risk element of it is the larger the batch, bigger the risk, because there's more change, as simple as that. So you need to make those batches as small as you possibly can so that you're reducing the amount of risk involved in the change that you're making into your running system. Yet we very often, you see in product development this drive towards well, we're going to put it all into one big batch because it's painful to make these changes. And then, when we, of course, the thing that's painful is the thing you need to do as often as possible so that you get good at it, and put that instead, we like we'll do, we'll do our release, like once every three months, or we'll do it every six months, and it's like, yeah, which makes it really risky and very, very painful because you don't do it very often. So you forget steps and stages and everything breaks. So what?

Dave: 9:34

you're describing. I think there's a really great undercurrent in the article, which is the economics of getting work done and I think one of the key recognitions is that in the physical factory setting which the physical setting of getting work done, the economics of that is driven by efficiency because you can measure it and it starts with the whole. You know Taylorism and time and motion studies, but just the idea that you know, we can see cues, we can see problems, the cost of those is very real. So the economics of the process are the critical drivers. Because of the lack of variation, because of the lack that there's no need for the innovation. What's interesting in the digital space is the economics of the wrong driver, exactly what you just mentioned about resources over people. Thinking of in that way is not helpful. But just as equally as if you look at the cost, you know that big cost of getting a change out. We look at the economics of that. We say is costly to get a change out. So don't get changes out often because it's costly economic viewpoint and it's not recognizing the hidden cost of continuous change and innovation in that product, which means I actually have to get the change out early and often in order to minimize the risk, minimize the hidden costs of those changes. So we've got these two economic models coming together and, as you mentioned, when there's a high release cost, when we have a product mindset, a digital product mindset, we're going to look at that high release cost and realize it should be a low release cost. So that we can get changes out all the time so we can reduce the batch size, because that's how we protect ourselves from the risks of innovation and change of variability in the product of the building In a factory setting it's the opposite.

Peter: 11:12

Yeah, and reducing your cost of release is actually a good thing to look at and measure. From a KPI perspective. It's like what is the cost of release? Because I have seen multiple organizations where they've made the decision to release faster without looking at what their cost of release is, and they've gone from releasing twice a year and costing them, say, 100,000 to they're now doing that monthly, which means it's costing them one and a half million. And because they never looked at what the cost of release is and they're still having these massive release weekends. They're just doing it way more often and with the same of people. So there's that piece of it to look at too. So the next myth is about sticking to the plan, which is something that we strongly stick to our plan of getting through all the time. Yes, exactly as we stick to our plan of getting through all six of these myths. So the sticking to the plan, which is the next piece here. So, apparently, there are times you want to stick to the plan, maybe not, we could just veer off somewhere else. But the sticking to a plan is always this problem where we start off in one direction and we continue in that direction, despite what we might have learned along the way. So, even though we may have learned that this may not be the right direction to go anymore, we're not. We're saying well, this is what we set out to do, so we're going to do it the same way we originally started and we're not going to change anything about our direction as a consequence of this.

Dave: 12:35

I feel that the sticking with the plan because this is something that we bump into all the time and I think I'm having some great conversations about how agile DevOps, sort of the approach that that community takes to project management to get in work and committing to dates and understanding what they can build how that varies or contrasts with traditional project management approaches, and I think one of the key differences that we have to and we kind of need both we've talked about it with data centers and things like this you kind of need a little bit of both. But one of the interesting things is the cost of change in a physical environment and the cost of change in a digital environment. And the cost of change in a physical environment is high If I have a factory and I'm building something, if I'm building a building and in construction, the cost of tweaking that and changing my blueprint to build in a different way for the most part is quite costly, depending on exactly what you're changing, and so that cost of change that means sticking to the plan is really important to reduce the cost of change and so on.

Peter: 13:32

In a digital environment.

Dave: 13:33

Cost of change is basically falling to zero, and in that context, change then becomes one of the tools that we have to navigate our way to a successful solution, and that means sticking to the plan is actually is removing one of the real benefits we have of building a product in a digital context.

Peter: 13:52

Yeah, so in a digital context, we want to plan to create options. We want to plan to open up paths forward, because by doing that we open up what possible ways we could go, but we have to be willing to actually then take those different paths. So that's. The other side of this is that even if you start to operate that way, sometimes you run into the problem that people don't actually want to. There's a sunk cost piece of it, like we've spent all of this time and this effort and this money and going in this direction. Changing is we don't feel comfortable changing, and I suppose some of that comes from if you leave too long between your points of decision.

Dave: 14:32

Yeah, no, that makes a lot of sense, and so that kind of leads aside. And I think the fourth one here is is a little. It stands out a little bit in my mind when I'm reading through this one, the fourth one is basically saying the sooner we start something, the sooner we finish it. So this is that I'm trying to? I've been kind of thinking about this one, how to understand it. This is the moment we have a bit of slack time. That focus on utilization means we're likely to pick up the next piece of work and start working on that, and the sooner we start, the sooner we're going to work through all of the steps and therefore, the sooner we're going to get to the end.

Peter: 15:03

Yeah, so it's almost a rewording about utilization, one in that sense, because, because there's one way, it's an interesting statement, but sooner we start, the sooner we're done, because in one sense, that is true. And it's the sense that they mean it isn't so it does stick out in that way.

Dave: 15:20

Well, yeah, and I've been trying to think it and I think part of this is how I've seen this play out, in the sense that funding year starts. I remember one organization the funding year started literally the day after the funding year started, 100 projects started immediately and there's that idea that in order to get finished first, you have to start quickly or get finished sooner, you have to start quickly, and that's counter. Of course, in a digital context, we talk about limiting work in progress all the time, and of course, they do in a lean context as well. So it's not something that is kind of tied just to limiting work in progress. I think a part of it is that utilization pieces.

Peter: 15:58

We want innovation.

Dave: 16:00

we want slack time to allow people to be creative and a mindset that says hold on, if you're not working on project X or product X, you've got capacity there for me to go over here and do something over here, like decrease. It's almost like reducing the energy level or creativity level in the organization.

Peter: 16:17

Yeah, I think maybe the stop starting, start finishing might be another way of looking at this, like where we're actually looking to finish work before we start new work, that we're not trying to do everything all at once. As a consequence, we just keep starting projects and we're just starting and starting, and starting and starting, which then cause overload to system.

Dave: 16:36

Yeah, well, and I think about the efficiency and effectiveness kind of you know there's two ends to that particular axis and sometimes we're too heavily and a lot of the kind of project management heuristics really push towards the efficiency side and lean six sigma and things like this as well, whereas when you're in an innovative variable space, we need to drift over to the effectiveness side a little bit more, which means not starting everything like you say, not not being pushed to the next thing and the next thing and the next thing, and something of actually saying we're better off just giving a bit of space so that we can make a more effective product, so we can be more effective on what we have to do.

Peter: 17:16

Well, that's a nice segue into the next one, right Number five.

Dave: 17:21

So how, yes, how many things should we build, right? Yes, the feature stuffing. This is what I always think of feature stuffing. If you're going to build a product, then every little idea comes out all over the place from the stakeholders and we shove it all into this product that's going to go out of the door, because that's the best thing that we can do.

Peter: 17:39

Yeah, it's interesting, isn't it? It's. Let's take something like Microsoft Word, where you like all of these other features, in of which we use a tiny number, and we don't really look at them. The other analogy that I often use with this one is the like the app on the phone, where we where the beauty of the original sort of app in the app store was it was. It was a single purpose that just did the one thing that it did, and it did that thing very well, and people just made it more effective at doing that thing, and if you needed to do something else, you got another app. You didn't have the original app you had. I find it kind of interesting that you're also seeing, though, a rise in what they're like the ultimate app, like where Twitter is well, x, twitter, x, twitter X.

Dave: 18:23

I'm just gonna let you find your way forward.

Peter: 18:26

Yeah, look at how you put all that into it. But anyway, x, the company, xr, because what are the? And that universal app that they're looking to create there? I mean, it exists in other parts of the world right, where you basically have all of your like financial services components to get a loan, to look at your accounts, to transfer payments and communicate all of these pieces all built into the same app and it comes an app of apps essentially. So that's that kind of pieces kind of gets interesting there too. But this, this kind of belief that the more features you have, the more customers will like what you have, versus what customers actually mostly want, is they want something that does what they want really well and does it smoothly and does it quickly and is easy to use, depending on what criteria are driving that. I mean, you need to ask your customers what they might be, but this it's not about having something that does everything. Like adding more features might not necessarily make your people want to buy the thing that you're doing.

Dave: 19:29

Well, it's. I'm just as you're describing this. I'm just thinking why is this the case? And I wonder if it's to do with so. If I think of buying a car, for example, we all know what to expect when we step into a car with it's a very, very mature product being around for a while. We know what we're going to expect. There are requirements that we expect to have in there, but if you think about when you're looking at a brand new car. one of the things that's quite a bit of a delight is when you find those little extra touches, when you walk in and you suddenly find this holding a spot for your sunglasses, or there's some little massages. Yeah, okay, let's not go too far, but yes, I mean, it could be that. Yeah, I mean, but there's these additional features over and above an existing mature product that are actually the delighters, because you kind of go oh, that's not something I was expecting to have here and so, and if you think of things like Kano analysis, when they've got the mandatory, you know must have the linear feature model and then the exciters and those linear features. part of the thinking behind that is the more of them you have, the more value you are creating for your customer, and I wonder if that's a function of physical products that have been in the market for many, many years and we understand very, very well, so that when we see them, the additional features become the little delighters that actually draw us into those products. In the digital space, simplicity has been replacing, because we're dealing with things with a thumb on a phone.

Peter: 20:55

Yeah, we don't want to do everything.

Dave: 20:57

Yeah, we don't want it to do everything, we want it to do exactly what I want to do right then and there. And I think that's a big mindset difference. But if we're used to working, understanding product in the old way, in that sort of the more features, the better off we are, we now are trying to do exactly the wrong thing in the digital space because it's a different place.

Peter: 21:18

Yeah, for sure, we're at the last one Number six, get it right the first time.

Dave: 21:23

Right. This is yeah, it's actually a great follow on from what we a segue from what we were just talking about, because there's that element of, yes, we need to build as many features as possible, but also we need to get it right straight away, and I do maybe, you know, just in a follow on it's a little bit of the we know this product space really, really well, we're very, very good at it. So if we're going to build it, we're going to think about it, plan it really well and then you build it once and you build it right the first time. Basically. And of course that doesn't allow for innovation, it doesn't allow for variation, it doesn't allow for learning as you build.

Peter: 21:54

Yeah. So, as I put, this was the like. If you know, room for failure means no room for experimentation, means no room for learning, and that, as you say, it's that's where that problem comes, even if we're saying that we're going to experiment, and very often it's like, well, the experiment isn't allowed to fail because, well, obviously we know what we're doing, so that means that it's not really an experiment at that point. And this takes us back to some of the earlier points we were talking about around the like sticking to the plan. If we're not, because the if the plan is right and we follow the plan, then that means we're going to get it right the first time. Right Because because we already know what it is we're going to do, because we're we've already laid it all out. But that's only. That can only be true if it's something that we've done many, many, many, many, many, many times before. And even then there's going to be some variants, some something that's going to mess up the plan. So even in a physical world where there's always going to be, you know, thunderstorm comes through and sort of swamps out the building site and this means you get delayed as a consequence. So there's always going to be variants, or external influences potentially which are going to derail things. This idea that we will be able to get something right the first time, every single time that we do it. It is a fallacy. It's like we know this, we know things, we know from experience. That isn't the case yet. So often you see people build out plans of attack to things which have no room for the idea that we're going to have to learn as we go along.

Dave: 23:21

Well, it's quite interesting that this is the last, the sixth myth, because it's also probably one of the ones that lingers the most. Because, as a leader in an organization, if I'm used to sticking to the plan, if I'm used to getting all of the requirements to find upfront and building them out and successfully launching a product that hits on the market because we've got things right, we start doing things like managing to. I remember one organization. They managed to on time and slightly under budget, like they had a target. You had to be on time and you had to be 98% of your budget. That was considered success. Other organizations they talk about. Set a plan, hit a plan. So, all of these are like real mindsets of get it right the first time. That's, stick to the plan, get it right the first time, and it drives learning out of the organization. We talk about learning organizations, peter Sengge's work and so on. Well, it is based on making mistakes and learning. Well, if you've got to get it right the first time, where is that opportunity to have a learning org? And the reason I kind of mentioned that is one of the struggles that we've certainly seen. I've seen is a lot of leadership where they pay lip service to the idea of this sort of agile and devops approach, but then they get very agitated when things don't go according to plan and they don't get the thing they want right the first time.

Peter: 24:43

Yes, yeah, I've been. I've been there for some of that agitation.

Dave: 24:49

Well, I mean, it's even to the I'm just thinking of product owners and stories, the number of product owners that we work with where their expectation is that when they put this user story in, I'll never have to solve that problem again.

Peter: 24:59

Yeah.

Dave: 24:59

And instead of recognizing it as this is a stepping stone, we're going to go build something. We're going to look at it and scratch our heads and go not quite what we were looking for and tweak it and keep modifying it until we get to where we want to go. Instead, there's an expectation. If I get this piece done, I can turn my attention to the next thing, and the next thing that rather than a recognition that this is dialogue, and it's a dialogue with some sort of physical activity in between, where now we're gradually learning and get getting better as we go.

Peter: 25:26

Yeah, for sure. So should we wrap this up? Sum up the six, myths Six six minutes.

Dave: 25:32

I thought you said six minutes there.

Peter: 25:34

Yes, we should wrap it up.

Dave: 25:35

There's a lot that you know. It's an interesting because the articles only got six minutes and you look at it and you think, well, what could possibly be there?

Peter: 25:43

And yet there's such depth in these myths For sure, and so so just to recap for a listen. There was the myth one was the maximized utilization, and myth two was the do work in large batches. And three was the stick to a plan. And four was the the sooner we start, the sooner we are done, although we came up with a few different variants on that. And then five, there was the more features we build, the more customers will like them. And number six was that get it right the first time, so I like it. I think it's a good list and the actual article itself is quite long. There's a lot of information in there about all these different pieces.

Dave: 26:20

And three, things that really struck me, and I don't know that we'll keep it to three, since it started with six, but let's, let's try it out. And so there are two things I really wanted to draw attention to one is as I was going through that article and even in our conversation. I think a big realization is the different, the different role that the economics of what's going on play and how that economics of cost saving and optimization, which is so prevalent in the sort of non product space that that is being tried to talk about, has a detrimental effect in the digital product space. So we have to understand that economics thing. I think that was a really big takeaway as I looked at that and we discussed it.

Peter: 27:00

And the second one I just wanted to pull out.

Dave: 27:02

What you mentioned, which is the plan to create options, and that one is is almost like completely opposite to the mindset that we're kind of contrasting with in a digital product mindset. It's all about creating options, learning, managing variability by how, always having choices, which is a very, very different mindset, to contrast with this sort of physical product development.

Peter: 27:24

As to you want to bring something in, sure, I think. I think one of the pieces I was thinking about in the back of my head was in like the translation of the product into it's like operational life, and how we look to also generate learning in that space to and how that can then feed back into the system. So I'm starting to think down that right, but it might be going a little further, like some of the pieces there, where we've run into a lot of these in the operational space too, as well as in the product space, where we start to get too fixated on doing things in one particular way and, as consequence, change becomes harder and so we don't end up taking the right actions as a consequence of that. So I think there's some interesting takeaways here outside of just even the product development space, or at least extending that all the way through into the sort of the operational management as well.

Dave: 28:12

Well, I mean, I think it's that whole idea of digital product being dealing with variability, innovation, creativity, so even in the operation space.

Peter: 28:20

It's still a digital product and there's still significant elements which are continuously changing and yeah, and we want to generate room for learning and we want to create that learning, which is why we well with it, we get into other topics. Maybe there's a topic for another day around SRE and chaos engineering and things like that so awesome. So, as always, you can get hold of us at feedback feedback@definitelymaybeagile.com, and don't forget to hit subscribe and look forward to next time. Enjoy your vacation Dave, looking forward to it and until next time, thanks again. You've been listening to definitely maybe agile, the podcast, where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.