If the CEO of LG wants to add a new button to the remote on one of their TV models, this will require prototyping the new remote, designing changes to the PCB and plastic casing, getting on the same page with their manufacturing contractor, and updating support documentation. I've certainly left out a few steps, but executives at a CRM SaaS company could ask for a 'Send Profile' button mid-morning and expect to see it in front of customers before lunch. This dictates a lot of what it means to work in the SaaS industry. If you are writing line-of-business applications with web-browser clients, you aren't constrained by having one shot to get your program right before it is written onto a game cartridge, and you aren't constrained by hardware specifications for 2000's PC programs. You have a much freer hand to pursue 'what drives business value to customers', which is incredibly nebulous.
Do you actually need that "Send Profile" button? Is there work scheduled for the next quarter that will automatically share profiles across customer profiles? What else would the engineer tasked with adding this button be doing, and is that more valuable? Is this customer on the verge of cancelling? Is this needed today? These are not always easy questions to answer, and they often can't be massaged into an Excel model to min/max a decision, especially given the relevant interpersonal dimensions. If you want to run your SaaS company into the ground, say 'yes' to every single customer feature request. At best you will make a confusing Frankenstein’s monster of an application that does nothing particularly well (other than confusing your customers). At worst your best engineers will become demoralised and consider other options as they see a piece of software crawling with bugs losing its battle against entropy.
The power to ship in less time than it takes to brew a pot of coffee can be terrible in the wrong hands, but it underscores that a lot of B2B SaaS companies are paid for their judgment on relatively subjective decisions. This can also be about how you model the business problem in the first place: if you are writing an expense reimbursement application, should you make an assumption that every expense is attributable to one budgetable category? That doesn't sound unreasonable. But sometimes that model won't be accurate. Let's say one of your customers sends an engineer to a conference. This engineer is presenting at one of the major sessions, but you've found out that some important customer prospects will be in attendance so you'll also need your engineer to introduce themselves, and perhaps do some wining-and-dining. If this hypothetical employee expenses his Delta ticket to "Sales Travel" rather than "Engineering: Other" because they've procrastinated on their expenses long enough that the prospect became a customer then that's not the end of the world, but why not have fractional expense categories? That may be required for some customers, but any time a one-to-one restriction is relaxed you've made the problem more complicated. How should rounding be handled? Are there accounting consequences for doing so? If an expense is split between sales and engineering, should there be an approver from both teams?
The contrast between B2B SaaS and open-source HTTP servers is telling: it isn't that there's no room for different approaches on domain model and feature sets, but the choices are more constrained. Apache and Nginx have made meaningfully different technical choices, but the minimal feature set is specified in handful of RFCs. These programs and the projects backing them have a narrow, well-defined mandate for the job they are supposed to do, requiring fewer (but by no means zero) quasi-subjective decisions about where to add incremental value. Spolsky's Strategy Letter V explains how open source software is a compliment to commercial software, but 'what type of judgement calls did the authors have to make' is a factor in determining which category of software a problem will end up in.