Many engineering problems look technical on the surface but are actually constraint problems. The hard part is rarely the math or the hardware. It is understanding what the problem really is.
My typical process
- Understand the real requirement.
- Identify the constraints.
- Test multiple strategies.
- Document everything.
- Improve continuously.
Why this order matters
If you skip step one, every later step optimizes the wrong thing. I have watched expensive systems get built around a requirement that nobody actually had, simply because the question "what are we really solving?" was never asked out loud.
The best solution is rarely the most complicated one. The biggest challenge is usually understanding the problem correctly.
A worked example
A request arrives: "We need a camera that can see 1 um defects."
Taken literally, that is a sub-micron imaging system: high-NA optics, vibration isolation, focus control, slow scanning, serious money. But walking the requirement back changed everything:
- What happens when this defect ships? It causes a short in a later process step.
- How small can the defect be and still cause the short? Analysis of failed parts showed the harmful ones were 20 um and larger.
- Why did someone say 1 um? Because the smallest defect anyone had ever photographed in the lab was about 1 um, so it became "the requirement".
The real requirement was detect 20 um defects reliably at line speed. That is a completely different system - roughly 10x cheaper, far more robust, and actually buildable within the cycle time.
Questions I always ask first
- What decision will be made with this result? (Scrap? Rework? Process feedback?)
- What does a miss cost, and what does a false alarm cost? They are almost never symmetric.
- Which constraints are physics (cycle time, space, cleanliness) and which are preferences ("we have always used brand X")?
- Who owns the problem after I leave the room?
What this looks like in practice
- I write the requirement down in one sentence and read it back to whoever owns the problem.
- I list the constraints that are non-negotiable (cycle time, budget, space, cleanliness) separately from the ones that are merely preferences.
- I try at least two approaches before committing, because the first idea is usually wrong.
- I keep notes on what failed, not just what worked. The failures are where the reusable knowledge lives.