The Knowledge Your Team Has That Nobody’s Using

You’ve been in this meeting before. Engineering is three months into detailed design when someone from manufacturing finally sees the concept and says, “We tried this two years ago. Here’s why it failed.”

The knowledge existed, but it didn’t have a path into the conversation when it actually mattered. We often treat this as a “people problem” or a failure of a database, but it can actually be a structural problem: when you engage for this information in product development. After all, it’s significantly cheaper to change a piece of paper during concept development than it is to retool a production line later.

In this episode, I share the results of an experiment I ran using AI agents to test two different development approaches across three distinct products: a solar service design, a medical device, and a field harvester. The results were clear: the traditional approach produces “answers,” but the structured concept development approach produces clarity.

Key Takeaways

The experiment compared a traditional “feature-first” approach against a structured concept development method that helped a team to map the use process, identify failure points, and target benefits before generating concept designs.

1. Features vs. Context

The traditional approach often stops at the “what.” For example, in the solar installation case study, the output was “real-time inventory API.” While accurate, it lacks intent. The structured approach identified that if data is stale, a technician arrives without parts—a specific severity-four failure. By defining the “who” and the “why,” engineering doesn’t have to guess what “done” looks like.

2. Designing for the Human Element

With the portable oxygen concentrator, the traditional method produced a decibel specification. The structured concept development method, however, looked at the user, Margaret. It identified that if the device is too loud, she feels embarrassed and leaves it at home. This transformed a simple noise spec into a critical risk factor and a potential market differentiator.

3. Catching the “Operational Fog”

In the field lettuce harvester study, the traditional method was excellent at catching mechanical requirements like harnesses and mounting. But it missed the operational realities of the field—the “design vacuum” issues. Structured development pulls tribal knowledge out of people’s heads and into the requirements before the “fog” moves downstream.

4. The Tree-Question Filter for “Done”

Before you hand any design input to engineering, apply this filter. if you can’t answer these three questions, you aren’t finished; you’ve just moved the ambiguity to a more expensive phase of the project:

Who fails or loses if this is wrong? Identify a specific user in a specific step.
How severe is the failure (or how big is the benefit)? Rank it. If you can’t rank it, you don’t understand the priority.
What does “done” look like? Define the acceptance condition that can actually be tested.

This Week’s Challenge

Pick one design input from your current project and ask those three questions. If you can’t answer them, you’ve found your fog. Now you can see it, and more importantly, you can fix it.

Watch the Experiment Fold Out Throughout May, I am publishing a video series on YouTube breaking down these case studies (Service Design, Medical Device, and Field Harvester) with side-by-side output comparisons.

Other Quality during Design podcast episodes you might like:

The Design Fog is Derailing Your Project

Constraints Unlock Creativity: Why Frameworks Beat Blank Slates in Product Concept Design