Case Study: What Engineering Really Gets from Concept Development (Equipment Design)

Two Methods Showdown 

 Same product, same team, two concept methods, totally different inputs for engineering. One gave engineering a list, the other gave engineering something they could actually build from. The traditional method produced about 15 directional items, risks, open questions, and a concept direction. No priority, and three critical items were still unresolved when they got handed to engineering. 

Structured concept development methods used in the book Pierce the Design Fog, produced severity-rated failure modes, hard design targets, and a mapped use process that showed exactly what had to work in the field and exactly where it was likely to break. And if you lead engineering or quality, you already know why that matters. 

Ambiguous inputs don’t just slow teams down, they create expensive mistakes. [00:01:00] So let me show you exactly what each method produced. 

Harvester L1 Case Study 

First, let’s set up our case study. The product is Harvester L1, an autonomous selective harvest retrofit kit for leafy greens. In other words, it’s something that can harvest lettuce from the fields. It installs onto growers’ existing harvest rigs. The installation target is that it can be installed by two technicians over no more than fourteen hours, and no chassis modification. 

The product and company are fictional, although it’s a case study based on realistic demands. The market problem it’s solving is a labor pinch. Labor is needed to harvest, but the pool of available agricultural labor has declined about twenty-eight percent over the last eight years. Full autonomous harvesters exist, but they run [00:02:00] six hundred and fifty thousand to one point two million dollars. 

They’re out of reach for most commercial growers. Harvester L1 fills that unoccupied middle tier at sixty-eight to ninety-two thousand dollars. There are two users at the center of the story. The VP of Operations signs the check. His key process indicators are cost per acre, contract fulfillment, and earnings margin. 

His deal killers are using an unproven technology with unclear liability and a long retrofit downtime The other user is the harvest crew foreman. He manages 20 to 35 workers. His day starts at 4:30 in the morning. He’s working in dust in 105-degree heat, often with no cellular signal. If the machine stops and he can’t fix it in five minutes, his whole crew is just standing there.[00:03:00]  

Why this is a useful test case? The ROI promise is specific and fragile. A two-point-nine-month customer payback with a five-year net value of $18.4 million. None of that holds if engineering can’t hit the 97% harvest accuracy and validate a one-to-two operator-to-rig ratio. Both were unvalidated at the concept stage. 

Ambiguous design inputs don’t just produce a worse product here, they break the business case. 

Experiment Setup and Hypothesis 

Now for our experiment, we conducted two complete concept development trials using the same product brief. The product brief is really a green light packet that reviewed all the information we just covered and led the business to decide we want to develop this product. 

So they gave it a green light for [00:04:00] development. 

This same product brief was used in both trials using the same AI-powered cross-functional team. This is a team of AI agents trained in a particular aspect of product development: engineering, manufacturing, quality, marketing, sales, and customer success. They’re all starting from their respective points of knowledge, but then they’re also given the green light packet. 

They all receive the same information at the beginning of our trials. Trial one was the traditional method. We did five structured rounds: a kickoff, users and use environment, concept exploration, risk and feasibility, and summary Then we cleared all the information and ran trial two, the techniques in Pierce the Design Fog using the ADEPT team framework. [00:05:00] We conducted six sessions in a two-tier cascade. Tier one covered three concept space model sessions to surface and prioritize the top benefits, the potential symptoms, and use process steps. Tier two, we had three impact sessions going deep on each. 

Each two-tier session took its tier one output as input and ran the full ADEPT cycle: align, discover, examine, prioritize, and teamwork. The AI made it possible to run both complete trials and compare the outputs directly. That’s the setup. What matters is what came out of it. Our hypothesis is that Pierce the Design Fog techniques would produce more work. 

That’s expected. But the question was whether it would produce better inputs, more specific, more traceable, [00:06:00] more actionable. And the harder question, would it surface things engineering couldn’t generate on their own? 

Traditional Outputs and Gaps 

So let’s review what came out of the traditional concept development sessions. 

The team reviewed the product brief, flagged concerns by discipline, and developed a concept direction, a flexure-based sensor mounting system. It would also have a multi-toggle HMI, human machine interface, and a hardware-enforced mechanical interlock. 

Let’s talk about what the engineering team was handed. These aren’t just suggestions, they are high-stake constraints. First, reliability is non-negotiable. If a subscription lapses, the machine cannot stop harvesting in the field. We need an offline fail-safe that keeps working. 

