It sounds harmless.
A product is already taking shape. The design looks good, prototypes are being built, and the development team is making progress.
Then someone asks:
“Can we just add this feature?”
Maybe it is another button. A different locking mechanism. Bluetooth connectivity. An additional sensor. A slightly larger display. A new material. An extra adjustment point.
From the outside, the request might seem small. Sometimes it genuinely is. But in product development, there is one problem with the word “just.”
There is rarely such a thing.
A seemingly minor change can affect mechanical components, electronics, software, manufacturing, testing, documentation, cost, schedules, and even regulatory requirements. What looks like a two-hour CAD modification can turn into weeks of additional development.
That doesn't mean products shouldn't change. Iteration is fundamental to engineering, and many of the best products become successful precisely because teams identify opportunities for improvement along the way.
The danger comes when teams underestimate what those changes actually mean.
One of the easiest mistakes to make when looking at a product is seeing each component independently. Change the handle. Move the button. Add the sensor. Make the housing smaller. Simple enough. Except engineers rarely have the luxury of changing one thing in isolation.
Imagine a team developing a handheld medical device and deciding to add a larger battery late in development to improve operating time. The battery itself might only cost a few dollars more. But now the battery doesn't fit inside the existing enclosure.
So the housing gets larger. The larger housing changes the ergonomics of the device. Internal mounting features have to move. The printed circuit board may need to be repositioned. The device's center of gravity changes. The injection mold may need modification. Packaging may need to change. Previous drop testing may no longer represent the final configuration.
Suddenly, “use a bigger battery” isn't a battery change anymore.
It's a product change.
This interconnected nature of engineering is one reason seemingly small modifications can have surprisingly large consequences.
There is a name for the gradual expansion of a project's requirements: scope creep.
It rarely begins dramatically.
Nobody walks into a meeting and says, “Let's completely change the product, increase the budget, and delay the launch.”
Instead, it happens one small decision at a time.
Could we add another adjustment? Could we make this wireless? Could we offer another configuration? Could this component be removable? Could the display show one more piece of information?
Individually, each request may seem reasonable. Collectively, they can transform the scope of a project. The original product might have contained 20 major requirements. Several months later, it was 35.
But the budget, engineering resources, and launch schedule may still be based on the original 20. That's when projects begin falling behind.
This is one of the most frustrating concepts for people outside engineering to understand.
Sometimes the physical design change really does take five minutes. Moving a hole 3 millimeters in CAD might be incredibly easy. But changing the CAD model isn't necessarily the work.
The real question is:
What does that change affect?
Maybe that hole interfaces with a mating component. Now its drawing needs to change. The updated drawing needs to be reviewed and released. A supplier already has the previous revision. Existing prototype parts may no longer be usable. A fixture was designed around the previous location. Tooling may already exist. An assembly procedure references the old configuration. Previous testing used the old geometry.
Suddenly, moving one hole requires communication between engineering, manufacturing, suppliers, quality, and project management.
The mouse click was easy.
Managing everything that mouse click affected wasn't.
Early in product development, changes are relatively cheap.
If an engineer sketches three concepts on paper and decides the second one won't work, almost nothing has been lost.
Change the sketch. Move on.
The same is generally true during early CAD development. Changing dimensions, materials, mechanisms, and layouts may require engineering time, but the financial consequences are still relatively limited.
As the project advances, the design itself becomes increasingly connected to physical assets, documentation, testing, inventory, and other parts of the organization as development progresses.
That is why experienced development teams try to resolve major uncertainties as early as possible.
Changing direction isn't inherently bad. Changing direction late is where things get painful.
For medical devices, feature creep can create another layer of consequences.
A design change may not only affect engineering and manufacturing, it may affect the device's risk profile and regulatory documentation.
Suppose a company decides to add wireless connectivity to an existing device.
From a customer's perspective, that's a feature.
From an engineering perspective, it could introduce:
The feature may be valuable enough to justify all of that. But the decision should be made with an understanding of the complete impact, not simply because adding wireless connectivity sounds useful.
The same principle applies to materials, patient-contacting components, software functions, alarms, sensors, and mechanical safety features.
Medical device development requires extensive documentation and risk management, meaning a change to the physical product can create changes throughout the development record as well.
Imagine that a product successfully completes a series of verification tests. Then the design changes. Are those test results still valid?
Sometimes yes. Sometimes no.
The answer depends on what changed and whether that change could reasonably affect the tested performance:
Engineering teams therefore have to evaluate whether previous testing remains representative of the final device. In some cases, additional testing is required.
This is one reason seemingly minor late-stage changes can become surprisingly expensive. The cost isn't necessarily the new component.
It's proving that the product still works after the component changed.
There is also a larger product-design question worth asking:
Does the feature actually make the product better?
Engineers and inventors naturally want to improve their products. Once development begins, new possibilities become visible, and it can become tempting to solve every problem the team encounters.
Eventually, however, additional functionality can begin working against the product.
More features can mean:
Some of the best engineering decisions involve deciding what not to include.
A product that performs five important functions extremely well may be more successful than one attempting to perform fifteen.
Good engineering isn't about maximizing the number of features. It's about maximizing the value of the product.
Absolutely not. A development process where nothing ever changes would probably be more concerning.
Prototypes exist specifically because engineers expect to learn something from them. Testing is performed because teams want to discover weaknesses. User feedback matters because designers cannot anticipate every real-world interaction.
Iteration is engineering.
The goal isn't to eliminate changes. The goal is to make them intentionally.
Before adding a feature, teams should understand what problem it solves, how much value it provides, and what consequences it creates elsewhere in the project.
A useful question isn't:
“Can we add this?”
The better question is:
“Is adding this worth everything that comes with it?”
That small change in thinking can prevent enormous amounts of unnecessary development.
Product development is a constant balancing act between possibility and practicality. There will always be another feature that could be added, another mechanism that could be improved, or another problem that could be solved. But eventually, a product has to leave the engineering department and enter the real world. Successful development requires knowing when an improvement creates meaningful value, and when it simply creates more development.
So the next time someone in a product development meeting says:
“What if we just add…”
It may be worth paying attention to the word that comes next. Because in engineering, some of the most expensive projects begin with something that sounded surprisingly simple.
If you have questions about the development process, feel free to reach out for help. We do hundreds of free consults every year to help guide innovators along their path of device development.