From Tools to Teamwork — 200 Episodes of Rethinking Quality during Design

In this milestone episode, Dianna reflects on how the thinking evolved from quality methods to product development processes, to team dynamics, and ultimately to one central idea:

Quality during Design happens when teams align early and think together intentionally.

In this episode

•  The question that has guided all 200 episodes 
•  Why good engineering teams still build products that miss the mark 
•  The evolution from tools → process → people → systems 
•  The "Design Fog" and why the earliest product decisions matter most 
•  What a backyard orchard taught Dianna about product development 
•  How brainwriting led to the ADEPT Framework 
•  Why the future of quality starts before engineering design begins 

Featured ideas

•  Design Fog 
•  ADEPT Framework 
•  Concept Space Model 
•  Brainwriting 
•  Early concept development 
•  Cross-functional alignment 
•  Building the right product before building the product right 

Thank you

Whether this is your first episode or you've been listening since 2021, thank you for being part of the Quality During Design community. Your questions, conversations, and willingness to rethink product development have shaped this podcast as much as the ideas shared.

Here's to the next 200 episodes.

Work with Dianna I help product development teams build quality into the front end when it's cheap and easy, not late when it's expensive and painful.

Book a 20-minute discovery call with Dianna's calendar. Whether you're navigating the "fuzzy front end" of product development and want to explore a workshop or advisory partnership, or you'd like to be a guest on this podcast. You'll leave with a summary, relevant resources, and a clear path for next steps within 24 hours. 

Pierce the Design Fog (piercethedesignfog.com): my book on aligning cross-functional teams, defining clear design inputs, and accelerating product success. NIEA Finalist Award, reviewed by PDMA. 

Connect with me: I'm most active on LinkedIn. 

Free Resources for Subscribers Subscribe to the Quality during Design digest — https://newsletter.deeneyenterprises.com — for monthly actionable highlights, plus access to the Strategic Quality Integration Checklist (a free self-assessment download) and my Swipe File Vault.

Transcript

0:00

