Quality during Design
Quality during Design is a production of Deeney Enterprises, LLC. It is a podcast for product designers, engineers, and anyone else who cares about creating high-quality products. In each episode, we explore the principles of quality design, from user-centered thinking to iterative development. We introduce frameworks to make better design decisions and reduce costly re-designs. We explore ways to co-work with cross-functional teams. We also talk to experts in the field about their experiences and insights.
Join host Dianna Deeney in using quality thinking throughout the design process to create products others love, for less. Whether you're a seasoned designer or just starting out, looking to improve your existing designs or start from scratch, Quality during Design is the podcast for you.
Quality during Design
The Hidden Costs of Poor Concept Development in Product Design
The hidden costs of poor product development can devastate your project timeline, budget, and ultimate market success. Drawing from Dr. Robert Cooper's research, this episode reveals how skipping proper concept development—the critical "fuzzy front end" of product design—leads many teams into a costly "ready-fire-aim" approach.
Most development teams dedicate a mere 16% of project time to concept work, despite evidence showing successful products allocate 75% more resources to these early activities. The consequences? Designs repeatedly scrapped or substantially modified mid-development, wasted engineering hours, multiple unnecessary prototypes, and products that fail to meet customer expectations.
Through practical scenarios and comparative timelines, I demonstrate how proper concept development using Quality During Design methodology can reduce engineering time by 35% and design iterations by 60%. By engaging cross-functional teams early and using visual frameworks instead of multiple physical prototypes, you'll not only save time but develop products with significantly higher chances of market success—up to three times more likely, with 38% higher market share and better customer ratings.
This approach doesn't mean endless planning without action. Rather, it's about focused teamwork that addresses customer needs, use environments, and potential risks before diving into detailed design. The result? More efficient development, stronger team alignment, and products that genuinely solve customer problems. Visit the blog for additional resources to transform your product development process and start creating products others love for less.
Visit the podcast blog.
BI-WEEKLY EPISODES
Subscribe to this show on your favorite provider and Give us a Rating & Review to help others find us!
MONTHLY DIGEST
Subscribe to the free monthly e-newsletter: newsletter.deeneyenterprises.com
Get the short version on Linked-In: Subscribe here.
SELF-PACED COURSE FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Join over 300 students: Click Here.
About me
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 optimize their engineering processes and team performance by promoting the use of reliability and quality methods during design. She offers consulting services for managers and directors, training for engineers through the Quality During Design program, and other practical resources.
You're working in new product development in industry. You're designing things and part of a team that's helping to design things that people find useful and safe, make people's lives easier. It's a great space to work in. Anything worth doing isn't necessarily easy, and that's the case with product development. A lot of the challenges that we have in product development can stem from our lack of concept development, which is that early phase of product development, before we've even really designed anything. There are many hidden costs of poor product development in product design. Let's talk more about those and ways we can combat them or address them after this brief introduction.
Speaker 1: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 on how to apply quality during design to their processes. Listen in and then join us. Visit qualityduringdesigncom.
Speaker 1:Product development is a great space to be working in. It's very rewarding. You get to create and design things, work with other people and, with the products that you design, make people's lives a little better and, with the products that you design make people's lives a little better. It's exciting when something gets developed and it makes it into the hands of the customers with success, and that's really what we all want when we're on these product development teams. We want to be designing and developing things that are success. It isn't always easy. In fact. We could be developing and designing something that we then share with the team and they don't really like it. It gets picked apart. All that work that we've done just wasn't worth it. It's trashed, or we have to change so much of it that we really have to start over again. Or we're in the middle of product development and we realize that uh-oh, we have a missing customer need, that we didn't address, a regulation that we just happen to not be meeting, or other unforeseen things that just happen to happen that make us need to just change the design in mid-development. There are a lot of situations in where projects just don't meet expectations. They don't meet the expectations of the engineers, the cross-functional team, our customers. These are all challenges in product development that we face. Now, not all, but many of the challenges relate to concept development or our lack of concept development. Concept development is that fuzzy front end of product development. Now we have already have a product idea, we have customers that have been identified, the project has been approved. We may even have done a preliminary technical feasibility study. Then we get into concept development, actually developing ideas about what this design could be.
Speaker 1:Dr Robert Cooper authored how to Win at New Products. He identified some of the roadblocks with concept development, or some of the lack of concept development, and he related it to the end result of what really happens with our products. And these are some of the hidden costs that we recognize but maybe we don't realize how big they are, how costly they are, when we don't do concept development well. Based on Dr Cooper's studies with teams that had a well-defined product prior to the development phase, they were over three times more likely to be successful with their project and they also have a higher market share by 38 share points on the average, and their products were rated better by their customers. So their customer perception also increased. So well-defined product prior to the development phase leads to success, market share and customer's perception, not by a little bit but actually by a lot. I know that even in concept development we don't have a well-defined product prior to actually design development. We're actually developing a product in concept development. But Dr Cooper's studies also show that sharp, fact-based product definitions before development begins also leads to products that are more likely to succeed, and that solid, upfront homework, including activities that precede development, also significantly impacts success and market share.
Speaker 1:But here's the thing many of us aren't doing this early homework, this concept development, or when we're doing them, we're not doing it to the level that we should. Cooper shows that only 16% of person days on a project is dedicated to early work. So, even though concept development is really important to do, only 16% of our time on a project is spent doing it. Quoting Cooper, in too many projects we observed new product idea that moved directly into development with very little in the way of upfront homework to define the product and justify the project A ready-fire aim approach. Dr Cooper further describes that teams move ahead into product development without customer requirements or customer input, move ahead into product development without customer requirements or customer input. Comparing successful products to failed products, successful ones have about 75% more time dedicated to these pre-development activities. So we're not spending enough time in concept development and it's costing us.
Speaker 1:But I know when we get an idea or we get an ask the things we really want to do is start creating and start designing. We'd rather be on our workbench mocking up a prototype or building something and be able to get iterative feedback from our team on it. In that case, we kind of feel like we're developing as we're designing, but that can backfire also. But that can backfire also. Doing that is still designing too early and can lead to those problems that we talked about at the beginning of the episode Designs being picked apart, late concepts changing mid-development, wasted time and money and just projects not meeting expectations. The other thing we don't want to do is just to spin our wheels and not make decisions and not move forward with a project. But by jumping into action and into designs too early, we're skipping this concept development phase and we're missing out on opportunities, opportunities for our product to be in the market, to make it to market and to be successful. Product to be in the market, to make it to market and to be successful.
Speaker 1:We want to spend more time in concept development, but we want to make it worthwhile. We actually want to be developing a concept. So how do we balance this with design, especially in a product development lifecycle, and how do we do this with our cross-functional team. Well, we need to be intentional about our concept development. We need focused teamwork. We can use visual frameworks to talk about concepts and ideas and to prioritize those ideas, and we can use quality ideals that's a capital Q quality to help us navigate the whole process. And that's what quality during design in D&E Enterprises is all about being able to work with your team in early concept development using some quality principles. It's a philosophy that emphasizes the benefits of cross-functional team involvement in design and a methodology that uses quality tools to refine design concepts.
Speaker 1:Early After the work with your team, you should have a better understanding of your customers, the use environment, the environment in which your product is being used, potential use scenarios of your product and generally design inputs that are based on potential benefits to the customers or risks that you want to design out of your product, and also features and options that will make your product usable for your user to achieve their goal. And with your team's input, you can prioritize that so you can make trade-off decisions when you're actually designing. In fact, concept development can help you save time. You can reduce engineering design concept time by 35%. Plus, you'll have all that extra information that I just talked about, and with concept development activities you can reduce the number of design iterations to get buy-in on a concept by 60%. You're using visual frameworks to explore ideas and less mock-ups.
Speaker 1:Let me explain this in a couple scenarios. In our project we're given a challenge to develop something. We're going to develop it and then in the end we're going to have an approved concept design. In this scenario the timeline is pretty aggressive. But let's step through a typical scenario when we're using a lot of mock-ups and prototypes to be able to communicate ideas and iteratively update our concept. So let's say we're given a problem and we take 10 business days or two weeks to research and engineer a concept. Then we take two days to create a mock prototype and one day to plan a show and tell meeting and then the next day we have a reveal meeting where we invite our cross functional team to review what it is we've developed and they're going to challenge a lot of things. They're going to challenge a lot of ideas and it's likely going to result in big changes to whatever we've engineered. So we go back to the drawing board. We take two days to adjust the design, another day to change the mock prototype and then another day for the cross-functional team. They have additional feedback and request a few more changes. So we go back again and we don't spend as much time adjusting the design because we're getting closer. We take one day to adjust the design, one day to change the mock prototype and then we finally have an approved design concept Again an aggressive schedule, but in 20 days of engineering work we've done three mock prototype versions and have an approved design concept.
Speaker 1:Let's compare that against a similar scenario same start and end point, but now we're going to do concept development using quality during design methodologies. Our first big step is to plan a meeting, a co-working meeting, with our cross-functional team. We're going to take a day to plan it, three days to host working meetings and one day to look at all the information and prioritize and assess information. And at the end of those five days, at the end of a week, we'll have clear design inputs. Now we take a day to draw a schematic and this is just a layout of systems and subsystems, functions, how this product might work together, and we review the schematic with our cross functional team and ask for some feedback. Now our cross functional team has worked with us over three days in developing a concept idea based on our customers' benefits, symptoms and the use process. So they've already been designing with us and they're already on board with how the development is occurring. So for them to review a schematic should be not a big jump. It's not like you're introducing a brand new idea to them. They're already been working with you.
Speaker 1:After the schematic review, you decide you want to further develop the design based on all this feedback that you've been getting and working with your cross-functional team to get. Now you're going to create a geometric layout. This uses blocks and shapes to kind of start to put a picture together about what this product design might be looking like and how it's coming together. And then you host another layout review with your cross-functional team. They give you feedback and you take it back and draw an interactions diagram. Now you want to evaluate the interactions between these different modules and sub-modules and you're going to have another review with a cross-functional team. Really, your reliability engineers are going to be especially interested in this interactions diagram.
Speaker 1:At the end of that you're going to take two days to create a mock prototype that you're going to share with the team. At the end of that you'll have an approved design concept. Now all of that took 13 days of engineering work, one mock prototype plus. You now have a better understanding of the potential customer benefits, the bad things that could happen or the risks, the tasks that they need to take with your product to get from A to B, the tasks that they need to take with your product to get from A to B and these are all prioritized and explored for design inputs, for engineering design inputs. Plus, you've iteratively worked with your cross-functional team to develop this design and have their buy-in and understanding of what it is that's being developed. Comparing these two scenarios you have 20 days and three mock prototypes versus 13 days and one mock prototype. Over a week less of time and two less prototypes Could save you 35% of engineering time and 60% of design iterations. So now, with a better concept development process, we've saved time. We've saved materials and prototypes and mock-ups. We have increased chance of success in the marketplace because we're better aligned with our customers and we'll have increased market share.
Speaker 1:For the same reasons, I do not wear rose-colored glasses, meaning that I'm very realistic about what can be achieved with a product development process. It's not to say that if you do really well at concept development, you won't have any problems later in the product development process, and that's probably just not the case. Product development is difficult. There's a lot of moving pieces, parts, interactions, a lot can go wrong and you have a team that's helping you to manage that. During the product development process you are creating targets for what you want your product to be able to do, but at the end your product is what it is and that's why we test for it. Part of concept development is learning more about your product earlier in the development cycle so you can make some of those more informed design decisions, and it's linking your design up more closely with your customers and their expectations and aligning your cross-functional team on the expectations for this product design, getting their input and actually asking them to help you design it.
Speaker 1:There are certainly times when designers and design engineers need to step away and do the detail work of design. There is a place for that. The place for that may not necessarily be in concept development. Concept development is that place to do sharp, fact-based product definitions before development even begins. So all of this is to say that concept development is really important. Most of us aren't doing enough of it, but there are things that we can do to do it better and in the long run it'll have a big effect on how successful our products are and how pleasant our product development process can be with our teammates. Applying quality methods early can make a difference. We can be proactive with our team in early meetings, manage budget and market release and design what the customers want. Visit the blog for this podcast episode for extra information and more links. This has been a production of Dini Enterprises. Thanks for listening.
