Myths of Product Development – Part 1

Introduction

You are listening to the Quality During Design podcast. This is a channel where we talk about product development, product design, actually creating new things for people to use, and we don't just want to create stuff. We want to create really awesome stuff. But product development is hard. Can we improve it with quality tools and techniques? Yes, but not if we treat it as a manufacturing process. Let's talk more about how to treat product development with quality. After this brief introduction, hello and welcome to Quality During Design, the place to use quality thinking to create products others love for less.¹

I'm your host, Dianna Deeney. I'm a senior level quality professional and engineer with over 20 years of experien²ce in manufacturing and design. I consult with businesses and coach individuals and how to apply quality during design to their processes. Listen in and then join us. Visit qualityduringdesi³gn.com. Welcome back to the episode. If you are new to Quality During Design, this is a place where we talk about product design, product development and using quality tools to be able to do it better. Quality During Design is a philosophy that emphasizes the benefits of cross-functional team involvement in design, but it's also a methodology that uses quality tools to help us refine design concepts early. Each episode of the Quality During Design podcast is focused on some sort of insight to action, some sort of takeaway that you can use to help you with product design and to do better. If you've listened to the podcast before, welcome back. I appreciate your continued ears and our continued conversation on this important topic, because quality has been around for quite a long time—almost 100 years now, if not a little more than 100 years. It's been used successfully to improve and make things better in industry, manufacturing and product design also. It's a very versatile profession and a very versatile set of tools and techniques that can be used as a plug and play for where you need help, where you need to assess data, where you need to work with a team and co-work with a team and generally just to help you identify what needs to be improved and then how to improve it and what to do to improve it.

If you have any friends that are quality practitioners or if you've been involved in quality at all, you may have heard the term the seven basic quality tools. These are seven basic tools and techniques that quality practitioners can use to improve nearly anything. Some of these tools have changed with the times and some quality practitioners have a certain seven and their set. That might be a little bit different than another quality practitioner's set of seven, but no matter their particulars, these are a set of tools that are recognized as being useful and they work and they're repeatable and they're easy enough to understand that many people can use them and adapt them for what they need.

Now, the story goes that there are seven quality tools because it's related to a legend, a Japanese warrior monk named Ben Kai. He lived in the 1100s and he's depicted in a lot of ancient texts and also modern scripts, literature and productions, like in anime, and they mentioned an American detective show, but I'm not sure which one that is. He's also depicted in video games. Benkai is often seen as very strong and loyal, and legend has it that he carried seven weapons with him. The story is that the introduction of these seven basic quality tools was inspired by the seven weapons of Ben Kai.

The Six Myths of Product Development

Now, quality isn't the only one that has myths and legends. Product development does too. In fact, I found an article that is not as old as the 1100s. Rather. It was published in May of 2012 with the Harvard Business Review, and it's titled "The Six Myths of Product Development". This article piqued my interest, so I decided to try to access it, get access to it and then evaluate. What is it that the authors were trying to say and what do I think about it? There are two authors of this article. Stefan Topp is a Harvard Business School professor and author, and Donald Reinersten is a consultant who is also an author, and together they wrote this article for Harvard Business Review.

The basic idea of the article is that product development managers struggle to bring projects in on time and on budget. There's never enough people to actually do the job, but yet everyone expects them to stick to schedules and deliverables, and so they focus in on the plan the product development plan itself and try to minimize the waste and issues with the plan. The problem with this is that they start to treat the product development process like it's a manufacturing process, in which case it really isn't, which is what those six myths relate to. So I am going to review the six myths that are printed in this article and give you an idea of what it is they're talking about, and then also give my opinion on it, where I sit with some of these ideas. Generally, I think the article was well stated and I don't have anything that refutes or goes against what the authors originally said, but I do have some additions to it. I'm going to list the six myths as they show in order of the article, but I'm going to review them out of order and I think we're also going to split this up into two podcast episodes.

