Honest question: does this model apply when your product can't at any point be, for lack of a better word, half-baked?
Say you're making a security product or working on control code for rocket thrusters.
Small and simple doesn't have to mean janky and shitty. You reduce scope, not reduce quality.
To carry on with your two examples, I'll make up a security product and a product related to control code for rocket thrusters.
For the security product, let's do a "secure storage on Dropbox" product. Version 1, you do as much as you can with with existing libraries and pieces. Use OpenSSL to handle the crypto bits. The UI has two options: the passphrase for the encrypted storage, and the path to the encrypted directory (and a system tray icon).
Right away, I can think of all kinds of features that would be cool to add to this product, but DON'T build them out for V1. Eventually, you can add PKI so that you can have different keys on different devices and selectively revoke them. And build out the mobile app so that you can access your encrypted stuff on the go. And bake in crypto libraries so that you're not just calling out to openssl.exe. Etc etc. That's V2, V3, V4...
For rocket thruster control code... You're going to need a way to test it. Start with a thruster simulator. You're going to probably need a FEA model and a numeric solver. It's not going to be "simple" as in "I banged it out in a week", but it's way less scope than building and testing thruster control code. Once you've got the simulator built out and working reliably, start selling the simulator while you build out your own control code.
Hell, if you want to keep it super simple, start out by only simulating solid fuel model rocket engines. You can use that to bootstrap the verification process (compare simulation results against measured results for a couple bucks/launch)