One of the reasons that we have feature creep is that many (most?) software teams either don’t know to, or don’t know how to, dissect feature requests from cust

One of the reasons that we have feature creep is that many (most?) software teams either don’t know to, or don’t know how to, dissect feature requests from customers. Imagine one of your customer requests a feature, e.g. “add a button on form X that transmogrifies a foo into a bar and then copies it to form baz”. The request is communicating multiple things and blurring them together. First, your customer is telling you that they have a business problem that needs to be solved, eg converting foos into bars and making them available to other business processes. Second, they are telling you that in their current process in their business, which likely is centered on particular people with particular personalities, the best solution for them (“best” here means “least amount of stuff I have to change and grief I have to deal with”) is a button that does the conversion and then takes the next step in their workflow. If you build the feature exactly as requested, it will likely only delight exactly one customer. On the other hand, if you decompose the request into its different constituent parts, and then build the unique features in such a way it can be composed into arbitrary workflows, you are likely to delight many customers. In my example, maybe you build some kind of library function that converts foos into bars, and then have a general way to compose it. If I were writing Microsoft Excel, I might implement a ConvertFooToBar() function and make it available in both formulas and in script. In other words, dissect customer requests carefully, implement the uniqueness and throw away customer specific workflows in favor of composability. In fact it’s a lot like the Unix philosophy. There are other kinds of feature requests that may not initially seem to fit this model, like security features. One I have gotten a lot (and made myself) is “federated login”. You still need to dissect these to separate business problem from workflow, eg the business problem might be “I don't want you having a list pf all my users and their passwords”; again you need to aim for composability while solving the business problem. Separately, at a previous job, we stopped using the term “minimum viable product” because such MVP products are almost invariably shitty. Instead, we adopted the term “minimum lovable product”, implying that the product must not only be useful and fit for purpose but must also not be onerous to use; you don't want customers to discard it as soon as anything else comes along that isn't as painful.