In our latest featured episode of Quality during Design, I chat with Vincent Deeney, a director with decades of experience in data governance who has spent his personal time “nerding out” on what’s possible with local LLMs. Vincent argues that playing is learning, and that by experimenting with models locally, you discover how to bridge the gap between having a technical idea and actually executing it faster.

🎧 Listen via your favorite app or get it here.

Keep reading 🡫

The Secret to Personal Mastery: The “Senior Engineer vs. Intern” One of the most actionable takeaways from this conversation is a workflow designed for personal growth:

• The Senior Engineer (The Frontier Model): Use powerful cloud models like Claude to act as the “professor” who helps you plan architecture, identify design gaps, and define a methodology.

• The Intern (The Local Model): Once the plan is set, you hand it off to a local model running on your hardware to do the “grunt work”—like writing Python code for statistical analysis or crunching local data sets.

Learning the Mechanics By moving your AI experimentation local, you get to see the “why” behind the results. You’ll learn how to manage context windows to prevent model “bloat” and how to use sub-agents to run multiple tasks simultaneously, effectively building a team of assistants that live entirely on your machine.

You don’t need to be a programmer to start; tools like Ollama and LM Studio make it easy to download and run models that fit your specific hardware. This isn’t just about productivity. It’s about future-proofing your career by learning the boundaries of what these tools can truly do.

The False Peak

In the high-pressure world of product development, finally landing on a feature list, user IDs, and some risks can feel like a major victory. There’s relief, clarity, and momentum. The team has been slogging through uncertainty, and moving into the solution space feels productive in a way that the problem space never does.

But “we have answers” isn’t the same as “engineering can build to these answers without reverse-engineering our intent.”

This is the false peak, where teams mistake alignment for specification. Nodding heads in a meeting indicates a common starting place (the first step of the ADEPT Team Framework), but it does not mean the team has defined the engineering needs. Without rigorous questioning, teams risk what I call the “Ta-da Flop”: a clever design gets presented to stakeholders only to be rejected because it doesn’t actually solve the customer’s underlying need.

Unstructured knowledge produces answers that look finished but leave engineering carrying the ambiguity.

Structured conversations is what turns knowledge into usable design inputs.

The Engineering Tax

When a team mistakes alignment for input, the work doesn’t vanish. It shifts onto the engineers as an invisible workload: the mental and technical labor of reverse-engineering intent.

This happens when an engineer gets the what (a feature or product idea) without the why (the underlying customer problem). Without access to what I call “field vision” (direct understanding of the customer’s world) the engineer becomes a middleman, reconstructing a complex reality from a few bullet points.

This isn’t from a lack of team synergy or report-sharing. It’s from a lack of the structure needed to wrangle everything a team knows, and identify the relevant unknowns, during concept development. Even when functional groups swap reports they feel are complete, a simple hand-off introduces a high probability of misinterpretation because the information remains disjointed and often conflicting.

What guesswork looks like in practice

When an engineer is forced to guess the “why” behind a “what,” the development process buckles under the weight of untested assumptions.

The Daily Vacuum. Every day, engineers make hundreds of small decisions about materials, tolerances, and logic. When intent is invisible, they guess how the product will be stressed, what environmental factors it will face, and which features are truly must-haves versus features that would delight the customer. We want to ensure the ‘must-haves’ are met and tested against while ‘delighters’ don’t need to be engineered to the 10th degree to provide value. Understanding the difference allows for engineers to focus on the right things for the user.

The Lost-in-Translation Shuffle. Teams assume shared knowledge exists because they had a kickoff meeting. Designers spend hours trying to decipher what clarifying questions to ask, rarely given the opportunity or time to explore options, with clients expecting results yesterday. Or, engineers reconcile vague requirements like “easy to use” without specific context.

The Ta-da Flop Cycle. An engineer may spend weeks applying high-level innovation to a solution they believe is spectacular, only to present a finished prototype or drawing and be told it doesn’t solve the actual customer need. It was built on guesses, not co-created design inputs.

Late-Stage Rework. Guesswork leads to “ready, fire, aim” development. An engineer reverse-engineers requirements to fit a design already halfway built, or redoes months of work when a “hidden” design input surfaces on a Friday afternoon.

This invisible workload is a symptom of jumping into the solution space too early. Teams trade a few hours of rigorous questioning for weeks of expensive, frustrating rework.

The Financial Liability

The “fog” of uncertainty isn’t a sign of failure. It’s a natural byproduct of moving from a vague idea to a concrete design. How you handle that fog determines whether your project thrives or merely survives. Think of it as the 1-10-100 rule of design fog.

Clearing the fog in concept development is cheap. Defining customer needs and the Concept Space is the highest-leverage activity. Teams that do solid up-front homework are three times as likely to succeed and significantly more profitable. At this stage, you’re using tools like Benefit-Impact templates and flowcharts, not expensive engineering resources. Adjusting a requirement on paper costs nearly nothing compared to retooling a physical product. It even trumps the cost of gathering your team to do the work.

Clearing the fog in prototyping is expensive. When teams skip the “define and develop” stages and jump straight to solutions, the fog doesn’t vanish. It relocates downstream. Wrong assumptions produce prototypes that stakeholders or customers reject. Guesswork leads to constant rework, missed deadlines, and the frustration of redoing everything when a hidden requirement finally surfaces. There is a place for prototypes: they can be a great way to test ideas. They also invite a cognitive bias: fixedness, where we ignore other potential possibilities because now we’re working from “this”. If you want to improve innovation, leave the prototypes until after rigorous concept co-work.

Clearing the fog in the field is catastrophic. If you don’t provide guardrails of design inputs early, the fog moves into your manufacturing, your risk analysis, and eventually your customer’s hands. This is exactly what we want to avoid in the first place.

The goal of concept development is to share knowledge before you engineer solutions. Structured investigation (using the ADEPT Team Framework and the Concept Space Model) helps you identify what is new, different, or unknown early, so you’re designing the right thing the first time rather than paying the 100x price of clearing the fog when it’s already in the field.

Mislabeling the Goal

Engineers often receive a set of features presented as equally important. But when tradeoff decisions come later, those features need to be prioritized. Not everything can sit at the same priority level.
During the design process, engineers choose what matters most. This is not just among features, but across cost limitations, manufacturability, and usability.

As consumers ourselves, we recognize this intuitively. Maybe one feature must be there for us to even consider buying. But other characteristics make the design shine and influence us to choose it. Engineers need that same differentiation to make the best tradeoff decisions for the user. And to do that, they need each feature, characteristic, or outcome linked back to the customer and how that customer’s experience is affected.

If the engineers don’t understand how this feature or characteristic relates to the user’s experience (including symptoms when bad things happen and what’s related to critical use process steps), then they need to reverse-engineer the intent.

The SunCore 360 experiment made this concrete

I ran a side-by-side concept development trial on a product called SunCore 360. It’s a post-installation solar service redesign for Luminos Energy (a completely fictional company and product yet built to simulate real-world scenarios):

• Same product brief: the green light packet that executives reviewed to approve the project.

• Same cross-functional team: 6 AI agents for PMM, engineering, quality, CS/UX, manufacturing and sales.

• Two methods: traditional concept development versus the Pierce the Design Fog / ADEPT method.

Traditional concept development treated the 24-hour SLA as a differentiator, as if customers would choose the service because that promise set it apart from competitors. Our AI team, using the PTDF method and Kano analysis, revealed it was actually table stakes for this project: the bare necessity of what the service had to do. Failing the SLA would lose customers, but meeting it wouldn’t win them. What separated Luminos from competitors was “Proof of Prevention”: real-time anomaly alerts where the system caught issues before the homeowner noticed.

Think about how a decision like this cascades. If we mistake a basic requirement for a differentiator, we waste both marketing budget and engineering priority on something that only needs to meet the minimum bar. Yes, it must work, and it has to work well. But does it need all the bells and whistles? A basic requirement calls for design rigor focused on consistency and reliability.

On the other hand, a differentiator may influence a purchase decision but doesn’t require the same level of engineering investment. If it’s new, cool, and “wow”, then we may need to make it available but not validate it so thoroughly.

This distinction affects marketing too. Marketing shouldn’t spend resources promoting what the product must do. It should focus on what will delight the customer and truly the product in the field. They have insight into this, which is why they’re part of the concept development team.

This kind of differentiation can be defined upfront in concept development and linked directly to the user’s potential experience with whatever you are designing, a product or service.

Open items versus specific questions

The traditional method handed over four broad, unassigned gaps.

The PTDF method handed over three specific questions with functional owners, over three lens: benefits, symptoms, and use process. Engineering owns the Inventory Staleness Tolerance definition. Operations owns the SLA Pause Rules for rural zones. UX owns the Resolution Artifact architecture.

When you’re making a decision about a product or service design, think about the difference between a vague gap and a defined question. Engineering prefers a hard question over a vague hole. Even in concept development, we can get more specific about the questions that need to feed later engineering tradeoffs and design decisions. Those become the design inputs.

Raising these kinds of questions doesn’t create more work for engineers. It replaces vague ambiguity with a defined question. The volume of work isn’t changing. What changes is the placement of ambiguity in your design process. When you get specific about what needs to be solved, you can put a name and an address on that question. Instead of leaving a vague gap that maybe nobody addresses, you create a specific question that someone owns.

The Same Answer, With and Without Context

Here are two design inputs from the SunCore 360 trial that say the same thing.

Traditional: “Real-time Inventory API.” A feature name. No user, use step, or failure consequence. Engineering decides what “done” looks like.

vs.

PTDF / ADEPT: “If the Inventory Handshake provides stale data, the technician arrives without parts — First-Visit Failure, severity 4. Design input: Real-time Inventory API with staleness tolerance defined.”

Same answer. One has context. One doesn’t.

I’ve now run this same experiment on two more products:

• Project ClearAir — a portable oxygen concentrator for active seniors (regulated medical device)

• Harvester-L1 — an autonomous selective-harvest retrofit kit for leafy greens (agricultural equipment).

These case studies covered different domains, different constraints, and different regulatory environments. The pattern held every time:

• Traditional concept development produced directions and open questions.

• The PTDF method produced mapped use processes, Kano-rated benefits, severity-ranked failure modes with design inputs per failure, and in ClearAir’s case a Symptom-Impact table that gave the risk management team a starting hazard log instead of a blank page.

