Myths of Product Development - Part 2

In this Part 2, we continue to challenge product development ideas by reviewing the final three myths identified by Stefan Thomke and Donald Reinersten in their article, "6 Myths of Product Development". You'll leave with a better understanding of why smaller development 'batches, embracing mistakes, and focusing on the quality of features are what's needed for innovative products.

Discover how quality thinking and systems approaches not only enhances collaboration but also improves user experience from the ground up. By integrating insights from the concept phase, teams can make more informed and strategic decisions throughout the development lifecycle.

Use this episode as an opportunity to change-up your development toolkit with practical guidance and resources.

Visit the podcast blog for extra links and resources.

If your team is still catching problems too late — let's talk.
→ Schedule a free discovery call: Dianna's calendar

Want insights like this?
→ Subscribe to my newsletter: qualityduringdesign.substack.com

Get the full framework.
→ Pierce the Design Fog

ABOUT DIANNA
Dianna Deeney is a quality advocate for product development with over 25 years of experience in manufacturing. She is president of Deeney Enterprises, LLC, which helps organizations and people improve engineering design.

Transcript

Myths of Product Development Analysis

Speaker 1 0:00

Welcome back to part two of our episode about the six myths of product development. In the previous episode, we've been talking about why product development is so hard and why we can't manage it like we do a manufacturing process. We're not able to apply quality tools to product development like we would a manufacturing process, but there is an excellent place for quality tools and that's where Quality During Design fits in. In last episode, we reviewed three of the six myths of product development. Let's review the other three myths of product development 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, diana Deeney. I'm a senior level quality professional and engineer with over 20 years of experience 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 qualityduringdesigncom. Welcome back to the episode.

Fallacy A: "Processing work in large batches improves the economics of the development process."

Speaker 1 1:11

We've been reviewing a Harvard Business Review magazine article from 2012 titled the Six Myths of Product Development. It was written by Stefan Tompk and Donald Reinersten. In the last episode, we talked about three of the myths, or in the article, the authors called them a fallacy. Fallacy A was the sooner the project is started, the sooner it will be finished, which we know is not true. Fallacy B that we reviewed last week was that a high utilization of resources will improve performance, which we also know is not true, because just because you throw a bunch of people at a problem doesn't mean that the problem gets solved any faster. And fallacy three that we reviewed last week is our development plan is great. We just need to stick to it. And we also learned last week that the reason that isn't true is because product development projects are highly variable and volatile and need to iterate. We need to be able to shift and change directions once we learn new information. In this episode, let's finish reviewing these fallacies and how quality fits into product design development, considering that these fallacies exist. The three fallacies that we're going to review in this episode is fallacy A processing work in large batches improves the economics of the development process. Fallacy B is we will be more successful if we get it right the first time. And fallacy C is the more features we put into a product, the more customers will like it. For each of these fallacies, I'm going to review or summarize what's in the article. Talk about some of the points that it makes related to product design development, and I'll also share my own take on some of these fallacies. So fallacy A processing work in large batches improves the economics of the development process. This was an interesting fallacy that the authors explored In the last podcast episode.

Fallacy B: "We will be more successful if we get it right the first time."

Speaker 1 3:20

We already explained why product development processes are not like a manufacturing process, but in this case they're applying some lean principles to the product development process. The big idea with this fallacy is, instead of strictly following a linear product development process, where you are doing all of the designing and prototyping all at once and once you get that done, then you move on to test and you develop the test and you do the testing all at once and then, once that's done, then you move it to manufacturing. The idea here is to do things in small batches. So if you're developing a product that has five widgets, then develop one or two widgets, do the design and prototyping of it and development and then do the testing and then do the manufacturing, and maybe while you're developing the manufacturing, you're developing the other three widgets together. So you're spacing out the work. You're being iterative with your product development work. This does a few things. This allows you to get feedback on things earlier Instead of waiting to get feedback on everything. You're getting information and feedback on how the development process is going a little sooner because it takes you less time to develop two widgets versus five and, as we talked about last week, getting information about a new product earlier helps us to better plan, pivot and just adjust what we need to earlier in the project. The earlier that we can pivot or change, the better it is for the project. A good example of small batches would be maybe agile software development, where there is a small change, it's tested out, it's iterated and then they develop the next set of code or interfaces or whatever they're developing at. The Another thing you can do to reduce your batch in new product development projects is the computerized modeling and simulation. Or, if you're a reliability engineer, you could run some halt tests and find out where the weak link is. There are other reliability techniques that can accelerate testing so that you can get information earlier to affect your decisions about the design. So those are ways that we can think of applying lean type principles to product development process. Back to the article.

Speaker 1 6:04

Fallacy B is that we will be more successful if we get it right the first time. I guess it's like that saying you measure twice, cut once. But in new product development it's a little more difficult, right? If we're putting pressure on our teams to develop the perfect thing the first time. The authors point out that teams are going to lean toward or lean into the least risky solutions, the solutions that are not going to fail, but also that aren't going to wow or be really innovative either. The least risky choices could also lead to the ideas that are the least different from what we know, which is why we wouldn't want to innovate. We know this solution works and we know the limitations and the cost processes of this kind of product. So instead of developing something new and innovative, let's just tweak what we have. Sometimes that is the appropriate approach. Other times it's not really what we're looking for. Putting pressure on teams to get it right the first time can backfire. Putting pressure on teams to get it right the first time can backfire. The authors propose that a solution to that is to adopt a tolerance for getting it wrong the first time, to allow teams to be able to come up with ideas, make mistakes, find out more information so that they can continue to iterate their designs and their ideas. Again, we're getting back to that iteration idea where, instead of batching everything at once, we're doing little iterations of product development as we go and that iteration allows us to get more information earlier in the project.