Second, the hardware design is still risky We’re using a flexure mounting concept, but we [00:07:00] haven’t validated it yet. We need to prove it can handle material fatigue, vibration alignment, and thermal expansion. 

Third, supply chain is a bottleneck. The NIR sensors have a lead time of twenty-two to twenty-eight weeks. We need to qualify a second supplier before we freeze the design or the whole program stalls. 

Finally, manufacturing and interface conflicts. The triple rig harness concept is slowing down production. Standardizing it helps manufacturing, but it conflicts with our safety latency targets. We also need to manage thermal throttling under vibration and ensure the user interface works in any language. 

Now, here’s the bigger problem. What was handed to engineering was incomplete. We have undefined field stressors. The team said they couldn’t validate the design without specific environmental [00:08:00] variables, but nobody defined those variables. We have an active calibration protocol that was requested but never scoped. 

And we have the foreman’s self-recovery window. This is listed as a mandatory requirement for our ROI, but nobody has quantified how to actually achieve it. In total, there are fifteen open items. 

They are vague, they are thematic, and most critically, there are no owners. We need to assign accountability immediately. The honest read, this is real engineering and manufacturing domain work. 

Component supply chain, flexure mechanics, thermal throttling. These are consequential concerns, but the outputs are still domain-facing. They reflect what engineering already knows to worry about. There’s no mapped use [00:09:00] process, no severity ratings, and the user-grounded side of the design problem, the foreman’s operating environment and his crew’s actual failure modes is still largely unresolved. 

Engineering inherits that ambiguity once we move from concept development to further downstream development processes. 

Structured Outputs That Engineers Can Build 

Now let’s look at what happened in structured concept development. The methods in Pierce the Design Fog produced benefits, and I asked them to prioritize three, each rated and tied to a specific design input. 

A continuous harvest throughput: we need the machine to keep working even when conditions get tough. More reliability equals happier customers, but there’s a hard limit. The mechanical reset must happen in 90 seconds. If it takes longer, we’ll need extra operators on the line, and that kills our ROI [00:10:00] model. 

Zero contamination is a non-negotiable. We need a physical hardware barrier. Software alone won’t cut it. Food safety isn’t a competitive advantage, it’s the price of entry. If we fail on this requirement, the whole program ends, not just the product. 

And rapid retrofit installation. We need plug-and-play installation. The interface must connect with any hydraulic system. Downtime is the VP of Operations’ deal killer. By standardizing the interface, we protect our parts costs and keep the machines running. 

Our structured concept development produced symptoms tied to failure modes. I asked the AI agents to prioritize the top three and then further explore them with risk priority ratings and design actions assigned. 

[00:11:00] When fault messages are confusing, operators start bypassing safety interlocks just to keep throughput up. That’s a severity six safety issue, and it had the highest risk priority score in the trial. So the design input is a language-agnostic signal hierarchy that makes it obvious what’s fixable and what’s critical, plus a tool-required bypass, so overriding it isn’t easy. 

If a network or subscription issue can lock the machine in the middle of a field, that’s a major reliability problem. Severity five. The fix is a hardwired bailout mode that’s physically separated from subscription logic. That drops the symptom from severity six to severity four. A network outage cannot be what stops harvest. 

If the system doesn’t account for operator fatigue, unsafe bypass attempts go up. Severity four. The design input [00:12:00] is a passive spring-loaded bypass with a defined torque threshold, a hard mechanical stop, and haptic feedback that makes a jam feel different from a cognitive alert. That protection comes from the physics of the mechanism, not just the software. 

The team also mapped the foreman’s end-to-end process. I asked them to map the use process at a high level within five to ten use steps. They identified seven named nodes from HMI readiness through final cut confirmation. Each classified as functional priority, must work, or interface requirement sensitive to human and environmental inputs, and likely to fail under field conditions if not explicitly designed for. 

Two nodes carry both classifications. Verify cut authorization and actuation authorization. These must work and [00:13:00] must work under variable conditions. The mechanical geometry is the primary safety gate, not the HMI. The interface requirement nodes tell engineering exactly what the field environment will break if it isn’t designed for explicitly. 

A blind cut override. This haptic alert has to be strong and distinct enough that users can tell it apart from normal machine vibration. And before we can validate that, we first need to know whether the haptic driver can reliably produce that signal without overheating. 

