You Don't Have a Goal Until You Have a Number
Most engineering projects start with goals. Fewer start with justified goals.
When I took over as frame lead for Bearcat Motorsports' 2024 IC car, the first question I had to answer wasn't "how do I design the frame?" It was "what does a good frame actually need to do, and how do I put a number on it?"
The obvious answer is: be stiff and be light. But that's not an engineering goal. That's a direction. An engineering goal has a number attached to it, a reason behind the number, and a way to check whether you hit it.
Where the Stiffness Target Comes From
The frame doesn't exist in isolation. It sits structurally in series with the front and rear suspension , think of it as three springs connected end to end: the front suspension, the chassis, and the rear suspension. The total system stiffness is governed by the weakest link.
If the chassis is significantly softer than the suspension, changes to your anti-roll bars and spring rates stop producing predictable handling changes. The chassis flexes and absorbs the input instead of transmitting it to the tires. Suspension tuning becomes guesswork , you're adjusting settings on a system you can't actually control.
To quantify where the frame needed to be, I pulled the maximum front and rear suspension stiffness values from the suspension team and modeled the full system. The output is a curve showing how much of the suspension's potential you're actually using as chassis stiffness increases. What the curve shows clearly is that the benefits taper off sharply , for our setup, the knee of the curve sits around 1,500 ft·lb/deg. Past that point, you're adding structure and mass for diminishing returns in actual vehicle performance.
We set our target at 1,700 ft·lb/deg. That number sits comfortably past the knee, accounts for measurement uncertainty, and was specific enough to evaluate every design iteration against directly.
Mass Target: Same Logic, Different Lever
The mass target followed a similar process. Frame mass sits low in the car and contributes to both total vehicle weight and center of gravity height. Lower center of gravity improves cornering , the car transfers less weight to the outside tires, which means more grip available at all four corners. We set a target of 62.7 lb without mounts and subframe, aggressive but achievable with careful tube selection, this was chosen based upon historical data from the team.
The two targets are in direct tension. Every tube you add to stiffen the structure adds mass. Managing that tradeoff is what simulation (FEA , finite element analysis, software that predicts how a structure deforms under load) is actually for. Not just confirming that a design works, but finding where the structure is underworked and material can be removed.
Goals Beyond the Performance Numbers
Set process goals alongside performance goals. Competition judges don't just score your stiffness number , they score your ability to justify every decision you made throughout the year. That requires a different kind of goal-setting: simulation-to-test correlation targets, build timeline milestones, documentation discipline.
We targeted less than 5% error between simulation predictions and quasistatic physical test results. That goal shaped how we ran simulations, how we set up physical tests, and how carefully we calibrated the model before trusting its outputs. Having that target explicitly stated meant "good enough" had a definition.
What This Means for Your Project
The most transferable lesson here: the difference between a real engineering goal and a wishful direction is a number, a derivation, and a test.
"Make it strong enough" is not a goal. "Survive 500 load cycles with less than 0.1mm deflection at the mounting interface" is a goal. The first leaves every downstream decision open to interpretation. The second closes the design space and makes tradeoffs visible , which means when you're deciding between two design options, you're comparing numbers rather than opinions.
If you're developing a hardware product and your requirements are still written in terms of directions rather than numbers, that's the first thing worth fixing. Everything downstream , design decisions, simulation, testing, manufacturing , gets easier when success has a clear definition.