This is an incredibly convoluted hypothetical trying to negate the idea that users notice and/or appreciate how quickly their applications start. Usually as a PM you are managing multiple engineers, one of which I would assume is capable of debugging and eventually implementing a fix for faster start times. Even if they can't fix it immediately due to whatever contrived reason you've supposed, at least they will know where and how to fix it when the time does come. In fact, I would argue pretending there is no issue because of your mountain of other problems is the worst possible scenario to be in.

I don't think that fits MS Office. The situation is more that you have a working, usable word processor which has all the festures your user needs. Since many years ago. But your UI designer thinks it can be a little more beautiful but much slower. Of course you give that way too much priority.

On my Laptop where I am forced by my company to run windows, I run word 2010 and it runs far better(speed and stability) that the newest word I have to use ob my office pc.

Many of the important decisions are made at design and review time. When that team adds PDF support, they should act unlike the Explorer team and avoid unnecessary O(n^2) algorithms.

Part of getting this to happen is setting the right culture and incentives. PM is such a nebulous term that I can't say this definitively, but I don't think the responsibility for this lies with them. Some poor performance is simply tech debt and should be tackled in the same way.

$WORD_PROCESSOR employees should be capable of this: we've all seen how they interview.

Many things are slow because few programmers (or managers) care. Because they'll argue about "value" but all those notions of value are made up anyways.

People argue "sure, it's not optimal, but it's good enough". But that compounds. A little slower each time. A little slower each application. You test on your VM only running your program.

But all of this forgets what makes software so powerful AND profitable: scale. Since we always need to talk monetary value, let's do that. Shaving off a second isn't much if it's one person or one time but even with a thousand users that's over 15 minutes, per usage. I mean we're talking about a world where American Airlines talks about saving $40k/yr by removing an olive and we don't want to provide that same, or more(!), value to our customers? Let's say your employee costs $100k/yr and they use that program once a day. That's 260 seconds or just under 5 minutes. Nothing, right? A measly $4. But say you have a million users. Now that's $4 million!

Now, play a fun game with me. Just go about your day as normal but pay attention to all those little speedbumps. Count them as $1m/s and let me know what you got. We're being pretty conservative here as your employee costs a lot more than their salary (2-3x) and we're ignoring slowdown being disruptive and breaking flow. But I'm willing to bet in a typical day you'll get on the order of hundreds of millions ($100m is <2 minutes).

We solve big problems by breaking them into a bunch of smaller problems, so don't forget that those small problems add up. It's true even if you don't know what big problem you're solving.

I have uBO, they're still obscenely large.

untrue. what bloats the modern web is the widespread AND suboptimal use of web frameworks. otherwise, making adblockers would dramatically speed up the loading of every website that uses ads, while it is true to some extent, is not the entire picture. anyways, i'm not saying that these libraries are always slow, but the users aren't aware of the performance characteristics and perf habits they should use while making use of such libraries. do you have any idea how many tens of layers of abstractions a "website" takes to reach your screen?

  > No one paper cut is the cause of death, but all of them are when you have a thousand.

ironically, sometimes its the reactions to big issues that cause paper-cuts to flourish (aka red-tape, incident mitigation, rushing to deadlines, "temporary" bug fixes piling up etc etc)