So let's get into these policies of product development. The first one is that a high utilization of resources will improve performance. Remember, it's usually the opposite, that's true. This is a fallacy of new product development. Fallacy number two is processing work in large batches improves the economics of the development process. Fallacy number three is our development plan is great. We just need to stick to it, the fallacy being that that's usually not the case and usually not how it works. Fallacy number four is the sooner the project is started, the sooner it will be finished. I bet some of you are probably chuckling with that one. Fallacy number five is the more features we put into the product, the more customers will like it. I have quite a bit to say about that one. And finally, fallacy six is, we will be more successful if we get it right the first time. Those are the six myths of product development that are listed in this article. I will include a link to the article in the podcast blog so that you can take a look at it for yourself and then maybe follow along with the episode.

Reviewing the Fallacies

In this podcast episode I want to talk to three different fallacies. I want to start with fallacy four. The sooner the project is started, the sooner it will be finished. And then I want to add policy number one high utilization of resources will improve performance. And finally, we'll end this episode of policy three With our development plan is great. We just need to stick to it. So, without further introduction, let's get into it. Just so we can keep track of how we're doing these fallacies in these episodes, I'm going to relabel them as A, b and C. So fallacy A is the sooner the project is started, the sooner it will be finished.

Basically, the authors describe new product development as being a process where, if you're trying to work ahead, that doesn't actually mean that you're achieving progress on your new development project. The main reason is because the product development work is highly perishable. That's how they described it, and I like that description. What is good for the development of this product on Monday may not necessarily fit with what is happening on Tuesday, and that's because between Monday and Tuesday we've actually learned a lot. A product development process is an iterative cycle where we're continually learning about whatever it is we're developing and who it is we're supposed to be serving, and where, whenever we come up against new information be it from the field, from our customer-facing teammates, from our customers themselves, from the manufacturing limitations on the floor or the technological limitations or cost limitations all of these things can really make product design and development difficult. That's because we make an assumption on one day and then we learn that that assumption was wrong and we have to go back and reconfigure things. This is part of the fun of developing new products, and I do mean that. It is exciting and fun to develop new products, and this is partially why it's also a big challenge of designing anything new.

Why this is a problem is because we can get involved in too many product development projects. We could be assigned to one project and then we may have some downtime and our managers say, well, why don't you get started on this other product development project, so we get something started and we start developing something there, but then we're pulled back to the original one and we have to continue work on the original one. We're bouncing around a lot and projects have different priorities, so the projects with lower priorities had some development work done on it and now it's left to languish. And now whatever we've done may be out of date. The authors relate this to a queuing problem, like a work queuing problem, and one of the solutions is just to manage the number of projects that your team and your people are working on, which sort of relates to fallacy B. High utilization of resources will improve performance. This is another queuing problem. We think that if Bob and Sue are utilized to their max, to 100%, that's going to improve the performance of our product development processes, but that's not necessarily the case, for some of the reasons that we've already been talking about, that development work is perishable.

Well, development work is also variable. There is not a direct relationship between the amount of people or people hours that you put on a development project and the results that you get, because a design development process is not a manufacturing process. When we think of improving a manufacturing process, we think of reducing cycle time, eliminating queues, managing the product flow to be efficient and effective. But new product development projects don't typically work that way because they are highly variable and the product that they're producing is sort of invisible. Now what I mean by the development work is variable.

The authors give an example of this, so I'll just use it. They say if you add 5% more work to a product development project, it may take you 100% longer to complete the project. An example is if we are plugging along in our development project and we decide that, oh, we made one of the wrong assumptions or we didn't understand this about our customer. We have to change this. We have to go back and change a whole lot of other things in the development process. So just by making a 5% change to our product, it may mean that we just double the length of our project in order to get it done.

The other thing is that the output of a product development project is invisible. It's not like a manufacturing line where we're producing widgets and we can keep track of them and how many there are and what their components are. New product development isn't built that way. It isn't built like a widget. A lot of what is produced is just not able to be easily tracked. That's because it's a lot of ideas and iterations of ideas, other information that is used to make decisions, including design documentations and testing procedure, development and the actual test results themselves. There's no real physical signs of a product development process being completed. Therefore it's hard to see, and then it makes it also hard to measure and to evaluate for continuous improvement. This leads to another problem, all associated with this.