The method isn’t product-specific. A solar service redesign, a medical device, and an autonomous harvest rig have almost nothing in common. Except that all three teams needed structured concept development to hand engineering something better than a feature list and a set of open questions.

The Practical Filter

For each design input your concept development produced, ask yourself three questions:

1. Who fails if this is wrong? This is the most important question because it connects accountability to the design input. Not blame, but accountability. If you can’t name who is affected when this input is missed, you haven’t finished defining it.

2. How severe is that failure? This answer tells engineering how to prioritize their defensive design work. Not everything needs the same level of rigor. A ranking makes the tradeoff decisions visible before they become emergencies.

3. What does “done” look like for engineering? This is the exit criteria. If you can’t describe the finish line, don’t start the race. Engineering needs to know what satisfying this input actually looks like in measurable outcomes, not vague terms.

If you can’t answer all three, you haven’t finished concept development. You’ve moved the fog downstream, where it costs more to clear. Much of this can be done for a new product or service design before a prototype is even mocked.

The Takeaway

The fog didn’t disappear. It got cleared in concept development (where it’s cheap) instead of downstream in engineering, where it’s expensive.

For videos of all the case studies → visit www.youtube.com@qualityduringdesign
For how to use structured concept development → Pierce the Design Fog

At that moment, the room goes cold. You realize that the knowledge to avoid a massive mistake was already in the building. It just didn’t have a path into the conversation when the conversation was happening.

In this week’s podcast episode, I’m sharing the results of an experiment that made this “fog” visible in a way I didn’t expect.

The Experiment: AI Agents and Design Ambiguity

I ran three product concepts (a solar service redesign, a medical device, and a field harvester) through two different development approaches. I used identical teams (simulated via AI agents) and the same product briefs.

The results were a stark reminder that features are not the same thing as clarity.

• The Traditional Approach produced legitimate work: feature lists, risk registers, and specs. Most organizations would have stamped these “Ready for Engineering.”

• The Structured Approach produced the same features, but with a critical difference: Context.

In this episode, I cover:

• The side-by-side results of the three case studies.

• The “Three-Question Filter” you can apply to any design input this week.

• Why “ready enough” is where expensive ambiguity hides.

https://deeneyenterprises.com/qdd/podcast/the-knowledge-your-team-has-that-nobodys-using/

Stay with me this May

Throughout this month, I am publishing a breakdown video series on YouTube showing side-by-side outputs from this experiment. If you want to see exactly how structured concept development looks in practice check out the links below.

www.youtube.com/@qualityduringdesign

About “Pierce the Design Fog”

If you found this insight helpful, consider sharing it with a lead engineer or project manager who is currently navigating their own design fog.

The premise is simple: take a product concept, run it through concept development twice. Run it once with a traditional structured method and once with the Pierce the Design Fog frameworks. Use the same cross-functional team and the same product brief. Then compare what engineering actually receives at the end.

Not what the method promises. What it produces.

I’m using AI-powered cross-functional team agents (six functions: engineering, manufacturing, quality, marketing, sales, and customer success) to run both trials. The AI is the mechanism that makes it possible to run two complete concept development cycles on the same product quickly enough to compare them directly. The story is what comes out.

The first two case studies are up now. One is a Class II medical device (a portable oxygen concentrator for COPD patients). The other is a service product (a post-installation service redesign for a residential solar company). Two very different product types, same experiment.

I chose these deliberately. The medical device case tests whether concept development can produce outputs that feed directly into HFE and risk management (analyses you’re required to run anyway). The service case tests whether the same methods work when there’s no physical product at all, just operations and user experience.

More case studies are coming. The playlist will grow as they publish.

📺 Watch the series: https://www.youtube.com/playlist?list=PLTtGpfRyyNcZ9qMVL2HmWA7heE3Idyfbt

📖 The method is in Pierce the Design Fog — available in paperback, eBook, and audiobook.

🤝 Workshops and advisory engagements at qualityduringdesign.com.

Quality during Design has been brought to you since 2021 from Deeney Enterprises and Dianna Deeney. This is the monthly digest sent on the first Friday of the month: gain insights, podcast highlights, and resources for engineering and product development professionals.

This month’s highlights at a glance:

📅 May’s Theme — Your team’s expertise isn’t missing. It’s just not showing up when it matters. What changes when you fix that.

📋 April Recap — Accidental systems, accidental outcomes. A solo episode on why lessons learned don’t stick, a conversation with aerospace engineer Cassie Leonard on engineering careers, and an article on why organizational problems aren’t personality problems.

🎙️ Conversations — I joined another show to talk about why good designs pass every review and still fall apart in manufacturing.

Coming up in May

Most product development teams don't have a knowledge problem. They have a structure problem. The expertise about failure modes, customer workarounds, and past design decisions exists…it's just not organized to show up when it matters. What changes in concept development when you fix that? What does engineering actually get? And how can you tell whether your team's knowledge is working or just sitting there?

Podcast, long-form article, and a guest conversation this month.

Free for all: Podcast episodes and blogs on deeneyenterprises.com.

What you get as a subscriber: My emails, free guides, templates, and vault downloads - everything organized in the Substack app.

Subscribe now

April recap

April was about pulling back the curtain on why organizations think they’re improving while quietly repeating the same patterns. One theme kept surfacing across everything I published: when systems are accidental, outcomes are accidental too.

Free Content

🎙️ Podcast Episode: The Quiet System: Why Your Lessons Learned Aren’t Sticking Teams aren’t careless — they’re operating inside systems built to react, not learn. This episode breaks down why organizations keep rediscovering the same problems and how protective structures unintentionally block information flow. Listen → https://deeneyenterprises.com/qdd/podcast/the-quiet-system-why-your-lessons-learned-arent-sticking/

🎙️ Podcast Episode: The ROI of Engineering Motivation with Cassie Leonard (A Chat with Cross-Functional Experts) Aerospace engineer and executive coach Cassie Leonard joined me to challenge the long‑held “pipeline” model of engineering careers. We dug into why linear career thinking fails both people and products — and what a more adaptive, human-centered approach looks like. Listen → https://deeneyenterprises.com/qdd/podcast/s3e19

🔍 Strategic Insights: Intentional Organizations Don’t Happen by Accident When something slips, leaders often look at behavior. But the root cause I see most often, both inside organizations and across industries, is systemic: unclear ownership, overlapping responsibilities, structures that create territorialism, and information that never travels to the people who need it. These aren’t personality problems. They’re design problem. Read → https://deeneyenterprises.com/qdd/articles/intentional-organizations-dont-happen-by-accident/

Conversations

Why Good Designs Fail

I was a guest on another podcast this month to talk about something that doesn't get enough attention: the invisible gaps between design, quality, and production. If you've watched a design move smoothly through every review and still fall apart in manufacturing, you know exactly what I mean. We dig into why no single team "owns" those handoffs — and how leaders can redesign them so quality isn't something you inspect at the end, but something you architect from the start.

​How to engage with me

If your organization is tired of firefighting what could have been prevented, let's talk. https://calendly.com/dianna-deeney/discovery-call

Learn more about all services

The list has names on it. Diagnostic Fidelity Threshold. Real-Time Inventory API. Safety-Critical Anchor Protocol. The names are good. They sound like engineering. They feel like progress.

And they are progress…up to a point.

The problem is that a feature name tells engineering what to build. It doesn’t tell them who it’s for, what step in the user’s experience it has to work in, what happens if it doesn’t work, or what “done” actually looks like. Those gaps don’t disappear when concept development ends. They show up later, in engineering, where the cost of resolving them is much higher.

A design input is different. A design input carries context. It traces back to a specific user, a specific moment in the use process, and a specific consequence if it fails. It tells engineering what they’re protecting against, not just what they’re building.

That distinction is always important. In service design, it’s critical.

When the product is a physical object, a feature list at least gives engineering something to hold onto. Dimensions. Materials. Load requirements. There’s a tangible artifact to interrogate.

When the product is a service, there’s no artifact. There’s a process, a set of human interactions, and a promise. And promises are surprisingly hard to engineer to if no one has mapped exactly what the promise requires at each step.

This is what I wanted to test in the first Pierce the Design Fog case study.

The product is SunCore 360, a fictional solar service redesign for a fictional residential installer called Luminos Energy. The design challenge: a 5.3-day average response time, a premium tier promising 24-hour service, and a BBB rating that needs to improve. The kind of problem where what engineering receives at the end of concept development genuinely matters. The gap between the promise and the delivery isn’t a technology problem, it’s a design problem.

I ran the same product brief through two concept development methods using a simulated cross-functional team running on AI. Same team, same brief, no variability. The AI isn’t the story. The AI is what makes a clean comparison possible. You can’t run this experiment in the real world because the team changes, the facilitation varies, the context shifts. The simulation holds all of that constant so the methods can speak for themselves.

The traditional method produced five engineering design inputs. Real work, like diagnostic algorithms, BOM linkages, safety protocols. But every input was feature-described. System capability names with no user attached, no use process step identified, no failure consequence named. Engineering can build from a list like that. But they’re carrying ambiguity that concept development didn’t resolve.

The PTDF/ADEPT method worked differently. It started with the user’s experience and moved forward from there: mapping the full-service resolution process step by step, identifying what adds customer value and what doesn’t, analyzing each potential benefit through a Kano lens, and running failure mode thinking at the concept stage rather than leaving it for engineering.

What came out wasn’t a longer list. It was a richer one. Every design input traced back to a specific user, a specific process step, and a specific failure consequence. Severity-ranked. Prioritized. With the FMEA-style thinking already done.

Three failure modes in that analysis didn’t appear anywhere in what the traditional method produced. Not described less precisely. Not present at all.

That’s the difference between a feature and a design input. And it shows up most clearly when the product is a service, because without a physical artifact to anchor the conversation, concept development either maps the human experience systematically or it doesn’t. There’s no middle ground to hide in.

This is the first case study in a new series. Each one runs the same experiment: same simulated CF team, same product brief, two methods, clean comparison. The cases will vary: products, services, industries, design challenges. The question stays the same: what does each method actually hand to engineering?

The video walks through the full SunCore 360 comparison.

SunCore 360 is a fictional case study. Luminos Energy and all characters are not real.

This week’s conversation with Cassie Leonard gave me a framework I wish I’d had years ago. It’s called expectancy-value theory, and Cassie translates it into an ROI equation for career decisions:

Every engineer is already solving this daily. This just gives them different language for it.

The insight that stuck with me most wasn’t about the equation itself. It was about the denominator.

