The Difference Between a Feature and a Design Input
Pierce the Design Fog Case Studies | No. 1
Here is something that happens at the end of almost every concept development process: engineering gets a list.
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.