Reducing latency is mostly easy to measure, has directly understandable implications, is likely (and understood to be likely) quite difficult to pull off on a product like maps. It's basically a perfect promo packet project.
The example given by the author - fixing lots of tiny features in sheets - is the opposite. Difficult to measure, lots of little and difficult to explain implications, sounds kinda easy - many individual items probably are just work.
I disagree. Add a couple of these features, put them behind an experiment flag, and inspect metrics that matter. What usage are they getting? Do users in the experiment use the product more frequently? And for longer periods? If not, perhaps feature parity with Excel is not the highest impact project, despite the feature requests. If you are finding it hard to come up with measures that show impact towards your orgs' OKRs, this is also a signal that your pet project may not be the best thing for you to spend time on in the eyes of your bosses.
At a high level, promo is an incentive that directors and VPs use to keep an org working towards strategic goals. You may disagree with those goals, but that doesn't necessarily mean promo is broken.
Think about how companies choose between office and google workspace, especially excel v sheets, and the buying process. And think about the industry/function where it matters most - finance. You aren't going to see sheets usage tick up next qtr because you added 5 features that ibankers use. Usage of those feature will slowly go up, and when mixed with 20 other things you'll slowly see more finance users. Hopefully. Maybe Goldman will switch, and others will follow. Whoever is running Sheets is in a long term game. Much of enterprise software is like this. It isn't Facebook where you often get instant feedback.
I guess this works for explicit features, but might not work for omissions, especially the tiny features and bugs.
Small annoyances might add up, and the GP's point is that this incentive system doesn't reward those who try to fix them. Unless... somebody's deranged enough to keep known and fixed bugs in a customer facing product behind an experiment flag to see how a small percentage of unlucky users would react...
The example given by the author - fixing lots of tiny features in sheets - is the opposite. Difficult to measure, lots of little and difficult to explain implications, sounds kinda easy - many individual items probably are just work.