Your Concept Development Isn’t Done Just Because It Produced Answers

Two design inputs say the same thing. One is a feature name. The other tells engineering who fails, how, how badly, and what "done" means.
What happened in concept development that produced one versus the other?

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:

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.
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.
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.