When Cassie was deciding whether to leave her Fortune 100 role, one conversation with a senior manager nearly zeroed out her cost-of-failure. They told her, “Go try it. If it doesn’t work, call me.”

That’s it! One sentence that changed everything. How many people stay stuck or leave quietly because no one thought to say something like that?

If you lead engineers, the one question Cassie recommends adding to your next 1-on-1:

“If you took this opportunity, what do you think you’d be giving up?”

Not what they’d gain, but what they’d lose. That’s where the real conversation can start.

🎧 Full episode on Quality during Design. https://deeneyenterprises.com/qdd/podcast/s3e19/

On one side: the idea. Someone sees a need, makes a case, gets a project approved. There’s energy in the room and a direction.

On the other side: the design input. The CAD drawing, spec, formal requirements that engineering will actually build to.

Between those two things is a gap. And in that gap, teams are guessing.

• sharing reports that don’t quite answer the right questions

• making assumptions about the customer that nobody has tested

• having conversations that feel productive but aren’t converging on anything

The design engineer doesn’t know what to ask. The quality person doesn’t know when to speak up. Manufacturing isn’t in the room yet.

I’ve sat in those rooms. I’ve watched smart, experienced teams spin in that space. They didn’t lack expertise, but they lacked a shared language and a structure for the conversation.

That’s what Pierce the Design Fog is about.

It’s not a new design process or another framework to implement on top of what you already have. Just targeted tools and templates to help cross-functional teams get specific about what they’re designing, for whom, and why it matters BEFORE the model exists.

It’s prioritized around customer experience: what do users love, what frustrates them, where does the product fall short in actual use. And it brings the whole team (design, quality, manufacturing, sales) into that conversation while there’s still room to shape the answer.

I talked about this on a recent podcast episode with Martin Griffiths of Manufacturers Makes Rides (their image made me chuckle 👇). If you want to hear the conversation, the link is here. And if that gap I described feels familiar, Pierce the Design Fog is available at piercethedesignfog.com.

A new owner takes over a facility. He’s hands-on, engaged, clearly different from what came before. One of the first things he notices: the break room refrigerator has been broken for weeks. He says, immediately, “Why didn’t anyone tell me? Order a new one and get it here tomorrow.”

A week later, nothing had changed. The person responsible had ordered a cheaper option with a two-week lead time because under the previous owner, cost always won. Nobody escalated because, under the previous owner, nothing ever got done anyway.

So, the new owner went out that night, bought an industrial fridge himself, installed it before morning, and apologized to the staff.

The refrigerator wasn’t the problem. The system was.

The previous leadership had conditioned people to prioritize minimal cost over meeting basic needs. The new owner had to show, through action, that responsiveness was the new expectation. Until he did, the old rules still ran the place…silently, automatically, without anyone making a conscious decision to follow them.

That’s what an accidental organization looks like from the inside. Nobody chose it. Nobody designed it. It simply drifted into being.

The root cause is almost never the people

When something is slipping the instinct is to look at behavior. The slip could be a deadline, a process, a leader’s confidence that the work is actually on track. Who dropped the ball? Who should have escalated?

But the root cause I see most often, both inside organizations and across industries, is systemic: unclear ownership, overlapping responsibilities, structures that create territorialism, and information that never travels to the people who need it. These aren’t personality problems. They’re design problems.

You can coach an individual to navigate a broken system. There are limits, though, when the system itself is the problem.

The proprietary data wall

One of the most expensive patterns I see is one I call the proprietary data wall. Teams quietly relearn the same painful lessons because the mechanisms of failure are never shared – not across functions, not across projects, and not across product lines.

The intent is usually protection: protecting people, protecting liability, protecting the company. The effect is stagnation.

Here’s the part worth sitting with: in many industries, the reporting systems themselves reinforce the wall. Medical device manufacturers file MDRs (Medical Device Reports) when a device may have caused or contributed to a serious injury or death. Automotive has mandatory reporting obligations tied to safety defects and recall decisions. NASA has spent years trying to break down what it calls reliability silos across programs and contractors.

These systems exist for good reason. But notice what they’re designed to capture: incidents after the fact, routed through regulatory and legal channels. What they don’t do (can’t do, by design) is share the mechanisms of failure upstream, across organizations, before the next team makes the same mistake.

When liability dictates what gets documented in Lessons Learned, organizations don’t become safer. They just become quieter. And quiet systems don’t learn.

The shift that high-performing organizations make isn’t about abandoning protection. It’s more precise than that:

• They share failure mechanisms, not proprietary designs.

• They shift from “Who caused it?” to “What did we miss upstream, and how do we prevent it in the next FMEA?”

• They treat Lessons Learned as strategic inputs, not compliance artifacts filed away after a project closes.

For quality and engineering leaders, this isn’t about blame or liability exposure. It’s about protecting future design decisions, reducing rework, and building organizational memory that outlives any single project team.

The mark of a mature quality culture is one where learning compounds instead of resets.

What intentional looks like

GE didn’t tackle quality issues by asking people to try harder. They invested in shared systems: common language, decision frameworks, visible process data. These ensured leaders could see the work instead of guessing at it.

Toyota didn’t “arrive” at excellence. They treated learning itself as a system, one that compounded over time instead of resetting with each project. That’s why their performance looks effortless from the outside.

The difference isn’t resources, culture, or the right hire. It’s that these organizations made intentional choices about how work would flow, who owned what, and what would happen when something went wrong.

Intentionality is a system, not a personality trait

This is the part leaders sometimes resist: the work of becoming intentional isn’t a one-time project. It’s an ongoing operating discipline.

It means building shared language – not acronyms, which keep people out, but clarity that travels across roles and functions. It means structured conversations: using a flowchart when you need to understand who owns what, a fishbone diagram when you’re exploring a failure, a concept framework when you’re still shaping the problem.

And it means connecting strategy to daily decisions. When people understand how their work connects to the bigger picture (and who their internal and external customers are) decision-making improves. Accountability becomes easier when roles are clear.

A word of caution: over-constrained is still accidental

Can you go too far? Absolutely. Too much structure, too much documentation, and suddenly the system exists to be obeyed rather than to help people think. Gates that stop work instead of guiding it. Approval processes with no clarity on what’s actually being approved.

The question to keep asking is: how does this help people make decisions in their work? If you can’t answer that, the structure probably isn’t earning its place. Intentional systems are agile. If you find yourself unable to move, the pendulum has swung from accidentally undefined to accidentally over-constrained. Both are design problems.

The shift that gives me the most hope

Leaders usually bring me in when something is slipping. What I’ve found, consistently, is that I don’t need to push them to change. Once the system becomes visible and they can actually see what’s going wrong and why, the adjustments come naturally.

Clarity has a way of doing that. It turns a vague, demoralizing problem into a solvable one.
That’s the work: not fixing people but making the system visible. And then designing something better: deliberately, iteratively, with the humility to adjust when it breaks.

Intentional organizations don’t happen by accident. But they do happen.

Want to see where your system is leaking quality before it reaches engineering?

Subscribers get the Strategic Quality Integration Checklist: six diagnostic questions that reveal gaps in how your organization integrates quality from the earliest design stages. It’s a fast read with a high signal-to-noise ratio. Check what’s working. Anything left blank is your next leverage point.

You’ll also get access to the Swipe File Vault: practical templates and frameworks you can apply right away, built on the same principles as the checklist.

And if you want to talk through what this looks like in your organization specifically, visit qualityduringdesign.com/talk. Twenty minutes. No pitch. Just clarity on your next best move.

In this week’s podcast episode, I talk about why this happens. (Hint: It’s not because your team is careless). It’s because we accidentally build reactive systems that hide failure data instead of learning from it.

In this episode:
• Discover how protective, reactive systems create "quiet" organizations where vital failure data gets buried instead of shared.
• Learn the three essential shifts high-performing organizations use to turn lessons learned into strategic, upstream inputs.
• Understand why the pendulum swing toward over-constrained, paperwork-heavy processes is just another system design failure.

https://www.buzzsprout.com/1722601/episodes/18986368

There’s a moment that sticks with me. I was acting as a quality engineer on a new product development project. We had just finished putting together comprehensive supplier quality plans for critical components, and I ran a standard “lessons learned” review with the team.

Afterward, a director looked at the report and asked me: “What are we doing to seed this within the rest of the organization?”

That’s one of the most important questions he could’ve asked, and it completely changed how I look at system design. That director understood that a quiet system doesn’t improve. If we aren’t intentionally seeding our failures and successes back into the upstream process (like our next FMEA), we are destined to repeat our struggles.

The true mark of a mature quality culture is that learning compounds instead of resets.

If you’re feeling stuck in a loop of rediscovering old problems, I highly recommend downloading the Strategic Quality Integration Checklist or booking a quick 20-minute chat with me at qualityduringdesign.com/talk to map out your next best move.

I also attended a satellite conference in D.C. where I talked with many leaders and OEMs. Sadly, the leaders in the space sector notice a shift in “sovereignty”. What used to be pride is now about trust and security.

For the circles I work in and the work that I do - we cannot change people’s behavior or psychology. At least I’m not usually in a position (or honestly properly trained) to do so. We can influence decisions. And we can be intentional about what gets done, by whom, how, and when it affects decisions.

That’s systems thinking. That’s how we build intentional structures to avoid firefighting and emergencies.

This is what I’ve been pondering lately. So, April’s content is about being intentional for our work, our teams, and our own growth. The system you didn’t design is already running. April is about designing a better one.

Because intentional organizations and people don’t happen by accident. We can do something about it.

Dianna

Quality during Design has been brought to you since 2021 from Deeney Enterprises and Dianna Deeney. This is the monthly digest sent on the first Friday of the month: gain insights, podcast highlights, and resources for engineering and product development professionals.

This month’s highlights at a glance:

• April’s Theme

• March Recap

• SATShow 2026 takeaways

• Conversations

Coming up in April

Intentional organizations is the theme for April. This month includes a solo podcast episode, a guest interview, and a new article. Each one is a different angle on the same idea: intentional orgs build the structures to prevent the firefighting in the first place.

Free for all: Podcast episodes and blogs on deeneyenterprises.com.

What you get as a subscriber:

• My emails

• Free guides, templates, and vault downloads

• Everything organized in the Substack app with Q&A

Subscribe now

March recap

March brought some of the most direct conversations I've had on this platform about influence, timing, and what it really costs when the right people show up too late.