Speaker 1 7:53

The last fallacy the fallacy C is the more features we put into a product, the more customers will like it. We think that if we put more bells and whistles into a product, or if we make our effort into whatever we're developing obvious then our customers will like it or appreciate it more, or our managers or bosses will appreciate our work more, whereas really if we develop something where our work and the effort we put into it is hidden, it leads to more success. It's a simpler product that customers tend to appreciate more. There's less confusion, less use errors. The simpler the better.

Speaker 1 8:41

But the key for combating this fallacy is really that we need to focus on the customer. What is it that they really need? Do they really need to have all of these options? Which option is a priority? Because we know that not every feature that we produce is going to lead to the same customer experience. There are going to be some features that are just a must-have. Our customers need to have this as part of the product or they're not going to buy it at all, and there are other features that are a pleasant surprise. They wouldn't have thought that they needed that feature at all and that makes them want to buy it, and that leads to our product leading the market. Part of the challenge in that is actually defining the problem that our product is intending to solve, and the other thing is just determining what to hide or omit from the product.

How Quality during Design relates to these Fallacies

Speaker 1 9:37

The author suggests this kind of thinking. Products get closer to perfection when no more features can be eliminated. So, taking these three fallacies together, we want to be able to iterate in small pieces of our ideas or of our product. We want to allow ourselves some grace to make mistakes and learn information so we can pivot and make different decisions, and we need to focus on providing the kind of features that our customers want, realizing that not all features are created equal. How would quality relate to this aspect of new product development? It relates because we can take a system's point of view of our product, but yet focused on the user.

Speaker 1 10:26

A typical system design is an input, you have a black box system and then you have outputs. Maybe you have two outputs, one where you have the intended output and the other is where a mistake was made or an error happened, an unintended output. At each of these nodes, our customers are experiencing our product. With this systems point of view, we can take a huge step backward and create avatars for our customers at each of these places. On the intended output, our customers are experiencing benefits of using our product and it makes them happy. We can target customer experiences and benefits in order to develop ideas about features, and then we can prioritize those features using something like a Kano model based on the level of customer satisfaction that this benefit might provide our customers.

Speaker 1 11:28

With the unintended output, we can look at what our customer experience is when things go wrong. What are the symptoms that they're experiencing? They may not understand the problem, but they're certainly experiencing something bad. When bad things happen, what's the severity of that bad thing and how likely is that to happen? We can prioritize these things in order to make design decisions, create design inputs against which we can design a solution. At the input part, our customers have certain assumptions and conditions and we have certain assumptions and conditions about them, their use environment, their understanding of how things work and how we think they're going to be interfacing with our product and the decisions that they'll make. This is all information that we consider for product design and we may need to iterate on this information. The more that we learn about it, the more that we target customer benefits and try to eliminate or diminish the customer symptoms.

Final Conclusion of the HBR article, and Parts 1 and 2

Speaker 1 12:39

Between the input and output, we have our product itself, but from our customer's point of view, but from our customer's point of view, they're using our product. They're using it to get from A to B, from start to finish, from input to output. They are following certain steps and interacting with our product. What are going to be the typical use steps? Even if we don't know what we're designing yet, if it's just a concept development, if we're kicking around ideas, we can still have a few steps with which to analyze. We can highlight what is critical to quality, meaning what step is going to affect the output, the quality of the output, or what step is highly sensitive to our inputs. That is just one way we can use quality tools to help us prioritize these different use steps so that we can mistake-proof the use process, evaluate it later in a usability FMEA or do a task analysis when we take a systems approach and focus on the user. I call that the concept space model. We're breaking down those invisible ideas, gathering information from our team and getting that information early so that we're less likely to be surprised later. With more information like that up front, we'll be able to develop the design inputs that affect our customers' experiences with our product.

Speaker 1 14:16

So that is it for this article the six myths of product development. Over the last two episodes we reviewed all six of the myths. I am sure if you have been working in product development that you would have experienced some of these situations, if not all of them, because they are very common. I liked the article and appreciated that they called out these problems. After reading it I really wasn't surprised. The authors come out strong from the get-go. We can't improve a product development process like we do a manufacturing process. We can't apply quality tools in the same way to product development like we would on the shop floor on a manufacturing process. I agree. In fact, when I saw this article I was a little bit surprised that that was a suggestion.

Speaker 1 15:13

So quality during design is not using quality tools to manage a product development process. What it is is it's using quality tools with a cross-functional team to develop early design concepts and to gather information so you can make more informed decisions earlier in your product development project. With these last three myths, the insight to action is this we want to focus on iteration. We want to develop things in batches. We want to test and iterate. Use your reliability engineer to help you with some of these tests and iterations and use your quality engineer to help you with some of the customer interfaces To talk about ideas and information that are intangible and invisible.

Speaker 1 16:05

We can turn to quality tools to help us to work with our team through those ideas. We can use a systems approach, but yet focused on the user's experiences, to be able to help us gather and prioritize information for design inputs. There's a spirit of information with concept development too, because once you develop some of the ideas at concept when you don't have anything designed yet but you're using it to develop your design inputs you can iterate whatever you did at concept and work it into what you're doing later in development. You can continue to use that information to pull it through into later aspects of your product development project to help you make decisions. I will link to some relevant Quality During Design podcast episodes where you can learn more about that. I enjoyed going through the six myths of product development with you. I hope you enjoyed it too. Please visit the website and the podcast blog and connect with me on LinkedIn. This has been a production of Dini Enterprises. Thanks for listening. Thank you.