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

Service Design Case Study: What Engineering Needs That a Feature List Can’t Give Them

Case Study Setup

What if you ran the same product concept through two different development methods and compared what engineering actually received at the end? That’s this case study.

Here’s the summary. We had the same product, but we did two trials. One method produced a solid feature list and a set up open questions for engineering to resolve. The other produced design inputs tied to specific users ranked by severity with failure modes identified before engineering ever opened a file. This table is the punchline of the case study and the rest of this video is the proof.

Suncor 360 Scenario

The product is actually a service product called Suncor 360. I created a product concept using fictional companies and products. This is a fictional use case of a residential solar installer.

They have about 31,000 customers across 14 [00:01:00] states, and their current Better Business Bureau rating is a B+. They’ve decided that they need to hit a strategic goal of an BBB rating of A+ by the end of the next year. So that’s about a year and a half they have to do this. Suncor 360 is actually a post installation service redesign.

They want to target three service tiers, but the core challenge here is that they’re currently averaging 5.3 days to respond to a service request, and the premium tier promises 24 hours. That gap is not a technology problem, it’s an operations problem. It involves multiple user types, homeowners, field technicians, prospects, at-risk customers with competing priorities and real constraints.

That’s why it’s a good test case. It’s the kind of product where what you hand to engineering [00:02:00] actually matters.

Two Trial Methods

So we ran two full concept development trials. We used the same product brief, the same green light packet, which is all the information that the company used to determine if this project was a go, if it’s something they wanted to develop and pursue.

We also used the same cross-functional team: engineering, manufacturing, quality marketing, sales, and customer success. This team I developed as experts in their field and represented by AI agents. They communicated in a Slack type interface and worked through different methods.

Trial one used a traditional method. There were five structured rounds. There was kickoff users and use environment concept, exploration, risk and feasibility. And finally, a summary.

Trial two used the methods and frameworks that are outlined in Pierce the Design Fog, [00:03:00] including the ADEPT framework. Trial two used six ADEPT rounds. Each round runs the full aligned, discover, examine, prioritize, teamwork cycle, but apply to a specific lens: the concept space model for the use process, benefits and symptoms. Then further exploration of benefits with a benefit impact, symptom impact for symptoms, and a value added analysis to get more detailed information from the use process.

Since I used AI to run both complete trials, it made it possible to compare the outputs directly. The AI is mechanism made this fast. The story is what came out.

Traditional Output Review

Let’s start with the traditional method. There were five structured rounds and the team did real work. I want to be fair about that before I show you what it hands to engineering.

[00:04:00] Five engineering design inputs came out of five sessions. There was diagnostic fidelity thresholds, noise reduction algorithms, ensuring that ticket validity was high before a technician was even dispatched. BOM to SKU Precision diagnostic reports hard linked to the bill of materials. Every ticket arrives with a confirmed SKU list. A safety critical anchor, hard-coded logic protocols for high voltage and structural failure modes, determining earlier who needs to be sent and what’s needed to solve the problem. System health Scoring, a real-time metric that distinguishes environmental soiling from actual hardware degradation. And onsite verification.

Engineering also received four open action items, not answers, but questions. Is the 24 hour SLA achievable with current headcount? How do you restock parts depots for the top 20 failure modes in 48 hours? How do you sell prevention to a customer who feels fine right now? And there are 27 open Better Business Bureau complaints that have to be resolved before launch.

Now here’s what’s worth noticing about the design inputs themselves: they’re feature described: “diagnostic fidelity thresholds”, “BOM- to-SKU precision”. Those are system capability names, not user needs or benefits or symptoms. There’s no traceability to a specific user or a specific step in how the service actually gets delivered.

There’s no prioritization. Which of these five matters most is left for engineering to figure out, and there’s no analysis of what goes wrong if an input isn’t met. Engineering can build from [00:06:00] this, but they’re curing ambiguity that wasn’t resolved in concept development.

ADEPT User-First Results

Now the same product, same team, using the Pierce the Design Fog and ADEPT frameworks. Six rounds of analysis each running the full align, discover, examine, prioritize, teamwork cycle, applied to a specific lens. This method works from the user’s experience forward, not from the feature list backward. It takes more rigor, but here’s what came out of it.

The team mapped the full nine step service resolution use process from anomaly detection to closed loop confirmation, and then analyzed each step for what adds customer value, what’s business required, and what adds nothing.