Whether you've ever walked out of a meeting wondering why you were even there, watched a product launch fall flat because marketing was an afterthought, or found yourself nodding along to a four-year-old argument that still hasn't been resolved… this month's content was made for you.

Below you'll find two podcast episodes and a strategic reflection that all circle the same uncomfortable truth: in product development, when you're in the room matters as much as what you bring to it.

Free Content

🎙️ Podcast Episode: Stop Being a Witness to Decisions That You Should be Helping to Shape If you feel like you’re late to the game, or that you wish they had involved you earlier, this episode is for you. I explore why this happens, why it feels so frustrating, and most importantly how to fix it. Listen → https://deeneyenterprises.com/qdd/podcast/stop-being-a-witness/

🎙️ Podcast Episode: Shannon Cummings on Why Marketing Should Be in the Room Before the First Prototype (A Chat with Cross-Functional Experts) Marketing as part of product design instead of a hand-off? I talk with Shannon about what that looks like and why it’s important. Shannon and I both come from medical device backgrounds, but once you’ve lived a project with Marketing involved, it’s difficult to want to do it any other way. This applies to you no matter what industry you work in. Listen → https://deeneyenterprises.com/qdd/podcast/s3e18

🔍 Strategic Insights: Four Years Later: Why Quality Still Needs to Move Upstream In 2022, I published an article about the future of the quality profession. The core message was stark: if quality departments don’t evolve beyond their traditional roles, they risk becoming obsolete. Now, in 2026, I’m revisiting that piece. Not because I was wrong, but because I was right. And that’s the problem. Read → https://deeneyenterprises.com/qdd/articles/quality-upstream/

SATShow 2026: Takeaways from the satellite conference

I sat in opening presentations, panel discussions, and walked the floor of this conference in D.C. last week. Here are some of my initial notes.

Growing pains

I see in the space industry many of the hurdles that other (now traditional) industries needed to address when they were growing. For one, the market power is among too few players. There’s a need to encourage more companies to enter the industry. This was stated as part of a panel discussion of leaders in this space. Everyone I have talked with about this industry, outside of the show, also recognizes this.

The barriers to entry (pun intended) are great.

• Components are expensive with long lead times, and now also more in demand. This is so much of a problem that there are dedicated businesses that will act as a middle-man order-er to ensure parts are available when needed. They are not warehousing parts, like Grainger, because of chain-of-custody requirements. When you need parts, get them from your warehouse at a markup. This is a supplier management and manufacturing throughput problem. With a global market, cutting edge tech, and growing demand, this will be problem to navigate for decades. Can we look to more mature industries like automotive for lessons learned?

• For new companies, what’s known about space is hidden behind proprietary data walls. These walls are behind the companies that have been in space for longer: Boeing, Northrop Grumman, Lockheed Martin, etc. Information about how to build, what works, and performance limits are not openly shared. There are standards, but they are difficult to interpret or apply. Proprietary data is a consistent hurdle for reliability engineers in any industry. MedDev has required reporting made publicly available - the intent is to make data available to improve outcomes. How can we model meddev for space?

• To learn, the “build fast and see what fails” method is being employed in space itself, but then there’s a bunch of space junk that “no one is taking care of”. Also, the satellites being used as communication nets are dedicated to last for just a few years. Here on earth, there are organizations fighting hard for right to repair laws to reduce waste and conserve resources. I didn’t hear about space junk as a concern, or that there were constraints for what is launched into space. What can be adopted from consumer products to apply to space waste?

We’ve collectively learned hard lessons already from automotive, medical devices, and consumer products. We need to apply that, now, to space.

Getting to space and getting the tech to work is already difficult enough. They don’t want to be constrained - build and launch. There’s a race!

Must we put more boundaries on it? Yes. But we better know how to do it this time.

We do lessons learned on projects. As a collective human race, we’ve already learned through the development of these other industries. To do it better, let’s look to those other industries for lessons learned and apply it to this new frontier.

AI was a topic, of course

The most insightful comments about AI came from Lisa Rich, COO of Xplore, Inc. AI is the “delivery system for the data”. AI is for writing algorithms to send to satellites to get quality data, and to bring more data from space to earth. Their target with AI: quality data at low cost. I think this is a wonderful way to think about AI!

LLMs are going to become a partner in discovering the root causes of complex systems. They’re figuring out how to use this type of AI to solve problems faster. As a test, an engineering firm gave an LLM context for a problem that took them months to solve. Frustratingly, the AI pinpointed the root cause in 10 minutes. They noted there might be bias at work since they knew what the root cause was. The results were not scientific, but striking given the months of human effort required to find the same answer.

Navigating sovereignty

I noted in my opening letter that the leaders in the space sector notice a shift in sovereignty: what used to be pride is now about trust and security. When the stage is space (a ‘contested’ area), builders for space equipment must build for global use while being able to make their technology adaptably ‘sovereign’ for individual entities: countries, organizations, or regions. They are trying to ally these space systems and navigate these political complexities.

Heading to the moon!

I was at a sports bar when I got a text from my mother about the Artemis II launch in 5 minutes. I asked the bartender if we could change one of the channels to NASA, and they obliged! We all watched it, and it sparked conversations about space around the whole bar. Good luck to the people on the mission: we’ll be watching from here!

As a side-trip to the SATShow, I got a behind-the-scenes tour of a NASA facility where the LEMS project (lunar environment monitoring station) is being finalized. I’ll write more about that later.

Conversations

Piercing the Design Fog: How to Lead Effective Product Development Meetings

In this episode of the Iferia Techcast, I break down why traditional product development meetings are often broken, leading to expensive rework and siloed departments. I share some powerful statistics that show why investing in the early conceptual phase leads to significantly more successful products. We also discuss redefining "quality" from a final checkpoint to a day-one creative tool, how solo developers can use AI as a cross-functional partner, and the surprising connection between innovation, potato chips, and violins.

​How to engage with me

If your organization is tired of firefighting what could have been prevented, let's talk. https://calendly.com/dianna-deeney/discovery-call

Learn more about all services

I recently spoke with Shannon Cummings on the Quality during Design podcast. I’ve never worked with Shannon, only followed his posts on LinkedIn. But when he shared how his team launched a medical device in half the typical time by getting aligned earlier (not working harder), I knew I wanted to find out more about it.

What stayed with me was a shift in how the team operated. Engineers weren’t just building; they were listening. Marketers weren’t just messaging; they were shaping the product. And that integration started before the first prototype, not after.

That’s the piece I think most teams skip. Marketing gets a seat at the milestones. Rarely the messy work in between, where the real decisions get made.

If you’re working on a product right now and marketing isn’t already in the room, it might be worth asking, “Why not?”

🎧 Full conversation here: https://deeneyenterprises.com/qdd/podcast/s3e18/

Dianna

Now, in 2026, I’m revisiting that piece. Not because I was wrong, but because I was right. And that’s the problem.

This article resides on my website, where you can find other related resources.

The Pattern That Won’t Break

Most organizations still treat Quality as compliance, not leadership. The data confirms this hasn’t improved, and in some critical areas, it’s getting worse.

Quality is losing strategic ground. ASQ’s 2025 Insights on Excellence Benchmarking Report reveals a troubling trend: only 74% of 2024 respondents agreed that “the need to manage business risk drives their pursuit of quality”. This is a 15-percentage point drop from just two years ago. Even more telling: of those who agreed, only one-third completely agreed, meaning two-thirds believe their organizations are failing to adjust based on customer-tied performance indicators.

Organizations are pulling back from strategic change. The same report shows only 33% of respondents said their organization’s quality strategies actually promote achievable objectives. This is a 22-percentage point decrease from 2022. Quality strategies aren’t connecting with reality.

The workforce isn’t prepared for what’s coming. Only 30% of respondents said their organizations effectively prepare their workforces for future necessary skills, meaning 70% feel unprepared. The top skills requiring improvement? Data analytics, problem solving, cross-functional teamwork, strategic implementation, and communication. This is exactly what quality professionals need to move upstream.

Data silos remain a critical barrier. DATAVERSITY’s 2024 Trends in Data Management survey found that 68% of organizations cite data silos as their top concern. This is a 7% increase from the previous year. When quality remains isolated in functional silos, the entire organization suffers.

Cross-functional collaboration is still broken. The same survey revealed that among organizations with defined data architectures, just 32% see better collaboration with business teams. Perhaps most telling: 26% of respondents admitted they don’t have a defined data architecture at all.

These aren’t just quality problems. They’re business problems. Poor data quality leads to poor customer relations, inaccurate analytics, and bad decisions that harm business performance.

What I Wrote Then Still Holds Now

Back in 2022, I argued that the quality profession was at a crossroads. External pressures were mounting. Increased customer communication, big data, expanding regulations, and relentless innovation demands. Businesses had to react quickly, and quality needed to keep pace or get left behind.

I wrote about how quality needs to move out and integrate into other areas of the organization to remain relevant and useful. Not as gatekeepers. Not as the department people “don’t want to fight with anymore”. But as strategic partners.

The warning was clear: if quality professionals don’t adapt, decisions will be made without them. Decisions will be based on gut instinct and abbreviated metrics instead of proper quality methods. The business loses money. Teams lose capability. And quality loses its seat at the table.

Subscribe now

But the Companies That Get It Right Are Winning

Here’s what’s different now: we have more proof of what works.

LNS Research’s 2025 report emphasizes that companies that lead with embedded and delivered quality achieve +23% net profit margins and +20% more successful new product launches. The same research shows that companies leading with Delivered Quality and disciplined Operational Excellence are key differentiators. LNS Research’s 2025 Industrial Productivity Index made it unambiguous that quality is a competitive advantage, not just compliance.

Baldrige Award recipients consistently demonstrate this. These aren’t theoretical case studies. They’re real organizations that have documented performance improvements by integrating quality into strategic decision-making. The 2024 Baldrige Award recipients show a clear pattern: organizations that embed quality leadership throughout their operations (not just in isolated quality departments) achieve measurable success.

What do individual practitioners see?

I conducted two polls on Linked-In, Substack, and to my newsletter subscribers. The sample size is low and limited to my network (i.e. biased), but there’s still something to learn from them.

Here are the results:

My network shows earlier integration leading to better business outcomes. Some additional insights from responders:

• One key for earlier reliability discussions is NUDS: what’s new, unique, difficult or special? This is a great conversation starter as a gateway to deeper discussions.

• While quality/reliability can be a big influence on the technical outcome, business outcomes are complicated. It can depend on the size of the company, the product being developed, and the maturity of its leadership and systems. So, while there’s influence, it’s not the whole picture.

