During the first half of my career I mostly worked on SaaS products. When I started working on a on-prem system with many large enterprise customers, I quickly learned a few important differences that changed what tradeoffs need to be made every day:
Addressing Bugs
SaaS: Our dev team develops a fix and deploys it
On-Prem: Our dev team develops a fix; we make one or more patches available to customers; every single affected customer needs to deploy the fix
Feedback Cycles
SaaS: You deploy a change; every customer immediately sees the change and can give you feedback
On-Prem: You ship a new major or minor; customers take months to pick up the new version; you might not get substantial feedback for a year after you shipped.
Strong partnerships with your customers can of course make a tremendous difference here. Till someone is trying to use your new features in production, you won’t have get the real feedback.
Support Costs
SaaS: Unless you do some form of A/B testing or a deliberately slow rollout to detect issue you really only have one version you care about.
On-Prem: All versions that are still under support will need to be understood and updated if there is an issue. Minimum support durations are contractually fixed. The more often you ship new majors or minors, the more versions you might have to patch when the next log4shell comes around.
On-prem support durations present you with competing forces. Every customer will want the version they are happy with to be supported as long as possible. At the same time customers want the new feature that they care about as quickly as possible. This is really where having long term support versions becomes valuable.
When I first started working on on-prem software, I was appaled by how long it took to get a release out. I was used to days being deemed a complete disaster. We were taking weeks. You get better at something if you do it more often. So I naively proposed to try to ship a new minor release every month. If every minor release is supported for 18 months this will quickly drive up support costs. Every important patch might have to go back to upto 18 branches. In the very least you’ll have to go back and check which versions were affected. You have to have pipelines and documentation for all versions.
This changes the tradeoffs you need to make in your process. Getting an individual change merged and shipped matters less and reducing the number of even smallish bugs that make it in matters more. If you get this wrong, your customers will quickly get frustrated with having to patch your software. They will be more reluctant to pick up new releases. This in turn leads to even more delay between building and shipping a new feature and getting useful feedback from customers.
It’s much harder to deliver incremental value in an on-prem product. This also means you are less likely to have to change direction mid-course (it of course still happens). Between the slower feedback, decreased ability to iterate and the increased cost of bugs, design upfront becomes more attractive and many of its relative costs go down.
Looking back it seems natural that Agile and Lean startups really took off when more products started moving to a SaaS model.