Two highest leverage steps emerged the remote diagnostic gate -which is the automated analysis that determines whether a truck roll is actually needed- and the [00:07:00] inventory handshake- which verifies parts are in stock before a technician is dispatched. One insight the traditional method never surfaced: the 24 hour SLA clock starts at customer notification, not at anomaly detection. That gap in the process is a design input. Engineering needs to know it exists before they build.

The team applied benefit- impact and Kano analysis. They mapped each benefit to what the user actually experiences then rated it. What’s basic are table stakes. If you don’t meet this or you fail to meet this, it destroys trust and ruins reputation. For performance measures: they’re really a linear return. The better you do it, the happier customers are. And attractive measures are the differentiator. They are what separate [00:08:00] you from your competitors and the other people providing similar services.

The critical finding is that the 24 hour SLA is basic. Engineering needs to protect it, but it’s not a marketing hook. Meaning it doesn’t win customers, it just prevents losing them.

What is a differentiator? Proof of prevention. Showing the homeowner what didn’t break, the anomaly that was caught before they noticed anything wrong. That’s what distinguishes Luminos from other competitors in the field, and that design insight came from working forward from the user’s experience, not from the feature list.

They also ran symptom impact analysis, essentially FMEA thinking at the concept stage. For each potential failure, the team identified what goes wrong, rated its severity on a one to six scale, and [00:09:00] derived the specific design input required to prevent it. Two Severity five failures: ” silent failure” is a false negative at the diagnostic gate where the customer’s system is underperforming but nobody knows. And the other one is radio silence: the human fallback is delayed during the 24 hour window and the customer hears nothing. There are two severity four failures. A “first- visit failure”, where stale inventory data sends a technician without the right parts and a broken warranty promise In rural zones where the SLA extension was never disclosed.

Each one has a specific design input. Manual override protocols, heartbeat monitor triggers, real-time inventory API, geographic zone logic. Engineering isn’t guessing what matters. They’re building to it.

Side-by-Side Takeaways

Let’s put them side by side across the five dimensions that matter.

Design inputs with our traditional method: we got five items that are feature described. Using Pierce the Design Fog, we have a use process map, Kano rated benefits, and a severity ranked symptom analysis with a required design input for each failure mode. Not a longer list, a richer one with structure.

Traceability: our traditional method had inputs named as system capabilities. With Pierce the Design Fog, every input was traced to a specific user, a specific step in the use process, and a specific failure consequence.

Prioritization: there were five inputs with an equal weight. With Pierce the Design Fog methods, the Kano category plus the symptom severity tells engineering what to protect first. Severity five items are protected before severity four. Basic requirements are kept basic, not oversold as differentiators.

Failure mode visibility: using traditional concept development, we got a project level risk register, four risks, and high level. With Pierce the Design Fog, we have design input level symptom analysis. The failure mode style thinking happened in concept development, not in engineering.

Finally open items: with our traditional methods, we had four broad action items unassigned. With Pierce the Design Fog, we have three specific questions each with a named functional owner. Engineering owns the inventory staleness tolerance definition. Operations owns the SLA pause rules for rural zones. UX owns the resolution artifact architecture.

Here’s the clearest way to show what changed. Both methods produce the same answer: a realtime inventory API. But look at what engineering receives. On the left, a feature name, realtime inventory API, that’s it. On the right, the same feature with context. If the inventory handshake provides stale data, the technician arrives without parts. First visit failure: severity four. Design input: real-time inventory API with staleness tolerance defined.

Same answer. One has context, one doesn’t. Engineering building to the right hand version knows what they’re protecting against, what failure looks like, and what ‘done’ means. Engineering building to the left has to figure all of that out on their own time.

Close

Before we close, notice what the comparison example [00:13:00] didn’t show. The inventory API was one case where both methods landed on a similar answer expressed at two different levels of specificity.

Three of Pierce the Design Fog’s design inputs don’t appear anywhere in what the traditional method handed to engineering. Those failure modes were never surfaced. Not described less clearly- not presented at all. Engineering would’ve found them eventually in engineering where the cost of discovery is much higher.

The fog didn’t disappear, it got cleared in concept development where it’s cheap instead of in engineering where it’s expensive. Or instead of later in the product development process where it’s harder to make changes. It’s defined early as an input when those engineering decisions are being made.

If your team’s concept development process is handing engineering a feature list and a set of open questions, [00:14:00] this is what changes when you use a structured method that works from the user’s experience forward.

Suncor 360 is just one case. I’m running the same experiment on other product concepts, and I’ll link to those in the description as they publish.

The method is in Pierce the Design Fog. If you wanna put it to work with your team, workshop and advisory information is in the description.

Thanks for joining me on this case study. This has been a production of Deeney Enterprises.