• Design for Reliability is a generally accepted practice nowadays in some industries. The difficulty lies in measurement. With earlier integration of prevention, how do you know what you don't know? The key, here, will be to either compare results against predictions based on other, previous projects. Or to measure inputs. For example, I cover measuring the effectiveness and efficiency of FMEAs with tactical and strategic metrics in the Udemy course: FMEA in Practice.

The Shift That’s Still Needed

Quality needs to move upstream. That means:

Into customer and market insight

Understanding the voice of the customer isn’t just about complaint tracking. It’s about monitoring multiple channels, anticipating needs, and shaping what quality means to the brand.

Into early-stage alignment

Quality tools applied early in projects prevent costly issues down the line. Short-term timeline gains from skipping quality activities lead to long-term pain.

Into decision-making, not just documentation

Strong quality leadership should be in the boardroom, helping define brand quality, guiding infrastructure changes, and ensuring data-driven decisions.

What This Actually Looks Like

In my 2022 article, I outlined practical roles quality can play:

• As mentors who help others use quality tools effectively

• As service providers with clearly defined internal customers

• As experts who guide critical decisions

I also emphasized that quality management needs to define what they want to be in the organization and make that clear companywide. Without that clarity, quality initiatives get strangled and people don’t know how to adapt to changing environments.

Putting This Into Practice

This is why I founded the Quality during Design network and wrote the book Pierce the Design Fog. The network brings together the people and ideas. In the book, I lay out the exact frameworks and conversations that help teams move quality upstream before the first line of code is written or the first engineering model is created.

It’s about moving Quality upstream, into product design and the “room where it happens.” It’s about facilitating cross-functional conversations that lead to better data and improved decision-making, not gut feel.

My 2022 article was a wake-up call to some in the quality profession: to remain relevant, you must shift your thinking.

But here’s what matters: I didn’t create Quality during Design just for me to stay relevant. I created it as a way to showcase HOW Quality can be part of product design and early decision-making. My goal is to share the frameworks, processes, and other methods to actually do it: to improve decisions with data and collaboration.

Because it’s one thing to say, “Quality needs a seat at the table.”

It’s another to show up prepared with the tools and approach that make you invaluable once you’re there.

Why I’m Bringing This Up Again

Because the predictions still hold.

The external pressures I identified in 2022 haven’t eased. Instead, they’ve intensified. Customer expectations are higher. Data is bigger. Regulations are tighter. Innovation timelines are shorter.

And yet, too many quality professionals are still out-of-sight, out-of-mind. Shuffled into silos. Working remotely without strategic connection. Unclear on whether they’re mentors, service providers, or experts.

The businesses that figure this out win. They add quality professionals who contribute to profitability, build portfolios of business wins, and become instrumental to success.

The ones that don’t? They’re still fighting with Quality.

Read the Full 2022 Article

I’ve kept the original article where it was published, on CERM Risk Insights. If you want the full context (including specific examples, industry changes like Quality 4.0, and the detailed case for why quality leadership matters). You can read it here.

The question now isn’t whether the future I described is coming.

It’s whether you and your organization are ready for it.

If you lead a quality or product development team at a med device company and this pattern sounds familiar — I'd like to talk about what moving upstream actually looks like for your team. https://calendly.com/dianna-deeney/discovery-call

And as I sat there, I realized something: I’d been to this meeting before. Just with a different name. I’d shown up to design reviews ready to challenge, to question, to problem-solve. But then only to find the story already written. The evidence curated. The decision already made.

Here’s what I’ve learned: real influence doesn’t happen in the meeting. It happens in the hallway. In the coffee chat. In the quiet conversations before the agenda is set.

Listen to the episode here: https://deeneyenterprises.com/qdd/podcast/stop-being-a-witness

This week, I’m challenging you: pick one upcoming decision. Choose something mid-project that should’ve been decided at the start. Then go have that conversation now. Before the meeting. Before the story is written. Before you’re just a witness.

Because the best kind of influence isn’t loud. It’s early.

Subscribe now

In March, we’re talking about timing and why it’s one of the most expensive things your team gets wrong without realizing it.

Not deadlines or project schedules. The kind of timing that determines whether your engineers have real input into a product, or whether they’re brought in just late enough to inherit problems they had no hand in creating.

If your team regularly surfaces issues at design reviews that should have been caught two phases earlier, that’s a timing problem. If your quality engineers are spending more time documenting failure than preventing it, that’s a timing problem. And if the people closest to the product don’t feel like contributors to key decisions, that’s a timing problem with a culture cost attached.

This month’s content looks at how teams can shift that pattern with practical tools your engineers can actually use, and frameworks to help you see where the bottlenecks are.

Whether you’re managing the team, shaping the process, or doing the day-to-day work of keeping a product development effort on track, there’s something here worth a conversation.

Dianna

Quality during Design has been brought to you since 2021 from Deeney Enterprises and Dianna Deeney. This is the monthly digest sent on the first Friday of the month: gain insights, podcast highlights, and resources for engineering design professionals.

This month’s highlights at a glance:

📅 March Theme: Timing Is Everything When cross-functional collaboration happens early enough to shape decisions, not just react to them.

🎙️ February Recap: Constraints Unlock Creativity A solo episode, a guest interview with Karli Auble, and an AMA. Three formats, one throughline: early thinking makes everything downstream faster and better.

🎤 Dianna in Conversation Four recent podcast appearances — on the SAFE Leader, Antifragility Reframe, The Thoughtful Entrepreneur, and Speaking of Reliability podcasts — covering design fog, unspoken assumptions, and taming requirements.

📊 New Polls — We Want Your Take When a project goes sideways, what’s really to blame? And where does your org actually put its quality energy? Cast your vote and see what your peers say.

Coming up in March

We’re exploring what it looks like when cross-functional collaboration actually works. When customer voice, quality thinking, and market insight show up early enough to shape decisions instead of just react to them.

And we’re getting into the real barriers: the incentives, the habits, and the structural patterns that keep the right conversations from happening at the right time.

This month includes a solo podcast episode, a guest interview, and a new article. Each one is a different angle on the same idea: the earlier you have the conversation, the better the outcome.

Free for all: Podcast episodes and blogs on deeneyenterprises.com.

What you get as a subscriber:

• My emails

• Free guides, templates, and vault downloads

• Everything organized in the Substack app with Q&A

Subscribe now

February recap

February content explored a theme that might surprise you: constraints aren't the enemy of creativity, they're the engine of it.

In the solo podcast episode, we dug into how having the right frameworks at the concept stage (right after business approval, before detailed design kicks off) actually unlocks better, more targeted ideas than starting from a blank slate.

The guest episode brings in Karli Auble, who connected positive psychology with engineering practice, specifically the human dynamics that derail projects, damage relationships, and lead to burnout. She shares how her THRIVE framework helps teams work better together.

And if you want to go deeper, the AMA article walked through the frameworks, templates, and a real-world example for generating high-quality design inputs before a single prototype exists.

Three different formats, one throughline: the thinking you do early makes everything downstream faster and better.

Free Content

🎙️ Podcast Episode: Constraints Unlock Creativity: Why Frameworks Beat Blank Slates in Product Concept Design Discover how the Goldilocks principle and Concept Space Model unlock creative, high‑impact product ideas—right after business approval and before detailed design. Listen → https://deeneyenterprises.com/qdd/podcast/constraints-unlock-creativity-why-frameworks-beat-blank-slates-in-product-concept-design/

🎙️ Podcast Episode: Karli Auble THRIVES: Positive Psychology Meets Engineering Rigor We talk about the human errors that can derail projects, damage relationships, and lead to burnout, and what to do about it. Karli’s THRIVE framework helps. Listen → https://deeneyenterprises.com/qdd/podcast/s3e17

🔍 AMA: Creativity Loves Constraints What if your team could generate high‑quality, targeted design inputs before a single prototype exists? This deep‑dive reveals the frameworks, templates, and real-world example that make early‑stage concept development faster, clearer, and dramatically more creative.

https://deeneyenterprises.com/qdd/articles/creativity-constraints-concept-development-frameworks/

Conversations

Piercing the Design Fog on the SAFE Leader podcast.

I joined Dr. Mark McBride-Wright on the SAFE Leader Podcast: “This is a powerful conversation for engineers, product leaders and anyone building solutions for real people. If you care about clarity, collaboration and designing products that truly work for their users, this episode will change how you think about quality forever.”

If this is you, then check it out! Then leave a comment with your thoughts on YouTube.

Antifragility is built in the fog: the Antifragility Reframe Podcast

I recently joined Dr. Frank L. Douglas on The Antifragility Reframe podcast, and this one covers territory close to everything I write and teach about.

We talked about why unspoken assumptions are so dangerous in early design, how cross-functional teams can turn constructive conflict into a strength, and what it really means to target customer experiences before you start building solutions. Antifragility, it turns out, is built in the fog — before the drawings, before the prototypes.

👉 Listen here:

Entrepreneurial insights to product design

Host Josh Elledge and I talked about something I see trip up product teams constantly: solution jumping — rushing to build before truly understanding the problem.

We got into how staying in the problem space longer actually accelerates your path to market, and how quality thinking isn’t a late-stage checkpoint — it’s a day-one design tool.

🎙️ Give it a listen:

How reliability engineering work gets done and how to tame requirements: on the Speaking of Reliability podcast

Mojan and I cover a few more topics on the “Speaking of Reliability” Podcast.

SOR1150 - Reliability in Start-up vs. Established Businesses Join Dianna and Mojan as they compare the challenges of implementing reliability programs in fast-paced startups versus well-resourced, established corporations. https://accendoreliability.com/podcast/sor/sor-1150-reliability-in-start-up-vs-established-businesses/

SOR1151 - Why Your Product Requirements are Slipping (and How to Fix Them) Mojan and Dianna explore the often-murky transition from vague product “needs” to actionable engineering requirements. https://accendoreliability.com/podcast/sor/sor-1151-engineering-requirements-development/

​How to engage with me

If this content resonates with your team’s situation, let’s talk. https://calendly.com/dianna-deeney/discovery-call

Learn more about all services

New polls

I want to hear from you - what’s your experience? I’ll include results in one of April’s posts.

Last month’s poll: How early does Quality/Reliability get involved in new product development?

Last month I hosted two polls on the newsletter and social. I asked questions about quality and reliability early in product development.

