Because I think you do.
You see, Mac Andreessen’s famous quote about how “software is eating the world” is surprisingly close to the mark.
A lot of my customers are typical manufacturing companies, often building some kind of machine. Typical German Mittelstand. They consider themselves mechanical engineering companies, manufacturing companies, and two or three decades ago they may have been right.
But increasingly, they aren’t right anymore. Increasingly, their products (while physical), are software-defined!
Sure, they assemble machines. These machines are put on trucks, and sold to customers all over the world. But… increasingly, somewhere in that machine, there is a computer. And increasingly, this computer plays a pivotal role in the success, indeed the functioning of that machine.
Software-defined machines. They pose new, and perhaps unfamiliar, challenges.
 For the sake of argument, imagine that such a company designs a new component for their machines. A drill, let’s say. Because the machine needs to drill something.
Certainly, the drill is a physical device. It will be designed by mechanical engineers, it will be machined out of steel, and bolted on the physical machine.
But it’s also a software artifact. The machine’s control computer has to be aware of the new drill. Of its dimensions perhaps, and certainly of how to drive it, how to actually use it during the machine’s operation.
Now, consider: what if the mechanical engineer were to make an engineering mistake. Say, the drill has a vibration problem. Maybe we could come up with a clever way for the software to drive it such that the vibration issue can be mitigated.
Conversely, imagine the software engineer messes up. The drill is a mechanical work of art, performing flawlessly. But its driving software has problems. What could the mechanical engineer do to mitigate?
…nothing.
This is what I mean by software-defined products: their success is inextricably linked to the quality of the software that runs on (or alongside) them.
Are your products software-defined? Are you sure you’re not working for a software company?
And are you developing your software-defined product according to state-of-the-art development practices? Because you can’t afford not to.