"Doing the Right Things" vs. "Doing Things Right" 7

In 2014, we received a development assignment from our German headquarters: design an outdoor dual cable. On the surface it looked unremarkable, and its structure was not complicated. But we had no prior development experience with this type of product, and the customer's requirements ran on for several pages — so from day one the project was shrouded in uncertainty.

This was a textbook "forward development" project. Forward development means the company had never made this kind of product before: there was no ready-made experience or existing drawings to fall back on, and everything had to be built from zero. At the same time, it can be viewed as a miniature forward-development case, because this small piece of cable carried some very special technical requirements.

Faced with this challenge, we did not rush to the drawing board. We strictly followed the company's product development process and put the emphasis on requirements management, which we broke down into four progressive stages: first, deep collection and organization of the customer's original requirements, distilling core value from a noisy surface; second, mining and consolidating internal requirements, mobilizing the company's accumulated experience assets; third, a second round of requirements consolidation and architecture building during concept design; and finally, final calibration and implementation of detailed requirements during the 3D and 2D design stages.

When we reviewed the project after completion, one set of numbers stood out: requirements explicitly raised by the customer accounted for only 5% of the total requirement set. Requirements we proactively supplemented, based on our deep experience with other product designs, accounted for 46%. Requirements collected broadly through concurrent engineering — from manufacturing, quality, purchasing and other departments — accounted for 39%. On top of that, we dynamically added another 10% during the subsequent concept and product design stages.

It was this relentless pursuit of the complete requirement set that laid a solid foundation for everything that followed. With such a complete battle map in hand, the rest of the development went smoothly and swiftly. Not a single major design change occurred throughout the project — one design pass, one round of testing, one success. In the end, we formally delivered the engineering samples ahead of the customer's required deadline.

Looking back at the whole project, the core success factor was this: deeply understand the product and the environment it operates in, then collect and accurately define the complete set of product requirements up front. By front-loading the work this way, we achieved first-time-right development and completely avoided the heavy cost of late-stage design changes caused by vague requirements.

This was a double victory for product quality and development speed — and a vivid illustration of the management philosophy of "doing the right things" versus "doing things right." In this case, doing the right things did not mean blindly responding to the customer's explicit 5%; it meant seeing the essence behind the phenomena and proactively constructing the hidden 95% — the full requirement set — to ensure that what we developed was a genuinely "right product": one that truly matched the application, was manufacturable, and delivered high quality. Doing things right, in turn, was reflected in the rigorous execution of the four-stage requirements management process, using concurrent engineering and professional experience to translate those requirements into design drawings efficiently and precisely.

In the end, this small success story not only validated the wisdom of front-loaded development, it also earned us deeper trust from German headquarters — and a steady stream of new product development business ever since. The lesson it teaches: only by thinking through "the right things" early can you execute "the things" correctly — and beautifully — later on.

The Four-Stage Requirements Funnel in Practice

The four stages are not four meetings; they are four filters, each with a different owner and a different output. Treating them as a funnel makes the 5/46/39/10 split reproducible rather than accidental.

A requirement that cannot name its source, its owner and its verification method is not yet a requirement — it is an opinion. Stage 4 is where that test is applied line by line.

Worked Example: From "Outdoor" to a Measurable Requirement

Consider how one vague customer phrase — "suitable for outdoor use" — becomes a set of verifiable requirements. The customer text gives no numbers; the numbers come from stages 2 and 3.

• Customer statement (stage 1): "The cable must be installed outdoors and remain functional." One line, no values.
• Application questions (stage 1): Where is it mounted — facade, pole, buried duct? What is the expected service life? Is it flexed after installation or fixed?
• Internal mining (stage 2): Prior outdoor products in our portfolio failed in the field mainly through UV embrittlement of the jacket and water ingress at the connector interface. Lessons-learned records point to a UV exposure test and an IP rating as mandatory supplements.
• Concept consolidation (stage 3): The team fixes the architecture — UV-stabilised jacket compound, sealed transition to the connector — and assigns a target to each: a defined UV ageing hours target and a defined ingress protection level, both agreed with the customer in writing.
• Detail calibration (stage 4): Each target becomes a drawing callout and a test in the design verification plan: jacket material specification on the 2D drawing, a UV ageing test, and an ingress test on three samples.

None of those numbers came from the customer's pages. All of them are defensible because each carries a source, an owner and a test. That is exactly what the 46% and 39% shares represent in daily work.

Step-by-Step Checklist for the Requirements Phase

Use this list as a gate review before concept design is allowed to start.

1. Transcribe every customer sentence into a numbered requirement; keep the original wording alongside your interpretation.
2. Mark each line as explicit, derived or assumed — assumptions are the highest-risk category.
3. Walk the application with the customer: mounting, environment, service life, mating parts, installation tools.
4. Search the lessons-learned library and past 8D reports for similar products; add every relevant failure mode as a supplemented requirement.
5. Run a cross-functional review with manufacturing, quality and purchasing; record who raised what.
6. Convert every requirement into a measurable acceptance criterion with a verification method (test, analysis, inspection, demonstration).
7. Flag any requirement that cannot be verified — either define a test or escalate it as an open risk.
8. Baseline the set, version it, and freeze it before 3D design; later changes go through change control.
9. Trace each requirement forward to a drawing feature and a verification record.

Common Failure Modes and How to Detect Them

• Silent assumptions. The team believes a requirement is obvious and never writes it down. Detect it by asking each engineer to state, in one sentence, what the product must do — mismatched answers reveal the gap.
• Customer-specification worship. The team treats the customer document as complete and skips stage 2. Detect it by checking the ratio of supplemented to explicit requirements; a near-zero supplement rate on a new product family is a red flag, not efficiency.
• Unverifiable requirements. Phrases such as "robust" or "long life" survive into the baseline. Detect them with a keyword scan of the requirement list for adjectives without numbers.
• Late requirement discovery. New needs appear during 3D design or after first samples. Detect it by counting requirements added after baseline; each one should trigger a root-cause question about which stage missed it.
• Concurrent engineering on paper only. Manufacturing and quality sign the review sheet but never contribute content. Detect it by auditing the origin column — if no requirement traces to those functions, the review was ceremonial.

How to Verify the Output

Verification happens at two levels. At the requirement level, confirm that every line has a source, an owner, a measurable criterion and a verification method, and that the trace matrix has no orphan features (drawing callouts with no requirement behind them) and no orphan requirements (requirements with no feature). At the project level, the proof is behavioural: a first-time-right pass with no major design change, a single test round, and delivery on or ahead of schedule. Track the number of engineering change requests raised after design freeze — in this project it was zero for major changes, and that number is the honest KPI for requirements management.

Links to the Neighbouring D-Steps

This work sits at the front of the 8D chain and determines how the rest behaves. A complete requirement set is the input to D2 (problem description) — without it, "the problem" cannot be separated from "a missing requirement." It feeds D3 (containment), because a requirement gap discovered late forces containment actions on shipped samples. It is the reference against which D4 (root cause) distinguishes a design fault from a specification fault. Most importantly, it protects D5/D6 (corrective action and validation): corrective actions that add requirements retroactively are far more expensive than requirements captured up front, and validation in D6 is only meaningful against a frozen, traceable baseline. In short, the four-stage funnel is where D5 and D6 are made cheap.