I summarize the results as part of the in-depth Strategic Insights post being published this month. Subscribe to get it when it publishes!

Subscribe now

But what about the error codes your own body is sending?

→ Heart racing before that meeting
→ Shoulders tensed up to your ears
→ Mind scrambling for an exit strategy

These are warnings. And ignoring them leads to costly mistakes.

I just interviewed Karli Auble, an engineering leader in defense who combined systems engineering with positive psychology to create a framework that prevents human failures—the kind that derail projects, damage relationships, and lead to burnout.

In our conversation, she reveals:

✓ The simple breathing technique Navy SEALs use in combat (that works in conference rooms too)

✓ Why your office environment is sabotaging your decision-making

✓ How to have difficult conversations without triggering fight-or-flight responses

✓ The real reason technical debt starts with human stress

Here’s your challenge this week: The next time you feel tension building in a meeting, don’t push through it. Treat it like an error code. Ask yourself: Is it safe to keep flying, or do I need to recalibrate?

👉 [Listen to the full conversation here] to learn how the THRIVE framework can improve both your engineering work and your well-being.

Because the most expensive failures aren’t always technical ones.

This is part of our “Chat with Cross-Functional Experts” series on the Quality during Design podcast, where we explore how different disciplines make engineering teams more effective.

Subscribe now

My kid got an electronic drum kit recently. We’re about a month into having it and it’s starting to look a little dusty. So, I started searching for videos about drummers on YouTube to share with them. You know, as inspiration. “Isn’t that cool? You should try it!”

It didn’t work to inspire my kid. However, I was the one who got sucked into Drumeo’s series on YouTube. They take tracks of popular songs, remove the drum track layer, and “present” it to guest drummers. My favorite episode so far was with Ashton Irwin.

Drumeo’s Show is all about Creativity within Limits

The guest drummer’s task: fill-in the drum piece.

The catch: they need to do it for a popular song they’ve never heard before.

Every guest drummer is nervous. They’re creating their own version of an already recognizable and popular song. What if the original drummer finds this episode and watches them butchering their song? What will fans think as they compare and judge their on-the-spot performance?

They get to hear the song once, sometimes twice. Some mark up a piece of paper as a sort-of cheat sheet music. Some listen intently and play around with a few licks. They hear the singers, the guitar riffs, the base. There’s structure there. There’s already a beat and a pace. There are solo sections and a chorus.

They work it all out. Then, it’s time to record. It’s fascinating to watch their creativity flow.

What always happens at the end? They’re smiling. They did the best they could. And it was awesome!

The Song is the Framework

Why does this work?

Can you imagine inviting a world class drummer into a studio to just record a few licks? Find a groove? I bet we’d hear great things. But, meh. I’ve watched those YouTube videos, too. While I appreciate their talent, it’s sanitary and lacks the type of creativity that, well, creates new things and pushes boundaries!

This challenge of creating within an existing song works because the song provides a framework.

It’s a structure within which to create. It’s a limited time. The beat and pace are set. The times when the chorus kicks in and the space for riffs is already defined. There’s even an obvious genre, and the drummers take cues from that, too.

Now, within that framework, they can let loose and be creative. Everything they know goes into that moment. Sometimes it sounds nothing like the original. But it always sounds good.

Frameworks are best when targeted, including in Concept Development

It’s not just Drumeo’s show where this works. This also works in Concept Development.

No Guardrails is No Bueno

Imagine inviting a world-class marketing expert who knows all about your customer and how to successfully market this new product concept. You invite him or her into a room to get their ideas about this big product concept that hasn’t quite taken form, yet.

What type of ideas are you going to get? “Meh” ideas is what you’ll get.

This is just like inviting a world class drummer to play around on the drums. It’s not creative. There’s too much space for their creativity to really shine.

A Prototype Design Introduces Fixedness

Alright. So, what if you wait for the design to have a prototype, then invite the world-class marketing expert to share their ideas about the design? They can change whatever they want.

Ah, “too late!”

They had awesome ideas, but now that they’ve seen your prototype they’re experiencing fixedness, a cognitive bias. Why be creative when it’s already done? Or (if that sounds too lazy), there’s not much creativity they can add to what’s already been decided.

This situation is as if Drumeo played the whole song, with the original drums, to the guests. It would be difficult to unhear the original drum licks, wouldn’t it? They’d start to copy it. Adjust their ideas to fit into what was already done. They would more likely play their version like the original, with maybe a few additions or subtractions.

Frameworks are Just Right

Now, you invite the marketing guru to a concept development working session.

You’re focused on the customer:

• Where they are when they use your product? We check the conditions and their/our assumptions.

• What’s the basic use process, in 7 steps or less? Where do customers start and where do they end up?

• When things go right, what benefits do they experience?

• When things do go as planned, what symptoms might they experience?

This is the Concept Space Model: a framework for team creativity in concept development. The bees are just avatars, there to remind us that we’re not designing features, yet. We’re focused on the customers.

This visual model is like Drumeo’s song without the drum track. It provides guardrails (we’re talking about this customer within this use scenario and these results). It enables creativity of the best talent to work within these guardrails to come up with product concept ideas.

Targeted Frameworks Based on What You Want to Learn is Concept Development Gold

The Concept Space Model offers an opportunity for alignment and a complete project understanding. It’s too high-level and not executable from an engineering perspective. though.

Let’s drill down a little using the Benefit-Impact Template. Here’s how:

Let’s say there’s an intriguing benefit that we want to explore more with this potential product offering.

• Can we express this as having an available feature or characteristic and the impact that has on our customer?

• What product ideas could enable the feature/characteristic to be available to our customer?

• What offerings could drive the positive impact even more?

Finally, given these opens and how we might make it happen, what is the overall effect on our customers?

• Is this something that just has to be part of our product, as a bare minimum?

• Is this a situation where the better we do it, the happier they are?

• Is this so mind blowing, we wouldn’t need to hardly do it at all and they’d still be excited?

This is what working with a template and the ADEPT Team Framework can do for you.

The ADEPT Team Framework is a process for team collaboration, including the steps Align, Discover, Examine, Prioritize, Teamwork. It’s a framework we can use to improve our creativity toward targeted customer benefits of our concept product. If you want to read more about ADEPT, see this article.

We haven’t even designed anything, yet! We just have an idea. But here we are, developing ideas about potential features and characteristics, and then prioritizing them against how well our product should deliver it. As you can see, the Benefit-Impact Template is easy to replicate, but puts up guardrails for the team to develop ideas. It’s designed to be targeted toward a design that can be engineered.

There are frameworks for exploring symptoms and the use process, too. They’re all explained in Pierce the Design Fog.

Subscribe now

The Effectiveness of a Visual Template Depends on its Design and Alignment with the Task at Hand

I explore why frameworks work in Pierce the Design Fog, Chapter 4: “The Art of Using Models to Ignite Ideas”.

Structured idea generation with visual models and templates improves

idea quality. Researchers say visual templates help structure a process,

improve focus, and lead to more and higher-quality ideas. When planning

a meeting or workshop, it’s important to choose or create visual tools that

are right for the specific job. Generic tools may not work as well.

A multinational telecommunications company was seeking ideas

for a five-year product pipeline. They asked employees to take part in

unstructured brainstorming for six months using a generic visual template.

The template prompted them to give their idea a headline, describe it “in

a nutshell,” and then sketch it. There was also space on the template for

employees to list how their idea might relate to existing business platforms.

Over those six months, people generated 93 ideas but only three were

considered high-quality.

Then, company leaders changed their visual template to be more specific

to innovation. The template was about the same size as the previous one but

asked different questions with a single deadline. It still required an idea

name and description, but it also asked employees to identify prospective

customers, their motivations to use the product, and the benefits they would

derive from it.

This time, the process resulted in 11 high quality ideas in a single

session. The change from the generic template to the specific template

represents a more than 300% improvement in the number of high-quality

ideas. In addition, using the structured process with a visual template saved

the company two months of work.

Visual models and templates work. They’re successful because of their association with Activity Theory. Activity Theory is a framework used to understand team activities in educational research, psychology, and organizational studies. According to this theory, using shared and easy-to-understand tools improves teamwork, maintains focus, and prevents confusion. These tools or objects are clear, memorable, and ensure everyone focuses on the same things.

They also work if they are focused on what it is we want to learn. With concept development, we want to get to the point where we can have potential features, characteristics, and offerings and understand how that relates to the customer experience. And we want to be able to do this without actually doing engineering design, yet. Instead, we’re working on the bridge from targeted customer experiences to design inputs and engineering requirements.

A Case Study: an Electronic Maraca

Let’s look at an example of a benefit-impact template for a new product.

We’re developing electric percussion accessories: an electronic version of the maraca. Not a sample pad for the drummer to hit. It’s a hand-held device that can be recorded on the same track as the e-drum kit. This is our product idea. (In real life, this doesn’t exist. So, maybe we’ll inspire the drum kit makers!)

The customer need is to be able to record a maraca sound with the electronic drum kit while mimicking the motion of a maraca.

• A market needs analysis has been done. We’ve concluded there’s indeed a hot market. Bands already use and record sampled percussion. But background singers want to play the maraca as a percussion instrument while also being able to directly record. (I don’t know if this is really the case, but it seems feasible and we’re going to go ahead for our working example).

• A technical feasibility study has been done. We have the in-house capability to do it using mostly OEM components with custom housing that we can make.

• Looking at our portfolio of products, we think we can make it with healthy profit margins, and it fits within our business structure.

Because of all that, the company has approved the project to develop it.

We get our cross-functional team together: the project manager, marketing rep, engineering lead, sales rep, manufacturing, and a paid percussion rep. For our paid customer rep, we’re going to ask for Ashton Irwin because he nailed that Megadeath song and his best friend back-up singer is a maraca player (we can pay her, too).

We ask that the team review the information that led the business to approve this project (marketing needs, technical feasibility, etc.). This should be something they’re doing already.

E-Maraca Concept Development

If you’re an engineer, you’re probably already thinking about gyroscopes, latency, and power sources. But hold on! I implore you to:

Before we start, we’re clear that the project manager is going to facilitate and that this is a development activity that feeds into product direction decisions.

1. First, we draw out the concept space with inputs and outputs on our shared whiteboard (virtual or physical).

2. Next, we consider our users at the input. Where are they (physically, mentally)? What are they assuming as they reach for our product?

