When you are developing a medical device, software features are easy to ask for.

• Can we store the user’s current settings so they persist across power cycles?
• The touchscreen interface needs to be buttery-smooth, like an iPhone.
• Can we connect this to the cloud?

Each of these requests likely requires additional hardware, and sometime a LOT of additional software.

• storing information across power cycles means adding EEPROM memory, with the associated firmware driver, error checking, etc.
• buttery smooth touchscreens typically means a microcontroller-driven UI won’t do – you need an embedded linux board running a more powerful UI framework such at Qt
• Connect to the cloud? Oh boy. Wireless connectivity, cloud data storage, bootloaders, remote updates, encryption, cybersecurity, maybe a mobile app, not to mention you probably need to build a web SaaS to view and use the data. How much benefit do you get from connecting this thing to the cloud again?

Product managers who are not software engineers often have limited understanding of what features are easy, what features are hard, and what features are REALLY hard. Don’t take this as me bad-mouthing product managers – it’s a very difficult job.

Software developers and their managers have a responsibility to clearly communicate the trade-offs associated with each feature request. They also have a responsibility to educate themselves about other domains in the business – such as sales, marketing, and manufacturing – so that they can participate intelligently in product definition discussions.

There are thresholds in functionality that, when crossed, lead to big step jumps in project cost, time, and risk. Sometimes these thresholds are worth it, sometimes not. You do yourself no favors by keeping your head down and just doing what you’re told. Take a business-level view of these decisions, and give your viewpoint openly and honestly.

Be safe out there, and happy developing.