The crew has to work in a coordinated way in a noisy field and across multiple languages. And because of that, crew confirmation can’t rely on the screen alone. The alert system still has to work if the display fails.  

Multi-rig supervisory handoff. A way to compensate for cognitive load is required. [00:14:00] One foreman can only manage two rigs if the system makes those attention shifts easy and safe. 

And bilingual confirmation, so that we have mandatory acknowledgement before anyone does a safety-critical override. 

Open items from our structured concept development. There are three specific questions with owners. What haptic frequency is distinct from general machine vibration for the blind cut override? 

What is the maximum latency between system stop and mechanical fail-safe activation? Does the bilingual confirmation requirement introduce unacceptable cycle time delay at peak harvest pace? These are specific, owned, grounded in the foreman’s actual process. 

Side-by-Side Takeaways and Wrap 

Now let me put them side by side, including what each method found that the other didn’t. [00:15:00] With our traditional concept development methods, we got roughly 15 directional items. They’re thematic. They each carry the same weight as far as importance. Inputs are described as system features or engineering risks. There’s no use process map. Field stressors are undefined, and we have 15 items that are unassigned. 

With our structured concept development using Pierce the Design Fog methodologies, we have Kano-rated benefits, a severity-scored failure modes with risk priority calculations. And a seven-node use process with every node classified and design inputs assigned per node, one hundred percent prioritized. 

The clearest way to see the difference is this. Both methods surface the language-agnostic HMI requirement. From our traditional concept [00:16:00] development, it was language-agnostic HMI required, a requirement. From our structured concept development, unintelligible fault messaging causes the foreman’s crew to bypass safety interlocks to maintain throughput. Severity six, unsafe. A design input is tiered signal hierarchy that distinguishes fixable from critical at the interface level. A tool-required bypass procedure that raises the friction cost of overriding, and a risk priority score calculated with an owner assigned. 

Same underlying concern. One is a requirement. One has a user, a failure consequence, a severity score, and a design action. 

And here’s the honest comparison. We have to admit that the traditional method found things that our structured method didn’t.[00:17:00]  

Specifically, the traditional approach uniquely serviced the technical risks. They flagged the NIR sensor lead times, which is a potential program showstopper. They identified the flexure mounting mechanics as a specific concept direction that needs rigorous validation. They found the triple rig harness as a manufacturing bottleneck. They noted the sensor fusion thermal throttling, and they analyzed the solenoid redundancy trade-off, weighing the cost of extra hardware against recall liability. 

These are real, they are consequential, and engineering teams absolutely need them But here’s the counterpart. Engineering teams are expected to generate these concerns. When they open their design files, supply chain issues and mechanical tolerances are squarely in their domain. That [00:18:00] is their job. 

What engineering is unlikely to generate on their own: they won’t naturally define the 90-second reset target tied to our one-to-two operator ratio. They won’t design the tiered signal hierarchy that prevents the foreman from accidentally bypassing safety interlocks. They may not consider the subscription independence circuit isolation that ensures a network outage doesn’t become a harvest stand down. And they won’t specify the interface requirements based on what the foreman’s crew actually does at 4:30 in the morning, including the capability and geometry standards required for that workflow. 

So here’s the bottom line. The traditional method’s unique items reflect what engineering already knows to worry about. But the Pierce the Design Fog method’s unique items reflect what the field environment and the foreman’s [00:19:00] actual process demand. These are the things engineering is much less likely to generate without a structured, user-grounded concept process. 

In agriculture, the cost of ambiguity isn’t a delayed feature. It’s a machine that doesn’t earn its keep in the field. A seventy-eight-thousand-dollar kit with a one-to-two operator ratio promise only holds if engineering builds to inputs that were grounded in what the foreman actually does at 4:30 in the morning in a dust cloud. 

Our structured concept development didn’t replace engineering work. It made sure engineering started with inputs grounded in the field, not just in the conference room. 

Harvester L1 is the third case in this series. The products are different on purpose. A solar service platform, a medical device, and an agricultural robotics kit. Different industries, different [00:20:00] value domains. Same hypothesis. The method holds. 

You’ll find the method in Pierce the Design Fog, and there is workshop and advisory information in the description. This has been a production of Deeney Enterprises.