3. Then, we consider our users at the output. What has happened?

   1. When it works like it should, what benefits are our customers experiencing? The team prioritizes their top 3 picks for further work.

   2. When it doesn’t work like expected, what symptoms are our customers experiencing? The team prioritizes their top 3 symptoms.

4. Finally, we consider the use process.

   1. What’s the first thing we think our customers do?

   2. What’s the last thing they do?

   3. What are the 3-5 steps they take in using our product to get from start to finish?

Our Team's Concept Space Results

Here’s the results of our team’s co-working session:

You’ll see the team performed an affinity diagram exercise on the benefits so they could better understand the list. This just means they silently grouped benefits and symptoms into categories.

Focusing on Benefits

Coming out of our first concept development activity are these categories and potential benefits:

• Authentic User Experience & Performance

  • Natural feel & response 🔴

  • Authentic Performance Experience

  • Rhythmic Freedom

  • Expanded Role Capability

• Technical Recording Quality & Accuracy

  • Ultra-Low Latency

  • Guaranteed Clean Recording

  • Unique Content

• Product Reliability & Business Value

  • High Durability

  • Consistent Build Quality

  • Reduced Warranty Claims

  • Efficient Power

• Setup, Integration, & Customization

  • Quick Integration 🔴

  • Customizable Sensitivity 🔴

  • Instant Sound Swapping

  • Ergonomic Housing

All of these are worthwhile ideas for design inputs. However, the team prioritized three that they want to do a deeper-dive on, highlighted with red dots. So, we decide to further explore those benefits.

Next step: Ensuring impact, collecting drivers, and prioritizing

Beforehand, we decide that the engineer is going to facilitate these sessions. We’re not designing in the meeting but instead exploring options that might become part of the design.

We review our prioritization rating scale which will help us categorize features based on customer satisfaction. It helps teams determine if features are mandatory, one-dimensional, attractive, neutral, or negative.

Each benefit gets its own template and goes through its own ADEPT cycle.

1. First, we want to turn this benefit into a Benefit-Impact Statement: [Our Customers} can [have this feature/use this characteristic] so they can [experience this positive value]. We add that to the top of the template.

2. Next, we list feature drivers, the reasons why the product offers certain capabilities or characteristics. (They are the steppingstones to creating design inputs for the product itself).

3. Then, we list impact drivers, the factors that affect the impact of the feature on the user. (Understanding these can help increase the value and positive experiences for the customer and can lead to design inputs or service-related offerings).

4. Finally, considering 1 through 3 above, we examine what we have to come to a common understanding of it, and prioritize this targeted benefit against the prioritization criteria.

The team’s results:

For our three priorities, the team completed the benefit-impact statement and template, with drivers and a priority/satisfaction rating.

1. Natural Feel and Response

Benefit-Impact Statement: Our customers can use the Electronic Maraca Simulator (EMS) with realistic weight and responsiveness so they can transfer their muscle memory/motion for a natural maraca.

2. Quick Integration

Benefit-Impact Statement: Our customers can connect the EMS to their existing drum module or DAW so they can setup fast and reliably and immediately play.

3. Customizable Sensitivity

Benefit-Impact Statement: Our customers can adjust the motion sensor sensitivity and trigger threshold so they can tune the instrument precisely to their personal playing dynamics.

The Team’s Results and How I Would Advise Them

First of all, our team did well to clearly define the benefit as an available feature/characteristic and its impact to the customer. Good job team! 👍If there was a benefit that we couldn’t clearly do that for, then we’d need to evaluate if it was really a benefit. If it has no impact on the customer, then why consider it a benefit?

What we must get right

Since they rated the “Natural Feel and Response” as a must-have, our design MUST be able to deliver on this, at a minimum. If not, our customers will not buy it or recommend it.

We must get the weight, balance, ergonomics, and latency just right, or it’s a failure for our customers, who want to “play” the maracas whether they’re digital versions or not.

Our team has already identified other factors that can increase the positive playing experience even more, like supporting complex rhythm performances. We should take these into considerations in UX and involve customers in our design review loops for this aspect.

What we should work hard to do: the better we do it, the more our customers will love it

Our team rated the “Quick Integration” as one-dimensional. The better we do this, the more our customers will love it.

We’ll want to spend time to design-in features like standardized, common connectivity protocols; plug-and-play; and robust connection ports. And we look to the impact drivers to make the user experience even more special.

What we should offer as a special feature.

The team rated “Customizable Sensitivity” as attractive. This is where we deliver the “wow” factor, the reason people would want to buy it. We don’t necessarily have to implement it perfectly to get great customer reviews.

This could be what makes our e-maraca a huge market win!

Examining Other Areas of the Concept Space Model

Back to our Concept Space Model, we notice there’s a lot of symptoms listed. If our product doesn’t do what it’s intended to do, then it’s going to be a problem making this product a success in the market. Not addressing these could make it a flop. But we’re in concept development - the perfect time to address them!

Because of this, if I were on this team I would be advocating for us to focus on these symptoms. We’d either work to design them out or put in controls to manage them or lessen their impact. Our next step to do this is to use the Symptom-Impact Template with the ADEPT Team Framework. We’d explore the potential symptoms more, similarly to how we did benefits.

With the use process (pictured with the blue Post-it notes), let’s face it head-on. A new e-maraca is going to have a lot of unfamiliar use steps to our customers.

• What areas of our use process are new, different or unknown? Do we need to break them down further (i.e. expand the steps of our process flowchart)?

• Do we actually have two users: the backup singers and the ones managing the electronic signal for recording? We may want to evaluate the users differently.

• We may decide we want to do both a Critical to Quality analysis and a Value-Added flowchart analysis to design an e-maraca that bandmates will love to play.

All of these additional tools are outlined in Pierce the Design Fog. And all are important aspects of concept development.

What results from the work

E-Maracas: are they the future of band recording?

If this were a real use case, I would feel more confident jumping into this project after having done just the Concept Space Model and the Benefit-Impact Template with my team.

Not only did this exercise identify usable ideas within a realistic realm, but the activities also gave us focused questions for follow-up. It highlighted areas that we need to do more homework to better understand. We were able to do all of this really early with just an idea - not a prototype or engineering design.

Why Frameworks Matter: The Drumeo Lesson

Just like those nervous drummers facing an unfamiliar song, product teams often freeze when given too much freedom or too little structure. But give them the right framework and watch them thrive. Give them guardrails that focus creativity without dictating the solution.

The Concept Space Model and Benefit-Impact Template work because they solve the Goldilocks problem of ideation: they provide just enough structure to channel your team’s expertise toward customer value, without the fixedness that comes from premature design decisions.

Your cross-functional team already knows their parts. They’re world-class at what they do. They just need the right framework to play together, to create something that resonates with customers before a single component is specified or CAD file is opened.

That dusty drum kit in my house might not have inspired my kid yet, but watching those drummers work within constraints reminded me why great products don’t come from blank slates or rushed prototypes. They come from teams who know where to focus their creativity.

Start Here: Your First Concept Development Session

Ready to try this with your team? Here’s how to run your first framework-based concept development session:

1. Pick one active project in early stages (before detailed design, after business approval) Choose something where you have a product idea but haven’t locked into specific features yet. If you’re already in CAD, it’s not too late, just harder.

2. Gather your cross-functional team for 90 minutes (minimum: PM, engineering lead, marketing/sales rep) Block the time. Make it sacred. This isn’t a status meeting, it’s a creation session.

3. Start with the Concept Space Model Draw it on a shared whiteboard (physical or virtual). Spend 20 minutes on each focus area:

• Inputs: Where is the customer when they reach for your product? What are they assuming?

• Process: What are the 5-7 steps from start to finish in using your product?

• Outputs: When it works, what benefits do they experience? When it doesn’t, what symptoms occur?

4. Prioritize your top 3 benefits Vote with dots or discuss. Pick the ones that matter most to customer success. These become your deep-dive targets.

5. Explore one benefit with the Benefit-Impact Template Take your #1 benefit and spend 30 minutes filling out the template:

• Turn it into a Benefit-Impact Statement: “Customers can [have feature/characteristic] so they [experience this positive value]”

• List feature drivers (how the product can deliver this)

• List impact drivers (what maximizes the positive experience)

• Rate it: Must-have? One-dimensional? Attractive?

If this first session feels productive, schedule time to work through your other prioritized benefits and symptoms. You’re now doing real concept development by bridging the gap between “we should build this” and “here’s what engineering needs to design”.

Want Help Implementing This?

Reading about frameworks is one thing. Applying it to your actual product with your cross-functional team is another.

Pierce the Design Fog Workshop helps your team learn and apply these frameworks to YOUR real project—in just 2 days. You’ll leave with actionable design inputs and aligned priorities.

Learn more and schedule a discovery call: https://calendly.com/dianna-deeney/discovery-call

When we let our team brainstorm with no guardrails, we get generic, safe ideas that never excite anyone. When we wait until a prototype is already in hand, we fall into “fixedness,” where everyone can only tweak what’s already been decided. The magic happens between those extremes: after we have business approval and a clear market need, but before we start drawing CAD files. In that window (the Goldilocks zone of creativity), a well‑designed framework gives your team the right amount of constraint to spark real innovation.

I’ve boiled this into the Concept Space Model: map the inputs (where the customer is), the process (the steps they take), and the outputs (their experiences). With those guardrails, your cross‑functional crew can riff like those drummers…free to explore yet anchored to something meaningful.

Learn more in the latest podcast episode: https://deeneyenterprises.com/qdd/podcast/constraints-unlock-creativity-why-frameworks-beat-blank-slates-in-product-concept-design/

If you’ve ever felt your brainstorming sessions stall, or your team pushes back on “frameworks,” I’ve got a free worksheet that walks you through building your own Concept Space for the next project.

Become a subscriber and grab the swipe file: “Concept Space Handout”

Subscribe now

And if you want a deeper dive, let’s hop on a quick discovery call to see if the Pierce the Design Fog workshop can fast‑track your next product from idea to market‑ready. https://calendly.com/dianna-deeney/discovery-call

If January was about recognizing the Design Fog, February is about building your way out of it.

This month, we’re diving into frameworks. Not as rigid bureaucracy, but as creative scaffolding that helps teams move faster without losing alignment.

Most teams either over-process everything or reject all structure entirely. Both keep them stuck in the Design Fog.

From YouTube creativity experiments to real-world engineering collaboration tools, we’ll explore how the right structure unlocks better ideas, smoother teamwork, and those critical “soft skills” that make-or-break product development.

