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