I've worked on a project that failed and I always felt speed was a real problem. I tried but never succeeded in convincing people that speed was the issue.
In our case, our users had a specific flow through the application they would use, and it worked, but it required clicking many (10+) buttons and waiting for a web request on each. People on the team were satisfied that the flow worked and going through it didn't take TOO long... But what people on our side didn't get is that our customers had to go through this flow dozens if not hundreds of times - some users would need to do it this many times regularly. It effectively made our users hate using the product, or they would refuse to, or they'd use it but only a little bit and they'd try to minimize the cost.
I tried to get people on our side to experience the pain points, e.g. asking PMs to follow this flow one hundred times, and things like that, but I never could get through to anyone that we should redesign and refocus on making it usable. Maybe a mockup of a faster flow was what was needed to be persuasive there.
I've got a team that I am actively trying to convince that this is a problem, and I am scared that I'm failing. We're introducing new components that have deliberately introduced latency to make transitions smoother (and I mean LARGE latency. 500ms large). I brought up the terminal insanity of doing this and got in response "no one has complained about it so far... we can tweak it if you like, but I'm following best practices" (citing nothing).
I bring this up with others, and they are lukewarm about it. I feel like our company is in deeeeep shit if I don't convince people this is a problem.
There are two levels of slowness being talked about here, both valid. One is that 16ms vs. 60ms response to typing and touch. The other is yours, and I think yours is the more problematic one. Not only do those multi-second waits accumulate through the workday to be a significant fraction of the day, but each one presents an opportunity for the user's mind to wander, or other parallel tasks to be switched to, with a high cost of returning to the current state.
In our case, our users had a specific flow through the application they would use, and it worked, but it required clicking many (10+) buttons and waiting for a web request on each. People on the team were satisfied that the flow worked and going through it didn't take TOO long... But what people on our side didn't get is that our customers had to go through this flow dozens if not hundreds of times - some users would need to do it this many times regularly. It effectively made our users hate using the product, or they would refuse to, or they'd use it but only a little bit and they'd try to minimize the cost.
I tried to get people on our side to experience the pain points, e.g. asking PMs to follow this flow one hundred times, and things like that, but I never could get through to anyone that we should redesign and refocus on making it usable. Maybe a mockup of a faster flow was what was needed to be persuasive there.