Plus, we’ve got a fun worked example: designing an electronic maraca that doesn’t exist yet.

Dianna

Quality during Design has been brought to you since 2021 from Deeney Enterprises and Dianna Deeney. This is the monthly digest sent on the first Friday of the month: gain insights, podcast highlights, and resources for engineering design professionals.

This month’s highlights at a glance:

• Introducing February’s Theme – Creativity within Constraints.

• January Recap: The Design Fog – Revisit last month's insights on recognizing when you're in the fog and the intentional activities that help you navigate through it.

• New Vault Resource: ADEPT Team Framework Infographic – Fresh download in the Swipe File Vault.

• Frameworks vs Process – Why the distinction matters

• New poll & last month’s poll results – What subscribers are planning (or not planning) for conferences this year, plus our approach to maximizing conference value.

Coming up in February

We explore why frameworks can be helpful: in ideation, co-working, and those necessary ‘soft skills’.

• What we can learn from Drumeo’s showcase of bounded creativity, perfectly cataloged in their YouTube series.

• How a framework can be a reminder of how to thrive in an engineering environment - I invite a special guest on the show to share.

• See a worked example of frameworks built for concept development of an electronic maraca! It doesn’t exist, yet. If it did, what about it would be important to develop? We figure it out and provide answers!

Free for all: Podcast episodes and blogs on deeneyenterprises.com.

• What you get as a subscriber:

  • Substack articles + Q&A participation

  • Free guides, templates, and vault downloads

  • Everything organized in the Substack app

Subscribe now

January recap

In January, we talked about what the ‘Design Fog’ is: that it’s inherent in all new development activities, not just created by teams. There are intentional and worthwhile activities to do. January’s content was about recognizing when we’re in the fog and knowing what to do to avoid its common pitfalls.

Free Content

🎙️ Podcast Episode: The Design Fog is Derailing Your Project Understand the symptoms of the design fog, including the silent assumptions problem and the premature precision trap. Listen → https://deeneyenterprises.com/qdd/podcast/the-design-fog-is-derailing-your-project/

🎙️ Podcast Episode: Cut Through the Design Fog Listen → The solution isn't more bureaucracy; it’s a shared, intentional structure. https://deeneyenterprises.com/qdd/podcast/cut-through-the-design-fog/

🔍 Strategic Insights: The Real Reason Your Product Launches Late (It’s Not What You Think) A late product launch is almost never caused by the reasons teams assume. It’s born much earlier, in the unseen “design fog” where misalignment, silent assumptions, and premature decisions quietly derail progress. This article shows how to cut through that fog with two practical, repeatable frameworks that help teams align fast, design smarter, and avoid months of wasted effort. This article expands upon the podcast episodes.

New in the Swipe File Vault: The ADEPT Team Framework Infographic

Framework vs. Process: Why the Distinction Actually Matters

I see these terms used interchangeably all the time in engineering organizations. I do it too.

In my Pierce the Design Fog’s glossary, I define the ADEPT Team Framework as “a process for team collaboration during concept development.” But throughout the book, I call it a framework. So, which is it?

The truth is: it’s both. And that’s actually the point.

Here’s what I mean

A process is a prescribed series of steps you follow to get from A to B. It’s sequential, often documented with specific methods, and usually has clear inputs and outputs. Think: your design review process with its required documentation and sign-offs, your change management process with specific approval gates.

A framework is a structure for thinking. It’s a set of principles, phases, or organizing concepts that guide your work without dictating exactly how you do it. Frameworks give you the “what to consider” without rigidly prescribing the “how.”

You already know frameworks, you just might not call them that

Stage-Gate is a framework. It gives you phases (stages) and decision points (gates), but doesn’t prescribe exactly how you do the work within each stage. That’s why different organizations implement Stage-Gate very differently. Some have 3 gates, some have 7; documentation requirements vary wildly. It’s a framework.

Agile is a framework. It gives you principles and ceremonies, but teams adapt how they execute. That’s why you have Scrum, Kanban, SAFe, and dozens of other implementations. They’re all working within the Agile framework but with different specifics.

But here’s the key: Within Stage-Gate, you might have very specific processes. ”Our Gate 3 review requires these 7 documents in this format, reviewed by these 5 people.” Within Agile, your team might have a specific process for daily standup. ”Every morning at 9am, these 3 questions, under 2 minutes each.”

Frameworks contain processes. Processes live inside frameworks. Just like ADEPT.

ADEPT lives in the middle ground

Align-Discover-Examine-Prioritize-Teamwork gives you a repeatable sequence, but within each phase, you have flexibility in how you execute:

• Align on a goal for your meeting—but you choose how

• Discover ideas—I promote brainwriting, but other discovery methods work too

• Examine those ideas for common understanding—format is flexible

• Prioritize through multi-voting or rating scales—you pick what fits

• Teamwork follow-up like notes and tracking—you decide your documentation approach

And here’s the framework flexibility in action

Sometimes ADEPT looks like A-DEP-DEP-T—you Align once, then cycle through Discover-Examine-Prioritize multiple times for items related to the same goal using the same priority criteria.

Sometimes it’s A-DDD-EPT—you need multiple discovery prompts before you’re ready to examine and prioritize.

If ADEPT were a rigid process, that adaptability wouldn’t be possible. But because it’s a framework, you can flex the sequence to match what your team actually needs in the moment.

Yet I also provide specific instructions

In the book, I walk through activities with clear steps: “follow these steps to use the ADEPT Team Framework for X exercise.” That sounds like a process. And it is, for that specific exercise. You can have processes within a framework.

Think of it this way: ADEPT is the framework, or the overall structure and principles. Within it, you might follow a specific process for ideation, or a specific process for multi-voting. Those are repeatable, prescribed steps. But the framework tells you when to use them and gives you permission to adapt when needed.

The visual frameworks you use within ADEPT are pure framework territory:

• The Concept Space Model helps you map possibilities

• The Benefit-Impact Template organizes customer evaluation

• The Symptom-Impact Template structures problem analysis

• Process Flowcharts capture use processes

These are thinking tools, not step-by-step instructions.

The mistake I see most often?

Teams either over-process everything (47 prescribed steps for ideation that kill innovation) or reject all structure because “processes are bureaucratic” (chaotic meetings where nothing sticks).

The Design Fog lifts when you find the middle ground: enough structure to create rhythm and shared expectations, enough flexibility to adapt to what each project actually needs.

So, is ADEPT a process or a framework?

It’s a framework that contains processes and adapts like a framework should. The distinction matters because teams misuse both when they don’t understand the difference.

Call it what you want but be intentional about how you use it. Make sure your team understands when to follow prescribed steps and when to adapt guiding principles. That clarity is what actually lifts the Design Fog.

Conversations

Fred and I cover a few more topics on the “Speaking of Reliability” Podcast.

SOR1145, Standard Reliability Methods: We discuss the immense value of creating a common touchstone for an org: a “cliff notes” version of a Design for Reliability manual. https://accendoreliability.com/podcast/sor/sor-1145-standard-reliability-methods/

SOR1146, Customer Expectations: We discuss the critical role of customer expectations in determining product reliability requirements. https://accendoreliability.com/podcast/sor/sor-1146-customer-expectations/

Tune in later in the month for some interesting conversations between me and Mojan on “Speaking of Reliability”.

​How to engage with me

Learn more about all services

New polls

Here’s what the 2025 data shows: Quality is losing strategic ground in most organizations. But I want to know YOUR reality.

These quick polls will help me understand the current state across different organizations. Results will be shared in an upcoming article about why some companies are thriving while others struggle.

Please choose, then consider forwarding to colleagues to add their choices!

Last month’s poll: What’s on your 2026 event list?

Last month I hosted a poll on the newsletter and social. I asked what conferences you were looking to go to this year.

It appears that most of you are not planning to go to any of those big conferences this year! I understand that many businesses are getting ‘tighter’ on their allowances for these activities, so it may be a lack of support rather than a disinterest.

Fred and I talked about the value of attending conferences. They’re more worthwhile if you go with a plan. Click the link to listen or read the show notes where we outline our recommended approach. It’s “Speaking of Reliability” podcast episode 1033. SOR1033 Conference Value

If you’re not sure if it’s worth it, or if you want to make a case to go - listen to this episode for ideas. If you’ve got some advice, please share it in the comments!

That’s why the ADEPT Team Framework is non-negotiable. It’s the “how to work together” layer that makes the “what to focus on” layer (the Concept Space Model) actually actionable.

Subscribe now

The middle steps of ADEPT are the secret sauce. Specifically, in the Discover phase, we use brain writing. This silent, timed idea generation is crucial. I’ve seen time and again how this simple shift—moving from verbal brainstorming to silent writing—completely changes the dynamic. It prevents groupthink, ensures that introverts and less dominant personalities are heard, and gives you a much richer set of ideas to work with in the subsequent Examine phase. Remember, Examine isn’t about judgment; it’s about establishing a common understanding so you can prioritize effectively. If you’re leading a session soon, commit to using brainwriting. Your team will thank you for the focus and the results.

Learn more about these models in the latest podcast episode: https://deeneyenterprises.com/qdd/podcast/cut-through-the-design-fog/

I have some exciting news to share: Pierce the Design Fog is now available as an audiobook!

This wasn’t a “hire a voice actor and call it done” situation. Nor was it “let’s use AI”. I spent weeks in my home studio recording and editing all 50,000+ words myself. Why? Because I wanted to make sure the listening experience actually worked for the material.

Here’s what makes this audiobook different:

The content doesn’t always translate well to audio, especially when you’re talking about diagrams and templates. So, I carefully adapted the narration to work without the visuals in front of you. You won’t get lost.

Every purchase includes a companion PDF with all the important visual frameworks and templates from the book. Think of it as your reference guide while you listen.

And honestly? The best experience is multi-modal: listen while following along with the physical copy. It reinforces the concepts in a way that either medium alone can’t quite match.

The audiobook is live on Spotify right now, with Audible and other platforms coming soon.

If you’ve already read Pierce the Design Fog (or you listen to the audiobook), I have one request: please leave a review on Goodreads or wherever you purchased it. Reviews are genuinely the best way to help other innovators and designers discover these tools.

Whether you’re on your morning commute, out for a run, or just prefer listening to reading - you can now learn concept development wherever you are.

Thanks for being here,

Dianna

P.S. Curious what recording more than 50,000 words in your home studio teaches you? Patience. And that coffee is a terrible way to hydrate!