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

When I started the Quality During Design podcast in 2021, I wanted to answer a question I'd seen throughout my engineering career:

Why do capable teams build products that miss the mark?

The early episodes reflected where my experience was deepest. I talked about FMEA, reliability engineering, statistical analysis, and other quality methods that help engineers design better products.

As the years went on, the conversations expanded to product development processes, cross-functional collaboration, systems thinking, and eventually the frameworks I describe in Pierce the Design Fog.

Preparing Episode 200 gave me the opportunity to look back across those conversations. What struck me wasn't that the podcast had changed direction. It was that the progression had become clear.

Looking back, I could finally see the throughline.

  • 2021: quality engineering tools
  • 2022: design process and concept development
  • 2023: people and cross-functional collaboration
  • 2024: systems thinking and the ADEPT Framework
  • 2025–2026: scaling better thinking across organizations

At first glance those look like different topics. But they weren't. They were all different ways of answering the same question: Why do capable teams still build products that miss the mark?

The Problem That Started It All

There's a pattern I kept seeing in my work. Teams would build something good. Engineers would put real effort into the design, follow process, use quality tools. Engineers say, "We built something great." Marketing says, "That's not what we asked for." Or the customer would receive the product and say, "This isn't what we need."

There would be rework, cost, field failures, warranty issues. These are real consequences, and often expensive and disappointing.

But here's what I noticed: this wasn't a failure of execution. People were doing their jobs. The design process existed. The problem was happening earlier, much earlier.

I started calling it the design fog. I kept seeing it everywhere: in my own work, in companies I'd worked for, in conversations with engineers at conferences and manufacturing events. When I asked reliability engineers at an ASQ event if they wished they'd been involved earlier in product development, every single hand went up. It was a full room and my best conference presentation topic yet.

That's when I knew: this isn't a personal failure. This is a common pattern.

One Question, Many Perspectives

The first few years of this podcast weren't random topics. They were uncovering the ingredients of a better way to develop products together.

About 180 of my episodes have been solo, where I synthesize what works, explain frameworks, or translate ideas so you can use them.

About 20 (so far) have been interviews with people solving these problems in real organizations. Jake McKee on why slowing down speeds you up. Emily Haidemenos on brainwriting. Yakira Mirabito on social dynamics in engineering. Jeff Lewis on timing reliability. Shere Tuckey on how to have conversations that matter.

These are people in the trenches solving the problems you're facing. The guests aren't my guests. They're your access to the field. They bring the pulse of what's actually working from people doing it right now.

Together, those 200 episodes document the development of an approach to thinking earlier and working better together.

The Orchard Metaphor (And Why Timing Matters)

I'm a hobby orchardist. I have eight fruit trees on less than an acre.

If you just let an apple tree grow however it wants, it will grow apples. But they'll be little, hard, and sour. You won't want to eat them. But if you prune the tree intentionally, at the right time, shaping it as it grows, you get good fruit. Fruit that's worth eating.

That's how I think about Quality during Design.

Quality isn't an inspection at the end. It's not a check when everything's already done. It's about shaping throughout.

And timing matters. If I prune early, I'm likely to get a good yield. If I prune late, it's too late to matter.

Most of you are trying to fix things downstream that should have been prevented upstream. When decisions still matter in product development (when pruning actually matters) is during the concept phase. Before engineering design locks in or requirements are set.

Why Existing Processes Miss Upstream Thinking

Don't get me wrong: Design for Six Sigma is solid. Design controls work. Agile approaches, stage gates...these are all good things.

But they all assume the problem is already correctly defined.

In real work, that's where it falls apart. You have an approved project. You have an idea. You know your customers. You have some customer needs. And then there's this gap, this huge fog, between that and "here are the engineering requirements and design inputs we're building to."

In that space, teams commit to solutions before they share an understanding of the true problem. Assumptions stay hidden until it's too late, until something's already designed and it's too far down the path to change.

The problem isn't execution. The problem is definition and alignment. Can your team actually agree on why you're doing this? What it means for the customer? What it means for the business? What the priorities are?

Structure Changes Everything

So, here's what I learned from testing different approaches with teams and doing some real research:

Structure changes what you're able to think and say.

Emily Haidemenos, who I met at a conference workshop, introduced me to brainwriting. It's different from brainstorming. You describe your ideas succinctly, within a time limit, to generate a number of ideas. The loudest person stops dominating. Ideas surface differently. Better thinking happens.

That thread led me to other systematic ways of working together. Over time, testing brainwriting and structured thinking with real teams in real organizations, I realized this could be systematized in a way that worked specifically for concept development.

I eventually organized those ideas into what I call the ADEPT Framework: Align, Discover, Examine, Prioritize, Teamwork.

It's five steps that help teams actually co-work instead of just coexist. It turns meetings into moments where everyone can think together.

This is what I'd been looking for. ADEPT was my way of putting those lessons into a practical framework.

When you use ADEPT, you're structuring how your team thinks together. When you clarify the Concept Space Model (a way to explore the benefits, symptoms, and use process of a design problem before committing to a solution) you're clarifying what to explore.

But the real work is this: Can you actually align your team on the problem before you start solving it?

That's what I mean by Quality during Design.

When you think this way early, everything downstream gets easier. Fewer surprises. Better alignment. You're actually building the right thing instead of fixing the wrong thing later.

It's Not Just Tools. It's How You Work Together.

When I look back at this podcast since 2021, I don't see a collection of quality methods. I see an evolution: from tools, to process, to people, to systems, to how organizations actually scale better thinking.

And underneath it all, one consistent thread: the earlier this thinking happens, the more leverage it has.

Quality During Design isn't a methodology I created. It's what happens when teams align early and think together intentionally.

The frameworks (ADEPT, Concept Space Model) are tools. You use what serves you. I detail how to apply all of them in Pierce the Design Fog, but you don't have to do it all at once. Figure out where you are, what you need, and do that piece of it.

Where We Go from Here

The best time to shape a product is before it's built. You know that. But knowing it and doing it are different things.

The question isn't solved. It evolves. How do organizations actually adopt this when they're under deadline pressure? How do we help engineers lead earlier, before decisions are locked in? What changes when AI can run scenarios faster than humans can think?

These aren't questions I'm solving alone. You're solving them in your organizations. You're testing these frameworks. You're experimenting with early alignment. That's where the real work is happening.

I haven't spent five years making a podcast about quality tools. I spent five years trying to answer one question: Why do smart, capable teams still build the wrong thing?

Along the way, the picture became clearer. Better tools matter. Better processes matter. But they have the greatest impact when teams first align on the problem they're trying to solve. Helping teams think together before they start solving - that's what ties all of these ideas together.

That's what Quality During Design has always been about. And I have a feeling we're just getting started!

Thank you for thinking through better design with me over these 200 episodes.

Listen to Episode 200: "200 Episodes, One Question: Why Do Teams Build the Wrong Thing?" on the Quality During Design podcast.

Learn more: Deeney Enterprises, LLC  | Pierce the Design Fog book – Develop High-Quality Products Faster through Team Innovation

Leave a Comment