The feature backlog is rarely more important than performance but you often see it being pushed ahead of nonfunctional concerns for presentational reasons.
For the most part users or companies buy features, not performance. You can have the fastest software ever but if it doesn’t have the features I actually need to use it then, sorry, no dice.
If performance is one of your features then fair enough, but it’s not for a lot of software.
This is NOT true. There is almost always an expectation that your application have a reasonable performance profile. It's often not a captured requirement, but I guarantee you once things slow to a crawl you WILL get an escalation.
Do you know what happens when escalations become too frequent? Progress grinds to a halt as developers have to churn out of what they're doing to address non-functional issues.
Somebody operating at a product owner level rarely has any concept of this stuff. It's up to the engineering team to be the bad guy and tell him or her that they're not going to get their laundry list satisfied in the time that's available and actually deliver usable software.
The problem with your statement is that it was unbounded. What you are saying is “when your performance is bad, features should take a back seat”. That i agree with.
But “reasonable performance” is relative and context dependent
No, I was presenting my experience that when given a choice of features over “quality” (however you choose to quantify it) we almost always see a push for the former. Unless of course you have a robust communications arrangement with your techies.
