Feature's hierarchy of needs

So I watched Gojko's video Reinventing software quality where he talks about a software quality model that is based on Maslow's hierarchy of needs. He says that of course his model is wrong, as all models, but at least it  worked for the given problem context.

For each layer just enough work is invested to reach the next one. So if it is deployable and functionally ok, there is no need to make the deployment faster or redesign the code ... If the system is usable  the next step is to measure its usefulness; is anybody using it? If not, where is the point in maintaining it, etc. The last step is to verify if it is successful in terms of business value.

So, I found that approach very interesting and after reading 'Impact Mapping' I came up with a similar model (which is of course wrong), but just for a single feature.

Before the feature can be developed there needs to be a related business value or goal, the purpose of it's life. The customer formulates a problem he wants to be solved: 'increase sales by 10%' or 'being able to sell bundles'. After that  the feature is developed, is functionally ok, can be deployed, is performant and usable.
I removed 'useful' as in my opinion  for a feature this is part of being successful. However, it is successful if the business goal was reached; 'sale increased by 10%' or if the customer accepted it at the live demo.

You ain't gonna need it

Now it is time for self-actualization, meaning it is now time to invest in it. Within Maslow's pyramid it is possible to desire the next layer even if the current one is just fulfilled to 70%. And that should be the same for our feature. There was no need to have 100% test coverage or to even use TDD (of course it results in better quality, but costs 30% more time). No need  doing exploratory testing for several hours by 3 testers.

We'll get it “right” the third time.

But now as we have the certainty that this feature is worth the effort, we start to redesign it, invest in its quality, secure it etc. so we can decrease later maintenance costs. The last step is done if the defined quality level is reached and non functional requirements are met.

So, my point is, if there is a lot of uncertainty (there mostly is) get the feature out as fast as possible, to learn and to know if the feature is worth the effort and especially the money. If this is the case, invest in it immediately to reduce ongoing maintenance costs.