In a sufficiently complex system with a big enough hierarchy, personal OKRs become quite far from the end product due to necessity. If the product objective is

In a sufficiently complex system with a big enough hierarchy, personal OKRs become quite far from the end product due to necessity. If the product objective is to grow an app to 100m users, the objective of a backend distributed systems team would be to scale the system to handle the load. If front end requirements change, for example the app needs to serve videos instead of images, entire OKRs of the backend team might need to be rewritten. If requirements change often enough the backend team OKRs just become meaningless. If they follow your model, the backend team objective would be to just "help the product scale", and the personal OKRs would be just to "help the team scale the backend and make my EM happy" because there's no way to really plan for what the product team wants next. That may well be the only thing that can be done, but it's a degeneration to a system that offers no clear accountability, and just points to the futility of sticking to the OKR model in a large organization that needs to move fast.