The Knowledge Your Team Has That Nobody's Using

Late-breaking insights in product development aren’t caused by negligence but by a lack of structure that pulls existing team knowledge into concept discussions early, when changes are cheaper. 

Dianna describes an experiment running three product briefs (solar post-installation support, a portable oxygen concentrator, and a field lettuce harvester module) through traditional versus structured concept development. 

Both produced credible outputs, but the structured method added context: linking each design input to a specific use-process failure or targeted benefit, its severity or importance, and a clear acceptance condition. Engineering inherits clarity rather than having to guess intent. 

Dianna proposes a three-question filter (who fails, how severe/important, what “done” means) and challenges listeners to apply it to one current design input. 

Visit the YouTube series showing side-by-side results: https://www.youtube.com/playlist?list=PLTtGpfRyyNcZ9qMVL2HmWA7heE3Idyfbt

Transcript

The Pattern

Dianna 0:01

You've been to this kind of meeting before. I'm sure you have. Engineering is three months into detailed design. Someone from quality or manufacturing finally sees the concept and says, "We tried something like this two years ago. Here's what failed." Everyone in the room knows that information would have changed the direction, but it showed up too late. That's not a people problem. Nobody was hiding it. Nobody was negligent. The knowledge existed. It just didn't have a path into the conversation when the conversation was happening. This isn't about knowledge management systems or databases. It's about whether the knowledge your team already has is structured to show up at the right moment during concept development when it's cheaper to act on. It's easier to change paper than to retool something. I've been running an experiment that made this visible in a way I didn't quite expect. I wanna tell you more about it after this brief introduction.

What I Saw in Three Case Studies

Dianna 1:57

I ran three product concepts through two different concept development approaches. Now, I used AI agents, and they used a Slack-like environment to communicate. So with each experiment, I used the same team composition. They each have the same product brief, which is-- I call it a green light packet. It's all the information a business would use to decide whether they wanted to pursue a project or not. But I ran this same team and same product brief through different structures for concept development. I intentionally chose products that introduced a lot of variety. One was a service design. A solar energy company was redesigning their post-installation support. The other was a physical medical device, a portable oxygen concentrator. The third was a field lettuce harvester module that would fit on farm equipment. In all cases, the traditional approach produced legitimate work, real design inputs, real risk flags. If you looked at the output, you'd say, "We're ready for engineering." But when I ran the same brief through a structured method, one that forced the team to map the use process, identify who fails and how, and what targeted benefits would look like, doing that before generating design inputs, the outputs that I got were different in a specific way. The difference wasn't more answers. It was answers with more context. The traditional approach produced a feature. For example, in our solar panel installation, the feature was real-time inventory API. The structured approach produced, if inventory data is stale, the technician arrives without parts. That's a first visit failure, which we're calling a severity four on our one to six scale. And our design input is real-time inventory API with a staleness tolerance defined. Same answer, real-time inventory API. One tells engineering what to build. The other tells engineering what to build, who fails if it's wrong, how badly, and what done means. The portable oxygen concentrator showed the same pattern. A loudness specification was given, a certain decibel at a defined range. Whereas a structured method looked further. Margaret, our user, decides it's too noisy and embarrassing, leaves it at home or hides it under the table at the restaurant. So now she's not using it. We have a device the patient needs but chooses not to use. That's a risk. The team also thinks this is a differentiator for their product against others in the market. If they get this right, it could be a huge win for both Margaret and the business. With the field harvester, the traditional method caught the mechanical stuff, harnesses and mounting. But the structured method caught the operational stuff, the things engineering is least likely to think of while working in a design vacuum. So what was different? It wasn't the team's knowledge. It was identical. It was whether the process structured that knowledge before handing it to engineering or left engineering to structure it themselves.

Why Teams Stop Too Soon

Dianna 5:40

There's a natural pressure in concept development to declare done as soon as you have something that looks like an answer. Feature lists feel like progress. A risk register feels like diligence. Open questions feel like someone else's problem to resolve later. And honestly, that output is progress. The traditional approach didn't fail in any of the case studies. It produced work that most organizations would accept and move forward with. The problem is that ready enough is where the expensive ambiguity hides. When a design input says real-time inventory API with no context about who fails or how badly, engineering has to reverse engineer your intent. They have to guess what done looks like, and they'll guess based on whatever information they have, Which may not include the failure scenario you were thinking of when you wrote it down. This is how teams end up building the right feature for the wrong reason, and then discovering during verification that it doesn't actually prevent the failure it was supposed to prevent. The fog doesn't announce itself. It feels like forward motion. So what does done actually look like? Before

The Three-Question Test

Dianna 7:09

your concept development team hands anything to engineering, even when engineering is involved in concept development, which they should be, you can apply this filter to every design input. Who fails or who loses if this is wrong? Not the system or the customer, a specific user in a specific step of the use process. How severe is that failure? Or how important is this potential benefit? Is it an inconvenience, a service breakdown, a safety event? Is it bare minimum table stakes or something that is very attractive? If you can't rank it, you haven't finished. What does done look like for engineering? Not build it. What's the acceptance condition? What would you test to confirm this input was implemented correctly? If you can answer all three for every design input, your concept development did its job. Engineering inherits clarity, not ambiguity. If you can't answer all three, and be honest, most of us can't for the majority of our specs, you aren't done. You've just moved the fog downstream where the price tag is higher. I'm not talking about adding more process. It's about finishing the process you're already doing.

The Broader Point

Dianna 8:39

This applies beyond concept development. Think about the knowledge your team has right now about failure modes, targeted benefits, customer workarounds, about why the last design decision was made the way it was. Where does that knowledge live? In someone's head? In a lessons learned report that nobody opens? In tribal lore that gets passed along informally? If the right person happens to be in the room? The structure question isn't, do we have a knowledge management system? It's, does our development process have a moment, a specific named moment, where that knowledge gets pulled into the conversation? If it doesn't, then your team's knowledge is an asset that's not working, and no tool fixes that until you build the structure for it to show up.

Close

Dianna 9:37

Here is what I challenge you to do this week. Pick one design input from your current project, just one, and ask those three questions. Who fails if it's wrong or who misses out if it's missing? How does it stack up against the other priorities of our project, the other features and characteristics? And what does done look like? If you can't answer them, that's your fog, and now you can see it. Throughout the month of May, I'm publishing on YouTube a breakdown video of this experiment that I'm running, comparing traditional methods versus structured methods. I'm covering the service design, the medical device, the field lettuce harvester, and I'm in the middle of creating a fourth one about a consumer product. I'll show you the side-by-side output so you can see exactly what structured concept development produces versus what traditional concept development produces. I'll provide links in the show notes. This has been a production of Deeney Enterprises. Thanks for listening.