One fallacy is work queues. Because what we're producing is invisible, it's hard to also manage the work queues. In a typical manufacturing process, you would eliminate idle time and manage the work queues for the process to be effective and efficient. That's part of what quality professionals would help you do. But in a product development process it doesn't work like that. There are work cues happening, but they're difficult to manage. This can lead to other problems, like not getting the feedback when you need it, when you're trying to make a decision. Now the authors suggest several solutions to this particular fallacy. One is just management control of who's doing what and which department is supporting the other department. Another one is being really careful about where you decide you need to increase utilization of your workforce and that you really have to be selective about doing that, based on goals that you need to achieve or problems that you've identified. Another solution is just to stop doing so many different product development projects at once, to limit the number of active projects. And then, lastly, they do have suggestions for making that invisible work easier to see.

Now, the fallacy C that ties into the first two that I reviewed is our development plan is great. We just need to stick to it. Usually, there is something to say about making a plan and then sticking to it, seeing it through to its completion. But in new product development projects, the plans are harder to maintain and to stick to. That's because product development is not really repetitive activities. We're not continually assembling different parts or components together like we would in a manufacturing line. We are working with information, iterating and continuously changing as we learn more.

The authors say that deviations to the product development plan isn't necessarily because it was bad planning or because of improper or bad management, or even in the way that the plan was executed. It's just that product development is complex and requires a lot of coordination and attention to detail. I like this parallel that they made. They said that the product development plan should be treated as an initial hypothesis that's constantly revised as the evidence unfolds, the economic assumptions change and the opportunity is reassessed. So where does that leave us with these three fallacies? And what does that have to do with quality in the first place? Besides, product development is difficult. The authors are also explaining why it's difficult. It's variable. The outputs of the process are largely invisible and difficult to measure and manage. Working ahead doesn't necessarily mean that you're achieving progress and we have to be careful with working too far ahead and letting queues of information build up because it may become obsolete.

Applying Quality During Design

My takeaway with reviewing these three fallacies, these three myths of product development, is that we want to get and gain as much evidence as we can as soon as we can, so that it'll allow us to pivot and adjust our plan and our execution of our plan and the product development project itself. How it relates to quality and how it relates to quality during design is that I promote working with the cross-functional team in early concept development. This is at a point where we've already identified a problem in the market. There's already been a market needs analysis. We may have some customer needs. To start, we have a product idea, general idea. Now, before we jump into the solution space where we start engineering and designing and prototyping things, we take a minute with our cross-functional team, maybe with a few customers, and we explore the problem space a little more. We develop the concept space, which is where our customers are experiencing our product. This is before we've even developed a product.

We can talk about our targeted customer benefits, some of the symptoms if things should go wrong, the basic use process that we expect our customers to be doing when they use our product to successfully get from A to B. But then also where we're initially meeting our customers with our product. What are their expectations and their assumptions? How are we meeting our customers where they are with our product so we can help them achieve the goal that they want to achieve by using our product? It is difficult to talk about because we don't have anything physical to look at. We don't have any sketches or drawings to pick apart.

We are really just talking about ideas which, as we talked about earlier in the episode here, it's invisible. The way we make it visible is through using quality tools. We use quality tools to help the team work together, to co-work to develop ideas and prioritize ideas against these sort of customer experiences. We use visual models to help the team develop these ideas and when we gather those outputs, we're able to use them as design inputs into our solution space. We'll be able to better define the design inputs so that we can design and prototype things that are more meaningful for the project.

If there are things that we can do with our team in early concept development that do take some effort but not a whole lot of time, but gets us a whole lot more information against which we can plan and devise and ideate, then our projects will be more successful. We'll have had more information earlier in the project and we'd be able to pivot, twist and dance around the new evidence that we've gotten. So what's today's insight to action? It's really an idea that we can't manage new product development like a manufacturing process. We can't do it because it's variable, it's not repetitive, what's being produced is invisible, and managing the queue the same way we would a manufacturing process just doesn't work with new product development. But we can use quality tools and methods for early concept development with our team to evaluate data and information and to help us manage co-work with our team.

Conclusion

If you would like to know what to do next with some of this information on the podcast blog for this episode, I will link to some previous podcast episodes and blogs with more information. Tune in to the next Quality During Design podcast episode, we'll review the other three myths of product development. This has been a production of Deeney Enterprises. Thanks for listening.