However, speed is not “the killer feature”. Speed does not add any value in isolation; your app needs to solve a need for the user first. If you don’t have PMF don’t think about speed yet.
The article gestures at objectivity by linking some cases where people measured revenue gains from speed improvements, but fails to follow through and actually propose an experiment or ROI calc. If you think your app is slow, run an experiment and measure the impact on conversion. (You can even take a page from Google’s book and _add_ delay with a simple sleep() if you don’t want to spend any time on perf work before you get data. Or just do the first bit of low-hanging fruit and measure the impact.)
Talk to your users and ask them what frustrates them in the app. It might be “takes so long to check out”, or it might be “it just lacks feature X that competitor Y has”. I’d suggest it’s unwise to spend time on perf work if you are pre-pmf and the main feedback was the latter. Again, do experiments too because customers don’t always tell you what they need. In particular enterprise users often don’t care as much about speed, as long as you tick all of the boxes. Many users are used to line-of-business software that is slow and buggy, so your bar in B2B is not always high here.
Finally do an ROI calculation. If a perf iteration is going to cost you $20k in dev resource, and get you 7% improvement on $10k of monthly revenue, that might not be the right thing to focus on. Ideally you’re looking at features that will improve your top of funnel volume more than that.
It’s all a trade-off. It depends on your company’s level of maturity, Product/Market fit, and the value of the marginal feature that you’d be deferring to make your app go faster.
If we interpret this to be a political manifesto carrying the message “you should care more about speed/performance”, I’d prefer the meta-level “you should care more about trade-offs and marginal value”.