It's the 200th episode of the Quality during Design podcast. Uh, just picture Kermit the Frog doing his yay moment. Um, I really honestly can't believe it, and I really thought I knew what I was going to cover in this 200th episode, But as I dug into the podcast history, I actually learned that there was an evolution of the ideas that I've been sharing on this podcast. in taking all of the previous 199 episodes together, I realize that, um, there is a definite progression in the things that we have been talking about, and it's all culminated into this idea that I wanna share with you today Before we dive in, I just wanna say thank you. Whether this is your first episode or you've listened since 2021, you've made these 200 conversations possible. Every email, every question, every conference conversation, every guest recommendation has shaped where this podcast has gone. I appreciate you spending your time with me, and I'm excited to see where the next 200 episodes take us. When I started this podcast in 2021, I was covering tools and methods, things like FMEA, reliability engineering, and statistical analysis, and these are still some of the top listened to, most downloaded episodes. in 2022, I shifted to more process thinking, where I talked more about design for Six Sigma, early concept development, and requirement cascading. Then in 2023, I shifted again into people and dynamics, and I got to have some really interesting guests on the show and we talked a lot about cross-functional teams. In 2024, the year after that, I started thinking more about systems and how they integrate, and that's where I introduced the ADEPT framework. We talked about complex interactions and optimization of these systems. And then finally, last year and into this year, um, really looking at industry case studies, talking about global manufacturing, really looking to scale all the things that we've previously talked about, including having more interviews and more guests on the show Spanning all of those years of production, it, it still goes back to the root and the original question and why I started this podcast in the first place And the original problem that I kept seeing and hearing people talk about and experiencing myself was that engineering, and I'm an engineer, engineering designs something that misses the mark somehow. There was a key insight or a key requirement that was missed in the beginning, or what was developed really isn't what marketing envisioned. It's that feeling when a team builds something great, but then nobody wants it. That's what I've been focused on in Quality during Design since 2021. The engineers say, "We built something great. Why doesn't anybody want it?" And the rest of the cross-functional team, like marketing or sales, um, you know, they know that it's not quite right for the customer or, or the customers just don't buy it. And so there's a lot of frustration there too, I call it the design fog, where that early concept development where we have an idea, but we don't have the design yet, that in-between space It's a problem and it's a pattern that repeats across industries. What was really eye-opening for me is I had seen it in the groups that I worked in, in the companies that I had worked for. But then I went to, um, an ASQ event. It was full of reliability engineers from a, a bunch of different industries, and we were there to help with the certification process. We went out to dinner and I, I asked this question of them, like, "How, how involved are you in early product development, and do you wish you had been involved earlier?" And they all said, "Yes." And that's when I knew if all these reliability engineers in a bunch of different industries all had stories from the field about why they wish they had been involved earlier, that they could've saved the team time, given some expertise, redirected the design in another way to prevent field failures, to improve warranty, to improve the customer's experience, um, that's when I knew that this is a real problem It's not a failure of execution or an engineering failure, it's a failure to really align early And what I've learned after working with teams on this is that there's a way to think about it differently Here's one way to think about what's actually happening in your design process. I am a hobby orchardist, I have eight fruit trees on my very modest property, and fruit trees need to be managed You're not supposed to just let them grow wherever and however they want to grow because they won't produce the kind of fruit that you would want to eat later. If you just let an apple tree grow, it will grow apples, but they'll be little tiny things, and they'll be hard, and they'll be sour. There is a lot of maintenance and care that goes into actually having an apple tree or a mini orchard that produces for your family We can think about the design process in the same way. The tree is our design process itself, and the fruit is the product that we're actually trying to design, and we wanna get the perfect fruit, the one that other people are going to want. So we need to prune the tree and do maintenance on it so that as the tree's growing, as we're going through the design process, we're actually getting the right fruit, the right product. I attribute that kind of pruning to quality thinking. I don't think of quality as an inspection at the end or as a check when everything's already done. It's about shaping throughout whatever you're doing And timing matters. We can extend our story into the timing factor too, Because if I prune early, I'm likely to get a good yield, but if I prune late, it's too late to matter, which is actually where I am this year in my mini orchard. It's too late So when you're thinking about applying quality thinking to your design process to make it better or to get the best product, it needs to happen when decisions still matter Most of you are trying to fix things downstream that should have been prevented upstream. When decisions still matter in product development is during the concept phase, even before engineering design, before the requirements are set So if we know we need to apply quality thinking in the early parts of product design then we really need to look at how teams actually work together in the early concept development. There are a lot of design processes that are perfectly fine and do a good job. If you've been trained in Design for Six Sigma or similar methods, you know how to define, measure, analyze, design, and verify. That's a solid way to do it, and that's a design process. If you're in a regulated industry, you would have a design control process. It's structured, and that's a good thing. It could be an agile approach. You could be using stage gates. These are all good things to have in a design process. But it assumes that the problem that we're trying to solve with our product is already correctly defined. in real work, defining the problem that we're solving with our customer is where it falls apart. I'm not talking about customer needs. Those are separate. I'm not talking about innovation. I'm talking about that gap where we have an approved project to develop a new product. We have an idea. We know who our customers are. We have some customer needs. Between that and here's the engineering requirements and design inputs to build it. That space in there is still a gap. There's still a huge fog. It's the fuzzy front end of any new product development process, Even though we have the perfect process for designing a product, we can still build the wrong thing if we didn't align on what right means. What right means for the customer, what it means for the business, what it means for the project So I started asking, what do teams actually need to do upstream? I went looking for the answer in the field I spent time at conferences talking with people about the work that they do I would go to manufacturing events and talk to business owners about how they line up what their customers need with what they produce And in my own work, I brought my own experiences and would talk to my engineering cohorts and friends about their experiences It's 20/20 hindsight. When you're moving forward with a design, you're thinking, "This is good. We're making progress." It's not really until later when you're in validation, when you're talking with the rest of the cross-functional team, when you're doing human factors studies It's at those points when you realize we missed something or there was some critical information that really didn't get properly communicated. We decided on something too early, and we committed before we understood I mean, if you see that in your own processes and if you feel that way, you're not alone. This is systemic It's not a personal failure. It's how teams get structured. But that doesn't mean that we can't take some ownership and do something about it In order to understand what to do about this problem, we need to understand more of the root cause of it And several stories came out when I was talking with other people, Teams commit to solutions before they really share an understanding with each other of the true problem that this product is going to solve. Marketing may have one understanding of the problem, and they may think that in their reports they're summarizing the data, they're giving it to engineers, uh, the engineers are reading the reports and not deriving the same conclusions from it So that's another thing is that the assumptions are there, but they just stay hidden until it's too late, until something's already been designed and now it's either too late to change it, it's too far down the path And then we have the failures that happen in testing, in field testing, in the field itself, and reworks happen. The problem is definition and alignment. Definition of exactly why we're doing it, the context for some of our decisions, the priority against the benefits and the potential failures that could happen. That and the cross-functional team getting alignment on what that means. So if we want to fix this systemic problem, we have to fix it before the design actually starts, which means we need concrete ways to help our teams think together differently, and that's where I found something that actually works. One of the things I tested with teams was brainwriting. Brainwriting is different than brainstorming, and this is one of the reasons I like it. you need to be able to describe your ideas succinctly And you're given a time limit to generate a number of ideas Brainwriting changes what people are willing to say. It prevents the loudest person from dominating, and when you add structure, ideas surface differently. Emily Haidemenos talked about brainwriting on this podcast. She's using it as an engineering leader to help her teams get unstuck with problems. And she showcased brain writing as part of a workshop at a conference that I attended which is where I met Emily Brainwriting was the thread that I pulled to discover other systematic ways of thinking, Over time, testing structured brainstorming and brainwriting with teams, I realized this could be systematized, So I created what I call ADEPT, which are five steps that help teams actually co-work instead of just coexisting. For me, this was the missing piece. The first few years of this podcast weren't random topics. They were uncovering the ingredients of a better way to develop products together. ADEPT was my attempt to put those lessons into a practical framework It turns meetings into actual co-working sessions. Align first, discover ideas together, examine them, prioritize, then agree on the teamwork Structure changes what you're able to think and say. These targeted templates can help us gather information with our team for a system FMEA, feed into things like human factors studies can actually help us write requirements that fulfill the user needs while also describing the test parameters that we may need We can intentionally design how our team works together. And isn't this a great stand-in for that fuzzy front end of concept development, where we have an idea, but we don't know how we're going to execute it yet? We don't know what the solution is, and we don't have all the engineering design inputs. We have the idea, we have the project go, we have customer needs, and there's this big space in between that and designing that's just foggy and fuzzy. What a great moment to apply this structured thinking to be able to develop better design inputs and get better alignment with our team okay, so listen, back to the podcast. This is my 180th solo episode I synthesize what works. I explain frameworks. I translate ideas so you can use them. And the 20 interview episodes, you hear directly from practitioners that are solving these kind of problems in real organizations. The guests aren't my guests, they're your access to the field, because they bring the pulse of what's actually working the people you hear on this show, Jake McKee on why slowing down speeds you up, Emily on brain writing, Yakira Mirabito on social dynamics, especially in engineering environments, Jeff Lewis on timing reliability, Sheri Tuckey on how to have conversations that matter. These are people in the trenches solving the problems you're facing I'm very happy and proud to be able to share their voices with you on this podcast And over 200 episodes, something became clear about what actually creates conditions for better design. If you take everything we talked about, the frameworks, the guest stories, the field wisdom, here is what creates better design It's creating conditions for early thinking. ADEPT is how you structure it. The concept space model, benefits, symptoms, use process is what to explore. But the real work is can you actually align your team on the problem before you start solving it? That's quality during design. When you think this way, everything downstream gets a little easier. There's fewer surprises, better alignment, and you're actually building the right thing instead of fixing the wrong thing The best time to shape a product is before it's built. You know that, but knowing it and doing it are different things. So a few final thoughts. The Quality during Design podcast is a platform for you to access field wisdom and tested approaches Quality during Design is what happens when teams align early and think together intentionally. The frameworks like ADEPT and Concept Space Model are tools. You use what serves you, the Pierce the Design Fog book is full of a whole system approach, but you don't have to do it all, all at once. Figure out where you are, what you need, and do that piece of it I'm so grateful to you, the listeners, who are actually doing the work, testing it, and improving it in your organizations, thanks for joining me over the years on the podcast I welcome your suggestions. What kind of topics or things have we not covered that you'd like to hear more about? Is there a leader in the space that you think their voice needs to be shared? Contact me on LinkedIn or via my email There's a contact page on deeneyenterprises.com. I'd love to hear from you. As with all the other podcasts, this has been a production of Deeney Enterprises. Thanks for listening